From report at bugs.python.org  Tue Feb  1 00:01:37 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 01 Feb 2022 05:01:37 +0000
Subject: [issue41266] IDLE call hints and completions confused by ints and
 floats
In-Reply-To: <1594370995.93.0.883531134582.issue41266@roundup.psfhosted.org>
Message-ID: <1643691697.32.0.409488739244.issue41266@roundup.psfhosted.org>


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

There are 1000s of open python issues and perhaps 200 for IDLE. I consider this one to be lower priority that enough others to fill my IDLE time.

----------
stage:  -> test needed
versions: +Python 3.11 -Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Feb  1 00:08:29 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 01 Feb 2022 05:08:29 +0000
Subject: [issue46594] Windows "Edit with IDLE >" only has one selection
In-Reply-To: <1643671307.89.0.0253325125686.issue46594@roundup.psfhosted.org>
Message-ID: <1643692109.01.0.246812538852.issue46594@roundup.psfhosted.org>


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

The registry settings should be correctly set by the installer.  The bug is that they are not.  I don't touch the registry, and the last 3 versions are less than 2 weeks old.

----------

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

From report at bugs.python.org  Tue Feb  1 03:29:29 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Tue, 01 Feb 2022 08:29:29 +0000
Subject: [issue46571] Strange `@typing.no_type_check` behavior for class
 variables
In-Reply-To: <1643465522.51.0.205719891345.issue46571@roundup.psfhosted.org>
Message-ID: <1643704169.62.0.634258521902.issue46571@roundup.psfhosted.org>


Change by Nikita Sobolev <mail at sobolevn.me>:


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

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

From report at bugs.python.org  Tue Feb  1 03:48:19 2022
From: report at bugs.python.org (Nathan Shain)
Date: Tue, 01 Feb 2022 08:48:19 +0000
Subject: [issue46596] PyLineTable_InitAddressRange isn't exported - causing C
 Extensions to fail at import
Message-ID: <1643705299.86.0.148763425917.issue46596@roundup.psfhosted.org>


New submission from Nathan Shain <nathan at rookout.com>:

I'm trying to develop C++ Extension that needs to access the new line table. I have a call to PyLineTable_InitAddressRange in my extension. After compiling, "_PyLineTable_InitAddressRange" symbol is undefined in the .so (which is ok so far).

When importing the extension, it fails with this error:

ImportError: /usr/foo/foo.cpython-310-x86_64-linux-gnu.so: undefined symbol: _PyLineTable_InitAddressRange

Obviously python isn't exporting this symbol, and making the dlopen fail

I'd make a PR with a fix, but I'm not sure which approach is appropriate

----------
components: C API
messages: 412237
nosy: nathan3
priority: normal
severity: normal
status: open
title: PyLineTable_InitAddressRange isn't exported - causing C Extensions to fail at import
versions: Python 3.10

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

From report at bugs.python.org  Tue Feb  1 04:10:18 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 01 Feb 2022 09:10:18 +0000
Subject: [issue45339] concurrent.future.ThreadPoolExecutor should parameterize
 class used for threads
In-Reply-To: <1633084673.43.0.269469120691.issue45339@roundup.psfhosted.org>
Message-ID: <1643706618.72.0.665827260082.issue45339@roundup.psfhosted.org>


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

I guess if you are asking for initialization and finalization of thread-specific data in a thread pool -- you need exactly these things (or a context manager).
A custom thread class reveals too many implementation details.
I personally prefer an explicit initializer/finalizer based approach.

----------

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

From report at bugs.python.org  Tue Feb  1 04:11:14 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 01 Feb 2022 09:11:14 +0000
Subject: [issue46487] `_SSLProtocolTransport` doesn't have the
 `get_write_buffer_limits` implementation.
In-Reply-To: <1642956579.88.0.874451356364.issue46487@roundup.psfhosted.org>
Message-ID: <1643706674.26.0.112736316989.issue46487@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
versions:  -Python 3.7, Python 3.8

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

From report at bugs.python.org  Tue Feb  1 04:58:59 2022
From: report at bugs.python.org (Ken Jin)
Date: Tue, 01 Feb 2022 09:58:59 +0000
Subject: [issue46482] `typing.Annotation.__new__` is not covered
In-Reply-To: <1642923930.92.0.866402366544.issue46482@roundup.psfhosted.org>
Message-ID: <1643709539.5.0.127386360071.issue46482@roundup.psfhosted.org>


Ken Jin <kenjin4096 at gmail.com> added the comment:


New changeset 4c0612ad00ba45dbea2a86f7db6d21546cf243f8 by Nikita Sobolev in branch 'main':
bpo-46482: add a test for `typing.Annotation.__new__` (GH-30821)
https://github.com/python/cpython/commit/4c0612ad00ba45dbea2a86f7db6d21546cf243f8


----------

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

From report at bugs.python.org  Tue Feb  1 04:59:01 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 01 Feb 2022 09:59:01 +0000
Subject: [issue46482] `typing.Annotation.__new__` is not covered
In-Reply-To: <1642923930.92.0.866402366544.issue46482@roundup.psfhosted.org>
Message-ID: <1643709541.29.0.492587562827.issue46482@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: +29225
pull_request: https://github.com/python/cpython/pull/31044

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

From report at bugs.python.org  Tue Feb  1 04:59:07 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 01 Feb 2022 09:59:07 +0000
Subject: [issue46482] `typing.Annotation.__new__` is not covered
In-Reply-To: <1642923930.92.0.866402366544.issue46482@roundup.psfhosted.org>
Message-ID: <1643709547.27.0.364773243417.issue46482@roundup.psfhosted.org>


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


----------
pull_requests: +29226
pull_request: https://github.com/python/cpython/pull/31045

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

From report at bugs.python.org  Tue Feb  1 05:02:55 2022
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 01 Feb 2022 10:02:55 +0000
Subject: [issue43721] Documentation of property.{getter, setter,
 deleter} fails to mention that a *new* property is returned
In-Reply-To: <1617491419.64.0.547160681333.issue43721@roundup.psfhosted.org>
Message-ID: <1643709775.45.0.856363105915.issue43721@roundup.psfhosted.org>


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


----------
keywords: +patch
nosy: +iritkatriel
nosy_count: 3.0 -> 4.0
pull_requests: +29227
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31046

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

From report at bugs.python.org  Tue Feb  1 05:07:27 2022
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 01 Feb 2022 10:07:27 +0000
Subject: [issue43721] Documentation of property.{getter, setter,
 deleter} fails to mention that a *new* property is returned
In-Reply-To: <1617491419.64.0.547160681333.issue43721@roundup.psfhosted.org>
Message-ID: <1643710047.47.0.750106222663.issue43721@roundup.psfhosted.org>


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


----------
type:  -> behavior
versions: +Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Tue Feb  1 05:10:23 2022
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 01 Feb 2022 10:10:23 +0000
Subject: [issue46451] Tracing causes module globals to be mutated when calling
 functions from C
In-Reply-To: <1642740862.08.0.497751420234.issue46451@roundup.psfhosted.org>
Message-ID: <1643710223.82.0.051672469067.issue46451@roundup.psfhosted.org>


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

Can you reproduce this in pure Python?
If not, can you produce a minimal reproducer using just NumPy?

If you can't do either, I'm going to have to assume that this is a NumPy or Pandas bug.

Maybe NumPy or Pandas is accessing CPython internals, but not via the C-API, and those internals changed between 3.9 and 3.10?

----------
nosy: +Mark.Shannon

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

From report at bugs.python.org  Tue Feb  1 05:22:37 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 01 Feb 2022 10:22:37 +0000
Subject: [issue46355] [C API] Document PyFrameObject and PyThreadState changes
 and explain how to port code to Python 3.11
In-Reply-To: <1641996684.93.0.427230565464.issue46355@roundup.psfhosted.org>
Message-ID: <1643710957.5.0.573385531247.issue46355@roundup.psfhosted.org>


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


New changeset a4cb31927a1f0ee31025ea1ca82fcbfad44755dc by Petr Viktorin in branch 'main':
bpo-46355: What's New: Note that PyFrameObject are private (GH-31032)
https://github.com/python/cpython/commit/a4cb31927a1f0ee31025ea1ca82fcbfad44755dc


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

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

From report at bugs.python.org  Tue Feb  1 05:25:42 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 01 Feb 2022 10:25:42 +0000
Subject: [issue46482] `typing.Annotation.__new__` is not covered
In-Reply-To: <1642923930.92.0.866402366544.issue46482@roundup.psfhosted.org>
Message-ID: <1643711142.34.0.517095577534.issue46482@roundup.psfhosted.org>


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


New changeset 2532b7c820ec2dc87b19eb322ab92b47f3c77866 by Miss Islington (bot) in branch '3.9':
[3.9] bpo-46482: add a test for `typing.Annotation.__new__` (GH-30821) (GH-31045)
https://github.com/python/cpython/commit/2532b7c820ec2dc87b19eb322ab92b47f3c77866


----------

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

From report at bugs.python.org  Tue Feb  1 05:27:40 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 01 Feb 2022 10:27:40 +0000
Subject: [issue46482] `typing.Annotation.__new__` is not covered
In-Reply-To: <1642923930.92.0.866402366544.issue46482@roundup.psfhosted.org>
Message-ID: <1643711260.33.0.795101021317.issue46482@roundup.psfhosted.org>


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


New changeset 6a188d88c562bfd68ef3a32d148d9b234d50646e by Miss Islington (bot) in branch '3.10':
bpo-46482: add a test for `typing.Annotation.__new__` (GH-30821)
https://github.com/python/cpython/commit/6a188d88c562bfd68ef3a32d148d9b234d50646e


----------

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

From report at bugs.python.org  Tue Feb  1 05:32:07 2022
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 01 Feb 2022 10:32:07 +0000
Subject: [issue44031] test_embed and test_tabnanny fails if the current
 directory is non-ASCII
In-Reply-To: <1620129028.97.0.901022211038.issue44031@roundup.psfhosted.org>
Message-ID: <1643711527.16.0.754753261462.issue44031@roundup.psfhosted.org>


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


New changeset 108e66b6d23efd0fc2966163ead9434b328c5f17 by Irit Katriel in branch 'main':
bpo-44031: fix test_tabnanny failure in non-ascii CWD (GH-31014)
https://github.com/python/cpython/commit/108e66b6d23efd0fc2966163ead9434b328c5f17


----------

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

From report at bugs.python.org  Tue Feb  1 05:32:16 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 01 Feb 2022 10:32:16 +0000
Subject: [issue44031] test_embed and test_tabnanny fails if the current
 directory is non-ASCII
In-Reply-To: <1620129028.97.0.901022211038.issue44031@roundup.psfhosted.org>
Message-ID: <1643711536.15.0.440059628483.issue44031@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: +29228
pull_request: https://github.com/python/cpython/pull/31047

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

From report at bugs.python.org  Tue Feb  1 05:32:20 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 01 Feb 2022 10:32:20 +0000
Subject: [issue44031] test_embed and test_tabnanny fails if the current
 directory is non-ASCII
In-Reply-To: <1620129028.97.0.901022211038.issue44031@roundup.psfhosted.org>
Message-ID: <1643711540.78.0.710608311949.issue44031@roundup.psfhosted.org>


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


----------
pull_requests: +29229
pull_request: https://github.com/python/cpython/pull/31048

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

From report at bugs.python.org  Tue Feb  1 05:44:23 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Tue, 01 Feb 2022 10:44:23 +0000
Subject: [issue46597] Remove Python 3.3 compatibility code from overlapped.c
Message-ID: <1643712263.04.0.804521209967.issue46597@roundup.psfhosted.org>


New submission from Kumar Aditya <rahuladitya303 at gmail.com>:

Remove Python 3.3 compatibility code from overlapped.c.

https://github.com/python/cpython/blob/108e66b6d23efd0fc2966163ead9434b328c5f17/Modules/overlapped.c#L27

----------
components: asyncio
messages: 412245
nosy: asvetlov, kumaraditya303, yselivanov
priority: normal
severity: normal
status: open
title: Remove Python 3.3 compatibility code from overlapped.c
versions: Python 3.11

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

From report at bugs.python.org  Tue Feb  1 05:45:34 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Tue, 01 Feb 2022 10:45:34 +0000
Subject: [issue46597] Remove Python 3.3 compatibility code from overlapped.c
In-Reply-To: <1643712263.04.0.804521209967.issue46597@roundup.psfhosted.org>
Message-ID: <1643712334.29.0.822299251333.issue46597@roundup.psfhosted.org>


Change by Kumar Aditya <rahuladitya303 at gmail.com>:


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

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

From report at bugs.python.org  Tue Feb  1 05:47:00 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Tue, 01 Feb 2022 10:47:00 +0000
Subject: [issue46482] `typing.Annotation.__new__` is not covered
In-Reply-To: <1642923930.92.0.866402366544.issue46482@roundup.psfhosted.org>
Message-ID: <1643712420.93.0.840780053337.issue46482@roundup.psfhosted.org>


Nikita Sobolev <mail at sobolevn.me> added the comment:

Thanks!

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

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

From report at bugs.python.org  Tue Feb  1 06:00:34 2022
From: report at bugs.python.org (Petr Prikryl)
Date: Tue, 01 Feb 2022 11:00:34 +0000
Subject: [issue46598] ElementTree: wrong XML prolog for the utf-8-sig encoding
Message-ID: <1643713234.05.0.62090035158.issue46598@roundup.psfhosted.org>


New submission from Petr Prikryl <prikryl at atlas.cz>:

When ElementTree object is to be written to the file, and when BOM is needed, the 'utf-8-sig' can be used for the purpose. However, the XML prolog then looks like...
    
    <?xml version='1.0' encoding='utf-8-sig'?>
    
... and that encoding in the prolog makes no sense. Therefore,
the utf-8-sig is changed to utf-8 for the purpose.

To fix the situation, the following two lines should be added to
`cpython/Lib/xml/etree/ElementTree.py`

`elif enc_lower == "utf-8-sig":
     declared_encoding = "utf-8"
`

just above the line 741 that says 
`write("<?xml version='1.0' encoding='%s'?>\n" % (
       declared_encoding,))`

I have already cloned the main branch, added the lines to `https://github.com/pepr/cpython.git`, and sent pull request.

I have tested the functionality locally with `Python 3.10.2 (tags/v3.10.2:a58ebcc, Jan 17 2022, 14:12:15) [MSC v.1929 64 bit (AMD64)] on win32`

----------
components: Library (Lib)
messages: 412247
nosy: prikryl
priority: normal
pull_requests: 29231
severity: normal
status: open
title: ElementTree: wrong XML prolog for the utf-8-sig encoding
versions: Python 3.10

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

From report at bugs.python.org  Tue Feb  1 06:01:29 2022
From: report at bugs.python.org (Antony Lee)
Date: Tue, 01 Feb 2022 11:01:29 +0000
Subject: [issue43721] Documentation of property.{getter, setter,
 deleter} fails to mention that a *new* property is returned
In-Reply-To: <1617491419.64.0.547160681333.issue43721@roundup.psfhosted.org>
Message-ID: <1643713289.0.0.71989284646.issue43721@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/issue43721>
_______________________________________

From report at bugs.python.org  Tue Feb  1 06:17:40 2022
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 01 Feb 2022 11:17:40 +0000
Subject: [issue40280] Consider supporting emscripten/webassembly as a build
 target
In-Reply-To: <1586848295.92.0.690921486188.issue40280@roundup.psfhosted.org>
Message-ID: <1643714260.64.0.87303276836.issue40280@roundup.psfhosted.org>


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


----------
pull_requests: +29232
pull_request: https://github.com/python/cpython/pull/31050

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

From report at bugs.python.org  Tue Feb  1 06:20:19 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 01 Feb 2022 11:20:19 +0000
Subject: [issue44031] test_embed and test_tabnanny fails if the current
 directory is non-ASCII
In-Reply-To: <1620129028.97.0.901022211038.issue44031@roundup.psfhosted.org>
Message-ID: <1643714419.12.0.797123717233.issue44031@roundup.psfhosted.org>


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


New changeset 1dcd77280410e4b3bd7b0680f00a38cea466ebd1 by Miss Islington (bot) in branch '3.10':
bpo-44031: fix test_tabnanny failure in non-ascii CWD (GH-31014)
https://github.com/python/cpython/commit/1dcd77280410e4b3bd7b0680f00a38cea466ebd1


----------

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

From report at bugs.python.org  Tue Feb  1 06:32:07 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 01 Feb 2022 11:32:07 +0000
Subject: [issue44031] test_embed and test_tabnanny fails if the current
 directory is non-ASCII
In-Reply-To: <1620129028.97.0.901022211038.issue44031@roundup.psfhosted.org>
Message-ID: <1643715127.61.0.624998516407.issue44031@roundup.psfhosted.org>


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


New changeset 2e9f77f9d4fc282666ff85051b6e7ade0eed1d4c by Miss Islington (bot) in branch '3.9':
[3.9] bpo-44031: fix test_tabnanny failure in non-ascii CWD (GH-31014) (GH-31048)
https://github.com/python/cpython/commit/2e9f77f9d4fc282666ff85051b6e7ade0eed1d4c


----------

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

From report at bugs.python.org  Tue Feb  1 06:32:30 2022
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 01 Feb 2022 11:32:30 +0000
Subject: [issue44031] test_embed and test_tabnanny fails if the current
 directory is non-ASCII
In-Reply-To: <1620129028.97.0.901022211038.issue44031@roundup.psfhosted.org>
Message-ID: <1643715150.73.0.88829475232.issue44031@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Tue Feb  1 06:57:48 2022
From: report at bugs.python.org (Marc Mueller)
Date: Tue, 01 Feb 2022 11:57:48 +0000
Subject: [issue43224] Add support for PEP 646
Message-ID: <1643716668.01.0.583209382505.issue43224@roundup.psfhosted.org>


Change by Marc Mueller <cdce8p at gmail.com>:


----------
nosy: +cdce8p

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

From report at bugs.python.org  Tue Feb  1 06:57:47 2022
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 01 Feb 2022 11:57:47 +0000
Subject: [issue46561] Descriptor resolution should own arguments passed to
 descriptors
In-Reply-To: <1643353574.8.0.417486846684.issue46561@roundup.psfhosted.org>
Message-ID: <1643716667.25.0.0570735039215.issue46561@roundup.psfhosted.org>


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

# This needs to be C code for this to fail, I'm writing it in Python for clarity and brevity

class D:
    def __get__(self, instance, owner):
       del C.d
       # There are now no strong references to self
       self.whatever # Access to freed memory

# This can be Python

class C:
    d = D()

C.d

----------
nosy: +Mark.Shannon

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

From report at bugs.python.org  Tue Feb  1 07:26:23 2022
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 01 Feb 2022 12:26:23 +0000
Subject: [issue46072] Unify handling of stats in the CPython VM
In-Reply-To: <1639498673.65.0.709719181358.issue46072@roundup.psfhosted.org>
Message-ID: <1643718383.1.0.775456013873.issue46072@roundup.psfhosted.org>


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


----------
pull_requests: +29233
pull_request: https://github.com/python/cpython/pull/31051

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

From report at bugs.python.org  Tue Feb  1 07:38:41 2022
From: report at bugs.python.org (A-Shvedov)
Date: Tue, 01 Feb 2022 12:38:41 +0000
Subject: [issue46599] Objects/object.c:767:24: runtime error: member access
 within null pointer of type 'PyObject' (aka 'struct _object')
Message-ID: <1643719121.07.0.180413749782.issue46599@roundup.psfhosted.org>


New submission from A-Shvedov <shvedov at gmx.com>:

Hello. Got an error with AFLplusplus, with crafted sample:
https://github.com/a-shvedov/res/blob/master/fuzzing/python/crashes/id:000000%2Csig:11%2Csrc:009074%2Ctime:446401660%2Cexecs:16120011%2Cop:arith8%2Cpos:16%2Cval:-21

Compiled with: clang (version 6.0.0-3) ;

Configure params: --enable-optimizations --prefix= .

Package version: Python-3.9.9 ;

Builded binary info:
python: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, not stripped ;

Stderr with run crafted sample: Segmentation fault ;

AddressSanitizer run:
Objects/object.c:767:24: runtime error: member access within null pointer of type 'PyObject' (aka 'struct _object') ;

AddressSanitizer log attached in logfile.

----------
components: Interpreter Core
files: issue-file_asanlog.log
messages: 412251
nosy: a-shvedov
priority: normal
severity: normal
status: open
title: Objects/object.c:767:24: runtime error: member access within null pointer of type 'PyObject' (aka 'struct _object')
type: crash
versions: Python 3.9
Added file: https://bugs.python.org/file50599/issue-file_asanlog.log

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

From report at bugs.python.org  Tue Feb  1 08:06:00 2022
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Feb 2022 13:06:00 +0000
Subject: [issue46600] Python built with clang -O0 allocates 10x more stack
 memory than clang -O3 on a Python function call
Message-ID: <1643720760.9.0.302596428689.issue46600@roundup.psfhosted.org>


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

Measure using this script on the main branch (commit 108e66b6d23efd0fc2966163ead9434b328c5f17):
---
import _testcapi
def f(): yield _testcapi.stack_pointer()
print(_testcapi.stack_pointer() - next(f()))
---

Stack usage depending on the compiler and compiler optimization level:

* clang -O0: 9,104 bytes
* clang -Og: 736 bytes
* gcc -O0: 6,784 bytes
* gcc -Og: 624 bytes

-O0 allocates around 10x more memory.

Moreover, "./configure --with-pydebug CC=clang" uses -O0 in CFLAGS, because "clang --help" output doesn't containt "-Og". I'm working on a configure change to use -Og on clang which supports it.

----------
components: Build
messages: 412252
nosy: vstinner
priority: normal
severity: normal
status: open
title: Python built with clang -O0 allocates 10x more stack memory than clang -O3 on a Python function call
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Tue Feb  1 08:12:00 2022
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Feb 2022 13:12:00 +0000
Subject: [issue46600] Python built with clang -O0 allocates 10x more stack
 memory than clang -O3 on a Python function call
In-Reply-To: <1643720760.9.0.302596428689.issue46600@roundup.psfhosted.org>
Message-ID: <1643721120.84.0.461411347745.issue46600@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Tue Feb  1 08:15:31 2022
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Feb 2022 13:15:31 +0000
Subject: [issue46600] Python built with clang -O0 allocates 10x more stack
 memory than clang -O3 on a Python function call
In-Reply-To: <1643720760.9.0.302596428689.issue46600@roundup.psfhosted.org>
Message-ID: <1643721331.01.0.602240820841.issue46600@roundup.psfhosted.org>


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

GH-31052 enables -Og when using clang and ./configure --with-pydebug and so the example uses 736 bytes instead of 9,104 bytes.

----------

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

From report at bugs.python.org  Tue Feb  1 08:16:29 2022
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Feb 2022 13:16:29 +0000
Subject: [issue46600] Python built with clang -O0 allocates 10x more stack
 memory than clang -O3 on a Python function call
In-Reply-To: <1643720760.9.0.302596428689.issue46600@roundup.psfhosted.org>
Message-ID: <1643721389.81.0.298191180868.issue46600@roundup.psfhosted.org>


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

This issue is a follow-up of bpo-46542 "test_json and test_lib2to3 crash on s390x Fedora Clang 3.x buildbot".

----------

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

From report at bugs.python.org  Tue Feb  1 08:22:24 2022
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Feb 2022 13:22:24 +0000
Subject: [issue46600] Python built with clang -O0 allocates 10x more stack
 memory than clang -O3 on a Python function call
In-Reply-To: <1643720760.9.0.302596428689.issue46600@roundup.psfhosted.org>
Message-ID: <1643721744.67.0.0627288308468.issue46600@roundup.psfhosted.org>


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

Previous issues about stack memory usage, work done in 2017:

* bpo-28870: Reduce stack consumption of PyObject_CallFunctionObjArgs() and like
* bpo-29227: Reduce C stack consumption in function calls
* bpo-29465: Modify _PyObject_FastCall() to reduce stack consumption
29464

I summarized the results in the "Stack consumption" section of my article: https://vstinner.github.io/contrib-cpython-2017q1.html

----------

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

From report at bugs.python.org  Tue Feb  1 08:25:28 2022
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Feb 2022 13:25:28 +0000
Subject: [issue46600] Python built with clang -O0 allocates 10x more stack
 memory than clang -O3 on a Python function call
In-Reply-To: <1643720760.9.0.302596428689.issue46600@roundup.psfhosted.org>
Message-ID: <1643721928.82.0.47677519142.issue46600@roundup.psfhosted.org>


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

See also bpo-30866: "Add _testcapi.stack_pointer() to measure the C stack consumption".

----------

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

From report at bugs.python.org  Tue Feb  1 08:28:01 2022
From: report at bugs.python.org (Chris Drake)
Date: Tue, 01 Feb 2022 13:28:01 +0000
Subject: [issue46601] Instructions do not work
Message-ID: <1643722081.07.0.215509583519.issue46601@roundup.psfhosted.org>


New submission from Chris Drake <cryptophoto at gmail.com>:

See https://github.com/python/pythondotorg/issues/1774#issuecomment-1025250329

----------
components: macOS
messages: 412257
nosy: cryptophoto, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Instructions do not work
versions: Python 3.11

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

From report at bugs.python.org  Tue Feb  1 08:40:57 2022
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Feb 2022 13:40:57 +0000
Subject: [issue46600] Python built with clang -O0 allocates 10x more stack
 memory than clang -O3 on a Python function call
In-Reply-To: <1643720760.9.0.302596428689.issue46600@roundup.psfhosted.org>
Message-ID: <1643722857.62.0.725903226653.issue46600@roundup.psfhosted.org>


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

stack_overflow-4.py: Update script from bpo-30866 to measure stack memory usage before Python crash or raises a RecursionError.

I had to modify the script since calling a Python function from a Python function no longer allocates (additional) memory on the stack! See bpo-45256 "Remove the usage of the C stack in Python to Python calls".

----------
Added file: https://bugs.python.org/file50600/stack_overflow-4.py

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

From report at bugs.python.org  Tue Feb  1 08:41:23 2022
From: report at bugs.python.org (Ken Jin)
Date: Tue, 01 Feb 2022 13:41:23 +0000
Subject: [issue46564] Near zero-cost super().meth() calls via adaptive
 superinstructions
In-Reply-To: <1643387818.31.0.971991048266.issue46564@roundup.psfhosted.org>
Message-ID: <1643722883.78.0.412023632088.issue46564@roundup.psfhosted.org>


Ken Jin <kenjin4096 at gmail.com> added the comment:


New changeset b9ebde8db7e176e021103745cd012bae700828b5 by Kumar Aditya in branch 'main':
bpo-46564: do not create frame object for super object (GH-31002)
https://github.com/python/cpython/commit/b9ebde8db7e176e021103745cd012bae700828b5


----------

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

From report at bugs.python.org  Tue Feb  1 08:46:28 2022
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Feb 2022 13:46:28 +0000
Subject: [issue46600] Python built with clang -O0 allocates 10x more stack
 memory than clang -O3 on a Python function call
In-Reply-To: <1643720760.9.0.302596428689.issue46600@roundup.psfhosted.org>
Message-ID: <1643723188.95.0.726054970964.issue46600@roundup.psfhosted.org>


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

stack_overflow-4.py output depending on the compiler and compiler flags.

gcc -O3 (./configure):
---
test_python_call: 11904 calls before crash, stack: 704.1 bytes/call
test_python_iterator: 17460 calls before crash, stack: 480.0 bytes/call
test_python_getitem: 245760 calls before recursion error, stack: 0.2 bytes/call

=> total: 275124 calls, 1184.3 bytes per call
---

It's better than stack memory usage in 2017: https://bugs.python.org/issue30866#msg297826


clang -O3 (./configure CC=clang):
---
test_python_call: 10270 calls before crash, stack: 816.1 bytes/call
test_python_iterator: 14155 calls before crash, stack: 592.0 bytes/call
test_python_getitem: 245760 calls before recursion error, stack: 0.3 bytes/call

=> total: 270185 calls, 1408.4 bytes per call
---

clang allocates a little bit more memory on the stack than gcc.

I didn't try PGO or LTO yet.

----------

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

From report at bugs.python.org  Tue Feb  1 08:47:26 2022
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Feb 2022 13:47:26 +0000
Subject: [issue46600] Python built with clang -O0 allocates 10x more stack
 memory than clang -O3 on a Python function call
In-Reply-To: <1643720760.9.0.302596428689.issue46600@roundup.psfhosted.org>
Message-ID: <1643723246.02.0.349059542596.issue46600@roundup.psfhosted.org>


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


New changeset 0515eafe55ce7699e3bbc3c1555f08073d43b790 by Victor Stinner in branch 'main':
bpo-46600: ./configure --with-pydebug uses -Og with clang (GH-31052)
https://github.com/python/cpython/commit/0515eafe55ce7699e3bbc3c1555f08073d43b790


----------

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

From report at bugs.python.org  Tue Feb  1 08:56:33 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 01 Feb 2022 13:56:33 +0000
Subject: [issue46584] Modernize `ctypes/test_python_api` by removing old
 version check
In-Reply-To: <1643554560.13.0.0620214587258.issue46584@roundup.psfhosted.org>
Message-ID: <1643723793.71.0.414350370975.issue46584@roundup.psfhosted.org>


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


New changeset 913e340a323c7e61ae6e4acbb1312b4342657bec by Nikita Sobolev in branch 'main':
bpo-46584: remove check for `py2.3` from `ctypes/test_python_api` (GH-31024)
https://github.com/python/cpython/commit/913e340a323c7e61ae6e4acbb1312b4342657bec


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

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

From report at bugs.python.org  Tue Feb  1 09:07:02 2022
From: report at bugs.python.org (PySimpleGUI)
Date: Tue, 01 Feb 2022 14:07:02 +0000
Subject: [issue46180] Button clicked failed when mouse hover tooltip and
 tooltip destroyed
In-Reply-To: <1640515148.68.0.766649384181.issue46180@roundup.psfhosted.org>
Message-ID: <1643724422.63.0.0336970641242.issue46180@roundup.psfhosted.org>


PySimpleGUI <PySimpleGUI at PySimpleGUI.com> added the comment:

This issue is impacting multiple PySimpleGUI users in particular.  One commented today:  
"I already spent a day trying to figure out what was happening to my UI when I found this open issue."
Until a fix is found, I'm going to add a specific check for 8.6.12 and disable the tooltip feature and issue a warning to users as to why.  Not sure what other options are available at the moment.

----------
nosy: +PySimpleGUI

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

From report at bugs.python.org  Tue Feb  1 09:08:50 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 01 Feb 2022 14:08:50 +0000
Subject: [issue46584] Modernize `ctypes/test_python_api` by removing old
 version check
In-Reply-To: <1643554560.13.0.0620214587258.issue46584@roundup.psfhosted.org>
Message-ID: <1643724530.52.0.528786634422.issue46584@roundup.psfhosted.org>


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


----------
pull_requests: +29236
pull_request: https://github.com/python/cpython/pull/31054

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

From report at bugs.python.org  Tue Feb  1 09:08:44 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 01 Feb 2022 14:08:44 +0000
Subject: [issue46584] Modernize `ctypes/test_python_api` by removing old
 version check
In-Reply-To: <1643554560.13.0.0620214587258.issue46584@roundup.psfhosted.org>
Message-ID: <1643724524.86.0.869506429582.issue46584@roundup.psfhosted.org>


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


----------
pull_requests: +29235
pull_request: https://github.com/python/cpython/pull/31053

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

From report at bugs.python.org  Tue Feb  1 09:19:59 2022
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Feb 2022 14:19:59 +0000
Subject: [issue45711] Simplify the interpreter's (type, val,
 tb) exception representation
In-Reply-To: <1636025387.26.0.346517237471.issue45711@roundup.psfhosted.org>
Message-ID: <1643725199.8.0.68793703891.issue45711@roundup.psfhosted.org>


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

Would it be possible to revert the change until Cython and numpy are ready for it?

> bpo-45711: Remove type and traceback from exc_info (GH-30122)

This change broke numpy which uses C code generated by Cython for coroutines in numpy/random/_mt19937.c (file generated from numpy/random/_mt19937.pyx).

Example of Cython code which no fails with a compiler error since exc_info->exc_type has been removed:

/* GetTopmostException */
#if CYTHON_USE_EXC_INFO_STACK
static _PyErr_StackItem *
__Pyx_PyErr_GetTopmostException(PyThreadState *tstate)
{
    _PyErr_StackItem *exc_info = tstate->exc_info;
    while ((exc_info->exc_type == NULL || exc_info->exc_type == Py_None) &&
           exc_info->previous_item != NULL)
    {
        exc_info = exc_info->previous_item;
    }
    return exc_info;
}
#endif

I propose this plan:

* (1) Revert this specific change
* (2) Wait until a change is merged in Cython 0.29.x
* (3) Wait until a new Cython 0.29.x version is released
* (4) Wait until numpy is released with regenerated code compatible with this change
* (5) Apply again the change

It should increase the number of packages when Python 3.11 will be released.

In Cython, the issue is tracked as: https://github.com/cython/cython/issues/4500

----------
nosy: +vstinner
resolution: fixed -> 
status: closed -> open

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

From report at bugs.python.org  Tue Feb  1 09:28:12 2022
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 01 Feb 2022 14:28:12 +0000
Subject: [issue45711] Simplify the interpreter's (type, val,
 tb) exception representation
In-Reply-To: <1636025387.26.0.346517237471.issue45711@roundup.psfhosted.org>
Message-ID: <1643725692.86.0.142363484514.issue45711@roundup.psfhosted.org>


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

I can probably just put back the two fields in _PyErr_StackItem and make sure they get updated when exc_value is set. 

Reverting the whole thing would include big changes in compile.c and ceval.c, so I'd rather avoid that if we can.

----------

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

From report at bugs.python.org  Tue Feb  1 09:41:00 2022
From: report at bugs.python.org (Matt B)
Date: Tue, 01 Feb 2022 14:41:00 +0000
Subject: [issue46581] _typevar_types and _paramspec_tvars are missing from
 _GenericAlias.copy_with
In-Reply-To: <1643548818.53.0.117293310302.issue46581@roundup.psfhosted.org>
Message-ID: <1643726460.29.0.711497959508.issue46581@roundup.psfhosted.org>


Matt B <eb3f73+python+org at yaymail.com> added the comment:

I am happy to attempt a patch, but I don't understand what's going on with _ConcatenateGenericAlias. Or rather, I don't fully understand the various copy_with semantics. This code is *very* hard to follow.

Patching _GenericAlias.copy_with seems relatively straightforward:

     def copy_with(self, params):
-        return self.__class__(self.__origin__, params, name=self._name, inst=self._inst)
+        return self.__class__(self.__origin__, params, name=self._name, inst=self._inst,
+                              _typevar_types=self._typevar_types,
+                              _paramspec_tvars=self._paramspec_tvars)

_ConcatenateGenericAlias.copy_with, on the other hand, appears to return a tuple rather than a type until it falls back to the parent implementation. What does one do with that?

Also, what about _AnnotatedAlias, _SpecialGenericAlias, _UnionGenericAlias, or _strip_annotations? Do any of those need to be modified?

I can't find any tests that deal with copy_with directly, so I'm assuming its use is stressed via higher level code paths, but it's not clear what use cases that method is supposed to serve. The good news is that its use is confined to typing.py. The bad news is that file gives little insight to those who aren't already experts in that territory.

In short, I will do my best, but I suspect I will need patience and guidance in arriving something acceptable.

----------

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

From report at bugs.python.org  Tue Feb  1 09:42:45 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 01 Feb 2022 14:42:45 +0000
Subject: [issue46584] Modernize `ctypes/test_python_api` by removing old
 version check
In-Reply-To: <1643554560.13.0.0620214587258.issue46584@roundup.psfhosted.org>
Message-ID: <1643726565.5.0.26132823679.issue46584@roundup.psfhosted.org>


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


New changeset 8765b01bcf6514602affcca66e7deeeb998f9cef by Miss Islington (bot) in branch '3.10':
[3.10] bpo-46584: remove check for `py2.3` from `ctypes/test_python_api` (GH-31024) (GH-31054)
https://github.com/python/cpython/commit/8765b01bcf6514602affcca66e7deeeb998f9cef


----------

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

From report at bugs.python.org  Tue Feb  1 09:42:53 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 01 Feb 2022 14:42:53 +0000
Subject: [issue46584] Modernize `ctypes/test_python_api` by removing old
 version check
In-Reply-To: <1643554560.13.0.0620214587258.issue46584@roundup.psfhosted.org>
Message-ID: <1643726573.27.0.347104922963.issue46584@roundup.psfhosted.org>


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


New changeset 7368ca1b889d7fa16423e69034bf4c5fe7b00268 by Miss Islington (bot) in branch '3.9':
[3.9] bpo-46584: remove check for `py2.3` from `ctypes/test_python_api` (GH-31024) (GH-31053)
https://github.com/python/cpython/commit/7368ca1b889d7fa16423e69034bf4c5fe7b00268


----------

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

From report at bugs.python.org  Tue Feb  1 09:43:29 2022
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 01 Feb 2022 14:43:29 +0000
Subject: [issue46584] Modernize `ctypes/test_python_api` by removing old
 version check
In-Reply-To: <1643554560.13.0.0620214587258.issue46584@roundup.psfhosted.org>
Message-ID: <1643726609.63.0.943230389505.issue46584@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Thanks for the patch!

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

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

From report at bugs.python.org  Tue Feb  1 09:52:41 2022
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 01 Feb 2022 14:52:41 +0000
Subject: [issue45711] Simplify the interpreter's (type, val,
 tb) exception representation
In-Reply-To: <1636025387.26.0.346517237471.issue45711@roundup.psfhosted.org>
Message-ID: <1643727161.74.0.370427136919.issue45711@roundup.psfhosted.org>


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

Does unsetting CYTHON_USE_EXC_INFO_STACK still work?



#if CYTHON_USE_EXC_INFO_STACK
// See  https://bugs.python.org/issue25612
#define __Pyx_ExcInfoStruct  _PyErr_StackItem
#else
// Minimal replacement struct for Py<3.7, without the Py3.7 exception state stack.
typedef struct {
    PyObject *exc_type;
    PyObject *exc_value;
    PyObject *exc_traceback;
} __Pyx_ExcInfoStruct;
#endif

----------

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

From report at bugs.python.org  Tue Feb  1 10:05:39 2022
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 01 Feb 2022 15:05:39 +0000
Subject: [issue46072] Unify handling of stats in the CPython VM
In-Reply-To: <1639498673.65.0.709719181358.issue46072@roundup.psfhosted.org>
Message-ID: <1643727939.14.0.0330994789863.issue46072@roundup.psfhosted.org>


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


New changeset 48be46ec1f3f8010570165daa1da4bf9961f3a83 by Mark Shannon in branch 'main':
bpo-46072: Add some object layout and allocation stats (GH-31051)
https://github.com/python/cpython/commit/48be46ec1f3f8010570165daa1da4bf9961f3a83


----------

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

From report at bugs.python.org  Tue Feb  1 10:07:35 2022
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Feb 2022 15:07:35 +0000
Subject: [issue45711] Simplify the interpreter's (type, val,
 tb) exception representation
In-Reply-To: <1636025387.26.0.346517237471.issue45711@roundup.psfhosted.org>
Message-ID: <1643728055.77.0.177599438184.issue45711@roundup.psfhosted.org>


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

> In Cython, the issue is tracked as: https://github.com/cython/cython/issues/4500

I don't understand the Cython status. The code was updated in the master branch:

* https://github.com/cython/cython/pull/4584
* https://github.com/cython/cython/commit/776957022d062ed24edea192b719720118ee3576

https://github.com/cython/cython/issues/4500 was closed even if the change was not backported to 0.29.x.

I understand that there is no released Cython 0.29.x version compatible with this change.

----------

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

From report at bugs.python.org  Tue Feb  1 10:12:45 2022
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Feb 2022 15:12:45 +0000
Subject: [issue45711] Simplify the interpreter's (type, val,
 tb) exception representation
In-Reply-To: <1636025387.26.0.346517237471.issue45711@roundup.psfhosted.org>
Message-ID: <1643728365.62.0.36475942554.issue45711@roundup.psfhosted.org>


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

I commented the Cython issue:
https://github.com/cython/cython/issues/4500#issuecomment-1026949365

I also opened a discussion on python-dev: "Please update Cython before introcuding C API incompatible changes in Python".
https://mail.python.org/archives/list/python-dev at python.org/thread/RS2C53LDZPXHRR2VCY2G2YSPDVA4LNQU/

----------

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

From report at bugs.python.org  Tue Feb  1 10:17:14 2022
From: report at bugs.python.org (Ken Jin)
Date: Tue, 01 Feb 2022 15:17:14 +0000
Subject: [issue46581] _typevar_types and _paramspec_tvars are missing from
 _GenericAlias.copy_with
In-Reply-To: <1643548818.53.0.117293310302.issue46581@roundup.psfhosted.org>
Message-ID: <1643728634.76.0.0672355948186.issue46581@roundup.psfhosted.org>


Ken Jin <kenjin4096 at gmail.com> added the comment:

> In short, I will do my best, but I suspect I will need patience and guidance in arriving something acceptable.

Yeah no worries. typing.py is really complex for many historical reasons. I still don't grasp all of it and probably never will.

> what about _AnnotatedAlias, _SpecialGenericAlias, _UnionGenericAlias, or _strip_annotations?

They shouldn't need modification. And there's an elegant reason why. Currently ParamSpec is only valid in Generic, Callable and Concatenate. We don't care about any other types. As long as ParamSpec appears in their __parameters__ and the copy_with of those 3 have the correct settings.

Well what about when they're nested? The other types blindly copy over whatever they see in __parameters__ of any nested types. So even if you don't pass those settings to their copy_with, it doesn't matter (well of course, until someone else uses this setting and expands its scope, then proceeds to trip over it :(. this seems like a potential trap affecting PEP 646's runtime.)

>>> X = Concatenate[int, ParamSpec('P')]
>>> Container[X]
typing.Container[typing.Concatenate[int, ~P]]
>>> Container[X].copy_with(X).__parameters__
(~P,)
^ Works even though this uses _SpecialGenericAlias, which doesn't properly pass in the settings!

> I can't find any tests that deal with copy_with directly, so I'm assuming its use is stressed via higher level code paths, but it's not clear what use cases that method is supposed to serve.

Yeah. If you search for "copy_with" in typing.py. You'll find that it's called in __getitem__. Now __getitem__ is used when we subscript an already subscripted type. What I mean is:

T = TypeVar('T')
X = List[T] (__class_getitem__ is called, returning a new genericalias object)
X[int] (__getitem__ is called, returning a new genericalias object)

We need copy_with because we want to create a full "copy" of all the args into the new GenericAlias object and not face weird problems with mutability. That specific use case is tested super often.

> _ConcatenateGenericAlias.copy_with, on the other hand, appears to return a tuple rather than a type until it falls back to the parent implementation. What does one do with that?

Frankly, I was quite lost too until I saw that it was part of bpo-44791, which deals with special special (undefined) cases in PEP 612 and Concatenate. Basically for a very weird Concatenate, the core dev there has chosen to return a tuple of types instead of another type. Let's just ignore those strange tuple paths, and only care about the path using the parent implementation.

----------

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

From report at bugs.python.org  Tue Feb  1 10:19:00 2022
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Feb 2022 15:19:00 +0000
Subject: [issue45711] Simplify the interpreter's (type, val,
 tb) exception representation
In-Reply-To: <1636025387.26.0.346517237471.issue45711@roundup.psfhosted.org>
Message-ID: <1643728740.39.0.797151220936.issue45711@roundup.psfhosted.org>


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

Irit Katriel:
> Reverting the whole thing would include big changes in compile.c and ceval.c, so I'd rather avoid that if we can.

It was a good idea to split changes of this issue into multiple commits :-) I'm only proposing to revert the one which introduces the C API incompatible changes: the commit 396b58345f81d4c8c5a52546d2288e666a1b9b8b "bpo-45711: Remove type and traceback from exc_info (GH-30122)".

Maybe Cython can be quickly updated, but the situation seems to be complicated :-( https://github.com/cython/cython/issues/4500

----------

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

From report at bugs.python.org  Tue Feb  1 10:21:01 2022
From: report at bugs.python.org (Sebastian Berg)
Date: Tue, 01 Feb 2022 15:21:01 +0000
Subject: [issue46451] Tracing causes module globals to be mutated when calling
 functions from C
In-Reply-To: <1642740862.08.0.497751420234.issue46451@roundup.psfhosted.org>
Message-ID: <1643728861.65.0.672321641239.issue46451@roundup.psfhosted.org>


Sebastian Berg <sebastian at sipsolutions.net> added the comment:

Thanks for having a look. I have confirmed this is related to Cython (no pandas/NumPy involved) ? repro at https://github.com/seberg/bpo46451.  What happens under the hood in Cython is probably:
    https://github.com/cython/cython/blob/master/Cython/Utility/ObjectHandling.c#L2569-L2611

Which generates `PyEval_EvalCodeEx`, and I could not repro with just a `PyObject_FastCallDict`, so I assume Cython is doing something wrong and will open an issue there, but if you have a quick tip as to what might wrong, that could be nice :).

Otherwise, will just close this, and may reopen if Cython hits a wall.

----------

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

From report at bugs.python.org  Tue Feb  1 10:21:06 2022
From: report at bugs.python.org (Sebastian Berg)
Date: Tue, 01 Feb 2022 15:21:06 +0000
Subject: [issue46451] Tracing causes module globals to be mutated when calling
 functions from C
In-Reply-To: <1642740862.08.0.497751420234.issue46451@roundup.psfhosted.org>
Message-ID: <1643728866.75.0.049214116722.issue46451@roundup.psfhosted.org>


Change by Sebastian Berg <sebastian at sipsolutions.net>:


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

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

From report at bugs.python.org  Tue Feb  1 10:21:47 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 01 Feb 2022 15:21:47 +0000
Subject: [issue46561] Descriptor resolution should own arguments passed to
 descriptors
In-Reply-To: <1643353574.8.0.417486846684.issue46561@roundup.psfhosted.org>
Message-ID: <1643728907.47.0.507603005038.issue46561@roundup.psfhosted.org>


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

If this can only be triggered from C code, it less of a concern.

The PR increases cost on a critical path, so we ought to be wary of applying it unless a known problem is being solved.

Note, this code path has survived two decades of deployment.  Also, the PR doesn't have a test to demonstrate that it fixes anything.  Those facts give some evidence that the PR has every user paying to solve a problem that almost no one actually has.

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

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

From report at bugs.python.org  Tue Feb  1 10:25:55 2022
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 01 Feb 2022 15:25:55 +0000
Subject: [issue46600] Python built with clang -O0 allocates 10x more stack
 memory than clang -O3 on a Python function call
In-Reply-To: <1643720760.9.0.302596428689.issue46600@roundup.psfhosted.org>
Message-ID: <1643729155.69.0.308523832825.issue46600@roundup.psfhosted.org>


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

PR 31052 seems to have broken a bunch of buildbots. If no fix is provided in 24 hours, we will need to revert :(

----------
nosy: +pablogsal

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

From report at bugs.python.org  Tue Feb  1 10:29:16 2022
From: report at bugs.python.org (Ned Deily)
Date: Tue, 01 Feb 2022 15:29:16 +0000
Subject: [issue46180] Button clicked failed when mouse hover tooltip and
 tooltip destroyed
In-Reply-To: <1640515148.68.0.766649384181.issue46180@roundup.psfhosted.org>
Message-ID: <1643729356.29.0.475894507777.issue46180@roundup.psfhosted.org>


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

Can you say which platforms are affected by this? The OP's example appears to be from a Windows system. Are Unix (X11) and/or macOS versions of Tk affected, too?

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

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

From report at bugs.python.org  Tue Feb  1 10:42:17 2022
From: report at bugs.python.org (Sebastian Berg)
Date: Tue, 01 Feb 2022 15:42:17 +0000
Subject: [issue46451] Tracing causes module globals to be mutated when calling
 functions from C
In-Reply-To: <1642740862.08.0.497751420234.issue46451@roundup.psfhosted.org>
Message-ID: <1643730137.64.0.222809714535.issue46451@roundup.psfhosted.org>


Sebastian Berg <sebastian at sipsolutions.net> added the comment:

Not reopening for now, but I will note again that (AFAIK) Cython uses `PyEval_EvalCodeEx`, and the docs say that it is not used internally to CPython anymore.

So it seems pretty plausible that the bug is in `PyEval_EvalCodeEx` and not the generated Cython code?

----------

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

From report at bugs.python.org  Tue Feb  1 10:47:03 2022
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 01 Feb 2022 15:47:03 +0000
Subject: [issue45711] Simplify the interpreter's (type, val,
 tb) exception representation
In-Reply-To: <1636025387.26.0.346517237471.issue45711@roundup.psfhosted.org>
Message-ID: <1643730423.65.0.705262379181.issue45711@roundup.psfhosted.org>


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

That commit has significant changes in ceval.c and compile.c. They don't need to be reverted to unbreak cython.  I'm working on a PR for a simpler change.

Have you tried with CYTHON_USE_EXC_INFO_STACK undefined?

----------

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

From report at bugs.python.org  Tue Feb  1 10:48:04 2022
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 01 Feb 2022 15:48:04 +0000
Subject: [issue46599] Objects/object.c:767:24: runtime error: member access
 within null pointer of type 'PyObject' (aka 'struct _object')
In-Reply-To: <1643719121.07.0.180413749782.issue46599@roundup.psfhosted.org>
Message-ID: <1643730484.95.0.222201775391.issue46599@roundup.psfhosted.org>


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

The crash occurs inside marshal module (Python/marshal.c). The marshal module is unsafe and cannot safely parse malicious code. Bad marshal code is expected to crash the interpreter.

----------
nosy: +christian.heimes
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Feb  1 10:55:33 2022
From: report at bugs.python.org (Matt B)
Date: Tue, 01 Feb 2022 15:55:33 +0000
Subject: [issue46581] _typevar_types and _paramspec_tvars are missing from
 _GenericAlias.copy_with
In-Reply-To: <1643548818.53.0.117293310302.issue46581@roundup.psfhosted.org>
Message-ID: <1643730933.4.0.396032359702.issue46581@roundup.psfhosted.org>


Matt B <eb3f73+python+org at yaymail.com> added the comment:

Thanks, @kj! Fantastic education and insight! I'm sad that I needed you as an interpreter but very grateful you were around to provide the interpretation. Working on a patch now?.

----------

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

From report at bugs.python.org  Tue Feb  1 10:58:47 2022
From: report at bugs.python.org (Ned Deily)
Date: Tue, 01 Feb 2022 15:58:47 +0000
Subject: [issue45925] Upgrade macOS and Windows installers to use SQLite 3.37.2
In-Reply-To: <1638187039.58.0.251846461245.issue45925@roundup.psfhosted.org>
Message-ID: <1643731127.66.0.135366941819.issue45925@roundup.psfhosted.org>


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


New changeset 0e4bef7a7f6f25a6f39755778c73e7026901611f by Kumar Aditya in branch 'main':
bpo-45925: Update macOS installer to SQLite 3.37.2 (GH-30921)
https://github.com/python/cpython/commit/0e4bef7a7f6f25a6f39755778c73e7026901611f


----------

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

From report at bugs.python.org  Tue Feb  1 11:05:10 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 01 Feb 2022 16:05:10 +0000
Subject: [issue46487] `_SSLProtocolTransport` doesn't have the
 `get_write_buffer_limits` implementation.
In-Reply-To: <1642956579.88.0.874451356364.issue46487@roundup.psfhosted.org>
Message-ID: <1643731510.72.0.776369766432.issue46487@roundup.psfhosted.org>


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


New changeset 64568acbd88a88d54ac9b8215447f88280448dd5 by Emiya in branch 'main':
bpo-46487: Add `get_write_buffer_limits` to Write and _SSLProtocol transports (GH-30958)
https://github.com/python/cpython/commit/64568acbd88a88d54ac9b8215447f88280448dd5


----------

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

From report at bugs.python.org  Tue Feb  1 11:05:17 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 01 Feb 2022 16:05:17 +0000
Subject: [issue46487] `_SSLProtocolTransport` doesn't have the
 `get_write_buffer_limits` implementation.
In-Reply-To: <1642956579.88.0.874451356364.issue46487@roundup.psfhosted.org>
Message-ID: <1643731517.29.0.112521795742.issue46487@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: +29237
pull_request: https://github.com/python/cpython/pull/31055

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

From report at bugs.python.org  Tue Feb  1 11:05:27 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 01 Feb 2022 16:05:27 +0000
Subject: [issue46487] `_SSLProtocolTransport` doesn't have the
 `get_write_buffer_limits` implementation.
In-Reply-To: <1642956579.88.0.874451356364.issue46487@roundup.psfhosted.org>
Message-ID: <1643731527.26.0.0139834984557.issue46487@roundup.psfhosted.org>


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


----------
pull_requests: +29238
pull_request: https://github.com/python/cpython/pull/31056

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

From report at bugs.python.org  Tue Feb  1 11:06:29 2022
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Feb 2022 16:06:29 +0000
Subject: [issue46600] Python built with clang -O0 allocates 10x more stack
 memory than clang -O3 on a Python function call
In-Reply-To: <1643720760.9.0.302596428689.issue46600@roundup.psfhosted.org>
Message-ID: <1643731589.11.0.429133847405.issue46600@roundup.psfhosted.org>


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

> PR 31052 seems to have broken a bunch of buildbots. If no fix is provided in 24 hours, we will need to revert :(

test_gdb fails if Python is built with clang -Og. I don't think that it's a regression. It's just that previously, buildbots using clang only build Python with -O0 or -O3.

I'm investigating the test_gdb issue: it's easy to reproduce on Linux (clang 13.0.0). I may skip test_gdb is Python is built with clang -Og.

----------

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

From report at bugs.python.org  Tue Feb  1 11:09:46 2022
From: report at bugs.python.org (Ned Deily)
Date: Tue, 01 Feb 2022 16:09:46 +0000
Subject: [issue45925] Upgrade macOS and Windows installers to use SQLite 3.37.2
In-Reply-To: <1638187039.58.0.251846461245.issue45925@roundup.psfhosted.org>
Message-ID: <1643731786.7.0.350871131501.issue45925@roundup.psfhosted.org>


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


----------
pull_requests: +29239
pull_request: https://github.com/python/cpython/pull/31057

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

From report at bugs.python.org  Tue Feb  1 11:24:05 2022
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Feb 2022 16:24:05 +0000
Subject: [issue46600] Python built with clang -O0 allocates 10x more stack
 memory than clang -O3 on a Python function call
In-Reply-To: <1643720760.9.0.302596428689.issue46600@roundup.psfhosted.org>
Message-ID: <1643732645.07.0.670703678453.issue46600@roundup.psfhosted.org>


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


----------
pull_requests: +29240
pull_request: https://github.com/python/cpython/pull/31058

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

From report at bugs.python.org  Tue Feb  1 11:29:10 2022
From: report at bugs.python.org (Ned Deily)
Date: Tue, 01 Feb 2022 16:29:10 +0000
Subject: [issue45925] Upgrade macOS and Windows installers to use SQLite 3.37.2
In-Reply-To: <1638187039.58.0.251846461245.issue45925@roundup.psfhosted.org>
Message-ID: <1643732950.73.0.223905181557.issue45925@roundup.psfhosted.org>


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


New changeset 519eb6ad74f946a9aa7676e2d6579a3a765a8b50 by Ned Deily in branch '3.10':
bpo-45925: Update macOS installer to SQLite 3.37.2 (GH-30921) (GH-31057)
https://github.com/python/cpython/commit/519eb6ad74f946a9aa7676e2d6579a3a765a8b50


----------

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

From report at bugs.python.org  Tue Feb  1 11:29:13 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 01 Feb 2022 16:29:13 +0000
Subject: [issue45925] Upgrade macOS and Windows installers to use SQLite 3.37.2
In-Reply-To: <1638187039.58.0.251846461245.issue45925@roundup.psfhosted.org>
Message-ID: <1643732953.87.0.113113676925.issue45925@roundup.psfhosted.org>


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


----------
pull_requests: +29241
pull_request: https://github.com/python/cpython/pull/31059

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

From report at bugs.python.org  Tue Feb  1 11:32:18 2022
From: report at bugs.python.org (Sebastian Berg)
Date: Tue, 01 Feb 2022 16:32:18 +0000
Subject: [issue46451] Tracing causes module globals to be mutated when calling
 functions from C
In-Reply-To: <1642740862.08.0.497751420234.issue46451@roundup.psfhosted.org>
Message-ID: <1643733138.37.0.513163468658.issue46451@roundup.psfhosted.org>


Sebastian Berg <sebastian at sipsolutions.net> added the comment:

While I have a repro for Python, I think the pre release of cython already fixes it (and I just did not regenerated the C sources when trying, I guess.  A `git clean` to the rescue...).

----------

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

From report at bugs.python.org  Tue Feb  1 11:34:24 2022
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 01 Feb 2022 16:34:24 +0000
Subject: [issue46072] Unify handling of stats in the CPython VM
In-Reply-To: <1639498673.65.0.709719181358.issue46072@roundup.psfhosted.org>
Message-ID: <1643733264.08.0.462599321712.issue46072@roundup.psfhosted.org>


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


----------
pull_requests: +29242
pull_request: https://github.com/python/cpython/pull/31060

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

From report at bugs.python.org  Tue Feb  1 11:40:13 2022
From: report at bugs.python.org (Ned Deily)
Date: Tue, 01 Feb 2022 16:40:13 +0000
Subject: [issue46598] ElementTree: wrong XML prolog for the utf-8-sig encoding
In-Reply-To: <1643713234.05.0.62090035158.issue46598@roundup.psfhosted.org>
Message-ID: <1643733613.79.0.00548561286913.issue46598@roundup.psfhosted.org>


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


----------
nosy: +eli.bendersky, scoder
versions: +Python 3.11

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

From report at bugs.python.org  Tue Feb  1 11:46:59 2022
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 01 Feb 2022 16:46:59 +0000
Subject: [issue45711] Simplify the interpreter's (type, val,
 tb) exception representation
In-Reply-To: <1636025387.26.0.346517237471.issue45711@roundup.psfhosted.org>
Message-ID: <1643734019.84.0.233604157428.issue45711@roundup.psfhosted.org>


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

If this is still the position of cython maintainers:

https://github.com/cython/cython/issues/4581#issuecomment-1016503683

then I will need to revert the change until 3.12.

----------

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

From report at bugs.python.org  Tue Feb  1 11:50:45 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 01 Feb 2022 16:50:45 +0000
Subject: [issue45711] Simplify the interpreter's (type, val,
 tb) exception representation
In-Reply-To: <1636025387.26.0.346517237471.issue45711@roundup.psfhosted.org>
Message-ID: <1643734245.35.0.795988179466.issue45711@roundup.psfhosted.org>


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

Time to insist on directly communicating with the Cython team (esp. @scoder) and broker some kind of compromise.

----------

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

From report at bugs.python.org  Tue Feb  1 12:02:41 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 01 Feb 2022 17:02:41 +0000
Subject: [issue45953] Statically allocate interpreter states as much as
 possible.
In-Reply-To: <1638384639.14.0.97360024283.issue45953@roundup.psfhosted.org>
Message-ID: <1643734961.41.0.890305601271.issue45953@roundup.psfhosted.org>


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


New changeset f78be59c83c151d94902daef56218530c52e29e7 by Eric Snow in branch 'main':
bpo-45953: Preserve backward compatibility on some PyThreadState field names. (GH-31038)
https://github.com/python/cpython/commit/f78be59c83c151d94902daef56218530c52e29e7


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

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

From report at bugs.python.org  Tue Feb  1 12:07:49 2022
From: report at bugs.python.org (Matt Bogosian)
Date: Tue, 01 Feb 2022 17:07:49 +0000
Subject: [issue46581] _typevar_types and _paramspec_tvars are missing from
 _GenericAlias.copy_with
In-Reply-To: <1643548818.53.0.117293310302.issue46581@roundup.psfhosted.org>
Message-ID: <1643735269.48.0.38656402314.issue46581@roundup.psfhosted.org>


Change by Matt Bogosian <eb3f73+python+org at yaymail.com>:


----------
keywords: +patch
nosy: +mbogosian
nosy_count: 4.0 -> 5.0
pull_requests: +29243
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31061

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

From report at bugs.python.org  Tue Feb  1 12:08:38 2022
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Feb 2022 17:08:38 +0000
Subject: [issue45711] Simplify the interpreter's (type, val,
 tb) exception representation
In-Reply-To: <1636025387.26.0.346517237471.issue45711@roundup.psfhosted.org>
Message-ID: <1643735318.52.0.758250758908.issue45711@roundup.psfhosted.org>


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

> __Pyx_PyErr_GetTopmostException(PyThreadState *tstate)

Python provides a *private* _PyErr_GetTopmostException(tstate) function, but Cython reimplements its own function. I'm not sure why.

GH-30531 proposes adding PyErr_GetActiveException() function which has no parameter, but Cython __Pyx_PyErr_GetTopmostException() has a tstate parameter.

Simplified example numpy/random/_mt19937.c code:

static CYTHON_INLINE void
__Pyx__ExceptionSave(PyThreadState *tstate, PyObject **type,
                     PyObject **value, PyObject **tb)
{
    _PyErr_StackItem *exc_info = __Pyx_PyErr_GetTopmostException(tstate);
    *type = exc_info->exc_type;
    *value = exc_info->exc_value;
    *tb = exc_info->exc_traceback;
    Py_XINCREF(*type);
    Py_XINCREF(*value);
    Py_XINCREF(*tb);
}

static CYTHON_INLINE void
__Pyx__ExceptionReset(PyThreadState *tstate, PyObject *type,
                      PyObject *value, PyObject *tb)
{
    PyObject *tmp_type, *tmp_value, *tmp_tb;
    _PyErr_StackItem *exc_info = tstate->exc_info;
    tmp_type = exc_info->exc_type;
    tmp_value = exc_info->exc_value;
    tmp_tb = exc_info->exc_traceback;
    exc_info->exc_type = type;
    exc_info->exc_value = value;
    exc_info->exc_traceback = tb;
    Py_XDECREF(tmp_type);
    Py_XDECREF(tmp_value);
    Py_XDECREF(tmp_tb);
}

Cython saves/restores the current exception of tstate. Maybe we need to provide a high-level API for that as well?

----------

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

From report at bugs.python.org  Tue Feb  1 12:10:35 2022
From: report at bugs.python.org (Ned Deily)
Date: Tue, 01 Feb 2022 17:10:35 +0000
Subject: [issue46601] macOS installer "Install Certificates.command" fails if
 pip is not installed
In-Reply-To: <1643722081.07.0.215509583519.issue46601@roundup.psfhosted.org>
Message-ID: <1643735435.53.0.912499445379.issue46601@roundup.psfhosted.org>


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

Thanks for opening the issue. From the pythondotorg issue, the output from the failed command:

    Last login: Sat May 8 17:08:01 on ttys005
    /Applications/Python\ 3.9/Install\ Certificates.command ; exit;
    perl: warning: Setting locale failed.
    perl: warning: Please check that your locale settings:
    LC_ALL = (unset),
    LC_CTYPE = "en_AU.UTF-8.UTF-8",
    LANG = "en_AU.UTF-8"
    are supported and installed on your system.
    perl: warning: Falling back to the standard locale ("C").
    [cnd at mac ~]$ /Applications/Python\ 3.9/Install\ Certificates.command ; exit;
    -- pip install --upgrade certifi
    /Library/Frameworks/Python.framework/Versions/3.9/bin/python3.9: No module named pip
    Traceback (most recent call last):
    File "", line 44, in 
    File "", line 24, in main
    File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/subprocess.py", line 373, in check_call
    raise CalledProcessError(retcode, cmd)
    subprocess.CalledProcessError: Command '['/Library/Frameworks/Python.framework/Versions/3.9/bin/python3.9', '-E', '-s', '-m', 'pip', 'install', '--upgrade', 'certifi']' returned non-zero exit status 1.
    logout
    
    [Process completed]

So the failure is due to pip not being installed. Install Certificates assumes pip will be available but that may not necessarily be the case, for instance, if a custom install of Python was selected and the "Install or upgrade pip" package is deselected. Install Certificates should protect itself, if nothing else, by providing a useful message.

(For the record, the "perl warnings" at the start of the terminal session are presumably coming from one of the shell startup scripts that are run automatically at the beginning of a terminal session. Install Certificates does not use perl.)

----------
assignee:  -> ned.deily
stage:  -> needs patch
title: Instructions do not work -> macOS installer "Install Certificates.command" fails if pip is not installed
versions: +Python 3.10, Python 3.9

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

From report at bugs.python.org  Tue Feb  1 12:12:36 2022
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Feb 2022 17:12:36 +0000
Subject: [issue46600] Python built with clang -O0 allocates 10x more stack
 memory than clang -O3 on a Python function call
In-Reply-To: <1643720760.9.0.302596428689.issue46600@roundup.psfhosted.org>
Message-ID: <1643735556.83.0.670508154667.issue46600@roundup.psfhosted.org>


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


New changeset bebaa95fd0f44babf8b6bcffd8f2908c73ca259e by Victor Stinner in branch 'main':
bpo-46600: Fix test_gdb.test_pycfunction() for clang -Og (GH-31058)
https://github.com/python/cpython/commit/bebaa95fd0f44babf8b6bcffd8f2908c73ca259e


----------

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

From report at bugs.python.org  Tue Feb  1 12:13:06 2022
From: report at bugs.python.org (Ned Deily)
Date: Tue, 01 Feb 2022 17:13:06 +0000
Subject: [issue45925] Upgrade macOS and Windows installers to use SQLite 3.37.2
In-Reply-To: <1638187039.58.0.251846461245.issue45925@roundup.psfhosted.org>
Message-ID: <1643735586.94.0.215886538629.issue45925@roundup.psfhosted.org>


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


New changeset a22dd00f2da4f6ff96f58fd8d551f16bdb870c8d by Miss Islington (bot) in branch '3.9':
bpo-45925: Update macOS installer to SQLite 3.37.2 (GH-30921) (GH-31057) (GH-31059)
https://github.com/python/cpython/commit/a22dd00f2da4f6ff96f58fd8d551f16bdb870c8d


----------

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

From report at bugs.python.org  Tue Feb  1 12:13:42 2022
From: report at bugs.python.org (Ned Deily)
Date: Tue, 01 Feb 2022 17:13:42 +0000
Subject: [issue45925] Upgrade macOS and Windows installers to use SQLite 3.37.2
In-Reply-To: <1638187039.58.0.251846461245.issue45925@roundup.psfhosted.org>
Message-ID: <1643735622.43.0.180958881419.issue45925@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Tue Feb  1 12:21:22 2022
From: report at bugs.python.org (Chris Drake)
Date: Tue, 01 Feb 2022 17:21:22 +0000
Subject: [issue46601] macOS installer "Install Certificates.command" fails if
 pip is not installed
In-Reply-To: <1643722081.07.0.215509583519.issue46601@roundup.psfhosted.org>
Message-ID: <1643736082.7.0.894075711648.issue46601@roundup.psfhosted.org>


Chris Drake <cryptophoto at gmail.com> added the comment:

So it looks like a dependency error in the installer then?

It obviously makes no sense for pip to required before the python installer can work - chicken-and-egg issue - the installer should install what it needs of course, which I guess includes pip if that's really needed at this stage...

----------

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

From report at bugs.python.org  Tue Feb  1 13:11:58 2022
From: report at bugs.python.org (xoph)
Date: Tue, 01 Feb 2022 18:11:58 +0000
Subject: [issue46364] asyncio subprocess cannot read from /dev/stdin
In-Reply-To: <1642062291.75.0.573432882614.issue46364@roundup.psfhosted.org>
Message-ID: <1643739118.69.0.681399688859.issue46364@roundup.psfhosted.org>


xoph <xoph at posteo.de> added the comment:

Created a PR: https://github.com/python/cpython/pull/30596

It's ready for review. Happy about any feedback!

----------

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

From report at bugs.python.org  Tue Feb  1 13:48:33 2022
From: report at bugs.python.org (Nathan Howard)
Date: Tue, 01 Feb 2022 18:48:33 +0000
Subject: [issue46602] Subtle trouble with heredoc append in configure.
Message-ID: <1643741313.11.0.141658321036.issue46602@roundup.psfhosted.org>


New submission from Nathan Howard <adanhawthorn at gmail.com>:

TODO: (see PR)

----------
components: Installation
messages: 412298
nosy: adanhawth
priority: normal
severity: normal
status: open
title: Subtle trouble with heredoc append in configure.
type: compile error
versions: Python 3.10

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

From report at bugs.python.org  Tue Feb  1 14:29:57 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 01 Feb 2022 19:29:57 +0000
Subject: [issue46487] `_SSLProtocolTransport` doesn't have the
 `get_write_buffer_limits` implementation.
In-Reply-To: <1642956579.88.0.874451356364.issue46487@roundup.psfhosted.org>
Message-ID: <1643743797.63.0.885120057759.issue46487@roundup.psfhosted.org>


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


New changeset e4a6e549027b33bbe87f49fcfccc880243e49834 by Miss Islington (bot) in branch '3.9':
bpo-46487: Add `get_write_buffer_limits` to Write and _SSLProtocol transports (GH-30958)
https://github.com/python/cpython/commit/e4a6e549027b33bbe87f49fcfccc880243e49834


----------

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

From report at bugs.python.org  Tue Feb  1 14:30:08 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 01 Feb 2022 19:30:08 +0000
Subject: [issue46487] `_SSLProtocolTransport` doesn't have the
 `get_write_buffer_limits` implementation.
In-Reply-To: <1642956579.88.0.874451356364.issue46487@roundup.psfhosted.org>
Message-ID: <1643743808.09.0.760224813388.issue46487@roundup.psfhosted.org>


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


New changeset e5e1441d41907f92cc3bb5de675a2c519068173d by Miss Islington (bot) in branch '3.10':
bpo-46487: Add `get_write_buffer_limits` to Write and _SSLProtocol transports (GH-30958)
https://github.com/python/cpython/commit/e5e1441d41907f92cc3bb5de675a2c519068173d


----------

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

From report at bugs.python.org  Tue Feb  1 14:30:35 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 01 Feb 2022 19:30:35 +0000
Subject: [issue46487] `_SSLProtocolTransport` doesn't have the
 `get_write_buffer_limits` implementation.
In-Reply-To: <1642956579.88.0.874451356364.issue46487@roundup.psfhosted.org>
Message-ID: <1643743835.75.0.306359077493.issue46487@roundup.psfhosted.org>


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

Done, thanks!

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

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

From report at bugs.python.org  Tue Feb  1 14:32:17 2022
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Tue, 01 Feb 2022 19:32:17 +0000
Subject: [issue45413] Add install scheme for virtual environments
In-Reply-To: <1633715402.49.0.434363843275.issue45413@roundup.psfhosted.org>
Message-ID: <1643743937.62.0.617711191639.issue45413@roundup.psfhosted.org>


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

The PR is now ready for review.

----------

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

From report at bugs.python.org  Tue Feb  1 14:32:23 2022
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 01 Feb 2022 19:32:23 +0000
Subject: [issue45711] Simplify the interpreter's (type, val,
 tb) exception representation
In-Reply-To: <1636025387.26.0.346517237471.issue45711@roundup.psfhosted.org>
Message-ID: <1643743943.69.0.0586506986161.issue45711@roundup.psfhosted.org>


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

This is a backport of @scoder's patch to 0.29.x. (I don't know if this is helpful).

https://github.com/cython/cython/compare/master...iritkatriel:exc_info?expand=1

----------

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

From report at bugs.python.org  Tue Feb  1 14:52:16 2022
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 01 Feb 2022 19:52:16 +0000
Subject: [issue45711] Simplify the interpreter's (type, val,
 tb) exception representation
In-Reply-To: <1636025387.26.0.346517237471.issue45711@roundup.psfhosted.org>
Message-ID: <1643745136.45.0.523433239347.issue45711@roundup.psfhosted.org>


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

> GH-30531 proposes adding PyErr_GetActiveException() function which has no parameter, but Cython __Pyx_PyErr_GetTopmostException() has a tstate parameter.


I've now updated it to follow the pattern of other functions, where the is a private function that takes tstate and the public function calls it.

So it adds in Include/pyerrors.h 

PyAPI_FUNC(PyObject*) PyErr_GetActiveException(void);
PyAPI_FUNC(void) PyErr_SetActiveException(PyObject *);

and in Include/cpython/pyerrors.h

PyAPI_FUNC(PyObject*) _PyErr_GetActiveException(PyThreadState *);
PyAPI_FUNC(void) _PyErr_SetActiveException(PyThreadState *, PyObject *);

----------

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

From report at bugs.python.org  Tue Feb  1 14:53:06 2022
From: report at bugs.python.org (Nathan Howard)
Date: Tue, 01 Feb 2022 19:53:06 +0000
Subject: [issue46602] Subtle trouble with heredoc append in configure.
In-Reply-To: <1643741313.11.0.141658321036.issue46602@roundup.psfhosted.org>
Message-ID: <1643745186.47.0.137895459086.issue46602@roundup.psfhosted.org>


Change by Nathan Howard <adanhawthorn at gmail.com>:


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

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

From report at bugs.python.org  Tue Feb  1 14:58:27 2022
From: report at bugs.python.org (Nathan Howard)
Date: Tue, 01 Feb 2022 19:58:27 +0000
Subject: [issue46602] Subtle trouble with heredoc append in configure.
In-Reply-To: <1643741313.11.0.141658321036.issue46602@roundup.psfhosted.org>
Message-ID: <1643745507.78.0.524117951319.issue46602@roundup.psfhosted.org>


Change by Nathan Howard <adanhawthorn at gmail.com>:


----------
components: +Build -Installation
versions:  -Python 3.10

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

From report at bugs.python.org  Tue Feb  1 15:04:44 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 01 Feb 2022 20:04:44 +0000
Subject: [issue44359] test_ftplib.test_makeport() fails as "env changes" if a
 socket operation times out in a thread: TimeoutError is not catched
In-Reply-To: <1623225511.63.0.739788412824.issue44359@roundup.psfhosted.org>
Message-ID: <1643745884.69.0.523457734425.issue44359@roundup.psfhosted.org>


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

Maybe it's time to actually try to fix this test rather than just complaining about it? Surely *somebody* here has an idea? Else maybe we need to just disable it.

----------
nosy: +gvanrossum

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

From report at bugs.python.org  Tue Feb  1 15:55:18 2022
From: report at bugs.python.org (embassy_vfx)
Date: Tue, 01 Feb 2022 20:55:18 +0000
Subject: [issue46540] dylibs not loading properly from NFS mounts
In-Reply-To: <1643593725.81.0.337966744961.issue46540@roundup.psfhosted.org>
Message-ID: <CAPmKE5brpHjzZARjGfeK2hFnNJY9+VY_cmN5bFWR9GV_98ysNg@mail.gmail.com>


embassy_vfx <emb_tech at theembassyvfx.com> added the comment:

Hi Ned,

Thanks for the reply. I figured that this may be the case but wanted to
report it anyway.

I currently do not have access to a more up-to-date Mac OS but once I do I
will test and report anything unusual back. I also have not tested other
file systems but will most likely do that as well. Thanks again for your
time here.

Kenny

On Sun, Jan 30, 2022 at 5:48 PM Ned Deily <report at bugs.python.org> wrote:

>
> Ned Deily <nad at python.org> added the comment:
>
> Thanks for the report but there are a lot of variables here that make this
> very difficult to act on. First, there have been many changes in macOS
> 10.15 regarding file permissions and file system layouts (with APFS et al)
> and further changes in the more recent versions of macOS, 11 Big Sur and
> now 12 Monterey. Further, Python 3.7 is now in the security-fix-only phase
> of its life cycle which means we no longer produce binary installers for
> macOS or Windows for 3.7. 3.7.9 was released prior to the official release
> of macOS 11 and so, as noted on the changelog for 3.7.9, macOS 11+ is not
> fully supported by 3.7.x. We have also learned more about these operating
> systems since then and there are changes in Python and in how we
> manufacture python.org macOS installers that are reflected in current
> releases of Python 3.9.x and 3.10.x. Beyond that, AFAIK, we do not do any
> testing of macOS NFS clients or servers and have no setup for that at hand.
> And throwing in a third-party extension module (shiboken2.abi3.so) plus
> use of @rpath on top of all that adds even more variability.
>
> My suggestion is to try to reproduce this with a current, fully-supported
> python.org macOS installer download (i.e. the 3.10.2 universal2
> installer) and preferably on a current version of macOS, currently 12.2 or
> possibly 11.6.3, and also check "System Preferences" -> "Security &
> Privacy" -> "Privacy settings" like "Full Disk Access" and "Files and
> Folders"; if problems persist, try doing some dynamic loader debugging
> using the DYLD_* environment variables documented in the macOS dyld man
> page (man dyld). Otherwise, as your issue stands now, it seems unlikely
> that anyone here would be willing to invest the significant time to try to
> reproduce and debug what seems to be an unusual macOS configuration with
> out-of-date OS and Python versions.
>
> Perhaps a simpler option is to just avoid use of NFS file systems on macOS
> for this purpose.
>
> Sorry I don't have a more positive answer for you.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue46540>
> _______________________________________
>

----------

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

From report at bugs.python.org  Tue Feb  1 16:17:10 2022
From: report at bugs.python.org (Ned Deily)
Date: Tue, 01 Feb 2022 21:17:10 +0000
Subject: [issue46540] dylibs not loading properly from NFS mounts
In-Reply-To: <1643231140.7.0.949544098465.issue46540@roundup.psfhosted.org>
Message-ID: <1643750230.83.0.460530154663.issue46540@roundup.psfhosted.org>


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

> I currently do not have access to a more up-to-date Mac OS but once I do I
will test and report anything unusual back.

Good luck! Since there's a good chance that this issue will languish in our open backlog, I am going to mark it as closed for now. But please re-open this issue if you find anything that appears to be an issue with Python rather than just macOS. Two other suggestions for debugging:
1. You've probably already done this but double-check file and directory access permissions on the NFS-mounted file system up to root. We have seen other issues with relative paths on 10.15+ with the introduction of the read-only system volume and related file system layout complications.
2. You might try using install_name_tool to alter copies of those third-party .so(s) and dylib(s) that use @rpath and instead use an absolute path to their installed location(s). That would eliminate one variable.

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Feb  1 16:17:41 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Tue, 01 Feb 2022 21:17:41 +0000
Subject: [issue46603] `typing._strip_annotations` is not fully covered
Message-ID: <1643750261.29.0.798402203083.issue46603@roundup.psfhosted.org>


New submission from Nikita Sobolev <mail at sobolevn.me>:

Right now `coverage` says that this line is not covered at all: https://github.com/python/cpython/blob/bebaa95fd0f44babf8b6bcffd8f2908c73ca259e/Lib/typing.py#L1882

Considering how hard all these `types.UnionType` / `typing.Union` stuff is and that the logic with `reduce` and `operator.or_` is also quite complex, I think it is important to cover it.

It actually took me some time to reach this line, but here's the test I came up with:

```
    def test_get_type_hints_annotated_in_union(self):
        def with_union(x: int | list[Annotated[str, 'meta']]): ...

        self.assertEqual(get_type_hints(with_union), {'x': int | list[str]})
        self.assertEqual(
            get_type_hints(with_union, include_extras=True),
            {'x': int | list[Annotated[str, 'meta']]},
        )
```

Note that direct `|` with `Annotated` does not work, because it triggers `_AnnotatedType.__or__`, which returns `typing.Union` and not `types.UnionType`.

I will send a PR with it in a minute :)

Any feedback is welcome!

----------
components: Library (Lib)
messages: 412308
nosy: AlexWaygood, gvanrossum, kj, sobolevn
priority: normal
severity: normal
status: open
title: `typing._strip_annotations` is not fully covered
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Tue Feb  1 16:18:13 2022
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 01 Feb 2022 21:18:13 +0000
Subject: [issue46573] Python modules such as pyglet or pygame crash Python
 when tkinter message boxes are opened on MacOS.
In-Reply-To: <1643482093.87.0.31269168021.issue46573@roundup.psfhosted.org>
Message-ID: <1643750293.82.0.754588639647.issue46573@roundup.psfhosted.org>


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

Error output when running the script:

2022-02-01 22:15:32.213 Python[5468:5726153] ApplePersistenceIgnoreState: Existing state will not be touched. New state will be written to /var/folders/d3/rc5nx4v12y96knh2px3bpqsc0000gn/T/org.python.python.savedState
2022-02-01 22:15:32.362 Python[5468:5726153] -[NSApplication macOSVersion]: unrecognized selector sent to instance 0x105624bc0
2022-02-01 22:15:32.367 Python[5468:5726153] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[NSApplication macOSVersion]: unrecognized selector sent to instance 0x105624bc0'
*** First throw call stack:
(
	0   CoreFoundation                      0x000000018b4c01cc __exceptionPreprocess + 240
	1   libobjc.A.dylib                     0x000000018b2117b8 objc_exception_throw + 60
	2   CoreFoundation                      0x000000018b5531a0 -[NSObject(NSObject) __retain_OA] + 0
	3   CoreFoundation                      0x000000018b420360 ___forwarding___ + 1728
	4   CoreFoundation                      0x000000018b41fbe0 _CF_forwarding_prep_0 + 96
	5   libtk8.6.dylib                      0x0000000100940a1c GetRGBA + 64
	6   libtk8.6.dylib                      0x00000001009404a8 SetCGColorComponents + 140
	7   libtk8.6.dylib                      0x00000001009408e0 TkpGetColor + 544
	8   libtk8.6.dylib                      0x00000001008a2454 Tk_GetColor + 220
	9   libtk8.6.dylib                      0x0000000100895aa0 Tk_Get3DBorder + 204
	10  libtk8.6.dylib                      0x00000001008958ac Tk_Alloc3DBorderFromObj + 144
	11  libtk8.6.dylib                      0x00000001008a3810 DoObjConfig + 832
	12  libtk8.6.dylib                      0x00000001008a33cc Tk_InitOptions + 348
	13  libtk8.6.dylib                      0x00000001008a32c8 Tk_InitOptions + 88
	14  libtk8.6.dylib                      0x00000001008cacf0 CreateFrame + 1448
	15  libtk8.6.dylib                      0x00000001008cafe8 TkListCreateFrame + 156
	16  libtk8.6.dylib                      0x00000001008c3ec0 Initialize + 1848
	17  _tkinter.cpython-310-darwin.so      0x00000001008762d4 Tcl_AppInit + 92
	18  _tkinter.cpython-310-darwin.so      0x0000000100875f6c Tkapp_New + 548
	19  _tkinter.cpython-310-darwin.so      0x0000000100875d44 _tkinter_create_impl + 268
	20  _tkinter.cpython-310-darwin.so      0x000000010087597c _tkinter_create + 240
	21  Python                              0x000000010109b1f0 cfunction_vectorcall_FASTCALL + 88
	22  Python                              0x0000000101169f48 call_function + 132
	23  Python                              0x0000000101161fac _PyEval_EvalFrameDefault + 23072
	24  Python                              0x000000010115ad5c _PyEval_Vector + 360
	25  Python                              0x0000000101033dac _PyObject_FastCallDictTstate + 96
	26  Python                              0x00000001010c7cbc slot_tp_init + 196
	27  Python                              0x00000001010be950 type_call + 312
	28  Python                              0x0000000101033af4 _PyObject_MakeTpCall + 136
	29  Python                              0x000000010116a040 call_function + 380
	30  Python                              0x0000000101160a18 _PyEval_EvalFrameDefault + 17548
	31  Python                              0x000000010115ad5c _PyEval_Vector + 360
	32  Python                              0x0000000101169f48 call_function + 132
	33  Python                              0x0000000101160a18 _PyEval_EvalFrameDefault + 17548
	34  Python                              0x000000010115ad5c _PyEval_Vector + 360
	35  Python                              0x0000000101169f48 call_function + 132
	36  Python                              0x0000000101161404 _PyEval_EvalFrameDefault + 20088
	37  Python                              0x000000010115ad5c _PyEval_Vector + 360
	38  Python                              0x000000010115cb3c _PyEval_EvalFrameDefault + 1456
	39  Python                              0x000000010115ad5c _PyEval_Vector + 360
	40  Python                              0x0000000101169f48 call_function + 132
	41  Python                              0x0000000101160a18 _PyEval_EvalFrameDefault + 17548
	42  Python                              0x000000010115ad5c _PyEval_Vector + 360
	43  Python                              0x000000010115cb3c _PyEval_EvalFrameDefault + 1456
	44  Python                              0x000000010115ad5c _PyEval_Vector + 360
	45  Python                              0x000000010115cb3c _PyEval_EvalFrameDefault + 1456
	46  Python                              0x000000010115ad5c _PyEval_Vector + 360
	47  Python                              0x0000000101169f48 call_function + 132
	48  Python                              0x0000000101161404 _PyEval_EvalFrameDefault + 20088
	49  Python                              0x000000010115ad5c _PyEval_Vector + 360
	50  Python                              0x0000000101169f48 call_function + 132
	51  Python                              0x0000000101161404 _PyEval_EvalFrameDefault + 20088
	52  Python                              0x000000010115ad5c _PyEval_Vector + 360
	53  Python                              0x0000000101169f48 call_function + 132
	54  Python                              0x0000000101161404 _PyEval_EvalFrameDefault + 20088
	55  Python                              0x000000010115ad5c _PyEval_Vector + 360
	56  Python                              0x0000000101169f48 call_function + 132
	57  Python                              0x0000000101161fac _PyEval_EvalFrameDefault + 23072
	58  Python                              0x000000010115ad5c _PyEval_Vector + 360
	59  Python                              0x00000001011c52c8 pyrun_file + 308
	60  Python                              0x00000001011c4a0c _PyRun_SimpleFileObject + 336
	61  Python                              0x00000001011c4058 _PyRun_AnyFileObject + 216
	62  Python                              0x00000001011f0280 pymain_run_file_obj + 180
	63  Python                              0x00000001011ef920 pymain_run_file + 72
	64  Python                              0x00000001011eef08 pymain_run_python + 300
	65  Python                              0x00000001011eed9c Py_RunMain + 24
	66  Python                              0x00000001011f0428 pymain_main + 56
	67  Python                              0x00000001011f06ec Py_BytesMain + 40
	68  dyld                                0x00000001005bd0f4 start + 520
)
libc++abi: terminating with uncaught exception of type NSException

----------

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

From report at bugs.python.org  Tue Feb  1 16:19:37 2022
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 01 Feb 2022 21:19:37 +0000
Subject: [issue46573] Python modules such as pyglet or pygame crash Python
 when tkinter message boxes are opened on MacOS.
In-Reply-To: <1643482093.87.0.31269168021.issue46573@roundup.psfhosted.org>
Message-ID: <1643750377.78.0.927058316916.issue46573@roundup.psfhosted.org>


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

The last bit of the call stack according to lldb:

* thread #2, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
    frame #0: 0x000000018b3419b8 libsystem_kernel.dylib`__pthread_kill + 8
    frame #1: 0x000000018b374eb0 libsystem_pthread.dylib`pthread_kill + 288
    frame #2: 0x000000018b2b2314 libsystem_c.dylib`abort + 164
    frame #3: 0x000000018b331b50 libc++abi.dylib`abort_message + 132
    frame #4: 0x000000018b322f64 libc++abi.dylib`demangling_terminate_handler() + 332
    frame #5: 0x000000018b21a140 libobjc.A.dylib`_objc_terminate() + 144
    frame #6: 0x000000018b330ee4 libc++abi.dylib`std::__terminate(void (*)()) + 20
  * frame #7: 0x000000018b333c5c libc++abi.dylib`__cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*) + 36
    frame #8: 0x000000018b333c08 libc++abi.dylib`__cxa_throw + 140
    frame #9: 0x000000018b2118dc libobjc.A.dylib`objc_exception_throw + 352
    frame #10: 0x000000018b5531a0 CoreFoundation`-[NSObject(NSObject) doesNotRecognizeSelector:] + 144
    frame #11: 0x000000018b420360 CoreFoundation`___forwarding___ + 1728
    frame #12: 0x000000018b41fbe0 CoreFoundation`_CF_forwarding_prep_0 + 96
    frame #13: 0x0000000102388a1c libtk8.6.dylib`GetRGBA + 64
    frame #14: 0x00000001023884a8 libtk8.6.dylib`SetCGColorComponents + 140
    frame #15: 0x00000001023888e0 libtk8.6.dylib`TkpGetColor + 544
    frame #16: 0x00000001022ea454 libtk8.6.dylib`Tk_GetColor + 220
    frame #17: 0x00000001022ddaa0 libtk8.6.dylib`Tk_Get3DBorder + 204
    frame #18: 0x00000001022dd8ac libtk8.6.dylib`Tk_Alloc3DBorderFromObj + 144
    frame #19: 0x00000001022eb810 libtk8.6.dylib`DoObjConfig + 832
    frame #20: 0x00000001022eb3cc libtk8.6.dylib`Tk_InitOptions + 348
    frame #21: 0x00000001022eb2c8 libtk8.6.dylib`Tk_InitOptions + 88
    frame #22: 0x0000000102312cf0 libtk8.6.dylib`CreateFrame + 1448
    frame #23: 0x0000000102312fe8 libtk8.6.dylib`TkListCreateFrame + 156
    frame #24: 0x000000010230bec0 libtk8.6.dylib`Initialize + 1848
    frame #25: 0x000000010026a2d4 _tkinter.cpython-310-darwin.so`Tcl_AppInit + 92
    frame #26: 0x0000000100269f6c _tkinter.cpython-310-darwin.so`Tkapp_New + 548
    frame #27: 0x0000000100269d44 _tkinter.cpython-310-darwin.so`_tkinter_create_impl + 268
    frame #28: 0x000000010026997c _tkinter.cpython-310-darwin.so`_tkinter_create + 240
    frame #29: 0x0000000100bf71f0 Python`cfunction_vectorcall_FASTCALL + 88

----------

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

From report at bugs.python.org  Tue Feb  1 16:20:36 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Tue, 01 Feb 2022 21:20:36 +0000
Subject: [issue46603] `typing._strip_annotations` is not fully covered
In-Reply-To: <1643750261.29.0.798402203083.issue46603@roundup.psfhosted.org>
Message-ID: <1643750436.05.0.443813565341.issue46603@roundup.psfhosted.org>


Change by Nikita Sobolev <mail at sobolevn.me>:


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

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

From report at bugs.python.org  Tue Feb  1 16:27:28 2022
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 01 Feb 2022 21:27:28 +0000
Subject: [issue46573] Python modules such as pyglet or pygame crash Python
 when tkinter message boxes are opened on MacOS.
In-Reply-To: <1643482093.87.0.31269168021.issue46573@roundup.psfhosted.org>
Message-ID: <1643750848.68.0.884179862074.issue46573@roundup.psfhosted.org>


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

If I interpret the information I posted earlier correctly this is a bug in Tkinter, it calls a non-existing Objecive-C method (``-[NSApplication macOSVersion]``) and that results in an uncaught Objective-C exception and hence an abort().

BTW. All of this is using python 3.10.2 using the installer on python.org.

----------
components: +Tkinter

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

From report at bugs.python.org  Tue Feb  1 16:30:45 2022
From: report at bugs.python.org (Ned Deily)
Date: Tue, 01 Feb 2022 21:30:45 +0000
Subject: [issue46573] Python modules such as pyglet or pygame crash Python
 when tkinter message boxes are opened on MacOS.
In-Reply-To: <1643482093.87.0.31269168021.issue46573@roundup.psfhosted.org>
Message-ID: <1643751045.68.0.703481038078.issue46573@roundup.psfhosted.org>


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

> If I interpret the information I posted earlier correctly this is a bug in Tkinter [...]

Tkinter? Or Tk itself?

----------

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

From report at bugs.python.org  Tue Feb  1 16:31:36 2022
From: report at bugs.python.org (Steve Dower)
Date: Tue, 01 Feb 2022 21:31:36 +0000
Subject: [issue46594] Windows "Edit with IDLE >" only has one selection
In-Reply-To: <1643671307.89.0.0253325125686.issue46594@roundup.psfhosted.org>
Message-ID: <1643751096.65.0.750657359254.issue46594@roundup.psfhosted.org>


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

I wonder if you've managed to install the launcher a second time? If the second one is for current user but the first is for local machine, the Open With entries may not be being merged.

In theory, the installer is supposed to detect a previous launcher and match its setting, but the default did change recently, so maybe the detection is not working.

Not sure when I'll get a chance to check it out, so if someone else wants to check and confirm that would be helpful.

----------

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

From report at bugs.python.org  Tue Feb  1 16:32:18 2022
From: report at bugs.python.org (Kossi GLOKPOR)
Date: Tue, 01 Feb 2022 21:32:18 +0000
Subject: [issue46604] Documentation fix in ssl module
Message-ID: <1643751138.89.0.0198780201325.issue46604@roundup.psfhosted.org>


Change by Kossi GLOKPOR <hotkatz32 at gmail.com>:


----------
assignee: docs at python
components: Documentation
nosy: docs at python, glk0
priority: normal
severity: normal
status: open
title: Documentation fix in ssl module
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Tue Feb  1 16:40:53 2022
From: report at bugs.python.org (Kossi GLOKPOR)
Date: Tue, 01 Feb 2022 21:40:53 +0000
Subject: [issue46604] Documentation fix in ssl module
Message-ID: <1643751653.82.0.407194598333.issue46604@roundup.psfhosted.org>


Change by Kossi GLOKPOR <hotkatz32 at gmail.com>:


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

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

From report at bugs.python.org  Tue Feb  1 16:41:42 2022
From: report at bugs.python.org (Brandt Bucher)
Date: Tue, 01 Feb 2022 21:41:42 +0000
Subject: [issue46528] Simplify the VM's stack manipulations
In-Reply-To: <1643161199.78.0.253250267538.issue46528@roundup.psfhosted.org>
Message-ID: <1643751702.62.0.154101465856.issue46528@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:


New changeset a0e55a571cf01885fd5826266c37abaee307c309 by Brandt Bucher in branch 'main':
bpo-46528: Simplify BUILD_TUPLE/UNPACK_SEQUENCE folding (GH-31039)
https://github.com/python/cpython/commit/a0e55a571cf01885fd5826266c37abaee307c309


----------

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

From report at bugs.python.org  Tue Feb  1 16:49:08 2022
From: report at bugs.python.org (ov2k)
Date: Tue, 01 Feb 2022 21:49:08 +0000
Subject: [issue46605] Py_XDECREF() module on fail in Py_mod_exec
Message-ID: <1643752148.46.0.568852350737.issue46605@roundup.psfhosted.org>


New submission from ov2k <ov2k.github at gmail.com>:

In some of the xx modules, a Py_mod_exec function steals a reference to the module argument when an error occurs (Py_XDECREF(m) after goto fail).  It's a bit pernicious given the modules' stated intent to be used as a template, although I'm not sure how often this has actually happened.  At the very least, I haven't noticed this outside the xx modules.

For Python <= 3.9, this affects xx_exec() in xxmodule.c and xx_modexec() in xxlimited.c.  For Python >= 3.10, this affects xx_exec() in xxmodule.c and xx_modexec() in xxlimited_35.c.

----------
components: Extension Modules
messages: 412315
nosy: ov2k
priority: normal
severity: normal
status: open
title: Py_XDECREF() module on fail in Py_mod_exec
type: behavior
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Feb  1 17:02:02 2022
From: report at bugs.python.org (da-woods)
Date: Tue, 01 Feb 2022 22:02:02 +0000
Subject: [issue45711] Simplify the interpreter's (type, val,
 tb) exception representation
In-Reply-To: <1636025387.26.0.346517237471.issue45711@roundup.psfhosted.org>
Message-ID: <1643752922.76.0.077587459418.issue45711@roundup.psfhosted.org>


da-woods <dw-git at d-woods.co.uk> added the comment:

Just a quick comment on Cython and these changes:

Cython 0.29 can build itself on Python 3.11a4 with `CFLAGS="-DCYTHON_FAST_THREAD_STATE=0 -DCYTHON_USE_EXC_INFO_STACK=0" python3.11 setup.py build_ext`.

I think there's some coroutine code left that isn't fixed by those flags, but a large chunk of Cython libraries won't use coroutines and so will work fine with these flags. Hopefully that unblocks some stuff for you.

----------
nosy: +da-woods

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

From report at bugs.python.org  Tue Feb  1 17:34:02 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 01 Feb 2022 22:34:02 +0000
Subject: [issue14916] PyRun_InteractiveLoop fails to run interactively when
 using a Linux pty that's not tied to stdin/stdout
In-Reply-To: <1337960558.56.0.442179213708.issue14916@psf.upfronthosting.co.za>
Message-ID: <1643754842.19.0.412872881338.issue14916@roundup.psfhosted.org>


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


New changeset 89b13042fcfc95bae21a49806a205ef62f1cdd73 by Paul m. p. P in branch 'main':
bpo-14916: use specified tokenizer fd for file input (GH-31006)
https://github.com/python/cpython/commit/89b13042fcfc95bae21a49806a205ef62f1cdd73


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

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

From report at bugs.python.org  Tue Feb  1 17:34:17 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 01 Feb 2022 22:34:17 +0000
Subject: [issue14916] PyRun_InteractiveLoop fails to run interactively when
 using a Linux pty that's not tied to stdin/stdout
In-Reply-To: <1337960558.56.0.442179213708.issue14916@psf.upfronthosting.co.za>
Message-ID: <1643754857.88.0.239942128275.issue14916@roundup.psfhosted.org>


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


----------
pull_requests: +29250
pull_request: https://github.com/python/cpython/pull/31065

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

From report at bugs.python.org  Tue Feb  1 18:13:36 2022
From: report at bugs.python.org (Brandt Bucher)
Date: Tue, 01 Feb 2022 23:13:36 +0000
Subject: [issue45773] Compiler hangs during jump elimination
In-Reply-To: <1636487782.5.0.379047434297.issue45773@roundup.psfhosted.org>
Message-ID: <1643757216.69.0.235823708771.issue45773@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

My fix for this seems to have erroneously added two invalid new jump threads:

POP_JUMP_IF_FALSE(a) to JUMP_IF_FALSE_OR_POP(b) is folded into POP_JUMP_IF_FALSE(b)
POP_JUMP_IF_TRUE(a) to JUMP_IF_TRUE_OR_POP(b) is folded into POP_JUMP_IF_TRUE(b)

The good news is that I can't get the compiler to actually emit these particular jump sequences. It still needs to be fixed ASAP, though.

----------
nosy: +pablogsal
priority: high -> release blocker
resolution: fixed -> 
stage: resolved -> patch review
status: closed -> open
type: crash -> behavior

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

From report at bugs.python.org  Tue Feb  1 18:13:54 2022
From: report at bugs.python.org (Brandt Bucher)
Date: Tue, 01 Feb 2022 23:13:54 +0000
Subject: [issue45773] Compiler hangs during jump elimination
In-Reply-To: <1636487782.5.0.379047434297.issue45773@roundup.psfhosted.org>
Message-ID: <1643757234.96.0.35594436249.issue45773@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
pull_requests: +29251
pull_request: https://github.com/python/cpython/pull/31066

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

From report at bugs.python.org  Tue Feb  1 18:48:12 2022
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 01 Feb 2022 23:48:12 +0000
Subject: [issue46594] Windows "Edit with IDLE >" only has one selection
In-Reply-To: <1643671307.89.0.0253325125686.issue46594@roundup.psfhosted.org>
Message-ID: <1643759292.98.0.904950273359.issue46594@roundup.psfhosted.org>


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

> the Open With entries may not be being merged.

That would probably be a bug in the Windows shell API. The HKCU and HKLM subkeys of "Software\Classes\Python.File\Shell\editwithidle\shell" are merged in the HKCR view. The same key path can exist in both hives, for which the view contains the union, with precedence for HKCU.

For example, with "Software\Classes\spam":

    import winreg

    hkm = winreg.CreateKey(winreg.HKEY_LOCAL_MACHINE, r'Software\Classes\spam')
    winreg.SetValueEx(hkm, 'eggs', 0, winreg.REG_SZ, 'hklm')
    winreg.SetValueEx(hkm, 'baz', 0, winreg.REG_SZ, 'hklm')

    hku = winreg.CreateKey(winreg.HKEY_CURRENT_USER, r'Software\Classes\spam')
    winreg.SetValueEx(hku, 'eggs', 0, winreg.REG_SZ, 'hkcu')
    winreg.SetValueEx(hku, 'bam', 0, winreg.REG_SZ, 'hkcu')

    hkr = winreg.OpenKey(winreg.HKEY_CLASSES_ROOT, 'spam')

    >>> winreg.EnumValue(hkr, 0)
    ('bam', 'hkcu', 1)
    >>> winreg.EnumValue(hkr, 1)
    ('baz', 'hklm', 1)
    >>> winreg.EnumValue(hkr, 2)
    ('eggs', 'hkcu', 1)

    >>> winreg.EnumValue(hkr, 3)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    OSError: [WinError 259] No more data is available

----------

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

From report at bugs.python.org  Tue Feb  1 18:57:32 2022
From: report at bugs.python.org (Matthew Davis)
Date: Tue, 01 Feb 2022 23:57:32 +0000
Subject: [issue42369] Reading ZipFile not thread-safe
In-Reply-To: <1605524871.74.0.395089652548.issue42369@roundup.psfhosted.org>
Message-ID: <1643759852.61.0.90681461109.issue42369@roundup.psfhosted.org>


Matthew Davis <bugs.python.org at mdavis.xyz> added the comment:

In addition to fixing any unexpected behavior, can we update the documentation [1] to state what the expected behavior is in terms of thread safety?

[1] https://docs.python.org/3/library/zipfile.html

----------
nosy: +mdavis-xyz

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

From report at bugs.python.org  Tue Feb  1 20:11:39 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 02 Feb 2022 01:11:39 +0000
Subject: [issue44359] test_ftplib.test_makeport() fails as "env changes" if a
 socket operation times out in a thread: TimeoutError is not catched
In-Reply-To: <1623225511.63.0.739788412824.issue44359@roundup.psfhosted.org>
Message-ID: <1643764299.52.0.018457262934.issue44359@roundup.psfhosted.org>


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

On Fedora Rawhide x64-64, I can reproduce the test_ftplib test_makeport() issue in reliable way.

On Python 3.9, the test also logs the exception but the test is marked as a success:
---
$ ./python -m test -u all test_ftplib -v -m test_makeport
(...)
test_makeport (test.test_ftplib.TestFTPClass) ... ok
test_makeport (test.test_ftplib.TestIPv6Environment) ... ok
test_makeport (test.test_ftplib.TestTLS_FTPClassMixin) ... Exception in thread Thread-3:
Traceback (most recent call last):
  File "/home/vstinner/python/3.9/Lib/asyncore.py", line 83, in read
    obj.handle_read_event()
  File "/home/vstinner/python/3.9/Lib/test/test_ftplib.py", line 377, in handle_read_event
    self._do_ssl_handshake()
  File "/home/vstinner/python/3.9/Lib/test/test_ftplib.py", line 338, in _do_ssl_handshake
    self.socket.do_handshake()
  File "/home/vstinner/python/3.9/Lib/ssl.py", line 1309, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLZeroReturnError: TLS/SSL connection has been closed (EOF) (_ssl.c:1129)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/vstinner/python/3.9/Lib/threading.py", line 973, in _bootstrap_inner
    self.run()
  File "/home/vstinner/python/3.9/Lib/test/test_ftplib.py", line 291, in run
    asyncore.loop(timeout=0.1, count=1)
  File "/home/vstinner/python/3.9/Lib/asyncore.py", line 207, in loop
    poll_fun(timeout, map)
  File "/home/vstinner/python/3.9/Lib/asyncore.py", line 150, in poll
    read(obj)
  File "/home/vstinner/python/3.9/Lib/asyncore.py", line 87, in read
    obj.handle_error()
  File "/home/vstinner/python/3.9/Lib/test/test_ftplib.py", line 414, in handle_error
    raise Exception
Exception
ok
(...)
Tests result: SUCCESS
---

make buildbottest uses -W option which hides the test output unless the test failed.

In this case, the unhandled threading exception is siently ignored:
---
$ ./python -m test -u all test_ftplib -W -m test_makeport -j1
(...)
0:00:00 load avg: 0.75 [1/1] test_ftplib passed
(...)
Tests result: SUCCESS
---

On Python 3.10 and newer, libregrtest sets a threading excepthook to (1) log the exception (2) mark that the note "altered the environmen": mark the test as "ENV CHANGED". I did that to detect unhandled exceptions like this one.

In this case, unhandled exceptions come from the four handle_error() method of test_ftplib dispatcher classes, like SSLConnection, which are implemented as:

    def handle_error(self):
        raise Exception

test_ftplib closes sockets in TestFTPClass.tearDown() method:

    def tearDown(self):
        self.client.close()
        self.server.stop()
        # Explicitly clear the attribute to prevent dangling thread
        self.server = None
        asyncore.close_all(ignore_all=True)

The problem is that the code doesn't implement any kind of error handling. If asyncore gets a socket exception, it calls handle_error() which raises an a new Exception instance. That's it.

IMO it's not worth it to bother with handling socket errors in test_ftplib. The server is implemented with asyncore which is deprecated since Python 3.6. The FTP protocol itself is legacy.

Attached PR simply ignores socket erors rather than logging unhandled threading exceptions.

----------

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

From report at bugs.python.org  Tue Feb  1 20:20:32 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 02 Feb 2022 01:20:32 +0000
Subject: [issue46591] Make About IDLE links clickable
In-Reply-To: <1643591753.6.0.172219328947.issue46591@roundup.psfhosted.org>
Message-ID: <1643764832.63.0.701691260901.issue46591@roundup.psfhosted.org>


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


New changeset 53c78080573b3bae4c4e782b9f47dce48aac9688 by Wes in branch 'main':
bpo-46591: Make About IDLE doc link label clickable (GH-30251)
https://github.com/python/cpython/commit/53c78080573b3bae4c4e782b9f47dce48aac9688


----------

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

From report at bugs.python.org  Tue Feb  1 20:20:37 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Feb 2022 01:20:37 +0000
Subject: [issue46591] Make About IDLE links clickable
In-Reply-To: <1643591753.6.0.172219328947.issue46591@roundup.psfhosted.org>
Message-ID: <1643764837.05.0.0441110775668.issue46591@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: +29252
pull_request: https://github.com/python/cpython/pull/31067

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

From report at bugs.python.org  Tue Feb  1 20:21:56 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Feb 2022 01:21:56 +0000
Subject: [issue46591] Make About IDLE links clickable
In-Reply-To: <1643591753.6.0.172219328947.issue46591@roundup.psfhosted.org>
Message-ID: <1643764916.07.0.253796228854.issue46591@roundup.psfhosted.org>


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


----------
pull_requests: +29253
pull_request: https://github.com/python/cpython/pull/31068

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

From report at bugs.python.org  Tue Feb  1 20:26:01 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 02 Feb 2022 01:26:01 +0000
Subject: [issue44359] test_ftplib.test_makeport() fails as "env changes" if a
 socket operation times out in a thread: TimeoutError is not catched
In-Reply-To: <1623225511.63.0.739788412824.issue44359@roundup.psfhosted.org>
Message-ID: <1643765161.52.0.174991413359.issue44359@roundup.psfhosted.org>


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


----------
pull_requests: +29254
pull_request: https://github.com/python/cpython/pull/31069

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

From report at bugs.python.org  Tue Feb  1 20:31:33 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 02 Feb 2022 01:31:33 +0000
Subject: [issue44359] test_ftplib.test_makeport() fails as "env changes" if a
 socket operation times out in a thread: TimeoutError is not catched
In-Reply-To: <1623225511.63.0.739788412824.issue44359@roundup.psfhosted.org>
Message-ID: <1643765493.62.0.913885409591.issue44359@roundup.psfhosted.org>


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

GH-31069 simply silently ignore all socket errors.

I tried to write a smart fix which only ignores socket errors when tests are done, in tearDown(). But than I got issues in makepasv() tests which creates a socket and immediately closes it. The server also logs an error in this case.

IMO it's not worth it trying to write the perfect error handling for test_ftplib.

----------
versions: +Python 3.9

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

From report at bugs.python.org  Tue Feb  1 20:47:17 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Feb 2022 01:47:17 +0000
Subject: [issue46591] Make About IDLE links clickable
In-Reply-To: <1643591753.6.0.172219328947.issue46591@roundup.psfhosted.org>
Message-ID: <1643766437.34.0.113376070916.issue46591@roundup.psfhosted.org>


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


New changeset a1869e385b17bfdfe8d9850047f5b2dbb88e58fa by Miss Islington (bot) in branch '3.9':
bpo-46591: Make About IDLE doc link label clickable (GH-30251)
https://github.com/python/cpython/commit/a1869e385b17bfdfe8d9850047f5b2dbb88e58fa


----------

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

From report at bugs.python.org  Tue Feb  1 20:47:49 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 02 Feb 2022 01:47:49 +0000
Subject: [issue44359] test_ftplib.test_makeport() fails as "env changes" if a
 socket operation times out in a thread: TimeoutError is not catched
In-Reply-To: <1623225511.63.0.739788412824.issue44359@roundup.psfhosted.org>
Message-ID: <1643766469.1.0.777526353649.issue44359@roundup.psfhosted.org>


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


New changeset 0611eafc709cbe8a2a0bdde082d25df0c5034de7 by Victor Stinner in branch 'main':
bpo-44359: Fix test_ftplib unhandled thread exceptions (GH-31069)
https://github.com/python/cpython/commit/0611eafc709cbe8a2a0bdde082d25df0c5034de7


----------

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

From report at bugs.python.org  Tue Feb  1 20:47:49 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Feb 2022 01:47:49 +0000
Subject: [issue44359] test_ftplib.test_makeport() fails as "env changes" if a
 socket operation times out in a thread: TimeoutError is not catched
In-Reply-To: <1623225511.63.0.739788412824.issue44359@roundup.psfhosted.org>
Message-ID: <1643766469.23.0.75897261679.issue44359@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Tue Feb  1 20:47:53 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Feb 2022 01:47:53 +0000
Subject: [issue44359] test_ftplib.test_makeport() fails as "env changes" if a
 socket operation times out in a thread: TimeoutError is not catched
In-Reply-To: <1623225511.63.0.739788412824.issue44359@roundup.psfhosted.org>
Message-ID: <1643766473.68.0.631897310362.issue44359@roundup.psfhosted.org>


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


----------
pull_requests: +29256
pull_request: https://github.com/python/cpython/pull/31071

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

From report at bugs.python.org  Tue Feb  1 20:47:54 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Feb 2022 01:47:54 +0000
Subject: [issue46591] Make About IDLE links clickable
In-Reply-To: <1643591753.6.0.172219328947.issue46591@roundup.psfhosted.org>
Message-ID: <1643766474.78.0.969485599033.issue46591@roundup.psfhosted.org>


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


New changeset 7dee93c2d223a080f410f6901987e9d363743471 by Miss Islington (bot) in branch '3.10':
bpo-46591: Make About IDLE doc link label clickable (GH-30251)
https://github.com/python/cpython/commit/7dee93c2d223a080f410f6901987e9d363743471


----------

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

From report at bugs.python.org  Tue Feb  1 21:07:12 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 02 Feb 2022 02:07:12 +0000
Subject: [issue45173] Remove configparser deprecations
In-Reply-To: <1631383839.78.0.984503527213.issue45173@roundup.psfhosted.org>
Message-ID: <1643767632.9.0.739991143878.issue45173@roundup.psfhosted.org>


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

> Searching 4,764 sdists from the top 5,000 PyPI packages, these 13 contain "LegacyInterpolation"

Other removed symbols are causing troubles, like SafeConfigParser.

Example of Fedora bz #2025600: mom fails to build with Python 3.11: AttributeError: module 'configparser' has no attribute 'SafeConfigParser'.

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

Another example: python-iniparse fails to build with Python 3.11: AttributeError: 'RawConfigParser' object has no attribute 'readfp'

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

You can try to unfold https://bugzilla.redhat.com/buglist.cgi?bug_id=2016048&bug_id_type=anddependson&format=tvp and search for "configparser".

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

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

From report at bugs.python.org  Tue Feb  1 21:10:47 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 02 Feb 2022 02:10:47 +0000
Subject: [issue45173] Remove configparser deprecations
In-Reply-To: <1631383839.78.0.984503527213.issue45173@roundup.psfhosted.org>
Message-ID: <1643767847.43.0.880985943035.issue45173@roundup.psfhosted.org>


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

Currently, the issue title is "Remove configparser deprecations".

GH-30927 doesn't remove deprecated functions, but adds new warnings. It's really confusing to make this change as part of this issue.

Can you please create a new issue for GH-30927 "bpo-45173: Add DeprecationWarning to LegacyInterpolation"? If it's removed, it's not going to be removed before Python 3.13, so it's not directly related to this issue. By the way, it would be nice explain the rationale for removing it.

----------

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

From report at bugs.python.org  Tue Feb  1 21:12:34 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Feb 2022 02:12:34 +0000
Subject: [issue44359] test_ftplib.test_makeport() fails as "env changes" if a
 socket operation times out in a thread: TimeoutError is not catched
In-Reply-To: <1623225511.63.0.739788412824.issue44359@roundup.psfhosted.org>
Message-ID: <1643767954.55.0.439505511057.issue44359@roundup.psfhosted.org>


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


New changeset 85b421fbff23ff41c52fa5bde191920b3701f0d0 by Miss Islington (bot) in branch '3.10':
bpo-44359: Fix test_ftplib unhandled thread exceptions (GH-31069)
https://github.com/python/cpython/commit/85b421fbff23ff41c52fa5bde191920b3701f0d0


----------

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

From report at bugs.python.org  Tue Feb  1 21:17:15 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Feb 2022 02:17:15 +0000
Subject: [issue44359] test_ftplib.test_makeport() fails as "env changes" if a
 socket operation times out in a thread: TimeoutError is not catched
In-Reply-To: <1623225511.63.0.739788412824.issue44359@roundup.psfhosted.org>
Message-ID: <1643768235.64.0.987882740245.issue44359@roundup.psfhosted.org>


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


New changeset 0371e5d7f1248abb0712fc98c3135d01d265cec8 by Miss Islington (bot) in branch '3.9':
bpo-44359: Fix test_ftplib unhandled thread exceptions (GH-31069)
https://github.com/python/cpython/commit/0371e5d7f1248abb0712fc98c3135d01d265cec8


----------

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

From report at bugs.python.org  Tue Feb  1 21:38:22 2022
From: report at bugs.python.org (Ned Deily)
Date: Wed, 02 Feb 2022 02:38:22 +0000
Subject: [issue46602] Subtle trouble with heredoc append in configure.
In-Reply-To: <1643741313.11.0.141658321036.issue46602@roundup.psfhosted.org>
Message-ID: <1643769502.64.0.543087853709.issue46602@roundup.psfhosted.org>


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


New changeset b1288964e31069bdf81abe560c82874f6f620928 by adanhawth in branch 'main':
bpo-46602: Do not append conftest.c (GH-31062)
https://github.com/python/cpython/commit/b1288964e31069bdf81abe560c82874f6f620928


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

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

From report at bugs.python.org  Tue Feb  1 21:48:05 2022
From: report at bugs.python.org (Ned Deily)
Date: Wed, 02 Feb 2022 02:48:05 +0000
Subject: [issue46602] Subtle trouble with heredoc append in configure.
In-Reply-To: <1643741313.11.0.141658321036.issue46602@roundup.psfhosted.org>
Message-ID: <1643770085.24.0.7295820635.issue46602@roundup.psfhosted.org>


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

Merged for release in 3.11.0a5. We *could* backport it to 3.10 and 3.9 but that involves regenerating configure again for each. It's probably not high enough priority to justify the churn for bugfix releases.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.11

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

From report at bugs.python.org  Tue Feb  1 21:49:15 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 02 Feb 2022 02:49:15 +0000
Subject: [issue46414] Add typing.reveal_type
In-Reply-To: <1642431742.97.0.220350932108.issue46414@roundup.psfhosted.org>
Message-ID: <1643770155.37.0.468232734024.issue46414@roundup.psfhosted.org>


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


New changeset abcc3d75f6e570519cb37c62130a2295c6928bff by Jelle Zijlstra in branch 'main':
bpo-46414: Add typing.reveal_type (#30646)
https://github.com/python/cpython/commit/abcc3d75f6e570519cb37c62130a2295c6928bff


----------

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

From report at bugs.python.org  Tue Feb  1 21:50:04 2022
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 02 Feb 2022 02:50:04 +0000
Subject: [issue45639] Support webp and aivf image formats in mimetypes
In-Reply-To: <1635388414.48.0.724029722643.issue45639@roundup.psfhosted.org>
Message-ID: <1643770204.79.0.963357188231.issue45639@roundup.psfhosted.org>


Change by ?ric Araujo <merwok at netwok.org>:


----------
title: Support modern image formats in MIME types -> Support webp and aivf image formats in mimetypes

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

From report at bugs.python.org  Tue Feb  1 21:50:12 2022
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 02 Feb 2022 02:50:12 +0000
Subject: [issue46600] Python built with clang -O0 allocates 10x more stack
 memory than clang -O3 on a Python function call
In-Reply-To: <1643720760.9.0.302596428689.issue46600@roundup.psfhosted.org>
Message-ID: <1643770212.29.0.594888401019.issue46600@roundup.psfhosted.org>


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

FWIW, it seems -O0 don't merge local variables in different path or lifetime.

For example, see _Py_abspath

```
    if (path[0] == '\0' || !wcscmp(path, L".")) {
       wchar_t cwd[MAXPATHLEN + 1];
       //(snip)
    }
    //(snip)
    wchar_t cwd[MAXPATHLEN + 1];
```

wchar_t is 4bytes and MAXPATHLEN is 4096 on Linux. So each cwd is 16388bytes.
-Og allocates 32856 bytes for it and -Og allocates 16440 bytes for it.

I don't know what is the specific optimization flag in -Og do merge local variable, but I think -Og is very important for _PyEval_EvalFrameDefault() since it has many local variables in huge switch-case statements.
-Og allocates 312 bytes for it and -O0 allocates 8280 bytes for it.

By the way, clang 13 has `-fstack-usage` option like gcc, but clang 12 don't have it.
Since Ubuntu 20.04 have only clang 12, I use `-fstack-size-segment` and https://github.com/mvanotti/stack-sizes to get stack size.

----------
nosy: +methane

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

From report at bugs.python.org  Tue Feb  1 21:50:29 2022
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 02 Feb 2022 02:50:29 +0000
Subject: [issue45639] Support webp and avif image formats in mimetypes
In-Reply-To: <1635388414.48.0.724029722643.issue45639@roundup.psfhosted.org>
Message-ID: <1643770229.39.0.638210943539.issue45639@roundup.psfhosted.org>


Change by ?ric Araujo <merwok at netwok.org>:


----------
title: Support webp and aivf image formats in mimetypes -> Support webp and avif image formats in mimetypes

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

From report at bugs.python.org  Tue Feb  1 21:51:21 2022
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 02 Feb 2022 02:51:21 +0000
Subject: [issue38902] image/webp support in mimetypes
In-Reply-To: <1574548382.26.0.67471558876.issue38902@roundup.psfhosted.org>
Message-ID: <1643770281.55.0.220414291735.issue38902@roundup.psfhosted.org>


Change by ?ric Araujo <merwok at netwok.org>:


----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> Support webp and avif image formats in mimetypes
versions: +Python 3.11 -Python 3.10

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

From report at bugs.python.org  Tue Feb  1 21:51:57 2022
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 02 Feb 2022 02:51:57 +0000
Subject: [issue42049] Add image/webp to list of media types in mimetypes.py
In-Reply-To: <1602826491.72.0.784851705448.issue42049@roundup.psfhosted.org>
Message-ID: <1643770317.8.0.897714917773.issue42049@roundup.psfhosted.org>


Change by ?ric Araujo <merwok at netwok.org>:


----------
superseder: image/webp support in mimetypes -> Support webp and avif image formats in mimetypes

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

From report at bugs.python.org  Tue Feb  1 21:52:36 2022
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 02 Feb 2022 02:52:36 +0000
Subject: [issue42205] Add image/webp to list of non-standard mimetypes
In-Reply-To: <1604049363.03.0.933855009454.issue42205@roundup.psfhosted.org>
Message-ID: <1643770356.61.0.830020284942.issue42205@roundup.psfhosted.org>


Change by ?ric Araujo <merwok at netwok.org>:


----------
superseder: image/webp support in mimetypes -> Support webp and avif image formats in mimetypes

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

From report at bugs.python.org  Tue Feb  1 22:06:44 2022
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 02 Feb 2022 03:06:44 +0000
Subject: [issue46606] Large C stack usage of os.getgroups() and os.setgroups()
Message-ID: <1643771204.31.0.0513908090604.issue46606@roundup.psfhosted.org>


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

I checked stack usage for bpo-46600 and found this two functions use a lot of stack.

os_setgroups: 262200 bytes
os_getgroups_impl: 262184 bytes

Both function has local variable like this:

    gid_t grouplist[MAX_GROUPS];

MAX_GROUPS is defined as:

```
#ifdef NGROUPS_MAX
#define MAX_GROUPS NGROUPS_MAX
#else
    /* defined to be 16 on Solaris7, so this should be a small number */
#define MAX_GROUPS 64
#endif
```

NGROUPS_MAX is 65536 and sizeof(gid_t) is 4 on Ubuntu 20.04, so grouplist is 262144bytes.

It seems this grouplist is just for avoid allocation:

```
    } else if (n <= MAX_GROUPS) {
        /* groups will fit in existing array */
        alt_grouplist = grouplist;
    } else {
        alt_grouplist = PyMem_New(gid_t, n);
        if (alt_grouplist == NULL) {
            return PyErr_NoMemory();
        }
```

How about just using `#define MAX_GROUPS 64`?
Or should we remove this grouplist because os.grouplist() is not called so frequently?

----------
components: Library (Lib)
messages: 412335
nosy: methane
priority: normal
severity: normal
status: open
title: Large C stack usage of os.getgroups() and os.setgroups()
versions: Python 3.11

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

From report at bugs.python.org  Tue Feb  1 22:42:56 2022
From: report at bugs.python.org (Nathan Howard)
Date: Wed, 02 Feb 2022 03:42:56 +0000
Subject: [issue46602] Subtle trouble with heredoc append in configure.
In-Reply-To: <1643770085.24.0.7295820635.issue46602@roundup.psfhosted.org>
Message-ID: <CALT7LGwPHhHjnCs+RnVH06HmoqwgnAnpQcKUnaGSptmigUkuGw@mail.gmail.com>


Nathan Howard <adanhawthorn at gmail.com> added the comment:

Ok.  Let me know if something changes to justify the backport churn.
I can regen.

On 2/1/22, Ned Deily <report at bugs.python.org> wrote:
>
> Ned Deily <nad at python.org> added the comment:
>
> Merged for release in 3.11.0a5. We *could* backport it to 3.10 and 3.9 but
> that involves regenerating configure again for each. It's probably not high
> enough priority to justify the churn for bugfix releases.
>
> ----------
> resolution:  -> fixed
> stage: patch review -> resolved
> status: open -> closed
> versions: +Python 3.11
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue46602>
> _______________________________________
>

----------

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

From report at bugs.python.org  Tue Feb  1 23:54:36 2022
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 02 Feb 2022 04:54:36 +0000
Subject: [issue46606] Large C stack usage of os.getgroups() and os.setgroups()
In-Reply-To: <1643771204.31.0.0513908090604.issue46606@roundup.psfhosted.org>
Message-ID: <1643777676.06.0.151902831469.issue46606@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Wed Feb  2 00:16:18 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 02 Feb 2022 05:16:18 +0000
Subject: [issue46600] Python built with clang -O0 allocates 10x more stack
 memory than clang -O3 on a Python function call
In-Reply-To: <1643720760.9.0.302596428689.issue46600@roundup.psfhosted.org>
Message-ID: <1643778978.31.0.556441013224.issue46600@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/issue46600>
_______________________________________

From report at bugs.python.org  Wed Feb  2 00:16:27 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 02 Feb 2022 05:16:27 +0000
Subject: [issue46606] Large C stack usage of os.getgroups() and os.setgroups()
In-Reply-To: <1643771204.31.0.0513908090604.issue46606@roundup.psfhosted.org>
Message-ID: <1643778987.36.0.0272824034173.issue46606@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/issue46606>
_______________________________________

From report at bugs.python.org  Wed Feb  2 00:29:28 2022
From: report at bugs.python.org (Jason Yang)
Date: Wed, 02 Feb 2022 05:29:28 +0000
Subject: [issue46180] Button clicked failed when mouse hover tooltip and
 tooltip destroyed
In-Reply-To: <1640515148.68.0.766649384181.issue46180@roundup.psfhosted.org>
Message-ID: <1643779768.5.0.609406859667.issue46180@roundup.psfhosted.org>


Jason Yang <jason990420 at outlook.com> added the comment:

The platform is WIN10 which shown at last line in first message.
I don't have other platforms to test if ok or not.

----------

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

From report at bugs.python.org  Wed Feb  2 00:50:10 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Wed, 02 Feb 2022 05:50:10 +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: <1643781010.7.0.422509357048.issue40077@roundup.psfhosted.org>


Kumar Aditya <rahuladitya303 at gmail.com> added the comment:

On Windows PC/winreg.c has PyHKEY_Type static type which isn't cleared at exit too.

----------
nosy: +kumaraditya303

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

From report at bugs.python.org  Wed Feb  2 02:01:09 2022
From: report at bugs.python.org (Hugo van Kemenade)
Date: Wed, 02 Feb 2022 07:01:09 +0000
Subject: [issue46607] Add DeprecationWarning to configparser's
 LegacyInterpolation
Message-ID: <1643785269.24.0.226402381238.issue46607@roundup.psfhosted.org>


New submission from Hugo van Kemenade <hugovk+python at gmail.com>:

The LegacyInterpolation class of configparser has been deprecated in docs since 3.2, but without raising a DeprecationWarning.

The 3.2 HISTORY file says:

> - configparser: the SafeConfigParser class has been renamed to ConfigParser.
> The legacy ConfigParser class has been removed but its interpolation mechanism is still available as LegacyInterpolation.

Searching the top 5,000 PyPI sdists, there's very little (if any "real") use of LegacyInterpolation. Details: https://bugs.python.org/issue45173#msg409685

Other configparser deprecations were added in 3.2, but with DeprecationWarnings.

Let's add a DeprecationWarning for a couple of releases before removal.

----------
components: Library (Lib)
messages: 412339
nosy: hugovk
priority: normal
severity: normal
status: open
title: Add DeprecationWarning to configparser's LegacyInterpolation
versions: Python 3.11

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

From report at bugs.python.org  Wed Feb  2 02:07:05 2022
From: report at bugs.python.org (Hugo van Kemenade)
Date: Wed, 02 Feb 2022 07:07:05 +0000
Subject: [issue46607] Add DeprecationWarning to configparser's
 LegacyInterpolation
In-Reply-To: <1643785269.24.0.226402381238.issue46607@roundup.psfhosted.org>
Message-ID: <1643785625.94.0.660317371387.issue46607@roundup.psfhosted.org>


Change by Hugo van Kemenade <hugovk+python at gmail.com>:


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

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

From report at bugs.python.org  Wed Feb  2 02:10:02 2022
From: report at bugs.python.org (Hugo van Kemenade)
Date: Wed, 02 Feb 2022 07:10:02 +0000
Subject: [issue45173] Remove configparser deprecations
In-Reply-To: <1631383839.78.0.984503527213.issue45173@roundup.psfhosted.org>
Message-ID: <1643785802.29.0.114250492372.issue45173@roundup.psfhosted.org>


Change by Hugo van Kemenade <hugovk+python at gmail.com>:


----------
pull_requests:  -29106

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

From report at bugs.python.org  Wed Feb  2 02:11:00 2022
From: report at bugs.python.org (Hugo van Kemenade)
Date: Wed, 02 Feb 2022 07:11:00 +0000
Subject: [issue45173] Remove configparser deprecations
In-Reply-To: <1631383839.78.0.984503527213.issue45173@roundup.psfhosted.org>
Message-ID: <1643785860.44.0.923416899777.issue45173@roundup.psfhosted.org>


Hugo van Kemenade <hugovk+python at gmail.com> added the comment:

Sure, please see https://bugs.python.org/issue46607.

I've rebased GH-30927 to use the new issue number.

----------

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

From report at bugs.python.org  Wed Feb  2 02:53:49 2022
From: report at bugs.python.org (Elmir)
Date: Wed, 02 Feb 2022 07:53:49 +0000
Subject: [issue46005] [doc] replace 'distutils' examples with 'setuptools'
In-Reply-To: <1638864537.57.0.967787312853.issue46005@roundup.psfhosted.org>
Message-ID: <1643788429.79.0.732763331454.issue46005@roundup.psfhosted.org>


Elmir <elmir.jagudin at maxiv.lu.se> added the comment:

I agree that documenting third-party tools in CPython docs is a bit weird. I guess this is more an issue with setuptools docs. IMHO here is no clear explanation on how to build extension modules there.

As a temporary work around, I wrote an example of building extension module with setuptools here:

https://elmjag.github.io/setuptools.html

----------

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

From report at bugs.python.org  Wed Feb  2 03:15:30 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 02 Feb 2022 08:15:30 +0000
Subject: [issue46583] Modernize `selectors.py` by removing unused
 `sys.version_info` check
In-Reply-To: <1643553495.3.0.869043137908.issue46583@roundup.psfhosted.org>
Message-ID: <1643789730.2.0.674847145357.issue46583@roundup.psfhosted.org>


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


New changeset 3483aa65dfebfc60a87ea9db3f20da84be41f606 by Nikita Sobolev in branch 'main':
bpo-46583: remove unused `sys.version_info` check from `selectors` (GH-31023)
https://github.com/python/cpython/commit/3483aa65dfebfc60a87ea9db3f20da84be41f606


----------

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

From report at bugs.python.org  Wed Feb  2 03:35:32 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 02 Feb 2022 08:35:32 +0000
Subject: [issue46583] Modernize `selectors.py` by removing unused
 `sys.version_info` check
In-Reply-To: <1643553495.3.0.869043137908.issue46583@roundup.psfhosted.org>
Message-ID: <1643790932.26.0.915382834399.issue46583@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/issue46583>
_______________________________________

From report at bugs.python.org  Wed Feb  2 03:36:54 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 02 Feb 2022 08:36:54 +0000
Subject: [issue46583] Modernize `selectors.py` by removing unused
 `sys.version_info` check
In-Reply-To: <1643553495.3.0.869043137908.issue46583@roundup.psfhosted.org>
Message-ID: <1643791014.53.0.813436387403.issue46583@roundup.psfhosted.org>


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

The change should NOT be backported, it doesn't fix any bug but clears code a little

----------
versions:  -Python 3.10, Python 3.9

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

From report at bugs.python.org  Wed Feb  2 03:38:22 2022
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 02 Feb 2022 08:38:22 +0000
Subject: [issue46573] Python modules such as pyglet or pygame crash Python
 when tkinter message boxes are opened on MacOS.
In-Reply-To: <1643482093.87.0.31269168021.issue46573@roundup.psfhosted.org>
Message-ID: <1643791102.22.0.684136890259.issue46573@roundup.psfhosted.org>


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

Oops, sorry: In Tk itself.

----------

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

From report at bugs.python.org  Wed Feb  2 03:40:11 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 02 Feb 2022 08:40:11 +0000
Subject: [issue46591] Make About IDLE links clickable
In-Reply-To: <1643591753.6.0.172219328947.issue46591@roundup.psfhosted.org>
Message-ID: <1643791211.95.0.879807738299.issue46591@roundup.psfhosted.org>


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

Thank you for the idea and patch.

----------
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/issue46591>
_______________________________________

From report at bugs.python.org  Wed Feb  2 04:08:27 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Wed, 02 Feb 2022 09:08:27 +0000
Subject: [issue46608] Exclude marshalled-frozen data if deep-freezing to save
 300 KB space
Message-ID: <1643792907.85.0.286906427988.issue46608@roundup.psfhosted.org>


New submission from Kumar Aditya <rahuladitya303 at gmail.com>:

This reduces the size of the data segment by 300 KB of the executable because if the modules are deep-frozen then the marshalled frozen data just wastes space. This was inspired by comment by @gvanrossum in #29118 (comment). Note: There is a new option `--deepfreeze-only` in freeze_modules.py to change this behavior, it is on be default to save disk space.

# du -s ./python before
27892   ./python
# du -s ./python after
27524   ./python

----------
components: Build
messages: 412346
nosy: gvanrossum, kumaraditya303
priority: normal
severity: normal
status: open
title: Exclude marshalled-frozen data if deep-freezing to save 300 KB space
versions: Python 3.11

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

From report at bugs.python.org  Wed Feb  2 04:08:50 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Wed, 02 Feb 2022 09:08:50 +0000
Subject: [issue46608] Exclude marshalled-frozen data if deep-freezing to save
 300 KB space
In-Reply-To: <1643792907.85.0.286906427988.issue46608@roundup.psfhosted.org>
Message-ID: <1643792930.99.0.310969226603.issue46608@roundup.psfhosted.org>


Change by Kumar Aditya <rahuladitya303 at gmail.com>:


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

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

From report at bugs.python.org  Wed Feb  2 04:30:54 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Wed, 02 Feb 2022 09:30:54 +0000
Subject: [issue46597] Remove Python 3.3 compatibility code from overlapped.c
In-Reply-To: <1643712263.04.0.804521209967.issue46597@roundup.psfhosted.org>
Message-ID: <1643794254.78.0.0325814339848.issue46597@roundup.psfhosted.org>


Change by Kumar Aditya <rahuladitya303 at gmail.com>:


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

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

From report at bugs.python.org  Wed Feb  2 05:02:47 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 02 Feb 2022 10:02:47 +0000
Subject: [issue46607] Add DeprecationWarning to configparser's
 LegacyInterpolation
In-Reply-To: <1643785269.24.0.226402381238.issue46607@roundup.psfhosted.org>
Message-ID: <1643796167.3.0.718448057372.issue46607@roundup.psfhosted.org>


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

Oh, LegacyInterpolation is not documented at:
https://docs.python.org/dev/library/configparser.html

> Other configparser deprecations were added in 3.2, but with DeprecationWarnings.

Its deprecation was never documented anywhere in Doc/.

Well, to respect the PEP 387, the class should emit a DeprecationWarning and its depreaction must be documented in What's New in Python 3.11.


> The LegacyInterpolation class of configparser has been deprecated in docs since 3.2, but without raising a DeprecationWarning.

I found the following change:
---
commit 7f64c8a5121576fd8f92010b7a936b89581c4051
Author: ?ukasz Langa <lukasz at langa.pl>
Date:   Thu Dec 16 01:16:22 2010 +0000

    Broken ConfigParser removed, SafeConfigParser renamed to ConfigParser.
    Life is beatiful once again.
---

It renamed BrokenInterpolation to LegacyInterpolation:

-class BrokenInterpolation(Interpolation):
-    """Deprecated interpolation as implemented in the classic ConfigParser.
+class LegacyInterpolation(Interpolation):
+    """Deprecated interpolation used in old versions of ConfigParser.


The BrokenInterpolation class was added  by bpo-10499:
---
commit b6a6f5f886ed869612e16cd1e29a1190996dc78d
Author: ?ukasz Langa <lukasz at langa.pl>
Date:   Fri Dec 3 16:28:00 2010 +0000

    Issue 10499: Modular interpolation in configparser
---

It would be nice to have ?ukasz's opinion on deprecating LegacyInterpolation.


The configparser.RawConfigParser has an "interpolation" parameter and configparser.RawConfigParser._DEFAULT_INTERPOLATION is an instance of configparser.Interpolation:
---
    # Interpolation algorithm to be used if the user does not specify another        
    _DEFAULT_INTERPOLATION = Interpolation()                                       
---


If the BrokenInterpolation is removed in Python 3.13 and a project is affected by the removal, can it simply copy/paste the Python 3.12 copy in its project and continue using the class? configparser.Interpolation seems to be a clean ABC class, so it seems safe to copy/paste the code. It doesn't seem to depend on anything but configparser.Interpolation which is public (even if it's not documented).


https://bugs.python.org/issue45173#msg409685:
> Searching 4,764 sdists from the top 5,000 PyPI packages, these 13 contain "LegacyInterpolation": (...)
> two are stdlib backports: (...)
> The others are all configparser.pyi typeshed stub files: (...)

I understand that *in practice*, removing the class would impact no project of the top 5000 PyPI projects. Thanks for checking!

----------
nosy: +lukasz.langa, vstinner

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

From report at bugs.python.org  Wed Feb  2 05:04:49 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 02 Feb 2022 10:04:49 +0000
Subject: [issue46600] Python built with clang -O0 allocates 10x more stack
 memory than clang -O3 on a Python function call
In-Reply-To: <1643720760.9.0.302596428689.issue46600@roundup.psfhosted.org>
Message-ID: <1643796289.36.0.539892675621.issue46600@roundup.psfhosted.org>


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

> For example, see _Py_abspath

For functions which are commonly called in Python at runtime, it may be worth it to manually merged large local variables to save a few bytes on the stack when Python is built with -O0. For _Py_abspath(), this function is only called at startup, if I recall correctly, so it should be a big issue in practice.

----------

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

From report at bugs.python.org  Wed Feb  2 05:11:32 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 02 Feb 2022 10:11:32 +0000
Subject: [issue44359] test_ftplib.test_makeport() fails as "env changes" if a
 socket operation times out in a thread: TimeoutError is not catched
In-Reply-To: <1623225511.63.0.739788412824.issue44359@roundup.psfhosted.org>
Message-ID: <1643796692.04.0.420727604644.issue44359@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/issue44359>
_______________________________________

From report at bugs.python.org  Wed Feb  2 05:11:45 2022
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 02 Feb 2022 10:11:45 +0000
Subject: [issue46573] Python modules such as pyglet or pygame crash Python
 when tkinter message boxes are opened on MacOS.
In-Reply-To: <1643482093.87.0.31269168021.issue46573@roundup.psfhosted.org>
Message-ID: <1643796705.69.0.625208248977.issue46573@roundup.psfhosted.org>


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

I've done some more research and this is an integration issue between pyglet and Tk. In particular:

* Both pyglet and Tk use AppKit to implement their GUI
* AppKit uses an NSApplication class, and in particular a singleton instance of that class, to represent the application, which will get instantiated during application startup
* The Tk library uses a sublclass of NSApplication with additional functionality (TkApplication).
* When pyglet is started first the NSApplication singleton is an instance of NSApplication and not of TkApplication, but Tk's implementation assumes that the singleton is an instance of TkApplicationo.

A workaround for this issue is to make sure Tk is initialised before initialising pyglet. For example using this code at the start of the script: "from tkinter import Tk; root = Tk()"


There's not much we can do about this in CPython, other than maybe filing an issue with the Tk project about this. I haven't looked at the Tk codebase and there cannot tell how hard it would be for then to avoid a dependency on TkApplication as a separate class (for example by implementing the additional functionality they need in a category on NSApplication).

----------
resolution:  -> third party
stage:  -> resolved
status: open -> pending

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

From report at bugs.python.org  Wed Feb  2 06:02:00 2022
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 02 Feb 2022 11:02:00 +0000
Subject: [issue46072] Unify handling of stats in the CPython VM
In-Reply-To: <1639498673.65.0.709719181358.issue46072@roundup.psfhosted.org>
Message-ID: <1643799720.67.0.754810224993.issue46072@roundup.psfhosted.org>


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


New changeset 187930f74c44e460ba09c60ba5d9bb4fac543d8f by Mark Shannon in branch 'main':
bpo-46072: Add some frame stats. (GH-31060)
https://github.com/python/cpython/commit/187930f74c44e460ba09c60ba5d9bb4fac543d8f


----------

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

From report at bugs.python.org  Wed Feb  2 07:05:32 2022
From: report at bugs.python.org (PySimpleGUI)
Date: Wed, 02 Feb 2022 12:05:32 +0000
Subject: [issue46180] Button clicked failed when mouse hover tooltip and
 tooltip destroyed
In-Reply-To: <1640515148.68.0.766649384181.issue46180@roundup.psfhosted.org>
Message-ID: <1643803532.64.0.215599256209.issue46180@roundup.psfhosted.org>


PySimpleGUI <PySimpleGUI at PySimpleGUI.com> added the comment:

I'll do some Linux testing today to see if I can replicate it.

There was another problem reported that only on 8.6.12 on Mac (sorry, don't mean to muddy the waters by mentioning it).  The reason I bring it up is that I've not seen a tkinter release have these specific kinds of problems in a very long time and am wondering if something was changed internally that could have an impact on this problem.

I'll report back with what I find on Linux. Thank you SO much for giving this problem some attention.

----------

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

From report at bugs.python.org  Wed Feb  2 07:27:05 2022
From: report at bugs.python.org (Sebastian Rittau)
Date: Wed, 02 Feb 2022 12:27:05 +0000
Subject: [issue46609] Generator-based coroutines in Python 3.10 docs
Message-ID: <1643804825.5.0.310548487717.issue46609@roundup.psfhosted.org>


New submission from Sebastian Rittau <srittau at rittau.biz>:

Currently, the Python 3.10.2 documentation at https://docs.python.org/3/library/asyncio-task.html?highlight=coroutine#asyncio.coroutine says:

"Note: Support for generator-based coroutines is deprecated and is scheduled for removal in Python 3.10."

Python 3.10 still has support for those (although it emits a warning), so the note should be updated.

----------
assignee: docs at python
components: Documentation
messages: 412352
nosy: docs at python, srittau
priority: normal
severity: normal
status: open
title: Generator-based coroutines in Python 3.10 docs
versions: Python 3.10

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

From report at bugs.python.org  Wed Feb  2 07:38:49 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Feb 2022 12:38:49 +0000
Subject: [issue43012] Remove pathlib accessors
In-Reply-To: <1611425755.47.0.494853383169.issue43012@roundup.psfhosted.org>
Message-ID: <1643805529.75.0.283990742289.issue43012@roundup.psfhosted.org>


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


New changeset 08f8301b21648d58d053e1a513db8ed32fbf37dd by Barney Gale in branch 'main':
bpo-43012: remove `pathlib._Accessor` (GH-25701)
https://github.com/python/cpython/commit/08f8301b21648d58d053e1a513db8ed32fbf37dd


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

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

From report at bugs.python.org  Wed Feb  2 07:38:49 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Feb 2022 12:38:49 +0000
Subject: [issue24132] Direct sub-classing of pathlib.Path
In-Reply-To: <1430890013.04.0.304568332905.issue24132@psf.upfronthosting.co.za>
Message-ID: <1643805529.86.0.51037612142.issue24132@roundup.psfhosted.org>


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


New changeset 08f8301b21648d58d053e1a513db8ed32fbf37dd by Barney Gale in branch 'main':
bpo-43012: remove `pathlib._Accessor` (GH-25701)
https://github.com/python/cpython/commit/08f8301b21648d58d053e1a513db8ed32fbf37dd


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

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

From report at bugs.python.org  Wed Feb  2 08:09:50 2022
From: report at bugs.python.org (Julien Palard)
Date: Wed, 02 Feb 2022 13:09:50 +0000
Subject: [issue42238] Deprecate suspicious.py?
In-Reply-To: <1604274563.95.0.828690163802.issue42238@roundup.psfhosted.org>
Message-ID: <1643807390.63.0.428233834737.issue42238@roundup.psfhosted.org>


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

OK, we have: https://github.com/sphinx-contrib/sphinx-lint

Ping me if you want rights :)

----------

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

From report at bugs.python.org  Wed Feb  2 08:19:38 2022
From: report at bugs.python.org (Can)
Date: Wed, 02 Feb 2022 13:19:38 +0000
Subject: [issue46610] assertCountEqual doesn't work as expected for dictionary
 elements
Message-ID: <1643807978.22.0.824288315103.issue46610@roundup.psfhosted.org>


Change by Can <ertugrulsarigol at gmail.com>:


----------
nosy: cansarigol
priority: normal
severity: normal
status: open
title: assertCountEqual doesn't work as expected for dictionary elements
type: behavior

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

From report at bugs.python.org  Wed Feb  2 08:22:45 2022
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 02 Feb 2022 13:22:45 +0000
Subject: [issue45703] importlib.invalidate_caches() does not invalidate
 _NamespacePath's _last_parent_path-based cache
In-Reply-To: <1635938516.86.0.42328943914.issue45703@roundup.psfhosted.org>
Message-ID: <1643808165.83.0.713853988496.issue45703@roundup.psfhosted.org>


Change by Petr Viktorin <encukou at gmail.com>:


----------
pull_requests: +29260
pull_request: https://github.com/python/cpython/pull/31076

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

From report at bugs.python.org  Wed Feb  2 08:36:15 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Wed, 02 Feb 2022 13:36:15 +0000
Subject: [issue46610] assertCountEqual doesn't work as expected for dictionary
 elements
Message-ID: <1643808975.15.0.46322422431.issue46610@roundup.psfhosted.org>


New submission from Nikita Sobolev <mail at sobolevn.me>:

@cansarigol, can you please specify what do you expect and how it works?

----------
nosy: +sobolevn

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

From report at bugs.python.org  Wed Feb  2 08:36:27 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Wed, 02 Feb 2022 13:36:27 +0000
Subject: [issue46610] assertCountEqual doesn't work as expected for dictionary
 elements
In-Reply-To: <1643808975.15.0.46322422431.issue46610@roundup.psfhosted.org>
Message-ID: <1643808987.42.0.99630244259.issue46610@roundup.psfhosted.org>


Change by Nikita Sobolev <mail at sobolevn.me>:


----------
components: +Library (Lib)
versions: +Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Wed Feb  2 08:42:16 2022
From: report at bugs.python.org (Can)
Date: Wed, 02 Feb 2022 13:42:16 +0000
Subject: [issue46610] assertCountEqual doesn't work as expected for dictionary
 elements
In-Reply-To: <1643808975.15.0.46322422431.issue46610@roundup.psfhosted.org>
Message-ID: <1643809336.31.0.258765852426.issue46610@roundup.psfhosted.org>


Change by Can <ertugrulsarigol at gmail.com>:


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

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

From report at bugs.python.org  Wed Feb  2 08:45:42 2022
From: report at bugs.python.org (=?utf-8?q?Tin_Tvrtkovi=C4=87?=)
Date: Wed, 02 Feb 2022 13:45:42 +0000
Subject: [issue46200] Discourage logging f-strings due to security
 considerations
In-Reply-To: <1640850255.25.0.496981368409.issue46200@roundup.psfhosted.org>
Message-ID: <1643809542.34.0.380663251908.issue46200@roundup.psfhosted.org>


Tin Tvrtkovi? <tinchester at gmail.com> added the comment:

Eric is absolutely right, due to function calls being somewhat slow in Python the performance argument in practice falls in favor of f-strings.

So if they're faster, more readable, and more convenient to write, no wonder people prefer them (including me).

The overload approach is intriguing.

----------
nosy: +tinchester

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

From report at bugs.python.org  Wed Feb  2 08:47:26 2022
From: report at bugs.python.org (Steve Dower)
Date: Wed, 02 Feb 2022 13:47:26 +0000
Subject: [issue46594] Windows "Edit with IDLE >" only has one selection
In-Reply-To: <1643759292.98.0.904950273359.issue46594@roundup.psfhosted.org>
Message-ID: <ac68e604-675f-6d90-cc4f-76a1ac0b5a48@python.org>


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

True. I guess we need to dig a little deeper to find a cause here. Any 
other ideas?

----------

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

From report at bugs.python.org  Wed Feb  2 08:50:55 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Feb 2022 13:50:55 +0000
Subject: [issue45703] importlib.invalidate_caches() does not invalidate
 _NamespacePath's _last_parent_path-based cache
In-Reply-To: <1635938516.86.0.42328943914.issue45703@roundup.psfhosted.org>
Message-ID: <1643809855.0.0.0903949363924.issue45703@roundup.psfhosted.org>


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


New changeset 8d239bfdcc98f4e4a592d9cda569380a9c15a5c0 by Petr Viktorin in branch '3.9':
[3.9] bpo-45703: Invalidate _NamespacePath cache on importlib.invalidate_cache (GH-29384) (GH-30922) (GH-31076)
https://github.com/python/cpython/commit/8d239bfdcc98f4e4a592d9cda569380a9c15a5c0


----------

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

From report at bugs.python.org  Wed Feb  2 08:54:50 2022
From: report at bugs.python.org (John Belmonte)
Date: Wed, 02 Feb 2022 13:54:50 +0000
Subject: [issue45995] string formatting: normalize negative zero
In-Reply-To: <1638792226.95.0.292604366656.issue45995@roundup.psfhosted.org>
Message-ID: <1643810090.87.0.420734966398.issue45995@roundup.psfhosted.org>


John Belmonte <john at neggie.net> added the comment:

PEP at https://github.com/python/peps/pull/2295

----------

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

From report at bugs.python.org  Wed Feb  2 09:00:52 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Wed, 02 Feb 2022 14:00:52 +0000
Subject: [issue46611] Improve coverage of `__instancecheck__` and
 `__subclasscheck__` methods in `typing.py`
Message-ID: <1643810452.7.0.438267754834.issue46611@roundup.psfhosted.org>


New submission from Nikita Sobolev <mail at sobolevn.me>:

There are several problem reported by coverage:
1. This line is never reached in `_SpecialGenericAlias.__subclasscheck__`: https://github.com/python/cpython/blob/08f8301b21648d58d053e1a513db8ed32fbf37dd/Lib/typing.py#L1140
2. `__instancecheck__` and `__subclasscheck__` for `_UnionGenericAlias` are not covered at all: https://github.com/python/cpython/blob/08f8301b21648d58d053e1a513db8ed32fbf37dd/Lib/typing.py#L1243-L1249 I suspect this happened because of `types.UnionType` / `typing.Union` duality

I am going to add these today! 

By the way, this is the last coverage issue in typing! ?

----------
components: Library (Lib)
messages: 412361
nosy: sobolevn
priority: normal
severity: normal
status: open
title: Improve coverage of `__instancecheck__` and `__subclasscheck__` methods in `typing.py`
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Wed Feb  2 09:01:12 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Wed, 02 Feb 2022 14:01:12 +0000
Subject: [issue46611] Improve coverage of `__instancecheck__` and
 `__subclasscheck__` methods in `typing.py`
In-Reply-To: <1643810452.7.0.438267754834.issue46611@roundup.psfhosted.org>
Message-ID: <1643810472.4.0.0643145858932.issue46611@roundup.psfhosted.org>


Change by Nikita Sobolev <mail at sobolevn.me>:


----------
nosy: +AlexWaygood, gvanrossum, kj

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

From report at bugs.python.org  Wed Feb  2 09:04:41 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Wed, 02 Feb 2022 14:04:41 +0000
Subject: [issue46611] Improve coverage of `__instancecheck__` and
 `__subclasscheck__` methods in `typing.py`
In-Reply-To: <1643810452.7.0.438267754834.issue46611@roundup.psfhosted.org>
Message-ID: <1643810681.08.0.377563736679.issue46611@roundup.psfhosted.org>


Change by Nikita Sobolev <mail at sobolevn.me>:


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

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

From report at bugs.python.org  Wed Feb  2 09:04:32 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 02 Feb 2022 14:04:32 +0000
Subject: [issue46610] assertCountEqual doesn't work as expected for dictionary
 elements
In-Reply-To: <1643808975.15.0.46322422431.issue46610@roundup.psfhosted.org>
Message-ID: <1643810672.35.0.420296978045.issue46610@roundup.psfhosted.org>


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

The PR changes the meaning of assertCountEqual. https://docs.python.org/3/library/unittest.html#unittest.TestCase.assertCountEqual says: Equivalent to: assertEqual(Counter(list(first)), Counter(list(second))) ...

At the very least, the documentation would need to be updated. But since this could be a breaking change, I don't think it will be accepted.

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

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

From report at bugs.python.org  Wed Feb  2 09:12:06 2022
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 02 Feb 2022 14:12:06 +0000
Subject: [issue45703] importlib.invalidate_caches() does not invalidate
 _NamespacePath's _last_parent_path-based cache
In-Reply-To: <1635938516.86.0.42328943914.issue45703@roundup.psfhosted.org>
Message-ID: <1643811126.31.0.139217699132.issue45703@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/issue45703>
_______________________________________

From report at bugs.python.org  Wed Feb  2 09:23:01 2022
From: report at bugs.python.org (Can)
Date: Wed, 02 Feb 2022 14:23:01 +0000
Subject: [issue46610] assertCountEqual doesn't work as expected for dictionary
 elements
In-Reply-To: <1643808975.15.0.46322422431.issue46610@roundup.psfhosted.org>
Message-ID: <1643811781.23.0.810673264539.issue46610@roundup.psfhosted.org>


Can <ertugrulsarigol at gmail.com> added the comment:

@sobolevn I was expecting the following test case to be covered.

self.assertRaises(self.failureException, self.assertCountEqual,
                          {'a': 1}, {'a': 2})

what I understand from the doc of the assertion is that elements have to be the same without regard to order. The doc can be extended for dict.

In [10]: d = {"key": "value"}

In [11]: collections.Counter(list(d))
Out[11]: Counter({'key': 1})

In [12]: collections.Counter(d.items())
Out[12]: Counter({('key', 'value'): 1})

----------

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

From report at bugs.python.org  Wed Feb  2 09:55:08 2022
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 02 Feb 2022 14:55:08 +0000
Subject: [issue46072] Unify handling of stats in the CPython VM
In-Reply-To: <1639498673.65.0.709719181358.issue46072@roundup.psfhosted.org>
Message-ID: <1643813708.55.0.0714464750926.issue46072@roundup.psfhosted.org>


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


----------
pull_requests: +29263
pull_request: https://github.com/python/cpython/pull/31079

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

From report at bugs.python.org  Wed Feb  2 10:03:18 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Feb 2022 15:03:18 +0000
Subject: [issue45459] Limited API support for Py_buffer
In-Reply-To: <1634118913.79.0.141868262007.issue45459@roundup.psfhosted.org>
Message-ID: <1643814198.63.0.937703661205.issue45459@roundup.psfhosted.org>


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


New changeset f66c857572a308822c70fd25e0197b6e0dec6e34 by Christian Heimes in branch 'main':
 bpo-45459: Add Py_buffer to limited API (GH-29991)
https://github.com/python/cpython/commit/f66c857572a308822c70fd25e0197b6e0dec6e34


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

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

From report at bugs.python.org  Wed Feb  2 10:06:11 2022
From: report at bugs.python.org (Marek Scholle)
Date: Wed, 02 Feb 2022 15:06:11 +0000
Subject: [issue46612] Unclear behavior of += operator
Message-ID: <1643814371.03.0.343657653727.issue46612@roundup.psfhosted.org>


New submission from Marek Scholle <mscholle at purestorage.com>:

Hi, I ran into discussion about scoping in Python (visibility of outer variables in nested functions, global, nonlocal) which made me to create for other some showcases.

I realized there is a space for ambiguity which I extracted to this REPL:

----
>>> x = []
>>> def f(): x += [1]
...
>>> f()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 1, in f
UnboundLocalError: local variable 'x' referenced before assignment
>>> x = []
>>> def f(): x.append(1)
...
>>> f()
>>> x
[1]
----

The documentation says about `x += [1]` it is "translated" to `x.__iadd__([1])`. It would be interesting to know if Python actually documents that `x += [1]` will err with `UnboundLocalError`.

I think there is a natural argument that `x += <rhs>` should behave as an in-place version of `x = x + <rhs>` (where `UnboundLocalError` makes perfect sense), but diving into documentation it seems that `x += <rhs>` should be a syntax sugar for `x.__iadd__(rhs)` in which case `UnboundLocalError` should not happen and looks like some parser artifact.

----------
components: Interpreter Core
messages: 412365
nosy: mscholle
priority: normal
severity: normal
status: open
title: Unclear behavior of += operator
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Wed Feb  2 10:19:26 2022
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 02 Feb 2022 15:19:26 +0000
Subject: [issue46612] Unclear behavior of += operator
In-Reply-To: <1643814371.03.0.343657653727.issue46612@roundup.psfhosted.org>
Message-ID: <1643815166.25.0.814670120421.issue46612@roundup.psfhosted.org>


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

You say: "The documentation says ..." but don't tell us which documentation.

This documentation:

https://docs.python.org/3/reference/simple_stmts.html#augmented-assignment-statements


tells us that augmented assignment is assignment:

"An augmented assignment evaluates the target (which, unlike normal assignment statements, cannot be an unpacking) and the expression list, performs the binary operation specific to the type of assignment on the two operands, and assigns the result to the original target."

And also: "the assignment done by augmented assignment statements is handled the same way as normal assignments."

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

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

From report at bugs.python.org  Wed Feb  2 10:33:10 2022
From: report at bugs.python.org (Marek Scholle)
Date: Wed, 02 Feb 2022 15:33:10 +0000
Subject: [issue46612] Unclear behavior of += operator
In-Reply-To: <1643814371.03.0.343657653727.issue46612@roundup.psfhosted.org>
Message-ID: <1643815990.65.0.6624312354.issue46612@roundup.psfhosted.org>


Marek Scholle <mscholle at purestorage.com> added the comment:

Thanks for pointing to reference https://docs.python.org/3/reference/simple_stmts.html#augmented-assignment-statements

Although I can agree it tries to point to similarity with `x = x + 1`, it says about how `x += [1]` is processed:

(1) evaluate the target (`x`)
(2) evaluate the expression list (`[1]`)
(3) call `+=`, which I understand dispatch `x.__iadd__([1])`

I see there is no space left for `UnboundLocalError`.

> The assignment done by augmented assignment statements is handled the same way as normal assignments.

This is not a technical claim. They are not the same, and to claim "they are handled the same way" is strictly speaking an empty statement. For which definition of "same way"?

----------

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

From report at bugs.python.org  Wed Feb  2 10:37:05 2022
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 02 Feb 2022 15:37:05 +0000
Subject: [issue43012] Remove pathlib accessors
In-Reply-To: <1611425755.47.0.494853383169.issue43012@roundup.psfhosted.org>
Message-ID: <1643816225.07.0.285413446723.issue43012@roundup.psfhosted.org>


Change by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +petr.viktorin
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Wed Feb  2 10:46:38 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 02 Feb 2022 15:46:38 +0000
Subject: [issue46610] assertCountEqual doesn't work as expected for dictionary
 elements
In-Reply-To: <1643808975.15.0.46322422431.issue46610@roundup.psfhosted.org>
Message-ID: <1643816798.77.0.230602276041.issue46610@roundup.psfhosted.org>


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

I agree with Eric that this should not be changed.  It is working as documented and intended.

In its original incarenation, assertCountEqual was documented as being equivalent to ``assertEqual(sorted(expected), sorted(actual))``.  Either way, the goal was to count the values produced by iterating.

To compare two dicts or two Counters including both keys and values, just use assertEqual.

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

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

From report at bugs.python.org  Wed Feb  2 10:49:53 2022
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 02 Feb 2022 15:49:53 +0000
Subject: [issue45459] Limited API support for Py_buffer
In-Reply-To: <1634118913.79.0.141868262007.issue45459@roundup.psfhosted.org>
Message-ID: <1643816993.97.0.881512399265.issue45459@roundup.psfhosted.org>


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

Thanks for the review, Petr!

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

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

From report at bugs.python.org  Wed Feb  2 10:57:56 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Feb 2022 15:57:56 +0000
Subject: [issue46433] _PyType_GetModuleByDef optimization is incorrect
In-Reply-To: <1642607197.61.0.0970144809853.issue46433@roundup.psfhosted.org>
Message-ID: <1643817476.34.0.5144193657.issue46433@roundup.psfhosted.org>


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


New changeset 0ef08530124c5ca13a9394f4ac18bee8e6c66409 by Petr Viktorin in branch 'main':
bpo-46433: _PyType_GetModuleByDef: handle static types in MRO (GH-30696)
https://github.com/python/cpython/commit/0ef08530124c5ca13a9394f4ac18bee8e6c66409


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

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

From report at bugs.python.org  Wed Feb  2 11:09:04 2022
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 02 Feb 2022 16:09:04 +0000
Subject: [issue46550] __slots__ updates despite being read-only
In-Reply-To: <1643295332.29.0.0186682990953.issue46550@roundup.psfhosted.org>
Message-ID: <1643818144.53.0.628267606357.issue46550@roundup.psfhosted.org>


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

W.r.t. augmented assignments, this is a good blog post about how they work under the hood: https://snarky.ca/unravelling-augmented-arithmetic-assignment/

----------

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

From report at bugs.python.org  Wed Feb  2 11:23:35 2022
From: report at bugs.python.org (E:V:A)
Date: Wed, 02 Feb 2022 16:23:35 +0000
Subject: [issue45870] There's no readline module on Windows Python (cmd.Cmd)
In-Reply-To: <1637589082.36.0.67630471216.issue45870@roundup.psfhosted.org>
Message-ID: <1643819015.57.0.694444248171.issue45870@roundup.psfhosted.org>


E:V:A <xdae3v3a at gmail.com> added the comment:

I would like to make the python community aware that there has recently been a renewed interest in updating and maintaining 'pyreadline', but in a new(ish) repository 'pyreadline3'. 

https://github.com/pyreadline3/pyreadline3

This apparently now works under Py3.10, but there are some minor issues with how pyreadline handles ANSI escape sequences for coloring auto completion etc. This is probably due to the code developed for the older/original Windows cmd/powershell use of 4-bit ANSI colors, no longer being able to handle 256 or RGB. There was a PR for that, but because that PR is aged it seem limited to older 4-bit ANSI's, since it is using a RegEx for stripping the sequences to calculate the actual line length.

[OT. This also bring up the question where the function "rl_expand_prompt()" (handling RL_PROMPT_START_IGNORE and RL_PROMPT_END_IGNORE) was moved, as it can't be found in the cpython codebase. (https://github.com/python/cpython/blob/main/Modules/readline.c) The equivalent HEX for those _does_ work, at least for the prompt, but maybe they are handled on the windows side?]

----------
nosy: +E3V3A

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

From report at bugs.python.org  Wed Feb  2 11:23:46 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Feb 2022 16:23:46 +0000
Subject: [issue37705] winerror_to_errno implementation
In-Reply-To: <1564407660.89.0.454912973453.issue37705@roundup.psfhosted.org>
Message-ID: <1643819026.67.0.588092299938.issue37705@roundup.psfhosted.org>


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


New changeset 38e0b9efdf164be656782db0f969fb536cfbcaf1 by Oleg Iarygin in branch 'main':
bpo-37705: Remove orphaned PC/errmap.mak (GH-29724)
https://github.com/python/cpython/commit/38e0b9efdf164be656782db0f969fb536cfbcaf1


----------

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

From report at bugs.python.org  Wed Feb  2 11:38:45 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 02 Feb 2022 16:38:45 +0000
Subject: [issue46612] Unclear behavior of += operator
In-Reply-To: <1643814371.03.0.343657653727.issue46612@roundup.psfhosted.org>
Message-ID: <1643819925.71.0.298960918844.issue46612@roundup.psfhosted.org>


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

The "evaluate the target" part causes the UnboundLocalError, just as in:

>>> x=1
>>> def f():
...   x
...   x = x + 1
... 
>>> f()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in f
UnboundLocalError: local variable 'x' referenced before assignment

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

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

From report at bugs.python.org  Wed Feb  2 11:40:06 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 02 Feb 2022 16:40:06 +0000
Subject: [issue46608] Exclude marshalled-frozen data if deep-freezing to save
 300 KB space
In-Reply-To: <1643792907.85.0.286906427988.issue46608@roundup.psfhosted.org>
Message-ID: <1643820006.29.0.670098364503.issue46608@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


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

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

From report at bugs.python.org  Wed Feb  2 11:49:00 2022
From: report at bugs.python.org (Marek Scholle)
Date: Wed, 02 Feb 2022 16:49:00 +0000
Subject: [issue46612] Unclear behavior of += operator
In-Reply-To: <1643814371.03.0.343657653727.issue46612@roundup.psfhosted.org>
Message-ID: <1643820540.44.0.818915267125.issue46612@roundup.psfhosted.org>


Marek Scholle <mscholle at purestorage.com> added the comment:

I don't understand the comment https://bugs.python.org/issue46612#msg412374

----
>>> def f(): x
...
>>> f()
----
is OK, so x is something which can be evaluated inside nested function, it is a good target to be used in `x.__iadd__(iterable)`.

That 
----
>>> def f(): x = x + 1
...
>>> f()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 1, in f
UnboundLocalError: local variable 'x' referenced before assignment
----
is OK, the interpreter sees `x` as local variable (by default inner scope variables shadow those from outer scopes), hence the `UnboundLocalError`

----------

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

From report at bugs.python.org  Wed Feb  2 11:52:20 2022
From: report at bugs.python.org (paul j3)
Date: Wed, 02 Feb 2022 16:52:20 +0000
Subject: [issue46440] ArgumentParser.parse_args exits on missing required
 argument with exit_on_error=False
In-Reply-To: <1642626270.03.0.621125172575.issue46440@roundup.psfhosted.org>
Message-ID: <1643820740.8.0.489010609159.issue46440@roundup.psfhosted.org>


paul j3 <ajipanca at gmail.com> added the comment:

Duplicate of https://bugs.python.org/issue41255

Argparse.parse_args exits on unrecognized option with exit_on_error=False

----------
nosy: +paul.j3
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Wed Feb  2 11:53:04 2022
From: report at bugs.python.org (Julien Palard)
Date: Wed, 02 Feb 2022 16:53:04 +0000
Subject: [issue42238] Deprecate suspicious.py?
In-Reply-To: <1604274563.95.0.828690163802.issue42238@roundup.psfhosted.org>
Message-ID: <1643820784.5.0.243962243658.issue42238@roundup.psfhosted.org>


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

Georg, I was able to move forward:

- https://github.com/sphinx-contrib/sphinx-lint
- https://pypi.org/project/sphinx-lint/

Does everything looks good to you?

Next step would be to remove rstlint.py from Docs/tools and add a dependency to rstlint from the Makefile (for make check), so the CI uses sphinx-lint.

----------

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

From report at bugs.python.org  Wed Feb  2 11:53:48 2022
From: report at bugs.python.org (paul j3)
Date: Wed, 02 Feb 2022 16:53:48 +0000
Subject: [issue46080] argparse.BooleanOptionalAction with
 default=argparse.SUPPRESS and help specified raises exception
In-Reply-To: <1639549771.77.0.946249381009.issue46080@roundup.psfhosted.org>
Message-ID: <1643820828.66.0.139844721081.issue46080@roundup.psfhosted.org>


Change by paul j3 <ajipanca at gmail.com>:


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

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

From report at bugs.python.org  Wed Feb  2 11:55:22 2022
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 02 Feb 2022 16:55:22 +0000
Subject: [issue46613] Add PyType_GetModuleByDef to the public & limited API
Message-ID: <1643820922.83.0.000906972876287.issue46613@roundup.psfhosted.org>


New submission from Petr Viktorin <encukou at gmail.com>:

_PyType_GetModuleByDef (added in bpo-42100)allows module state access 
from slot methods (like tp_init or nb_add),
the main thing missing from PEP 573 (Module State Access from C 
Extension Methods).
It's time to make it public.

The function itself can be implemented using only limited API, though 
it's a bit tricky to do so correctly (and our implementation uses 
private speedups), so it's better if extension authors can use it as a 
pre-made building block.

Discussed in: https://mail.python.org/archives/list/capi-sig at python.org/thread/WMSDNMQ7A6LE6X4MQW4QAQUKDDL7MJ72/
Note that a bug was found in the CPython optimization recently: bpo-46433

----------
components: C API
messages: 412378
nosy: petr.viktorin
priority: normal
severity: normal
status: open
title: Add PyType_GetModuleByDef to the public & limited API
versions: Python 3.11

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

From report at bugs.python.org  Wed Feb  2 11:56:04 2022
From: report at bugs.python.org (paul j3)
Date: Wed, 02 Feb 2022 16:56:04 +0000
Subject: [issue46101] argparse: using parents & subcommands,
 options can be ignored
In-Reply-To: <1639668546.2.0.488904720024.issue46101@roundup.psfhosted.org>
Message-ID: <1643820964.11.0.28517248388.issue46101@roundup.psfhosted.org>


Change by paul j3 <ajipanca at gmail.com>:


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

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

From report at bugs.python.org  Wed Feb  2 11:56:39 2022
From: report at bugs.python.org (paul j3)
Date: Wed, 02 Feb 2022 16:56:39 +0000
Subject: [issue46228] argparse docs: default for prog= in ArgumentParser()
 should be basename of argv[0], not argv[0], to match behaviour
In-Reply-To: <1641153038.74.0.113301629042.issue46228@roundup.psfhosted.org>
Message-ID: <1643820999.83.0.957467491681.issue46228@roundup.psfhosted.org>


Change by paul j3 <ajipanca at gmail.com>:


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

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

From report at bugs.python.org  Wed Feb  2 11:59:47 2022
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 02 Feb 2022 16:59:47 +0000
Subject: [issue45173] Remove configparser deprecations
In-Reply-To: <1631383839.78.0.984503527213.issue45173@roundup.psfhosted.org>
Message-ID: <1643821187.66.0.894312842702.issue45173@roundup.psfhosted.org>


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


New changeset e8659b47dece5a272111c0af5e340c364a9f807b by Hugo van Kemenade in branch 'main':
bpo-45173: Keep configparser deprecations until Python 3.12 (GH-30952)
https://github.com/python/cpython/commit/e8659b47dece5a272111c0af5e340c364a9f807b


----------

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

From report at bugs.python.org  Wed Feb  2 11:59:52 2022
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Wed, 02 Feb 2022 16:59:52 +0000
Subject: [issue46612] Unclear behavior of += operator
In-Reply-To: <1643814371.03.0.343657653727.issue46612@roundup.psfhosted.org>
Message-ID: <1643821192.64.0.642221969712.issue46612@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

You've managed to write 3 messages already, without at any point mentioning what _really_ happens when you += something.

    a += b means (is closest to) a = type(a).__iadd__(a, b)

You focus all the time on __iadd__ call, disregarding that its result it assigned back to a in scope.

----------
nosy: +veky

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

From report at bugs.python.org  Wed Feb  2 12:00:44 2022
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 02 Feb 2022 17:00:44 +0000
Subject: [issue46613] Add PyType_GetModuleByDef to the public & limited API
In-Reply-To: <1643820922.83.0.000906972876287.issue46613@roundup.psfhosted.org>
Message-ID: <1643821244.63.0.669775007911.issue46613@roundup.psfhosted.org>


Change by Petr Viktorin <encukou at gmail.com>:


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

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

From report at bugs.python.org  Wed Feb  2 12:09:31 2022
From: report at bugs.python.org (Marek Scholle)
Date: Wed, 02 Feb 2022 17:09:31 +0000
Subject: [issue46612] Unclear behavior of += operator
In-Reply-To: <1643814371.03.0.343657653727.issue46612@roundup.psfhosted.org>
Message-ID: <1643821771.5.0.921560921915.issue46612@roundup.psfhosted.org>


Marek Scholle <mscholle at purestorage.com> added the comment:

> a += b means (is closest to) a = type(a).__iadd__(a, b)

I exchanged several messages, and this is all I needed!
I propose to resolve as "Not a bug"

----------

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

From report at bugs.python.org  Wed Feb  2 12:20:28 2022
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 02 Feb 2022 17:20:28 +0000
Subject: [issue42238] Deprecate suspicious.py?
In-Reply-To: <1604274563.95.0.828690163802.issue42238@roundup.psfhosted.org>
Message-ID: <1643822428.29.0.478053785763.issue42238@roundup.psfhosted.org>


Georg Brandl <georg at python.org> added the comment:

Looks good. I should have rights automatically for everything in that org.

----------

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

From report at bugs.python.org  Wed Feb  2 12:21:59 2022
From: report at bugs.python.org (Russel Webber)
Date: Wed, 02 Feb 2022 17:21:59 +0000
Subject: [issue31582] Add _pth breadcrumb to sys.path documentation
In-Reply-To: <1506401240.1.0.91731713201.issue31582@psf.upfronthosting.co.za>
Message-ID: <1643822519.68.0.883907365581.issue31582@roundup.psfhosted.org>


Change by Russel Webber <russel at computer.org>:


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

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

From report at bugs.python.org  Wed Feb  2 12:24:57 2022
From: report at bugs.python.org (Nick Drozd)
Date: Wed, 02 Feb 2022 17:24:57 +0000
Subject: [issue45975] Simplify some while-loops with walrus operator
In-Reply-To: <1638573350.23.0.80297686747.issue45975@roundup.psfhosted.org>
Message-ID: <1643822697.37.0.937139732451.issue45975@roundup.psfhosted.org>


Change by Nick Drozd <nicholasdrozd at gmail.com>:


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

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

From report at bugs.python.org  Wed Feb  2 12:31:45 2022
From: report at bugs.python.org (Hugo van Kemenade)
Date: Wed, 02 Feb 2022 17:31:45 +0000
Subject: [issue45173] Remove configparser deprecations
In-Reply-To: <1631383839.78.0.984503527213.issue45173@roundup.psfhosted.org>
Message-ID: <1643823105.39.0.0606120725418.issue45173@roundup.psfhosted.org>


Change by Hugo van Kemenade <hugovk+python at gmail.com>:


----------
pull_requests: +29268
pull_request: https://github.com/python/cpython/pull/31084

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

From report at bugs.python.org  Wed Feb  2 12:31:46 2022
From: report at bugs.python.org (Paul Ganssle)
Date: Wed, 02 Feb 2022 17:31:46 +0000
Subject: [issue46614] Add option to output UTC datetimes as "Z" in
 `.isoformat()`
Message-ID: <1643823106.57.0.535855742317.issue46614@roundup.psfhosted.org>


New submission from Paul Ganssle <bpo at m.ganssle.io>:

As part of bpo-35829, it was suggested that we add the ability to output the "Z" suffix in `isoformat()`, so that `fromisoformat()` can both be the exact functional inverse of `isoformat()` and parse datetimes with "Z" outputs. I think that that's not a particularly compelling motivation for this, but I also see plenty of examples of `datetime.utcnow().isoformat() + "Z"` out there, so it seems like this is a feature that we would want to have *anyway*, particularly if we want to deprecate and remove `utcnow`.

I've spun this off into its own issue so that we can discuss how to implement the feature. The two obvious questions I see are:

1. What do we call the option? `use_utc_designator`, `allow_Z`, `utc_as_Z`?
2. What do we consider as "UTC"? Is it anything with +00:00? Just `timezone.utc`? Anything that seems like a fixed-offset zone with 0 offset?

For example, do we want this?

>>> LON = zoneinfo.ZoneInfo("Europe/London")
>>> datetime(2022, 3, 1, tzinfo=LON).isoformat(utc_as_z=True)
2022-03-01T00:00:00Z
>>> datetime(2022, 6, 1, tzinfo=LON).isoformat(utc_as_z=True)
2022-06-01T00:00:00+01:00

Another possible definition might be if the `tzinfo` is a fixed-offset zone with offset 0:

>>> datetime.timezone.utc.utcoffset(None)
timedelta(0)
>>> zoneinfo.ZoneInfo("UTC").utcoffset(None)
timedelta(0)
>>> dateutil.tz.UTC.utcoffset(None)
timedelta(0)
>>> pytz.UTC.utcoffset(None)
timedelta(0)

The only "odd man out" is `dateutil.tz.tzfile` objects representing fixed offsets, since all `dateutil.tz.tzfile` objects return `None` when `utcoffset` or `dst` are passed `None`. This can and will be changed in future versions.

I feel like "If the offset is 00:00, use Z" is the wrong rule to use conceptually, but considering that people will be opting into this behavior, it is more likely that they will be surprised by `datetime(2022, 3, 1, tzinfo=ZoneInfo("Europe/London").isoformat(utc_as_z=True)` returning `2022-03-01T00:00:00+00:00` than alternation between `Z` and `+00:00`.

Yet another option might be to add a completely separate function, `utc_isoformat(*args, **kwargs)`, which is equivalent to (in the parlance of the other proposal) `dt.astimezone(timezone.utc).isoformat(*args, **kwargs, utc_as_z=True)`.  Basically, convert any datetime to UTC and append a Z to it. The biggest footgun there would be people using it on na?ve datetimes and not realizing that it would interpret them as system local times.

----------
assignee: p-ganssle
components: Library (Lib)
messages: 412384
nosy: belopolsky, brett.cannon, p-ganssle
priority: normal
severity: normal
stage: needs patch
status: open
title: Add option to output UTC datetimes as "Z" in `.isoformat()`
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Wed Feb  2 12:32:27 2022
From: report at bugs.python.org (Paul Ganssle)
Date: Wed, 02 Feb 2022 17:32:27 +0000
Subject: [issue35829] datetime: parse "Z" timezone suffix in fromisoformat()
In-Reply-To: <1548445007.56.0.14925163397.issue35829@roundup.psfhosted.org>
Message-ID: <1643823147.48.0.89346472828.issue35829@roundup.psfhosted.org>


Paul Ganssle <bpo at m.ganssle.io> added the comment:

I don't think it's necessary to add a feature to `isoformat()` just for the purpose of being able to add the corresponding parser, particularly when the plan is to implement a much broader ISO 8601 parser for Python 3.11 (I've done most of the implementation in C already, I can share the progress I've made, particularly if someone else wants to pick up the baton there before I get back to it).

That said, I think it's useful for `isoformat()` to be able to output UTC times as "Z", so we may as well do that as part of 3.11 anyway. I think that's a separate issue to discuss, so I've created bpo-46614 to hammer out the details.

----------
versions: +Python 3.11 -Python 3.8

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

From report at bugs.python.org  Wed Feb  2 12:41:28 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 02 Feb 2022 17:41:28 +0000
Subject: [issue46612] Unclear behavior of += operator
In-Reply-To: <1643814371.03.0.343657653727.issue46612@roundup.psfhosted.org>
Message-ID: <1643823688.35.0.883931904379.issue46612@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/issue46612>
_______________________________________

From report at bugs.python.org  Wed Feb  2 13:00:03 2022
From: report at bugs.python.org (Barney Gale)
Date: Wed, 02 Feb 2022 18:00:03 +0000
Subject: [issue24132] Direct sub-classing of pathlib.Path
In-Reply-To: <1430890013.04.0.304568332905.issue24132@psf.upfronthosting.co.za>
Message-ID: <1643824803.6.0.0778362652547.issue24132@roundup.psfhosted.org>


Change by Barney Gale <barney.gale at gmail.com>:


----------
pull_requests: +29269
pull_request: https://github.com/python/cpython/pull/31085

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

From report at bugs.python.org  Wed Feb  2 13:01:22 2022
From: report at bugs.python.org (Dennis Sweeney)
Date: Wed, 02 Feb 2022 18:01:22 +0000
Subject: [issue46615] Segfault in set intersection (&) and difference (-)
Message-ID: <1643824882.75.0.278611227582.issue46615@roundup.psfhosted.org>


New submission from Dennis Sweeney <sweeney.dennis650 at gmail.com>:

Maybe related to https://bugs.python.org/issue8420

Somewhat obscure, but using only standard Python, and no frame- or gc-hacks, it looks like we can get a use-after-free:

from random import random

BADNESS = 0.0

class Bad:
    def __eq__(self, other):
        if random() < BADNESS:
            set1.clear()
        if random() < BADNESS:
            set2.clear()
        return True
    def __hash__(self):
        return 42

SIZE = 100
TRIALS = 10_000

ops = [
    "|", "|=",
    "==", "!=",
    "<", "<=",
    ">", ">=",
    # "&",  # crash!
    # "&=", # crash!
    "^",
    # "^=", # crash
    # "-", # crash
    "-=",
]

for op in ops:
    stmt = f"set1 {op} set2"
    print(stmt, "...")
    for _ in range(TRIALS):
        BADNESS = 0.00
        set1 = {Bad() for _ in range(SIZE)}
        set2 = {Bad() for _ in range(SIZE)}
        BADNESS = 0.02
        exec(stmt)
    print("ok.")

----------
components: Interpreter Core
messages: 412386
nosy: Dennis Sweeney, rhettinger
priority: normal
severity: normal
status: open
title: Segfault in set intersection (&) and difference (-)
type: crash
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Wed Feb  2 13:12:23 2022
From: report at bugs.python.org (Dennis Sweeney)
Date: Wed, 02 Feb 2022 18:12:23 +0000
Subject: [issue46615] Segfault in set intersection (&) and difference (-)
In-Reply-To: <1643824882.75.0.278611227582.issue46615@roundup.psfhosted.org>
Message-ID: <1643825543.13.0.375628831857.issue46615@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

replacing `return True` with `return random() < 0.5` makes *all* of the operations crash, except for `|` and `|=`.

----------

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

From report at bugs.python.org  Wed Feb  2 13:14:07 2022
From: report at bugs.python.org (Steve Dower)
Date: Wed, 02 Feb 2022 18:14:07 +0000
Subject: [issue46616] test_importlib leaves stray registry entries on Windows
Message-ID: <1643825646.98.0.404653154913.issue46616@roundup.psfhosted.org>


New submission from Steve Dower <steve.dower at python.org>:

When running test_importlib.test_windows, it may create registry keys that previously didn't exist. These keys are not fully cleaned up.

Detect if the full key is created and then delete it after the test. If it existed, only delete the specific test key.

----------
assignee: steve.dower
components: Windows
messages: 412388
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: test_importlib leaves stray registry entries on Windows
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Wed Feb  2 13:15:04 2022
From: report at bugs.python.org (Dennis Sweeney)
Date: Wed, 02 Feb 2022 18:15:04 +0000
Subject: [issue46615] Use-after-free by mutating set during set operations
In-Reply-To: <1643824882.75.0.278611227582.issue46615@roundup.psfhosted.org>
Message-ID: <1643825704.06.0.745687825775.issue46615@roundup.psfhosted.org>


Change by Dennis Sweeney <sweeney.dennis650 at gmail.com>:


----------
title: Segfault in set intersection (&) and difference (-) -> Use-after-free by mutating set during set operations

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

From report at bugs.python.org  Wed Feb  2 13:17:01 2022
From: report at bugs.python.org (Dennis Sweeney)
Date: Wed, 02 Feb 2022 18:17:01 +0000
Subject: [issue46615] Use-after-free by mutating set during set operations
In-Reply-To: <1643824882.75.0.278611227582.issue46615@roundup.psfhosted.org>
Message-ID: <1643825821.2.0.542365358067.issue46615@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

set1.isdisjoint(set2) also crashes

----------

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

From report at bugs.python.org  Wed Feb  2 13:17:25 2022
From: report at bugs.python.org (Steve Dower)
Date: Wed, 02 Feb 2022 18:17:25 +0000
Subject: [issue46616] test_importlib leaves stray registry entries on Windows
In-Reply-To: <1643825646.98.0.404653154913.issue46616@roundup.psfhosted.org>
Message-ID: <1643825845.81.0.990571489413.issue46616@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Wed Feb  2 13:41:39 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Feb 2022 18:41:39 +0000
Subject: [issue45173] Remove configparser deprecations
In-Reply-To: <1631383839.78.0.984503527213.issue45173@roundup.psfhosted.org>
Message-ID: <1643827299.23.0.146703717337.issue45173@roundup.psfhosted.org>


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


New changeset ba4d79af32b6bb8378cb7003f67d6c4d413fbe89 by Hugo van Kemenade in branch '3.10':
[3.10] bpo-45173: Note configparser deprecations will be removed in 3.12 (GH-31084)
https://github.com/python/cpython/commit/ba4d79af32b6bb8378cb7003f67d6c4d413fbe89


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

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

From report at bugs.python.org  Wed Feb  2 13:54:28 2022
From: report at bugs.python.org (Hugo van Kemenade)
Date: Wed, 02 Feb 2022 18:54:28 +0000
Subject: [issue46607] Add DeprecationWarning to configparser's
 LegacyInterpolation
In-Reply-To: <1643785269.24.0.226402381238.issue46607@roundup.psfhosted.org>
Message-ID: <1643828068.9.0.316552010726.issue46607@roundup.psfhosted.org>


Hugo van Kemenade <hugovk+python at gmail.com> added the comment:

> > Other configparser deprecations were added in 3.2, but with DeprecationWarnings.

> Its deprecation was never documented anywhere in Doc/.

Correct, only in the docstring:

```
class LegacyInterpolation(Interpolation):
    """Deprecated interpolation used in old versions of ConfigParser.
    Use BasicInterpolation or ExtendedInterpolation instead."""
```

I've updated GH-30927 to say "deprecated in the docstring" instead of "deprecated in docs".

----------

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

From report at bugs.python.org  Wed Feb  2 14:54:21 2022
From: report at bugs.python.org (Ned Deily)
Date: Wed, 02 Feb 2022 19:54:21 +0000
Subject: [issue46573] Python modules such as pyglet or pygame crash Python
 when tkinter message boxes are opened on MacOS.
In-Reply-To: <1643482093.87.0.31269168021.issue46573@roundup.psfhosted.org>
Message-ID: <1643831661.5.0.66468371961.issue46573@roundup.psfhosted.org>


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

Thanks for looking into this, Ronald. Before we close this as a Python issue, perhaps Marc might have a suggestion on what should be done here from a Tk perspective.

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

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

From report at bugs.python.org  Wed Feb  2 14:54:31 2022
From: report at bugs.python.org (Steve Dower)
Date: Wed, 02 Feb 2022 19:54:31 +0000
Subject: [issue46616] test_importlib leaves stray registry entries on Windows
In-Reply-To: <1643825646.98.0.404653154913.issue46616@roundup.psfhosted.org>
Message-ID: <1643831671.44.0.888653789751.issue46616@roundup.psfhosted.org>


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


New changeset 89a0a90c2e0e685bc70206fc45e4413c4f4411ed by Steve Dower in branch 'main':
bpo-46616: Ensures test_importlib.test_windows cleans up registry keys after completion (GH-31086)
https://github.com/python/cpython/commit/89a0a90c2e0e685bc70206fc45e4413c4f4411ed


----------

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

From report at bugs.python.org  Wed Feb  2 14:54:56 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Feb 2022 19:54:56 +0000
Subject: [issue46616] test_importlib leaves stray registry entries on Windows
In-Reply-To: <1643825646.98.0.404653154913.issue46616@roundup.psfhosted.org>
Message-ID: <1643831696.23.0.0639972357274.issue46616@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: +29271
pull_request: https://github.com/python/cpython/pull/31087

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

From report at bugs.python.org  Wed Feb  2 14:55:04 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Feb 2022 19:55:04 +0000
Subject: [issue46616] test_importlib leaves stray registry entries on Windows
In-Reply-To: <1643825646.98.0.404653154913.issue46616@roundup.psfhosted.org>
Message-ID: <1643831704.2.0.526224267715.issue46616@roundup.psfhosted.org>


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


----------
pull_requests: +29272
pull_request: https://github.com/python/cpython/pull/31088

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

From report at bugs.python.org  Wed Feb  2 15:09:27 2022
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 02 Feb 2022 20:09:27 +0000
Subject: [issue46550] __slots__ updates despite being read-only
In-Reply-To: <1643295332.29.0.0186682990953.issue46550@roundup.psfhosted.org>
Message-ID: <1643832567.86.0.0796615266511.issue46550@roundup.psfhosted.org>


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

There's a use case for using a dict for __slots__, pydoc will use a dict value for the slots as a mapping from attribute name to attribute documentation.

Because of that it is not really worthwhile to transform the value of __slots__ during class definition.

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

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

From report at bugs.python.org  Wed Feb  2 15:15:25 2022
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 02 Feb 2022 20:15:25 +0000
Subject: [issue46524] test_peg_generator takes 8 minutes on Windows
In-Reply-To: <1643137563.83.0.612264685435.issue46524@roundup.psfhosted.org>
Message-ID: <1643832925.29.0.311536015547.issue46524@roundup.psfhosted.org>


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


New changeset 164a017e13ee96bd1ea1ae79f5ac9e25fe83994e by Gregory P. Smith in branch 'main':
bpo-46576: bpo-46524: Disable compiler optimization within test_peg_generator. (#31015)
https://github.com/python/cpython/commit/164a017e13ee96bd1ea1ae79f5ac9e25fe83994e


----------

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

From report at bugs.python.org  Wed Feb  2 15:15:25 2022
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 02 Feb 2022 20:15:25 +0000
Subject: [issue46576] test_peg_generator is extremely slow
In-Reply-To: <1643488302.33.0.475443222477.issue46576@roundup.psfhosted.org>
Message-ID: <1643832925.48.0.766823353762.issue46576@roundup.psfhosted.org>


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


New changeset 164a017e13ee96bd1ea1ae79f5ac9e25fe83994e by Gregory P. Smith in branch 'main':
bpo-46576: bpo-46524: Disable compiler optimization within test_peg_generator. (#31015)
https://github.com/python/cpython/commit/164a017e13ee96bd1ea1ae79f5ac9e25fe83994e


----------

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

From report at bugs.python.org  Wed Feb  2 15:22:30 2022
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 02 Feb 2022 20:22:30 +0000
Subject: [issue46524] test_peg_generator takes 8 minutes on Windows
In-Reply-To: <1643137563.83.0.612264685435.issue46524@roundup.psfhosted.org>
Message-ID: <1643833350.7.0.455022291032.issue46524@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
pull_requests: +29274
pull_request: https://github.com/python/cpython/pull/31089

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

From report at bugs.python.org  Wed Feb  2 15:22:30 2022
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 02 Feb 2022 20:22:30 +0000
Subject: [issue46576] test_peg_generator is extremely slow
In-Reply-To: <1643488302.33.0.475443222477.issue46576@roundup.psfhosted.org>
Message-ID: <1643833350.61.0.703773134411.issue46576@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
pull_requests: +29273
pull_request: https://github.com/python/cpython/pull/31089

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

From report at bugs.python.org  Wed Feb  2 15:23:58 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Feb 2022 20:23:58 +0000
Subject: [issue46616] test_importlib leaves stray registry entries on Windows
In-Reply-To: <1643825646.98.0.404653154913.issue46616@roundup.psfhosted.org>
Message-ID: <1643833438.52.0.499575890581.issue46616@roundup.psfhosted.org>


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


New changeset 3c6173ca67c019f3eb7a2fc34c5bfc426f99c5b2 by Miss Islington (bot) in branch '3.9':
bpo-46616: Ensures test_importlib.test_windows cleans up registry keys after completion (GH-31086)
https://github.com/python/cpython/commit/3c6173ca67c019f3eb7a2fc34c5bfc426f99c5b2


----------

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

From report at bugs.python.org  Wed Feb  2 15:25:49 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Feb 2022 20:25:49 +0000
Subject: [issue46616] test_importlib leaves stray registry entries on Windows
In-Reply-To: <1643825646.98.0.404653154913.issue46616@roundup.psfhosted.org>
Message-ID: <1643833549.22.0.709340821773.issue46616@roundup.psfhosted.org>


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


New changeset 5765eaa13654e5f812a286700da7d6b8e144da0e by Miss Islington (bot) in branch '3.10':
bpo-46616: Ensures test_importlib.test_windows cleans up registry keys after completion (GH-31086)
https://github.com/python/cpython/commit/5765eaa13654e5f812a286700da7d6b8e144da0e


----------

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

From report at bugs.python.org  Wed Feb  2 15:33:48 2022
From: report at bugs.python.org (Steve Dower)
Date: Wed, 02 Feb 2022 20:33:48 +0000
Subject: [issue46616] test_importlib leaves stray registry entries on Windows
In-Reply-To: <1643825646.98.0.404653154913.issue46616@roundup.psfhosted.org>
Message-ID: <1643834028.72.0.731255285208.issue46616@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/issue46616>
_______________________________________

From report at bugs.python.org  Wed Feb  2 15:36:04 2022
From: report at bugs.python.org (Marc Culler)
Date: Wed, 02 Feb 2022 20:36:04 +0000
Subject: [issue46573] Python modules such as pyglet or pygame crash Python
 when tkinter message boxes are opened on MacOS.
In-Reply-To: <1643831661.5.0.66468371961.issue46573@roundup.psfhosted.org>
Message-ID: <CALcZXRESqgx7beOAsPJdTqu4+_zrBBOQWL42CcLOAZ_SQJKKqg@mail.gmail.com>


Marc Culler <marc.culler at gmail.com> added the comment:

The TKApplication class is a subclass of NSApplication which adds both
attributes and methods.  Those are used throughout the macOS port of Tk,
and as Ronald says, the unique instance of NSApplication in Tk is actually
a TKApplication.  Every macOS Application must have a unique NSApplication
object which is referenced by the global variable NSApp.  The TKApplication
subclass was part of the first Cocoa port of Tk, long before I became
involved, and it may have even been there in the Carbon days.  Subclassing
NSApplication appears to be something that Apple expects.

I don't know enough about Categories to understand how they could be used
to solve this problem.  Do they somehow make it possible to add new methods
and attributes to an existing NSApplication object at runtime?  I have
always thought of them as being syntactical in nature, as opposed to
allowing runtime modifications of an object's class after the object has
been instantiated.  But I am not an expert on Categories by any means.

- Marc

On Wed, Feb 2, 2022 at 1:54 PM Ned Deily <report at bugs.python.org> wrote:

>
> Ned Deily <nad at python.org> added the comment:
>
> Thanks for looking into this, Ronald. Before we close this as a Python
> issue, perhaps Marc might have a suggestion on what should be done here
> from a Tk perspective.
>
> ----------
> nosy: +culler
> status: pending -> open
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue46573>
> _______________________________________
>

----------
nosy: +Marc.Culler

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

From report at bugs.python.org  Wed Feb  2 16:34:08 2022
From: report at bugs.python.org (Matthew Stidham)
Date: Wed, 02 Feb 2022 21:34:08 +0000
Subject: [issue46617] CSV Creation occasional off by one error
Message-ID: <1643837648.9.0.298281382063.issue46617@roundup.psfhosted.org>


New submission from Matthew Stidham <stidmatt at gmail.com>:

The file which I found the error in is in https://github.com/greearb/lanforge-scripts

----------
components: C API
files: debug from pandas failure.txt
messages: 412400
nosy: matthewstidham
priority: normal
severity: normal
status: open
title: CSV Creation occasional off by one error
type: compile error
versions: Python 3.10, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file50601/debug from pandas failure.txt

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

From report at bugs.python.org  Wed Feb  2 16:40:53 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 02 Feb 2022 21:40:53 +0000
Subject: [issue46617] CSV Creation occasional off by one error
In-Reply-To: <1643837648.9.0.298281382063.issue46617@roundup.psfhosted.org>
Message-ID: <1643838053.18.0.616855519925.issue46617@roundup.psfhosted.org>


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

There's too much for us to look at here. Can you create a small example which demonstrates the problem?

It should include the input, the code, the actual output, and the expected output.

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

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

From report at bugs.python.org  Wed Feb  2 17:33:12 2022
From: report at bugs.python.org (koala-lava)
Date: Wed, 02 Feb 2022 22:33:12 +0000
Subject: [issue46618] Exponent operator(**) interpreter issue
Message-ID: <1643841192.81.0.245453697907.issue46618@roundup.psfhosted.org>


New submission from koala-lava <shgr11111 at yandex.ru>:

If I put -2 ** 2 in the interpreter it outputs -4. Expected is 4.

If I create a variable and initialize it with -2 and then try the same then it's correct.

----------
components: Interpreter Core
messages: 412402
nosy: koala-lava
priority: normal
severity: normal
status: open
title: Exponent operator(**) interpreter issue
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Wed Feb  2 17:36:14 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 02 Feb 2022 22:36:14 +0000
Subject: [issue42238] Deprecate suspicious.py?
In-Reply-To: <1604274563.95.0.828690163802.issue42238@roundup.psfhosted.org>
Message-ID: <1643841374.51.0.523728518393.issue42238@roundup.psfhosted.org>


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

> https://pypi.org/project/sphinx-lint/

Congrats :-)

----------

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

From report at bugs.python.org  Wed Feb  2 17:43:50 2022
From: report at bugs.python.org (Tim Peters)
Date: Wed, 02 Feb 2022 22:43:50 +0000
Subject: [issue46618] Exponent operator(**) interpreter issue
In-Reply-To: <1643841192.81.0.245453697907.issue46618@roundup.psfhosted.org>
Message-ID: <1643841830.23.0.360192315102.issue46618@roundup.psfhosted.org>


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

Exponentiation has higher precedence (binds more tightly) than unary minus, so the expression groups as -(2**2).

Virtually all computer languages (those that _have_ an exponentiation operator) do the same. For example, here from wxMaxima:

(%i1) -2**2;
(%o1) -4

Closing as not-a-bug.

----------
nosy: +tim.peters
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
versions:  -Python 3.10

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

From report at bugs.python.org  Wed Feb  2 17:53:22 2022
From: report at bugs.python.org (Eric Snow)
Date: Wed, 02 Feb 2022 22:53:22 +0000
Subject: [issue46541] Replace _Py_IDENTIFIER() with statically initialized
 objects.
In-Reply-To: <1643234464.46.0.949364478641.issue46541@roundup.psfhosted.org>
Message-ID: <1643842402.95.0.02468281018.issue46541@roundup.psfhosted.org>


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

FYI, I've posted to python-dev for feedback before proceeding:

https://mail.python.org/archives/list/python-dev at python.org/thread/DNMZAMB4M6RVR76RDZMUK2WRLI6KAAYS/

----------

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

From report at bugs.python.org  Wed Feb  2 18:18:52 2022
From: report at bugs.python.org (jakirkham)
Date: Wed, 02 Feb 2022 23:18:52 +0000
Subject: [issue45819] Avoid releasing the GIL in nonblocking socket operations
In-Reply-To: <1637088700.35.0.697825575179.issue45819@roundup.psfhosted.org>
Message-ID: <1643843932.31.0.86525621297.issue45819@roundup.psfhosted.org>


Change by jakirkham <jakirkham at gmail.com>:


----------
nosy: +jakirkham

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

From report at bugs.python.org  Wed Feb  2 18:26:24 2022
From: report at bugs.python.org (Matthew Stidham)
Date: Wed, 02 Feb 2022 23:26:24 +0000
Subject: [issue46617] CSV Creation occasional off by one error
In-Reply-To: <1643837648.9.0.298281382063.issue46617@roundup.psfhosted.org>
Message-ID: <1643844384.86.0.441728284667.issue46617@roundup.psfhosted.org>


Matthew Stidham <stidmatt at gmail.com> added the comment:

the problem was a file in our library screwing up the python configuration

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

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

From report at bugs.python.org  Wed Feb  2 18:26:50 2022
From: report at bugs.python.org (Matthew Suozzo)
Date: Wed, 02 Feb 2022 23:26:50 +0000
Subject: [issue43478] Disallow Mock spec arguments from being Mocks
In-Reply-To: <1615514023.14.0.0477922265442.issue43478@roundup.psfhosted.org>
Message-ID: <1643844410.99.0.320025727928.issue43478@roundup.psfhosted.org>


Change by Matthew Suozzo <matthew.suozzo at gmail.com>:


----------
pull_requests: +29275
pull_request: https://github.com/python/cpython/pull/31090

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

From report at bugs.python.org  Wed Feb  2 18:55:55 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 02 Feb 2022 23:55:55 +0000
Subject: [issue46617] CSV Creation occasional off by one error
In-Reply-To: <1643837648.9.0.298281382063.issue46617@roundup.psfhosted.org>
Message-ID: <1643846155.88.0.494621880308.issue46617@roundup.psfhosted.org>


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


----------
resolution:  -> not a bug

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

From report at bugs.python.org  Wed Feb  2 19:00:28 2022
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 03 Feb 2022 00:00:28 +0000
Subject: [issue46600] Python built with clang -O0 allocates 10x more stack
 memory than clang -O3 on a Python function call
In-Reply-To: <1643720760.9.0.302596428689.issue46600@roundup.psfhosted.org>
Message-ID: <1643846428.62.0.785774365087.issue46600@roundup.psfhosted.org>


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

I didn't mean _Py_abspath is problem. I just used it to describe why -O0 and -Og is so different.

We can reduce stack usage of it easily, but it is not a problem than _PyEval_EvalFrameDefault.
It is difficult to reduce stack usage of _PyEval_EvalFrameDefault with -O0.

----------

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

From report at bugs.python.org  Wed Feb  2 19:17:26 2022
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 03 Feb 2022 00:17:26 +0000
Subject: [issue46197] ensurepip bootstrap breaks out of isolated environment
In-Reply-To: <1640820251.78.0.719610352005.issue46197@roundup.psfhosted.org>
Message-ID: <1643847446.87.0.287312513298.issue46197@roundup.psfhosted.org>


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

Thanks for the report and PR.

The workflow would be to merge a fix to the main branch for 3.11, then there?s a bot that makes backports for active branches (3.10 and 3.9).

More info: https://devguide.python.org/

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

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

From report at bugs.python.org  Wed Feb  2 20:08:28 2022
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 03 Feb 2022 01:08:28 +0000
Subject: [issue46619] lazy module property not recognized by doctests
Message-ID: <1643850508.65.0.917170259408.issue46619@roundup.psfhosted.org>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

Attempting to define a lazy-loaded property for a module, I found [this guidance](https://stackoverflow.com/a/52018676/70170) referencing [module attribute access](https://docs.python.org/3/reference/datamodel.html#customizing-module-attribute-access) in the Python docs as a means of customizing attribute access.

I followed that guidance, but found that doctests don't have access to those attributes in its execution. Consider this reproducer:

```
"""
>>> print(static_property)
static value
>>> print(lazy_property)
lazy value
"""
# text.py
import types
import sys


static_property = 'static value'


class _Properties(types.ModuleType):
    @property
    def lazy_property(self):
        return 'lazy value'


sys.modules[__name__].__class__ = _Properties
```

Run that with `python -m doctest text.py` and it fails thus:

```
**********************************************************************
File "/Users/jaraco/draft/text.py", line 4, in text
Failed example:
    print(lazy_property)
Exception raised:
    Traceback (most recent call last):
      File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/doctest.py", line 1346, in __run
        exec(compile(example.source, filename, "single",
      File "<doctest text[1]>", line 1, in <module>
        print(lazy_property)
    NameError: name 'lazy_property' is not defined
**********************************************************************
1 items had failures:
   1 of   2 in text
***Test Failed*** 1 failures.
```

Same error using the `__getattr__` technique:

```
"""
>>> print(static_property)
static value
>>> print(lazy_property)
lazy value
"""

static_property = 'static value'


def __getattr__(name):
    if name != 'lazy_property':
        raise AttributeError(name)
    return 'lazy value'
```

I suspect the issue is that doctests runs with locals from the module's globals(), which won't include these lazy properties.

It would be nice if doctests could honor locals that would represent the properties available on the module.

----------
components: Library (Lib)
messages: 412409
nosy: jaraco
priority: normal
severity: normal
status: open
title: lazy module property not recognized by doctests
versions: Python 3.11

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

From report at bugs.python.org  Wed Feb  2 20:59:31 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 03 Feb 2022 01:59:31 +0000
Subject: [issue45975] Simplify some while-loops with walrus operator
In-Reply-To: <1638573350.23.0.80297686747.issue45975@roundup.psfhosted.org>
Message-ID: <1643853571.57.0.813436566148.issue45975@roundup.psfhosted.org>


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


New changeset 51a95be1d035a717ab29e98056b8831a98e61125 by Nick Drozd in branch 'main':
bpo-45975: Use walrus operator for some idlelib while loops (GH-31083)
https://github.com/python/cpython/commit/51a95be1d035a717ab29e98056b8831a98e61125


----------

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

From report at bugs.python.org  Wed Feb  2 20:59:33 2022
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Feb 2022 01:59:33 +0000
Subject: [issue45975] Simplify some while-loops with walrus operator
In-Reply-To: <1638573350.23.0.80297686747.issue45975@roundup.psfhosted.org>
Message-ID: <1643853573.5.0.551686387534.issue45975@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: +29276
pull_request: https://github.com/python/cpython/pull/31091

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

From report at bugs.python.org  Wed Feb  2 21:28:56 2022
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Feb 2022 02:28:56 +0000
Subject: [issue45975] Simplify some while-loops with walrus operator
In-Reply-To: <1638573350.23.0.80297686747.issue45975@roundup.psfhosted.org>
Message-ID: <1643855336.38.0.831868538954.issue45975@roundup.psfhosted.org>


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


New changeset 2ddc278875f789de622262ee8ff5a1c3788f031c by Miss Islington (bot) in branch '3.10':
bpo-45975: Use walrus operator for some idlelib while loops (GH-31083)
https://github.com/python/cpython/commit/2ddc278875f789de622262ee8ff5a1c3788f031c


----------

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

From report at bugs.python.org  Wed Feb  2 21:30:06 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 03 Feb 2022 02:30:06 +0000
Subject: [issue45975] Simplify some while-loops with walrus operator
In-Reply-To: <1638573350.23.0.80297686747.issue45975@roundup.psfhosted.org>
Message-ID: <1643855406.43.0.33173839145.issue45975@roundup.psfhosted.org>


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


----------
pull_requests: +29277
pull_request: https://github.com/python/cpython/pull/31092

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

From report at bugs.python.org  Wed Feb  2 21:46:49 2022
From: report at bugs.python.org (Kenta Tsuna)
Date: Thu, 03 Feb 2022 02:46:49 +0000
Subject: [issue46620] Documentation of ipaddress behavior for prefix length
 with leading zeros.
Message-ID: <1643856409.43.0.923620976074.issue46620@roundup.psfhosted.org>


New submission from Kenta Tsuna <lay20114 at gmail.com>:

ipaddress library tolerate the prefix length with leading zeros.
$ ./python.exe 
Python 3.11.0a4+ (heads/main:8fb3649450, Jan 31 2022, 16:39:46) [Clang 13.0.0 (clang-1300.0.29.3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ipaddress
>>> ipaddress.ip_interface('192.0.2.0/0000000024')
IPv4Interface('192.0.2.0/24')
>>> ipaddress.ip_interface('2001:db8::/0000000032')
IPv6Interface('2001:db8::/32')

The explanation of this behavior exists in follow tests.
https://github.com/python/cpython/blob/51a95be1d035a717ab29e98056b8831a98e61125/Lib/test/test_ipaddress.py#L747-L748
https://github.com/python/cpython/blob/51a95be1d035a717ab29e98056b8831a98e61125/Lib/test/test_ipaddress.py#L755-L756
https://github.com/python/cpython/blob/51a95be1d035a717ab29e98056b8831a98e61125/Lib/test/test_ipaddress.py#L592-L593

But, it seems that the explanation does not exists in the document.
https://docs.python.org/3.11/library/ipaddress.html
https://docs.python.org/3.10/library/ipaddress.html
https://docs.python.org/3.9/library/ipaddress.html
https://docs.python.org/3.8/library/ipaddress.html
https://docs.python.org/3.7/library/ipaddress.html

----------
assignee: docs at python
components: Documentation
messages: 412412
nosy: docs at python, lay20114
priority: normal
severity: normal
status: open
title: Documentation of ipaddress behavior for prefix length with leading zeros.
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Feb  2 22:12:47 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 03 Feb 2022 03:12:47 +0000
Subject: [issue45975] Simplify some while-loops with walrus operator
In-Reply-To: <1638573350.23.0.80297686747.issue45975@roundup.psfhosted.org>
Message-ID: <1643857967.33.0.163821496481.issue45975@roundup.psfhosted.org>


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


New changeset fafd2dadf63973a04f5693e5be19f3e7521c10d4 by Terry Jan Reedy in branch '3.9':
[3.9] bpo-45975: Use walrus operator for some idlelib while loops (GH-31083)
https://github.com/python/cpython/commit/fafd2dadf63973a04f5693e5be19f3e7521c10d4


----------

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

From report at bugs.python.org  Wed Feb  2 22:48:03 2022
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 03 Feb 2022 03:48:03 +0000
Subject: [issue46490] Add "follow_symlinks=False" support for "os.utime()" on
 Windows
In-Reply-To: <1642963308.84.0.964070745498.issue46490@roundup.psfhosted.org>
Message-ID: <1643860083.34.0.660068429112.issue46490@roundup.psfhosted.org>


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

In case you missed it, I implemented _Py_CreateFile2() in bpo-46506 and rewrote os.stat() based on it. Check it out in case you're interested in moving forward with a PR in bpo-46506.

For this issue, follow_symlinks is fairly simple to support with _Py_CreateFile2(). We may as well add fd support, since that's trivial to add. For example:

    if (path->fd != -1) {
        hFile = _Py_get_osfhandle(path->fd);
    } else {
        Py_BEGIN_ALLOW_THREADS
        hFile = _Py_CreateFile2(path->wide, FILE_WRITE_ATTRIBUTES, 0,
                    OPEN_EXISTING, NULL, follow_symlinks, NULL);
        Py_END_ALLOW_THREADS
    }
    if (hFile == INVALID_HANDLE_VALUE) {
        if (path->fd == -1) {
            path_error(path);
        }
        return NULL;
    }

One also has to define the following macros to declare follow_symlinks and fd support: UTIME_HAVE_NOFOLLOW_SYMLINKS and PATH_UTIME_HAVE_FD.

To announce support in os.supports_follow_symlinks and os.supports_fd, it should be conditioned on MS_WINDOWS, i.e. _add("MS_WINDOWS", "utime"). The os module is frozen, so changing these two sets requires rebuilding Python.

----------

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

From report at bugs.python.org  Wed Feb  2 23:03:08 2022
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 03 Feb 2022 04:03:08 +0000
Subject: [issue46524] test_peg_generator takes 8 minutes on Windows
In-Reply-To: <1643137563.83.0.612264685435.issue46524@roundup.psfhosted.org>
Message-ID: <1643860988.02.0.194108276518.issue46524@roundup.psfhosted.org>


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


New changeset f5ebec4d3e1199ec38b88920cfde8e460e5120dd by Gregory P. Smith in branch '3.10':
[3.10] bpo-46576: bpo-46524: Disable compiler optimization within test_peg_generator. (GH-31015) (GH-31089)
https://github.com/python/cpython/commit/f5ebec4d3e1199ec38b88920cfde8e460e5120dd


----------

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

From report at bugs.python.org  Wed Feb  2 23:03:11 2022
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Feb 2022 04:03:11 +0000
Subject: [issue46576] test_peg_generator is extremely slow
In-Reply-To: <1643488302.33.0.475443222477.issue46576@roundup.psfhosted.org>
Message-ID: <1643860991.35.0.96316453998.issue46576@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: +29278
pull_request: https://github.com/python/cpython/pull/31093

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

From report at bugs.python.org  Wed Feb  2 23:03:08 2022
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 03 Feb 2022 04:03:08 +0000
Subject: [issue46576] test_peg_generator is extremely slow
In-Reply-To: <1643488302.33.0.475443222477.issue46576@roundup.psfhosted.org>
Message-ID: <1643860988.21.0.256524086922.issue46576@roundup.psfhosted.org>


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


New changeset f5ebec4d3e1199ec38b88920cfde8e460e5120dd by Gregory P. Smith in branch '3.10':
[3.10] bpo-46576: bpo-46524: Disable compiler optimization within test_peg_generator. (GH-31015) (GH-31089)
https://github.com/python/cpython/commit/f5ebec4d3e1199ec38b88920cfde8e460e5120dd


----------

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

From report at bugs.python.org  Wed Feb  2 23:03:11 2022
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Feb 2022 04:03:11 +0000
Subject: [issue46524] test_peg_generator takes 8 minutes on Windows
In-Reply-To: <1643137563.83.0.612264685435.issue46524@roundup.psfhosted.org>
Message-ID: <1643860991.49.0.348372066626.issue46524@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: +29279
pull_request: https://github.com/python/cpython/pull/31093

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

From report at bugs.python.org  Wed Feb  2 23:33:03 2022
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Feb 2022 04:33:03 +0000
Subject: [issue46524] test_peg_generator takes 8 minutes on Windows
In-Reply-To: <1643137563.83.0.612264685435.issue46524@roundup.psfhosted.org>
Message-ID: <1643862783.84.0.66835919966.issue46524@roundup.psfhosted.org>


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


New changeset e8258608c28c65680253d0ca6167430e34c2fd87 by Miss Islington (bot) in branch '3.9':
[3.9] [3.10] bpo-46576: bpo-46524: Disable compiler optimization within test_peg_generator. (GH-31015) (GH-31089) (GH-31093)
https://github.com/python/cpython/commit/e8258608c28c65680253d0ca6167430e34c2fd87


----------

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

From report at bugs.python.org  Wed Feb  2 23:33:03 2022
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Feb 2022 04:33:03 +0000
Subject: [issue46576] test_peg_generator is extremely slow
In-Reply-To: <1643488302.33.0.475443222477.issue46576@roundup.psfhosted.org>
Message-ID: <1643862783.98.0.00708338727001.issue46576@roundup.psfhosted.org>


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


New changeset e8258608c28c65680253d0ca6167430e34c2fd87 by Miss Islington (bot) in branch '3.9':
[3.9] [3.10] bpo-46576: bpo-46524: Disable compiler optimization within test_peg_generator. (GH-31015) (GH-31089) (GH-31093)
https://github.com/python/cpython/commit/e8258608c28c65680253d0ca6167430e34c2fd87


----------

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

From report at bugs.python.org  Wed Feb  2 23:46:26 2022
From: report at bugs.python.org (Peiran Yao)
Date: Thu, 03 Feb 2022 04:46:26 +0000
Subject: [issue46621] Should map(function, iterable,
 ...) replace StopIteration with RuntimeError?
Message-ID: <1643863586.75.0.713225774424.issue46621@roundup.psfhosted.org>


New submission from Peiran Yao <peiran.yao at tuna.tsinghua.edu.cn>:

Currently, StopIteration raised accidentally inside the `function` being applied is not caught by map(). This will cause the iteration of the map object to terminate silently. (Whereas, when some other exception is raised, a traceback is printed pinpointing the cause of the problem.)

Here's a minimal working example:

```
def take_first(it: Iterable):
    # if `it` is empty, StopIteration will be raised accidentally
    return next(it) 

iterables = [iter([1]), iter([]), iter([2, 3])] # the second one is empty
for i in map(take_first, iterables):
    print(i)
```

`take_first` function didn't consider the case where `it` is empty. The programmer would expect an uncaught StopIteration, instead of the loop terminating silently after only one iteration.

Similar to the case of generators (described in PEP 497), this behaviour can conceal obscure bugs, and a solution could be catching StopIteration when applying the function, and replacing it with a RuntimeError.

Beside the built-in map(), imap() and imap_unordered() in the concurrent and multiprocessing modules also have similar behaviour.


PEP 479 -- Change StopIteration handling inside generators https://www.python.org/dev/peps/pep-0479/

----------
messages: 412419
nosy: xavieryao
priority: normal
severity: normal
status: open
title: Should map(function, iterable, ...) replace StopIteration with RuntimeError?
type: behavior

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

From report at bugs.python.org  Wed Feb  2 23:53:56 2022
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 03 Feb 2022 04:53:56 +0000
Subject: [issue45629] Tools/freeze needs tests in the test suite.
In-Reply-To: <1635349332.56.0.690000934648.issue45629@roundup.psfhosted.org>
Message-ID: <1643864036.77.0.731201068815.issue45629@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
nosy: +gregory.p.smith
nosy_count: 2.0 -> 3.0
pull_requests: +29280
pull_request: https://github.com/python/cpython/pull/31094

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

From report at bugs.python.org  Thu Feb  3 00:14:13 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 03 Feb 2022 05:14:13 +0000
Subject: [issue46621] Should map(function, iterable,
 ...) replace StopIteration with RuntimeError?
In-Reply-To: <1643863586.75.0.713225774424.issue46621@roundup.psfhosted.org>
Message-ID: <1643865253.82.0.920512292367.issue46621@roundup.psfhosted.org>


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

-1 for being a breaking change, for addressing a minor issue that rarely arises in real life, and for being a slippery slope.

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

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

From report at bugs.python.org  Thu Feb  3 00:36:25 2022
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 03 Feb 2022 05:36:25 +0000
Subject: [issue45629] Tools/freeze needs tests in the test suite.
In-Reply-To: <1635349332.56.0.690000934648.issue45629@roundup.psfhosted.org>
Message-ID: <1643866585.41.0.343482684856.issue45629@roundup.psfhosted.org>


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


New changeset 8726067ace98a27557e9fdf1a8e1c509c37cfcfc by Gregory P. Smith in branch 'main':
bpo-45629: Improve test.support.skip_if_buildbot (GH-31094)
https://github.com/python/cpython/commit/8726067ace98a27557e9fdf1a8e1c509c37cfcfc


----------

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

From report at bugs.python.org  Thu Feb  3 02:28:28 2022
From: report at bugs.python.org (Tzu-ping Chung)
Date: Thu, 03 Feb 2022 07:28:28 +0000
Subject: [issue46622] Support decorating a coroutine with
 functools.cached_property
Message-ID: <1643873308.65.0.92890586202.issue46622@roundup.psfhosted.org>


New submission from Tzu-ping Chung <uranusjr at gmail.com>:

Currently, decorating a coroutine with cached_property would cache the coroutine itself. But this is not useful in any way since a coroutine cannot be awaited multiple times.

Running this code:

    import asyncio
    import functools

    class A:
        @functools.cached_property
        async def hello(self):
            return 'yo'

    async def main():
        a = A()
        print(await a.hello)
        print(await a.hello)

    asyncio.run(main())

produces:

    yo
    Traceback (most recent call last):
      File "t.py", line 15, in <module>
        asyncio.run(main())
      File "/lib/python3.10/asyncio/runners.py", line 44, in run
        return loop.run_until_complete(main)
      File "/lib/python3.10/asyncio/base_events.py", line 641, in run_until_complete
        return future.result()
      File "t.py", line 12, in main
        print(await a.hello)
    RuntimeError: cannot reuse already awaited coroutine

The third-party cached_property package, on the other hand, detects a coroutine and caches its result instead. I feel this is a more useful behaviour. https://github.com/pydanny/cached-property/issues/85

----------
components: Library (Lib)
messages: 412422
nosy: uranusjr
priority: normal
severity: normal
status: open
title: Support  decorating a coroutine with functools.cached_property
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Feb  3 02:37:23 2022
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 03 Feb 2022 07:37:23 +0000
Subject: [issue46573] Python modules such as pyglet or pygame crash Python
 when tkinter message boxes are opened on MacOS.
In-Reply-To: <1643482093.87.0.31269168021.issue46573@roundup.psfhosted.org>
Message-ID: <1643873843.68.0.956943317008.issue46573@roundup.psfhosted.org>


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

Categories make it possible to add methods to an existing class, but not new attributes.  The latter shouldn't be a problem in principle for an NSApplication subclass because only a single instance of the application class will get created and you may as well use global variables for those.

In some sense categories are syntactic sugar for monkey patching existing classes, commonly used to add convenience methods to Cocoa classes.

----------

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

From report at bugs.python.org  Thu Feb  3 03:25:22 2022
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 03 Feb 2022 08:25:22 +0000
Subject: [issue46576] test_peg_generator is extremely slow
In-Reply-To: <1643488302.33.0.475443222477.issue46576@roundup.psfhosted.org>
Message-ID: <1643876722.01.0.452560833411.issue46576@roundup.psfhosted.org>


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

for my purposes those PRs make it reasonable, even though it remains one of our slowest tests.  we can reopen/reuse this issue for any further test_peg_generator performance improvements as needed.

----------
assignee:  -> gregory.p.smith
resolution:  -> fixed
stage: patch review -> commit review
status: open -> closed
versions: +Python 3.10, Python 3.9

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

From report at bugs.python.org  Thu Feb  3 03:29:56 2022
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 03 Feb 2022 08:29:56 +0000
Subject: [issue46573] Python modules such as pyglet or pygame crash Python
 when tkinter message boxes are opened on MacOS.
In-Reply-To: <1643482093.87.0.31269168021.issue46573@roundup.psfhosted.org>
Message-ID: <1643876996.76.0.621196070179.issue46573@roundup.psfhosted.org>


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

Something I forgot to mention: I don't think this is a bug in Tk now that I've looked into this more deeply. 

The integration problem between Tk and other users of the Cocoa event loop is unfortunate but not a bug.

----------

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

From report at bugs.python.org  Thu Feb  3 03:34:40 2022
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 03 Feb 2022 08:34:40 +0000
Subject: [issue46623] test_zlib: test_pair() and test_speech128() fail with
 s390x hardware accelerator
Message-ID: <1643877280.17.0.469977325894.issue46623@roundup.psfhosted.org>


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

test_pair() and test_speech128() tests of test_zlib fail on the s390x architecture if zlib uses the s390x hardware accelerator.

RHEL8 downstream issues (with most details):
https://bugzilla.redhat.com/show_bug.cgi?id=1974658

Fedora downstream issues:
https://bugzilla.redhat.com/show_bug.cgi?id=2038848

The s390x has a hardware accelerator for zlib. Depending if the hardware accelerator is used or not, the output (compress data) is different.

Also, test_zlib compress data in two different ways and then expect the same output. test_zlib pass with the software implementation which creates a single (final) compressed block. test_zlib fails with the hardware implementation which creates multiple compressed blocks (the last one is a final block).

Another reason the output differs is the FHT/DHT heuristic. The zlib deflate algorithm can analyze the data distribution and decide whether it wants to use a fixed-Huffman table (FHT) or a dynamic-Huffman table (DHT) for the next block, but the accelerator can't. Furthermore, looking at data in software would kill the accelerator performance. Therefore the following heuristic is used on s390x: the first 4k are compressed with FHT and the rest of the data with DHT. So, compress() creates a single FHT block. compressobj() creates a FHT block, a DHT block and a trailing block.

It is *not a bug* in zlib: the decompression gives back the original content as expected in all cases. The issue is that Python test_zlib makes too many assumptions on how "streamed" data should be compressed. The test expected that compressed data using different ways to call zlib would return the exact same compressed data. If an accelarator is used, it's not always the case.

----------
components: Tests
messages: 412426
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_zlib: test_pair() and test_speech128() fail with s390x hardware accelerator
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Thu Feb  3 03:35:11 2022
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 03 Feb 2022 08:35:11 +0000
Subject: [issue46524] test_peg_generator takes 8 minutes on Windows
In-Reply-To: <1643137563.83.0.612264685435.issue46524@roundup.psfhosted.org>
Message-ID: <1643877311.47.0.40795975353.issue46524@roundup.psfhosted.org>


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

test_peg_generator is significantly less of the long tail on optimized builds now.  CI extremely noisy performance wise (times vary by 2-3x without any differences anways) so I can't easily judge if this made a notable difference in windows CI latency.

----------

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

From report at bugs.python.org  Thu Feb  3 03:44:59 2022
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 03 Feb 2022 08:44:59 +0000
Subject: [issue46623] test_zlib: test_pair() and test_speech128() fail with
 s390x hardware accelerator
In-Reply-To: <1643877280.17.0.469977325894.issue46623@roundup.psfhosted.org>
Message-ID: <1643877899.96.0.717110269699.issue46623@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Thu Feb  3 04:06:00 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 03 Feb 2022 09:06:00 +0000
Subject: [issue46615] Use-after-free by mutating set during set operations
In-Reply-To: <1643824882.75.0.278611227582.issue46615@roundup.psfhosted.org>
Message-ID: <1643879160.79.0.860268764577.issue46615@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Thu Feb  3 04:08:52 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 03 Feb 2022 09:08:52 +0000
Subject: [issue46610] assertCountEqual doesn't work as expected for dictionary
 elements
In-Reply-To: <1643808975.15.0.46322422431.issue46610@roundup.psfhosted.org>
Message-ID: <1643879332.55.0.624399654048.issue46610@roundup.psfhosted.org>


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

Concur with Eric and Raymond.

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Feb  3 04:20:22 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 03 Feb 2022 09:20:22 +0000
Subject: [issue46565] Delete module-level loop variables when no longer needed
In-Reply-To: <1643388451.48.0.632570140145.issue46565@roundup.psfhosted.org>
Message-ID: <1643880022.81.0.0330767814044.issue46565@roundup.psfhosted.org>


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


New changeset 0cbdd2131195b0d313762968f604e80a3e65ca9f by Nikita Sobolev in branch 'main':
bpo-46565: `del` loop vars that are leaking into module namespaces (GH-30993)
https://github.com/python/cpython/commit/0cbdd2131195b0d313762968f604e80a3e65ca9f


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

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

From report at bugs.python.org  Thu Feb  3 04:24:11 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 03 Feb 2022 09:24:11 +0000
Subject: [issue46483] `pathlib.PurePath.__class_getitem__` does not return
 `GenericAlias`
In-Reply-To: <1642925790.59.0.879604059643.issue46483@roundup.psfhosted.org>
Message-ID: <1643880251.01.0.212923774203.issue46483@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/issue46483>
_______________________________________

From report at bugs.python.org  Thu Feb  3 04:25:27 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 03 Feb 2022 09:25:27 +0000
Subject: [issue46483] `pathlib.PurePath.__class_getitem__` does not return
 `GenericAlias`
In-Reply-To: <1642925790.59.0.879604059643.issue46483@roundup.psfhosted.org>
Message-ID: <1643880327.08.0.897134531921.issue46483@roundup.psfhosted.org>


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


New changeset 7ffe7ba30fc051014977c6f393c51e57e71a6648 by Nikita Sobolev in branch 'main':
bpo-46483: Remove `__class_getitem__` from `pathlib.PurePath` (GH-30848)
https://github.com/python/cpython/commit/7ffe7ba30fc051014977c6f393c51e57e71a6648


----------

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

From report at bugs.python.org  Thu Feb  3 04:43:45 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 03 Feb 2022 09:43:45 +0000
Subject: [issue44977] Deprecate delegation of int to __trunc__
In-Reply-To: <1629623877.06.0.26111591106.issue44977@roundup.psfhosted.org>
Message-ID: <1643881425.38.0.548328201378.issue44977@roundup.psfhosted.org>


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


New changeset b4bd1e1422997de61faf506b4916e83013bc7d21 by Zackery Spytz in branch 'main':
bpo-44977: Deprecate delegation of int to __trunc__ (GH-31031)
https://github.com/python/cpython/commit/b4bd1e1422997de61faf506b4916e83013bc7d21


----------

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

From report at bugs.python.org  Thu Feb  3 04:44:44 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 03 Feb 2022 09:44:44 +0000
Subject: [issue44977] Deprecate delegation of int to __trunc__
In-Reply-To: <1629623877.06.0.26111591106.issue44977@roundup.psfhosted.org>
Message-ID: <1643881484.78.0.551022677277.issue44977@roundup.psfhosted.org>


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

Thanks Zackery.

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

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

From report at bugs.python.org  Thu Feb  3 05:14:48 2022
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 03 Feb 2022 10:14:48 +0000
Subject: [issue45773] Compiler hangs during jump elimination
In-Reply-To: <1636487782.5.0.379047434297.issue45773@roundup.psfhosted.org>
Message-ID: <1643883288.08.0.340355052629.issue45773@roundup.psfhosted.org>


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


New changeset e0433c1e70254d4d0357a9e14596929a04bdf769 by Brandt Bucher in branch 'main':
bpo-45773: Remove invalid peephole optimizations (GH-31066)
https://github.com/python/cpython/commit/e0433c1e70254d4d0357a9e14596929a04bdf769


----------

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

From report at bugs.python.org  Thu Feb  3 05:14:49 2022
From: report at bugs.python.org (Julien Palard)
Date: Thu, 03 Feb 2022 10:14:49 +0000
Subject: [issue42238] Deprecate suspicious.py?
In-Reply-To: <1604274563.95.0.828690163802.issue42238@roundup.psfhosted.org>
Message-ID: <1643883289.75.0.0228330488734.issue42238@roundup.psfhosted.org>


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


----------
pull_requests: +29282
pull_request: https://github.com/python/cpython/pull/31097

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

From report at bugs.python.org  Thu Feb  3 05:19:11 2022
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 03 Feb 2022 10:19:11 +0000
Subject: [issue46524] test_peg_generator takes 8 minutes on Windows
In-Reply-To: <1643137563.83.0.612264685435.issue46524@roundup.psfhosted.org>
Message-ID: <1643883551.39.0.605771536082.issue46524@roundup.psfhosted.org>


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

Duration of the "Tests" step of https://github.com/python/cpython/pull/30890 

* GHA win32: 14 min 11 sec (test_peg_generator: 8 min 16 sec)
* GHA win64: 21 min 2 sec (test_peg_generator: 16 min 38 sec)
* Azure win32: 9 min 34 sec (test_peg_generator: 5 min 30 sec)
* Azure win64: 13 min 56 sec (test_peg_generator: 8 min 3 sec)

Duration of the "Tests" step of https://github.com/python/cpython/pull/31096 (which includes Gregory's change):

* GHA win32: 8 min 30 sec (test_peg_generator: 5 min 1 sec)
* GHA win64: 8 min 29 sec (test_peg_generator: 4 min 52 sec)
* Azure win32: 9 min 54 sec (test_peg_generator: 4 min 19 sec)
* Azure win64: 7 min 57 sec (test_peg_generator: 3 min 32 sec)

test_peg_generator is way faster, and the total tests duration is shorter especially the maximum time: 21 min (before) => 10 min (after).

----------

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

From report at bugs.python.org  Thu Feb  3 05:35:01 2022
From: report at bugs.python.org (jack1142)
Date: Thu, 03 Feb 2022 10:35:01 +0000
Subject: [issue45380] help() appears confused about the module of
 typing.Annotated
In-Reply-To: <1633458543.21.0.19270161871.issue45380@roundup.psfhosted.org>
Message-ID: <1643884501.87.0.192573300868.issue45380@roundup.psfhosted.org>


Change by jack1142 <kuba.kuczys at gmail.com>:


----------
nosy: +jack1142

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

From report at bugs.python.org  Thu Feb  3 05:41:29 2022
From: report at bugs.python.org (Petr Viktorin)
Date: Thu, 03 Feb 2022 10:41:29 +0000
Subject: [issue42222] Modernize integer test/conversion in randrange()
In-Reply-To: <1604165232.15.0.0916383458838.issue42222@roundup.psfhosted.org>
Message-ID: <1643884889.44.0.000276849219091.issue42222@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

Since this is a user-visible change in 3.11, could you add a What's New entry?

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

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

From report at bugs.python.org  Thu Feb  3 05:52:01 2022
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Thu, 03 Feb 2022 10:52:01 +0000
Subject: [issue46624] random.randrange removed support for non-integer types
 after just one release of deprecation
Message-ID: <1643885521.08.0.473990761772.issue46624@roundup.psfhosted.org>


New submission from Miro Hron?ok <miro at hroncok.cz>:

In https://github.com/python/cpython/commit/5afa0a411243210a30526c7459a0ccff5cb88494 the support for non-integer types was removed from random.randrange().

This change is not backward-compatible and it breaks 3rd party code, for example:

simplewrap: https://bugzilla.redhat.com/show_bug.cgi?id=2050093
numpy-stl: https://bugzilla.redhat.com/show_bug.cgi?id=2050092 == https://github.com/WoLpH/numpy-stl/issues/188

That support was only deprecated in Python 3.10 and it needs to remain deprecated for at least two Python releases. Please revert this change from Python 3.11 and wait for at least Python 3.12.

See https://www.python.org/dev/peps/pep-0387/#making-incompatible-changes

When you do remove this from Python 3.12, please make sure to document it in the What's new document.

Thank you.

----------
components: Library (Lib)
messages: 412436
nosy: hroncok, pablogsal, rhettinger
priority: normal
severity: normal
status: open
title: random.randrange removed support for non-integer types after just one release of deprecation
versions: Python 3.11

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

From report at bugs.python.org  Thu Feb  3 06:09:13 2022
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Thu, 03 Feb 2022 11:09:13 +0000
Subject: [issue46624] random.randrange removed support for non-integer types
 after just one release of deprecation
In-Reply-To: <1643885521.08.0.473990761772.issue46624@roundup.psfhosted.org>
Message-ID: <1643886553.12.0.414069610926.issue46624@roundup.psfhosted.org>


Change by Miro Hron?ok <miro at hroncok.cz>:


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

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

From report at bugs.python.org  Thu Feb  3 06:09:26 2022
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Thu, 03 Feb 2022 11:09:26 +0000
Subject: [issue46624] random.randrange removed support for non-integer types
 after just one release of deprecation
In-Reply-To: <1643885521.08.0.473990761772.issue46624@roundup.psfhosted.org>
Message-ID: <1643886566.32.0.900622308371.issue46624@roundup.psfhosted.org>


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

Proposed the revert at https://github.com/python/cpython/pull/31098

----------

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

From report at bugs.python.org  Thu Feb  3 06:44:05 2022
From: report at bugs.python.org (Simon Arlott)
Date: Thu, 03 Feb 2022 11:44:05 +0000
Subject: [issue41962] Make threading._register_atexit public?
In-Reply-To: <1602032984.5.0.326433134447.issue41962@roundup.psfhosted.org>
Message-ID: <1643888645.58.0.591248406502.issue41962@roundup.psfhosted.org>


Simon Arlott <python.simon at arlott.org> added the comment:

Another way to do this is to call threading.main_thread().join() in another thread and do the shutdown cleanup when it returns.

The main thread is stopped at shutdown just before the threading._threading_atexits are called.

----------
nosy: +sa

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

From report at bugs.python.org  Thu Feb  3 07:34:15 2022
From: report at bugs.python.org (Thomas Grainger)
Date: Thu, 03 Feb 2022 12:34:15 +0000
Subject: [issue44863] Allow TypedDict to inherit from Generics
In-Reply-To: <1628363087.29.0.710236107674.issue44863@roundup.psfhosted.org>
Message-ID: <1643891655.78.0.11675387174.issue44863@roundup.psfhosted.org>


Thomas Grainger <tagrain at gmail.com> added the comment:

there's a thread on typing-sig for this now: https://mail.python.org/archives/list/typing-sig at python.org/thread/I7P3ER2NH7SENVMIXK74U6L4Z5JDLQGZ/#I7P3ER2NH7SENVMIXK74U6L4Z5JDLQGZ

----------
nosy: +graingert

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

From report at bugs.python.org  Thu Feb  3 07:44:03 2022
From: report at bugs.python.org (timka)
Date: Thu, 03 Feb 2022 12:44:03 +0000
Subject: [issue38119] resource tracker destroys shared memory segments when
 other processes should still have valid access
In-Reply-To: <1568217506.85.0.770661201111.issue38119@roundup.psfhosted.org>
Message-ID: <1643892243.85.0.480924492334.issue38119@roundup.psfhosted.org>


timka <tim at kaluza.space> added the comment:

On the long run: Maybe this could solve some win32api problems?

https://devblogs.microsoft.com/commandline/af_unix-comes-to-windows/

----------
nosy: +timka

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

From report at bugs.python.org  Thu Feb  3 08:33:04 2022
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 03 Feb 2022 13:33:04 +0000
Subject: [issue45885] Specialize COMPARE_OP
In-Reply-To: <1637701224.16.0.881347004039.issue45885@roundup.psfhosted.org>
Message-ID: <1643895184.7.0.18189540779.issue45885@roundup.psfhosted.org>


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


New changeset 674ab66ebdf06f187e193a3d7bde13b71ba0f9af by Dennis Sweeney in branch 'main':
bpo-45885: Add more stats for COMPARE_OP in specialize.c (GH-31040)
https://github.com/python/cpython/commit/674ab66ebdf06f187e193a3d7bde13b71ba0f9af


----------

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

From report at bugs.python.org  Thu Feb  3 08:48:21 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 03 Feb 2022 13:48:21 +0000
Subject: [issue46624] random.randrange removed support for non-integer types
 after just one release of deprecation
In-Reply-To: <1643885521.08.0.473990761772.issue46624@roundup.psfhosted.org>
Message-ID: <1643896101.62.0.169525535478.issue46624@roundup.psfhosted.org>


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


New changeset 6baa98e538b2e26f16eaaf462f99496e98d2cfb1 by Miro Hron?ok in branch 'main':
bpo-46624: Defer to 3.12: "Remove deprecated support for non-integer values" (GH-31098)
https://github.com/python/cpython/commit/6baa98e538b2e26f16eaaf462f99496e98d2cfb1


----------

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

From report at bugs.python.org  Thu Feb  3 08:48:43 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 03 Feb 2022 13:48:43 +0000
Subject: [issue46624] random.randrange removed support for non-integer types
 after just one release of deprecation
In-Reply-To: <1643885521.08.0.473990761772.issue46624@roundup.psfhosted.org>
Message-ID: <1643896123.11.0.675848744807.issue46624@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/issue46624>
_______________________________________

From report at bugs.python.org  Thu Feb  3 09:18:19 2022
From: report at bugs.python.org (Nicolas SURRIBAS)
Date: Thu, 03 Feb 2022 14:18:19 +0000
Subject: [issue46625] timeout option of socket.create_connection is not
 respected
Message-ID: <1643897899.25.0.188715237752.issue46625@roundup.psfhosted.org>


New submission from Nicolas SURRIBAS <nicolas.surribas at gmail.com>:

When passing to socket.create_connection a timeout option above (approximately) 127 seconds, the timeout is not respected. 

Code to reproduce the issue :

import socket
from time import monotonic

print(socket.getdefaulttimeout())
start = monotonic()
try:
    socket.create_connection(("1.1.1.1", 21), 300)
except Exception as exception:
    print(exception)

print(monotonic() - start)

Output at execution:

None
[Errno 110] Connection timed out
129.3075186319984

Expected behavior would be that the "Connection timed out" exception is raised after 300 seconds, as given in argument, not 129.

Observed with Python 3.9.1

----------
components: IO
messages: 412443
nosy: Nicolas SURRIBAS
priority: normal
severity: normal
status: open
title: timeout option of socket.create_connection is not respected
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Thu Feb  3 09:22:04 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 03 Feb 2022 14:22:04 +0000
Subject: [issue46615] Use-after-free by mutating set during set operations
In-Reply-To: <1643824882.75.0.278611227582.issue46615@roundup.psfhosted.org>
Message-ID: <1643898124.27.0.661593068544.issue46615@roundup.psfhosted.org>


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

The likely culprit is the set_next() loop.  Perhaps it is never safe to use set_next() because any lookup can callback to __eq__ which can mutate the set.

Since set_isdisjoint() method isn't a mutating method, that is the easiest place to start investigating.  Try disabling the exact set fast path to see if the issue persists.

----------

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

From report at bugs.python.org  Thu Feb  3 10:22:53 2022
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 03 Feb 2022 15:22:53 +0000
Subject: [issue46569] final note on StrEnum documentation incorrectly refers
 to int.__format__ instead of str.__format__
In-Reply-To: <1643450429.02.0.752906644712.issue46569@roundup.psfhosted.org>
Message-ID: <1643901773.6.0.663776299665.issue46569@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:


New changeset 734b1f119be6f0dcd6845c78a9e0a71d88a90b59 by Nikita Sobolev in branch 'main':
bpo-46569: [Enum] fix typo in `StrEnum` docs (GH-31007)
https://github.com/python/cpython/commit/734b1f119be6f0dcd6845c78a9e0a71d88a90b59


----------

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

From report at bugs.python.org  Thu Feb  3 10:23:24 2022
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 03 Feb 2022 15:23:24 +0000
Subject: [issue46569] final note on StrEnum documentation incorrectly refers
 to int.__format__ instead of str.__format__
In-Reply-To: <1643450429.02.0.752906644712.issue46569@roundup.psfhosted.org>
Message-ID: <1643901804.48.0.962512838512.issue46569@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/issue46569>
_______________________________________

From report at bugs.python.org  Thu Feb  3 10:29:01 2022
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Feb 2022 15:29:01 +0000
Subject: [issue45773] Compiler hangs during jump elimination
In-Reply-To: <1636487782.5.0.379047434297.issue45773@roundup.psfhosted.org>
Message-ID: <1643902141.89.0.77847370423.issue45773@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: +29284
pull_request: https://github.com/python/cpython/pull/31101

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

From report at bugs.python.org  Thu Feb  3 10:51:14 2022
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Feb 2022 15:51:14 +0000
Subject: [issue46436] Pass the -d/--directory command-line option to
 http.server.CGIHTTPRequestHandler
In-Reply-To: <1642613980.51.0.0570385311323.issue46436@roundup.psfhosted.org>
Message-ID: <1643903474.07.0.396168682785.issue46436@roundup.psfhosted.org>


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


New changeset 2d080347d74078a55c47715d232d1ab8dc8cd603 by G?ry Ogam in branch 'main':
bpo-46436: Fix command-line option -d/--directory in module http.server (GH-30701)
https://github.com/python/cpython/commit/2d080347d74078a55c47715d232d1ab8dc8cd603


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

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

From report at bugs.python.org  Thu Feb  3 10:51:17 2022
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Feb 2022 15:51:17 +0000
Subject: [issue46436] Pass the -d/--directory command-line option to
 http.server.CGIHTTPRequestHandler
In-Reply-To: <1642613980.51.0.0570385311323.issue46436@roundup.psfhosted.org>
Message-ID: <1643903477.56.0.448214966716.issue46436@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Thu Feb  3 10:51:22 2022
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Feb 2022 15:51:22 +0000
Subject: [issue46436] Pass the -d/--directory command-line option to
 http.server.CGIHTTPRequestHandler
In-Reply-To: <1642613980.51.0.0570385311323.issue46436@roundup.psfhosted.org>
Message-ID: <1643903482.31.0.0308766661085.issue46436@roundup.psfhosted.org>


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


----------
pull_requests: +29286
pull_request: https://github.com/python/cpython/pull/31103

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

From report at bugs.python.org  Thu Feb  3 10:54:59 2022
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Feb 2022 15:54:59 +0000
Subject: [issue45773] Compiler hangs during jump elimination
In-Reply-To: <1636487782.5.0.379047434297.issue45773@roundup.psfhosted.org>
Message-ID: <1643903699.2.0.588456371177.issue45773@roundup.psfhosted.org>


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


New changeset ff6948b1286c854ee77dfc0b23b9d828b36873e4 by Miss Islington (bot) in branch '3.10':
bpo-45773: Remove invalid peephole optimizations (GH-31066)
https://github.com/python/cpython/commit/ff6948b1286c854ee77dfc0b23b9d828b36873e4


----------

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

From report at bugs.python.org  Thu Feb  3 10:57:34 2022
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 03 Feb 2022 15:57:34 +0000
Subject: [issue46285] protocol_version in http.server.test can be ignored
In-Reply-To: <1641494361.52.0.586828537376.issue46285@roundup.psfhosted.org>
Message-ID: <1643903854.9.0.754615801983.issue46285@roundup.psfhosted.org>


Change by ?ric Araujo <merwok at netwok.org>:


----------
dependencies: +Pass the -d/--directory command-line option to http.server.CGIHTTPRequestHandler
versions:  -Python 3.10, Python 3.9

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

From report at bugs.python.org  Thu Feb  3 11:04:53 2022
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 03 Feb 2022 16:04:53 +0000
Subject: [issue45773] Compiler hangs during jump elimination
In-Reply-To: <1636487782.5.0.379047434297.issue45773@roundup.psfhosted.org>
Message-ID: <1643904293.17.0.958433251792.issue45773@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


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

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

From report at bugs.python.org  Thu Feb  3 11:42:14 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 03 Feb 2022 16:42:14 +0000
Subject: [issue46615] Use-after-free by mutating set during set operations
In-Reply-To: <1643824882.75.0.278611227582.issue46615@roundup.psfhosted.org>
Message-ID: <1643906534.15.0.576271807029.issue46615@roundup.psfhosted.org>


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

Presumably _PyDict_Next is also suspect.  Even the advertised "safe" calls to PyDict_SetItem() for existing keys would be a trigger.  Calling clear() in either __eq__ or __hash__ would suffice.

If the next loops are the culprint, the new challenge is figuring out how to fix it without wrecking code clarity and performance (and having to deprecate PyDict_Next() which is part of the stable ABI).

----------

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

From report at bugs.python.org  Thu Feb  3 12:00:32 2022
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Thu, 03 Feb 2022 17:00:32 +0000
Subject: [issue46621] Should map(function, iterable,
 ...) replace StopIteration with RuntimeError?
In-Reply-To: <1643863586.75.0.713225774424.issue46621@roundup.psfhosted.org>
Message-ID: <1643907632.14.0.969493944495.issue46621@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

Just for the record, I consider PEP 479 one of (very rare) design bugs in Python, and would like it reversed some day. (So anything that helps this outcome, including -1 on this, is welcome.)

It subverts the natural property of exceptions (that they bubble through frames undisturbed until caught) for no benefit at all, and it has made me write almost every chained generator since then in a more complex way, adding boilerplate code that converts inner StopIteration to return. I'm sure many others have done so too. Ceterum censeo PEP479em esse delendam.

----------
nosy: +veky

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

From report at bugs.python.org  Thu Feb  3 12:04:37 2022
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 03 Feb 2022 17:04:37 +0000
Subject: [issue46072] Unify handling of stats in the CPython VM
In-Reply-To: <1639498673.65.0.709719181358.issue46072@roundup.psfhosted.org>
Message-ID: <1643907877.38.0.268360422914.issue46072@roundup.psfhosted.org>


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


----------
pull_requests: +29287
pull_request: https://github.com/python/cpython/pull/31104

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

From report at bugs.python.org  Thu Feb  3 12:42:54 2022
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Thu, 03 Feb 2022 17:42:54 +0000
Subject: [issue34486] "RuntimeError: release unlocked lock" when starting a
 thread
In-Reply-To: <1535119355.34.0.56676864532.issue34486@psf.upfronthosting.co.za>
Message-ID: <1643910174.74.0.973014073803.issue34486@roundup.psfhosted.org>


Change by G?ry <gery.ogam at gmail.com>:


----------
nosy: +maggyero

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

From report at bugs.python.org  Thu Feb  3 13:06:28 2022
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 03 Feb 2022 18:06:28 +0000
Subject: [issue46072] Unify handling of stats in the CPython VM
In-Reply-To: <1639498673.65.0.709719181358.issue46072@roundup.psfhosted.org>
Message-ID: <1643911588.05.0.230015319441.issue46072@roundup.psfhosted.org>


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


----------
pull_requests: +29288
pull_request: https://github.com/python/cpython/pull/31105

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

From report at bugs.python.org  Thu Feb  3 13:21:59 2022
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 03 Feb 2022 18:21:59 +0000
Subject: [issue46626] expose IP_BIND_ADDRESS_NO_PORT linux socket option
Message-ID: <1643912519.95.0.96688411003.issue46626@roundup.psfhosted.org>


Change by Benjamin Peterson <benjamin at python.org>:


----------
components: Library (Lib)
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: expose IP_BIND_ADDRESS_NO_PORT linux socket option
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Thu Feb  3 13:23:59 2022
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 03 Feb 2022 18:23:59 +0000
Subject: [issue46626] expose IP_BIND_ADDRESS_NO_PORT linux socket option
Message-ID: <1643912639.87.0.837895715213.issue46626@roundup.psfhosted.org>


Change by Benjamin Peterson <benjamin at python.org>:


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

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

From report at bugs.python.org  Thu Feb  3 13:40:18 2022
From: report at bugs.python.org (J.B. Langston)
Date: Thu, 03 Feb 2022 18:40:18 +0000
Subject: [issue46627] Regex hangs indefinitely
Message-ID: <1643913617.99.0.318274176206.issue46627@roundup.psfhosted.org>


New submission from J.B. Langston <jblangston at datastax.com>:

The following code will cause Python's regex engine to hang apparently indefinitely: 

import re
message = "Flushed to [BigTableReader(path='/data/cassandra/data/log/logEntry_202202-e68971800b2711ecaf770d5fa3f5ae87/md-112-big-Data.db')] (1 sstables, 8,650MiB), biggest 8,650MiB, smallest 8,650MiB"
regex = re.compile(r"Flushed to \[(?P<sstables>[^]]+)+\] \((?P<sstable_count>[^ ]+) sstables, (?P<total_size>[^)]+)\), biggest (?P<biggest_size>[^,]+), smallest (?P<smallest_size>[^ ]+)( \((?P<duration>\d+)ms\))?")
regex.match(message)

This may be a case of exponential backtracking similar to #35915 or #30973. Both of these issues have been closed as Wont Fix, and I suspect my issue is similar. The use of commas for decimal points in the input string was not anticipated but happened due to localization of the logs that the message came from.  The regex works properly when the decimal point is a period.

I will try to rewrite my regex to address this specific issue, but it's hard to anticipate every possible input and craft a bulletproof regex, so something like this kind of thing can be used for a denial of service attack (intentional or not). In this case the regex was used in an automated import process and caused the process to back up for many hours before someone noticed.  Maybe a solution could be to add a timeout option to the regex engine so it will give up and throw an exception if the regex executes for longer than the configured timeout.

----------
components: Regular Expressions
messages: 412450
nosy: ezio.melotti, jblangston, mrabarnett
priority: normal
severity: normal
status: open
title: Regex hangs indefinitely
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Thu Feb  3 13:46:58 2022
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 03 Feb 2022 18:46:58 +0000
Subject: [issue46626] expose IP_BIND_ADDRESS_NO_PORT linux socket option
Message-ID: <1643914018.43.0.489598482463.issue46626@roundup.psfhosted.org>


New submission from Benjamin Peterson <benjamin at python.org>:


New changeset 1aa6be06c4cb7f04a340adb1c7b16b89803ef254 by Benjamin Peterson in branch 'main':
closes bpo-46626: Expose IP_BIND_ADDRESS_NO_PORT socket option. (GH-31106)
https://github.com/python/cpython/commit/1aa6be06c4cb7f04a340adb1c7b16b89803ef254


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

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

From report at bugs.python.org  Thu Feb  3 14:03:57 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 03 Feb 2022 19:03:57 +0000
Subject: [issue45975] Simplify some while-loops with walrus operator
In-Reply-To: <1638573350.23.0.80297686747.issue45975@roundup.psfhosted.org>
Message-ID: <1643915037.89.0.706802617406.issue45975@roundup.psfhosted.org>


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


----------
pull_requests: +29290
pull_request: https://github.com/python/cpython/pull/31107

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

From report at bugs.python.org  Thu Feb  3 14:08:02 2022
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 03 Feb 2022 19:08:02 +0000
Subject: [issue46072] Unify handling of stats in the CPython VM
In-Reply-To: <1639498673.65.0.709719181358.issue46072@roundup.psfhosted.org>
Message-ID: <1643915282.77.0.809838984578.issue46072@roundup.psfhosted.org>


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


----------
pull_requests: +29291
pull_request: https://github.com/python/cpython/pull/31108

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

From report at bugs.python.org  Thu Feb  3 14:11:21 2022
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 03 Feb 2022 19:11:21 +0000
Subject: [issue46627] Regex hangs indefinitely
In-Reply-To: <1643913617.99.0.318274176206.issue46627@roundup.psfhosted.org>
Message-ID: <1643915481.57.0.597131550459.issue46627@roundup.psfhosted.org>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

That pattern has:

    (?P<sstables>[^]]+)+

Is that intentional? It looks wrong to me.

----------

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

From report at bugs.python.org  Thu Feb  3 14:14:22 2022
From: report at bugs.python.org (Paul Koning)
Date: Thu, 03 Feb 2022 19:14:22 +0000
Subject: [issue46628] Can't install YARL
Message-ID: <1643915662.48.0.0476331394582.issue46628@roundup.psfhosted.org>


New submission from Paul Koning <paulkoning at comcast.net>:

Trying to install "aiohttp" with pip I get a compile error installing "yarl".  I get the same error when I install just that module.  But it installs fine on 3.10.  This is on an Apple M1 (ARM64) machine.

----------
components: macOS
files: yarl.log
messages: 412453
nosy: ned.deily, pkoning, ronaldoussoren
priority: normal
severity: normal
status: open
title: Can't install YARL
type: compile error
versions: Python 3.11
Added file: https://bugs.python.org/file50602/yarl.log

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

From report at bugs.python.org  Thu Feb  3 14:28:48 2022
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 03 Feb 2022 19:28:48 +0000
Subject: [issue46524] test_peg_generator takes 8 minutes on Windows
In-Reply-To: <1643137563.83.0.612264685435.issue46524@roundup.psfhosted.org>
Message-ID: <1643916528.1.0.21054073672.issue46524@roundup.psfhosted.org>


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

Thanks to Kumar for contributing Windows compiler flags side of this (the point of this issue).

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

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

From report at bugs.python.org  Thu Feb  3 14:29:39 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 03 Feb 2022 19:29:39 +0000
Subject: [issue46628] Can't install YARL
In-Reply-To: <1643915662.48.0.0476331394582.issue46628@roundup.psfhosted.org>
Message-ID: <1643916579.03.0.147906374607.issue46628@roundup.psfhosted.org>


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

It looks like you're missing dependencies required to compile yarl. Since this isn't a bug with Python, I'm going to close this.

I suggest you ask the yarl community for help. Their home page is https://github.com/aio-libs/yarl/

Good luck!

----------
nosy: +eric.smith
resolution:  -> third party
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Feb  3 14:31:48 2022
From: report at bugs.python.org (J.B. Langston)
Date: Thu, 03 Feb 2022 19:31:48 +0000
Subject: [issue46627] Regex hangs indefinitely
In-Reply-To: <1643913617.99.0.318274176206.issue46627@roundup.psfhosted.org>
Message-ID: <1643916708.55.0.380613044613.issue46627@roundup.psfhosted.org>


J.B. Langston <jblangston at datastax.com> added the comment:

Yes, it is supposed to match everything up to the closing ] in this substring: 

[BigTableReader(path='/data/cassandra/data/log/logEntry_202202-e68971800b2711ecaf770d5fa3f5ae87/md-112-big-Data.db')]

Quoting from the re docs:

To match a literal ']' inside a set, precede it with a backslash, or place it at the beginning of the set. For example, both [()[\]{}] and []()[{}] will both match a parenthesis.

The docs don't specifically state the case of a negated set using ^, but I have used this construction many times and never had a problem with it.

Furthermore, it is not what caused the regex to hang.  That was caused by "(?P<biggest_size>[^,]+)," and changing it to "(?P<biggest_size>.+?)," fixed the problem.

----------

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

From report at bugs.python.org  Thu Feb  3 14:35:44 2022
From: report at bugs.python.org (Paul Koning)
Date: Thu, 03 Feb 2022 19:35:44 +0000
Subject: [issue46628] Can't install YARL
In-Reply-To: <1643915662.48.0.0476331394582.issue46628@roundup.psfhosted.org>
Message-ID: <1643916944.0.0.715049921665.issue46628@roundup.psfhosted.org>


Paul Koning <paulkoning at comcast.net> added the comment:

The only dependency mentioned by the yarl documentation is multidict and installing that makes no difference.  I see I can tell yarl to build a pure-python version to avoid compiling stuff.  If I do that it installs.  But what I actually wanted to do is install aiohttp, and that step fails with the exact same error message.

Given that it works in 3.10 but fails in 3.11a4, it does seem there is something about the new code that is involved here.

----------

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

From report at bugs.python.org  Thu Feb  3 14:38:22 2022
From: report at bugs.python.org (J.B. Langston)
Date: Thu, 03 Feb 2022 19:38:22 +0000
Subject: [issue46627] Regex hangs indefinitely
In-Reply-To: <1643913617.99.0.318274176206.issue46627@roundup.psfhosted.org>
Message-ID: <1643917102.11.0.208677530363.issue46627@roundup.psfhosted.org>


J.B. Langston <jblangston at datastax.com> added the comment:

Sorry, on rereading your message I guess you were referring to the extra +, not the [^]]. The extra + after the ) was not intentional, and after removing it, the regex no longer hangs.

I still think it would be nice to have a timeout setting on the regex so it can't hang up an entire process.

----------

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

From report at bugs.python.org  Thu Feb  3 14:44:39 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 03 Feb 2022 19:44:39 +0000
Subject: [issue45975] Simplify some while-loops with walrus operator
In-Reply-To: <1638573350.23.0.80297686747.issue45975@roundup.psfhosted.org>
Message-ID: <1643917479.83.0.243493823237.issue45975@roundup.psfhosted.org>


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


New changeset 916d0d822c79933f4c420f7a36f16f3eb788646b by Terry Jan Reedy in branch 'main':
bpo-45975: IDLE - Remove extraneous parens (GH-31107)
https://github.com/python/cpython/commit/916d0d822c79933f4c420f7a36f16f3eb788646b


----------

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

From report at bugs.python.org  Thu Feb  3 14:44:54 2022
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Feb 2022 19:44:54 +0000
Subject: [issue45975] Simplify some while-loops with walrus operator
In-Reply-To: <1638573350.23.0.80297686747.issue45975@roundup.psfhosted.org>
Message-ID: <1643917494.97.0.521940654995.issue45975@roundup.psfhosted.org>


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


----------
pull_requests: +29292
pull_request: https://github.com/python/cpython/pull/31109

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

From report at bugs.python.org  Thu Feb  3 14:44:59 2022
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Feb 2022 19:44:59 +0000
Subject: [issue45975] Simplify some while-loops with walrus operator
In-Reply-To: <1638573350.23.0.80297686747.issue45975@roundup.psfhosted.org>
Message-ID: <1643917499.02.0.167657891237.issue45975@roundup.psfhosted.org>


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


----------
pull_requests: +29293
pull_request: https://github.com/python/cpython/pull/31110

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

From report at bugs.python.org  Thu Feb  3 14:53:52 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 03 Feb 2022 19:53:52 +0000
Subject: [issue46628] Can't install YARL
In-Reply-To: <1643915662.48.0.0476331394582.issue46628@roundup.psfhosted.org>
Message-ID: <1643918032.73.0.212418918679.issue46628@roundup.psfhosted.org>


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

Ah. longintrepr.h is an internal Python file, not meant for external consumption. This file moved in Python 3.11. So this is still a yarl issue: they'll need to adjust how they read that file. But my recommendation is that they find another way to do what they want without including it.

See https://github.com/python/cpython/blob/main/Include/README.rst. Files in the cpython directory (which longintrepr.h is) are a CPython implementation detail, and can change or move at any time.

----------

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

From report at bugs.python.org  Thu Feb  3 15:01:49 2022
From: report at bugs.python.org (Steve Dower)
Date: Thu, 03 Feb 2022 20:01:49 +0000
Subject: [issue46629] Cannot sideload MSIX package on Windows
Message-ID: <1643918509.02.0.11986541964.issue46629@roundup.psfhosted.org>


New submission from Steve Dower <steve.dower at python.org>:

We need to update PC/classicAppCompat.can.xml for our new certificate and email Microsoft to get it signed again.

----------
assignee: steve.dower
messages: 412461
nosy: steve.dower
priority: normal
severity: normal
status: open
title: Cannot sideload MSIX package on Windows
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Thu Feb  3 15:02:34 2022
From: report at bugs.python.org (Paul Koning)
Date: Thu, 03 Feb 2022 20:02:34 +0000
Subject: [issue46628] Can't install YARL
In-Reply-To: <1643915662.48.0.0476331394582.issue46628@roundup.psfhosted.org>
Message-ID: <1643918554.66.0.288135601036.issue46628@roundup.psfhosted.org>


Paul Koning <paulkoning at comcast.net> added the comment:

Thanks, I'll pass the word to the yarl and aiohttp team (both have this issue).

----------

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

From report at bugs.python.org  Thu Feb  3 15:02:44 2022
From: report at bugs.python.org (Steve Dower)
Date: Thu, 03 Feb 2022 20:02:44 +0000
Subject: [issue46629] Cannot sideload MSIX package on Windows
In-Reply-To: <1643918509.02.0.11986541964.issue46629@roundup.psfhosted.org>
Message-ID: <1643918564.38.0.239547399341.issue46629@roundup.psfhosted.org>


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


----------
components: +Windows
nosy: +paul.moore, tim.golden, zach.ware

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

From report at bugs.python.org  Thu Feb  3 15:08:22 2022
From: report at bugs.python.org (=?utf-8?q?Miha_=C5=A0etina?=)
Date: Thu, 03 Feb 2022 20:08:22 +0000
Subject: [issue23041] csv needs more quoting rules
In-Reply-To: <1418402205.61.0.685044268577.issue23041@psf.upfronthosting.co.za>
Message-ID: <1643918902.36.0.395746814302.issue23041@roundup.psfhosted.org>


Miha ?etina <miha.setina at in516ht.com> added the comment:

Is this still on track for python 3.11?

----------

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

From report at bugs.python.org  Thu Feb  3 15:23:24 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 03 Feb 2022 20:23:24 +0000
Subject: [issue44796] Add __parameters__ and __getitem__ in TypeVar and
 ParamSpec
In-Reply-To: <1627738289.78.0.80035642919.issue44796@roundup.psfhosted.org>
Message-ID: <1643919804.18.0.403733186197.issue44796@roundup.psfhosted.org>


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

It does not have a use case of T[int] in mind. It is an implementation detail which simplifies the code, makes runtime checks more strict and makes types.GenericAlias more similar to typing._GenericAlias.

For example, currently:

>>> A = List[T]
>>> B = list[T]
>>> A[None]
typing.List[NoneType]
>>> B[None]
list[None]
>>> A['X']
typing.List[ForwardRef('X')]
>>> B['X']
list['X']

With the proposed change:

>>> B[None]
list[NoneType]
>>> B['X']
list[ForwardRef('X')]

Meanless expressions like A[42], A[Final], A[Final[int]], A[ClassVar], A[ClassVar[int]], etc which are silently accepted will now be errors.

The code simplification (especially for the C code) is my primary goal, and the rest is a nice side effect. It is possible to add more strict runtime checks and conversions without making TypeVar and ParamSpec subscriptable, but the code will not be so simple.

----------

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

From report at bugs.python.org  Thu Feb  3 15:37:52 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 03 Feb 2022 20:37:52 +0000
Subject: [issue46630] IDLE: Set query focus to entry box on Windows
Message-ID: <1643920672.2.0.211419458926.issue46630@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

On Mac, and I presume *nix in general, query boxes open with the focus on the first entry box, with the cursor displayed.  One can immediate enter a line number, dotted module name, or whatever. On Windows, since 3.9, one must hit Tab or click on the entry box to set the focus.  If a blank entry is an error, one can even click on OK or hit Enter and the focus will move after an error message.

idlelib/query.py already has self.entry.focus_set.  Why did that stop working in 3.9?  All patches to query.py were before May 2021 and backported to 3.8.  Perhaps the upgrade from tk 8.6.9 to 8.6.12 had an effect given the code as it is.  Text widgets have the same issue and Editor window has 'text.focus_set' in '__init__' and that works.  Whatever, moving entry.focus_set() to just after self.deiconify() works without affecting unittests both in Windows repository and 3.11 installed on macOS.

----------
assignee: terry.reedy
components: IDLE
messages: 412465
nosy: terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: Set query focus to entry box on Windows
type: behavior

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

From report at bugs.python.org  Thu Feb  3 15:40:40 2022
From: report at bugs.python.org (Steve Dower)
Date: Thu, 03 Feb 2022 20:40:40 +0000
Subject: [issue46629] Cannot sideload MSIX package on Windows
In-Reply-To: <1643918509.02.0.11986541964.issue46629@roundup.psfhosted.org>
Message-ID: <1643920840.74.0.113514057459.issue46629@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Thu Feb  3 15:44:20 2022
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Feb 2022 20:44:20 +0000
Subject: [issue45975] Simplify some while-loops with walrus operator
In-Reply-To: <1638573350.23.0.80297686747.issue45975@roundup.psfhosted.org>
Message-ID: <1643921060.12.0.302229241492.issue45975@roundup.psfhosted.org>


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


New changeset 63523e7b2a631f28134b25a8063d50e08c741db6 by Miss Islington (bot) in branch '3.10':
bpo-45975: IDLE - Remove extraneous parens (GH-31107)
https://github.com/python/cpython/commit/63523e7b2a631f28134b25a8063d50e08c741db6


----------

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

From report at bugs.python.org  Thu Feb  3 15:44:27 2022
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Feb 2022 20:44:27 +0000
Subject: [issue45975] Simplify some while-loops with walrus operator
In-Reply-To: <1638573350.23.0.80297686747.issue45975@roundup.psfhosted.org>
Message-ID: <1643921067.23.0.402380017063.issue45975@roundup.psfhosted.org>


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


New changeset cf7cb1a2bf40516dc571d1d90c12b632dcd9b8c8 by Miss Islington (bot) in branch '3.9':
bpo-45975: IDLE - Remove extraneous parens (GH-31107)
https://github.com/python/cpython/commit/cf7cb1a2bf40516dc571d1d90c12b632dcd9b8c8


----------

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

From report at bugs.python.org  Thu Feb  3 15:44:34 2022
From: report at bugs.python.org (Steve Dower)
Date: Thu, 03 Feb 2022 20:44:34 +0000
Subject: [issue46629] Cannot sideload MSIX package on Windows
In-Reply-To: <1643918509.02.0.11986541964.issue46629@roundup.psfhosted.org>
Message-ID: <1643921074.87.0.860414090147.issue46629@roundup.psfhosted.org>


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

Posted the PR for openness, but it's not ready to merge yet.

The file that's been updated there (which unfortunately is not very Unix friendly) now has the SHA256 hash of our signing certificate, and I've emailed the file to storeops at Microsoft to request them to sign it. The signed one will replace classicAppCompat.sccd

The reason we need this file is because we set globally readable registry keys on install for PEP 514 (these appear in the appxmanifest file generated by PC/layout). That's not a normal app permission, and so we have to request special permissions to do it.

----------

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

From report at bugs.python.org  Thu Feb  3 15:51:35 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 03 Feb 2022 20:51:35 +0000
Subject: [issue46630] IDLE: Set query focus to entry box on Windows
In-Reply-To: <1643920672.2.0.211419458926.issue46630@roundup.psfhosted.org>
Message-ID: <1643921495.39.0.961552819825.issue46630@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Thu Feb  3 16:05:49 2022
From: report at bugs.python.org (Ned Deily)
Date: Thu, 03 Feb 2022 21:05:49 +0000
Subject: [issue46573] Python modules such as pyglet or pygame crash Python
 when tkinter message boxes are opened on MacOS.
In-Reply-To: <1643482093.87.0.31269168021.issue46573@roundup.psfhosted.org>
Message-ID: <1643922349.58.0.255329755907.issue46573@roundup.psfhosted.org>


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

Thanks, Marc and Ronald, for the analysis.

And thanks for bringing up the issue, Remy. Perhaps you can verify that Ronald's suggestion of importing and launching Tk before calling pyglet or pygame works for you and, if so, follow up with those projects to, if nothing else, document that requirement for their users on macOS (I would guess it wouldn't hurt on other platforms as well but I've guessed wrong before). In any case, I'm closing this issue now.

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

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

From report at bugs.python.org  Thu Feb  3 16:19:02 2022
From: report at bugs.python.org (Eric Snow)
Date: Thu, 03 Feb 2022 21:19:02 +0000
Subject: [issue41962] Make threading._register_atexit public?
In-Reply-To: <1602032984.5.0.326433134447.issue41962@roundup.psfhosted.org>
Message-ID: <1643923142.6.0.840520381239.issue41962@roundup.psfhosted.org>


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

> I'm running some long-running (possibly infinite) tasks in the thread pool,
> and I cancel them in an `atexit` callback

To be clear, by "cancel" you are not talking about Future.cancel().  Rather, your handler causes all running tasks to finish (by sending a special message on the socket corresponding to each running task).  Is that right?

Some other things I inferred from your atexit handler:

* it does not make sure the task associated with the socket finishes (no way of knowing?)
* so if a task hangs while trying to stop then the running thread in the ThreadPoolExecutor would block shutdown forever
* similarly, if a task is stuck handling a request then it will never receive the special message on the socket, either blocking the send() in your handler or causing ThreadPoolExecutor shutdown/atexit to wait forever
* it vaguely implies a 1-to-1 relationship between sockets and *running* tasks
* likewise that pending (queued) tasks do not have an associated socket (until started)
* so once your handler finishes, any tasks pending in the ThreadPoolExecutor queue will eventually get started but never get stopped by your handler; thus you're back to the deadlock situation

Does all that sound right?  Most of that is relevant to some possible solutions I have in mind.

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

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

From report at bugs.python.org  Thu Feb  3 16:21:56 2022
From: report at bugs.python.org (Eric Snow)
Date: Thu, 03 Feb 2022 21:21:56 +0000
Subject: [issue41962] Make threading._register_atexit public?
In-Reply-To: <1602032984.5.0.326433134447.issue41962@roundup.psfhosted.org>
Message-ID: <1643923316.58.0.332312205916.issue41962@roundup.psfhosted.org>


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

> I'm running some long-running (possibly infinite) tasks in the thread pool,
> and I cancel them in an `atexit` callback

Alternately, perhaps ThreadPoolExecutor isn't the right fit here, as implied by the route you ended up going.  It seems like it's not well-suited for long-running (or infinite) tasks.  In that case, perhaps the concurrent.futures docs could be more clear about when ThreadPoolExecutor is not a good fit and what the alternatives are.

----------

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

From report at bugs.python.org  Thu Feb  3 16:27:24 2022
From: report at bugs.python.org (Eric Snow)
Date: Thu, 03 Feb 2022 21:27:24 +0000
Subject: [issue41962] Make threading._register_atexit public?
In-Reply-To: <1602032984.5.0.326433134447.issue41962@roundup.psfhosted.org>
Message-ID: <1643923644.64.0.270277458291.issue41962@roundup.psfhosted.org>


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

FWIW, here's a brain dump about ThreadPoolExecutor and its atexit handler after having looked at the code.

----

First, the relationship between the objects involved:

* work item -> Future
* work item -> task (e.g. function)
* queue -> [work item]
* worker -> executor
* worker -> queue
* worker -> currently running work item
* thread -> worker
* ThreadPoolExecutor -> [thread]
* ThreadPoolExecutor -> queue
* global state -> {thread: queue}

Observations:

* a work item's future and task are not aware of each other, and operations on either have no effect on the other

----

Next, let's look at the relevant ways the objects can be used:

* publicly
   * ThreadPoolExecutor.submit(task) -> Future
   * ThreadPoolExecutor.shutdown()
   * Future.result() and Future.exception()
   * Future.cancel()
   * Future.add_done_callback()
* internally
   * queue.pop() -> work item
   * <work item>.run()
   * thread.join()
   * Future.set_running_or_notify_cancel()
   * Future.set_result() and Future.set_exception()

Observations:

* nothing interacts with a worker directly; it is waited on via its thread and it receives work (or None) via the queue it was given
* once a worker pops the next work item off the queue, nothing else has access to that work item (the original ThreadPoolExecutor().submit() caller has the Future, but that's it)
* there is no cancelation mechanism for tasks
* there is no simple way to interact with the queued tasks
* realistically, there is no way to interact with the currently running task
* there is no reliable way to "kill" a thread

----

Regarding how tasks run:

* ThreadPoolExecutor.submit(task) -> Future
* ThreadPoolExecutor.submit(task) -> work item (Future, task) -> queue
* ThreadPoolExecutor.submit(task) -> thread (worker)
* thread -> worker -> ( queue -> work item -> task )

Observations::

* the worker loop exits if the next item in the queue is None (and the executor is shutting down)

----

Now lets look more closely at the atexit handler.

* as you noted, since 3.9 it is registered with threading._register_atexit() instead of atexit.register()
* the threading atexit handlers run before the regular atexit handlers
* the ThreadPoolExecutor handler does not actually interact with ThreadPoolExecutor instances directly
* it only deals with a module-global list of (thread, [work item]) pairs, to which ThreadPoolExecutor instances add items as they go

The handler does the following:

1. disables ThreadPoolExecutor.submit() (for all instances)
2. (indirectly) tells each worker to stop ASAP
3. lets every pending task run (and lets every running task keep running)
4. waits until all tasks have finished

It does not:

* call any ThreadPoolExecutor.shutdown()
* otherwise deal with the ThreadPoolExecutor instances directly
* call Future.cancel() for any of the tasks
* use any timeout in step 4, so it may block forever
* notify tasks that they should finish
* deal well with any long-running (or infinite) task

ThreadPoolExecutor.shutdown() basically does the same thing.  However, it only does the steps above for its own tasks.  It also optionally calls Future.cancel() for each queued task (right before step 2).  However, all that does is keep any queued-but-not-running tasks from starting.  Also, you can optionally skips step 4.

----------

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

From report at bugs.python.org  Thu Feb  3 16:36:10 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 03 Feb 2022 21:36:10 +0000
Subject: [issue46200] Discourage logging f-strings due to security
 considerations
In-Reply-To: <1640850255.25.0.496981368409.issue46200@roundup.psfhosted.org>
Message-ID: <1643924170.56.0.612581318118.issue46200@roundup.psfhosted.org>


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

> Eric is absolutely right, due to function calls being 
> somewhat slow in Python the performance argument in
> practice falls in favor of f-strings.

Also f-strings can evaluate expressions in the template which is also a big win:

   f('Pending {len(req)} requests: {req[0]!r} ... {req[-1]!r}')

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

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

From report at bugs.python.org  Thu Feb  3 16:40:34 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 03 Feb 2022 21:40:34 +0000
Subject: [issue46200] Discourage logging f-strings due to security
 considerations
In-Reply-To: <1640850255.25.0.496981368409.issue46200@roundup.psfhosted.org>
Message-ID: <1643924434.17.0.369988733368.issue46200@roundup.psfhosted.org>


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

In a favor of deferred substitution, the cookbook should have a recipe where substituted messages are logged to a file and the unsubstituted message stored in SQLite3 database with the parameters stored as JSON.    This gives both human readable output and queryable, preparsed data for automated analysis.

----------

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

From report at bugs.python.org  Thu Feb  3 16:55:07 2022
From: report at bugs.python.org (Eric Snow)
Date: Thu, 03 Feb 2022 21:55:07 +0000
Subject: [issue41962] Make threading._register_atexit public?
In-Reply-To: <1602032984.5.0.326433134447.issue41962@roundup.psfhosted.org>
Message-ID: <1643925307.91.0.166736334915.issue41962@roundup.psfhosted.org>


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

> This means that ThreadPoolExecutor's atexit runs before mine,
> and since I never get a chance to cancel my tasks, it deadlocks.

(assuming we want to support long-running tasks here)

With all the above in mind, there are a few things that may help.

The first that comes to mind is to have the atexit handler call ThreadPoolExecutor.shutdown() for each instance.

So something like this:


def _python_exit():
    global _shutdown
    with _global_shutdown_lock:
        _shutdown = True
    for executor in list(_executors):
        executor.shutdown()


That would require a little refactoring to make it work.  However, the change is simpler if each executor has its own atexit handler:


class ThreadPoolExecutor(_base.Executor):

    def __init__(self, ...):
        ...
        threading._register_atexit(self._atexit())

    def _atexit(self):
        global _shutdown
        _shutdown = True
        self.shutdown()


The value of either approach is that you can then subclass ThreadPoolExecutor to get what you want:


class MyExecutor(ThreadPoolExecutor):
    def shutdown(self, *args, **kwargs):
        stop_my_tasks()
        super().shutdown(*args, **kwwargs)


----

One thing I thought about was supporting a per-task finalizer instead, since that aligns more closely with the way ThreadPoolExecutor works.  It would only apply  So something like one of the following:

* ThreadPoolExecutor(finalize_task=<callable>)
* ThreadPoolExecutor.submit(finalize=<callable)

----

Other things that could be helpful:

* always cancel all the pending tasks during shutdown (and maybe let users opt out)
* use a timeout during shutdown

----

FWIW, adding support for some sort of sub-atexit handler isn't so appealing.  I'm talking about something like one of the following:

* ThreadPoolExecutor(onshutdown=<callable>)
* ThreadPoolExecutor.register_atexit(<callable>)
* (classmethod) ThreadPoolExecutor.register_atexit(<callable>)
* concurrent.futures.register_atexit(<callable>)

(It would probably make sense to pass the list of currently running tasks to the callable.)

----------

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

From report at bugs.python.org  Thu Feb  3 16:57:12 2022
From: report at bugs.python.org (Steve Dower)
Date: Thu, 03 Feb 2022 21:57:12 +0000
Subject: [issue33125] Windows 10 ARM64 platform support
In-Reply-To: <1521767011.97.0.467229070634.issue33125@psf.upfronthosting.co.za>
Message-ID: <1643925432.01.0.537915193384.issue33125@roundup.psfhosted.org>


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

Closing this issue, as we have others to track individual tasks.

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

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

From report at bugs.python.org  Thu Feb  3 17:06:25 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 03 Feb 2022 22:06:25 +0000
Subject: [issue46630] IDLE: Set query focus to entry box on Windows
In-Reply-To: <1643920672.2.0.211419458926.issue46630@roundup.psfhosted.org>
Message-ID: <1643925985.46.0.800956781177.issue46630@roundup.psfhosted.org>


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


New changeset d1df81a730499cc6286d02afa6028a1e9c22bbbf by Terry Jan Reedy in branch 'main':
bpo-46630: Fix initial focus of IDLE query dialogs (GH-31112)
https://github.com/python/cpython/commit/d1df81a730499cc6286d02afa6028a1e9c22bbbf


----------

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

From report at bugs.python.org  Thu Feb  3 17:06:26 2022
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Feb 2022 22:06:26 +0000
Subject: [issue46630] IDLE: Set query focus to entry box on Windows
In-Reply-To: <1643920672.2.0.211419458926.issue46630@roundup.psfhosted.org>
Message-ID: <1643925986.27.0.743001699614.issue46630@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: +29296
pull_request: https://github.com/python/cpython/pull/31114

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

From report at bugs.python.org  Thu Feb  3 17:06:30 2022
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Feb 2022 22:06:30 +0000
Subject: [issue46630] IDLE: Set query focus to entry box on Windows
In-Reply-To: <1643920672.2.0.211419458926.issue46630@roundup.psfhosted.org>
Message-ID: <1643925990.7.0.969620112495.issue46630@roundup.psfhosted.org>


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


----------
pull_requests: +29297
pull_request: https://github.com/python/cpython/pull/31115

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

From report at bugs.python.org  Thu Feb  3 17:11:26 2022
From: report at bugs.python.org (Irit Katriel)
Date: Thu, 03 Feb 2022 22:11:26 +0000
Subject: [issue42926] Split compiler into code-gen, optimizer and assembler.
In-Reply-To: <1610550204.0.0.923150494092.issue42926@roundup.psfhosted.org>
Message-ID: <1643926286.53.0.297788508907.issue42926@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Thu Feb  3 17:32:06 2022
From: report at bugs.python.org (Tommy Vercetti)
Date: Thu, 03 Feb 2022 22:32:06 +0000
Subject: [issue33125] Windows 10 ARM64 platform support
In-Reply-To: <1521767011.97.0.467229070634.issue33125@psf.upfronthosting.co.za>
Message-ID: <1643927526.57.0.333869323155.issue33125@roundup.psfhosted.org>


Tommy Vercetti <tommyvct at outlook.com> added the comment:

Thank you Steve!

----------

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

From report at bugs.python.org  Thu Feb  3 17:33:34 2022
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Feb 2022 22:33:34 +0000
Subject: [issue46630] IDLE: Set query focus to entry box on Windows
In-Reply-To: <1643920672.2.0.211419458926.issue46630@roundup.psfhosted.org>
Message-ID: <1643927614.5.0.832489713904.issue46630@roundup.psfhosted.org>


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


New changeset dc315f30f86a1dc7c4607398b379d7c0b55c7549 by Miss Islington (bot) in branch '3.9':
bpo-46630: Fix initial focus of IDLE query dialogs (GH-31112)
https://github.com/python/cpython/commit/dc315f30f86a1dc7c4607398b379d7c0b55c7549


----------

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

From report at bugs.python.org  Thu Feb  3 17:34:09 2022
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Feb 2022 22:34:09 +0000
Subject: [issue46630] IDLE: Set query focus to entry box on Windows
In-Reply-To: <1643920672.2.0.211419458926.issue46630@roundup.psfhosted.org>
Message-ID: <1643927649.4.0.343968264817.issue46630@roundup.psfhosted.org>


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


New changeset 4f76b3667d856a13107c65d44d802d0e73c3f104 by Miss Islington (bot) in branch '3.10':
bpo-46630: Fix initial focus of IDLE query dialogs (GH-31112)
https://github.com/python/cpython/commit/4f76b3667d856a13107c65d44d802d0e73c3f104


----------

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

From report at bugs.python.org  Thu Feb  3 17:36:04 2022
From: report at bugs.python.org (Tommy Vercetti)
Date: Thu, 03 Feb 2022 22:36:04 +0000
Subject: [issue46566] Support -3.11-arm64 in py.exe launcher
In-Reply-To: <1643388779.11.0.426548045355.issue46566@roundup.psfhosted.org>
Message-ID: <1643927764.91.0.275336158259.issue46566@roundup.psfhosted.org>


Tommy Vercetti <tommyvct at outlook.com> added the comment:

PEP 514 looks good to me

----------
nosy: +TommyVCT

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

From report at bugs.python.org  Thu Feb  3 17:43:56 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 03 Feb 2022 22:43:56 +0000
Subject: [issue46630] IDLE: Set query focus to entry box on Windows
In-Reply-To: <1643920672.2.0.211419458926.issue46630@roundup.psfhosted.org>
Message-ID: <1643928236.61.0.69320587484.issue46630@roundup.psfhosted.org>


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


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Thu Feb  3 17:47:27 2022
From: report at bugs.python.org (Erlend E. Aasland)
Date: Thu, 03 Feb 2022 22:47:27 +0000
Subject: [issue46433] _PyType_GetModuleByDef optimization is incorrect
In-Reply-To: <1642607197.61.0.0970144809853.issue46433@roundup.psfhosted.org>
Message-ID: <1643928447.22.0.809329274128.issue46433@roundup.psfhosted.org>


Erlend E. Aasland <erlend.aasland at innova.no> added the comment:

It looks like this can be closed. Petr?

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

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

From report at bugs.python.org  Thu Feb  3 17:52:07 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 03 Feb 2022 22:52:07 +0000
Subject: [issue44796] Add __parameters__ and __getitem__ in TypeVar and
 ParamSpec
In-Reply-To: <1627738289.78.0.80035642919.issue44796@roundup.psfhosted.org>
Message-ID: <1643928727.68.0.0919413099844.issue44796@roundup.psfhosted.org>


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

I don't think that changing list[None] to list[NoneType] in the output is an improvement. I do appreciate the reduction in C code though!

----------

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

From report at bugs.python.org  Thu Feb  3 18:02:06 2022
From: report at bugs.python.org (Alex Waygood)
Date: Thu, 03 Feb 2022 23:02:06 +0000
Subject: [issue44796] Add __parameters__ and __getitem__ in TypeVar and
 ParamSpec
In-Reply-To: <1627738289.78.0.80035642919.issue44796@roundup.psfhosted.org>
Message-ID: <1643929326.84.0.851926588651.issue44796@roundup.psfhosted.org>


Change by Alex Waygood <Alex.Waygood at Gmail.com>:


----------
nosy: +AlexWaygood, sobolevn

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

From report at bugs.python.org  Thu Feb  3 18:10:49 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Thu, 03 Feb 2022 23:10:49 +0000
Subject: [issue44796] Add __parameters__ and __getitem__ in TypeVar and
 ParamSpec
In-Reply-To: <1627738289.78.0.80035642919.issue44796@roundup.psfhosted.org>
Message-ID: <1643929849.92.0.283696518736.issue44796@roundup.psfhosted.org>


Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:

I'd also be wary about making changes that introduce additional runtime checks. As we've seen with the PEP 612 and 646 implementations, those can impede future iteration on typing.

----------

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

From report at bugs.python.org  Thu Feb  3 18:18:38 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 03 Feb 2022 23:18:38 +0000
Subject: [issue45380] help() appears confused about the module of
 typing.Annotated
In-Reply-To: <1633458543.21.0.19270161871.issue45380@roundup.psfhosted.org>
Message-ID: <1643930318.71.0.666849364129.issue45380@roundup.psfhosted.org>


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

It looks like __metadata__ was *meant* to be a public attribute, but somehow overseen when the PEP and docs were written. :-(

I don't know anything about this class, really.

----------

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

From report at bugs.python.org  Thu Feb  3 18:31:04 2022
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Feb 2022 23:31:04 +0000
Subject: [issue44949] test_readline: test_auto_history_disabled() fails
 randomly on aarch64 RHEL8 Refleaks 3.9, 3.10 and 3.x
In-Reply-To: <1629299356.46.0.606067543476.issue44949@roundup.psfhosted.org>
Message-ID: <1643931064.73.0.097466822766.issue44949@roundup.psfhosted.org>


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


----------
pull_requests: +29299
pull_request: https://github.com/python/cpython/pull/31118

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

From report at bugs.python.org  Thu Feb  3 18:32:27 2022
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Feb 2022 23:32:27 +0000
Subject: [issue14916] PyRun_InteractiveLoop fails to run interactively when
 using a Linux pty that's not tied to stdin/stdout
In-Reply-To: <1337960558.56.0.442179213708.issue14916@psf.upfronthosting.co.za>
Message-ID: <1643931147.74.0.904725694413.issue14916@roundup.psfhosted.org>


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


New changeset 91e888904478271c27c52c773863b41f5a8f7f30 by Miss Islington (bot) in branch '3.10':
bpo-14916: use specified tokenizer fd for file input (GH-31006)
https://github.com/python/cpython/commit/91e888904478271c27c52c773863b41f5a8f7f30


----------

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

From report at bugs.python.org  Thu Feb  3 18:56:01 2022
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 03 Feb 2022 23:56:01 +0000
Subject: [issue33178] Add support for BigEndianUnion and LittleEndianUnion in
 ctypes
In-Reply-To: <1522331303.68.0.467229070634.issue33178@psf.upfronthosting.co.za>
Message-ID: <1643932561.89.0.493118180873.issue33178@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith
versions: +Python 3.11 -Python 2.7, Python 3.6

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

From report at bugs.python.org  Thu Feb  3 20:02:45 2022
From: report at bugs.python.org (Caio Agiani)
Date: Fri, 04 Feb 2022 01:02:45 +0000
Subject: [issue46588] fix typo in test_calltip.py
Message-ID: <1643936565.27.0.391641021125.issue46588@roundup.psfhosted.org>


Change by Caio Agiani <agianicaio at gmail.com>:


----------
pull_requests: +29300
pull_request: https://github.com/python/cpython/pull/31119

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

From report at bugs.python.org  Thu Feb  3 20:19:08 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 04 Feb 2022 01:19:08 +0000
Subject: [issue46615] Use-after-free by mutating set during set operations
In-Reply-To: <1643824882.75.0.278611227582.issue46615@roundup.psfhosted.org>
Message-ID: <1643937548.23.0.967393372523.issue46615@roundup.psfhosted.org>


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

Marking as low priority given that ehe next loop code has been deployed without incident for two decades (a little less for sets and a little more for dicts).

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

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

From report at bugs.python.org  Thu Feb  3 20:34:21 2022
From: report at bugs.python.org (Eric Snow)
Date: Fri, 04 Feb 2022 01:34:21 +0000
Subject: [issue46541] Replace _Py_IDENTIFIER() with statically initialized
 objects.
In-Reply-To: <1643234464.46.0.949364478641.issue46541@roundup.psfhosted.org>
Message-ID: <1643938461.12.0.505001669712.issue46541@roundup.psfhosted.org>


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

(thanks Victor: https://mail.python.org/archives/list/python-dev at python.org/message/7RMLIJHUWVBZFV747TFEHOE6LNBVQSMM/)

3rd party use of _Py_IDENTIFIER():

* blender
   + https://github.com/blender/blender/blob/master/source/blender/python/intern/bpy_traceback.c#L53
      - copied from core code
      - "msg", "filename", "lineno", "offset", "text", "<string>"
      - uses _PyObject_GetAttrId()
* datatable
   + https://github.com/h2oai/datatable/blob/45a87337bc68576c7fb6900f524925d4fb77d6a6/src/core/python/obj.cc#L76
      - in C++ wrapper getting sys.stdout, etc. and writing to sys.stdout
      - has to hack around C++14 support
      - has a fallback under limited API
      - "stdin", "stdout", "stderr", "write"
      - uses _PySys_GetObjectId(), _PyObject_GetAttrId()
* multidict (in aiohttp)
   + https://github.com/aio-libs/multidict/blob/6dedb623cca8e8fe64f502dfa479826efc321385/multidict/_multilib/defs.h#L8
   + https://github.com/aio-libs/multidict/blob/6dedb623cca8e8fe64f502dfa479826efc321385/multidict/_multilib/istr.h#L46
   + https://github.com/aio-libs/multidict/blob/6dedb623cca8e8fe64f502dfa479826efc321385/multidict/_multilib/pair_list.h#L114
      - calling str.lower()
      - "lower"
      - uses _PyObject_CallMethodId()
* mypy (exclusively in mypyc, including in generated code!)
   + https://github.com/python/mypy/blob/3c935bdd1332672f5daeae7f3f9a858a453333d4/mypyc/lib-rt/dict_ops.c#L76
   + https://github.com/python/mypy/blob/3c935bdd1332672f5daeae7f3f9a858a453333d4/mypyc/lib-rt/dict_ops.c#L131
      - "setdefault", "update"
      - uses _PyObject_CallMethodIdObjArgs(), _PyObject_CallMethodIdOneArg()
   + https://github.com/python/mypy/blob/2b7e2df923f7e4a3a199915b3c8563f45bc69dfa/mypyc/lib-rt/pythonsupport.h#L26
   + https://github.com/python/mypy/blob/2b7e2df923f7e4a3a199915b3c8563f45bc69dfa/mypyc/lib-rt/pythonsupport.h#L109
      - "__mro_entries__", "__init_subclass__"
      - uses _PyObject_LookupAttrId(), _PyObject_GetAttrId()
   + https://github.com/python/mypy/blob/2b7e2df923f7e4a3a199915b3c8563f45bc69dfa/mypyc/lib-rt/misc_ops.c#L27
   + https://github.com/python/mypy/blob/2b7e2df923f7e4a3a199915b3c8563f45bc69dfa/mypyc/lib-rt/misc_ops.c#L47
      - "send", "throw", "close"
      - uses _PyObject_CallMethodIdOneArg(), _PyObject_GetAttrId()
   + https://github.com/python/mypy/blob/8c5c915a89ec0f35b3e07332c7090e62f143043e/mypyc/lib-rt/bytes_ops.c#L104
      - "join"
      - uses _PyObject_CallMethodIdOneArg()
   + https://github.com/python/mypy/blob/3c935bdd1332672f5daeae7f3f9a858a453333d4/mypyc/codegen/emitwrapper.py#L326
   + https://github.com/python/mypy/blob/2b7e2df923f7e4a3a199915b3c8563f45bc69dfa/mypyc/lib-rt/misc_ops.c#L694
      - uses _PyObject_GetAttrId()
* pickle5
   + https://github.com/pitrou/pickle5-backport/blob/e6117502435aba2901585cc6c692fb9582545f08/pickle5/_pickle.c#L224
   + https://github.com/pitrou/pickle5-backport/blob/e6117502435aba2901585cc6c692fb9582545f08/pickle5/compat.h
      - "getattr"
      - uses _PyUnicode_FromId()
* pysqlite3
   + https://github.com/coleifer/pysqlite3/blob/f302859dc9ddb47a1089324dbca3873740b74af9/src/microprotocols.c#L103
   + https://github.com/coleifer/pysqlite3/blob/f302859dc9ddb47a1089324dbca3873740b74af9/src/microprotocols.c#L119
      - "__adapt__", "__conform__"
      - uses _PyObject_CallMethodId()
   + https://github.com/coleifer/pysqlite3/blob/093b88d1a58b141db8cf971c35ea1f6b674d0d02/src/connection.c#L51
   + https://github.com/coleifer/pysqlite3/blob/093b88d1a58b141db8cf971c35ea1f6b674d0d02/src/connection.c#L772
      - "finalize", "value", "upper", "cursor"
      - uses _PyObject_CallMethodId(), _PyObject_CallMethodIdObjArgs()
   + https://github.com/coleifer/pysqlite3/blob/49ce9c7a89a3c9f47ab8d32b6c4e2f7d629c1688/src/module.c#L195
      - "upper"
      - uses _PyObject_CallMethodId()
   + https://github.com/coleifer/pysqlite3/blob/91b2664f525b19feedfca3f0913302c6f1e8be8a/src/cursor.c#L103
      - "upper"
      - uses _PyObject_CallMethodId()
* typed_ast
   + a fork of CPython's ast code
* zodbpickle
   + a fork of CPython's pickle

All of them should be trivial to drop _Py_IDENTIFIER() without any real performance impact or mess.

Also, the following implies that PyPy has some sort of _Py_IDENTIFIER() support: https://github.com/benhoyt/scandir/blob/3396aa4155ffde8600a0e9ca50d5872569169b5d/_scandir.c#L51.

----------

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

From report at bugs.python.org  Thu Feb  3 22:12:21 2022
From: report at bugs.python.org (Dennis Sweeney)
Date: Fri, 04 Feb 2022 03:12:21 +0000
Subject: [issue46615] Use-after-free by mutating set during set operations
In-Reply-To: <1643824882.75.0.278611227582.issue46615@roundup.psfhosted.org>
Message-ID: <1643944341.01.0.253824066883.issue46615@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

It looks like usages of the PyDict_Next API assume the resulting references are borrowed and so INCREF them.

Usages of set_next do not, but should.

It should hopefully be a straightforward fix of adding INCREF/DECREFs.

----------

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

From report at bugs.python.org  Thu Feb  3 23:24:42 2022
From: report at bugs.python.org (Dennis Sweeney)
Date: Fri, 04 Feb 2022 04:24:42 +0000
Subject: [issue46615] Use-after-free by mutating set during set operations
In-Reply-To: <1643824882.75.0.278611227582.issue46615@roundup.psfhosted.org>
Message-ID: <1643948682.96.0.64954780358.issue46615@roundup.psfhosted.org>


Change by Dennis Sweeney <sweeney.dennis650 at gmail.com>:


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

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

From report at bugs.python.org  Thu Feb  3 23:40:03 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Feb 2022 04:40:03 +0000
Subject: [issue46588] fix typo in test_calltip.py
Message-ID: <1643949603.05.0.419681546036.issue46588@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:


New changeset 222865daabfa7a8b12ca9a5e9c23b9ce217448f1 by Caio Agiani in branch 'main':
bpo-46588: fix typo in test_calltip.py  (GH-31119)
https://github.com/python/cpython/commit/222865daabfa7a8b12ca9a5e9c23b9ce217448f1


----------
nosy: +terry.reedy

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

From report at bugs.python.org  Thu Feb  3 23:40:10 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 04 Feb 2022 04:40:10 +0000
Subject: [issue46588] fix typo in test_calltip.py
In-Reply-To: <1643949603.05.0.419681546036.issue46588@roundup.psfhosted.org>
Message-ID: <1643949610.62.0.852633903689.issue46588@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: +29302
pull_request: https://github.com/python/cpython/pull/31121

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

From report at bugs.python.org  Thu Feb  3 23:40:14 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 04 Feb 2022 04:40:14 +0000
Subject: [issue46588] fix typo in test_calltip.py
In-Reply-To: <1643949603.05.0.419681546036.issue46588@roundup.psfhosted.org>
Message-ID: <1643949614.63.0.665776267359.issue46588@roundup.psfhosted.org>


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


----------
pull_requests: +29303
pull_request: https://github.com/python/cpython/pull/31122

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

From report at bugs.python.org  Fri Feb  4 00:05:47 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 04 Feb 2022 05:05:47 +0000
Subject: [issue46588] fix typo in test_calltip.py
In-Reply-To: <1643949603.05.0.419681546036.issue46588@roundup.psfhosted.org>
Message-ID: <1643951147.94.0.845476731275.issue46588@roundup.psfhosted.org>


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


New changeset 663370aea5dcf9074455b45283e980c7bc353674 by Miss Islington (bot) in branch '3.9':
bpo-46588: fix typo in test_calltip.py  (GH-31119)
https://github.com/python/cpython/commit/663370aea5dcf9074455b45283e980c7bc353674


----------

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

From report at bugs.python.org  Fri Feb  4 00:11:22 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 04 Feb 2022 05:11:22 +0000
Subject: [issue46588] fix typo in test_calltip.py
In-Reply-To: <1643949603.05.0.419681546036.issue46588@roundup.psfhosted.org>
Message-ID: <1643951482.29.0.49526003219.issue46588@roundup.psfhosted.org>


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


New changeset 9ce0b00fb1172e743de985eda28e3335aa95014a by Miss Islington (bot) in branch '3.10':
bpo-46588: fix typo in test_calltip.py  (GH-31119)
https://github.com/python/cpython/commit/9ce0b00fb1172e743de985eda28e3335aa95014a


----------

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

From report at bugs.python.org  Fri Feb  4 00:21:56 2022
From: report at bugs.python.org (Tim Peters)
Date: Fri, 04 Feb 2022 05:21:56 +0000
Subject: [issue46627] Regex hangs indefinitely
In-Reply-To: <1643913617.99.0.318274176206.issue46627@roundup.psfhosted.org>
Message-ID: <1643952116.71.0.644654834378.issue46627@roundup.psfhosted.org>


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

Introducing some kind of optional timeout is too involved to just drop in without significant discussion and design effort first. If you want to pursue this, please bring it up on the python-ideas mailing list.

My first take: it wouldn't really help, because nobody would use it until after it was too late ;-) So, in the absence of someone jumping on it right away, I'm closing this one too as "won't fix". If the idea gains traction, we can, of course, reopen this.

BTW, Jeffrey Friedl's book "Mastering Regular Expressions" teaches how to write bulletproof regexps. It's not always obvious at first glance, but it's an art that can be mastered.

----------
nosy: +tim.peters
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Feb  4 00:42:31 2022
From: report at bugs.python.org (Tim Peters)
Date: Fri, 04 Feb 2022 05:42:31 +0000
Subject: [issue46615] Use-after-free by mutating set during set operations
In-Reply-To: <1643824882.75.0.278611227582.issue46615@roundup.psfhosted.org>
Message-ID: <1643953351.07.0.715857697446.issue46615@roundup.psfhosted.org>


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

Raised the priority back to normal.

I agree with Dennis's observation that PyDict_Next is safe, provided it's used as intended: it returns borrowed references, but to things that absolutely are legitimate at the time. In the presence of mutations, *what* it returns isn't defined at all, but I don't see a way for it to blow up (unless its caller screws up by believing it owns the references). It doesn't assume anything about the structure of the dict across calls.

----------
nosy: +tim.peters
priority: low -> normal

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

From report at bugs.python.org  Fri Feb  4 00:55:34 2022
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 04 Feb 2022 05:55:34 +0000
Subject: [issue46631] Implement a "strict" mode for getpass.getuser()
Message-ID: <1643954134.16.0.436701246605.issue46631@roundup.psfhosted.org>


New submission from Eryk Sun <eryksun at gmail.com>:

getpass.getuser() checks the environment variables LOGNAME (login name), USER, LNAME, and USERNAME, in that order. In Windows, LOGNAME, USER, and LNAME have no conventional usage. I think there should be a strict mode that restricts getuser() to check only USERNAME in Windows and only LOGNAME in POSIX [1]. If the login variable isn't defined, it should fall back on using the system API, based on the user ID in POSIX and the logon ID in Windows.

For the fallback in Windows, the _winapi module could implement GetCurrentProcessToken(), GetTokenInformation(), and LsaGetLogonSessionData(). For TokenStatistics, return a dict with just "AuthenticationId". For LsaGetLogonSessionData(), return a dict with just "UserName". GetCurrentProcessToken() returns a pseudohandle (-4), which should not be closed.

For example, assuming _winapi wraps the required functions:

    def getuser(strict=False):
        """Get the username from the environment or password database.

        First try various environment variables. If strict, check only LOGNAME
        in POSIX and only USERNAME in Windows. As a fallback, in POSIX get the
        user name from the password database, and in Windows get the user name
        from the logon-session data of the current process.
        """
        posix = sys.platform != 'win32'

        if strict:
            names = ('LOGNAME',) if posix else ('USERNAME',)
        else:
            names = ('LOGNAME', 'USER', 'LNAME', 'USERNAME')

        for name in names:
            if user := os.environ.get(name):
                return user

        if posix:
            import pwd
            return pwd.getpwuid(os.getuid())[0]

        import _winapi
        logon_id = _winapi.GetTokenInformation(
                        _winapi.GetCurrentProcessToken(),
                        _winapi.TokenStatistics)['AuthenticationId']
        return _winapi.LsaGetLogonSessionData(logon_id)['UserName']

Like WinAPI GetUserNameW(), the above fallback returns the logon user name instead of the account name of the token user. As far as I know, the user name and the account name only differ for the builtin service account logons "SYSTEM" (999) and "NETWORK SERVICE" (996), for which the user name is the machine security principal (i.e. the machine's NETBIOS name plus "$"). The user name of the builtin "LOCAL SERVICE" logon (997), on the other hand, is just the "LOCAL SERVICE" account name, since this account lacks network access.

Unlike GetUserNameW(), the above code uses the process token instead of the effective token. This is like POSIX getuid(), whereas what GetUserNameW() does is like geteuid(). getuser() could implement an `effective` option to return the effective user name. In Windows this would switch to calling GetCurrentThreadEffectiveToken() instead of GetCurrentProcessToken().

---

[1] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html

----------
components: Library (Lib), Windows
messages: 412495
nosy: eryksun, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Implement a "strict" mode for getpass.getuser()
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Fri Feb  4 02:08:15 2022
From: report at bugs.python.org (Yassir Karroum)
Date: Fri, 04 Feb 2022 07:08:15 +0000
Subject: [issue20039] Missing documentation for argparse.ArgumentTypeError
In-Reply-To: <1387622425.21.0.562750433804.issue20039@psf.upfronthosting.co.za>
Message-ID: <1643958495.46.0.73168803651.issue20039@roundup.psfhosted.org>


Change by Yassir Karroum <ukarroum17 at gmail.com>:


----------
keywords: +patch
nosy: +ukarroum
nosy_count: 6.0 -> 7.0
pull_requests: +29304
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31125

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

From report at bugs.python.org  Fri Feb  4 02:23:18 2022
From: report at bugs.python.org (Arie Bovenberg)
Date: Fri, 04 Feb 2022 07:23:18 +0000
Subject: [issue46200] Discourage logging f-strings due to security
 considerations
In-Reply-To: <1640850255.25.0.496981368409.issue46200@roundup.psfhosted.org>
Message-ID: <1643959398.79.0.615987344006.issue46200@roundup.psfhosted.org>


Arie Bovenberg <a.c.bovenberg at gmail.com> added the comment:

@rhettinger @tinchester I definitely see now that f-strings should have a place in logging. 
But do you agree that f-strings don't mix 100% safely with the current logger API?
What are your thoughts on a safer set of logger functions (see my comments above, https://bugs.python.org/issue46200#msg409505)

Just throwing an additional alternative out there: instead of the @overload approach, one could have 2 logger function families:

debugs(s: str)                          # s-prefix indicates simply logging a string (no formatting done by logger!)
debugf(s: LiteralStr, *args, **kwargs)  # f prefix indicates logger does the formatting. (no formatting done by user!)

@vinay.sajip what are your thoughts on the discussion above?

----------

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

From report at bugs.python.org  Fri Feb  4 02:52:56 2022
From: report at bugs.python.org (97littleleaf11)
Date: Fri, 04 Feb 2022 07:52:56 +0000
Subject: [issue46066] Remove keyword args syntax for TypedDict definition
In-Reply-To: <1639409817.42.0.21314101687.issue46066@roundup.psfhosted.org>
Message-ID: <1643961176.43.0.584166759104.issue46066@roundup.psfhosted.org>


Change by 97littleleaf11 <97littleleaf11 at gmail.com>:


----------
title: TypedDict alternative definition syntax with keyword args is confusing -> Remove keyword args syntax for TypedDict definition

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

From report at bugs.python.org  Fri Feb  4 02:55:58 2022
From: report at bugs.python.org (97littleleaf11)
Date: Fri, 04 Feb 2022 07:55:58 +0000
Subject: [issue46066] Remove keyword args syntax for TypedDict definition
In-Reply-To: <1639409817.42.0.21314101687.issue46066@roundup.psfhosted.org>
Message-ID: <1643961358.49.0.148267348605.issue46066@roundup.psfhosted.org>


Change by 97littleleaf11 <97littleleaf11 at gmail.com>:


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

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

From report at bugs.python.org  Fri Feb  4 03:26:52 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Feb 2022 08:26:52 +0000
Subject: [issue46588] IDLE fix typo in test_calltip.py
In-Reply-To: <1643949603.05.0.419681546036.issue46588@roundup.psfhosted.org>
Message-ID: <1643963212.23.0.527343094077.issue46588@roundup.psfhosted.org>


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


----------
assignee:  -> terry.reedy
components: +IDLE
title: fix typo in test_calltip.py -> IDLE fix typo in test_calltip.py
type: enhancement -> behavior
versions: +Python 3.10, Python 3.9

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

From report at bugs.python.org  Fri Feb  4 04:54:45 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Feb 2022 09:54:45 +0000
Subject: [issue46632] test_ssl: 2 tests fail on cstratak-CentOS9-fips-x86_64
Message-ID: <1643968485.02.0.29316293905.issue46632@roundup.psfhosted.org>


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

test_load_verify_cadata() and test_connect_cadata() of test_ssl fail on cstratak-CentOS9-fips-x86_64 (with OpenSSL FIPS mode enabled):
https://buildbot.python.org/all/#builders/828/builds/63

test.pythoninfo:

fips.linux_crypto_fips_enabled: 1
fips.openssl_fips_mode: 1
ssl.OPENSSL_VERSION: OpenSSL 3.0.1 14 Dec 2021
ssl.OPENSSL_VERSION_INFO: (3, 0, 0, 1, 0)

Logs:

======================================================================
ERROR: test_load_verify_cadata (test.test_ssl.ContextTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-CentOS9-fips-x86_64.no-builtin-hashes-except-blake2/build/Lib/test/test_ssl.py", line 1494, in test_load_verify_cadata
    ctx.load_verify_locations(cadata=cacert_der)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ssl.SSLError: [EVP] unsupported (_ssl.c:3998)

======================================================================
ERROR: test_connect_cadata (test.test_ssl.SimpleBackgroundTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-CentOS9-fips-x86_64.no-builtin-hashes-except-blake2/build/Lib/test/test_ssl.py", line 2138, in test_connect_cadata
    ctx.load_verify_locations(cadata=der)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ssl.SSLError: [EVP] unsupported (_ssl.c:3998)

Stdout:
 server:  new connection from ('127.0.0.1', 49102)
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)

----------
assignee: christian.heimes
components: SSL, Tests
messages: 412497
nosy: christian.heimes, vstinner
priority: normal
severity: normal
status: open
title: test_ssl: 2 tests fail on cstratak-CentOS9-fips-x86_64
versions: Python 3.11

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

From report at bugs.python.org  Fri Feb  4 04:55:31 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Feb 2022 09:55:31 +0000
Subject: [issue46632] test_ssl: 2 tests fail on cstratak-CentOS9-fips-x86_64
In-Reply-To: <1643968485.02.0.29316293905.issue46632@roundup.psfhosted.org>
Message-ID: <1643968531.55.0.381935028542.issue46632@roundup.psfhosted.org>


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


----------
nosy: +cstratak

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

From report at bugs.python.org  Fri Feb  4 05:08:55 2022
From: report at bugs.python.org (Petr Viktorin)
Date: Fri, 04 Feb 2022 10:08:55 +0000
Subject: [issue46433] _PyType_GetModuleByDef optimization is incorrect
In-Reply-To: <1642607197.61.0.0970144809853.issue46433@roundup.psfhosted.org>
Message-ID: <1643969335.15.0.0691902731655.issue46433@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

Almost. It's a bugfix so it needs backports to 3.10 & 3.9.
Thanks for the reminder!
I should get to them next week.

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

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

From report at bugs.python.org  Fri Feb  4 05:09:11 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Feb 2022 10:09:11 +0000
Subject: [issue46633] AddressSanitizer: Skip tests directly in Python,
 not with external config
Message-ID: <1643969351.1.0.716031320154.issue46633@roundup.psfhosted.org>


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

It seems like bpo-45200: "Address Sanitizer: libasan dead lock in pthread_create() (test_multiprocessing_fork.test_get() hangs)" is not fixed yet.

In the GitHub Action job, test_multiprocessing_fork is skipped because it's too slow, so the job doesn't hang.

Yesterday, I modified the ASAN buildbot to double its timeout from 20 to 40 minutes:
https://github.com/python/buildmaster-config/commit/5a37411e75c9475d48eabaac18102a3c9fc2d467

But it's useful, when it hangs, it hangs forever. Exmaple on the AMD64 Arch Linux Asan Debug 3.9 buildbot (with the new config):

---
(test.test_multiprocessing_fork.WithProcessesTestPicklingConnections) ... ok
Timeout (0:35:00)!
---
https://buildbot.python.org/all/#/builders/588/builds/332

Tests are tuned for ASAN, but the configuration is copied and inconsistent between the GitHub Actions job and the buildbot configuration.

I propose to move this configuration directly into Python.

test_decimal.py checks for "-fsanitize=address" in CFLAGS and skip some tests if it's present.

----------
components: Tests
messages: 412499
nosy: pablogsal, vstinner
priority: normal
severity: normal
status: open
title: AddressSanitizer: Skip tests directly in Python, not with external config
versions: Python 3.11

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

From report at bugs.python.org  Fri Feb  4 05:11:08 2022
From: report at bugs.python.org (Erlend E. Aasland)
Date: Fri, 04 Feb 2022 10:11:08 +0000
Subject: [issue46433] _PyType_GetModuleByDef optimization is incorrect
In-Reply-To: <1642607197.61.0.0970144809853.issue46433@roundup.psfhosted.org>
Message-ID: <1643969468.2.0.0323768168636.issue46433@roundup.psfhosted.org>


Erlend E. Aasland <erlend.aasland at innova.no> added the comment:

Right, this of course affects 3.10 and 3.9. Let me know if you want me to do the backports :)


(Updating version field for this ticket)

----------
versions: +Python 3.10, Python 3.9

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

From report at bugs.python.org  Fri Feb  4 05:12:15 2022
From: report at bugs.python.org (Erlend E. Aasland)
Date: Fri, 04 Feb 2022 10:12:15 +0000
Subject: [issue46200] Discourage logging f-strings due to security
 considerations
In-Reply-To: <1640850255.25.0.496981368409.issue46200@roundup.psfhosted.org>
Message-ID: <1643969535.54.0.964487828729.issue46200@roundup.psfhosted.org>


Change by Erlend E. Aasland <erlend.aasland at innova.no>:


----------
nosy:  -erlendaasland

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

From report at bugs.python.org  Fri Feb  4 05:19:13 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Feb 2022 10:19:13 +0000
Subject: [issue46633] AddressSanitizer: Skip tests directly in Python,
 not with external config
In-Reply-To: <1643969351.1.0.716031320154.issue46633@roundup.psfhosted.org>
Message-ID: <1643969953.8.0.374250188246.issue46633@roundup.psfhosted.org>


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

Notes:

* test.support has check_sanitizer() function. Tests using it:

  * test_crypt
  * test_idle
  * test_tix
  * test_tk
  * test_ttk_guionly


* test_decimal also checks for memory sanitizer and skip some tests if it's present:

MEMORY_SANITIZER = (
    '-fsanitize=memory' in _cflags or
    '--with-memory-sanitizer' in _config_args
)   

* test_faulthandler suppress crash report, similir to support.SuppressCrashReport, directly in the C code used by tests: faulthandler_suppress_crash_report() function.

* Objects/obmalloc.c checks "#if __has_feature(address_sanitizer)": is ASAN enabled?

* GitHub Action config: .github/workflows/build.yml. Skipped tests:

  * test___all__
  * test_concurrent_futures
  * test_multiprocessing_fork
  * test_multiprocessing_forkserver
  * test_multiprocessing_spawn
  * test_peg_generator
  * test_tools

Comment:
---
# Skip test_tools test_peg_generator test_concurrent_futures because
# there are too slow: between 5 and 20 minutes on this CI.
#
# Skip multiprocessing and concurrent.futures tests which are affected by
# bpo-45200 bug: libasan dead lock in pthread_create().
#
# test___all__ is skipped because importing some modules directly can trigger
# known problems with ASAN (like tk or crypt).
---

* Buildbot configuration: UnixAsanBuild class of master/custom/factories.py. Options:

  ASAN_OPTIONS='detect_leaks=0:allocator_may_return_null=1:handle_segv=0'

With the comment:
---
# See https://bugs.python.org/issue42985 for more context on why
# SIGSEGV is ignored on purpose.
---

  Skipped tests:
  
  * test_ctypes
  * test_capi
  * test_crypt
  * test_decimal
  * test_faulthandler
  * test_interpreters

With the comment:
---
# These tests are currently raising false positives or are interfering with the ASAN mechanism,
# so we need to skip them unfortunately.
---

----------

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

From report at bugs.python.org  Fri Feb  4 05:23:01 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Feb 2022 10:23:01 +0000
Subject: [issue11871] test_default_timeout() of test_threading.BarrierTests
 failure: BrokenBarrierError
In-Reply-To: <1303163944.05.0.666091618845.issue11871@psf.upfronthosting.co.za>
Message-ID: <1643970181.97.0.859019346749.issue11871@roundup.psfhosted.org>


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

The race condition still exists in tests. Recent failure on AMD64 Windows8.1 Refleaks 3.x:
https://buildbot.python.org/all/#/builders/511/builds/249

0:03:31 load avg: 2.93 [ 42/432/1] test_threading failed (1 error) (1 min 12 sec) -- running: test_runpy (1 min 8 sec), test_pydoc (55.4 sec), test_io (1 min 29 sec)
beginning 6 repetitions
123456
...Warning -- Unraisable exceptionWarning -- Unraisable exceptionWarning -- Unraisable exception
Exception ignored in thread started by: 
<function Bunch.__init__.<locals>.task at 0x000000CA51433CD0>
Exception ignored in thread started by
Exception ignored in thread started by: Traceback (most recent call last):
  File "D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\test\lock_tests.py", line 49, in task
<function Bunch.__init__.<locals>.task at 0x000000CA51433CD0>: 
<function Bunch.__init__.<locals>.task at 0x000000CA51433CD0>
Traceback (most recent call last):
  File "D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\test\lock_tests.py", line 49, in task
Traceback (most recent call last):
  File "D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\test\lock_tests.py", line 49, in task
        f()f()    

f()  
       ^  ^^^^^

   File "D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\test\lock_tests.py", line 1021, in f
  File "D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\test\lock_tests.py", line 1021, in f
^^^
  File "D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\test\lock_tests.py", line 1021, in f
        i = barrier.wait()i = barrier.wait()

         i = barrier.wait()  
             ^ ^^^ ^^ ^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^  File "D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\threading.py", line 683, in wait

  File "D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\threading.py", line 683, in wait
^
  File "D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\threading.py", line 683, in wait
    self._wait(timeout)
    ^^^^    ^self._wait(timeout)^
^    self._wait(timeout)
 ^^ ^   ^  ^^ ^^^^^^^^^^^^^^^^^^^^^^^^^
^^  File "D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\threading.py", line 723, in _wait
^^^^^^^^^^
  File "D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\threading.py", line 723, in _wait
^^^^^    ^raise BrokenBarrierError^

     raise BrokenBarrierError  File "D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\threading.py", line 723, in _wait
   ^
^ ^ ^ ^ ^^^    ^^raise BrokenBarrierError^^
^^ ^^ ^^ ^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^threading.^^BrokenBarrierError^^: ^^^
^^^^^
^threading.BrokenBarrierError^: ^
^^^
threading.BrokenBarrierError: 
Warning -- Unraisable exception
Exception ignored in thread started by: <function Bunch.__init__.<locals>.task at 0x000000CA51433CD0>
Traceback (most recent call last):
  File "D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\test\lock_tests.py", line 49, in task
    f()
    ^^^
  File "D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\test\lock_tests.py", line 1021, in f
    i = barrier.wait()
        ^^^^^^^^^^^^^^
  File "D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\threading.py", line 674, in wait
    self._enter() # Block while the barrier drains.
    ^^^^^^^^^^^^^
  File "D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\threading.py", line 698, in _enter
    raise BrokenBarrierError
    ^^^^^^^^^^^^^^^^^^^^^^^^
threading.BrokenBarrierError: 
test test_threading failed -- Traceback (most recent call last):
  File "D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\test\lock_tests.py", line 1026, in test_default_timeout
    self.run_threads(f)
    ^^^^^^^^^^^^^^^^^^^
  File "D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\test\lock_tests.py", line 855, in run_threads
    f()
    ^^^
  File "D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\test\lock_tests.py", line 1021, in f
    i = barrier.wait()
        ^^^^^^^^^^^^^^
  File "D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\threading.py", line 683, in wait
    self._wait(timeout)
    ^^^^^^^^^^^^^^^^^^^
  File "D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\threading.py", line 721, in _wait
    raise BrokenBarrierError
    ^^^^^^^^^^^^^^^^^^^^^^^^
threading.BrokenBarrierError

----------

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

From report at bugs.python.org  Fri Feb  4 05:38:53 2022
From: report at bugs.python.org (Erlend E. Aasland)
Date: Fri, 04 Feb 2022 10:38:53 +0000
Subject: =?utf-8?q?=5Bissue46634=5D_=5Bsqlite3=5D=C2=A0speed_up_cursor=2Eexecute*?=
 =?utf-8?b?KCk=?=
Message-ID: <1643971133.68.0.0138168910429.issue46634@roundup.psfhosted.org>


New submission from Erlend E. Aasland <erlend.aasland at innova.no>:

`pysqlite_connection_execute_impl()` and friends (executemany, executescript) goes all the way through the Call API just to call `pysqlite_connection_cursor_impl`. We can same a lot of calls by calling the cursor _impl function directly; after all, it does live in the same file scope as the callers.

A quick bench (sqlitesynth) shows a small speedup:

    Mean +- std dev: [main] 9.55 us +- 0.25 us -> [patched] 9.32 us +- 0.23 us: 1.02x faster



(Side effect: will get rid of _Py_IDENTIFIER(cursor) in sqlite3)

----------
components: Extension Modules
messages: 412503
nosy: erlendaasland
priority: normal
severity: normal
status: open
title: [sqlite3]?speed up cursor.execute*()
versions: Python 3.11

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

From report at bugs.python.org  Fri Feb  4 05:50:59 2022
From: report at bugs.python.org (Erlend E. Aasland)
Date: Fri, 04 Feb 2022 10:50:59 +0000
Subject: =?utf-8?q?=5Bissue46634=5D_=5Bsqlite3=5D=C2=A0speed_up_cursor=2Eexecute*?=
 =?utf-8?b?KCk=?=
In-Reply-To: <1643971133.68.0.0138168910429.issue46634@roundup.psfhosted.org>
Message-ID: <1643971859.77.0.0342577379464.issue46634@roundup.psfhosted.org>


Change by Erlend E. Aasland <erlend.aasland at innova.no>:


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

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

From report at bugs.python.org  Fri Feb  4 06:24:50 2022
From: report at bugs.python.org (=?utf-8?q?Tin_Tvrtkovi=C4=87?=)
Date: Fri, 04 Feb 2022 11:24:50 +0000
Subject: [issue46200] Discourage logging f-strings due to security
 considerations
In-Reply-To: <1640850255.25.0.496981368409.issue46200@roundup.psfhosted.org>
Message-ID: <1643973890.35.0.701541572411.issue46200@roundup.psfhosted.org>


Tin Tvrtkovi? <tinchester at gmail.com> added the comment:

I mean, I agree with your point about being able to accidentally format twice when using the standard library logger.

I'm not a core dev but I think getting new APIs in will be challenging. And if by some fluke of chance you did get the approval to introduce new logging APIs, there are better APIs out there (look at the structlog library). Also the old APIs would have to stay for a *long* time since everybody's using them.

Adding clever typing overloads seems actually realistic and useful to me. But that depends on the LiteralString PEP being accepted and people actually running MyPy. That's probably the best we can do, apart from some documentation.

----------

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

From report at bugs.python.org  Fri Feb  4 06:35:56 2022
From: report at bugs.python.org (Tasos Papastylianou)
Date: Fri, 04 Feb 2022 11:35:56 +0000
Subject: [issue46635] unittest.defaultTestLoader.discover fails for namespace
 packages
Message-ID: <1643974556.47.0.0758530865107.issue46635@roundup.psfhosted.org>


New submission from Tasos Papastylianou <tpapastylianou at hotmail.com>:

Back in python 3.6.9, attempting to import __file__ on a namespace package resulted in an attribute error. From at least 3.8 onwards, this behaviour seems to have changed, and __file__ simply returns None instead.

This seems to have broken unittest discovery. Looking at the code, it seems that discover still seems to rely on a try/except block in order to test for a namespace package. Now that the attribute error is no longer present in later python versions, discover simply accepts the None value for __file__, and fails further down the line when attempting to canonicalise a path containing a None value (error effectively expects a string).

On my system with python 3.8, the relevant files/lines are:

- /usr/lib/python3.8/unittest/loader.py()discover()
  The try block starting at line 304 checks for the module's __file__ attribute, expecting to redirect to 307 to "look for namespace packages" in case of an attribute error. Obviously, now that __file__ returns None instead, this logic fails.

- The call to dirname in line 306 therefore proceeds normally, passing a None as a file, which then fails with a TypeError: expected str, bytes or os.PathLike object, not NoneType
 

See https://github.com/tpapastylianou/self-contained-runnable-python-package-template/issues/13# for the example in the wild that prompted the discovery of this bug.

----------
components: Tests
messages: 412505
nosy: tpapastylianou
priority: normal
severity: normal
status: open
title: unittest.defaultTestLoader.discover fails for namespace packages
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Feb  4 06:37:25 2022
From: report at bugs.python.org (Tasos Papastylianou)
Date: Fri, 04 Feb 2022 11:37:25 +0000
Subject: [issue46635] unittest.defaultTestLoader.discover fails for namespace
 packages
In-Reply-To: <1643974556.47.0.0758530865107.issue46635@roundup.psfhosted.org>
Message-ID: <1643974645.05.0.492304719933.issue46635@roundup.psfhosted.org>


Change by Tasos Papastylianou <tpapastylianou at hotmail.com>:


----------
components: +Distutils -Tests
nosy: +dstufft, eric.araujo

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

From report at bugs.python.org  Fri Feb  4 06:43:09 2022
From: report at bugs.python.org (Marc Mueller)
Date: Fri, 04 Feb 2022 11:43:09 +0000
Subject: [issue44791] Substitution of ParamSpec in Concatenate
In-Reply-To: <1627727114.02.0.621938171006.issue44791@roundup.psfhosted.org>
Message-ID: <1643974989.83.0.971644111131.issue44791@roundup.psfhosted.org>


Change by Marc Mueller <cdce8p at gmail.com>:


----------
nosy: +cdce8p

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

From report at bugs.python.org  Fri Feb  4 07:24:59 2022
From: report at bugs.python.org (Alex Waygood)
Date: Fri, 04 Feb 2022 12:24:59 +0000
Subject: [issue46066] Remove keyword args syntax for TypedDict definition
In-Reply-To: <1639409817.42.0.21314101687.issue46066@roundup.psfhosted.org>
Message-ID: <1643977499.41.0.480950910844.issue46066@roundup.psfhosted.org>


Change by Alex Waygood <Alex.Waygood at Gmail.com>:


----------
nosy: +AlexWaygood, Jelle Zijlstra, sobolevn

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

From report at bugs.python.org  Fri Feb  4 07:37:30 2022
From: report at bugs.python.org (Alex Waygood)
Date: Fri, 04 Feb 2022 12:37:30 +0000
Subject: [issue46433] _PyType_GetModuleByDef optimization is incorrect
In-Reply-To: <1642607197.61.0.0970144809853.issue46433@roundup.psfhosted.org>
Message-ID: <1643978250.95.0.536934299543.issue46433@roundup.psfhosted.org>


Change by Alex Waygood <Alex.Waygood at Gmail.com>:


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

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

From report at bugs.python.org  Fri Feb  4 08:00:45 2022
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 04 Feb 2022 13:00:45 +0000
Subject: [issue46633] AddressSanitizer: Skip tests directly in Python,
 not with external config
In-Reply-To: <1643969351.1.0.716031320154.issue46633@roundup.psfhosted.org>
Message-ID: <1643979645.51.0.109243651426.issue46633@roundup.psfhosted.org>


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

I have recently added some decorators in test.
support to deactivate tests if running under the sanitizers.

----------

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

From report at bugs.python.org  Fri Feb  4 08:29:48 2022
From: report at bugs.python.org (Steve Dower)
Date: Fri, 04 Feb 2022 13:29:48 +0000
Subject: [issue46629] Cannot sideload MSIX package on Windows
In-Reply-To: <1643918509.02.0.11986541964.issue46629@roundup.psfhosted.org>
Message-ID: <1643981388.47.0.247513827515.issue46629@roundup.psfhosted.org>


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

They got back to me with the files, so I've added them to the PR. I'll run a test (signed) build from my branch to validate.

----------

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

From report at bugs.python.org  Fri Feb  4 09:49:36 2022
From: report at bugs.python.org (chen-y0y0)
Date: Fri, 04 Feb 2022 14:49:36 +0000
Subject: [issue46636] Bugs of 2to3
Message-ID: <1643986176.49.0.812119099931.issue46636@roundup.psfhosted.org>


New submission from chen-y0y0 <cyy144881 at icloud.com>:

I have a file named foo.py:
try :
    input = raw_input
    int = long
    chr = unichr
    range = xrange
except NameError :
    pass

When I process this file to 2to3, it shows:
--- foo.py (original)
+++ foo.py (refactored)
@@ -1,7 +1,7 @@
 try :
     input = raw_input
-    int = long
-    chr = unichr
+    int = int
+    chr = chr
     range = xrange
except NameError :
    pass
RefactoringTool: Files that need to be modified:
RefactoringTool: foo.py

I don't know why it modifies the Python 2.x and 3.x compatible code.

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 412508
nosy: prasechen
priority: normal
severity: normal
status: open
title: Bugs of 2to3
type: behavior
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Feb  4 09:49:59 2022
From: report at bugs.python.org (chen-y0y0)
Date: Fri, 04 Feb 2022 14:49:59 +0000
Subject: [issue46636] Bugs of 2to3 on built-in function or types(classes)
In-Reply-To: <1643986176.49.0.812119099931.issue46636@roundup.psfhosted.org>
Message-ID: <1643986199.89.0.360261743014.issue46636@roundup.psfhosted.org>


Change by chen-y0y0 <cyy144881 at icloud.com>:


----------
title: Bugs of 2to3 -> Bugs of 2to3 on built-in function or types(classes)

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

From report at bugs.python.org  Fri Feb  4 10:25:29 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 04 Feb 2022 15:25:29 +0000
Subject: [issue46636] Bugs of 2to3 on built-in function or types(classes)
In-Reply-To: <1643986176.49.0.812119099931.issue46636@roundup.psfhosted.org>
Message-ID: <1643988329.58.0.659265771529.issue46636@roundup.psfhosted.org>


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

I'm not sure what you're trying to accomplish here, but long and unichr are not available in python 3.

2to3 has been deprecated and is no longer supported.

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

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

From report at bugs.python.org  Fri Feb  4 10:54:15 2022
From: report at bugs.python.org (=?utf-8?q?Anders_Hovm=C3=B6ller?=)
Date: Fri, 04 Feb 2022 15:54:15 +0000
Subject: [issue46637] Incorrect error message: "missing 1 required positional
 argument"
Message-ID: <1643990055.45.0.970752611144.issue46637@roundup.psfhosted.org>


New submission from Anders Hovm?ller <boxed at killingar.net>:

>>> def foo(a):
...     pass
... 
>>> foo()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: foo() missing 1 required positional argument: 'a'

This error is incorrect. It says "positional argument", but it's just "argument". The proof is that if you call it with

foo(a=3)

it works fine.

----------
components: Interpreter Core
messages: 412510
nosy: Anders.Hovm?ller
priority: normal
severity: normal
status: open
title: Incorrect error message: "missing 1 required positional argument"
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Feb  4 11:07:49 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 04 Feb 2022 16:07:49 +0000
Subject: [issue46637] Incorrect error message: "missing 1 required positional
 argument"
In-Reply-To: <1643990055.45.0.970752611144.issue46637@roundup.psfhosted.org>
Message-ID: <1643990869.81.0.068659647038.issue46637@roundup.psfhosted.org>


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

I guess the technically correct term is positional-or-keyword, but that seems like too much: https://docs.python.org/3/glossary.html

I think dropping "positional" doesn't increase the precision of the error message, but I'll admit I can't think of anything better. And lacking something better I don't think we should change this.

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

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

From report at bugs.python.org  Fri Feb  4 11:11:30 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 04 Feb 2022 16:11:30 +0000
Subject: [issue46629] Cannot sideload MSIX package on Windows
In-Reply-To: <1643918509.02.0.11986541964.issue46629@roundup.psfhosted.org>
Message-ID: <1643991090.53.0.623538366591.issue46629@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: +29307
pull_request: https://github.com/python/cpython/pull/31128

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

From report at bugs.python.org  Fri Feb  4 11:11:36 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 04 Feb 2022 16:11:36 +0000
Subject: [issue46629] Cannot sideload MSIX package on Windows
In-Reply-To: <1643918509.02.0.11986541964.issue46629@roundup.psfhosted.org>
Message-ID: <1643991096.87.0.178787609169.issue46629@roundup.psfhosted.org>


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


----------
pull_requests: +29308
pull_request: https://github.com/python/cpython/pull/31129

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

From report at bugs.python.org  Fri Feb  4 11:11:49 2022
From: report at bugs.python.org (Steve Dower)
Date: Fri, 04 Feb 2022 16:11:49 +0000
Subject: [issue46629] Cannot sideload MSIX package on Windows
In-Reply-To: <1643918509.02.0.11986541964.issue46629@roundup.psfhosted.org>
Message-ID: <1643991109.33.0.461735250824.issue46629@roundup.psfhosted.org>


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


New changeset 9b4e3d94a5746af093392ed8e977b26fcc1bfd11 by Steve Dower in branch 'main':
bpo-46629: Update classicAppCompat.sccd for new signing certificate (GH-31111)
https://github.com/python/cpython/commit/9b4e3d94a5746af093392ed8e977b26fcc1bfd11


----------

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

From report at bugs.python.org  Fri Feb  4 11:16:10 2022
From: report at bugs.python.org (Steve Dower)
Date: Fri, 04 Feb 2022 16:16:10 +0000
Subject: [issue46638] Inconsistent registry use in Windows Store package
Message-ID: <1643991370.43.0.929070469703.issue46638@roundup.psfhosted.org>


New submission from Steve Dower <steve.dower at python.org>:

The build of the Store package detects whether the build PC supports disabling registry virtualisation or not when deciding whether to add it to the manifest. Because our release builds just moved from the windows-2019 image to the windows-2022 image, this setting changed and now builds have virtualisation disabled.

While this is probably desirable for some users, having it happen without  warning is bad.

I'll check whether we can leave it unconditionally enabled for 3.11 and still install on older Windows versions. If it won't install, we'll just have to leave it disabled.

----------
assignee: steve.dower
components: Windows
messages: 412513
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Inconsistent registry use in Windows Store package
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Fri Feb  4 11:23:34 2022
From: report at bugs.python.org (=?utf-8?q?Anders_Hovm=C3=B6ller?=)
Date: Fri, 04 Feb 2022 16:23:34 +0000
Subject: [issue46637] Incorrect error message: "missing 1 required positional
 argument"
In-Reply-To: <1643990055.45.0.970752611144.issue46637@roundup.psfhosted.org>
Message-ID: <1643991814.82.0.526917253054.issue46637@roundup.psfhosted.org>


Anders Hovm?ller <boxed at killingar.net> added the comment:

Just dropping the word "positional" is very good. That word is a lie, and just removing it makes it true.

----------

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

From report at bugs.python.org  Fri Feb  4 11:34:21 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 04 Feb 2022 16:34:21 +0000
Subject: [issue46629] Cannot sideload MSIX package on Windows
In-Reply-To: <1643918509.02.0.11986541964.issue46629@roundup.psfhosted.org>
Message-ID: <1643992461.74.0.546455112644.issue46629@roundup.psfhosted.org>


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


New changeset 7b5b23c31db87cfc5e09ec297147499ba1d47d31 by Miss Islington (bot) in branch '3.10':
bpo-46629: Update classicAppCompat.sccd for new signing certificate (GH-31111)
https://github.com/python/cpython/commit/7b5b23c31db87cfc5e09ec297147499ba1d47d31


----------

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

From report at bugs.python.org  Fri Feb  4 11:37:46 2022
From: report at bugs.python.org (Steve Dower)
Date: Fri, 04 Feb 2022 16:37:46 +0000
Subject: [issue46629] Cannot sideload MSIX package on Windows
In-Reply-To: <1643918509.02.0.11986541964.issue46629@roundup.psfhosted.org>
Message-ID: <1643992666.81.0.620070117275.issue46629@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/issue46629>
_______________________________________

From report at bugs.python.org  Fri Feb  4 11:38:22 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 04 Feb 2022 16:38:22 +0000
Subject: [issue46629] Cannot sideload MSIX package on Windows
In-Reply-To: <1643918509.02.0.11986541964.issue46629@roundup.psfhosted.org>
Message-ID: <1643992702.89.0.481030172049.issue46629@roundup.psfhosted.org>


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


New changeset 6da436497a79dea0f3bb756c2d78921b2838e03b by Miss Islington (bot) in branch '3.9':
bpo-46629: Update classicAppCompat.sccd for new signing certificate (GH-31111)
https://github.com/python/cpython/commit/6da436497a79dea0f3bb756c2d78921b2838e03b


----------

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

From report at bugs.python.org  Fri Feb  4 11:51:08 2022
From: report at bugs.python.org (Steve Dower)
Date: Fri, 04 Feb 2022 16:51:08 +0000
Subject: [issue46638] Inconsistent registry use in Windows Store package
In-Reply-To: <1643991370.43.0.929070469703.issue46638@roundup.psfhosted.org>
Message-ID: <1643993468.34.0.0732570922811.issue46638@roundup.psfhosted.org>


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

Okay, so it doesn't install at all on 1803. However, that's out of support [1], so I guess it doesn't matter.

In theory, 1809 should be the first one that supports it. I'll try that, but I think we're okay to leave this turned on for 3.11.

The changes for 3.9-3.10 will be to disable the option unconditionally.

[1]: https://docs.microsoft.com/en-us/lifecycle/products/windows-10-home-and-pro

----------

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

From report at bugs.python.org  Fri Feb  4 11:57:02 2022
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 04 Feb 2022 16:57:02 +0000
Subject: [issue46636] Bugs of 2to3 on built-in function or types(classes)
In-Reply-To: <1643986176.49.0.812119099931.issue46636@roundup.psfhosted.org>
Message-ID: <1643993822.31.0.975745856067.issue46636@roundup.psfhosted.org>


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

lib2to3 is going away per https://bugs.python.org/issue40360

but it is behaving as intended above, it does not understand logic.  it was only ever intended to maybe work on python 2-only code.  not python 2-and-3 compatible code.

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

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

From report at bugs.python.org  Fri Feb  4 12:05:31 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 04 Feb 2022 17:05:31 +0000
Subject: [issue46637] Incorrect error message: "missing 1 required positional
 argument"
In-Reply-To: <1643990055.45.0.970752611144.issue46637@roundup.psfhosted.org>
Message-ID: <1643994331.77.0.0500691363385.issue46637@roundup.psfhosted.org>


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

Given this current behavior:

>>> def foo(a, /, b): pass
...
>>> foo()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: foo() missing 2 required positional arguments: 'a' and 'b'

What would you suggest?

I agree the current messages aren't perfect.

----------

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

From report at bugs.python.org  Fri Feb  4 12:13:07 2022
From: report at bugs.python.org (=?utf-8?q?Anders_Hovm=C3=B6ller?=)
Date: Fri, 04 Feb 2022 17:13:07 +0000
Subject: [issue46637] Incorrect error message: "missing 1 required positional
 argument"
In-Reply-To: <1643990055.45.0.970752611144.issue46637@roundup.psfhosted.org>
Message-ID: <1643994787.57.0.527137368603.issue46637@roundup.psfhosted.org>


Anders Hovm?ller <boxed at killingar.net> added the comment:

For `foo(a, /, b)`, it could be:

"TypeError: foo() missing 1 required argument 'a', and one required positional argument 'b'.

If we start on this road there are some more, like for `def foo(a, *, b)` you get the error "TypeError: foo() missing 1 required positional argument: 'a'" which leaves out that the keyword only argument is also required. 

Another solution would be something like:

TypeError: foo() missing 3 required arguments: 'a' (positional only), 'b', 'c' (keyword only)

This solution scales to the worst complex cases, and is a lot clearer imo. Could even be further improved with some nicer formatting:

TypeError: foo() missing 3 required arguments: 
    'a' (positional only)
    'b'
    'c' (keyword only)

But that might be a bit overkill :)

----------

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

From report at bugs.python.org  Fri Feb  4 12:57:12 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 04 Feb 2022 17:57:12 +0000
Subject: [issue46608] Exclude marshalled-frozen data if deep-freezing to save
 300 KB space
In-Reply-To: <1643792907.85.0.286906427988.issue46608@roundup.psfhosted.org>
Message-ID: <1643997432.37.0.442049058665.issue46608@roundup.psfhosted.org>


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


New changeset bf95ff91f2c1fc5a57190491f9ccdc63458b089e by Kumar Aditya in branch 'main':
bpo-46608: exclude marshalled-frozen data if deep-freezing to save 300 KB space  (GH-31074)
https://github.com/python/cpython/commit/bf95ff91f2c1fc5a57190491f9ccdc63458b089e


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

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

From report at bugs.python.org  Fri Feb  4 13:04:16 2022
From: report at bugs.python.org (Steve Dower)
Date: Fri, 04 Feb 2022 18:04:16 +0000
Subject: [issue46638] Inconsistent registry use in Windows Store package
In-Reply-To: <1643991370.43.0.929070469703.issue46638@roundup.psfhosted.org>
Message-ID: <1643997856.27.0.763332622893.issue46638@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Fri Feb  4 13:05:54 2022
From: report at bugs.python.org (Steve Dower)
Date: Fri, 04 Feb 2022 18:05:54 +0000
Subject: [issue46638] Inconsistent registry virtualization in Windows Store
 package
In-Reply-To: <1643991370.43.0.929070469703.issue46638@roundup.psfhosted.org>
Message-ID: <1643997954.46.0.0935705877906.issue46638@roundup.psfhosted.org>


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


----------
title: Inconsistent registry use in Windows Store package -> Inconsistent registry virtualization in Windows Store package

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

From report at bugs.python.org  Fri Feb  4 13:13:45 2022
From: report at bugs.python.org (Steve Dower)
Date: Fri, 04 Feb 2022 18:13:45 +0000
Subject: [issue46638] Inconsistent registry virtualization in Windows Store
 package
In-Reply-To: <1643991370.43.0.929070469703.issue46638@roundup.psfhosted.org>
Message-ID: <1643998425.04.0.193770988572.issue46638@roundup.psfhosted.org>


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

Didn't work on 1809, but it does work on 20H2, which is the earliest update that will still be supported when 3.11 ships. I didn't try the ones in between, but I think we're okay to ignore them.

Interestingly, double-clicking the MSIX on Windows 11 refuses to install because of the unvirtualised resources, but on earlier Windows it's fine. The Powershell command (Add-AppxPackage <filename>) does work fine though. I'll see if I can find out what happened.

----------

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

From report at bugs.python.org  Fri Feb  4 13:24:42 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Fri, 04 Feb 2022 18:24:42 +0000
Subject: [issue46608] Exclude marshalled-frozen data if deep-freezing to save
 300 KB space
In-Reply-To: <1643792907.85.0.286906427988.issue46608@roundup.psfhosted.org>
Message-ID: <1643999082.79.0.0231162003896.issue46608@roundup.psfhosted.org>


Change by Kumar Aditya <rahuladitya303 at gmail.com>:


----------
pull_requests: +29310
pull_request: https://github.com/python/cpython/pull/31131

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

From report at bugs.python.org  Fri Feb  4 13:25:49 2022
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2022 18:25:49 +0000
Subject: [issue46635] unittest.defaultTestLoader.discover fails for namespace
 packages
In-Reply-To: <1643974556.47.0.0758530865107.issue46635@roundup.psfhosted.org>
Message-ID: <1643999149.09.0.206211689314.issue46635@roundup.psfhosted.org>


Change by ?ric Araujo <merwok at netwok.org>:


----------
components: +Library (Lib) -Distutils
nosy: +brett.cannon, eric.snow, ezio.melotti, michael.foord, ncoghlan, rbcollins -dstufft, eric.araujo
versions:  -Python 3.8

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

From report at bugs.python.org  Fri Feb  4 13:34:39 2022
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2022 18:34:39 +0000
Subject: [issue46586] In documentation contents enum.property erroneously
 links to built-in property
In-Reply-To: <1643555525.86.0.209520180874.issue46586@roundup.psfhosted.org>
Message-ID: <1643999679.1.0.312312184196.issue46586@roundup.psfhosted.org>


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

Changing the markup to this should fix the link without changing the text:

   :func:`~enum.property`

Would you like to turn this into a pull request?

----------
keywords: +easy
nosy: +eric.araujo
versions: +Python 3.10, Python 3.9

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

From report at bugs.python.org  Fri Feb  4 13:34:58 2022
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2022 18:34:58 +0000
Subject: [issue46587] datetime and time tests use non-portable "%4Y" format
In-Reply-To: <1643555688.39.0.0858908096334.issue46587@roundup.psfhosted.org>
Message-ID: <1643999698.45.0.432235215968.issue46587@roundup.psfhosted.org>


Change by ?ric Araujo <merwok at netwok.org>:


----------
title: datetime and time tests use non-portal "%4Y" format -> datetime and time tests use non-portable "%4Y" format

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

From report at bugs.python.org  Fri Feb  4 13:48:42 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Feb 2022 18:48:42 +0000
Subject: [issue46609] Generator-based coroutines in Python 3.10 docs
In-Reply-To: <1643804825.5.0.310548487717.issue46609@roundup.psfhosted.org>
Message-ID: <1644000522.37.0.167127516687.issue46609@roundup.psfhosted.org>


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

Yuri or Andrew: either of you know the fix for "Support for generator-based coroutines is deprecated and is scheduled for removal in Python 3.10."?

----------
nosy: +asvetlov, terry.reedy, yselivanov

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

From report at bugs.python.org  Fri Feb  4 14:02:57 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Feb 2022 19:02:57 +0000
Subject: [issue46609] Generator-based coroutines in Python 3.10 docs
In-Reply-To: <1643804825.5.0.310548487717.issue46609@roundup.psfhosted.org>
Message-ID: <1644001377.67.0.167604938375.issue46609@roundup.psfhosted.org>


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

Looking at the doc answered the question.  Further down the 3.10 version, '3.10' was revised to '3.11', and indeed, the decorator and the entire section are gone.  There was no change in 3.9 doc, but should be.  I will submit a PR for 3.10 and try to remember to make an additional change in the 3.9 backport.

The doc for iscoroutine and ...function are gone because they have no use in new 3.11+ code.  The functions remain though, as they will still work, even though redundant.

----------
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.9

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

From report at bugs.python.org  Fri Feb  4 14:07:30 2022
From: report at bugs.python.org (Ben Darnell)
Date: Fri, 04 Feb 2022 19:07:30 +0000
Subject: [issue41962] Make threading._register_atexit public?
In-Reply-To: <1602032984.5.0.326433134447.issue41962@roundup.psfhosted.org>
Message-ID: <1644001650.81.0.594791280552.issue41962@roundup.psfhosted.org>


Ben Darnell <ben.darnell at gmail.com> added the comment:

> To be clear, by "cancel" you are not talking about Future.cancel().  Rather, your handler causes all running tasks to finish (by sending a special message on the socket corresponding to each running task).  Is that right?

Correct. My tasks here are calls to functions from the `select` module (one select call per executor task), and cancelling them means writing a byte to a pipe set up for this purpose. 

The select calls could be given a timeout so there is never an infinite task, but that's not ideal - a timeout that's too low has a performance cost as calls timeout and restart even when the system is "at rest", and a too-long timeout is still going to be perceived as a hanging application. 

> * it does not make sure the task associated with the socket finishes (no way of knowing?)
> * so if a task hangs while trying to stop then the running thread in the ThreadPoolExecutor would block shutdown forever
> * similarly, if a task is stuck handling a request then it will never receive the special message on the socket, either blocking the send() in your handler or causing ThreadPoolExecutor shutdown/atexit to wait forever

Correct. If the task were buggy it could still cause a deadlock. In my case the task is simple enough (a single selector call) that this is not a risk. 

> * it vaguely implies a 1-to-1 relationship between sockets and *running* tasks
> * likewise that pending (queued) tasks do not have an associated socket (until started)

Each task is associated with a selector object (managing a set of sockets), not a single socket. There is only ever one task at a time; a task is enqueued only after the previous one finishes. (This thread pool is not used for any other purpose)

> * so once your handler finishes, any tasks pending in the ThreadPoolExecutor queue will eventually get started but never get stopped by your handler; thus you're back to the deadlock situation

In my case this one-at-a-time rule means that the queue is always empty. But yes, in a more general solution you'd need some sort of interlock between cancelling existing tasks and starting new ones. 

> Alternately, perhaps ThreadPoolExecutor isn't the right fit here, as implied by the route you ended up going. 

Yes, this is my conclusion as well. I filed this issue because I was frustrated that Python 3.9 broke previously-working code, but I'm willing to chalk this up to Hyrum's law and I'm not sure that this is something that ThreadPoolExecutor should be modified to support.

----------

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

From report at bugs.python.org  Fri Feb  4 14:17:54 2022
From: report at bugs.python.org (Andre Roberge)
Date: Fri, 04 Feb 2022 19:17:54 +0000
Subject: [issue46637] Incorrect error message: "missing 1 required positional
 argument"
In-Reply-To: <1643990055.45.0.970752611144.issue46637@roundup.psfhosted.org>
Message-ID: <1644002274.0.0.353786576443.issue46637@roundup.psfhosted.org>


Change by Andre Roberge <andre.roberge at gmail.com>:


----------
nosy: +aroberge

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

From report at bugs.python.org  Fri Feb  4 14:25:23 2022
From: report at bugs.python.org (Vladimir Feinberg)
Date: Fri, 04 Feb 2022 19:25:23 +0000
Subject: [issue46639] Ceil division with math.ceildiv
Message-ID: <1644002723.68.0.838942257454.issue46639@roundup.psfhosted.org>


New submission from Vladimir Feinberg <vladimirfeinberg at gmail.com>:

I have a request related to the rejected proposal (https://bugs.python.org/issue43255) to introduce a ceildiv operator.

I frequently find myself wishing for a ceildiv function which computes `ceil(x/y)` for integers `x,y`. This comes up all the time when "batching" some resource and finding total consumption, be it for memory allocation or GUI manipulation or time bucketing or whatnot.

It is easy enough to implement this inline, but `math.ceildiv` would express intent clearly.

```
# x, y, out: int

# (A)
import math
out = math.ceil(x / y)  # clear intent but subtly changes type, and also incorrect for big ints

# (B)
out = int(math.ceil(x / y))  # wordy, especially if using this multiple times, still technically wrong

# (C)
out = (x + y - 1) // y  # too clever if you haven't seen it before, does it have desirable semantics for negatives?

# (D)
out = -(-x//y) 

def ceildiv(a: int, b: int) -> int:  # Clearest and correct, but should my library code really invent this wheel? 
  """Returns ceil(a/b)."""
  return -(-x//y)

out = ceildiv(x, y)
```

Even though these are all "one-liners", as you can see leaving people to complex manually-implemented `ceildiv`s might result in bugs or unclear handling of negatives.

----------
components: Library (Lib)
messages: 412527
nosy: Vladimir Feinberg
priority: normal
severity: normal
status: open
title: Ceil division with math.ceildiv
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Fri Feb  4 14:29:44 2022
From: report at bugs.python.org (Nathaniel Manista)
Date: Fri, 04 Feb 2022 19:29:44 +0000
Subject: [issue46639] Ceil division with math.ceildiv
In-Reply-To: <1644002723.68.0.838942257454.issue46639@roundup.psfhosted.org>
Message-ID: <1644002984.13.0.00331703101936.issue46639@roundup.psfhosted.org>


Change by Nathaniel Manista <nathaniel at google.com>:


----------
nosy: +Nathaniel Manista

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

From report at bugs.python.org  Fri Feb  4 14:31:00 2022
From: report at bugs.python.org (Nathaniel Manista)
Date: Fri, 04 Feb 2022 19:31:00 +0000
Subject: [issue43255] Ceil division with /// operator
In-Reply-To: <1613657884.47.0.693807596849.issue43255@roundup.psfhosted.org>
Message-ID: <1644003060.21.0.54202538703.issue43255@roundup.psfhosted.org>


Change by Nathaniel Manista <nathaniel at google.com>:


----------
nosy: +Nathaniel Manista

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

From report at bugs.python.org  Fri Feb  4 14:35:44 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Feb 2022 19:35:44 +0000
Subject: [issue46609] Generator-based coroutines in Python 3.10 docs
In-Reply-To: <1643804825.5.0.310548487717.issue46609@roundup.psfhosted.org>
Message-ID: <1644003344.86.0.663179975889.issue46609@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Fri Feb  4 14:40:52 2022
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 04 Feb 2022 19:40:52 +0000
Subject: [issue46639] Ceil division with math.ceildiv
In-Reply-To: <1644002723.68.0.838942257454.issue46639@roundup.psfhosted.org>
Message-ID: <1644003652.1.0.955075612366.issue46639@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Fri Feb  4 14:58:45 2022
From: report at bugs.python.org (Aaron Gokaslan)
Date: Fri, 04 Feb 2022 19:58:45 +0000
Subject: [issue46166] Get "self" args or non-null co_varnames from frame
 object with C-API
In-Reply-To: <1640288010.25.0.698839040509.issue46166@roundup.psfhosted.org>
Message-ID: <1644004725.96.0.888965171993.issue46166@roundup.psfhosted.org>


Aaron Gokaslan <aaronGokaslan at gmail.com> added the comment:

I saw the latest Python 3.11 5A release notes on the frame API changes. Do the notes mean the only officially supported way of accessing co_varnames is now through the Python interface and the inspect module? By using PyObject_GetAttrString?

Also, the documentation in the WhatsNew is a bit unclear as PyObject_GetAttrString(frame, "f_locals") doesn't work for PyFrameObject*, only PyObject* and it doesn't describe how to get the PyObject* version of FrameObject. The same problem also happens when trying to access the co_varnames field of the PyCodeObject*.

----------

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

From report at bugs.python.org  Fri Feb  4 14:59:44 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 04 Feb 2022 19:59:44 +0000
Subject: [issue46609] Generator-based coroutines in Python 3.10 docs
In-Reply-To: <1643804825.5.0.310548487717.issue46609@roundup.psfhosted.org>
Message-ID: <1644004784.1.0.875510934099.issue46609@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: +29312
pull_request: https://github.com/python/cpython/pull/31133

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

From report at bugs.python.org  Fri Feb  4 14:59:47 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Feb 2022 19:59:47 +0000
Subject: [issue46609] Generator-based coroutines in Python 3.10 docs
In-Reply-To: <1643804825.5.0.310548487717.issue46609@roundup.psfhosted.org>
Message-ID: <1644004787.65.0.752984430482.issue46609@roundup.psfhosted.org>


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


New changeset 5603db43ba7ba5568b7516d0e28730a2bc1e1f26 by Terry Jan Reedy in branch '3.10':
[3.10] bpo-46609: Update asyncio-task coroutine doc (GH-31132)
https://github.com/python/cpython/commit/5603db43ba7ba5568b7516d0e28730a2bc1e1f26


----------

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

From report at bugs.python.org  Fri Feb  4 15:06:08 2022
From: report at bugs.python.org (Segev Finer)
Date: Fri, 04 Feb 2022 20:06:08 +0000
Subject: [issue28686] py.exe ignored PATH when using python3 shebang
In-Reply-To: <1479110844.15.0.911795795866.issue28686@psf.upfronthosting.co.za>
Message-ID: <1644005168.21.0.0326015973107.issue28686@roundup.psfhosted.org>


Change by Segev Finer <segev208 at gmail.com>:


----------
nosy: +Segev Finer

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

From report at bugs.python.org  Fri Feb  4 15:15:08 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Feb 2022 20:15:08 +0000
Subject: [issue46637] Incorrect error message: "missing 1 required positional
 argument"
In-Reply-To: <1643990055.45.0.970752611144.issue46637@roundup.psfhosted.org>
Message-ID: <1644005708.0.0.36748102601.issue46637@roundup.psfhosted.org>


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

I think the incorrect qualification should be dropped, if sanely feasible.

More misleading are hidden positional-only args.  Doc:
  min(iterable, *[, key, default])
  min(arg1, arg2, *args[, key])

>>> min(iterator=(1,3))
Traceback (most recent call last):
  File "<pyshell#0>", line 1, in <module>
    min(iterator=(1,3))
TypeError: min expected at least 1 argument, got 0

1 was passed, but 0 were gotten, as the 1 passed was silently ignored.

----------
nosy: +terry.reedy
versions: +Python 3.11 -Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Feb  4 15:24:09 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Feb 2022 20:24:09 +0000
Subject: [issue46640] Python can now use the C99 NAN constant
Message-ID: <1644006249.4.0.292742084923.issue46640@roundup.psfhosted.org>


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

While debugging a GCC regression (*) on "HUGE_VAL * 0" used by Py_NAN macro, I noticed that Python can now C99 "NAN" constant.

(*) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104389

In bpo-45440, I already removed legacy code for pre-C99 support and old platforms:

"Building Python now requires a C99 <math.h> header file providing the following functions: copysign(), hypot(), isfinite(), isinf(), isnan(), round()."

Attached patch modifies Py_NAN to simply reuse NAN.

mathmodule.c and cmathmodule.c m_nan() still use _Py_dg_stdnan() by default (if PY_NO_SHORT_FLOAT_REPR is not defined).

----------
components: Interpreter Core
messages: 412531
nosy: vstinner
priority: normal
severity: normal
status: open
title: Python can now use the C99 NAN constant
versions: Python 3.11

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

From report at bugs.python.org  Fri Feb  4 15:26:32 2022
From: report at bugs.python.org (Br Km)
Date: Fri, 04 Feb 2022 20:26:32 +0000
Subject: [issue46641] multiplication error 2.2 and 2.1
Message-ID: <1644006392.6.0.966274499639.issue46641@roundup.psfhosted.org>


New submission from Br Km <jzradom at gmail.com>:

Python 3.6.9 (default, Dec  8 2021, 21:08:43) 
[GCC 8.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 2.2 * 2.1
4.620000000000001
>>>

----------
messages: 412532
nosy: jzradom
priority: normal
severity: normal
status: open
title: multiplication error 2.2 and 2.1
type: compile error
versions: Python 3.10

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

From report at bugs.python.org  Fri Feb  4 15:28:10 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Feb 2022 20:28:10 +0000
Subject: [issue46640] Python can now use the C99 NAN constant
In-Reply-To: <1644006249.4.0.292742084923.issue46640@roundup.psfhosted.org>
Message-ID: <1644006490.13.0.59519976571.issue46640@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Fri Feb  4 15:30:48 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Feb 2022 20:30:48 +0000
Subject: [issue46640] Python can now use the C99 NAN constant
In-Reply-To: <1644006249.4.0.292742084923.issue46640@roundup.psfhosted.org>
Message-ID: <1644006648.43.0.175148560619.issue46640@roundup.psfhosted.org>


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

The Py_NAN has a special implementation for the ICC compiler, if __INTEL_COMPILER and ICC_NAN_STRICT macros are defined, in bpo-21167:
---
commit edbc28ce81f46d042f9d5ddf9c5bc8cecebc715a
Author: R David Murray <rdmurray at bitdance.com>
Date:   Thu Aug 13 09:58:07 2015 -0400

    #21167: Fix definition of NAN when ICC used without -fp-model strict.
    
    Patch from Chris Hogan of Intel, reviewed by Mark Dickinson.
---

I don't know if it should be kept if Py_NAN is modified to use the NAN constant. In case of doubt, I prefer to remove the ICC code since we have no ICC buildbot anymore and maybe ICC changed in the meanwhile.

Also, I don't have acess to ICC.

----------
nosy: +mark.dickinson, r.david.murray

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

From report at bugs.python.org  Fri Feb  4 15:33:05 2022
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 04 Feb 2022 20:33:05 +0000
Subject: [issue46641] multiplication error 2.2 and 2.1
In-Reply-To: <1644006392.6.0.966274499639.issue46641@roundup.psfhosted.org>
Message-ID: <1644006785.44.0.318778317922.issue46641@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

See https://docs.python.org/3/tutorial/floatingpoint.html.

Your computer thinks in base 2 rather than base 10, unless you ask it nicely (https://docs.python.org/3/library/decimal.html) :)

----------
nosy: +zach.ware
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: compile error -> behavior
versions:  -Python 3.10

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

From report at bugs.python.org  Fri Feb  4 15:46:16 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Feb 2022 20:46:16 +0000
Subject: [issue46609] Generator-based coroutines in Python 3.10 docs
In-Reply-To: <1643804825.5.0.310548487717.issue46609@roundup.psfhosted.org>
Message-ID: <1644007576.41.0.0360161049255.issue46609@roundup.psfhosted.org>


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


New changeset 459e26f0987a12a19238baba422e13a8f7fcfca3 by Miss Islington (bot) in branch '3.9':
[3.9] bpo-46609: Update asyncio-task coroutine doc (GH-31132) 
https://github.com/python/cpython/commit/459e26f0987a12a19238baba422e13a8f7fcfca3


----------

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

From report at bugs.python.org  Fri Feb  4 15:46:31 2022
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 04 Feb 2022 20:46:31 +0000
Subject: [issue21762] update the import machinery to only use __spec__
In-Reply-To: <1402781631.86.0.838758150876.issue21762@psf.upfronthosting.co.za>
Message-ID: <1644007591.18.0.230571016877.issue21762@roundup.psfhosted.org>


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


----------
dependencies: +Use specs instead of just __loader__ in C code

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

From report at bugs.python.org  Fri Feb  4 15:47:15 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Feb 2022 20:47:15 +0000
Subject: [issue46640] Python can now use the C99 NAN constant
In-Reply-To: <1644006249.4.0.292742084923.issue46640@roundup.psfhosted.org>
Message-ID: <1644007635.8.0.445614802362.issue46640@roundup.psfhosted.org>


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

> mathmodule.c and cmathmodule.c m_nan() still use _Py_dg_stdnan() by default (if PY_NO_SHORT_FLOAT_REPR is not defined).

These functions are only use to create the following constants:

* math.nan
* cmath.nan
* cmath.nanj

----------

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

From report at bugs.python.org  Fri Feb  4 15:47:27 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Feb 2022 20:47:27 +0000
Subject: [issue46609] Generator-based coroutines in Python 3.10, 3.9 docs
In-Reply-To: <1643804825.5.0.310548487717.issue46609@roundup.psfhosted.org>
Message-ID: <1644007647.75.0.95146084656.issue46609@roundup.psfhosted.org>


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


----------
nosy:  -miss-islington
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
title: Generator-based coroutines in Python 3.10 docs -> Generator-based coroutines in Python 3.10, 3.9 docs

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

From report at bugs.python.org  Fri Feb  4 15:50:24 2022
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 04 Feb 2022 20:50:24 +0000
Subject: [issue21762] update the import machinery to only use __spec__
In-Reply-To: <1402781631.86.0.838758150876.issue21762@psf.upfronthosting.co.za>
Message-ID: <1644007824.67.0.670626080625.issue21762@roundup.psfhosted.org>


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

Dumping my personal notes here as backup and in case anyone else wants to know how this is going.


1. `__package__`
    - [x]  Make sure all uses of the attribute fall back on `__spec__` (done way back when)
    - [x]  Add an `ImportWarning` when the attribute is used but it differs from `__spec__`  (3.6)
    - [x]  Update code to prefer the spec over the attribute, raising `ImportWarning` when having to fall back to the attribute (3.10)
    - [ ]  Change `ImportWarning` to `DeprecationWarning` when falling back to the attribute
    - [ ]  Remove code in `importlib` that used the old attribute
2. `__loader__`
    - [x]  Make sure all Python code uses of the attribute fall back on `__spec__` (3.10)
    - [ ]  Update C code to fall back to using `__spec__` ([issue](https://bugs.python.org/issue42132))
    - [ ]  Add an `ImportWarning` when the attribute is used but it differs from `__spec__`
    - [ ]  Update code to prefer the spec over the attribute, raising `ImportWarning` when having to fall back to the attribute
    - [ ]  Change `ImportWarning` to `DeprecationWarning` when falling back to the attribute
    - [ ]  Remove code in `importlib` that used the old attribute
3. `__cached__`
    - [ ]  Make sure all uses of the attribute fall back on `__spec__`
    - [ ]  Add an `ImportWarning` when the attribute is used but it differs from `__spec__`
    - [ ]  Update code to prefer the spec over the attribute, raising `ImportWarning` when having to fall back to the attribute
    - [ ]  Change `ImportWarning` to `DeprecationWarning` when falling back to the attribute
    - [ ]  Remove code in `importlib` that used the old attribute

----------

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

From report at bugs.python.org  Fri Feb  4 15:55:44 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Feb 2022 20:55:44 +0000
Subject: [issue46640] Python can now use the C99 NAN constant
In-Reply-To: <1644006249.4.0.292742084923.issue46640@roundup.psfhosted.org>
Message-ID: <1644008144.24.0.578316880975.issue46640@roundup.psfhosted.org>


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

Manual test to check if m_nan(), _Py_dg_stdnan(0) and Py_NAN are exactly the same number (same bits):

$ ./python
>>> import math, struct
>>> m_nan=math.nan; Py_NAN=math.atan2(m_nan, 1.0)
>>> Py_NAN is m_nan
False
>>> struct.pack('d', m_nan) == struct.pack('d', Py_NAN)
True
>>> struct.pack('d', Py_NAN)
b'\x00\x00\x00\x00\x00\x00\xf8\x7f'

=> see attached script: test_nan_bits.py

"struct.pack('d', m_nan) == struct.pack('d', Py_NAN)" is true with GH-31134 on Fedora 35 with gcc-11.2.1-7.fc35.x86_64. I tested with "gcc -O0" and "gcc -O3".

GCC float.h defines NAN with:

    #define NAN (__builtin_nanf (""))

GCC: "Built-in Function: double __builtin_nan (const char *str): This is an implementation of the ISO C99 function nan."

----------
Added file: https://bugs.python.org/file50603/test_nan_bits.py

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

From report at bugs.python.org  Fri Feb  4 15:57:28 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Feb 2022 20:57:28 +0000
Subject: [issue46640] Python can now use the C99 NAN constant
In-Reply-To: <1644006249.4.0.292742084923.issue46640@roundup.psfhosted.org>
Message-ID: <1644008248.03.0.205451080264.issue46640@roundup.psfhosted.org>


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

Python/dtoa.c uses:

/* Standard NaN used by _Py_dg_stdnan. */

#define NAN_WORD0 0x7ff80000
#define NAN_WORD1 0

/* Return a 'standard' NaN value.

   There are exactly two quiet NaNs that don't arise by 'quieting' signaling
   NaNs (see IEEE 754-2008, section 6.2.1).  If sign == 0, return the one whose
   sign bit is cleared.  Otherwise, return the one whose sign bit is set.
*/

double
_Py_dg_stdnan(int sign)
{
    U rv;
    word0(&rv) = NAN_WORD0;
    word1(&rv) = NAN_WORD1;
    if (sign)
        word0(&rv) |= Sign_bit;
    return dval(&rv);
}

----------

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

From report at bugs.python.org  Fri Feb  4 16:14:19 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Feb 2022 21:14:19 +0000
Subject: [issue46640] Python can now use the C99 NAN constant
In-Reply-To: <1644006249.4.0.292742084923.issue46640@roundup.psfhosted.org>
Message-ID: <1644009259.35.0.745592598695.issue46640@roundup.psfhosted.org>


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

> see attached script: test_nan_bits.py

test_nan_bits.py says "True" for Python built with "clang -O3" and with "clang -O0".

----------

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

From report at bugs.python.org  Fri Feb  4 16:15:06 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 04 Feb 2022 21:15:06 +0000
Subject: [issue46639] Ceil division with math.ceildiv
In-Reply-To: <1644002723.68.0.838942257454.issue46639@roundup.psfhosted.org>
Message-ID: <1644009306.98.0.547418637372.issue46639@roundup.psfhosted.org>


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

See also issue31978.

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

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

From report at bugs.python.org  Fri Feb  4 16:15:08 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Feb 2022 21:15:08 +0000
Subject: [issue46640] Python can now use the C99 NAN constant
In-Reply-To: <1644006249.4.0.292742084923.issue46640@roundup.psfhosted.org>
Message-ID: <1644009308.68.0.356843645209.issue46640@roundup.psfhosted.org>


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

Using clang -E, I see that clang also replaces NAN with: __builtin_nanf ("").

----------

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

From report at bugs.python.org  Fri Feb  4 16:55:21 2022
From: report at bugs.python.org (Alex Waygood)
Date: Fri, 04 Feb 2022 21:55:21 +0000
Subject: [issue46586] In documentation contents enum.property erroneously
 links to built-in property
In-Reply-To: <1643555525.86.0.209520180874.issue46586@roundup.psfhosted.org>
Message-ID: <1644011721.16.0.458835243218.issue46586@roundup.psfhosted.org>


Alex Waygood <Alex.Waygood at Gmail.com> added the comment:

`enum.property` is new in Python 3.11, so this isn't an issue for 3.9 or 3.10.

----------
nosy: +AlexWaygood
versions:  -Python 3.10, Python 3.9

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

From report at bugs.python.org  Fri Feb  4 16:59:21 2022
From: report at bugs.python.org (Gregory Beauregard)
Date: Fri, 04 Feb 2022 21:59:21 +0000
Subject: [issue46642] typing: tested TypeVar instance subclass TypeError is
 incidental
Message-ID: <1644011961.17.0.0152846458354.issue46642@roundup.psfhosted.org>


New submission from Gregory Beauregard <greg at greg.red>:

https://github.com/python/cpython/blob/bf95ff91f2c1fc5a57190491f9ccdc63458b089e/Lib/test/test_typing.py#L227-L230

typing's testcases contain the following test to ensure instances of TypeVar cannot be subclassed:

def test_cannot_subclass_vars(self):
    with self.assertRaises(TypeError):
        class V(TypeVar('T')):
            pass

The reason this raises a TypeError is incidental and subject to behavior change, not because doing so is prohibited per se; what's happening is the class creation does the equivalent of type(TypeVar('T')(name, bases, namespace), but this calls TypeVar's __init__ function with these items as the TypeVar constraints. TypeVar runs typing._type_check on the type constraints passed to it, and the literals for the namespace/name do not pass the callable() check in typing._type_check, causing it to raise a TypeError. I find it dubious this is the behavior the testcase is intending to test and the error it gives is confusing

I propose we add __mro_entries__ to the TypeVar class that only contains a raise of TypeError to properly handle this case

I can write this patch

----------
components: Library (Lib)
messages: 412544
nosy: AlexWaygood, GBeauregard, Jelle Zijlstra, gvanrossum, kj, sobolevn
priority: normal
severity: normal
status: open
title: typing: tested TypeVar instance subclass TypeError is incidental
type: enhancement

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

From report at bugs.python.org  Fri Feb  4 17:17:25 2022
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 04 Feb 2022 22:17:25 +0000
Subject: [issue46586] In documentation contents enum.property erroneously
 links to built-in property
In-Reply-To: <1643555525.86.0.209520180874.issue46586@roundup.psfhosted.org>
Message-ID: <1644013045.28.0.292908387785.issue46586@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

What does the tilde (~) do?

----------

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

From report at bugs.python.org  Fri Feb  4 17:19:26 2022
From: report at bugs.python.org (Gregory Beauregard)
Date: Fri, 04 Feb 2022 22:19:26 +0000
Subject: [issue46643] typing.Annotated cannot wrap typing.ParamSpec args/kwargs
Message-ID: <1644013165.99.0.0164231326825.issue46643@roundup.psfhosted.org>


New submission from Gregory Beauregard <greg at greg.red>:

Consider the following.
```
import logging
from typing import Annotated, Callable, ParamSpec, TypeVar

T = TypeVar("T")
P = ParamSpec("P")

def add_logging(f: Callable[P, T]) -> Callable[P, T]:
    """A type-safe decorator to add logging to a function."""
    def inner(*args: Annotated[P.args, "meta"], **kwargs: P.kwargs) -> T:
        logging.info(f"{f.__name__} was called")
        return f(*args, **kwargs)
    return inner

@add_logging
def add_two(x: float, y: float) -> float:
    """Add two numbers together."""
    return x + y
```
This raises an error at runtime because P.args/P.kwargs cannot pass the typing._type_check called by Annotated because they are not callable(). This prevents being able to use Annotated on these type annotations.

This can be fixed by adding __call__ methods that raise to typing.ParamSpecArgs and typing.ParamSpecKwargs to match other typeforms.

I can write this patch given agreement

----------
components: Library (Lib)
messages: 412546
nosy: AlexWaygood, GBeauregard, Jelle Zijlstra, gvanrossum, kj
priority: normal
severity: normal
status: open
title: typing.Annotated cannot wrap typing.ParamSpec args/kwargs
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Fri Feb  4 17:19:38 2022
From: report at bugs.python.org (Gregory Beauregard)
Date: Fri, 04 Feb 2022 22:19:38 +0000
Subject: [issue46643] typing.Annotated cannot wrap typing.ParamSpec args/kwargs
In-Reply-To: <1644013165.99.0.0164231326825.issue46643@roundup.psfhosted.org>
Message-ID: <1644013178.75.0.694974892046.issue46643@roundup.psfhosted.org>


Change by Gregory Beauregard <greg at greg.red>:


----------
nosy: +sobolevn

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

From report at bugs.python.org  Fri Feb  4 17:26:05 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Feb 2022 22:26:05 +0000
Subject: [issue46166] Get "self" args or non-null co_varnames from frame
 object with C-API
In-Reply-To: <1640288010.25.0.698839040509.issue46166@roundup.psfhosted.org>
Message-ID: <1644013565.11.0.00915973103702.issue46166@roundup.psfhosted.org>


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

> PyObject_GetAttrString(frame, "f_locals") doesn't work for PyFrameObject*

Oh, would you mind to elaborate?

Example in Python:

$ ./python
Python 3.11.0a5+ 
>>> import sys
>>> f=sys._getframe()
>>> f.f_locals
{'__name__': '__main__', '__doc__': None, ...}

----------

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

From report at bugs.python.org  Fri Feb  4 18:02:57 2022
From: report at bugs.python.org (Gregory Beauregard)
Date: Fri, 04 Feb 2022 23:02:57 +0000
Subject: [issue46644] typing: remove callable() check from typing._type_check
Message-ID: <1644015777.96.0.875814750019.issue46644@roundup.psfhosted.org>


New submission from Gregory Beauregard <greg at greg.red>:

I propose removing the callable() check[1] from typing._type_check. This restriction is usually met in typeform instances by implementing a __call__ method that raises at runtime[2]. _type_check is called at runtime in a few disparate locations, such as in an argument to typing.Annotated or for certain stringified annotations in typing.get_type_hints.

Because the requirement to be callable is unexpected and shows up in situations not easily discoverable during development or common typing usage, it is the cause of several existing cpython bugs and will likely continue to be the cause of bugs in typeforms outside of cpython. Known cpython bugs caused by the callable() check are bpo-46643, bpo-44799, a substantial contributing factor to bpo-46642, and partly bpo-46511. I discovered bpo-46643 with only a cursory check of typing.py while writing this proposal. Moreover, it doesn't make any particular technical sense to me why it should be required to add an awkward __call__ method.

Removing the callable() check fails 10 tests:
7 tests: checking that an int literal is not a type
2 tests: testing that list literals are not valid types (e.g. [3] raises a TypeError because the literal [('name', str), ('id', int)] doesn't pass callable())
1 test: bpo-46642

The responsibility of determining these invalid typeforms (e.g. int literals) would need to be passed to a static type checker. If it's desired to do this at runtime it's my opinion that a different check would be more appropriate.

Have I missed any reasons for the callable() check? Can I remove the check and adjust or remove the tests?

[1] https://github.com/python/cpython/blob/bf95ff91f2c1fc5a57190491f9ccdc63458b089e/Lib/typing.py#L183-L184
[2] https://github.com/python/cpython/blob/bf95ff91f2c1fc5a57190491f9ccdc63458b089e/Lib/typing.py#L392-L393
[3] https://github.com/python/cpython/blob/bf95ff91f2c1fc5a57190491f9ccdc63458b089e/Lib/test/test_typing.py#L4262-L4263

----------
components: Library (Lib)
messages: 412548
nosy: AlexWaygood, GBeauregard, Jelle Zijlstra, gvanrossum, kj, levkivskyi, sobolevn
priority: normal
severity: normal
status: open
title: typing: remove callable() check from typing._type_check
type: enhancement

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

From report at bugs.python.org  Fri Feb  4 18:08:25 2022
From: report at bugs.python.org (Gregory Beauregard)
Date: Fri, 04 Feb 2022 23:08:25 +0000
Subject: [issue46643] typing.Annotated cannot wrap typing.ParamSpec args/kwargs
In-Reply-To: <1644013165.99.0.0164231326825.issue46643@roundup.psfhosted.org>
Message-ID: <1644016105.23.0.734828745427.issue46643@roundup.psfhosted.org>


Gregory Beauregard <greg at greg.red> added the comment:

We can also fix this with my proposal in bpo-46644. I'm okay with either fix (that or implementing __call__), or both.

----------

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

From report at bugs.python.org  Fri Feb  4 18:13:35 2022
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 04 Feb 2022 23:13:35 +0000
Subject: [issue42353] Proposal: re.prefixmatch method (alias for re.match)
In-Reply-To: <1605295623.12.0.914188426549.issue42353@roundup.psfhosted.org>
Message-ID: <1644016415.81.0.292122989726.issue42353@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith
versions: +Python 3.11 -Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42353>
_______________________________________

From report at bugs.python.org  Fri Feb  4 18:35:43 2022
From: report at bugs.python.org (Gregory Beauregard)
Date: Fri, 04 Feb 2022 23:35:43 +0000
Subject: [issue46644] typing: remove callable() check from typing._type_check
In-Reply-To: <1644015777.96.0.875814750019.issue46644@roundup.psfhosted.org>
Message-ID: <1644017743.0.0.754175269434.issue46644@roundup.psfhosted.org>


Gregory Beauregard <greg at greg.red> added the comment:

In addition to the 10 tests failed in test_typing.py, one additional test fails in test_types.py with this change: https://github.com/python/cpython/blob/bf95ff91f2c1fc5a57190491f9ccdc63458b089e/Lib/test/test_types.py#L834-L838 and those are all the tests in cpython changed.

This falls in category (1), checking that an int literal is not a type, but with the apparent intent to prevent index subscripting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46644>
_______________________________________

From report at bugs.python.org  Fri Feb  4 19:10:27 2022
From: report at bugs.python.org (Alex Waygood)
Date: Sat, 05 Feb 2022 00:10:27 +0000
Subject: [issue46586] In documentation contents enum.property erroneously
 links to built-in property
In-Reply-To: <1643555525.86.0.209520180874.issue46586@roundup.psfhosted.org>
Message-ID: <1644019827.57.0.479762408622.issue46586@roundup.psfhosted.org>


Alex Waygood <Alex.Waygood at Gmail.com> added the comment:

:func:`~enum.property` means that the visible text on the webpage will be "property", but the link will be to enum.property rather than builtins.property.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46586>
_______________________________________

From report at bugs.python.org  Fri Feb  4 19:12:22 2022
From: report at bugs.python.org (Alex Waygood)
Date: Sat, 05 Feb 2022 00:12:22 +0000
Subject: [issue46586] In documentation contents enum.property erroneously
 links to built-in property
In-Reply-To: <1643555525.86.0.209520180874.issue46586@roundup.psfhosted.org>
Message-ID: <1644019942.08.0.823591417777.issue46586@roundup.psfhosted.org>


Alex Waygood <Alex.Waygood at Gmail.com> added the comment:

The ~ always only uses the final part of the name for the display text, e.g.  `~collections.abc.Iterator` would have "Iterator" as the visible text on the website.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46586>
_______________________________________

From report at bugs.python.org  Fri Feb  4 19:40:55 2022
From: report at bugs.python.org (Alex Waygood)
Date: Sat, 05 Feb 2022 00:40:55 +0000
Subject: [issue46637] Incorrect error message: "missing 1 required positional
 argument"
In-Reply-To: <1643990055.45.0.970752611144.issue46637@roundup.psfhosted.org>
Message-ID: <1644021655.39.0.485461536602.issue46637@roundup.psfhosted.org>


Change by Alex Waygood <Alex.Waygood at Gmail.com>:


----------
nosy: +AlexWaygood

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46637>
_______________________________________

From report at bugs.python.org  Fri Feb  4 21:02:13 2022
From: report at bugs.python.org (Josh Triplett)
Date: Sat, 05 Feb 2022 02:02:13 +0000
Subject: [issue46645] Portable python3 shebang for Windows, macOS, and Linux
Message-ID: <1644026533.87.0.375364061362.issue46645@roundup.psfhosted.org>


New submission from Josh Triplett <josh at joshtriplett.org>:

I'm writing this issue on behalf of the Rust project.

The build system for the Rust compiler is a Python 3 script `x.py`, which orchestrates the build process for a user even if they don't already have Rust installed. (For instance, `x.py build`, `x.py test`, and various command-line arguments for more complex cases.)

We currently run into various issues making this script easy for people to use on all common platforms people build Rust on: Windows, macOS, and Linux.

If we use a shebang of `#!/usr/bin/env python3`, then x.py works for macOS and Linux users, and also works on Windows systems that install Python via the Windows store, but fails to run on Windows systems that install via the official Python installer, requiring users to explicitly invoke Python 3 on the script, and adding friction, support issues, and complexity to our documentation to help users debug that situation.

If we use a shebang of `#!/usr/bin/env python`, then x.py works for Windows users, fails on some modern macOS systems, works on other modern macOS systems (depending on installation method I think, e.g. homebrew vs Apple), fails on some modern Linux systems, and on macOS and Linux systems where it *does* work, it might be python2 or python3. So in practice, people often have to explicitly run `python3 x.py`, which again results in friction, support issues, and complexity in our documentation.

We've even considered things like `#!/bin/sh` and then writing a shell script hidden inside a Python triple-quoted string, but that doesn't work well on Windows where we can't count on the presence of a shell.

We'd love to write a single shebang that works for all of Windows, macOS, and Linux systems, and doesn't resort in recurring friction or support issues for us across the wide range of systems that our users use.

As far as we can tell, `#!/usr/bin/env python3` would work on all platforms, if the Python installer for Windows shipped a `python3.exe` and handled that shebang by using `python3.exe` as the interpreter.

Is that something that the official Python installer could consider adding, to make it easy for us to supply cross-platform Python 3 scripts that work out of the box for all our users?

Thank you,
Josh Triplett, on behalf of many Rust team members

----------
messages: 412553
nosy: joshtriplett
priority: normal
severity: normal
status: open
title: Portable python3 shebang for Windows, macOS, and Linux
type: behavior
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46645>
_______________________________________

From report at bugs.python.org  Fri Feb  4 21:12:56 2022
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 05 Feb 2022 02:12:56 +0000
Subject: [issue42353] Proposal: re.prefixmatch method (alias for re.match)
In-Reply-To: <1605295623.12.0.914188426549.issue42353@roundup.psfhosted.org>
Message-ID: <1644027176.69.0.924110583394.issue42353@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
keywords: +patch
pull_requests: +29314
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31137

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42353>
_______________________________________

From report at bugs.python.org  Fri Feb  4 21:36:29 2022
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 05 Feb 2022 02:36:29 +0000
Subject: [issue42353] Proposal: re.prefixmatch method (alias for re.match)
In-Reply-To: <1605295623.12.0.914188426549.issue42353@roundup.psfhosted.org>
Message-ID: <1644028589.79.0.970255123007.issue42353@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

What do other APIs in widely used languages do with regex terminology?  We appear to be the only popular language who anchors to the start of a string with an API named "match".

libpcre C: uses "match" to mean what we call "search" - https://www.pcre.org/current/doc/html/pcre2_match.html

Go: Uses "Match" to mean what we call "search" - https://pkg.go.dev/regexp#Match

JavaScript: Uses "match" to mean what we call "search" - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/match

Java: Uses "matches" (I think meaning what we call fullmatch?) - https://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html

C++ RE2: explicit "FullMatch" and "PartialMatch" APIs - https://github.com/google/re2 

Jave re2j: uses "matches" like Java regex.Pattern - https://github.com/google/re2j 

Ruby: Uses "match" as we do "search" - https://ruby-doc.org/core-2.4.0/Regexp.html

Rust: Uses match as we do "search" - https://docs.rs/regex/latest/regex/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42353>
_______________________________________

From report at bugs.python.org  Fri Feb  4 22:06:30 2022
From: report at bugs.python.org (Josh Triplett)
Date: Sat, 05 Feb 2022 03:06:30 +0000
Subject: [issue46645] Portable python3 shebang for Windows, macOS, and Linux
In-Reply-To: <1644026533.87.0.375364061362.issue46645@roundup.psfhosted.org>
Message-ID: <1644030390.08.0.314006906675.issue46645@roundup.psfhosted.org>


Josh Triplett <josh at joshtriplett.org> added the comment:

Correction to the above evaluation of `#!/usr/bin/env python3`, based on some retesting on Windows systems:

The failure case we encounter reasonably often involves the official Python installer for Windows, but applies specifically in the case of third-party shells such as MSYS2, which fail with that shebang. `#!/usr/bin/env python3` does work with the official Python installer when running from cmd or PowerShell, it just doesn't work from third-party shells.

We have enough users that cases like this come up reasonably often, and it'd be nice to Just Work in those cases too.

Thank you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46645>
_______________________________________

From report at bugs.python.org  Fri Feb  4 22:39:16 2022
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 05 Feb 2022 03:39:16 +0000
Subject: [issue46631] Implement a "strict" mode for getpass.getuser()
In-Reply-To: <1643954134.16.0.436701246605.issue46631@roundup.psfhosted.org>
Message-ID: <1644032356.47.0.0313408712095.issue46631@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

Here's an example for the suggested changes to _winapi.

Include these headers:

    #include <ntsecapi.h> // LsaGetLogonSessionData
    #include <subauth.h> // STATUS_SUCCESS

Add these argument-clinic macros to _winapi_functions:

    _WINAPI_GETCURRENTPROCESSTOKEN_METHODDEF
    _WINAPI_GETTOKENINFORMATION_METHODDEF
    _WINAPI_LSAGETLOGONSESSIONDATA_METHODDEF

Add TokenStatistics in winapi_exec():

    WINAPI_CONSTANT(F_DWORD, TokenStatistics);

Add minimal implementations that wrap the WinAPI functions:

    /*[clinic input]
    _winapi.GetCurrentProcessToken -> HANDLE

    Return a handle for the access token of the current process.
    [clinic start generated code]*/

    static HANDLE
    _winapi_GetCurrentProcessToken_impl(PyObject *module)
    /*[clinic end generated code: output=cf8e8e20dd41dd6e input=73a282cf3718af9e]*/

    {
        return GetCurrentProcessToken();
    }


    /*[clinic input]
    _winapi.GetTokenInformation

        handle: HANDLE
        information_class: unsigned_long
        /

    Get information from an access token.
    [clinic start generated code]*/

    static PyObject *
    _winapi_GetTokenInformation_impl(PyObject *module, HANDLE handle,
                                     unsigned long information_class)
    /*[clinic end generated code: output=caecec0a25658348 input=b277ad2414f1b03e]*/

    {
        if (information_class != TokenStatistics) {
            return PyErr_Format(
                        PyExc_NotImplementedError,
                        "Unsupported information class: %d",
                        information_class);
        }

        DWORD returned_size;
        TOKEN_STATISTICS info;

        if (!GetTokenInformation(handle, information_class, &info, sizeof(info),
                &returned_size)) {
            return PyErr_SetFromWindowsErr(0);
        }

        PyObject *result = PyDict_New();
        if (!result) {
            return NULL;
        }

        PyObject *value = PyLong_FromUnsignedLongLong(
                            (((uint64_t)info.AuthenticationId.HighPart) << 32) +
                            info.AuthenticationId.LowPart);
        if (!value) {
            goto error;
        }
        if (PyDict_SetItemString(result, "AuthenticationId", value) < 0) {
            Py_DECREF(value);
            goto error;
        }
        Py_DECREF(value);

        return result;

    error:
        Py_CLEAR(result);
        return NULL;
    }


    /*[clinic input]
    _winapi.LsaGetLogonSessionData

        logon_id: unsigned_long_long
        /
    Get data for the logon session identified by logon_id.
    [clinic start generated code]*/

    static PyObject *
    _winapi_LsaGetLogonSessionData_impl(PyObject *module,
                                        unsigned long long logon_id)
    /*[clinic end generated code: output=680ac7725ef34527 input=01ff4216b89d01ef]*/

    {
        SECURITY_LOGON_SESSION_DATA *pdata;
        LUID logon_luid;
        logon_luid.HighPart = logon_id >> 32;
        logon_luid.LowPart = logon_id & 0xFFFFFFFF;

        NTSTATUS status = LsaGetLogonSessionData(&logon_luid, &pdata);
        if (status != STATUS_SUCCESS) {
            return PyErr_SetFromWindowsErr(LsaNtStatusToWinError(status));
        }

        PyObject *result = PyDict_New();
        if (!result) {
            goto error;
        }

        PyObject *value = PyUnicode_FromWideChar(pdata->UserName.Buffer,
                                pdata->UserName.Length / sizeof(WCHAR));
        if (!value) {
            goto error;
        }
        if (PyDict_SetItemString(result, "UserName", value) < 0) {
            Py_DECREF(value);
            goto error;
        }
        Py_DECREF(value);

        LsaFreeReturnBuffer(pdata);
        return result;

    error:
        LsaFreeReturnBuffer(pdata);
        Py_CLEAR(result);
        return NULL;
    }

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46631>
_______________________________________

From report at bugs.python.org  Fri Feb  4 22:54:33 2022
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 05 Feb 2022 03:54:33 +0000
Subject: [issue31369] re.RegexFlag is not included in __all__,
 makes type inference less useful
In-Reply-To: <1504730402.58.0.544251648863.issue31369@psf.upfronthosting.co.za>
Message-ID: <1644033273.48.0.35408784749.issue31369@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:


New changeset fea7290a0ecee09bbce571d4d10f5881b7ea3485 by andrei kulakov in branch 'main':
bpo-31369: include ``RegexFlag`` in ``re.__all__`` (GH-30279)
https://github.com/python/cpython/commit/fea7290a0ecee09bbce571d4d10f5881b7ea3485


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31369>
_______________________________________

From report at bugs.python.org  Fri Feb  4 22:55:29 2022
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 05 Feb 2022 03:55:29 +0000
Subject: [issue31369] re.RegexFlag is not included in __all__,
 makes type inference less useful
In-Reply-To: <1504730402.58.0.544251648863.issue31369@psf.upfronthosting.co.za>
Message-ID: <1644033329.86.0.619608493458.issue31369@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

Thanks, everyone!

----------
components: +Library (Lib) -Regular Expressions
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> behavior
versions: +Python 3.11 -Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31369>
_______________________________________

From report at bugs.python.org  Fri Feb  4 23:19:28 2022
From: report at bugs.python.org (Jacob Walls)
Date: Sat, 05 Feb 2022 04:19:28 +0000
Subject: [issue41259] Find adverbs is not correct on the documentation
In-Reply-To: <1594312922.82.0.0846663616251.issue41259@roundup.psfhosted.org>
Message-ID: <1644034768.25.0.828754915447.issue41259@roundup.psfhosted.org>


Jacob Walls <jacobtylerwalls at gmail.com> added the comment:

Fixed in PR 21420, suggest closing as fixed.

----------
nosy: +jacobtylerwalls

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41259>
_______________________________________

From report at bugs.python.org  Sat Feb  5 00:12:57 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 05 Feb 2022 05:12:57 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644037977.98.0.788176174025.issue46323@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
assignee:  -> corona10
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Sat Feb  5 00:14:55 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 05 Feb 2022 05:14:55 +0000
Subject: [issue45447] IDLE: Support syntax highlighting for .pyi stub files
In-Reply-To: <1634052276.56.0.989526823091.issue45447@roundup.psfhosted.org>
Message-ID: <1644038095.15.0.283096724339.issue45447@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

For the open dialog, we only need the expanded extension list.  People with no-extension python code file must select 'all files'.  Once the file is open, we need the issource function to decide whether to turn on the colorizer.  I intend to review the patch itself tomorrow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45447>
_______________________________________

From report at bugs.python.org  Sat Feb  5 00:47:24 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 05 Feb 2022 05:47:24 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644040044.2.0.221801062385.issue46323@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
keywords: +patch
pull_requests: +29316
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31138

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Sat Feb  5 01:15:20 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 05 Feb 2022 06:15:20 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644041720.43.0.307687788521.issue46323@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


Added file: https://bugs.python.org/file50604/bench_callback.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Sat Feb  5 02:05:52 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Sat, 05 Feb 2022 07:05:52 +0000
Subject: [issue46646] `address` arg can be `bytes` for `ip_*` functions in
 `ipaddress` module
Message-ID: <1644044752.78.0.400898810491.issue46646@roundup.psfhosted.org>


New submission from Nikita Sobolev <mail at sobolevn.me>:

Right now the docs say:

> ipaddress.ip_interface(address)
> Return an IPv4Interface or IPv6Interface object depending on the IP address passed as argument. **address is a string or integer** representing the IP address. Either IPv4 or IPv6 addresses may be supplied; integers less than 2**32 will be considered to be IPv4 by default. A ValueError is raised if address does not represent a valid IPv4 or IPv6 address.

Note the `address is a string or integer` part.

But, this is not true. Counter example:

```
>>> import ipaddress
>>> ipaddress.ip_interface(b'0000')
IPv4Interface('48.48.48.48/32')
>>> ipaddress.ip_interface(b'1111')
IPv4Interface('49.49.49.49/32')
```

So, packed version that accepts `bytes`, should be also mentioned.

For `ip_address` types are not mentioned:

> ipaddress.ip_address(address)
> Return an IPv4Address or IPv6Address object depending on the IP address passed as argument. Either IPv4 or IPv6 addresses may be supplied; integers less than 2**32 will be considered to be IPv4 by default. A ValueError is raised if address does not represent a valid IPv4 or IPv6 address.

I will send a PR with proposed changes.

----------
assignee: docs at python
components: Documentation
messages: 412562
nosy: docs at python, sobolevn
priority: normal
severity: normal
status: open
title: `address` arg can be `bytes` for `ip_*` functions in `ipaddress` module
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46646>
_______________________________________

From report at bugs.python.org  Sat Feb  5 02:27:33 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Sat, 05 Feb 2022 07:27:33 +0000
Subject: [issue46646] `address` arg can be `bytes` for `ip_*` functions in
 `ipaddress` module
In-Reply-To: <1644044752.78.0.400898810491.issue46646@roundup.psfhosted.org>
Message-ID: <1644046053.16.0.251289149589.issue46646@roundup.psfhosted.org>


Change by Nikita Sobolev <mail at sobolevn.me>:


----------
keywords: +patch
pull_requests: +29317
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31139

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46646>
_______________________________________

From report at bugs.python.org  Sat Feb  5 03:20:36 2022
From: report at bugs.python.org (Christoph Reiter)
Date: Sat, 05 Feb 2022 08:20:36 +0000
Subject: [issue46645] Portable python3 shebang for Windows, macOS, and Linux
In-Reply-To: <1644026533.87.0.375364061362.issue46645@roundup.psfhosted.org>
Message-ID: <1644049236.1.0.410683377257.issue46645@roundup.psfhosted.org>


Christoph Reiter <reiter.christoph at gmail.com> added the comment:

(MSYS2 maintainer here) If you run a Python script in MSYS2 bash, the shebang gets interpreted by bash, which looks up in PATH (which by default doesn't include the full Windows PATH to avoid conflicts) and if installed leads to the MSYS2 included CPython to be invoked, either the Cygwin based one, or the MinGW fork, depending on the active MSYS2 environment.

In short, there is no System CPython involved in any of this.

----------
nosy: +lazka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46645>
_______________________________________

From report at bugs.python.org  Sat Feb  5 03:57:42 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 05 Feb 2022 08:57:42 +0000
Subject: [issue42353] Proposal: re.prefixmatch method (alias for re.match)
In-Reply-To: <1605295623.12.0.914188426549.issue42353@roundup.psfhosted.org>
Message-ID: <1644051462.61.0.634464606738.issue42353@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I am not convinced. What are examples of using re.match() instead of re.search()? How common is this type of errors?

There are perhaps many millions of scripts which use re.match(), deprecating re.match() at any time in future would be very destructive, and keeping an alias indefinitely would only add more confusion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42353>
_______________________________________

From report at bugs.python.org  Sat Feb  5 04:22:41 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 05 Feb 2022 09:22:41 +0000
Subject: [issue41259] Find adverbs is not correct on the documentation
In-Reply-To: <1594312922.82.0.0846663616251.issue41259@roundup.psfhosted.org>
Message-ID: <1644052961.08.0.161352017956.issue41259@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/issue41259>
_______________________________________

From report at bugs.python.org  Sat Feb  5 05:46:54 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Sat, 05 Feb 2022 10:46:54 +0000
Subject: [issue46647] `test_functools` unexpected failures when C
 `_functoolsmodule` is missing
Message-ID: <1644058014.78.0.386662810799.issue46647@roundup.psfhosted.org>


New submission from Nikita Sobolev <mail at sobolevn.me>:

Reproduction steps:

1. Add to `Setup.local`:

```
*disabled*
_functoolsmodule
```

2. `.configure && make -j`. Then, ensure that this module is not available:

```
? ./python.exe -c 'import _functools'                                         
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ModuleNotFoundError: No module named '_functools'
```

3. Run `test_functools`:

```
======================================================================
ERROR: test_bad_cmp (test.test_functools.TestCmpToKeyC)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/sobolev/Desktop/cpython/Lib/test/test_functools.py", line 905, in test_bad_cmp
    key = self.cmp_to_key(cmp1)
          ^^^^^^^^^^^^^^^^^^^^^
TypeError: cmp_to_key() takes 1 positional argument but 2 were given

======================================================================
ERROR: test_cmp_to_key (test.test_functools.TestCmpToKeyC)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/sobolev/Desktop/cpython/Lib/test/test_functools.py", line 869, in test_cmp_to_key
    key = self.cmp_to_key(cmp1)
          ^^^^^^^^^^^^^^^^^^^^^
TypeError: cmp_to_key() takes 1 positional argument but 2 were given

======================================================================
ERROR: test_cmp_to_key_arguments (test.test_functools.TestCmpToKeyC)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/sobolev/Desktop/cpython/Lib/test/test_functools.py", line 885, in test_cmp_to_key_arguments
    key = self.cmp_to_key(mycmp=cmp1)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: cmp_to_key() got multiple values for argument 'mycmp'

======================================================================
ERROR: test_hash (test.test_functools.TestCmpToKeyC)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/sobolev/Desktop/cpython/Lib/test/test_functools.py", line 941, in test_hash
    key = self.cmp_to_key(mycmp)
          ^^^^^^^^^^^^^^^^^^^^^^
TypeError: cmp_to_key() takes 1 positional argument but 2 were given

======================================================================
ERROR: test_obj_field (test.test_functools.TestCmpToKeyC)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/sobolev/Desktop/cpython/Lib/test/test_functools.py", line 920, in test_obj_field
    key = self.cmp_to_key(mycmp=cmp1)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: cmp_to_key() got multiple values for argument 'mycmp'

======================================================================
ERROR: test_sort_int (test.test_functools.TestCmpToKeyC)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/sobolev/Desktop/cpython/Lib/test/test_functools.py", line 926, in test_sort_int
    self.assertEqual(sorted(range(5), key=self.cmp_to_key(mycmp)),
                                          ^^^^^^^^^^^^^^^^^^^^^^
TypeError: cmp_to_key() takes 1 positional argument but 2 were given

======================================================================
ERROR: test_sort_int_str (test.test_functools.TestCmpToKeyC)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/sobolev/Desktop/cpython/Lib/test/test_functools.py", line 934, in test_sort_int_str
    values = sorted(values, key=self.cmp_to_key(mycmp))
                                ^^^^^^^^^^^^^^^^^^^^^^
TypeError: cmp_to_key() takes 1 positional argument but 2 were given

======================================================================
ERROR: test_pickle (test.test_functools.TestPartialC)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/sobolev/Desktop/cpython/Lib/test/test_functools.py", line 258, in test_pickle
    f_copy = pickle.loads(pickle.dumps(f, proto))
                          ^^^^^^^^^^^^^^^^^^^^^^
_pickle.PicklingError: Can't pickle <class 'functools.partial'>: it's not the same object as functools.partial

======================================================================
ERROR: test_recursive_pickle (test.test_functools.TestPartialC)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/sobolev/Desktop/cpython/Lib/test/test_functools.py", line 343, in test_recursive_pickle
    pickle.dumps(f, proto)
    ^^^^^^^^^^^^^^^^^^^^^^
_pickle.PicklingError: Can't pickle <class 'functools.partial'>: it's not the same object as functools.partial

======================================================================
ERROR: test_iterator_usage (test.test_functools.TestReduceC)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/sobolev/Desktop/cpython/Lib/test/test_functools.py", line 843, in test_iterator_usage
    self.assertEqual(self.reduce(add, SequenceClass(5)), 10)
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/sobolev/Desktop/cpython/Lib/functools.py", line 249, in reduce
    it = iter(sequence)
         ^^^^^^^^^^^^^^
TypeError: 'builtin_function_or_method' object is not iterable

======================================================================
ERROR: test_reduce (test.test_functools.TestReduceC)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/sobolev/Desktop/cpython/Lib/test/test_functools.py", line 794, in test_reduce
    self.assertEqual(self.reduce(add, ['a', 'b', 'c'], ''), 'abc')
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: reduce() takes from 2 to 3 positional arguments but 4 were given

======================================================================
FAIL: test_disallow_instantiation (test.test_functools.TestCmpToKeyC)
----------------------------------------------------------------------
TypeError: type() takes 1 or 3 arguments

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/sobolev/Desktop/cpython/Lib/test/test_functools.py", line 955, in test_disallow_instantiation
    support.check_disallow_instantiation(
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/sobolev/Desktop/cpython/Lib/test/support/__init__.py", line 2121, in check_disallow_instantiation
    testcase.assertRaisesRegex(TypeError, msg, tp, *args, **kwds)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: "cannot create 'type' instances" does not match "type() takes 1 or 3 arguments"

======================================================================
FAIL: test_attributes_unwritable (test.test_functools.TestPartialC)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/sobolev/Desktop/cpython/Lib/test/test_functools.py", line 402, in test_attributes_unwritable
    self.assertRaises(AttributeError, setattr, p, 'func', map)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: AttributeError not raised by setattr

======================================================================
FAIL: test_attributes_unwritable (test.test_functools.TestPartialCSubclass)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/sobolev/Desktop/cpython/Lib/test/test_functools.py", line 402, in test_attributes_unwritable
    self.assertRaises(AttributeError, setattr, p, 'func', map)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: AttributeError not raised by setattr

----------------------------------------------------------------------
Ran 249 tests in 0.690s

FAILED (failures=3, errors=11)
test test_functools failed
test_functools failed (11 errors, 3 failures)

== Tests result: FAILURE ==

1 test failed:
    test_functools

Total duration: 1.3 sec
Tests result: FAILURE
```

List of individual problems:

1. This function is defined assuming that `c_functools` always has `.lru_cache`: https://github.com/python/cpython/blob/fea7290a0ecee09bbce571d4d10f5881b7ea3485/Lib/test/test_functools.py#L1860-L1862
2. `TestLRUC` is never skipped: https://github.com/python/cpython/blob/fea7290a0ecee09bbce571d4d10f5881b7ea3485/Lib/test/test_functools.py#L1879-L1881 I think it should be, because there's no need to test `_lru_cache_wrapper` twice for just python implementation (default if `_functools` is missing)
3. All similar modules tend to use `fresh=` in `import_fresh_module`, for example: https://github.com/python/cpython/blob/fea7290a0ecee09bbce571d4d10f5881b7ea3485/Lib/test/test_typing.py#L43-L44 But, `test_functools` does not do this: https://github.com/python/cpython/blob/fea7290a0ecee09bbce571d4d10f5881b7ea3485/Lib/test/test_functools.py#L30 So, even if `_functools` is missing, `c_functools` will not be `None`, it will still be `functools.py` module! And this causes multiple unexpected test failures above


Related:
- https://github.com/python/cpython/pull/23405
- https://github.com/python/cpython/pull/23407

I will send a patch for this in a moment.

----------
components: Tests
messages: 412565
nosy: rhettinger, shihai1991, sobolevn
priority: normal
severity: normal
status: open
title: `test_functools` unexpected failures when C `_functoolsmodule` is missing
type: behavior
versions: Python 3.10, Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46647>
_______________________________________

From report at bugs.python.org  Sat Feb  5 06:11:30 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Sat, 05 Feb 2022 11:11:30 +0000
Subject: [issue46647] `test_functools` unexpected failures when C
 `_functoolsmodule` is missing
In-Reply-To: <1644058014.78.0.386662810799.issue46647@roundup.psfhosted.org>
Message-ID: <1644059490.2.0.885927388355.issue46647@roundup.psfhosted.org>


Change by Nikita Sobolev <mail at sobolevn.me>:


----------
keywords: +patch
pull_requests: +29318
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31141

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46647>
_______________________________________

From report at bugs.python.org  Sat Feb  5 06:39:30 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Sat, 05 Feb 2022 11:39:30 +0000
Subject: [issue36019] test_urllib fail in s390x buildbots:
 http://www.example.com/
In-Reply-To: <1550450495.08.0.90804425705.issue36019@roundup.psfhosted.org>
Message-ID: <1644061170.55.0.312183492515.issue36019@roundup.psfhosted.org>


Nikita Sobolev <mail at sobolevn.me> added the comment:

`test.test_urllib2.MiscTests.test_issue16464` started to fail again:

```
 ======================================================================
ERROR: test_issue16464 (test.test_urllib2.MiscTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/runner/work/cpython/cpython/Lib/contextlib.py", line 155, in __exit__
    self.gen.throw(typ, value, traceback)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/runner/work/cpython/cpython/Lib/test/support/socket_helper.py", line 245, in transient_internet
    yield
    ^^^^^
  File "/Users/runner/work/cpython/cpython/Lib/test/test_urllib2.py", line 1799, in test_issue16464
    opener.open(request, "1".encode("us-ascii"))
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/runner/work/cpython/cpython/Lib/urllib/request.py", line 525, in open
    response = meth(req, response)
               ^^^^^^^^^^^^^^^^^^^
  File "/Users/runner/work/cpython/cpython/Lib/urllib/request.py", line 634, in http_response
    response = self.parent.error(
               ^^^^^^^^^^^^^^^^^^
  File "/Users/runner/work/cpython/cpython/Lib/urllib/request.py", line 563, in error
    return self._call_chain(*args)
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/runner/work/cpython/cpython/Lib/urllib/request.py", line 496, in _call_chain
    result = func(*args)
             ^^^^^^^^^^^
  File "/Users/runner/work/cpython/cpython/Lib/urllib/request.py", line 643, in http_error_default
    raise HTTPError(req.full_url, code, msg, hdrs, fp)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
urllib.error.HTTPError: HTTP Error 404: Not Found

----------------------------------------------------------------------
Ran 1 test in 0.093s
```

Link: https://github.com/python/cpython/runs/5077404591?check_suite_focus=true#step:7:705

Today I had like 3 or 4 different CI failures because of it.

----------
nosy: +sobolevn

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36019>
_______________________________________

From report at bugs.python.org  Sat Feb  5 06:45:33 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Sat, 05 Feb 2022 11:45:33 +0000
Subject: [issue46648] `test.test_urllib2.MiscTests.test_issue16464` started to
 fail
Message-ID: <1644061533.84.0.594817920054.issue46648@roundup.psfhosted.org>


New submission from Nikita Sobolev <mail at sobolevn.me>:

Today I've noticed that a lot of CI runs fail because of this test.

Output:

```
======================================================================
ERROR: test_issue16464 (test.test_urllib2.MiscTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/sobolev/Desktop/cpython/Lib/contextlib.py", line 155, in __exit__
    self.gen.throw(typ, value, traceback)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/sobolev/Desktop/cpython/Lib/test/support/socket_helper.py", line 245, in transient_internet
    yield
    ^^^^^
  File "/Users/sobolev/Desktop/cpython/Lib/test/test_urllib2.py", line 1799, in test_issue16464
    opener.open(request, "1".encode("us-ascii"))
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/sobolev/Desktop/cpython/Lib/urllib/request.py", line 525, in open
    response = meth(req, response)
               ^^^^^^^^^^^^^^^^^^^
  File "/Users/sobolev/Desktop/cpython/Lib/urllib/request.py", line 634, in http_response
    response = self.parent.error(
               ^^^^^^^^^^^^^^^^^^
  File "/Users/sobolev/Desktop/cpython/Lib/urllib/request.py", line 563, in error
    return self._call_chain(*args)
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/sobolev/Desktop/cpython/Lib/urllib/request.py", line 496, in _call_chain
    result = func(*args)
             ^^^^^^^^^^^
  File "/Users/sobolev/Desktop/cpython/Lib/urllib/request.py", line 643, in http_error_default
    raise HTTPError(req.full_url, code, msg, hdrs, fp)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
urllib.error.HTTPError: HTTP Error 404: Not Found

----------------------------------------------------------------------
Ran 1 test in 0.448s

FAILED (errors=1)
/Users/sobolev/Desktop/cpython/Lib/test/support/__init__.py:705: ResourceWarning: unclosed <socket.socket [closed] fd=7, family=2, type=1, proto=6>
  gc.collect()
ResourceWarning: Enable tracemalloc to get the object allocation traceback
test test_urllib2 failed
test_urllib2 failed (1 error)

== Tests result: FAILURE ==
```

I can also reproduce this failure locally with:

```
./python.exe -m test -v test_urllib2 -m test_issue16464 -u network
```

Related https://bugs.python.org/issue36019

----------
components: Tests
messages: 412567
nosy: sobolevn
priority: normal
severity: normal
status: open
title: `test.test_urllib2.MiscTests.test_issue16464` started to fail
type: behavior
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46648>
_______________________________________

From report at bugs.python.org  Sat Feb  5 06:45:50 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Sat, 05 Feb 2022 11:45:50 +0000
Subject: [issue36019] test_urllib fail in s390x buildbots:
 http://www.example.com/
In-Reply-To: <1550450495.08.0.90804425705.issue36019@roundup.psfhosted.org>
Message-ID: <1644061550.98.0.18819334574.issue36019@roundup.psfhosted.org>


Nikita Sobolev <mail at sobolevn.me> added the comment:

I can also reproduce it locally with: `./python.exe -m test -v test_urllib2 -m test_issue16464 -u network`

I've opened a new issue for it: https://bugs.python.org/issue46648

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36019>
_______________________________________

From report at bugs.python.org  Sat Feb  5 08:07:42 2022
From: report at bugs.python.org (Gabriele N Tornetta)
Date: Sat, 05 Feb 2022 13:07:42 +0000
Subject: [issue46649] Propagate Python thread name to thread state structure
Message-ID: <1644066462.37.0.754357637612.issue46649@roundup.psfhosted.org>


New submission from Gabriele N Tornetta <phoenix1987 at gmail.com>:

For tools like Austin (https://github.com/P403n1x87/austin) it is currently quite challenging to derive the name of a thread based on the information exposed by the PyThreadState structure and one stored in threading._active. I would like to propose propagating the thread name from the Thread object to the PyThreadState structure so that profiling information from tools like Austin could easily be enriched with the names of each sampled thread.

----------
components: C API
messages: 412569
nosy: Gabriele Tornetta
priority: normal
severity: normal
status: open
title: Propagate Python thread name to thread state structure
type: enhancement
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46649>
_______________________________________

From report at bugs.python.org  Sat Feb  5 08:18:12 2022
From: report at bugs.python.org (Gabriele N Tornetta)
Date: Sat, 05 Feb 2022 13:18:12 +0000
Subject: [issue46649] Propagate Python thread name to thread state structure
In-Reply-To: <1644066462.37.0.754357637612.issue46649@roundup.psfhosted.org>
Message-ID: <1644067092.96.0.644122766476.issue46649@roundup.psfhosted.org>


Change by Gabriele N Tornetta <phoenix1987 at gmail.com>:


----------
keywords: +patch
pull_requests: +29319
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31142

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46649>
_______________________________________

From report at bugs.python.org  Sat Feb  5 08:23:28 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 05 Feb 2022 13:23:28 +0000
Subject: [issue46649] Propagate Python thread name to thread state structure
In-Reply-To: <1644066462.37.0.754357637612.issue46649@roundup.psfhosted.org>
Message-ID: <1644067408.57.0.28967127037.issue46649@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

bpo-15500 looks like a more generic option, debuggers should be able to retrieve thread names.

faulthandler dumps "tstate->thread_id", maybe it should also dump "tstate->native_thread_id" and/or the thread name.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46649>
_______________________________________

From report at bugs.python.org  Sat Feb  5 08:32:15 2022
From: report at bugs.python.org (Gabriele N Tornetta)
Date: Sat, 05 Feb 2022 13:32:15 +0000
Subject: [issue46649] Propagate Python thread name to thread state structure
In-Reply-To: <1644066462.37.0.754357637612.issue46649@roundup.psfhosted.org>
Message-ID: <1644067935.41.0.938098852436.issue46649@roundup.psfhosted.org>


Gabriele N Tornetta <phoenix1987 at gmail.com> added the comment:

Thanks for mentioning that issue, it didn't come up in my search for a similar one. Indeed, with the proposals in bpo-15500 implemented, and the fact that native_thread_id is already in PyThreadState, retrieving the name should be easy and might make for a better implementation than what I'm proposing. Furthermore, doing this at the OS level would benefit an even larger set of tools. What pushed me to open this issue is the fact that this feature has been lacking for quite some time (indeed bpo-15500 dates back to 2012!), so I thought I'd propose a different approach in case it would get a quicker resolution this way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46649>
_______________________________________

From report at bugs.python.org  Sat Feb  5 08:39:14 2022
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 05 Feb 2022 13:39:14 +0000
Subject: [issue46647] `test_functools` unexpected failures when C
 `_functoolsmodule` is missing
In-Reply-To: <1644058014.78.0.386662810799.issue46647@roundup.psfhosted.org>
Message-ID: <1644068354.45.0.965808093533.issue46647@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

_functoolsmodule is a core bootstrap module and defined in Modules/Setup.bootstrap. It has no external dependencies. There is no reason and no point to disable the module.

We can safely assume that all modules defined in Modules/Setup.bootstrap are always available. (Maybe except for pwd, but that is a different story.)

I propose to close the bug and PR as wontfix.

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46647>
_______________________________________

From report at bugs.python.org  Sat Feb  5 08:40:17 2022
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 05 Feb 2022 13:40:17 +0000
Subject: [issue46632] test_ssl: 2 tests fail on cstratak-CentOS9-fips-x86_64
In-Reply-To: <1643968485.02.0.29316293905.issue46632@roundup.psfhosted.org>
Message-ID: <1644068417.47.0.810202312092.issue46632@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
assignee: christian.heimes -> 
type:  -> behavior
versions: +Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46632>
_______________________________________

From report at bugs.python.org  Sat Feb  5 08:44:16 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Sat, 05 Feb 2022 13:44:16 +0000
Subject: [issue46647] `test_functools` unexpected failures when C
 `_functoolsmodule` is missing
In-Reply-To: <1644058014.78.0.386662810799.issue46647@roundup.psfhosted.org>
Message-ID: <1644068656.14.0.210220768989.issue46647@roundup.psfhosted.org>


Nikita Sobolev <mail at sobolevn.me> added the comment:

Cristian, in this case - is there a reason to keep `skipUnless(c_functools)` around? 

If we are sure that it is always available - then it should be always tested. 

We either should have:
1. Cleanly defined skips that work (this PR)
2. Unconditional coverage

Or do you think that some middle-ground is possible?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46647>
_______________________________________

From report at bugs.python.org  Sat Feb  5 08:55:28 2022
From: report at bugs.python.org (Oleg Iarygin)
Date: Sat, 05 Feb 2022 13:55:28 +0000
Subject: [issue46649] Propagate Python thread name to thread state structure
In-Reply-To: <1644066462.37.0.754357637612.issue46649@roundup.psfhosted.org>
Message-ID: <1644069328.26.0.399649908565.issue46649@roundup.psfhosted.org>


Oleg Iarygin <oleg at arhadthedev.net> added the comment:

> bpo-15500 looks like a more generic option, debuggers should be able to retrieve thread names.

That option is not viable.

1. > Created on 2012-07-30 16:19 by bra, last changed 2022-01-19 00:32 by pitrou

2. > I don't think this should be done by default as it will break people's expectations and, perhaps worse, compatibility.

3. > It is indeed the compatibility that is the worse issue.  The problem is what people have gotten used to and may have coded their applications to expect/deal with.  I agree with you that most people would *not* find it surprising to see the name reflected in the OS, but I don't think the convenience of that is worth introducing a potential backward incompatibility.

Any chances?

----------
nosy: +arhadthedev

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46649>
_______________________________________

From report at bugs.python.org  Sat Feb  5 08:58:29 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 05 Feb 2022 13:58:29 +0000
Subject: [issue44796] Add __parameters__ and __getitem__ in TypeVar and
 ParamSpec
In-Reply-To: <1627738289.78.0.80035642919.issue44796@roundup.psfhosted.org>
Message-ID: <1644069509.76.0.141915743532.issue44796@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +29321
pull_request: https://github.com/python/cpython/pull/31143

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44796>
_______________________________________

From report at bugs.python.org  Sat Feb  5 09:21:07 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 05 Feb 2022 14:21:07 +0000
Subject: [issue44796] Add __parameters__ and __getitem__ in TypeVar and
 ParamSpec
In-Reply-To: <1627738289.78.0.80035642919.issue44796@roundup.psfhosted.org>
Message-ID: <1644070867.31.0.371767451133.issue44796@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I have created an alternative PR 31143 which adds special method __typing_subst__ in TypeVar and ParamSpec instead of __parameters__ and __getitem__. It has almost the same effect except making TypeVar and ParamSpec and subscriptable. The Python code in typing.py and _collections_abc.py is simplified, but the C code is little changed.

But on other hand, the reasons for PR 27511:

1. We already implemented __getitem__ for a Concatenate alias, although it is never documented. It is not even necessary, it is a pure implementation detail which makes the code for nested variables substitution simpler. Adding __parameters__ and __getitem__ in TypeVar and ParamSpec would have the same effect on simplification of the code.

2. There is a use case for subscription of TypeVar. For example:

if version < 2:
   RetType = T
elif version < 3:
   RetType = Optional[T]
else:
   RetType = Optional[T] | Literal[Unknown]

def get_int(precision: int) -> RetType[int]: ...
def get_str(encoding: str) -> RetType[str]: ...
def get_any(converter: Callable[[str], T]) -> RetType[T]: ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44796>
_______________________________________

From report at bugs.python.org  Sat Feb  5 10:08:10 2022
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 05 Feb 2022 15:08:10 +0000
Subject: [issue46640] Python can now use the C99 NAN constant
In-Reply-To: <1644006249.4.0.292742084923.issue46640@roundup.psfhosted.org>
Message-ID: <1644073690.95.0.432763164021.issue46640@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The big blocker here is that a platform that fully supports C99 might not define the "NAN" macro. I don't think we can require that NAN be defined in order for Python to build (which is what the PR currently does, if I'm understanding it correctly).

Python deliberately doesn't assume IEEE 754 floating-point. By requiring that the C "NAN" macro is present to be able to build Python, we'd be effectively requiring IEEE 754 by stealth. (No other common floating-point format has NaNs.)

I'd be fully on board with a decision to require IEEE 754 floating-point for Python in future, but that decision would at least need a python-dev discussion - we shouldn't sneak it in by the back door.

----------
nosy: +rhettinger, tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46640>
_______________________________________

From report at bugs.python.org  Sat Feb  5 10:50:11 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Sat, 05 Feb 2022 15:50:11 +0000
Subject: [issue46650] `priority` in `sched.scheduler` is not sufficiently
 tested
Message-ID: <1644076210.74.0.445085597972.issue46650@roundup.psfhosted.org>


New submission from Nikita Sobolev <mail at sobolevn.me>:

Right now there only a single test to ensure `priority` works correctly in `scheduler`: https://github.com/python/cpython/blob/fea7290a0ecee09bbce571d4d10f5881b7ea3485/Lib/test/test_sched.py#L90-L97

It looks like it is not enough. Why?

```
for priority in [1, 2, 3, 4, 5]:
  z = scheduler.enterabs(0.01, priority, fun, (priority,))
scheduler.run()
self.assertEqual(l, [1, 2, 3, 4, 5])
```

This test does not actually test different priorities. It only tests that a direct one works correctly. But, this might be a pure coincidence that numbers match. They are spawned in this particular order.

What if there are equal numbers? Like `[1, 2, 1]`

I propose adding more examples to this test. PR is on its way.

----------
components: Tests
messages: 412577
nosy: sobolevn
priority: normal
severity: normal
status: open
title: `priority` in `sched.scheduler` is not sufficiently tested
type: behavior
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46650>
_______________________________________

From report at bugs.python.org  Sat Feb  5 10:51:16 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Sat, 05 Feb 2022 15:51:16 +0000
Subject: [issue46650] `priority` in `sched.scheduler` is not sufficiently
 tested
In-Reply-To: <1644076210.74.0.445085597972.issue46650@roundup.psfhosted.org>
Message-ID: <1644076276.03.0.958736371768.issue46650@roundup.psfhosted.org>


Change by Nikita Sobolev <mail at sobolevn.me>:


----------
keywords: +patch
pull_requests: +29322
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31144

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46650>
_______________________________________

From report at bugs.python.org  Sat Feb  5 10:59:57 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 05 Feb 2022 15:59:57 +0000
Subject: [issue46608] Exclude marshalled-frozen data if deep-freezing to save
 300 KB space
In-Reply-To: <1643792907.85.0.286906427988.issue46608@roundup.psfhosted.org>
Message-ID: <1644076797.59.0.586376567197.issue46608@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset 9d4161a60ca8b470148ffd6c73e3110a0aa6d66f by Kumar Aditya in branch 'main':
bpo-46608: Fix argument parsing in freeze_modules.py (GH-31131)
https://github.com/python/cpython/commit/9d4161a60ca8b470148ffd6c73e3110a0aa6d66f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46608>
_______________________________________

From report at bugs.python.org  Sat Feb  5 11:09:18 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Sat, 05 Feb 2022 16:09:18 +0000
Subject: [issue46479] Implement typing.reveal_locals
In-Reply-To: <1642914950.74.0.308190454121.issue46479@roundup.psfhosted.org>
Message-ID: <1644077358.76.0.581823931733.issue46479@roundup.psfhosted.org>


Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:

Withdrawn as there's insufficient demand for this function.

----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46479>
_______________________________________

From report at bugs.python.org  Sat Feb  5 11:31:36 2022
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 05 Feb 2022 16:31:36 +0000
Subject: [issue46639] Ceil division with math.ceildiv
In-Reply-To: <1644002723.68.0.838942257454.issue46639@roundup.psfhosted.org>
Message-ID: <1644078696.12.0.465068726414.issue46639@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'm not convinced that this deserves to be a math module function. I agree that `-(-x // y)`, while simple to write, isn't necessarily obvious. But it does have some advantages, like not needing an import, and being naturally duck-typed, so that it automatically does the right thing for floats, or `fractions.Fraction` objects, or `numpy.int64` objects, or SymPy integers. (Not for `Decimal` instances, but that's another story.) Unless we were to add a whole __ceildiv__ mechanism, a math module implementation would necessarily be limited to integers. (Or perhaps integers and floats.)

There's also the "thin end of the wedge" argument: if ceildiv, why not also ceilrem, ceildivrem, rounddiv, roundmod, etc.

The main issue with the `-(-x // y)` spelling seems to be discoverability: if everyone knew that this was the right way to spell ceiling division, then there wouldn't be a problem. And I'm not convinced that a math.ceildiv function would necessarily solve the discoverability problem, either.

So maybe the solution is to advertise the `-(-x // y)` pattern better in documentation, for example at the point where floor division is introduced in the library reference?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46639>
_______________________________________

From report at bugs.python.org  Sat Feb  5 11:42:34 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 05 Feb 2022 16:42:34 +0000
Subject: [issue46640] Python can now use the C99 NAN constant
In-Reply-To: <1644006249.4.0.292742084923.issue46640@roundup.psfhosted.org>
Message-ID: <1644079354.76.0.516488002368.issue46640@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> The big blocker here is that a platform that fully supports C99 might not define the "NAN" macro. I don't think we can require that NAN be defined in order for Python to build (which is what the PR currently does, if I'm understanding it correctly).

If a platform doesn't implement NaN, it should define the Py_NO_NAN macro:

/* Py_NAN
 * A value that evaluates to a NaN. On IEEE 754 platforms INF*0 or
 * INF/INF works. Define Py_NO_NAN in pyconfig.h if your platform
 * doesn't support NaNs.
 */
#if !defined(Py_NAN) && !defined(Py_NO_NAN)
   // Use C99 "NAN" constant: quiet Not-A-Number (when supported)
#  define Py_NAN NAN
#endif

Or do you mean that a platform can support NaN but don't define the <math.h> NAN macro?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46640>
_______________________________________

From report at bugs.python.org  Sat Feb  5 11:47:14 2022
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 05 Feb 2022 16:47:14 +0000
Subject: [issue46640] Python can now use the C99 NAN constant
In-Reply-To: <1644006249.4.0.292742084923.issue46640@roundup.psfhosted.org>
Message-ID: <1644079634.55.0.337980622763.issue46640@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> If a platform doesn't implement NaN, it should define the Py_NO_NAN macro

Ah. In that case your PR description (and the PR news entry) is misleading:

> Building Python now requires a C99 <math.h> header file providing the
> NAN constant.

Please could you update them?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46640>
_______________________________________

From report at bugs.python.org  Sat Feb  5 12:32:17 2022
From: report at bugs.python.org (Vladimir Feinberg)
Date: Sat, 05 Feb 2022 17:32:17 +0000
Subject: [issue46639] Ceil division with math.ceildiv
In-Reply-To: <1644078696.12.0.465068726414.issue46639@roundup.psfhosted.org>
Message-ID: <CAArNnJfs1HmRZpiS0A7h6mbcnUaaO9oFZY=2zb54aghnZVqb=g@mail.gmail.com>


Vladimir Feinberg <vladimirfeinberg at gmail.com> added the comment:

Mark, I will say I'm pretty sympathetic to the feature-bloat avoidance
perspective here, and if the outcome here is to improve docs, that's still
a win, I think.

That said, since this thread will become precedent, and I think
`math.ceildiv` is the exactly-appropriate amount of commitment Lib should
make to the function (not __ceildiv__ and not "just" a doc note), let me
try to give `ceildiv` the strongest legs I can think of before we make a
decision.

1. Not needing an import - I don't find importing such a standard library
as `math` that onerous. We're not adding a new package here, just a
function. This skepticism could be applied to any existing library
function. Even `sys.stdout` needs an import.
2. Natural duck typing - I'll admit, this is pretty nice. But if that's the
argument, I'd expect this to work to its fullest extent. Namely, I'd expect
this to "naturally" work for any ring, and it doesn't. Z/nZ is a common one
and np.uint is a more common one where the identity -(-x // y) = ceildiv(x,
y) does not hold. The benefit of `math.ceildiv` is it'd either support it,
or say it doesn't, but at least it's explicit.
3. Thin end of wedge - A priori, I would put ceildiv as special because of
the "resource coverage" use case I described in my initial bug message. A
posteriori, there's a clear "kink" in the graph of usage here: ceildiv
(3033) <https://github.com/search?l=&q=ceildiv+language%3APython&type=code>,
rounddiv (25)
<https://github.com/search?q=rounddiv+language%3APython&type=code>, roundmod
(7) <https://github.com/search?q=roundmod+language%3APython&type=code>, ceilrem
(0) <https://github.com/search?q=ceilrem+language%3APython&type=code>,
ceildivrem
(0) <https://github.com/search?q=ceildivrem+language%3APython&type=code>.

But most importantly, let me detail what motivated me to post this. I was
working on unit tests for linear algebra code which blocked its operations.
But to not involve a lot of context, I'll provide a similarly-structured
use case. Say we're making a controller for a game engine GUI and need to
figure out how to paint sprites.

```
# sprite_A.py
class A:
  def get_covering_rectangle():
    return self.x, self.y, self.x - (-self.width // GRID_WIDTH), self.y -
(-self.height // GRID_HEIGHT)
```

Especially if I also use `-(-x//y)` elsewhere, this is just asking too much
of the reader. I could leave a comment to the tune of `# Note below is
equivalent to + (-(-x//y)), the ceildiv operator, and this works because x
isn't a uint`. Should I do this at all usage sites? I'd end up factoring
into my own `ceildiv` for clarity, especially if I use this elsewhere, like
a test.

Where should this hand-rolled ceildiv live, if not recreated in everyone's
code? It seems too light to wrap as its own dependency, and we probably
don't want to go down the leftpad
<https://www.theregister.com/2016/03/23/npm_left_pad_chaos/> path. `math`
seems most apt.

On Sat, Feb 5, 2022 at 8:31 AM Mark Dickinson <report at bugs.python.org>
wrote:

>
> Mark Dickinson <dickinsm at gmail.com> added the comment:
>
> I'm not convinced that this deserves to be a math module function. I agree
> that `-(-x // y)`, while simple to write, isn't necessarily obvious. But it
> does have some advantages, like not needing an import, and being naturally
> duck-typed, so that it automatically does the right thing for floats, or
> `fractions.Fraction` objects, or `numpy.int64` objects, or SymPy integers.
> (Not for `Decimal` instances, but that's another story.) Unless we were to
> add a whole __ceildiv__ mechanism, a math module implementation would
> necessarily be limited to integers. (Or perhaps integers and floats.)
>
> There's also the "thin end of the wedge" argument: if ceildiv, why not
> also ceilrem, ceildivrem, rounddiv, roundmod, etc.
>
> The main issue with the `-(-x // y)` spelling seems to be discoverability:
> if everyone knew that this was the right way to spell ceiling division,
> then there wouldn't be a problem. And I'm not convinced that a math.ceildiv
> function would necessarily solve the discoverability problem, either.
>
> So maybe the solution is to advertise the `-(-x // y)` pattern better in
> documentation, for example at the point where floor division is introduced
> in the library reference?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue46639>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46639>
_______________________________________

From report at bugs.python.org  Sat Feb  5 12:43:13 2022
From: report at bugs.python.org (Gobot1234)
Date: Sat, 05 Feb 2022 17:43:13 +0000
Subject: [issue46644] typing: remove callable() check from typing._type_check
In-Reply-To: <1644015777.96.0.875814750019.issue46644@roundup.psfhosted.org>
Message-ID: <1644082993.97.0.754197607293.issue46644@roundup.psfhosted.org>


Gobot1234 <gobot1234yt at gmail.com> added the comment:

I also support this change. I've had to write a lot of code to make SpecialForms able to accept my types where the code has to look like:
```py
class Something:
    ...
    def __call__(self, *args, **kwargs):
       raise NotImplementedError
```
I also know this comes up in typing-extensions a fair bit. I think type checkers should be enforcing this at type-checking-time not by typing.py run-time.

----------
nosy: +Gobot1234

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46644>
_______________________________________

From report at bugs.python.org  Sat Feb  5 12:43:27 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Sat, 05 Feb 2022 17:43:27 +0000
Subject: [issue46644] typing: remove callable() check from typing._type_check
In-Reply-To: <1644015777.96.0.875814750019.issue46644@roundup.psfhosted.org>
Message-ID: <1644083007.88.0.949112238801.issue46644@roundup.psfhosted.org>


Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:

I agree with removing this check. I suspect it's a holdover from very early typing when static types were supposed to be runtime types. Now the check is a bug magnet and doesn't serve a useful purpose.

I think we can just remove the tests that check for ints. I don't see a principled reason to special-case int literals.

I wonder if we should apply this change to 3.10 and 3.9. It's arguably a bugfix, but it's a pretty big change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46644>
_______________________________________

From report at bugs.python.org  Sat Feb  5 12:57:15 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 05 Feb 2022 17:57:15 +0000
Subject: [issue46651] test_urllib2.test_issue16464() fails randomly
Message-ID: <1644083835.92.0.540199213669.issue46651@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

test_urllib2.test_issue16464() fails randomly.

It uses http://www.example.com/ server.

Instead, I proposed to use http://httpbin.org/post URL which is written to support HTTP POST.

$ ./python -m test test_urllib2 -u all -v -m test_issue16464
======================================================================
ERROR: test_issue16464 (test.test_urllib2.MiscTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/vstinner/python/main/Lib/contextlib.py", line 155, in __exit__
    self.gen.throw(typ, value, traceback)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/vstinner/python/main/Lib/test/support/socket_helper.py", line 245, in transient_internet
    yield
    ^^^^^
  File "/home/vstinner/python/main/Lib/test/test_urllib2.py", line 1799, in test_issue16464
    opener.open(request, "1".encode("us-ascii"))
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/vstinner/python/main/Lib/urllib/request.py", line 525, in open
    response = meth(req, response)
               ^^^^^^^^^^^^^^^^^^^
  File "/home/vstinner/python/main/Lib/urllib/request.py", line 634, in http_response
    response = self.parent.error(
               ^^^^^^^^^^^^^^^^^^
  File "/home/vstinner/python/main/Lib/urllib/request.py", line 563, in error
    return self._call_chain(*args)
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/vstinner/python/main/Lib/urllib/request.py", line 496, in _call_chain
    result = func(*args)
             ^^^^^^^^^^^
  File "/home/vstinner/python/main/Lib/urllib/request.py", line 643, in http_error_default
    raise HTTPError(req.full_url, code, msg, hdrs, fp)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
urllib.error.HTTPError: HTTP Error 404: Not Found

----------
components: Tests
messages: 412586
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_urllib2.test_issue16464() fails randomly
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46651>
_______________________________________

From report at bugs.python.org  Sat Feb  5 12:59:58 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 05 Feb 2022 17:59:58 +0000
Subject: [issue46651] test_urllib2.test_issue16464() fails randomly
In-Reply-To: <1644083835.92.0.540199213669.issue46651@roundup.psfhosted.org>
Message-ID: <1644083998.71.0.0922063226239.issue46651@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Oh, bpo-46648 was already opened.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> `test.test_urllib2.MiscTests.test_issue16464` started to fail

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46651>
_______________________________________

From report at bugs.python.org  Sat Feb  5 13:00:22 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 05 Feb 2022 18:00:22 +0000
Subject: [issue46648] `test.test_urllib2.MiscTests.test_issue16464` started to
 fail
In-Reply-To: <1644061533.84.0.594817920054.issue46648@roundup.psfhosted.org>
Message-ID: <1644084022.83.0.198217419402.issue46648@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I close my bpo-46651 as a duplicate of this issue. Copy of my message.

test_urllib2.test_issue16464() fails randomly.

It uses http://www.example.com/ server.

Instead, I proposed to use http://httpbin.org/post URL which is written to support HTTP POST.

$ ./python -m test test_urllib2 -u all -v -m test_issue16464
======================================================================
ERROR: test_issue16464 (test.test_urllib2.MiscTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/vstinner/python/main/Lib/contextlib.py", line 155, in __exit__
    self.gen.throw(typ, value, traceback)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/vstinner/python/main/Lib/test/support/socket_helper.py", line 245, in transient_internet
    yield
    ^^^^^
  File "/home/vstinner/python/main/Lib/test/test_urllib2.py", line 1799, in test_issue16464
    opener.open(request, "1".encode("us-ascii"))
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/vstinner/python/main/Lib/urllib/request.py", line 525, in open
    response = meth(req, response)
               ^^^^^^^^^^^^^^^^^^^
  File "/home/vstinner/python/main/Lib/urllib/request.py", line 634, in http_response
    response = self.parent.error(
               ^^^^^^^^^^^^^^^^^^
  File "/home/vstinner/python/main/Lib/urllib/request.py", line 563, in error
    return self._call_chain(*args)
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/vstinner/python/main/Lib/urllib/request.py", line 496, in _call_chain
    result = func(*args)
             ^^^^^^^^^^^
  File "/home/vstinner/python/main/Lib/urllib/request.py", line 643, in http_error_default
    raise HTTPError(req.full_url, code, msg, hdrs, fp)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
urllib.error.HTTPError: HTTP Error 404: Not Found

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46648>
_______________________________________

From report at bugs.python.org  Sat Feb  5 13:01:30 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 05 Feb 2022 18:01:30 +0000
Subject: [issue46648] `test.test_urllib2.MiscTests.test_issue16464` started to
 fail
In-Reply-To: <1644061533.84.0.594817920054.issue46648@roundup.psfhosted.org>
Message-ID: <1644084090.17.0.0827063741628.issue46648@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +29323
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31146

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46648>
_______________________________________

From report at bugs.python.org  Sat Feb  5 13:45:04 2022
From: report at bugs.python.org (Gregory Beauregard)
Date: Sat, 05 Feb 2022 18:45:04 +0000
Subject: [issue46642] typing: tested TypeVar instance subclass TypeError is
 incidental
In-Reply-To: <1644011961.17.0.0152846458354.issue46642@roundup.psfhosted.org>
Message-ID: <1644086704.31.0.748442195134.issue46642@roundup.psfhosted.org>


Gregory Beauregard <greg at greg.red> added the comment:

The reason this test passed before is a bit confusing. Run the following code standalone to see where the type(TypeVar('T'))(name, bases, namespace) check is coming from.
```
class TypeVar:
    def __init__(self, name, *constraints):
        # in actual TypeVar, each constraint is run through
        # typing._type_check, casuing TypeError via not callable() 
        print(repr(constraints))

class V(TypeVar("T")):
    pass
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46642>
_______________________________________

From report at bugs.python.org  Sat Feb  5 13:45:31 2022
From: report at bugs.python.org (Gregory Beauregard)
Date: Sat, 05 Feb 2022 18:45:31 +0000
Subject: [issue46642] typing: tested TypeVar instance subclass TypeError is
 incidental
In-Reply-To: <1644011961.17.0.0152846458354.issue46642@roundup.psfhosted.org>
Message-ID: <1644086731.96.0.0289411689385.issue46642@roundup.psfhosted.org>


Change by Gregory Beauregard <greg at greg.red>:


----------
keywords: +patch
pull_requests: +29324
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31148

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46642>
_______________________________________

From report at bugs.python.org  Sat Feb  5 13:52:40 2022
From: report at bugs.python.org (Tim Peters)
Date: Sat, 05 Feb 2022 18:52:40 +0000
Subject: [issue46639] Ceil division with math.ceildiv
In-Reply-To: <1644002723.68.0.838942257454.issue46639@roundup.psfhosted.org>
Message-ID: <1644087160.8.0.31887426329.issue46639@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

GMP's mpz has 18 functions of this form. These are the 6 "ceiling" flavors:

c_divmod
c_div
c_mod

c_divmod_2exp
c_div_2exp
c_mod_2exp

The suggestion here is for c_div.

There are 6 more for floor rounding (with prefix "f_" instead of "c_"), and another 6 for truncation ("to-zero" rounding, with prefix "t_"). Curiously enough, there's no direct support for any form of "round to nearest".

So that's where this ends ;-)

I personally almost never use -(-x // y). Because it's a bit obscure, and in real life y is always known to be positive, so the nearly obvious (x + y - 1) // y works fine.

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46639>
_______________________________________

From report at bugs.python.org  Sat Feb  5 13:53:11 2022
From: report at bugs.python.org (Gregory Beauregard)
Date: Sat, 05 Feb 2022 18:53:11 +0000
Subject: [issue46642] typing: tested TypeVar instance subclass TypeError is
 incidental
In-Reply-To: <1644011961.17.0.0152846458354.issue46642@roundup.psfhosted.org>
Message-ID: <1644087191.25.0.587884937578.issue46642@roundup.psfhosted.org>


Gregory Beauregard <greg at greg.red> added the comment:

Fixing this test unblocks bpo-46644

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46642>
_______________________________________

From report at bugs.python.org  Sat Feb  5 13:59:29 2022
From: report at bugs.python.org (Tim Peters)
Date: Sat, 05 Feb 2022 18:59:29 +0000
Subject: [issue46187] Optionally support rounding for math.isqrt()
In-Reply-To: <1640633399.46.0.8152811809.issue46187@roundup.psfhosted.org>
Message-ID: <1644087569.71.0.890606967689.issue46187@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

I've been keeping my eyes open. The only mariginally relevant thing I've noticed is Hart's "one line factoring" method:

http://wrap.warwick.ac.uk/54707/1/WRAP_Hart_S1446788712000146a.pdf

That wants the _ceiling_ of the square root. And in another place it wants to know "is it a perfect square?". But the part that wants the ceiling doesn't care whether it's a perfect square, while the part asking "is it a perfect square?" doesn't care what the ceiling may be.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46187>
_______________________________________

From report at bugs.python.org  Sat Feb  5 14:06:49 2022
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 05 Feb 2022 19:06:49 +0000
Subject: [issue46639] Ceil division with math.ceildiv
In-Reply-To: <1644002723.68.0.838942257454.issue46639@roundup.psfhosted.org>
Message-ID: <1644088009.13.0.226015371357.issue46639@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Tim]
> Because it's a bit obscure, and in real life y is always known to be positive, so the nearly obvious (x + y - 1) // y works fine.

Whereas I find (x + y - 1) // y less obvious at first sight than -(-x // y). :-) I don't care about negative y - that's not my reason for preferring -(-x // y). The preference comes from the fact that -(-x // y) still does the right thing for non-integral cases.

[Vladimir]
> Say we're making a controller for a game engine GUI and need to
figure out how to paint sprites. [...]

For this example, I'd probably just use `ceil(x / y)`. For "real world" things with x and y representing counts of something tangible (pixels, work items, row or column count of a matrix, lines of text, bytes of memory used, ...), you have to go quite a long way before `ceil(x / y)` gives you the wrong answer due to floating-point errors. E.g. if you know the quotient is no larger than 10**6, you're safe for all y <= 10**10. (Or vice versa: if you know the quotient is at most 10**10, then you're safe for y <= 10**6.)

> not __ceildiv__ [...]

It would be a little odd (but only a little) to have __floor__, __ceil__, and __floordiv__ overloads, but not __ceildiv__. It probably wouldn't be long before someone requested it.

I'll quieten down now and wait to see what other people think.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46639>
_______________________________________

From report at bugs.python.org  Sat Feb  5 14:07:06 2022
From: report at bugs.python.org (Gregory Beauregard)
Date: Sat, 05 Feb 2022 19:07:06 +0000
Subject: [issue46648] `test.test_urllib2.MiscTests.test_issue16464` started to
 fail
In-Reply-To: <1644061533.84.0.594817920054.issue46648@roundup.psfhosted.org>
Message-ID: <1644088026.6.0.574584257083.issue46648@roundup.psfhosted.org>


Change by Gregory Beauregard <greg at greg.red>:


----------
nosy: +GBeauregard
nosy_count: 2.0 -> 3.0
pull_requests: +29325
pull_request: https://github.com/python/cpython/pull/31148

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46648>
_______________________________________

From report at bugs.python.org  Sat Feb  5 14:28:11 2022
From: report at bugs.python.org (Tim Peters)
Date: Sat, 05 Feb 2022 19:28:11 +0000
Subject: [issue46639] Ceil division with math.ceildiv
In-Reply-To: <1644002723.68.0.838942257454.issue46639@roundup.psfhosted.org>
Message-ID: <1644089291.01.0.734330305673.issue46639@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

I expect "obviousness" is mostly driven by background here. You know, e.g., that ceil(x) = -floor(-x) for any real x, and the application to integer division is just a special case of that. I expect programmers mostly don't know that, though. And Python having floor integer division is unusual among programming languages. Everyone coming from, say, C, has seen the (i + j - 1)/j "idiom" over and over, where "the usual" truncating integer division is the rule (and they know too that `i` and `j` are positive). Familiarity breeds "obviousness" too :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46639>
_______________________________________

From report at bugs.python.org  Sat Feb  5 14:52:28 2022
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 05 Feb 2022 19:52:28 +0000
Subject: [issue40280] Consider supporting emscripten/webassembly as a build
 target
In-Reply-To: <1586848295.92.0.690921486188.issue40280@roundup.psfhosted.org>
Message-ID: <1644090748.79.0.591554793053.issue40280@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset 96b344c2f15cb09251018f57f19643fe20637392 by Christian Heimes in branch 'main':
bpo-40280: Address more test failures on Emscripten (GH-31050)
https://github.com/python/cpython/commit/96b344c2f15cb09251018f57f19643fe20637392


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40280>
_______________________________________

From report at bugs.python.org  Sat Feb  5 15:25:05 2022
From: report at bugs.python.org (Jacob Walls)
Date: Sat, 05 Feb 2022 20:25:05 +0000
Subject: [issue38941] xml.etree.ElementTree.Element inconsistent warning for
 bool
In-Reply-To: <1575033665.72.0.950765215131.issue38941@roundup.psfhosted.org>
Message-ID: <1644092705.86.0.285258764326.issue38941@roundup.psfhosted.org>


Change by Jacob Walls <jacobtylerwalls at gmail.com>:


----------
keywords: +patch
nosy: +jacobtylerwalls
nosy_count: 6.0 -> 7.0
pull_requests: +29326
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31149

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38941>
_______________________________________

From report at bugs.python.org  Sat Feb  5 15:41:49 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 05 Feb 2022 20:41:49 +0000
Subject: [issue38941] xml.etree.ElementTree.Element inconsistent warning for
 bool
In-Reply-To: <1575033665.72.0.950765215131.issue38941@roundup.psfhosted.org>
Message-ID: <1644093709.9.0.713895347827.issue38941@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/issue38941>
_______________________________________

From report at bugs.python.org  Sat Feb  5 15:43:28 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 05 Feb 2022 20:43:28 +0000
Subject: [issue46642] typing: tested TypeVar instance subclass TypeError is
 incidental
In-Reply-To: <1644011961.17.0.0152846458354.issue46642@roundup.psfhosted.org>
Message-ID: <1644093808.67.0.0501347953323.issue46642@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/issue46642>
_______________________________________

From report at bugs.python.org  Sat Feb  5 15:59:57 2022
From: report at bugs.python.org (Gregory Beauregard)
Date: Sat, 05 Feb 2022 20:59:57 +0000
Subject: [issue46644] typing: remove callable() check from typing._type_check
In-Reply-To: <1644015777.96.0.875814750019.issue46644@roundup.psfhosted.org>
Message-ID: <1644094797.07.0.846449398936.issue46644@roundup.psfhosted.org>


Gregory Beauregard <greg at greg.red> added the comment:

Under the same failing int test cases before there were 2 more cases next to them that fail:

with self.assertRaises(TypeError):
    ClassVar[int, str]
with self.assertRaises(TypeError):
    Final[int, str]

These fail because tuple literals are not callable(). There is code that clearly intends for this to be the case: https://github.com/python/cpython/blob/96b344c2f15cb09251018f57f19643fe20637392/Lib/typing.py#L486

I can either remove support for this runtime check or change the implementation of Final et al to reject tuple literals. I will do the latter for now.

For https://github.com/python/cpython/blob/bf95ff91f2c1fc5a57190491f9ccdc63458b089e/Lib/test/test_typing.py#L4262-L4263 I think the best approach is to just remove these tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46644>
_______________________________________

From report at bugs.python.org  Sat Feb  5 16:23:10 2022
From: report at bugs.python.org (Gregory Beauregard)
Date: Sat, 05 Feb 2022 21:23:10 +0000
Subject: [issue46644] typing: remove callable() check from typing._type_check
In-Reply-To: <1644015777.96.0.875814750019.issue46644@roundup.psfhosted.org>
Message-ID: <1644096190.3.0.205950127179.issue46644@roundup.psfhosted.org>


Gregory Beauregard <greg at greg.red> added the comment:

Further questions: the msg argument in _type_check now wouldn't be used for anything! It was only used in the case where a type wasn't callable(). I think it should be removed. I'm also a bit negative on disallowing tuples in the case of e.g. Final and such since it complicates implementing tuple types in Python down the line if desired.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46644>
_______________________________________

From report at bugs.python.org  Sat Feb  5 16:25:55 2022
From: report at bugs.python.org (Gabriele N Tornetta)
Date: Sat, 05 Feb 2022 21:25:55 +0000
Subject: [issue46652] Use code.co_qualname to provide richer information
Message-ID: <1644096355.01.0.0724658726819.issue46652@roundup.psfhosted.org>


New submission from Gabriele N Tornetta <phoenix1987 at gmail.com>:

https://bugs.python.org/issue44530 introduced the co_qualname field to code objects. This could be used to, e.g. enrich the information provided by tracebacks. Consider this simple example

~~~ python
import traceback


class Bogus:
    def __init__(self):
        traceback.print_stack()
        raise RuntimeError("Oh no!")


class Foo:
    def __init__(self):
        Bogus()


Foo()
~~~

The current output is

~~~
? python3.10 test_tb_format.py                                                                                       
  File "/home/gabriele/Projects/cpython/test_tb_format.py", line 15, in <module>
    Foo()
  File "/home/gabriele/Projects/cpython/test_tb_format.py", line 12, in __init__
    Bogus()
  File "/home/gabriele/Projects/cpython/test_tb_format.py", line 6, in __init__
    traceback.print_stack()
Traceback (most recent call last):
  File "/home/gabriele/Projects/cpython/test_tb_format.py", line 15, in <module>
    Foo()
  File "/home/gabriele/Projects/cpython/test_tb_format.py", line 12, in __init__
    Bogus()
  File "/home/gabriele/Projects/cpython/test_tb_format.py", line 7, in __init__
    raise RuntimeError("Oh no!")
RuntimeError: Oh no!
~~~

The proposed change is to use the co_qualname field instead of co_name to provide more immediate information about the distinct functions __init__, viz.

~~~
? ./python test_tb_format.py   
  File "/home/gabriele/Projects/cpython/test_tb_format.py", line 15, in <module>
    Foo()
  File "/home/gabriele/Projects/cpython/test_tb_format.py", line 12, in Foo.__init__
    Bogus()
  File "/home/gabriele/Projects/cpython/test_tb_format.py", line 6, in Bogus.__init__
    traceback.print_stack()
Traceback (most recent call last):
  File "/home/gabriele/Projects/cpython/test_tb_format.py", line 15, in <module>
    Foo()
    ^^^^^
  File "/home/gabriele/Projects/cpython/test_tb_format.py", line 12, in Foo.__init__
    Bogus()
    ^^^^^^^
  File "/home/gabriele/Projects/cpython/test_tb_format.py", line 7, in Bogus.__init__
    raise RuntimeError("Oh no!")
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
RuntimeError: Oh no!
~~~

This makes it clear that two distinct __init__ functions are involved, without having to look at sources.

----------
components: Interpreter Core
messages: 412598
nosy: Gabriele Tornetta, pablogsal
priority: normal
severity: normal
status: open
title: Use code.co_qualname to provide richer information
type: enhancement
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46652>
_______________________________________

From report at bugs.python.org  Sat Feb  5 16:30:44 2022
From: report at bugs.python.org (Gabriele N Tornetta)
Date: Sat, 05 Feb 2022 21:30:44 +0000
Subject: [issue46652] Use code.co_qualname to provide richer information
In-Reply-To: <1644096355.01.0.0724658726819.issue46652@roundup.psfhosted.org>
Message-ID: <1644096644.3.0.00463132236866.issue46652@roundup.psfhosted.org>


Change by Gabriele N Tornetta <phoenix1987 at gmail.com>:


----------
keywords: +patch
pull_requests: +29327
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31150

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46652>
_______________________________________

From report at bugs.python.org  Sat Feb  5 17:08:08 2022
From: report at bugs.python.org (Gregory Beauregard)
Date: Sat, 05 Feb 2022 22:08:08 +0000
Subject: [issue46644] typing: remove callable() check from typing._type_check
In-Reply-To: <1644015777.96.0.875814750019.issue46644@roundup.psfhosted.org>
Message-ID: <1644098888.85.0.580445615488.issue46644@roundup.psfhosted.org>


Gregory Beauregard <greg at greg.red> added the comment:

I made a draft pull request where I went ahead and added a check to disallow tuple literals. This is basically already disallowed for types by restrictions on `__getitem__` because Union[typeform]->type needs to be different from Union[type,type]->Union[type,type].

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46644>
_______________________________________

From report at bugs.python.org  Sat Feb  5 17:20:45 2022
From: report at bugs.python.org (Mike Auty)
Date: Sat, 05 Feb 2022 22:20:45 +0000
Subject: [issue32442] file_open unc
In-Reply-To: <1514488197.55.0.213398074469.issue32442@psf.upfronthosting.co.za>
Message-ID: <1644099645.8.0.173950139018.issue32442@roundup.psfhosted.org>


Change by Mike Auty <mike.auty at gmail.com>:


----------
title: Result of pathlib.Path.resolve() with UNC path is not very useful -> file_open unc

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32442>
_______________________________________

From report at bugs.python.org  Sat Feb  5 17:20:58 2022
From: report at bugs.python.org (Josselin Poiret)
Date: Sat, 05 Feb 2022 22:20:58 +0000
Subject: [issue46653] sys.path entries normalization in site.py doesn't follow
 POSIX symlink behaviour
Message-ID: <1644099658.9.0.961977779463.issue46653@roundup.psfhosted.org>


New submission from Josselin Poiret <dev at jpoiret.xyz>:

Whenever sys.prefix contains a symlink followed by a '..', the corresponding part of sys.path entries will not refer to the parent directory of the directory pointed to by the symlink, but rather to the directory in which the symlink is. Thus, it will be impossible to import standard Python modules installed at sys.prefix, among other things.

Here is an example:
Suppose you have installed Python with prefix /usr. Create a symlink /tmp/symlink pointing to /usr/lib, and launch `PYTHONHOME=/tmp/symlink/.. python3`. In that REPL, `import warnings` will fail to find the correct module, as evidenced by the value of `sys.path` containing entries such as `/tmp/lib/python3.X/` instead of the expected `/usr/lib/python3.X/`.

This issue is caused by the makepath function (among others) in Lib/site.py using os.path.abspath instead of os.path.realpath, which does not follow POSIX as the documentation of os.path.normpath (used internally by abspath) suggests.

I propose replacing all four instances of abspath in Lib/site.py to realpath instead. This is a breaking change for users that relied on non-conforming symlink semantics (although that user-base might be quite small), but in my opinion Python should be expected to follow the behaviour of the platform it is running on.

This issue was raised while investigating a bug [1] in the relocatable packs feature of GNU Guix [2], which makes use of symlinks to achieve relocatability.

[1] https://issues.guix.gnu.org/53258
[2] https://guix.gnu.org/en/blog/2018/tarballs-the-ultimate-container-image-format/

----------
components: Library (Lib)
messages: 412600
nosy: jpoiret
priority: normal
severity: normal
status: open
title: sys.path entries normalization in site.py doesn't follow POSIX symlink behaviour
type: behavior
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46653>
_______________________________________

From report at bugs.python.org  Sat Feb  5 17:21:46 2022
From: report at bugs.python.org (Mike Auty)
Date: Sat, 05 Feb 2022 22:21:46 +0000
Subject: [issue32442] Result of pathlib Path.resolve() with UNC path is not
 very useful
In-Reply-To: <1514488197.55.0.213398074469.issue32442@psf.upfronthosting.co.za>
Message-ID: <1644099706.5.0.868673946833.issue32442@roundup.psfhosted.org>


Mike Auty <mike.auty at gmail.com> added the comment:

Sorry for the spam, thought I was in a different text box.  5:(

----------
nosy: +ikelos
title: file_open unc -> Result of pathlib Path.resolve() with UNC path is not very useful

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32442>
_______________________________________

From report at bugs.python.org  Sat Feb  5 17:27:29 2022
From: report at bugs.python.org (Gregory Beauregard)
Date: Sat, 05 Feb 2022 22:27:29 +0000
Subject: [issue46644] typing: remove callable() check from typing._type_check
In-Reply-To: <1644015777.96.0.875814750019.issue46644@roundup.psfhosted.org>
Message-ID: <1644100049.07.0.505208908314.issue46644@roundup.psfhosted.org>


Change by Gregory Beauregard <greg at greg.red>:


----------
keywords: +patch
pull_requests: +29328
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31151

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46644>
_______________________________________

From report at bugs.python.org  Sat Feb  5 17:27:39 2022
From: report at bugs.python.org (Mike Auty)
Date: Sat, 05 Feb 2022 22:27:39 +0000
Subject: [issue46654] file_open doesn't handle UNC paths produced by pathlib's
 resolve() (but can handle UNC paths with additional slashes)
Message-ID: <1644100059.97.0.383989396746.issue46654@roundup.psfhosted.org>


New submission from Mike Auty <mike.auty at gmail.com>:

I've found open to have difficulty with a resolved pathlib path:

Example code of:

   import pathlib
   path = "Z:\\test.py"
   with open(path) as fp:
       print("Stock open: works")
       data = fp.read()
   with open(pathlib.Path(path).resolve().as_uri()) as fp:
       print("Pathlib resolve open")
       data = fp.read()

Results in:

Z:\> python test.py
Stock open: works
Traceback (most recent call last):
  File "Z:\test.py", line 12, in <module>
    with open(pathlib.Path(path).resolve().as_uri()) as fp:
FileNotFoundError: [Errno 2] No such file or directory: "file://machine/share/test.py"

Interestingly, I've found that open("file:////machine/share/test.py") succeeds, but this isn't what pathlib's resolve() produces.  It appears as though file_open only supports hosts that are local, but will open UNC paths on windows with the additional slashes.  This is quite confusing behaviour and it's not clear why file://host/share/file won't work, but file:////host/share/file does.

I imagine this is a long time issue and a decision has already been reached on why file_open doesn't support such URIs, but I couldn't find the answer anywhere, just issue 32442 which was resolved without clarifying the situation...

----------
messages: 412602
nosy: ikelos
priority: normal
severity: normal
status: open
title: file_open doesn't handle UNC paths produced by pathlib's resolve() (but can handle UNC paths with additional slashes)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46654>
_______________________________________

From report at bugs.python.org  Sat Feb  5 18:07:17 2022
From: report at bugs.python.org (Barney Gale)
Date: Sat, 05 Feb 2022 23:07:17 +0000
Subject: [issue46654] file_open doesn't handle UNC paths produced by pathlib's
 resolve() (but can handle UNC paths with additional slashes)
In-Reply-To: <1644100059.97.0.383989396746.issue46654@roundup.psfhosted.org>
Message-ID: <1644102437.66.0.487548395023.issue46654@roundup.psfhosted.org>


Barney Gale <barney.gale at gmail.com> added the comment:

Why are you adding `.as_uri()`?

----------
nosy: +barneygale

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46654>
_______________________________________

From report at bugs.python.org  Sat Feb  5 18:20:21 2022
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 05 Feb 2022 23:20:21 +0000
Subject: [issue46654] file_open doesn't handle UNC paths produced by pathlib's
 resolve() (but can handle UNC paths with additional slashes)
In-Reply-To: <1644100059.97.0.383989396746.issue46654@roundup.psfhosted.org>
Message-ID: <1644103221.85.0.509713169412.issue46654@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

Builtin open() calls C open(). This C function supports whatever path types are supported natively. In Windows, C open() calls WinAPI CreateFileW(), which does not support "file://" URIs. The Windows API handles it as a relative path, which gets resolved against the current working directory. For example:

    >>> os.getcwd()
    'C:\\Temp'
    >>> nt._getfullpathname('file:////host/share/file')
    'C:\\Temp\\file:\\host\\share\\file'
    >>> nt._getfullpathname('file://host/share/file')
    'C:\\Temp\\file:\\host\\share\\file'

As to the resolved path somehow working, that generally will not be the case. Most filesystems in Windows will reject a path component named "file:" as an invalid name. The ":" character is usually disallowed in base file and directory names, since some Windows filesystems use it as a delimiter in file streams, e.g. "name:stream_name:stream_type". The default data stream in a regular file has no stream name, and its stream type is "$DATA". Thus for base name "file", the default data stream can be referenced explicitly as "file::$DATA". But just "file:", with neither a stream name nor a stream type, is an invalid name.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46654>
_______________________________________

From report at bugs.python.org  Sat Feb  5 18:32:56 2022
From: report at bugs.python.org (Mike Auty)
Date: Sat, 05 Feb 2022 23:32:56 +0000
Subject: [issue46654] file_open doesn't handle UNC paths produced by pathlib's
 resolve() (but can handle UNC paths with additional slashes)
In-Reply-To: <1644100059.97.0.383989396746.issue46654@roundup.psfhosted.org>
Message-ID: <1644103976.22.0.699686735662.issue46654@roundup.psfhosted.org>


Mike Auty <mike.auty at gmail.com> added the comment:

> Why are you adding `.as_uri()`?

The API we provide accepts URIs, so whilst the example seems a little contrived, the code itself expects a URI and then calls open (making use of the ability to add open handlers).

> Builtin open() calls C open().

As best I can tell the file handler is defined in urllib/request.py as file_open.  This appears to do some preprocessing to remove the file scheme and (and explicitly throws an exception if there's a host that isn't localhost) before it gets to the C open().  I wondered why it didn't check if it was on windows and, if so, construct an appropriate path (since quadruple hash I don't think adheres to the URI RFC, but seems to open correctly)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46654>
_______________________________________

From report at bugs.python.org  Sat Feb  5 18:34:51 2022
From: report at bugs.python.org (Mike Auty)
Date: Sat, 05 Feb 2022 23:34:51 +0000
Subject: [issue46654] file_open doesn't handle UNC paths produced by pathlib's
 resolve() (but can handle UNC paths with additional slashes)
In-Reply-To: <1644100059.97.0.383989396746.issue46654@roundup.psfhosted.org>
Message-ID: <1644104091.13.0.396392020802.issue46654@roundup.psfhosted.org>


Mike Auty <mike.auty at gmail.com> added the comment:

My bad, sorry, I realized I was conflating open with urllib.request.urlopen.  I believe the issue still exists though, sorry for the confusion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46654>
_______________________________________

From report at bugs.python.org  Sat Feb  5 18:45:49 2022
From: report at bugs.python.org (Mike Auty)
Date: Sat, 05 Feb 2022 23:45:49 +0000
Subject: [issue46654] file_open doesn't handle UNC paths produced by pathlib's
 resolve() (but can handle UNC paths with additional slashes)
In-Reply-To: <1644100059.97.0.383989396746.issue46654@roundup.psfhosted.org>
Message-ID: <1644104749.46.0.706902225817.issue46654@roundup.psfhosted.org>


Mike Auty <mike.auty at gmail.com> added the comment:

Here's the revised code sample:

    import pathlib
    import urllib.request
    
    path = "Z:\\test.py"
    
    print(f"Stock open: {pathlib.Path(path).as_uri()}")
    with urllib.request.urlopen(pathlib.Path(path).as_uri()) as fp:
        data = fp.read()
    
    print(f"Pathlib resolved open: {pathlib.Path(path).resolve().as_uri()}")
    with urllib.request.urlopen(pathlib.Path(path).resolve().as_uri()) as fp:
        data = fp.read()

and here's the output:

    Z:\> python test.py
    Stock open: file:///Z:/test.py
    Pathlib resolved open: file://host/share/test.py
    Traceback (most recent call last):
    File "C:\Program Files\Python310\lib\urllib\request.py", line 1505, in open_local_file
        stats = os.stat(localfile)
    FileNotFoundError: [WinError 2] The system cannot find the file specified: '\\share\\test.py'

    During handling of the above exception, another exception occurred:

    Traceback (most recent call last):
    File "Z:\test.py", line 14, in <module>
        with urllib.request.urlopen(pathlib.Path(path).resolve().as_uri()) as fp:
    File "C:\Program Files\Python310\lib\urllib\request.py", line 216, in urlopen
        return opener.open(url, data, timeout)
    File "C:\Program Files\Python310\lib\urllib\request.py", line 519, in open
        response = self._open(req, data)
    File "C:\Program Files\Python310\lib\urllib\request.py", line 536, in _open
        result = self._call_chain(self.handle_open, protocol, protocol +
    File "C:\Program Files\Python310\lib\urllib\request.py", line 496, in _call_chain
        result = func(*args)
    File "C:\Program Files\Python310\lib\urllib\request.py", line 1483, in file_open
        return self.open_local_file(req)
    File "C:\Program Files\Python310\lib\urllib\request.py", line 1522, in open_local_file
        raise URLError(exp)
    urllib.error.URLError: <urlopen error [WinError 2] The system cannot find the file specified: '\\share\\test.py'>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46654>
_______________________________________

From report at bugs.python.org  Sat Feb  5 19:01:02 2022
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 06 Feb 2022 00:01:02 +0000
Subject: [issue46654] file_open doesn't handle UNC paths produced by pathlib's
 resolve() (but can handle UNC paths with additional slashes)
In-Reply-To: <1644100059.97.0.383989396746.issue46654@roundup.psfhosted.org>
Message-ID: <1644105662.77.0.951070797768.issue46654@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
Removed message: https://bugs.python.org/msg412604

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46654>
_______________________________________

From report at bugs.python.org  Sat Feb  5 19:10:12 2022
From: report at bugs.python.org (Barney Gale)
Date: Sun, 06 Feb 2022 00:10:12 +0000
Subject: [issue46654] file_open doesn't handle UNC paths produced by pathlib's
 resolve() (but can handle UNC paths with additional slashes)
In-Reply-To: <1644100059.97.0.383989396746.issue46654@roundup.psfhosted.org>
Message-ID: <1644106212.29.0.0224613504267.issue46654@roundup.psfhosted.org>


Barney Gale <barney.gale at gmail.com> added the comment:

urllib uses nturl2path under the hood. On my system it seems to return reasonable results for both two and four leading slashes:

    >>> nturl2path.url2pathname('////host/share/test.py')
    '\\\\host\\share\\test.py'
    >>> nturl2path.url2pathname('//host/share/test.py')
    '\\\\host\\share\\test.py'

(note that urllib strips the `file:` prefix before calling this function).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46654>
_______________________________________

From report at bugs.python.org  Sat Feb  5 19:31:43 2022
From: report at bugs.python.org (Jacob Walls)
Date: Sun, 06 Feb 2022 00:31:43 +0000
Subject: [issue45948] Unexpected instantiation behavior for
 xml.etree.ElementTree.XMLParser(target=None)
In-Reply-To: <1638367672.95.0.357017255599.issue45948@roundup.psfhosted.org>
Message-ID: <1644107503.16.0.16927734485.issue45948@roundup.psfhosted.org>


Change by Jacob Walls <jacobtylerwalls at gmail.com>:


----------
keywords: +patch
nosy: +jacobtylerwalls
nosy_count: 1.0 -> 2.0
pull_requests: +29329
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31152

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45948>
_______________________________________

From report at bugs.python.org  Sat Feb  5 20:14:13 2022
From: report at bugs.python.org (Andre Roberge)
Date: Sun, 06 Feb 2022 01:14:13 +0000
Subject: [issue46652] Use code.co_qualname to provide richer information
In-Reply-To: <1644096355.01.0.0724658726819.issue46652@roundup.psfhosted.org>
Message-ID: <1644110053.29.0.0212315512499.issue46652@roundup.psfhosted.org>


Change by Andre Roberge <andre.roberge at gmail.com>:


----------
nosy: +aroberge

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46652>
_______________________________________

From report at bugs.python.org  Sat Feb  5 20:31:58 2022
From: report at bugs.python.org (Mike Auty)
Date: Sun, 06 Feb 2022 01:31:58 +0000
Subject: [issue46654] file_open doesn't handle UNC paths produced by pathlib's
 resolve() (but can handle UNC paths with additional slashes)
In-Reply-To: <1644100059.97.0.383989396746.issue46654@roundup.psfhosted.org>
Message-ID: <1644111118.22.0.42501864219.issue46654@roundup.psfhosted.org>


Mike Auty <mike.auty at gmail.com> added the comment:

I can confirm that url2pathname work with either number of slashes, and that open_file appears to have had the file: removed.

However, in even if the check in open_file were bypassed, it calls open_local_file, which then strips any host before calling url2pathname, meaning the host will never be included if only two slashes are used.

        host, file = _splithost(url)
        localname = url2pathname(file)

This is what seems to cause the issue when attempting to open file://server/host/file.ext on windows, even though file:////server/host/file.ext open just fine.

The problem that I found, and was in bug #32442, is that pathlib only ever returns two slashes, which despite being a valid and correctly formed url, can't be opened by urllib.request.urlopen().  Since there doesn't seem to be an issue with opening these files (given it works for file:////server...) and since nt2pathname will produce the correct result, it feels as though open_file should have special code on windows to allow servers to be accepted by the file handler (open_local_file should probably stay as is to not change the API too much).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46654>
_______________________________________

From report at bugs.python.org  Sat Feb  5 20:33:53 2022
From: report at bugs.python.org (Mike Auty)
Date: Sun, 06 Feb 2022 01:33:53 +0000
Subject: [issue46654] urllib.request.urlopen doesn't handle UNC paths produced
 by pathlib's resolve() (but can handle UNC paths with additional
 slashes)
In-Reply-To: <1644100059.97.0.383989396746.issue46654@roundup.psfhosted.org>
Message-ID: <1644111233.16.0.150776963089.issue46654@roundup.psfhosted.org>


Change by Mike Auty <mike.auty at gmail.com>:


----------
title: file_open doesn't handle UNC paths produced by pathlib's resolve() (but can handle UNC paths with additional slashes) -> urllib.request.urlopen doesn't handle UNC paths produced by pathlib's resolve() (but can handle UNC paths with additional slashes)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46654>
_______________________________________

From report at bugs.python.org  Sat Feb  5 20:45:25 2022
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 06 Feb 2022 01:45:25 +0000
Subject: [issue46654] urllib.request.urlopen doesn't handle UNC paths produced
 by pathlib's resolve() (but can handle UNC paths with additional
 slashes)
In-Reply-To: <1644100059.97.0.383989396746.issue46654@roundup.psfhosted.org>
Message-ID: <1644111925.95.0.727891586659.issue46654@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

In FileHandler.file_open(), req.host is the host name, which is either None or an empty string for a local drive path such as, respectively, "file:/Z:/test.py" or "file:///Z:/test.py". The value of req.selector never starts with "//", for which file_open() checks, but rather a single slash, such as "/Z:/test.py" or "/share/test.py". This is a bug in file_open(). Due to this bug, it always calls self.open_local_file(req), even if req.host isn't local. The distinction shouldn't matter in Windows, which supports UNC paths, but POSIX has to open a path on the local machine (possibly a mount point for a remote path, but that's irrelevant). In POSIX, if the local machine coincidentally has the req.selector path, then the os.stat() and open() calls will succeed with a bogus result.

For "file://host/share/test.py", req.selector is "/share/test.py". In Windows, url2pathname() converts this to r"\share\test.py", which is relative to the drive of the process current working directory. This is a bug in open_local_file() on Windows. For it to work correctly, req.host has to be joined back with req.selector as the UNC path "//host/share/test.py". Of course, this need not be a local file in Windows, so Windows should be exempted from the local file limitation in file_open().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46654>
_______________________________________

From report at bugs.python.org  Sat Feb  5 21:11:22 2022
From: report at bugs.python.org (Keelung Yang)
Date: Sun, 06 Feb 2022 02:11:22 +0000
Subject: [issue46554] Add append keyword argument to Path.write_text() and
 Path.write_bytes()
In-Reply-To: <1643318458.5.0.470070571625.issue46554@roundup.psfhosted.org>
Message-ID: <1644113482.66.0.607116101694.issue46554@roundup.psfhosted.org>


Keelung Yang <keelung.yang at flex.com> added the comment:

OK. Since most are opposed to append kwarg, I close this issue.
Thanks ALL!

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46554>
_______________________________________

From report at bugs.python.org  Sat Feb  5 21:42:03 2022
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 06 Feb 2022 02:42:03 +0000
Subject: [issue46654] urllib.request.urlopen doesn't handle UNC paths produced
 by pathlib's resolve() (but can handle UNC paths with additional
 slashes)
In-Reply-To: <1644100059.97.0.383989396746.issue46654@roundup.psfhosted.org>
Message-ID: <1644115323.86.0.484123455784.issue46654@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> file://server/host/file.ext on windows, even though 
> file:////server/host/file.ext open just fine.

For r"\\host\share\test.py", the two slash conversion "file://host/share/test.py" is correct according to RFC80889 "E.3.1. <file> URI with Authority" [1]. In this case, req.host is "host", and req.selector is "/share/test.py". 

The four slash version "file:////host/share/test.py" is a known variant for a converted UNC path, as noted in RFC8089 "E.3.2. <file> URI with UNC Path". In this case, req.host is an empty string, and req.selector is "//host/share/test.py". There's another variant that uses 5 slashes for a UNC path, but urllib (or url2pathname) doesn't support it.

---
[1] https://datatracker.ietf.org/doc/html/rfc8089

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46654>
_______________________________________

From report at bugs.python.org  Sat Feb  5 21:47:25 2022
From: report at bugs.python.org (Barney Gale)
Date: Sun, 06 Feb 2022 02:47:25 +0000
Subject: [issue46654] urllib.request.urlopen doesn't handle UNC paths produced
 by pathlib's resolve() (but can handle UNC paths with additional
 slashes)
In-Reply-To: <1644100059.97.0.383989396746.issue46654@roundup.psfhosted.org>
Message-ID: <1644115645.49.0.906767869518.issue46654@roundup.psfhosted.org>


Barney Gale <barney.gale at gmail.com> added the comment:

Agree with the previous analysis. Just noting that:

    >>> nturl2path.pathname2url('\\\\host\\share\\test.py')
    '////host/share/test.py'

So four slashes are produced by the urllib code, whereas pathlib only produces two.

According to wikipedia, both the two- and four-slash variants are in active usage. As we can see within Python itself! :P

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46654>
_______________________________________

From report at bugs.python.org  Sat Feb  5 21:49:03 2022
From: report at bugs.python.org (Barney Gale)
Date: Sun, 06 Feb 2022 02:49:03 +0000
Subject: [issue46654] urllib.request.urlopen doesn't handle UNC paths produced
 by pathlib's as_uri() (but can handle UNC paths with additional
 slashes)
In-Reply-To: <1644100059.97.0.383989396746.issue46654@roundup.psfhosted.org>
Message-ID: <1644115743.37.0.592962780412.issue46654@roundup.psfhosted.org>


Change by Barney Gale <barney.gale at gmail.com>:


----------
title: urllib.request.urlopen doesn't handle UNC paths produced by pathlib's resolve() (but can handle UNC paths with additional slashes) -> urllib.request.urlopen doesn't handle UNC paths produced by pathlib's as_uri() (but can handle UNC paths with additional slashes)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46654>
_______________________________________

From report at bugs.python.org  Sat Feb  5 22:17:34 2022
From: report at bugs.python.org (Zackery Spytz)
Date: Sun, 06 Feb 2022 03:17:34 +0000
Subject: [issue40479] Port _hashlib to OpenSSL 3.0.0
In-Reply-To: <1588497803.18.0.937746880221.issue40479@roundup.psfhosted.org>
Message-ID: <1644117454.33.0.27650840034.issue40479@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
nosy: +ZackerySpytz
nosy_count: 3.0 -> 4.0
pull_requests: +29330
pull_request: https://github.com/python/cpython/pull/31153

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40479>
_______________________________________

From report at bugs.python.org  Sat Feb  5 22:22:19 2022
From: report at bugs.python.org (Zackery Spytz)
Date: Sun, 06 Feb 2022 03:22:19 +0000
Subject: [issue40479] Port _hashlib to OpenSSL 3.0.0
In-Reply-To: <1588497803.18.0.937746880221.issue40479@roundup.psfhosted.org>
Message-ID: <1644117739.75.0.288464006823.issue40479@roundup.psfhosted.org>


Zackery Spytz <zspytz at gmail.com> added the comment:

There is a missing call to va_end() in 443b308fee088e21bbf472c376c5c9e3648f916c (which is undefined behavior).  PR 31153 fixes this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40479>
_______________________________________

From report at bugs.python.org  Sat Feb  5 22:44:07 2022
From: report at bugs.python.org (Jacob Walls)
Date: Sun, 06 Feb 2022 03:44:07 +0000
Subject: [issue34191] argparse: Missing subparser error message should be more
 clear
In-Reply-To: <1532289510.54.0.56676864532.issue34191@psf.upfronthosting.co.za>
Message-ID: <1644119047.14.0.602696404122.issue34191@roundup.psfhosted.org>


Jacob Walls <jacobtylerwalls at gmail.com> added the comment:

Duplicate of issue29298 (fixed)

----------
nosy: +jacobtylerwalls

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34191>
_______________________________________

From report at bugs.python.org  Sat Feb  5 22:58:59 2022
From: report at bugs.python.org (Dennis Sweeney)
Date: Sun, 06 Feb 2022 03:58:59 +0000
Subject: [issue46652] Use code.co_qualname to provide richer information
In-Reply-To: <1644096355.01.0.0724658726819.issue46652@roundup.psfhosted.org>
Message-ID: <1644119939.55.0.941973601332.issue46652@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

Similar changes at bpo-40679 accidentally broke Cython when it was assumed that co_qualname was non-null, which was then fixed by defaulting to co_name in that case. I don't know if Cython still produces cases like that, but we should make sure not to needlessly break such cases if it does.

----------
nosy: +Dennis Sweeney

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46652>
_______________________________________

From report at bugs.python.org  Sun Feb  6 00:05:16 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 06 Feb 2022 05:05:16 +0000
Subject: [issue46648] `test.test_urllib2.MiscTests.test_issue16464` started to
 fail
In-Reply-To: <1644061533.84.0.594817920054.issue46648@roundup.psfhosted.org>
Message-ID: <1644123916.23.0.335282362942.issue46648@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/issue46648>
_______________________________________

From report at bugs.python.org  Sun Feb  6 00:05:39 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 06 Feb 2022 05:05:39 +0000
Subject: [issue46648] `test.test_urllib2.MiscTests.test_issue16464` started to
 fail
In-Reply-To: <1644061533.84.0.594817920054.issue46648@roundup.psfhosted.org>
Message-ID: <1644123939.68.0.753547650909.issue46648@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
pull_requests:  -29325

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46648>
_______________________________________

From report at bugs.python.org  Sun Feb  6 01:39:12 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 06 Feb 2022 06:39:12 +0000
Subject: [issue45447] Make IDLE recognize .pyi stub files (and .pyw) as python
 source
In-Reply-To: <1634052276.56.0.989526823091.issue45447@roundup.psfhosted.org>
Message-ID: <1644129552.51.0.252537344871.issue45447@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I broaden the issue title scope and will correspondingly restrict the PR scope.  'Recognition' applies to open and save dialogs, syntax marking, and module browsing.  (The latter needs fixing for .pyw also.)

Improving the handling of no extension source with initial #! line will be a different issue.

----------
title: IDLE: Support syntax highlighting for .pyi stub files -> Make IDLE recognize .pyi stub files (and .pyw) as python source

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45447>
_______________________________________

From report at bugs.python.org  Sun Feb  6 02:30:06 2022
From: report at bugs.python.org (Gregory Beauregard)
Date: Sun, 06 Feb 2022 07:30:06 +0000
Subject: [issue46655] typing.TypeAlias is not in the list of allowed plain
 _SpecialForm typeforms
Message-ID: <1644132606.43.0.5970530565.issue46655@roundup.psfhosted.org>


New submission from Gregory Beauregard <greg at greg.red>:

typing.TypeAlias is allowed to be bare, but it's not listed in the list of types in typing._type_check that are allowed to be bare. This means it's possible to reach the wrong error `TypeError: Plain typing.TypeAlias is not valid as type argument` at runtime.

Examples offhand:
from typing import TypeAlias, get_type_hints
class A:
    a: "TypeAlias" = int
get_type_hints(A)

from typing import Annotated, TypeAlias
b: Annotated[TypeAlias, ""] = int

There's likely more and/or more realistic ways to trigger the problem. Anything that triggers typing._type_check on typing.TypeAlias will give this error (TypeError: Plain typing.TypeAlias is not valid as type argument).

I will fix this by adding TypeAlias to the list of typing special forms allowed to be bare/plain. I intend to move these to their own named var to reduce the chance of types not getting added in the future.

----------
components: Library (Lib)
messages: 412618
nosy: GBeauregard
priority: normal
severity: normal
status: open
title: typing.TypeAlias is not in the list of allowed plain _SpecialForm typeforms
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46655>
_______________________________________

From report at bugs.python.org  Sun Feb  6 02:37:24 2022
From: report at bugs.python.org (Gregory Beauregard)
Date: Sun, 06 Feb 2022 07:37:24 +0000
Subject: [issue46655] typing.TypeAlias is not in the list of allowed plain
 _SpecialForm typeforms
In-Reply-To: <1644132606.43.0.5970530565.issue46655@roundup.psfhosted.org>
Message-ID: <1644133044.11.0.620464907422.issue46655@roundup.psfhosted.org>


Change by Gregory Beauregard <greg at greg.red>:


----------
nosy: +Jelle Zijlstra

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46655>
_______________________________________

From report at bugs.python.org  Sun Feb  6 02:37:54 2022
From: report at bugs.python.org (Gregory Beauregard)
Date: Sun, 06 Feb 2022 07:37:54 +0000
Subject: [issue46655] typing.TypeAlias is not in the list of allowed plain
 _SpecialForm typeforms
In-Reply-To: <1644132606.43.0.5970530565.issue46655@roundup.psfhosted.org>
Message-ID: <1644133074.36.0.867251892282.issue46655@roundup.psfhosted.org>


Change by Gregory Beauregard <greg at greg.red>:


----------
nosy: +kj

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46655>
_______________________________________

From report at bugs.python.org  Sun Feb  6 03:41:50 2022
From: report at bugs.python.org (Gregory Beauregard)
Date: Sun, 06 Feb 2022 08:41:50 +0000
Subject: [issue46655] typing.TypeAlias is not in the list of allowed plain
 _SpecialForm typeforms
In-Reply-To: <1644132606.43.0.5970530565.issue46655@roundup.psfhosted.org>
Message-ID: <1644136910.0.0.871614685187.issue46655@roundup.psfhosted.org>


Change by Gregory Beauregard <greg at greg.red>:


----------
keywords: +patch
pull_requests: +29331
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31156

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46655>
_______________________________________

From report at bugs.python.org  Sun Feb  6 04:17:11 2022
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 06 Feb 2022 09:17:11 +0000
Subject: [issue46654] urllib.request.urlopen doesn't handle UNC paths produced
 by pathlib's as_uri() (but can handle UNC paths with additional
 slashes)
In-Reply-To: <1644100059.97.0.383989396746.issue46654@roundup.psfhosted.org>
Message-ID: <1644139031.07.0.151543014344.issue46654@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> The value of req.selector never starts with "//", for which file_open() 
> checks, but rather a single slash, such as "/Z:/test.py" or 
> "/share/test.py".

To correct myself, actually req.selector will start with "//" for a "file:////" URI, such as "file:////host/share/test.py". For this example, req.host is an empty string, so file_open() still ends up calling open_local_file(), which will open "//host/share/test.py". In Linux, "//host/share" is the same as "/host/share". In Cygwin and MSYS2 it's a UNC path. I guess this case should be allowed, even though the meaning of a "//" root isn't specifically defined in POSIX.

Unless I'm overlooking something, file_open() only has to check the value of req.host. In POSIX, it should require opening a 'local' path, i.e. if req.host isn't None, empty, or a local host, raise URLError.

In Windows, my tests show that the shell API special cases "localhost" (case insensitive) in "file:" URIs. For example, the following are all equivalent: "file:/C:/Temp", "file:///C:/Temp", and "file://localhost/C:/Temp". The shell API does not special case the real local host name or any of its IP addresses, such as 127.0.0.1. They're all handled as UNC paths.

Here's what I've experimented with thus far, which passes the existing urllib tests in Linux and Windows:

    class FileHandler(BaseHandler):
        def file_open(self, req):
            if not self._is_local_path(req):
                if sys.platform == 'win32':
                    path = url2pathname(f'//{req.host}{req.selector}')
                else:
                    raise URLError("In POSIX, the file:// scheme is only "
                                   "supported for local file paths.")
            else:
                path = url2pathname(req.selector)
            return self._common_open_file(req, path)


        def _is_local_path(self, req):
            if req.host:
                host, port = _splitport(req.host)
                if port:
                    raise URLError(f"the host cannot have a port: {req.host}")
                if host.lower() != 'localhost':
                    # In Windows, all other host names are UNC.
                    if sys.platform == 'win32':
                        return False
                    # In POSIX, support all names for the local host.
                    if _safe_gethostbyname(host) not in self.get_names():
                        return False
            return True


        # names for the localhost
        names = None
        def get_names(self):
            if FileHandler.names is None:
                try:
                    FileHandler.names = tuple(
                        socket.gethostbyname_ex('localhost')[2] +
                        socket.gethostbyname_ex(socket.gethostname())[2])
                except socket.gaierror:
                    FileHandler.names = (socket.gethostbyname('localhost'),)
            return FileHandler.names


        def open_local_file(self, req):
            if not self._is_local_path(req):
                raise URLError('file not on local host')
            return self._common_open_file(req, url2pathname(req.selector))


        def _common_open_file(self, req, path):
            import email.utils
            import mimetypes
            host = req.host
            filename = req.selector
            try:
                if host:
                    origurl = f'file://{host}{filename}'
                else:
                    origurl = f'file://{filename}'
                stats = os.stat(path)
                size = stats.st_size
                modified = email.utils.formatdate(stats.st_mtime, usegmt=True)
                mtype = mimetypes.guess_type(filename)[0] or 'text/plain'
                headers = email.message_from_string(
                            f'Content-type: {mtype}\n'
                            f'Content-length: {size}\n'
                            f'Last-modified: {modified}\n')
                return addinfourl(open(path, 'rb'), headers, origurl)
            except OSError as exp:
                raise URLError(exp)


Unfortunately nturl2path.url2pathname() parses some UNC paths incorrectly. For example, the following path should be an invalid UNC path, since "C:" is an invalid name, but instead it gets converted into an unrelated local path.

    >>> nturl2path.url2pathname('//host/C:/Temp/spam.txt')
    'C:\\Temp\\spam.txt'

This goof depends on finding ":" or "|" in the path. It's arguably worse if the last component has a named data stream (allowed by RFC 8089):

    >>> nturl2path.url2pathname('//host/share/spam.txt:eggs')
    'T:\\eggs'

Drive "T:" is from "t:" in "t:eggs", due to simplistic path parsing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46654>
_______________________________________

From report at bugs.python.org  Sun Feb  6 04:54:35 2022
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 06 Feb 2022 09:54:35 +0000
Subject: [issue46656] Compile fails if Py_NO_NAN is defined
Message-ID: <1644141275.01.0.967715714071.issue46656@roundup.psfhosted.org>


New submission from Mark Dickinson <dickinsm at gmail.com>:

The macro Py_NAN may or may not be defined: in particular, a platform that doesn't have NaNs is supposed to be able to define Py_NO_NAN in pyport.h to indicate that.

But not all of our uses of `Py_NAN` are guarded by suitable #ifdef conditionals. As a result, compilation fails if Py_NAN is not defined.

----------
messages: 412620
nosy: mark.dickinson
priority: normal
severity: normal
status: open
title: Compile fails if Py_NO_NAN is defined
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46656>
_______________________________________

From report at bugs.python.org  Sun Feb  6 04:55:07 2022
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 06 Feb 2022 09:55:07 +0000
Subject: [issue46656] Compile fails if Py_NO_NAN is defined
In-Reply-To: <1644141275.01.0.967715714071.issue46656@roundup.psfhosted.org>
Message-ID: <1644141307.79.0.853646422174.issue46656@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's the first point of failure on my machine. Fixing this shows up more failures.

gcc -c -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall    -std=c99 -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Wstrict-prototypes -Werror=implicit-function-declaration -fvisibility=hidden  -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o Objects/complexobject.o Objects/complexobject.c
Objects/complexobject.c:120:27: error: use of undeclared identifier 'Py_NAN'
        r.real = r.imag = Py_NAN;
                          ^
Objects/complexobject.c:206:16: error: use of undeclared identifier 'Py_NAN'
        return Py_NAN;
               ^
2 errors generated.
make: *** [Objects/complexobject.o] Error 1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46656>
_______________________________________

From report at bugs.python.org  Sun Feb  6 05:04:22 2022
From: report at bugs.python.org (Gabriele N Tornetta)
Date: Sun, 06 Feb 2022 10:04:22 +0000
Subject: [issue46652] Use code.co_qualname to provide richer information
In-Reply-To: <1644096355.01.0.0724658726819.issue46652@roundup.psfhosted.org>
Message-ID: <1644141862.15.0.308863424767.issue46652@roundup.psfhosted.org>


Gabriele N Tornetta <phoenix1987 at gmail.com> added the comment:

code.co_qualname was introduced in 2021 with bpo-44530 and shuold give the same guarantees as code.co_name. The __qualname__ attribute is derived from code.co_qualname, so perhaps Cython can benefit from accessing code.co_qualname directly instead?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46652>
_______________________________________

From report at bugs.python.org  Sun Feb  6 07:01:12 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 06 Feb 2022 12:01:12 +0000
Subject: [issue46644] typing: remove callable() check from typing._type_check
In-Reply-To: <1644015777.96.0.875814750019.issue46644@roundup.psfhosted.org>
Message-ID: <1644148872.33.0.641028733615.issue46644@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

There were two reasons of accepting arbitrary callables in _type_check():

1. NewType() returned a function.
2. xml.etree.cElementTree.Element was a function in Python 2.

Now NewType is a class, and Python 2 no longer supported. I agree that we should get rid of the callable() check, but I disagree with the proposed change. The check should be more explicit and strict, not more lenient. List[42] does not make sense and should not be accepted.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46644>
_______________________________________

From report at bugs.python.org  Sun Feb  6 07:01:20 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 06 Feb 2022 12:01:20 +0000
Subject: [issue46644] typing: remove callable() check from typing._type_check
In-Reply-To: <1644015777.96.0.875814750019.issue46644@roundup.psfhosted.org>
Message-ID: <1644148880.38.0.914164021978.issue46644@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +29332
pull_request: https://github.com/python/cpython/pull/31159

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46644>
_______________________________________

From report at bugs.python.org  Sun Feb  6 07:13:17 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Feb 2022 12:13:17 +0000
Subject: [issue46640] Python can now use the C99 NAN constant
In-Reply-To: <1644006249.4.0.292742084923.issue46640@roundup.psfhosted.org>
Message-ID: <1644149597.16.0.451526612193.issue46640@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 54842e4311bb0e34012d1984b42eab41eeeaea6a by Victor Stinner in branch 'main':
bpo-46640: Py_NAN now uses the C99 NAN constant (GH-31134)
https://github.com/python/cpython/commit/54842e4311bb0e34012d1984b42eab41eeeaea6a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46640>
_______________________________________

From report at bugs.python.org  Sun Feb  6 07:29:29 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Feb 2022 12:29:29 +0000
Subject: [issue46656] Compile fails if Py_NO_NAN is defined
In-Reply-To: <1644141275.01.0.967715714071.issue46656@roundup.psfhosted.org>
Message-ID: <1644150569.72.0.748485008652.issue46656@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Python uses Py_NAN without "#ifdef Py_NAN" guard since 2008. Building Python with Py_NO_NAN never worked. Nobody reported such build failure in the last 14 years...

IMO it's time to stop supporting platforms without NaN support.


> Objects/complexobject.c:120:27: error: use of undeclared identifier 'Py_NAN'

I only try a few Python versions: I reproduce this issue in Python 3.11, 3.5, 3.2 and... even Python 2.7!

The Py_NO_NAN macro was introduced in Python 2.6 (2007) by bpo-1635 "Float patch for inf and nan on Windows (and other platforms)":
--
commit 0a8143f6462b491d3f12bfb899efd6e044e350be
Author: Christian Heimes <christian at cheimes.de>
Date:   Tue Dec 18 23:22:54 2007 +0000

    Applied patch #1635: Float patch for inf and nan on Windows (and other platforms).
    
    The patch unifies float("inf") and repr(float("inf")) on all platforms.

(...)

+#if !defined(Py_NAN) && !defined(Py_NO_NAN)
+#define Py_NAN (Py_HUGE_VAL * 0.)
+#endif
---

The following change started to use Py_NAN in many C files:

* Modules/cmathmodule.c
* Objects/complexobject.c
* Objects/floatobject.c
* Python/pymath.c 

---
commit 6f34109384f3a78d5f4f8bdd418a89caca19631e (HEAD)
Author: Christian Heimes <christian at cheimes.de>
Date:   Fri Apr 18 23:13:07 2008 +0000

    I finally got the time to update and merge Mark's and my trunk-math branch. The patch is collaborated w
ork of Mark Dickinson and me. It was mostly done a few months ago. The patch fixes a lot of loose ends and 
edge cases related to operations with NaN, INF, very small values and complex math.
    
    The patch also adds acosh, asinh, atanh, log1p and copysign to all platforms. Finally it fixes differen
ces between platforms like different results or exceptions for edge cases. Have fun :)
---

At this commit, floatobject.c and pymath.c use "#ifdef Py_NAN" carefully, whereas cmathmodule.c and complexobject.c use Py_NAN with no "#ifdef Py_NAN" guard.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46656>
_______________________________________

From report at bugs.python.org  Sun Feb  6 07:30:09 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Feb 2022 12:30:09 +0000
Subject: [issue46640] Python can now use the C99 NAN constant or
 __builtin_nan()
In-Reply-To: <1644006249.4.0.292742084923.issue46640@roundup.psfhosted.org>
Message-ID: <1644150609.85.0.416242707791.issue46640@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I merged my change, thanks for the reviews.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
title: Python can now use the C99 NAN constant -> Python can now use the C99 NAN constant or __builtin_nan()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46640>
_______________________________________

From report at bugs.python.org  Sun Feb  6 07:31:53 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 06 Feb 2022 12:31:53 +0000
Subject: [issue46642] typing: tested TypeVar instance subclass TypeError is
 incidental
In-Reply-To: <1644011961.17.0.0152846458354.issue46642@roundup.psfhosted.org>
Message-ID: <1644150713.08.0.743261810917.issue46642@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Note that instances of most other types are non-subclassable "by accident".

>>> class A(42): pass
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: int() takes at most 2 arguments (3 given)

>>> class B:
...     def __init__(self, *args): pass
... 
>>> class C(B()): pass
... 
>>> C
<__main__.B object at 0x7fdcfb49aae0>

It is okay until we decide that there is a problem, and it that case it would require more general solution.

Are there any issues with this in real code?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46642>
_______________________________________

From report at bugs.python.org  Sun Feb  6 07:46:52 2022
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 06 Feb 2022 12:46:52 +0000
Subject: [issue46187] Optionally support rounding for math.isqrt()
In-Reply-To: <1640633399.46.0.8152811809.issue46187@roundup.psfhosted.org>
Message-ID: <1644151612.77.0.724731490749.issue46187@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks, Tim; very interesting. I hadn't seen this factoring algorithm before.

> That wants the _ceiling_ of the square root.

Looks like what it actually wants is the ceiling analog of isqrtrem: that is, it needs both the ceiling of the square root *and* the difference between the square of that ceiling and the original number.

The description of the algorithm in section 2 is a bit odd: they define m := s*s % n, using an expensive modulo operation, when all they need is a subtraction: m := s*s - n*i. This is noted in section 3 ("to reduce modulo Mn at step 3, one may simply subtract Mni from s2"), but they fail to note that the two things aren't equivalent for large enough i, possibly because that large an i won't be used in practice. And in the case that the two quantities differ, it's the subtraction that's needed to make the algorithm work, not the mod result.

Here's a Python version of Hart's algorithm:


from itertools import count
from math import gcd, isqrt

def isqrtrem(n):
    """ For n >= 0, return s, r satisfying s*s + r == n, 0 <= r <= 2*s. """
    s = isqrt(n)
    return s, n - s*s

def csqrtrem(n):
    """ For n > 0, return s, r satisfying n + s*s == r, 0 <= r <= 2*(s-1). """
    s = 1 + isqrt(n-1)
    return s, s*s - n

def factor(n):
    """ Attempt to use Hart's algorithm to find a factor of n. """
    for i in count(start=1):
        s, m = csqrtrem(n*i)
        t, r = isqrtrem(m)
        if not r:
            return gcd(n, s-t)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46187>
_______________________________________

From report at bugs.python.org  Sun Feb  6 08:07:08 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Feb 2022 13:07:08 +0000
Subject: [issue46656] Compile fails if Py_NO_NAN is defined
In-Reply-To: <1644141275.01.0.967715714071.issue46656@roundup.psfhosted.org>
Message-ID: <1644152828.84.0.239099135995.issue46656@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +29333
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31160

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46656>
_______________________________________

From report at bugs.python.org  Sun Feb  6 08:08:30 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Feb 2022 13:08:30 +0000
Subject: [issue46656] Compile fails if Py_NO_NAN is defined
In-Reply-To: <1644141275.01.0.967715714071.issue46656@roundup.psfhosted.org>
Message-ID: <1644152910.62.0.607403084852.issue46656@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

If someone suddenly requires platforms without NaN support, they can maintain a (downstream) patch, or we can revert the change in Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46656>
_______________________________________

From report at bugs.python.org  Sun Feb  6 08:11:52 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Feb 2022 13:11:52 +0000
Subject: [issue46656] Compile fails if Py_NO_NAN is defined
In-Reply-To: <1644141275.01.0.967715714071.issue46656@roundup.psfhosted.org>
Message-ID: <1644153112.61.0.284397161164.issue46656@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

See also bpo-46640 "Python can now use the C99 NAN constant or __builtin_nan()".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46656>
_______________________________________

From report at bugs.python.org  Sun Feb  6 08:23:47 2022
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 06 Feb 2022 13:23:47 +0000
Subject: [issue46187] Optionally support rounding for math.isqrt()
In-Reply-To: <1640633399.46.0.8152811809.issue46187@roundup.psfhosted.org>
Message-ID: <1644153827.68.0.96606568657.issue46187@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Ah, https://math.mit.edu/research/highschool/primes/materials/2019/Gopalakrishna.pdf is interesting - they conjecture a bound on the number of iterations required, and note that under that conjecture the mod can be replaced by a subtraction.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46187>
_______________________________________

From report at bugs.python.org  Sun Feb  6 08:26:32 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Feb 2022 13:26:32 +0000
Subject: [issue46648] `test.test_urllib2.MiscTests.test_issue16464` started to
 fail
In-Reply-To: <1644061533.84.0.594817920054.issue46648@roundup.psfhosted.org>
Message-ID: <1644153992.42.0.135088006796.issue46648@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29334
pull_request: https://github.com/python/cpython/pull/31161

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46648>
_______________________________________

From report at bugs.python.org  Sun Feb  6 08:36:53 2022
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 06 Feb 2022 13:36:53 +0000
Subject: [issue46656] Compile fails if Py_NO_NAN is defined
In-Reply-To: <1644141275.01.0.967715714071.issue46656@roundup.psfhosted.org>
Message-ID: <1644154613.0.0.780441443624.issue46656@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Okay, the comments I made on #46640 still apply (even though they didn't properly apply on that issue). I think this needs a python-dev discussion before it can be moved forward - requiring the existence of NaNs is very close to requiring IEEE 754 floating-point, and that's something we've been historically reluctant to do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46656>
_______________________________________

From report at bugs.python.org  Sun Feb  6 08:59:38 2022
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 06 Feb 2022 13:59:38 +0000
Subject: [issue23952] cgi: Document the 'maxlen' member of the cgi module
In-Reply-To: <1429034285.17.0.254053228622.issue23952@psf.upfronthosting.co.za>
Message-ID: <1644155978.06.0.631187744769.issue23952@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:


New changeset 6c4e44ef8ab550f846ba056d4561efb8256b8eab by Hugo van Kemenade in branch 'main':
bpo-23952: Document cgi module's maxlen variable (GH-30338)
https://github.com/python/cpython/commit/6c4e44ef8ab550f846ba056d4561efb8256b8eab


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23952>
_______________________________________

From report at bugs.python.org  Sun Feb  6 09:00:05 2022
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 06 Feb 2022 14:00:05 +0000
Subject: [issue23952] cgi: Document the 'maxlen' member of the cgi module
In-Reply-To: <1429034285.17.0.254053228622.issue23952@psf.upfronthosting.co.za>
Message-ID: <1644156005.62.0.457264488895.issue23952@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/issue23952>
_______________________________________

From report at bugs.python.org  Sun Feb  6 09:02:49 2022
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 06 Feb 2022 14:02:49 +0000
Subject: [issue46586] In documentation contents enum.property erroneously
 links to built-in property
In-Reply-To: <1643555525.86.0.209520180874.issue46586@roundup.psfhosted.org>
Message-ID: <1644156169.49.0.551359378992.issue46586@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

In case a future reader has the same question:

A tilde (~) creates a link to whatever follows (so `enum.property` above), but only shows the last segment in the text (so `property`).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46586>
_______________________________________

From report at bugs.python.org  Sun Feb  6 09:02:58 2022
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 06 Feb 2022 14:02:58 +0000
Subject: [issue46586] In documentation contents enum.property erroneously
 links to built-in property
In-Reply-To: <1643555525.86.0.209520180874.issue46586@roundup.psfhosted.org>
Message-ID: <1644156178.12.0.121108589301.issue46586@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
Removed message: https://bugs.python.org/msg412634

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46586>
_______________________________________

From report at bugs.python.org  Sun Feb  6 09:09:09 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Feb 2022 14:09:09 +0000
Subject: [issue46648] `test.test_urllib2.MiscTests.test_issue16464` started to
 fail
In-Reply-To: <1644061533.84.0.594817920054.issue46648@roundup.psfhosted.org>
Message-ID: <1644156549.14.0.460647648177.issue46648@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 1578de2fcd685c71f9c84e09bac32901dea192c1 by Victor Stinner in branch 'main':
bpo-46648: Skip test_urllib2.test_issue16464() (GH-31161)
https://github.com/python/cpython/commit/1578de2fcd685c71f9c84e09bac32901dea192c1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46648>
_______________________________________

From report at bugs.python.org  Sun Feb  6 09:09:15 2022
From: report at bugs.python.org (miss-islington)
Date: Sun, 06 Feb 2022 14:09:15 +0000
Subject: [issue46648] `test.test_urllib2.MiscTests.test_issue16464` started to
 fail
In-Reply-To: <1644061533.84.0.594817920054.issue46648@roundup.psfhosted.org>
Message-ID: <1644156555.45.0.532084452894.issue46648@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: +29335
pull_request: https://github.com/python/cpython/pull/31162

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46648>
_______________________________________

From report at bugs.python.org  Sun Feb  6 09:09:19 2022
From: report at bugs.python.org (miss-islington)
Date: Sun, 06 Feb 2022 14:09:19 +0000
Subject: [issue46648] `test.test_urllib2.MiscTests.test_issue16464` started to
 fail
In-Reply-To: <1644061533.84.0.594817920054.issue46648@roundup.psfhosted.org>
Message-ID: <1644156559.42.0.666354305759.issue46648@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29336
pull_request: https://github.com/python/cpython/pull/31163

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46648>
_______________________________________

From report at bugs.python.org  Sun Feb  6 09:11:39 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Feb 2022 14:11:39 +0000
Subject: [issue46656] Compile fails if Py_NO_NAN is defined
In-Reply-To: <1644141275.01.0.967715714071.issue46656@roundup.psfhosted.org>
Message-ID: <1644156699.99.0.381372106987.issue46656@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Is the macro PY_NO_SHORT_FLOAT_REPR also related to platforms which don't support IEEE 754?

In 2022, which platforms don't support IEEE 754?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46656>
_______________________________________

From report at bugs.python.org  Sun Feb  6 09:30:32 2022
From: report at bugs.python.org (miss-islington)
Date: Sun, 06 Feb 2022 14:30:32 +0000
Subject: [issue46648] `test.test_urllib2.MiscTests.test_issue16464` started to
 fail
In-Reply-To: <1644061533.84.0.594817920054.issue46648@roundup.psfhosted.org>
Message-ID: <1644157832.07.0.0382290332393.issue46648@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1b8a34ae65688cfadc81e0174b5aea979b264b3e by Miss Islington (bot) in branch '3.9':
bpo-46648: Skip test_urllib2.test_issue16464() (GH-31161)
https://github.com/python/cpython/commit/1b8a34ae65688cfadc81e0174b5aea979b264b3e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46648>
_______________________________________

From report at bugs.python.org  Sun Feb  6 09:33:11 2022
From: report at bugs.python.org (miss-islington)
Date: Sun, 06 Feb 2022 14:33:11 +0000
Subject: [issue46648] `test.test_urllib2.MiscTests.test_issue16464` started to
 fail
In-Reply-To: <1644061533.84.0.594817920054.issue46648@roundup.psfhosted.org>
Message-ID: <1644157991.68.0.0135895074138.issue46648@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c88407ccf5e72d00e909c2399ff7163501aa7089 by Miss Islington (bot) in branch '3.10':
bpo-46648: Skip test_urllib2.test_issue16464() (GH-31161)
https://github.com/python/cpython/commit/c88407ccf5e72d00e909c2399ff7163501aa7089


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46648>
_______________________________________

From report at bugs.python.org  Sun Feb  6 09:49:13 2022
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 06 Feb 2022 14:49:13 +0000
Subject: [issue46657] Add mimalloc memory allocator
Message-ID: <1644158952.9.0.443530192167.issue46657@roundup.psfhosted.org>


New submission from Christian Heimes <lists at cheimes.de>:

>From https://github.com/microsoft/mimalloc

> mimalloc (pronounced "me-malloc") is a general purpose allocator with excellent performance characteristics. Initially developed by Daan Leijen for the run-time systems of the Koka and Lean languages.

mimalloc has several interesting properties that make it useful for CPython. Amongst other it is fast, thread-safe, and NUMA-aware. It has built-in free lists with multi-sharding and allocation heaps. While Python's obmalloc requires the GIL to protect its data structures, mimalloc uses mostly thread-local and atomic instructions (compare-and-swap) for efficiency. Sam Gross' nogil relies on mimalloc's thread safety and uses first-class heaps for heap walking GC.

mimalloc works on majority of platforms and CPU architectures. However it requires a compiler with C11 atomics support. CentOS 7's default GCC is slightly too old, more recent GCC from Developer Toolset is required. 

For 3.11 I plan to integrate mimalloc as an optional drop-in replacement for obmalloc. Users will be able to compile CPython without mimalloc or disable mimalloc with PYTHONMALLOC env var. Since mimalloc will be optional in 3.11, Python won't depend or expose on any of the advanced features yet. The approach enables the community to test and give feedback with minimal risk of breakage.

mimalloc sources will vendored without any option to use system libraries. Python's mimalloc requires several non-standard compile-time flags. In the future Python may extend or modify mimalloc for heap walking and nogil, too.

(This is a tracking bug until I find time to finish a PEP.)

----------
components: Interpreter Core
messages: 412639
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: Add mimalloc memory allocator
type: enhancement
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46657>
_______________________________________

From report at bugs.python.org  Sun Feb  6 09:50:58 2022
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 06 Feb 2022 14:50:58 +0000
Subject: [issue46656] Compile fails if Py_NO_NAN is defined
In-Reply-To: <1644141275.01.0.967715714071.issue46656@roundup.psfhosted.org>
Message-ID: <1644159058.78.0.632025300026.issue46656@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Is the macro PY_NO_SHORT_FLOAT_REPR also related to platforms which don't support IEEE 754?

Yes, though it's a bit more than that: we also need the platform either not to have issues with double rounding for normal numbers, or we need to be able to control the x87 rounding mode in the case that double rounding might be an issue. See the explanations in the source.

https://github.com/python/cpython/blob/025cbe7a9b5d3058ce2eb8015d3650e396004545/Include/pyport.h#L345-L355

> In 2022, which platforms don't support IEEE 754?

None that CPython might plausibly run on that I'm aware of.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46656>
_______________________________________

From report at bugs.python.org  Sun Feb  6 09:52:03 2022
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 06 Feb 2022 14:52:03 +0000
Subject: [issue46657] Add mimalloc memory allocator
In-Reply-To: <1644158952.9.0.443530192167.issue46657@roundup.psfhosted.org>
Message-ID: <1644159123.52.0.177408869682.issue46657@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
keywords: +patch
pull_requests: +29337
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31164

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46657>
_______________________________________

From report at bugs.python.org  Sun Feb  6 09:57:03 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 06 Feb 2022 14:57:03 +0000
Subject: [issue46657] Add mimalloc memory allocator
In-Reply-To: <1644158952.9.0.443530192167.issue46657@roundup.psfhosted.org>
Message-ID: <1644159423.81.0.822776882362.issue46657@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
nosy: +corona10, nascheme

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46657>
_______________________________________

From report at bugs.python.org  Sun Feb  6 09:59:52 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 06 Feb 2022 14:59:52 +0000
Subject: [issue46657] Add mimalloc memory allocator
In-Reply-To: <1644158952.9.0.443530192167.issue46657@roundup.psfhosted.org>
Message-ID: <1644159592.11.0.558003357601.issue46657@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:

I add Neil to the nosy list since he is one of the kick-off members with this amazing works :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46657>
_______________________________________

From report at bugs.python.org  Sun Feb  6 10:01:09 2022
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 06 Feb 2022 15:01:09 +0000
Subject: [issue46656] Compile fails if Py_NO_NAN is defined
In-Reply-To: <1644141275.01.0.967715714071.issue46656@roundup.psfhosted.org>
Message-ID: <1644159669.83.0.705980998128.issue46656@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> See the explanations in the source.

Hmm. Those explanations made more sense before PR GH-28882. :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46656>
_______________________________________

From report at bugs.python.org  Sun Feb  6 10:42:54 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Feb 2022 15:42:54 +0000
Subject: [issue46648] `test.test_urllib2.MiscTests.test_issue16464` started to
 fail
In-Reply-To: <1644061533.84.0.594817920054.issue46648@roundup.psfhosted.org>
Message-ID: <1644162174.61.0.813126046115.issue46648@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/issue46648>
_______________________________________

From report at bugs.python.org  Sun Feb  6 10:52:18 2022
From: report at bugs.python.org (David CARLIER)
Date: Sun, 06 Feb 2022 15:52:18 +0000
Subject: [issue46658] shutil Lib enables sendfile on solaris for regular files
Message-ID: <1644162738.48.0.935411238665.issue46658@roundup.psfhosted.org>


New submission from David CARLIER <devnexen at gmail.com>:

- sendfile on solaris supports copy between regular file descriptors as well.

----------
components: Library (Lib)
messages: 412643
nosy: devnexen
priority: normal
pull_requests: 29338
severity: normal
status: open
title: shutil Lib enables sendfile on solaris for regular files
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46658>
_______________________________________

From report at bugs.python.org  Sun Feb  6 10:56:30 2022
From: report at bugs.python.org (Meer Suri)
Date: Sun, 06 Feb 2022 15:56:30 +0000
Subject: [issue46586] In documentation contents enum.property erroneously
 links to built-in property
In-Reply-To: <1643555525.86.0.209520180874.issue46586@roundup.psfhosted.org>
Message-ID: <1644162990.94.0.654264867108.issue46586@roundup.psfhosted.org>


Meer Suri <meersuri at gmail.com> added the comment:

(First time contributor here seeking guidance) I see that this problem of automatically linking to the unintended page has occurred in other parts of the docs and has been handled in another way - In Doc/library/functions.rst, local targets are used with replacement texts-

unintended linking code- :func:`dict`
local target code- |func-dict|_ 
and this substitution is added-  .. |func-dict| replace:: ``dict()``

Would this be the preferred way of solving this? I tried this change and it achieves the correct linking for me

----------
nosy: +meersuri

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46586>
_______________________________________

From report at bugs.python.org  Sun Feb  6 11:12:39 2022
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 06 Feb 2022 16:12:39 +0000
Subject: [issue46657] Add mimalloc memory allocator
In-Reply-To: <1644158952.9.0.443530192167.issue46657@roundup.psfhosted.org>
Message-ID: <1644163959.04.0.333231525155.issue46657@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

New features:

- vendored mimalloc 2.0.3 + two patches from mimalloc dev branch. Mimalloc is embedded in obmalloc.o. Symbols are either hidden or names are mangled to have a _Py_ prefix.
- ./configure --with[out]-mimalloc (default: yes), fails if atomics are not available.
- PYTHONMALLOC=mimalloc, PYTHONMALLOC=mimalloc-debug env var settings
- PYMEM_ALLOCATOR_MIMALLOC, PYMEM_ALLOCATOR_MIMALLOC_DEBUG
- sys.debugmallocstats() and _PyObject_DebugMallocStats() prints mimalloc stats
- sys._malloc_info struct, contains information about available and current allocator

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46657>
_______________________________________

From report at bugs.python.org  Sun Feb  6 12:25:28 2022
From: report at bugs.python.org (Gregory Beauregard)
Date: Sun, 06 Feb 2022 17:25:28 +0000
Subject: [issue46642] typing: tested TypeVar instance subclass TypeError is
 incidental
In-Reply-To: <1644011961.17.0.0152846458354.issue46642@roundup.psfhosted.org>
Message-ID: <1644168328.23.0.889787539107.issue46642@roundup.psfhosted.org>


Gregory Beauregard <greg at greg.red> added the comment:

The issue in real code I had in mind was internal to cpython: if we remove the callable() check from _type_check naively, this test starts to fail. Both of our proposed changes happen to not fail this check. Given your second example, would you prefer if we remove this testcase if the issue comes up in the final proposed patches? On the other hand, there is precedent for giving this a nice error message other places in typing.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46642>
_______________________________________

From report at bugs.python.org  Sun Feb  6 12:33:14 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Feb 2022 17:33:14 +0000
Subject: [issue46659] Deprecate locale.getdefaultlocale() function
Message-ID: <1644168794.44.0.0658923518102.issue46659@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

The locale.getdefaultlocale() function only relies on environment variables. At Python startup, Python calls setlocale() is set the LC_CTYPE locale to the user preferred encoding.

Since Python 3.7, if the LC_CTYPE locale is "C" or "POSIX", PEP 538 sets the LC_CTYPE locale to a UTF-8 variant if available, and PEP 540 ignores the locale and forces the usage of the UTF-8 encoding. The *effective* encoding used by Python is inconsistent with environment variables.

Moreover, if setlocale() is called to set the LC_CTYPE locale to a locale different than the user locale, again, environment variables are inconsistent with the effective locale.

In these cases, locale.getdefaultlocale() result is not the expected locale and it can lead to mojibake and other issues.

For these reasons, I propose to deprecate locale.getdefaultlocale(): setlocale(), getpreferredencoding() and getlocale() should be used instead.

For the background on these issues, see recent issue:

* bpo-43552
* bpo-43557

----------
components: Library (Lib)
messages: 412647
nosy: vstinner
priority: normal
severity: normal
status: open
title: Deprecate locale.getdefaultlocale() function
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46659>
_______________________________________

From report at bugs.python.org  Sun Feb  6 12:47:55 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Feb 2022 17:47:55 +0000
Subject: [issue43557] Deprecate getdefaultlocale(),
 getlocale() and normalize() functions
In-Reply-To: <1616160447.56.0.84902377628.issue43557@roundup.psfhosted.org>
Message-ID: <1644169675.2.0.0780950450588.issue43557@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Deprecating these functions is complex. I prefer to start with the least controversial part: bpo-46659.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43557>
_______________________________________

From report at bugs.python.org  Sun Feb  6 12:51:35 2022
From: report at bugs.python.org (Sam Roberts)
Date: Sun, 06 Feb 2022 17:51:35 +0000
Subject: [issue46660] datetime.datetime.fromtimestamp
Message-ID: <1644169895.69.0.613310626242.issue46660@roundup.psfhosted.org>


New submission from Sam Roberts <pythondotorg at roberts-family.com>:

Python 3.9.2 (tags/v3.9.2:1a79785, Feb 19 2021, 13:44:55) [MSC v.1928 64 bit (AMD64)] on win32

datetime.fromtimestamp() fails for naive-datetime values prior to the start of the epoch, but for some reason works properly for aware-datetime values prior to the start of the epoch.

This is at least inconsistent, but seems like a bug.

Negative timestamps for dates prior to the start of the epoch are used by yahoo finance and in the yfinance module.

>>> import datetime
>>> start = int(datetime.datetime(1962, 1, 31, tzinfo=datetime.timezone.utc).timestamp())
>>> start
-249868800
>>> start = int(datetime.datetime(1962, 1, 31).timestamp())
Traceback (most recent call last):
  File "<pyshell#3>", line 1, in <module>
    start = int(datetime.datetime(1962, 1, 31).timestamp())
OSError: [Errno 22] Invalid argument

----------
components: Library (Lib)
messages: 412649
nosy: smrpy
priority: normal
severity: normal
status: open
title: datetime.datetime.fromtimestamp
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46660>
_______________________________________

From report at bugs.python.org  Sun Feb  6 12:52:38 2022
From: report at bugs.python.org (Sam Roberts)
Date: Sun, 06 Feb 2022 17:52:38 +0000
Subject: [issue46660] datetime.fromtimestamp() fails for naive-datetime values
 prior to the start of the epoch
In-Reply-To: <1644169895.69.0.613310626242.issue46660@roundup.psfhosted.org>
Message-ID: <1644169958.98.0.00468177064767.issue46660@roundup.psfhosted.org>


Change by Sam Roberts <pythondotorg at roberts-family.com>:


----------
title: datetime.datetime.fromtimestamp -> datetime.fromtimestamp() fails for naive-datetime values prior to the start of the epoch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46660>
_______________________________________

From report at bugs.python.org  Sun Feb  6 12:55:57 2022
From: report at bugs.python.org (Sam Roberts)
Date: Sun, 06 Feb 2022 17:55:57 +0000
Subject: [issue46660] datetime.timestamp() fails for naive-datetime values
 prior to the start of the epoch
In-Reply-To: <1644169895.69.0.613310626242.issue46660@roundup.psfhosted.org>
Message-ID: <1644170157.38.0.615314703661.issue46660@roundup.psfhosted.org>


Sam Roberts <pythondotorg at roberts-family.com> added the comment:

the first sentence should have read:

datetime.timestamp() fails for naive-datetime values prior to the start of the epoch, but for some reason works properly for aware-datetime values prior to the start of the epoch.

----------
title: datetime.fromtimestamp() fails for naive-datetime values prior to the start of the epoch -> datetime.timestamp() fails for naive-datetime values prior to the start of the epoch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46660>
_______________________________________

From report at bugs.python.org  Sun Feb  6 12:59:09 2022
From: report at bugs.python.org (Gregory Beauregard)
Date: Sun, 06 Feb 2022 17:59:09 +0000
Subject: [issue46644] typing: remove callable() check from typing._type_check
In-Reply-To: <1644015777.96.0.875814750019.issue46644@roundup.psfhosted.org>
Message-ID: <1644170349.93.0.108632490881.issue46644@roundup.psfhosted.org>


Gregory Beauregard <greg at greg.red> added the comment:

List[42] is already accepted, and your proposed patch does not change it to make it not accepted. The issue is _type_check is only called in a few particular locations; this is part of the technical reason I'm not very concerned about relaxing the _type_check requirements.

>From a type checking philosophy point of view I agree with Jelle and am negative on strict runtime requirements in typing.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46644>
_______________________________________

From report at bugs.python.org  Sun Feb  6 13:14:46 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Feb 2022 18:14:46 +0000
Subject: [issue46659] Deprecate locale.getdefaultlocale() function
In-Reply-To: <1644168794.44.0.0658923518102.issue46659@roundup.psfhosted.org>
Message-ID: <1644171286.28.0.494334480335.issue46659@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +29339
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31166

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46659>
_______________________________________

From report at bugs.python.org  Sun Feb  6 13:21:24 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Feb 2022 18:21:24 +0000
Subject: [issue46659] Deprecate locale.getdefaultlocale() function
In-Reply-To: <1644168794.44.0.0658923518102.issue46659@roundup.psfhosted.org>
Message-ID: <1644171684.6.0.892895803727.issue46659@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

cal_locale.py: Test calendar.LocaleTextCalendar() default locale, manual test for GH-31166.

----------
Added file: https://bugs.python.org/file50605/cal_locale.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46659>
_______________________________________

From report at bugs.python.org  Sun Feb  6 13:24:00 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Feb 2022 18:24:00 +0000
Subject: [issue46659] Deprecate locale.getdefaultlocale() function
In-Reply-To: <1644168794.44.0.0658923518102.issue46659@roundup.psfhosted.org>
Message-ID: <1644171840.83.0.813186652564.issue46659@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


Removed file: https://bugs.python.org/file50605/cal_locale.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46659>
_______________________________________

From report at bugs.python.org  Sun Feb  6 13:24:05 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Feb 2022 18:24:05 +0000
Subject: [issue46659] Deprecate locale.getdefaultlocale() function
In-Reply-To: <1644168794.44.0.0658923518102.issue46659@roundup.psfhosted.org>
Message-ID: <1644171845.99.0.140284756758.issue46659@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


Added file: https://bugs.python.org/file50606/cal_locale.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46659>
_______________________________________

From report at bugs.python.org  Sun Feb  6 13:30:52 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Feb 2022 18:30:52 +0000
Subject: [issue46659] Deprecate locale.getdefaultlocale() function
In-Reply-To: <1644168794.44.0.0658923518102.issue46659@roundup.psfhosted.org>
Message-ID: <1644172252.09.0.887151469619.issue46659@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29340
pull_request: https://github.com/python/cpython/pull/31167

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46659>
_______________________________________

From report at bugs.python.org  Sun Feb  6 13:41:46 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Feb 2022 18:41:46 +0000
Subject: [issue46659] Deprecate locale.getdefaultlocale() function
In-Reply-To: <1644168794.44.0.0658923518102.issue46659@roundup.psfhosted.org>
Message-ID: <1644172906.78.0.689758974756.issue46659@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29341
pull_request: https://github.com/python/cpython/pull/31168

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46659>
_______________________________________

From report at bugs.python.org  Sun Feb  6 13:43:45 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 06 Feb 2022 18:43:45 +0000
Subject: [issue46661] Duplicat deprecation warnings in docs for asyncio
Message-ID: <1644173025.54.0.0182116442771.issue46661@roundup.psfhosted.org>


New submission from Guido van Rossum <guido at python.org>:

I found that several asyncio function descriptions, e.g. gather, have a duplicate deprecation notice like this:

   .. deprecated-removed:: 3.8 3.10
      The ``loop`` parameter.  This function has been implicitly getting the
      current running loop since 3.7.  See
      :ref:`What's New in 3.10's Removed section <whatsnew310-removed>`
      for more information.

For gather, that notice appears both before and after the example. For a few others, too.

----------
assignee: docs at python
components: Documentation, asyncio
messages: 412653
nosy: asvetlov, docs at python, gvanrossum, yselivanov
priority: normal
severity: normal
status: open
title: Duplicat deprecation warnings in docs for asyncio
versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46661>
_______________________________________

From report at bugs.python.org  Sun Feb  6 13:58:56 2022
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 06 Feb 2022 18:58:56 +0000
Subject: [issue46657] Add mimalloc memory allocator
In-Reply-To: <1644158952.9.0.443530192167.issue46657@roundup.psfhosted.org>
Message-ID: <1644173936.5.0.963442253707.issue46657@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Buildbots "PPC64 Fedora PR" and all RHEL 7 build bots provided by David Edelsohn are failing because compiler is missing support for stdatomic.h.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46657>
_______________________________________

From report at bugs.python.org  Sun Feb  6 14:03:59 2022
From: report at bugs.python.org (Bo-wei Chen)
Date: Sun, 06 Feb 2022 19:03:59 +0000
Subject: [issue46662] Lib/sqlite3/dbapi2.py: convert_timestamp function failed
 to correctly parse timestamp
Message-ID: <1644174239.54.0.192057033337.issue46662@roundup.psfhosted.org>


New submission from Bo-wei Chen <rayologist1002 at gmail.com>:

convert_timestamp function in Lib/sqlite3/dbapi2.py fails to parse a timestamp correctly, if it does not have microseconds but comes with timezone information, e.g. b"2022-02-01 16:09:35+00:00"

Traceback:

Traceback (most recent call last):
  File "/Users/user/Desktop/test.py", line 121, in <module>
    convert_timestamp(b"2022-02-01 16:09:35+00:00")
  File "/Users/user/Desktop/test.py", line 112, in convert_timestamp
    hours, minutes, seconds = map(int, timepart_full[0].split(b":"))
ValueError: invalid literal for int() with base 10: b'35+00'

----------
components: Library (Lib)
messages: 412655
nosy: Rayologist
priority: normal
severity: normal
status: open
title: Lib/sqlite3/dbapi2.py: convert_timestamp function failed to correctly parse timestamp
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46662>
_______________________________________

From report at bugs.python.org  Sun Feb  6 14:12:38 2022
From: report at bugs.python.org (Bo-wei Chen)
Date: Sun, 06 Feb 2022 19:12:38 +0000
Subject: [issue46662] Lib/sqlite3/dbapi2.py: convert_timestamp function failed
 to correctly parse timestamp
In-Reply-To: <1644174239.54.0.192057033337.issue46662@roundup.psfhosted.org>
Message-ID: <1644174758.61.0.914634132562.issue46662@roundup.psfhosted.org>


Change by Bo-wei Chen <rayologist1002 at gmail.com>:


----------
keywords: +patch
pull_requests: +29342
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31169

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46662>
_______________________________________

From report at bugs.python.org  Sun Feb  6 14:13:13 2022
From: report at bugs.python.org (PySimpleGUI)
Date: Sun, 06 Feb 2022 19:13:13 +0000
Subject: [issue46180] Button clicked failed when mouse hover tooltip and
 tooltip destroyed
In-Reply-To: <1640515148.68.0.766649384181.issue46180@roundup.psfhosted.org>
Message-ID: <1644174793.12.0.797021929288.issue46180@roundup.psfhosted.org>


PySimpleGUI <PySimpleGUI at PySimpleGUI.com> added the comment:

I'm sorry for not getting back quicker on the Linux testing.  I've not figured out how to get 8.6.12 up and running on my Linux environment.  I've tried both Python 3.9 and Python 3.10 and neither have 8.6.12.

----------
Added file: https://bugs.python.org/file50607/Linux3.10.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46180>
_______________________________________

From report at bugs.python.org  Sun Feb  6 14:15:28 2022
From: report at bugs.python.org (Irit Katriel)
Date: Sun, 06 Feb 2022 19:15:28 +0000
Subject: [issue25970] py_compile.compile fails if existing bytecode file is
 unwritable
In-Reply-To: <1451342366.02.0.359815374422.issue25970@psf.upfronthosting.co.za>
Message-ID: <1644174928.75.0.256885886808.issue25970@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at gmail.com>:


----------
stage:  -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25970>
_______________________________________

From report at bugs.python.org  Sun Feb  6 14:16:21 2022
From: report at bugs.python.org (Irit Katriel)
Date: Sun, 06 Feb 2022 19:16:21 +0000
Subject: [issue31057] pydoc for tempfile.TemporaryDirectory should say it
 returns the name
In-Reply-To: <1501167953.07.0.778065697758.issue31057@psf.upfronthosting.co.za>
Message-ID: <1644174981.74.0.835752869615.issue31057@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at gmail.com>:


----------
stage:  -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31057>
_______________________________________

From report at bugs.python.org  Sun Feb  6 14:16:53 2022
From: report at bugs.python.org (Irit Katriel)
Date: Sun, 06 Feb 2022 19:16:53 +0000
Subject: [issue40174] HAVE_CLOCK_GETTIME not repected in pytime.c
In-Reply-To: <1585927809.98.0.29079570836.issue40174@roundup.psfhosted.org>
Message-ID: <1644175013.75.0.0221237485957.issue40174@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at gmail.com>:


----------
stage: patch review -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40174>
_______________________________________

From report at bugs.python.org  Sun Feb  6 14:32:47 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Feb 2022 19:32:47 +0000
Subject: [issue45412] [C API] Remove Py_OVERFLOWED(),
 Py_SET_ERRNO_ON_MATH_ERROR(), Py_ADJUST_ERANGE1()
In-Reply-To: <1633700351.81.0.101355063932.issue45412@roundup.psfhosted.org>
Message-ID: <1644175967.99.0.293821916442.issue45412@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29343
pull_request: https://github.com/python/cpython/pull/31171

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45412>
_______________________________________

From report at bugs.python.org  Sun Feb  6 14:39:53 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 06 Feb 2022 19:39:53 +0000
Subject: [issue46644] typing: remove callable() check from typing._type_check
In-Reply-To: <1644015777.96.0.875814750019.issue46644@roundup.psfhosted.org>
Message-ID: <1644176393.85.0.657469880386.issue46644@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

No, List[42] is not currently accepted.

>>> List[42]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/typing.py", line 318, in inner
    return func(*args, **kwds)
           ^^^^^^^^^^^^^^^^^^^
  File "/home/serhiy/py/cpython/Lib/typing.py", line 1127, in __getitem__
    params = tuple(_type_check(p, msg) for p in params)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/serhiy/py/cpython/Lib/typing.py", line 1127, in <genexpr>
    params = tuple(_type_check(p, msg) for p in params)
                   ^^^^^^^^^^^^^^^^^^^
  File "/home/serhiy/py/cpython/Lib/typing.py", line 184, in _type_check
    raise TypeError(f"{msg} Got {arg!r:.100}.")
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: Parameters to generic types must be types. Got 42.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46644>
_______________________________________

From report at bugs.python.org  Sun Feb  6 14:48:33 2022
From: report at bugs.python.org (Gregory Beauregard)
Date: Sun, 06 Feb 2022 19:48:33 +0000
Subject: [issue46644] typing: remove callable() check from typing._type_check
In-Reply-To: <1644015777.96.0.875814750019.issue46644@roundup.psfhosted.org>
Message-ID: <1644176913.78.0.269564558238.issue46644@roundup.psfhosted.org>


Gregory Beauregard <greg at greg.red> added the comment:

I'm referring to within type annotations, where this code path isn't used: try a: List[42]

This code path can show up in type aliases though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46644>
_______________________________________

From report at bugs.python.org  Sun Feb  6 14:54:48 2022
From: report at bugs.python.org (Emanuelle Pharand)
Date: Sun, 06 Feb 2022 19:54:48 +0000
Subject: [issue46654] urllib.request.urlopen doesn't handle UNC paths produced
 by pathlib's as_uri() (but can handle UNC paths with additional
 slashes)
In-Reply-To: <1644100059.97.0.383989396746.issue46654@roundup.psfhosted.org>
Message-ID: <1644177288.97.0.825301995643.issue46654@roundup.psfhosted.org>


Change by Emanuelle Pharand <pharandemanuelle2608 at gmail.com>:


----------
assignee:  -> docs at python
components: +2to3 (2.x to 3.x conversion tool), Argument Clinic, Build, C API, Cross-Build, Demos and Tools, Distutils, Documentation, Extension Modules, FreeBSD, IDLE, IO, Installation, Interpreter Core, Library (Lib), Parser, Regular Expressions, SSL, Subinterpreters, Tests, Tkinter, Unicode, Windows, XML, asyncio, ctypes, email, macOS
nosy: +Alex.Willmer, asvetlov, barry, docs at python, dstufft, eric.araujo, ezio.melotti, koobs, ladykraken, larry, lys.nikolaou, mrabarnett, ned.deily, pablogsal, paul.moore, r.david.murray, ronaldoussoren, steve.dower, terry.reedy, tim.golden, vstinner, yselivanov, zach.ware
type:  -> performance
versions: +Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46654>
_______________________________________

From report at bugs.python.org  Sun Feb  6 14:55:47 2022
From: report at bugs.python.org (Sam Roberts)
Date: Sun, 06 Feb 2022 19:55:47 +0000
Subject: [issue46660] datetime.timestamp() fails for naive-datetime values
 prior to the start of the epoch
In-Reply-To: <1644169895.69.0.613310626242.issue46660@roundup.psfhosted.org>
Message-ID: <1644177347.67.0.0486896987025.issue46660@roundup.psfhosted.org>


Sam Roberts <pythondotorg at roberts-family.com> added the comment:

this seems like an expected discrepancy because of a difference in the mechanism used for aware datatimes vs. naive datetimes, although I'm not sure I understand why the computation with naive datetimes uses the mktime() function rather than invoking datetime.timedelta.total_seconds() on a datetime difference.

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46660>
_______________________________________

From report at bugs.python.org  Sun Feb  6 14:56:15 2022
From: report at bugs.python.org (Sam Roberts)
Date: Sun, 06 Feb 2022 19:56:15 +0000
Subject: [issue46660] datetime.timestamp() fails for naive-datetime values
 prior to the start of the epoch
In-Reply-To: <1644169895.69.0.613310626242.issue46660@roundup.psfhosted.org>
Message-ID: <1644177375.58.0.794842317628.issue46660@roundup.psfhosted.org>


Change by Sam Roberts <pythondotorg at roberts-family.com>:


----------
resolution:  -> not a bug

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46660>
_______________________________________

From report at bugs.python.org  Sun Feb  6 15:12:51 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 06 Feb 2022 20:12:51 +0000
Subject: [issue46644] typing: remove callable() check from typing._type_check
In-Reply-To: <1644015777.96.0.875814750019.issue46644@roundup.psfhosted.org>
Message-ID: <1644178371.57.0.390676015989.issue46644@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

But it gives the same result.

What version of Python do you test with?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46644>
_______________________________________

From report at bugs.python.org  Sun Feb  6 15:14:07 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 06 Feb 2022 20:14:07 +0000
Subject: [issue46642] typing: tested TypeVar instance subclass TypeError is
 incidental
In-Reply-To: <1644011961.17.0.0152846458354.issue46642@roundup.psfhosted.org>
Message-ID: <1644178447.06.0.776305151118.issue46642@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The test is good. If we accidentally make a TypeVar instance subclassable, it will catch such error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46642>
_______________________________________

From report at bugs.python.org  Sun Feb  6 15:28:55 2022
From: report at bugs.python.org (Gregory Beauregard)
Date: Sun, 06 Feb 2022 20:28:55 +0000
Subject: [issue46644] typing: remove callable() check from typing._type_check
In-Reply-To: <1644015777.96.0.875814750019.issue46644@roundup.psfhosted.org>
Message-ID: <1644179335.08.0.163644871148.issue46644@roundup.psfhosted.org>


Gregory Beauregard <greg at greg.red> added the comment:

I compiled your PR to run it and was testing in 3.10 as well, but I was testing in a file with from __future__ import annotations unintentionally. I retract the comment. It turns out `list[42]` is okay though, which I suppose is more relevant going forward. My confusion here is sort of the crux of my problem with these runtime checks: they are inconsistently applied in different locations which is why callable() was causing a lot of bugs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46644>
_______________________________________

From report at bugs.python.org  Sun Feb  6 15:31:25 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Feb 2022 20:31:25 +0000
Subject: [issue46663] test_math test_cmath test_complex fails on Fedora
 Rawhide buildbots
Message-ID: <1644179485.62.0.212038403809.issue46663@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

PPC64LE Fedora Rawhide LTO 3.10:
https://buildbot.python.org/all/#/builders/674/builds/543

3 tests failed: test_cmath test_complex test_math

That's a GCC 12 regression: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104389

----------
components: Tests
messages: 412663
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_math test_cmath test_complex fails on Fedora Rawhide buildbots
versions: Python 3.10, Python 3.11, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46663>
_______________________________________

From report at bugs.python.org  Sun Feb  6 15:50:17 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Feb 2022 20:50:17 +0000
Subject: [issue46659] Deprecate locale.getdefaultlocale() function
In-Reply-To: <1644168794.44.0.0658923518102.issue46659@roundup.psfhosted.org>
Message-ID: <1644180617.28.0.161137814079.issue46659@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 04dd60e50cd3da48fd19cdab4c0e4cc600d6af30 by Victor Stinner in branch 'main':
bpo-46659: Update the test on the mbcs codec alias (GH-31168)
https://github.com/python/cpython/commit/04dd60e50cd3da48fd19cdab4c0e4cc600d6af30


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46659>
_______________________________________

From report at bugs.python.org  Sun Feb  6 15:51:32 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Feb 2022 20:51:32 +0000
Subject: [issue29240] PEP 540: Add a new UTF-8 mode
In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za>
Message-ID: <1644180692.91.0.763750026041.issue29240@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> New changeset 91106cd9ff2f321c0f60fbaa09fd46c80aa5c266 by Victor Stinner in branch 'master':
> bpo-29240: PEP 540: Add a new UTF-8 Mode (#855)
> https://github.com/python/cpython/commit/91106cd9ff2f321c0f60fbaa09fd46c80aa5c266

Oh, this change broke the mbcs alias on Windows and the test_codecs and test_site tests (2 tests!) missed the bug :-( I fixed it in:

New changeset 04dd60e50cd3da48fd19cdab4c0e4cc600d6af30 by Victor Stinner in branch 'main':
bpo-46659: Update the test on the mbcs codec alias (GH-31168)
https://github.com/python/cpython/commit/04dd60e50cd3da48fd19cdab4c0e4cc600d6af30

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29240>
_______________________________________

From report at bugs.python.org  Sun Feb  6 15:52:04 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Feb 2022 20:52:04 +0000
Subject: [issue46659] Deprecate locale.getdefaultlocale() function
In-Reply-To: <1644168794.44.0.0658923518102.issue46659@roundup.psfhosted.org>
Message-ID: <1644180724.26.0.419551971371.issue46659@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 06b8f1615b09099fae5c5393334b8716a4144d20 by Victor Stinner in branch 'main':
bpo-46659: test.support avoids locale.getdefaultlocale() (GH-31167)
https://github.com/python/cpython/commit/06b8f1615b09099fae5c5393334b8716a4144d20


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46659>
_______________________________________

From report at bugs.python.org  Sun Feb  6 15:54:32 2022
From: report at bugs.python.org (miss-islington)
Date: Sun, 06 Feb 2022 20:54:32 +0000
Subject: [issue46648] `test.test_urllib2.MiscTests.test_issue16464` started to
 fail
In-Reply-To: <1644061533.84.0.594817920054.issue46648@roundup.psfhosted.org>
Message-ID: <1644180872.34.0.136179770674.issue46648@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29344
pull_request: https://github.com/python/cpython/pull/31173

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46648>
_______________________________________

From report at bugs.python.org  Sun Feb  6 16:13:32 2022
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 06 Feb 2022 21:13:32 +0000
Subject: [issue46659] Deprecate locale.getdefaultlocale() function
In-Reply-To: <1644168794.44.0.0658923518102.issue46659@roundup.psfhosted.org>
Message-ID: <1644182012.66.0.541880460148.issue46659@roundup.psfhosted.org>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

> For these reasons, I propose to deprecate locale.getdefaultlocale(): setlocale(), getpreferredencoding() and getlocale() should be used instead.

Please see the discussion on https://bugs.python.org/issue43552: locale.getpreferredencoding() needs to be deprecated as well. Instead we should have a single locale.getencoding() as outlined there... perhaps in a separate ticket ?! Thanks.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46659>
_______________________________________

From report at bugs.python.org  Sun Feb  6 16:15:22 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Feb 2022 21:15:22 +0000
Subject: [issue46659] Deprecate locale.getdefaultlocale() function
In-Reply-To: <1644168794.44.0.0658923518102.issue46659@roundup.psfhosted.org>
Message-ID: <1644182122.15.0.130544537549.issue46659@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Please see the discussion on https://bugs.python.org/issue43552: locale.getpreferredencoding() needs to be deprecated as well. Instead we should have a single locale.getencoding() as outlined there... perhaps in a separate ticket ?! Thanks.

Yeah, I read this issue. But these things are too complicated :-) I prefer to move step by step.

Once locale.getencoding() (or a similar function) is added, we can update the deprecation message.

I hope to be able to deprecate getdefaultlocale() and to add such new function in Python 3.11.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46659>
_______________________________________

From report at bugs.python.org  Sun Feb  6 16:16:36 2022
From: report at bugs.python.org (Neil Schemenauer)
Date: Sun, 06 Feb 2022 21:16:36 +0000
Subject: [issue46657] Add mimalloc memory allocator
In-Reply-To: <1644158952.9.0.443530192167.issue46657@roundup.psfhosted.org>
Message-ID: <1644182196.19.0.164076804643.issue46657@roundup.psfhosted.org>


Neil Schemenauer <nas-python at arctrix.com> added the comment:

Thanks, I'm indeed interested.  Most credit goes to Christian for advancing this.

For the missing stdatomic.h, would it be appropriate to have an autoconfig check for it?  Can just disable mimalloc if it doesn't exist.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46657>
_______________________________________

From report at bugs.python.org  Sun Feb  6 16:20:42 2022
From: report at bugs.python.org (ov2k)
Date: Sun, 06 Feb 2022 21:20:42 +0000
Subject: [issue46664] PY_SSIZE_T_MAX is not an integer constant expression
Message-ID: <1644182442.72.0.928372209775.issue46664@roundup.psfhosted.org>


New submission from ov2k <ov2k.github at gmail.com>:

PY_SSIZE_T_MAX is currently defined in Include/pyport.h as: 

#define PY_SSIZE_T_MAX ((Py_ssize_t)(((size_t)-1)>>1))

This is not an integer constant expression, which means it can't be used in preprocessor conditionals.  For example: 

#if PY_SSIZE_T_MAX > UINT32_MAX

will fail to compile.  This was touched upon and ignored a long time ago: 

https://mail.python.org/archives/list/python-dev at python.org/thread/27X7LINL4UO7DAJE6J3IFQEZGUKAO4VL/

I think the best fix is to move the definition of PY_SSIZE_T_MAX (and PY_SSIZE_T_MIN) next to the definition of Py_ssize_t, and use the proper corresponding limit macro.  If Py_ssize_t is a typedef for ssize_t, then PY_SSIZE_T_MAX should be SSIZE_MAX.  If Py_ssize_t is a typedef for Py_intptr_t, then PY_SSIZE_T_MAX should be INTPTR_MAX.  There's a minor complication because Py_ssize_t can be defined in PC/pyconfig.h.  I'm not so familiar with the various Windows compilers, so I'm not sure what's best to do here.  I think __int64 has a corresponding _I64_MAX macro, and int obviously has INT_MAX.

----------
components: C API
messages: 412670
nosy: ov2k
priority: normal
severity: normal
status: open
title: PY_SSIZE_T_MAX is not an integer constant expression
type: compile error
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46664>
_______________________________________

From report at bugs.python.org  Sun Feb  6 16:37:17 2022
From: report at bugs.python.org (ov2k)
Date: Sun, 06 Feb 2022 21:37:17 +0000
Subject: [issue46664] PY_SSIZE_T_MAX is not an integer constant expression
In-Reply-To: <1644182442.72.0.928372209775.issue46664@roundup.psfhosted.org>
Message-ID: <1644183437.88.0.748182112456.issue46664@roundup.psfhosted.org>


Change by ov2k <ov2k.github at gmail.com>:


----------
type: compile error -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46664>
_______________________________________

From report at bugs.python.org  Sun Feb  6 16:43:55 2022
From: report at bugs.python.org (primexx)
Date: Sun, 06 Feb 2022 21:43:55 +0000
Subject: [issue46665] IDLE Windows shortcuts by default
Message-ID: <1644183835.83.0.808508877845.issue46665@roundup.psfhosted.org>


New submission from primexx <primexx at gmail.com>:

In IDLE on Windows, there are certain keyboard shortcut idiosycracies in the default configuration. 

For example,

redo is ctrl+shift+z (standard elsewhere) rather than ctrl+y (Microsoft's standard)

de-indenting is ctrl+[ rather than shift+tab (also affects multi-line selected behaviour)

Request: adjust the defaults based on OS platform and use windows style by default on windows

If this is a dupe I apologize. I tried to search for an existing issue but wasn't able to find any with the keywords i can think of

----------
assignee: terry.reedy
components: IDLE
messages: 412671
nosy: primexx, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE Windows shortcuts by default
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46665>
_______________________________________

From report at bugs.python.org  Sun Feb  6 16:52:47 2022
From: report at bugs.python.org (primexx)
Date: Sun, 06 Feb 2022 21:52:47 +0000
Subject: [issue46666] IDLE indent guide
Message-ID: <1644184367.6.0.417629376487.issue46666@roundup.psfhosted.org>


New submission from primexx <primexx at gmail.com>:

Request: support indent guide for IDLE in editor window (i.e. not interactive shell)

there appears to not be currently support for indent guides in idle

one take is that idle is meant for small scripts and one should seek out a more complex IDE if it gets to the point of needing indent lines https://stackoverflow.com/q/66231105

i think that there would still be value in indent lines even in IDLE. it is a popular IDE for beginners and even in short scripts there can still be sufficiently large indented blocks, relatively speaking. it doesn't take that much code for indent guides to become helpful.

----------
assignee: terry.reedy
components: IDLE
messages: 412672
nosy: primexx, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE indent guide
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46666>
_______________________________________

From report at bugs.python.org  Sun Feb  6 16:58:45 2022
From: report at bugs.python.org (Jonathan)
Date: Sun, 06 Feb 2022 21:58:45 +0000
Subject: [issue46667] SequenceMatcher & autojunk - false negative
Message-ID: <1644184725.54.0.128225003107.issue46667@roundup.psfhosted.org>


New submission from Jonathan <bugreports at lightpear.com>:

The following two strings are identical other than the text "UNIQUESTRING".
UNIQUESTRING is at the start of first and at the end of second.
Running the below gives the following output:


0.99830220713073
0.99830220713073
0.023769100169779286  # ratio

0.99830220713073
0.99830220713073
0.023769100169779286  # ratio

As you can see, Ratio is basically 0. Remove either of the UNIQUESTRING pieces and it goes up to 0.98 (correct)... Remove both and you get 1.0 (correct)


```
from difflib import SequenceMatcher

first = """
UNIQUESTRING
Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged. It was popularised in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing software like Aldus PageMaker including versions of Lorem Ipsum
"""


second = """

Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged. It was popularised in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing software like Aldus PageMaker including versions of Lorem Ipsum  UNIQUESTRING
"""

sm = SequenceMatcher(None, first, second, autojunk=False)
print(sm.real_quick_ratio())
print(sm.quick_ratio())
print(sm.ratio())

print()

sm2 = SequenceMatcher(None, second, first, autojunk=False)
print(sm2.real_quick_ratio())
print(sm2.quick_ratio())
print(sm2.ratio())

```

If I add `autojunk=False`, then I get a correct looking ratio (0.98...), however from my reading of the autojunk docs, UNIQUESTRING shouldn't be triggering it. Furthermore, looking in the code, as far as I can see autojunk is having no effect...

Autojunk considers these items to be "popular" in that string:
`{'n', 'p', 'a', 'h', 'e', 'u', 'I', 'r', 'k', 'g', 'y', 'm', 'c', 'd', 't', 'l', 'o', 's', ' ', 'i'}`

If I remove UNIQUESTRING from `first`, this is the autojunk popular set:
`{'c', 'p', 'a', 'u', 'r', 'm', 'k', 'g', 'I', 'd', ' ', 'o', 'h', 't', 'e', 'i', 'l', 's', 'y', 'n'}`

They're identical!

In both scenarios, `b2j` is also identical.

I don't pretend to understand what the module is doing in any detail, but this certainly seems like a false positive/negative.

Python 3.8.10

----------
components: Library (Lib)
messages: 412673
nosy: jonathan-lp
priority: normal
severity: normal
status: open
title: SequenceMatcher & autojunk - false negative
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46667>
_______________________________________

From report at bugs.python.org  Sun Feb  6 17:05:44 2022
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 06 Feb 2022 22:05:44 +0000
Subject: [issue46648] `test.test_urllib2.MiscTests.test_issue16464` flaky due
 to external connection
In-Reply-To: <1644061533.84.0.594817920054.issue46648@roundup.psfhosted.org>
Message-ID: <1644185144.07.0.850015736464.issue46648@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

The merged PRs disable the test without anything tracking fixing or re-re-enabling it.  Reopening & retitling this issue.

This specific test does not need to use an external server. That has nothing to do with what the purposes of the test is which is all around a content-length issue per https://bugs.python.org/issue16464

The appropriate fix is to have the test manage it's own http server on localhost in another thread or process.

We do not need to test it with https.

----------
nosy: +gregory.p.smith
resolution: fixed -> 
stage: resolved -> needs patch
status: closed -> open
title: `test.test_urllib2.MiscTests.test_issue16464` started to fail -> `test.test_urllib2.MiscTests.test_issue16464` flaky due to external connection
versions: +Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46648>
_______________________________________

From report at bugs.python.org  Sun Feb  6 17:06:38 2022
From: report at bugs.python.org (Jonathan)
Date: Sun, 06 Feb 2022 22:06:38 +0000
Subject: [issue46667] SequenceMatcher & autojunk - false negative
In-Reply-To: <1644184725.54.0.128225003107.issue46667@roundup.psfhosted.org>
Message-ID: <1644185198.1.0.989106398742.issue46667@roundup.psfhosted.org>


Jonathan <bugreports at lightpear.com> added the comment:

(Like the idiot I am, the example code is wrong. `autojunk` parameter should *not* be set for either of them to get the stated wrong results).

In place of "UNIQUESTRING", any unique 3 character string triggers it (QQQ, EEE, ZQU...). And in those cases you get a ratio of 0.008! (and 0.993 in the other direction!)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46667>
_______________________________________

From report at bugs.python.org  Sun Feb  6 17:08:12 2022
From: report at bugs.python.org (Jonathan)
Date: Sun, 06 Feb 2022 22:08:12 +0000
Subject: [issue46667] SequenceMatcher & autojunk - false negative
In-Reply-To: <1644184725.54.0.128225003107.issue46667@roundup.psfhosted.org>
Message-ID: <1644185292.81.0.524606929524.issue46667@roundup.psfhosted.org>


Jonathan <bugreports at lightpear.com> added the comment:

Gah. I mean 0.008 in both directions. I'm just going to be quiet now. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46667>
_______________________________________

From report at bugs.python.org  Sun Feb  6 17:09:17 2022
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 06 Feb 2022 22:09:17 +0000
Subject: [issue46654] urllib.request.urlopen doesn't handle UNC paths produced
 by pathlib's as_uri() (but can handle UNC paths with additional
 slashes)
In-Reply-To: <1644100059.97.0.383989396746.issue46654@roundup.psfhosted.org>
Message-ID: <1644185357.57.0.791334428473.issue46654@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
assignee: docs at python -> 
components:  -2to3 (2.x to 3.x conversion tool), Argument Clinic, Build, C API, Cross-Build, Demos and Tools, Distutils, Documentation, Extension Modules, FreeBSD, IDLE, IO, Installation, Interpreter Core, Parser, Regular Expressions, SSL, Subinterpreters, Tests, Tkinter, Unicode, Windows, XML, asyncio, ctypes, email, macOS
stage:  -> needs patch
type: performance -> behavior
versions:  -Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46654>
_______________________________________

From report at bugs.python.org  Sun Feb  6 17:42:41 2022
From: report at bugs.python.org (Tim Peters)
Date: Sun, 06 Feb 2022 22:42:41 +0000
Subject: [issue46667] SequenceMatcher & autojunk - false negative
In-Reply-To: <1644184725.54.0.128225003107.issue46667@roundup.psfhosted.org>
Message-ID: <1644187361.61.0.218680261016.issue46667@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

SequenceMatcher looks for the longest _contiguous_ match. "UNIQUESTRING" isn't the longest by far when autojunk is False, but is the longest when autojunk is True. All those bpopular characters then effectively prevent finding a longer match than 'QUESTR' (capital 'I" is also in bpopular) directly.

The effects of autojunk can be surprising, and it would have been better if it were False by default. But I don't see anything unexpected here. Learn from experience and force it to False yourself ;-) BTW, it was introduced as a way to greatly speed comparing files of code, viewing them as sequences of lines. In that context, autojunk is rarely surprising and usually helpful. But it more often backfires when comparing strings (viewed as sequences of characters) :-(

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46667>
_______________________________________

From report at bugs.python.org  Sun Feb  6 18:05:41 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 06 Feb 2022 23:05:41 +0000
Subject: [issue46644] typing: remove callable() check from typing._type_check
In-Reply-To: <1644015777.96.0.875814750019.issue46644@roundup.psfhosted.org>
Message-ID: <1644188741.6.0.80201893266.issue46644@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/issue46644>
_______________________________________

From report at bugs.python.org  Sun Feb  6 18:06:49 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Feb 2022 23:06:49 +0000
Subject: [issue46668] encodings: the "mbcs" alias doesn't work
Message-ID: <1644188809.05.0.861398707442.issue46668@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

While working on bpo-46659, I found a bug in the encodings "mbcs" alias. Even if the function has 2 tests (in test_codecs and test_site), both tests missed the bug :-(

I fixed the alias with this change:
---
commit 04dd60e50cd3da48fd19cdab4c0e4cc600d6af30
Author: Victor Stinner <vstinner at python.org>
Date:   Sun Feb 6 21:50:09 2022 +0100

    bpo-46659: Update the test on the mbcs codec alias (GH-31168)
    
    encodings registers the _alias_mbcs() codec search function before
    the search_function() codec search function. Previously, the
    _alias_mbcs() was never used.
    
    Fix the test_codecs.test_mbcs_alias() test: use the current ANSI code
    page, not a fake ANSI code page number.
    
    Remove the test_site.test_aliasing_mbcs() test: the alias is now
    implemented in the encodings module, no longer in the site module.
---

But Eryk found two bugs:

"""


This was never true before. With 1252 as my ANSI code page, I checked codecs.lookup('cp1252') in 2.7, 3.4, 3.5, 3.6, 3.9, and 3.10, and none of them return the "mbcs" encoding. It's not equivalent, and not supposed to be. The implementation of "cp1252" should be cross-platform, regardless of whether we're on a Windows system with 1252 as the ANSI code page, as opposed to a Windows system with some other ANSI code page, or a Linux or macOS system.

The differences are that "mbcs" maps every byte, whereas our code-page encodings do not map undefined bytes, and the "replace" handler of "mbcs" uses a best-fit mapping (e.g. "?" -> "a") when encoding text, instead of mapping all undefined characters to "?".
"""

and my new test fails if PYTHONUTF8=1 env var is set:

"""
This will fail if PYTHONUTF8 is set in the environment, because it overrides getpreferredencoding(False) and _get_locale_encoding().
"""

The code for the "mbcs" alias changed at lot between Python 3.5 and 3.7.

In Python 3.5, site module:
---
def aliasmbcs():
    """On Windows, some default encodings are not provided by Python,
    while they are always available as "mbcs" in each locale. Make
    them usable by aliasing to "mbcs" in such a case."""
    if sys.platform == 'win32':
        import _bootlocale, codecs                        
        enc = _bootlocale.getpreferredencoding(False)
        if enc.startswith('cp'):            # "cp***" ?
            try:
                codecs.lookup(enc)
            except LookupError:
                import encodings
                encodings._cache[enc] = encodings._unknown
                encodings.aliases.aliases[enc] = 'mbcs'
---

In Python 3.6, encodings module:
---
(...)
codecs.register(search_function)

if sys.platform == 'win32':
    def _alias_mbcs(encoding):
        try:
            import _bootlocale
            if encoding == _bootlocale.getpreferredencoding(False):
                import encodings.mbcs
                return encodings.mbcs.getregentry()
        except ImportError:
            # Imports may fail while we are shutting down
            pass

    codecs.register(_alias_mbcs)
---

Python 3.7, encodings module:
---
(...)
codecs.register(search_function)

if sys.platform == 'win32':
    def _alias_mbcs(encoding):
        try:
            import _winapi
            ansi_code_page = "cp%s" % _winapi.GetACP()
            if encoding == ansi_code_page:
                import encodings.mbcs
                return encodings.mbcs.getregentry()
        except ImportError:
            # Imports may fail while we are shutting down
            pass

    codecs.register(_alias_mbcs)
---

The Python 3.6 and 3.7 "codecs.register(_alias_mbcs)" doesn't work because "search_function()" is tested before and it works for "cpXXX" encodings. My changes changes the order in which codecs search functions are registered: first the MBCS alias, then the encodings search_function().

In Python 3.5, the alias was only created if Python didn't support the code page.

----------
components: Library (Lib)
messages: 412678
nosy: vstinner
priority: normal
severity: normal
status: open
title: encodings: the "mbcs" alias doesn't work
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46668>
_______________________________________

From report at bugs.python.org  Sun Feb  6 18:08:03 2022
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 06 Feb 2022 23:08:03 +0000
Subject: [issue46657] Add mimalloc memory allocator
In-Reply-To: <1644158952.9.0.443530192167.issue46657@roundup.psfhosted.org>
Message-ID: <1644188883.76.0.744306065018.issue46657@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

We have an autoconf check for stdatomic.h. The test even verifies that a program with atomic_load_explicit() compiles and links.

How do we want to use mimalloc in the future? Is it going to stay optional in 3.12? Then the default setting for --with-mimalloc should depend on presence of stdatomic.h. Do we want to make it mandatory for GC heap walking and nogil? Then --with-mimalloc should default to "yes" and configure should abort when stdatomic.h is missing.

I'm leaning towards --with-mimalloc=yes. It will make users aware that they need a compiler with atomics:

configure: error: --with-mimalloc requires stdatomic.h. Update your compiler or rebuild with --without-mimalloc. Python 3.12 will require stdatomic.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46657>
_______________________________________

From report at bugs.python.org  Sun Feb  6 18:10:38 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Feb 2022 23:10:38 +0000
Subject: [issue46668] encodings: the "mbcs" alias doesn't work
In-Reply-To: <1644188809.05.0.861398707442.issue46668@roundup.psfhosted.org>
Message-ID: <1644189038.54.0.788426976875.issue46668@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The alias was created in 2003 to fix bpo-671666:
---
commit 4eab486476c0082087a8460a5ab1064e64cc1a6b
Author: Martin v. L?wis <martin at v.loewis.de>
Date:   Mon Mar 3 09:34:01 2003 +0000

    Patch #671666: Alias ANSI code page to "mbcs".
---

In 2003, bpo-671666 was created because Python didn't support "cp932" encoding, whereas the MBCS codec was available and could used directly since cp932 was the ANSI code page.

The alias allows to support the ANSI code 932 without implement it.

But Python got a "cp932" codec the year after:
---
commit 3e2a30692085d32ac63f72b35da39158a471fc68
Author: Hye-Shik Chang <hyeshik at gmail.com>
Date:   Sat Jan 17 14:29:29 2004 +0000

    Add CJK codecs support as discussed on python-dev. (SF #873597)
    
    Several style fixes are suggested by Martin v. Loewis and
    Marc-Andre Lemburg. Thanks!
---

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46668>
_______________________________________

From report at bugs.python.org  Sun Feb  6 18:10:42 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 06 Feb 2022 23:10:42 +0000
Subject: [issue46661] Duplicat deprecation warnings in docs for asyncio
In-Reply-To: <1644173025.54.0.0182116442771.issue46661@roundup.psfhosted.org>
Message-ID: <1644189042.7.0.747349420462.issue46661@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Kumar are you interested in fixing this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46661>
_______________________________________

From report at bugs.python.org  Sun Feb  6 18:12:51 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 06 Feb 2022 23:12:51 +0000
Subject: [issue46669] Add types.Self
Message-ID: <1644189171.85.0.34470950762.issue46669@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

Typeshed now has a nice self-describing type variable to annotate context managers:

Self = TypeVar('Self')

def __enter__(self: Self) -> Self:
    return self

It would be nice to have that in the standard library types module as well.

----------
messages: 412682
nosy: Jelle Zijlstra, gvanrossum, rhettinger
priority: normal
severity: normal
status: open
title: Add types.Self
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46669>
_______________________________________

From report at bugs.python.org  Sun Feb  6 18:13:19 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Feb 2022 23:13:19 +0000
Subject: [issue46668] encodings: the "mbcs" alias doesn't work
In-Reply-To: <1644188809.05.0.861398707442.issue46668@roundup.psfhosted.org>
Message-ID: <1644189199.29.0.83544736982.issue46668@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Python 3.11 supports the 40 code pages:

* 037
* 273
* 424
* 437
* 500
* 720
* 737
* 775
* 850
* 852
* 855
* 856
* 857
* 858
* 860
* 861
* 862
* 863
* 864
* 865
* 866
* 869
* 874
* 875
* 932
* 949
* 950
* 1006
* 1026
* 1125
* 1140
* 1250
* 1251
* 1252
* 1253
* 1254
* 1255
* 1256
* 1257
* 1258

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46668>
_______________________________________

From report at bugs.python.org  Sun Feb  6 18:14:04 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Sun, 06 Feb 2022 23:14:04 +0000
Subject: [issue46669] Add types.Self
In-Reply-To: <1644189171.85.0.34470950762.issue46669@roundup.psfhosted.org>
Message-ID: <1644189244.1.0.17513240793.issue46669@roundup.psfhosted.org>


Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:

PEP 673 (which was accepted) adds typing.Self already. bpo-46534 tracks implementing it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46669>
_______________________________________

From report at bugs.python.org  Sun Feb  6 18:16:00 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 06 Feb 2022 23:16:00 +0000
Subject: [issue46655] typing.TypeAlias is not in the list of allowed plain
 _SpecialForm typeforms
In-Reply-To: <1644132606.43.0.5970530565.issue46655@roundup.psfhosted.org>
Message-ID: <1644189360.57.0.223048959549.issue46655@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Looks like the more likely use case would be PEP 563:

from __future__ import annotations
from typing import TypeAlias, get_type_hints

import typing

class C:
    a: TypeAlias = int

print(get_type_hints(C))


This prints

Traceback (most recent call last):
  File "C:\Users\gvanrossum\cpython\t.py", line 9, in <module>
    print(get_type_hints(C))
  File "C:\Users\gvanrossum\AppData\Local\Programs\Python\Python310\lib\typing.py", line 1808, in get_type_hints
    value = _eval_type(value, base_globals, base_locals)
  File "C:\Users\gvanrossum\AppData\Local\Programs\Python\Python310\lib\typing.py", line 326, in _eval_type
    return t._evaluate(globalns, localns, recursive_guard)
  File "C:\Users\gvanrossum\AppData\Local\Programs\Python\Python310\lib\typing.py", line 690, in _evaluate
    type_ = _type_check(
  File "C:\Users\gvanrossum\AppData\Local\Programs\Python\Python310\lib\typing.py", line 171, in _type_check
    raise TypeError(f"Plain {arg} is not valid as type argument")

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46655>
_______________________________________

From report at bugs.python.org  Sun Feb  6 18:16:28 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 06 Feb 2022 23:16:28 +0000
Subject: [issue46655] typing.TypeAlias is not in the list of allowed plain
 _SpecialForm typeforms
In-Reply-To: <1644132606.43.0.5970530565.issue46655@roundup.psfhosted.org>
Message-ID: <1644189388.36.0.18510534768.issue46655@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset 77b025be4a4cd5a3bfc1b1af560cc57e8e956c98 by Gregory Beauregard in branch 'main':
bpo-46655: allow stringized TypeAlias with get_type_hints (GH-31156)
https://github.com/python/cpython/commit/77b025be4a4cd5a3bfc1b1af560cc57e8e956c98


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46655>
_______________________________________

From report at bugs.python.org  Sun Feb  6 18:17:16 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Feb 2022 23:17:16 +0000
Subject: [issue46668] encodings: the "mbcs" alias doesn't work
In-Reply-To: <1644188809.05.0.861398707442.issue46668@roundup.psfhosted.org>
Message-ID: <1644189436.64.0.086371820763.issue46668@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +29345
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31174

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46668>
_______________________________________

From report at bugs.python.org  Sun Feb  6 18:18:59 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Feb 2022 23:18:59 +0000
Subject: [issue46659] Deprecate locale.getdefaultlocale() function
In-Reply-To: <1644168794.44.0.0658923518102.issue46659@roundup.psfhosted.org>
Message-ID: <1644189539.15.0.649484683771.issue46659@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> New changeset 04dd60e50cd3da48fd19cdab4c0e4cc600d6af30 by Victor Stinner in branch 'main':
> bpo-46659: Update the test on the mbcs codec alias (GH-31168)

This change is not correct, I created bpo-46668 to fix it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46659>
_______________________________________

From report at bugs.python.org  Sun Feb  6 18:19:56 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Feb 2022 23:19:56 +0000
Subject: [issue46648] `test.test_urllib2.MiscTests.test_issue16464` flaky due
 to external connection
In-Reply-To: <1644061533.84.0.594817920054.issue46648@roundup.psfhosted.org>
Message-ID: <1644189596.5.0.878972475683.issue46648@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46648>
_______________________________________

From report at bugs.python.org  Sun Feb  6 18:34:47 2022
From: report at bugs.python.org (Gregory Beauregard)
Date: Sun, 06 Feb 2022 23:34:47 +0000
Subject: [issue46655] typing.TypeAlias is not in the list of allowed plain
 _SpecialForm typeforms
In-Reply-To: <1644132606.43.0.5970530565.issue46655@roundup.psfhosted.org>
Message-ID: <1644190487.47.0.730425507263.issue46655@roundup.psfhosted.org>


Change by Gregory Beauregard <greg at greg.red>:


----------
pull_requests: +29346
pull_request: https://github.com/python/cpython/pull/31175

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46655>
_______________________________________

From report at bugs.python.org  Sun Feb  6 18:39:40 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Feb 2022 23:39:40 +0000
Subject: [issue43882] [security] CVE-2022-0391: urllib.parse should sanitize
 urls containing ASCII newline and tabs.
In-Reply-To: <1618774620.3.0.412025280445.issue43882@roundup.psfhosted.org>
Message-ID: <1644190780.05.0.642554585207.issue43882@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

CVE-2022-0391 has been assigned to this vulnerability.

----------
nosy: +vstinner
title: [security] urllib.parse should sanitize urls containing ASCII newline and tabs. -> [security] CVE-2022-0391: urllib.parse should sanitize urls containing ASCII newline and tabs.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43882>
_______________________________________

From report at bugs.python.org  Sun Feb  6 18:49:34 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 06 Feb 2022 23:49:34 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644191374.42.0.217413311034.issue46323@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:

@hydroflask

It does not show impressive performance enhancement, so I decided not to change it
See PR 31138

----------
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Sun Feb  6 18:52:36 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Feb 2022 23:52:36 +0000
Subject: [issue46670] Build Python with -Wundef: don't use undefined macros
Message-ID: <1644191556.12.0.192524677903.issue46670@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Building Python with "gcc -Wundef" emits many warnings about usage of undefined macros. If a macro is not defined, it is equal to 0.

The problem is that a macro can be undefined because of a missing #include, or because of a typo in its name, or because "#ifdef MACRO" should be used instead of "#if MACRO". It can hide bugs.

I plan to fix these warnings.

----------
components: Build
messages: 412690
nosy: vstinner
priority: normal
severity: normal
status: open
title: Build Python with -Wundef: don't use undefined macros
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46670>
_______________________________________

From report at bugs.python.org  Sun Feb  6 19:01:06 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Feb 2022 00:01:06 +0000
Subject: [issue46670] Build Python with -Wundef: don't use undefined macros
In-Reply-To: <1644191556.12.0.192524677903.issue46670@roundup.psfhosted.org>
Message-ID: <1644192066.86.0.361329421689.issue46670@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +29347
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31176

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46670>
_______________________________________

From report at bugs.python.org  Sun Feb  6 19:04:21 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Feb 2022 00:04:21 +0000
Subject: [issue46670] Build Python with -Wundef: don't use undefined macros
In-Reply-To: <1644191556.12.0.192524677903.issue46670@roundup.psfhosted.org>
Message-ID: <1644192261.09.0.0089101515473.issue46670@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29348
pull_request: https://github.com/python/cpython/pull/31177

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46670>
_______________________________________

From report at bugs.python.org  Sun Feb  6 19:06:39 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Feb 2022 00:06:39 +0000
Subject: [issue46670] Build Python with -Wundef: don't use undefined macros
In-Reply-To: <1644191556.12.0.192524677903.issue46670@roundup.psfhosted.org>
Message-ID: <1644192399.42.0.365800279084.issue46670@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29349
pull_request: https://github.com/python/cpython/pull/31178

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46670>
_______________________________________

From report at bugs.python.org  Sun Feb  6 19:09:10 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Feb 2022 00:09:10 +0000
Subject: [issue46670] Build Python with -Wundef: don't use undefined macros
In-Reply-To: <1644191556.12.0.192524677903.issue46670@roundup.psfhosted.org>
Message-ID: <1644192550.37.0.0189033960562.issue46670@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29350
pull_request: https://github.com/python/cpython/pull/31179

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46670>
_______________________________________

From report at bugs.python.org  Sun Feb  6 19:10:02 2022
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 07 Feb 2022 00:10:02 +0000
Subject: [issue46668] encodings: the "mbcs" alias doesn't work
In-Reply-To: <1644188809.05.0.861398707442.issue46668@roundup.psfhosted.org>
Message-ID: <1644192602.69.0.606277256868.issue46668@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> The Python 3.6 and 3.7 "codecs.register(_alias_mbcs)" doesn't work 
> because "search_function()" is tested before and it works for "cpXXX" 
> encodings.

Isn't the 3.6-3.10 ordering of search_function() and _alias_mbcs() correct as a fallback? In this case, Python doesn't support a cross-platform encoding for the code page. That's why the old implementation of test_mbcs_alias() mocked _winapi.GetACP() to return 123 and then checked that looking up 'cp123' returned the "mbcs" codec.

I'd actually prefer to extend this by implementing _winapi.GetOEMCP() and using "oem" as a fallback for that case.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46668>
_______________________________________

From report at bugs.python.org  Sun Feb  6 19:19:02 2022
From: report at bugs.python.org (hydroflask)
Date: Mon, 07 Feb 2022 00:19:02 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644193142.35.0.204848941764.issue46323@roundup.psfhosted.org>


hydroflask <hydroflask at yqxmail.com> added the comment:

@corona10

Thank you for looking into it.

The benchmark you did is not reflective of my use-case. I have a codebase that I have completely converted into a C extension using mypyc. So the ctypes callback does not call into interpreted Python code but actually another C-extension. I have annotated types aggressively to avoid invoking malloc(). In this use-case the extra overhead from the tuple allocation would be significant.

Additionally your benchmark may not be as micro as intended. You call some math in the callback function which may have made the savings from avoiding the tuple allocation seem more like noise.

Since you already did the work I still think it's worth putting it in since PyObject_Vectorcall is an established API and it would have been used anyway if this were written from scratch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Sun Feb  6 19:20:58 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 07 Feb 2022 00:20:58 +0000
Subject: [issue46665] IDLE Windows shortcuts by default
In-Reply-To: <1644183835.83.0.808508877845.issue46665@roundup.psfhosted.org>
Message-ID: <1644193258.88.0.107430395785.issue46665@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I wish it were otherwise, but configuration defaults cannot be changed as some people would not like it and it would badly interact with custom configurations.  We can add new themes and keysets, but that should be very rare.  We can consider adding bindings, though clashes with customizations are possible.

Do you have any documentation for you claims?  My impression is that Microsoft occasionally makes UI changes, so that 'Microsoft Standard' is a bit of a joke.  Maybe keys are an exception.

Ctrl+y is *not* recognized in Notepad.  ctrl+shift+z acts the same as ctrl_z.  Notepad++ recognizes both and lists both for Dedent in its
Scintilla mapper.  If it is not in use in the Windows keyset, adding it could be considered.

Before the first character on a line, in the absence of a selection, tab and backspace indent and dedent.  When there is a selection, tab and ctrl-] indent the selections and ctrl-[ dedents.  Shift-tab acts the same as tab.  I believe that tk, at least on Windows, does not recognize shift-tab as different from tab.  I know that this is true for some named keys, such as Enter.  (This stuff needs to be documented.)  Shift-tab works as you (and I) want in Notepad++, so this is not a Windows issue.

----------
stage:  -> needs patch
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/issue46665>
_______________________________________

From report at bugs.python.org  Sun Feb  6 19:22:26 2022
From: report at bugs.python.org (Nnarol)
Date: Mon, 07 Feb 2022 00:22:26 +0000
Subject: [issue46671] "ValueError: min() arg is an empty sequence" is wrong
 (builtins.min/max)
Message-ID: <1644193346.19.0.843293726099.issue46671@roundup.psfhosted.org>


New submission from Nnarol <arpeger at gmail.com>:

Incorrect error message by min_max(): "ValueError: min() arg is an empty sequence" when using the form

    min(iterable, *[, default=obj, key=func]) -> value

and "iterable" is empty, like so:

    min([])

or:

    min(set())

"Sequence" is referred to, even though the function accepts any iterable. E.g. if a different type of collection, such as a set was provided by the user, "sequence" is still printed.

I propose to rephrase the error to "iterable argument is empty", to reflect actual behavior and be in line with the function's documented interface.

"arg" also does not name either any specific variable in C code or a parameter in user-facing documentation. Such an abbreviation is not used by the function's other error messages either, which simply write "argument" or "arguments" in free text, as appropriate in the given context.

Unlike for the error "max expected at least 1 argument, got 0", the above scenario's test does not include matching of the error string. This is probably the reason this was not noticed before. It would be nice to make the test more specific.

The issue seems trivial, but I am not familiar with the CPython project's policy on whether to treat messages of errors, printed on stderr as an interface, in which case, the change would be backwards-incompatible.
Definitely a decision to be made.

----------
components: Library (Lib)
messages: 412694
nosy: Nnarol
priority: normal
severity: normal
status: open
title: "ValueError: min() arg is an empty sequence" is wrong (builtins.min/max)
type: behavior
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46671>
_______________________________________

From report at bugs.python.org  Sun Feb  6 19:25:48 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Feb 2022 00:25:48 +0000
Subject: [issue46670] Build Python with -Wundef: don't use undefined macros
In-Reply-To: <1644191556.12.0.192524677903.issue46670@roundup.psfhosted.org>
Message-ID: <1644193548.15.0.536855085167.issue46670@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 16f96a4cf9ab1e91e6e8e18232378bc4b42bb796 by Victor Stinner in branch 'main':
bpo-46670: Remove unused get_frame_state() function (GH-31177)
https://github.com/python/cpython/commit/16f96a4cf9ab1e91e6e8e18232378bc4b42bb796


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46670>
_______________________________________

From report at bugs.python.org  Sun Feb  6 19:27:01 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Feb 2022 00:27:01 +0000
Subject: [issue46670] Build Python with -Wundef: don't use undefined macros
In-Reply-To: <1644191556.12.0.192524677903.issue46670@roundup.psfhosted.org>
Message-ID: <1644193621.86.0.259328715827.issue46670@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 097f74a5a37e2a8a26d529cede456ede7011b66f by Victor Stinner in branch 'main':
bpo-46670: Define all macros for stringlib (GH-31176)
https://github.com/python/cpython/commit/097f74a5a37e2a8a26d529cede456ede7011b66f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46670>
_______________________________________

From report at bugs.python.org  Sun Feb  6 19:33:49 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Feb 2022 00:33:49 +0000
Subject: [issue46670] Build Python with -Wundef: don't use undefined macros
In-Reply-To: <1644191556.12.0.192524677903.issue46670@roundup.psfhosted.org>
Message-ID: <1644194029.38.0.0659915976711.issue46670@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29351
pull_request: https://github.com/python/cpython/pull/31180

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46670>
_______________________________________

From report at bugs.python.org  Sun Feb  6 19:35:09 2022
From: report at bugs.python.org (Nnarol)
Date: Mon, 07 Feb 2022 00:35:09 +0000
Subject: [issue46671] "ValueError: min() arg is an empty sequence" is wrong
 (builtins.min/max)
In-Reply-To: <1644193346.19.0.843293726099.issue46671@roundup.psfhosted.org>
Message-ID: <1644194109.96.0.429956930819.issue46671@roundup.psfhosted.org>


Change by Nnarol <arpeger at gmail.com>:


----------
keywords: +patch
pull_requests: +29352
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31181

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46671>
_______________________________________

From report at bugs.python.org  Sun Feb  6 19:46:54 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Feb 2022 00:46:54 +0000
Subject: [issue46670] Build Python with -Wundef: don't use undefined macros
In-Reply-To: <1644191556.12.0.192524677903.issue46670@roundup.psfhosted.org>
Message-ID: <1644194814.94.0.115048676646.issue46670@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset b556f53785cb9ad8cc088ad8c10efee91fe3da58 by Victor Stinner in branch 'main':
bpo-46670: Test if a macro is defined, not its value (GH-31178)
https://github.com/python/cpython/commit/b556f53785cb9ad8cc088ad8c10efee91fe3da58


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46670>
_______________________________________

From report at bugs.python.org  Sun Feb  6 19:50:02 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 07 Feb 2022 00:50:02 +0000
Subject: [issue46666] IDLE Add indent guide
In-Reply-To: <1644184367.6.0.417629376487.issue46666@roundup.psfhosted.org>
Message-ID: <1644195002.7.0.767044757955.issue46666@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

[Please just select the current development version.  Others can be marked if and when backported.  3.8 and before only get security fixes.  Same for 3.9 after about next May 31.]

Please explain exactly what you want and rewrite something like the following.
if a:
    if b:
        if c:
            pass
    if d:
        pass

IDLE's code context feature (Options menu) could be considered an indent guide.  In some ways, it is better.


What you see in the editor is what is saved (including when running), so any non-code additions have to be removed first.

----------
stage:  -> test needed
title: IDLE indent guide -> IDLE Add indent guide
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/issue46666>
_______________________________________

From report at bugs.python.org  Sun Feb  6 19:52:23 2022
From: report at bugs.python.org (Nnarol)
Date: Mon, 07 Feb 2022 00:52:23 +0000
Subject: [issue46671] "ValueError: min() arg is an empty sequence" is wrong
 (builtins.min/max)
In-Reply-To: <1644193346.19.0.843293726099.issue46671@roundup.psfhosted.org>
Message-ID: <1644195143.42.0.128284214645.issue46671@roundup.psfhosted.org>


Change by Nnarol <arpeger at gmail.com>:


----------
components: +Interpreter Core -Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46671>
_______________________________________

From report at bugs.python.org  Sun Feb  6 20:03:55 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 07 Feb 2022 01:03:55 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644195835.31.0.301672164009.issue46323@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:

@hydroflask

I am one of the big fans of applying vectorcall :)

> The benchmark you did is not reflective of my use-case. I have a codebase that I have completely converted into a C extension using mypyc.

Can you provide me a minimal benchmarkable script(if you need to include mypyc it's okay) to persuade other core dev?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Sun Feb  6 20:33:56 2022
From: report at bugs.python.org (primexx)
Date: Mon, 07 Feb 2022 01:33:56 +0000
Subject: [issue46665] IDLE Windows shortcuts by default
In-Reply-To: <1644183835.83.0.808508877845.issue46665@roundup.psfhosted.org>
Message-ID: <1644197636.8.0.24185336214.issue46665@roundup.psfhosted.org>


primexx <primexx at gmail.com> added the comment:

> I wish it were otherwise, but configuration defaults cannot be changed as some people would not like it and it would badly interact with custom configurations.

that is a good point. perhaps just adding alternate keysets. this is clearly not a high priority issue since it can be changed manually.

> Do you have any documentation for you claims?

for redo: https://support.microsoft.com/en-us/windows/keyboard-shortcuts-in-windows-dcc61a57-8ff0-cffe-9796-cb9706c75eec

shift + tab does a lot of different things depending on context (e.g. the link above, and there are 3 documented behaviour in word alone https://support.microsoft.com/en-us/office/keyboard-shortcuts-in-word-95ef89dd-7142-4b50-afb2-f762f663ceb2). however, i just tried and it does de-indent in word 365 with just a simple text selection (i.e. plain paragraph, not inside tables, etc.). also tried the same thing in google docs and it also de-indents text selection. i think you could be correct that  this is not actually windows specific, it does seem to be fairly common behaviour in the context of text editors anyway.

> Ctrl+y is *not* recognized in Notepad.

yeah notepad is all sorts of messed up. it does not have the usual ctrl+z behaviour either.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46665>
_______________________________________

From report at bugs.python.org  Sun Feb  6 20:35:55 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 07 Feb 2022 01:35:55 +0000
Subject: [issue46611] Improve coverage of `__instancecheck__` and
 `__subclasscheck__` methods in `typing.py`
In-Reply-To: <1643810452.7.0.438267754834.issue46611@roundup.psfhosted.org>
Message-ID: <1644197755.29.0.181353051664.issue46611@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset 067c03bf40d13393209f0138fa9c4d5980c4ff8a by Nikita Sobolev in branch 'main':
bpo-46611: add coverage to instance and class checks in `typing.py` (GH-31078)
https://github.com/python/cpython/commit/067c03bf40d13393209f0138fa9c4d5980c4ff8a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46611>
_______________________________________

From report at bugs.python.org  Sun Feb  6 20:44:46 2022
From: report at bugs.python.org (primexx)
Date: Mon, 07 Feb 2022 01:44:46 +0000
Subject: [issue46666] IDLE Add indent guide
In-Reply-To: <1644184367.6.0.417629376487.issue46666@roundup.psfhosted.org>
Message-ID: <1644198286.99.0.284039335786.issue46666@roundup.psfhosted.org>


primexx <primexx at gmail.com> added the comment:

> Please just select the current development version.  Others can be marked if and when backported

oh sorry about  that!

> Please explain exactly what you want

these dotted lines in the attached screenshot

> What you see in the editor is what is saved (including when running), so any non-code additions have to be removed first.

yes, this would be a pure visual element in the editor, not modifying the actual code

> IDLE's code context feature (Options menu) could be considered an indent guide.  In some ways, it is better.

it is very useful indeed, but not quite the same as a persistent visual indicator imho

thanks!

----------
Added file: https://bugs.python.org/file50608/npp-indent-guide.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46666>
_______________________________________

From report at bugs.python.org  Sun Feb  6 20:59:39 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 07 Feb 2022 01:59:39 +0000
Subject: [issue46589] Improve documentation for typing._GenericAlias
In-Reply-To: <1643572528.41.0.126032041698.issue46589@roundup.psfhosted.org>
Message-ID: <1644199179.75.0.368059875939.issue46589@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset a335d98f19b7fa66159d12932cc9a05eb2d8395f by Matthew Rahtz in branch 'main':
bpo-46589: Improve documentation for typing._GenericAlias (GH-31026)
https://github.com/python/cpython/commit/a335d98f19b7fa66159d12932cc9a05eb2d8395f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46589>
_______________________________________

From report at bugs.python.org  Sun Feb  6 21:13:00 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 07 Feb 2022 02:13:00 +0000
Subject: [issue44796] Add __parameters__ and __getitem__ in TypeVar and
 ParamSpec
In-Reply-To: <1627738289.78.0.80035642919.issue44796@roundup.psfhosted.org>
Message-ID: <1644199980.46.0.833719727422.issue44796@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Super subtle stuff. Tonight I do not have time to really dive into this, but I think Serhiy is on to something. KJ or Jelle, do you have the guts to dive in here?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44796>
_______________________________________

From report at bugs.python.org  Sun Feb  6 22:06:06 2022
From: report at bugs.python.org (Mike Lissner)
Date: Mon, 07 Feb 2022 03:06:06 +0000
Subject: [issue43882] [security] CVE-2022-0391: urllib.parse should sanitize
 urls containing ASCII newline and tabs.
In-Reply-To: <1618774620.3.0.412025280445.issue43882@roundup.psfhosted.org>
Message-ID: <1644203166.54.0.0392477613923.issue43882@roundup.psfhosted.org>


Mike Lissner <mlissner at michaeljaylissner.com> added the comment:

Looks like that CVE isn't public yet.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0391

Any chance I can get access (I originally reported this vuln.). My email is mike at free.law, if it's possible and my email is needed.

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43882>
_______________________________________

From report at bugs.python.org  Sun Feb  6 22:08:26 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 07 Feb 2022 03:08:26 +0000
Subject: [issue45955] Calling read() on HTTPError may cause KeyError in
 tempfile
In-Reply-To: <1638385925.39.0.609829377944.issue45955@roundup.psfhosted.org>
Message-ID: <1644203306.18.0.745610542034.issue45955@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/issue45955>
_______________________________________

From report at bugs.python.org  Sun Feb  6 22:14:19 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 07 Feb 2022 03:14:19 +0000
Subject: [issue46666] IDLE Add indent guide
In-Reply-To: <1644184367.6.0.417629376487.issue46666@roundup.psfhosted.org>
Message-ID: <1644203659.89.0.467418518434.issue46666@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I loaded a .py file into N++ and see them.  Under 3 x, there are clearly separate minidots.  Under 10x, the dots are hardly visible.  They are not characters in the text (cannot be copied) but a special manipulation of the column of pixels 'between' spaces.  This must be a built-in feature of to the text widget.  I suspect it involves special subpixel manipulation, perhaps requiring information from the monitor.  AFAIK, Tk widgets do not have this feature.  Unless there is a unicode char consisting of light dots on the very edge, we cannot even simulate this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46666>
_______________________________________

From report at bugs.python.org  Sun Feb  6 22:34:28 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 07 Feb 2022 03:34:28 +0000
Subject: [issue46666] IDLE Add indent guide
In-Reply-To: <1644184367.6.0.417629376487.issue46666@roundup.psfhosted.org>
Message-ID: <1644204868.57.0.512128824445.issue46666@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

If this were possible, it would be really nice to have.

FWIW, the rich? project was able to pull this off in regular text terminal window:

$ python3.10 -m pip install rich
$ python3.10 -m rich.pretty
{
?   'foo': [1, 'Hello World!', 100.123, 323.232, 432324.0, {(1, 2, 3, 4), 5, 6, 7, 8}, ...],
?   'bar': frozenset({1, 2, 3}),
?   'defaultdict': defaultdict(<class 'list'>, {'crumble': ['apple', 'rhubarb', 'butter', 'sugar', 'flour']}),
?   'counter': Counter({'apple': 1, 'orange': 1, 'pear': 1, 'kumquat': 2, 'duriandurianduriandu'+580: 1}),
?   'atomic': (False, True, None),
?   'Broken': <repr-error 'division by zero'>
}


? https://rich.readthedocs.io/en/stable/index.html

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46666>
_______________________________________

From report at bugs.python.org  Sun Feb  6 23:53:27 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 07 Feb 2022 04:53:27 +0000
Subject: [issue46666] IDLE Add indent guide
In-Reply-To: <1644184367.6.0.417629376487.issue46666@roundup.psfhosted.org>
Message-ID: <1644209607.88.0.107041372167.issue46666@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

'?' is a bit taller that ascii bar '|'; hex(ord('?')) = '0x2502'.   It is a bit heavy.  In this Windows Firefox box it is slightly lighter than | but in IDLE with Source Code Pro, it is slightly darder.  Worse is being centered instead of on one edge.

We would have to check it with multiple fixed-ascii-pitch fonts on multiple systems before using any non-ascii char.  Does it always have the exact width of ascii ' ' or easier to check, ascii '|', so that is does not change the indent?   This is easily tested in the Settings dialog Font tab sample box.  Paste the following
???????????????
|||||||||||||||
It passes with all but one of the Windows mono fonts I tried.

I may ask a tk/tkinter question on SO about other possible options.  Testing this one in code:

if a:  # Put 1st bar on 4th space.
    if b:
   ?    if c:
   ?   ?    pass
    if d:
   ?    pass

if a: # Put 1st bar on 5th space.
    if b:
    ?   if c:
    ?   ?   pass
    if d:
    ?   pass

if a: # Put 1st bar on 1st space.
?   if b:
?   ?   if c:
?   ?   ?   pass
?   if d:
?   ?   pass

The 2nd option looks best to me.  The 3rd would be easier to program, as default tab indent would always be '?   '.  In any case, copied code would not be runnable code.  I would add this on the Option menu between Code Context and Line Numbers.

I believe only updating the markers on demand would be much easier to program than dynamically updating them with each keystroke (checking key and whether whitespace in indent area).

Before merging a PR (writen by someone else), someone other than me, such as Raymond, must test it in real use both for correctness, usefulness, and aesthetics.  (I anticipate that I would fail it on the latter two.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46666>
_______________________________________

From report at bugs.python.org  Mon Feb  7 00:24:45 2022
From: report at bugs.python.org (arl)
Date: Mon, 07 Feb 2022 05:24:45 +0000
Subject: [issue46672] NameError in asyncio.gather when passing a invalid type
 as an arg with multiple awaitables
Message-ID: <1644211485.82.0.488303396987.issue46672@roundup.psfhosted.org>


New submission from arl <genericusername414 at gmail.com>:

It is possible to cause a NameError in asyncio.gather if the second presumed coroutine fails the internal type check.


Sample code:

import asyncio
async def main():
    coros = (asyncio.sleep(1), {1: 1})
    await asyncio.gather(*coros)
asyncio.run(main())



Exception in callback gather.<locals>._done_callback(<Task cancell...tasks.py:593>>) at /usr/local/lib/python3.10/asyncio/tasks.py:714
handle: <Handle gather.<locals>._done_callback(<Task cancell...tasks.py:593>>) at /usr/local/lib/python3.10/asyncio/tasks.py:714>
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/asyncio/runners.py", line 44, in run
    return loop.run_until_complete(main)
  File "/usr/local/lib/python3.10/asyncio/base_events.py", line 641, in run_until_complete
    return future.result()
  File "<string>", line 4, in main
  File "/usr/local/lib/python3.10/asyncio/tasks.py", line 775, in gather
    if arg not in arg_to_fut:
TypeError: unhashable type: 'dict'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.10/asyncio/events.py", line 80, in _run
    self._context.run(self._callback, *self._args)
  File "/usr/local/lib/python3.10/asyncio/tasks.py", line 718, in _done_callback
    if outer.done():
NameError: free variable 'outer' referenced before assignment in enclosing scope
Traceback (most recent call last):
  File "<string>", line 5, in <module>
  File "/usr/local/lib/python3.10/asyncio/runners.py", line 44, in run
    return loop.run_until_complete(main)
  File "/usr/local/lib/python3.10/asyncio/base_events.py", line 641, in run_until_complete
    return future.result()
  File "<string>", line 4, in main
  File "/usr/local/lib/python3.10/asyncio/tasks.py", line 775, in gather
    if arg not in arg_to_fut:
TypeError: unhashable type: 'dict'

----------
components: asyncio
messages: 412709
nosy: asvetlov, onerandomusername, yselivanov
priority: normal
severity: normal
status: open
title: NameError in asyncio.gather when passing a invalid type as an arg with multiple awaitables
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46672>
_______________________________________

From report at bugs.python.org  Mon Feb  7 01:40:20 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Mon, 07 Feb 2022 06:40:20 +0000
Subject: [issue46611] Improve coverage of `__instancecheck__` and
 `__subclasscheck__` methods in `typing.py`
In-Reply-To: <1643810452.7.0.438267754834.issue46611@roundup.psfhosted.org>
Message-ID: <1644216020.69.0.145302665298.issue46611@roundup.psfhosted.org>


Change by Nikita Sobolev <mail at sobolevn.me>:


----------
pull_requests: +29354
pull_request: https://github.com/python/cpython/pull/31182

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46611>
_______________________________________

From report at bugs.python.org  Mon Feb  7 01:45:49 2022
From: report at bugs.python.org (hydroflask)
Date: Mon, 07 Feb 2022 06:45:49 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644216349.65.0.947319413006.issue46323@roundup.psfhosted.org>


hydroflask <hydroflask at yqxmail.com> added the comment:

Okay I put together a benchmark that better exemplifies my use case and results are in favor of adding patch.

When bench_callback_v2.py is not compiled with mypyc I see a ~10% reduction in runtime:

    $ unpatched-env/bin/python bench_callback_v2.py
    1.1262263769749552
    $ patched-env/bin/python bench_callback_v2.py
    1.0174838998354971

When bench_callback_v2.py is compiled with mypyc, I am getting ~6% reduction in runtime:

    $ unpatched-env/bin/python -c "import bench_callback_v2"
    1.0056699379347265
    $ patched-env/bin/python -c "import bench_callback_v2"
    0.9415687420405447

bench_callback_v2.py is attached.

----------
Added file: https://bugs.python.org/file50609/bench_callback_v2.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Mon Feb  7 01:54:50 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 07 Feb 2022 06:54:50 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644216890.46.0.243455179157.issue46323@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:

@vstinner

I got a similar result from hydroflask's benchmark.
I think that is worth reopening this issue WDYT?

----------
nosy: +erlendaasland, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Mon Feb  7 02:00:19 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 07 Feb 2022 07:00:19 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644217219.46.0.649254050752.issue46323@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:

@hydroflask

Would you like to run your benchmark with my latest PR?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Mon Feb  7 02:05:50 2022
From: report at bugs.python.org (hydroflask)
Date: Mon, 07 Feb 2022 07:05:50 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644217550.65.0.494584771936.issue46323@roundup.psfhosted.org>


hydroflask <hydroflask at yqxmail.com> added the comment:

Vanilla bench_callback_v2.py, not compiled with mypyc:

    $ env/bin/python bench_callback_v2.py
    1.114047016017139
    $ env2/bin/python bench_callback_v2.py
    0.9644024870358407

~13% reduction in runtime. Nice job!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Mon Feb  7 02:08:12 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 07 Feb 2022 07:08:12 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644217692.09.0.0500950334819.issue46323@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


Added file: https://bugs.python.org/file50610/bench_callback_v3.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Mon Feb  7 02:08:29 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 07 Feb 2022 07:08:29 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644217709.89.0.299937067024.issue46323@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:

With v3 benchmark

Mean +- std dev: [base] 1.32 us +- 0.02 us -> [opt] 1.18 us +- 0.02 us: 1.13x faster

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Mon Feb  7 02:10:37 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 07 Feb 2022 07:10:37 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644217837.76.0.0176104273249.issue46323@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
stage: resolved -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Mon Feb  7 02:10:32 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 07 Feb 2022 07:10:32 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644217832.75.0.230015644267.issue46323@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
resolution: wont fix -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Mon Feb  7 02:40:58 2022
From: report at bugs.python.org (miss-islington)
Date: Mon, 07 Feb 2022 07:40:58 +0000
Subject: [issue40479] Port _hashlib to OpenSSL 3.0.0
In-Reply-To: <1588497803.18.0.937746880221.issue40479@roundup.psfhosted.org>
Message-ID: <1644219658.83.0.867261352484.issue40479@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 59e004af63742361b67d1e1ae70229ff0db1059d by Zackery Spytz in branch 'main':
bpo-40479: Fix undefined behavior in Modules/_hashopenssl.c (GH-31153)
https://github.com/python/cpython/commit/59e004af63742361b67d1e1ae70229ff0db1059d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40479>
_______________________________________

From report at bugs.python.org  Mon Feb  7 02:41:05 2022
From: report at bugs.python.org (miss-islington)
Date: Mon, 07 Feb 2022 07:41:05 +0000
Subject: [issue40479] Port _hashlib to OpenSSL 3.0.0
In-Reply-To: <1588497803.18.0.937746880221.issue40479@roundup.psfhosted.org>
Message-ID: <1644219665.34.0.675299884138.issue40479@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29355
pull_request: https://github.com/python/cpython/pull/31183

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40479>
_______________________________________

From report at bugs.python.org  Mon Feb  7 02:41:10 2022
From: report at bugs.python.org (miss-islington)
Date: Mon, 07 Feb 2022 07:41:10 +0000
Subject: [issue40479] Port _hashlib to OpenSSL 3.0.0
In-Reply-To: <1588497803.18.0.937746880221.issue40479@roundup.psfhosted.org>
Message-ID: <1644219670.49.0.502376554308.issue40479@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29356
pull_request: https://github.com/python/cpython/pull/31184

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40479>
_______________________________________

From report at bugs.python.org  Mon Feb  7 03:05:39 2022
From: report at bugs.python.org (miss-islington)
Date: Mon, 07 Feb 2022 08:05:39 +0000
Subject: [issue40479] Port _hashlib to OpenSSL 3.0.0
In-Reply-To: <1588497803.18.0.937746880221.issue40479@roundup.psfhosted.org>
Message-ID: <1644221139.83.0.429790697915.issue40479@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 3ceff9968be059209f0d7271365f38895207b24d by Miss Islington (bot) in branch '3.10':
bpo-40479: Fix undefined behavior in Modules/_hashopenssl.c (GH-31153)
https://github.com/python/cpython/commit/3ceff9968be059209f0d7271365f38895207b24d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40479>
_______________________________________

From report at bugs.python.org  Mon Feb  7 03:08:13 2022
From: report at bugs.python.org (miss-islington)
Date: Mon, 07 Feb 2022 08:08:13 +0000
Subject: [issue40479] Port _hashlib to OpenSSL 3.0.0
In-Reply-To: <1588497803.18.0.937746880221.issue40479@roundup.psfhosted.org>
Message-ID: <1644221293.99.0.201766582301.issue40479@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 0892a0e3ec925ac959bc959b985293b4b96ef863 by Miss Islington (bot) in branch '3.9':
bpo-40479: Fix undefined behavior in Modules/_hashopenssl.c (GH-31153)
https://github.com/python/cpython/commit/0892a0e3ec925ac959bc959b985293b4b96ef863


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40479>
_______________________________________

From report at bugs.python.org  Mon Feb  7 03:22:58 2022
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 07 Feb 2022 08:22:58 +0000
Subject: [issue24904] Provide a way for potentially long runtime difflib
 algorithms to be aborted by the caller (and report progress?)
In-Reply-To: <1440109087.94.0.522414876776.issue24904@psf.upfronthosting.co.za>
Message-ID: <1644222178.19.0.873824822779.issue24904@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

The way I'd go about this is to support some form of periodic checkpoint in the algorithm where it checks in with code supplied by the difflib user. Traditionally that'd have been via callbacks, there might be an async style way to express that these days. Those could indicate that they want the operation to be aborted. If it is possible to estimate progress, supplying that as input to the checkpoint API would be useful.

This leaves decision logic on when to abort something entirely up to the user rather than being clock based which is often not what the user wants.

I'm re-titling the issue as the original patch and proposal of a timeout isn't the direction several core devs have suggested we head.

----------
nosy: +gregory.p.smith
stage:  -> needs patch
title: Patch: add timeout to difflib SequenceMatcher ratio() and quick_ratio() -> Provide a way for potentially long runtime difflib algorithms to be aborted by the caller (and report progress?)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24904>
_______________________________________

From report at bugs.python.org  Mon Feb  7 03:25:59 2022
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 07 Feb 2022 08:25:59 +0000
Subject: [issue20342] Endianness not detected correctly due to AC_RUN_IFELSE
 macros
In-Reply-To: <1390380271.48.0.67555288445.issue20342@psf.upfronthosting.co.za>
Message-ID: <1644222359.88.0.443317041235.issue20342@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

any idea if this is still relevant?

----------
components: +Cross-Build
nosy: +Alex.Willmer, gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20342>
_______________________________________

From report at bugs.python.org  Mon Feb  7 03:38:11 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Mon, 07 Feb 2022 08:38:11 +0000
Subject: [issue46648] `test.test_urllib2.MiscTests.test_issue16464` flaky due
 to external connection
In-Reply-To: <1644061533.84.0.594817920054.issue46648@roundup.psfhosted.org>
Message-ID: <1644223091.63.0.545305471337.issue46648@roundup.psfhosted.org>


Change by Nikita Sobolev <mail at sobolevn.me>:


----------
pull_requests: +29357
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31186

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46648>
_______________________________________

From report at bugs.python.org  Mon Feb  7 03:41:30 2022
From: report at bugs.python.org (Erlend E. Aasland)
Date: Mon, 07 Feb 2022 08:41:30 +0000
Subject: [issue46657] Add mimalloc memory allocator
In-Reply-To: <1644158952.9.0.443530192167.issue46657@roundup.psfhosted.org>
Message-ID: <1644223290.63.0.421541512818.issue46657@roundup.psfhosted.org>


Change by Erlend E. Aasland <erlend.aasland at innova.no>:


----------
nosy: +erlendaasland

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46657>
_______________________________________

From report at bugs.python.org  Mon Feb  7 03:42:37 2022
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 07 Feb 2022 08:42:37 +0000
Subject: [issue46648] `test.test_urllib2.MiscTests.test_issue16464` flaky due
 to external connection
In-Reply-To: <1644061533.84.0.594817920054.issue46648@roundup.psfhosted.org>
Message-ID: <1644223357.51.0.230791022715.issue46648@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> sobolevn

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46648>
_______________________________________

From report at bugs.python.org  Mon Feb  7 03:47:18 2022
From: report at bugs.python.org (Yury V. Zaytsev)
Date: Mon, 07 Feb 2022 08:47:18 +0000
Subject: [issue20342] Endianness not detected correctly due to AC_RUN_IFELSE
 macros
In-Reply-To: <1390380271.48.0.67555288445.issue20342@psf.upfronthosting.co.za>
Message-ID: <1644223638.05.0.500546771929.issue20342@roundup.psfhosted.org>


Yury V. Zaytsev <yury at shurup.com> added the comment:

Well, the machine that I had the problem on does no longer exist and I'm not sure whether this is a generic POWER issue.

The problem was that I had to cross-compile Python on one generation of POWER machines for another POWER chip using its own special toolchain. I can't tell whether Python build system was doing something wrong, or else whether it was a problem with the toolchain. In theory, both are valid options.

Also, I can't test whether the current version of Python has this problem or not with this particular chip / toolchain anymore. Maybe someone who has interest in POWER could try to cross-compile from AMD64 to POWER and check whether the result is still subtly broken... this should be much easier, and if there is a genuine problem with Python build system, it will probably expose it just as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20342>
_______________________________________

From report at bugs.python.org  Mon Feb  7 03:48:42 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 07 Feb 2022 08:48:42 +0000
Subject: [issue46611] Improve coverage of `__instancecheck__` and
 `__subclasscheck__` methods in `typing.py`
In-Reply-To: <1643810452.7.0.438267754834.issue46611@roundup.psfhosted.org>
Message-ID: <1644223722.74.0.304504422475.issue46611@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset c1ff4cb98b11c00aee765019364544c71e7dd2df by Nikita Sobolev in branch '3.10':
[3.10] bpo-46611: add coverage to instance and class checks in `typing.py` (GH-31078) (GH-31182)
https://github.com/python/cpython/commit/c1ff4cb98b11c00aee765019364544c71e7dd2df


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46611>
_______________________________________

From report at bugs.python.org  Mon Feb  7 03:49:38 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 07 Feb 2022 08:49:38 +0000
Subject: [issue46611] Improve coverage of `__instancecheck__` and
 `__subclasscheck__` methods in `typing.py`
In-Reply-To: <1643810452.7.0.438267754834.issue46611@roundup.psfhosted.org>
Message-ID: <1644223778.79.0.959220853879.issue46611@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thanks Nikita.

----------
components: +Tests -Library (Lib)
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46611>
_______________________________________

From report at bugs.python.org  Mon Feb  7 03:51:47 2022
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 07 Feb 2022 08:51:47 +0000
Subject: [issue20342] Endianness not detected correctly due to AC_RUN_IFELSE
 macros
In-Reply-To: <1390380271.48.0.67555288445.issue20342@psf.upfronthosting.co.za>
Message-ID: <1644223907.06.0.710628912336.issue20342@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

I'll leave it open, nothing about this should be ppc64 vs ppc64el specific. Our cross compilation story has historically been not great.  

Building for a target of one endianness from a build host of other endianness... sounds like exactly one of many kinds of thing that we might have a mess with until someone can confirm.  (I'm not setup with a big endian toolchain to build for a qemu target right now so I can't easily confirm)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20342>
_______________________________________

From report at bugs.python.org  Mon Feb  7 04:14:09 2022
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 07 Feb 2022 09:14:09 +0000
Subject: [issue46663] test_math test_cmath test_complex fails on Fedora
 Rawhide buildbots
In-Reply-To: <1644179485.62.0.212038403809.issue46663@roundup.psfhosted.org>
Message-ID: <1644225249.19.0.840713372084.issue46663@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

@vstinner What was the change that caused the buildbots to start failing? Did the GCC version get updated on those machines between the last runs and this one, or was the change due to recent PRs in Python?

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46663>
_______________________________________

From report at bugs.python.org  Mon Feb  7 04:21:42 2022
From: report at bugs.python.org (Olli Lupton)
Date: Mon, 07 Feb 2022 09:21:42 +0000
Subject: [issue46673] Py_BuildValue tuple creation segfaults in python3.9..3.11
Message-ID: <1644225702.08.0.855610983498.issue46673@roundup.psfhosted.org>


New submission from Olli Lupton <olli at lupton.ch>:

The following function, compiled and linked into a shared library, segfaults when called from Python:
```
#define PY_SSIZE_T_CLEAN
#include <Python.h>
extern "C" PyObject* my_func() {
  return Py_BuildValue("(O)", Py_None);
}
```
called using ctypes:
```
from ctypes import CDLL
h = CDLL('./libtest.so?)
h.my_func()?
```
crashes with a stacktrace
```
Program received signal SIGSEGV, Segmentation fault.
_PyObject_GC_TRACK_impl (filename=0x7fffed7ab1b0 "src/Objects/tupleobject.c", lineno=36, op=(0x0,)) at src/Include/internal/pycore_object.h:43
(gdb) bt
#0  _PyObject_GC_TRACK_impl (filename=0x7fffed7ab1b0 "src/Objects/tupleobject.c", lineno=36,
    op=(0x0,)) at src/Include/internal/pycore_object.h:43
#1  tuple_gc_track (op=0x7fffe5e42dc0) at src/Objects/tupleobject.c:36
#2  PyTuple_New (size=<optimized out>) at src/Objects/tupleobject.c:124
#3  PyTuple_New (size=size at entry=1) at src/Objects/tupleobject.c:100
#4  0x00007fffed7031eb in do_mktuple (p_format=0x7fffffffa8d0, p_va=0x7fffffffa8d8, endchar=<optimized out>, n=1, flags=1) at src/Python/modsupport.c:259
#5  0x00007fffed703358 in va_build_value (format=<optimized out>, va=va at entry=0x7fffffffa918, flags=flags at entry=1) at src/Python/modsupport.c:562
#6  0x00007fffed7036d9 in _Py_BuildValue_SizeT (format=<optimized out>) at src/Python/modsupport.c:530
#7  0x00007fffedae6126 in my_func () at test.cpp:4
#8  0x00007fffedaf1c9d in ffi_call_unix64 () from libffi.so.7
#9  0x00007fffedaf0623 in ffi_call_int () from libffi.so.7
?
```
this is reproducible on RHEL7 (Python 3.9.7 built with GCC 11.2) and macOS (Python 3.9.10, 3.10.2 and 3.11.0a4 installed via MacPorts).
It does not crash with Python 3.8, I tested on RHEL7 (Python 3.8.3 built with GCC 9.3.0) and macOS (Python 3.8.12 installed via MacPorts).

This is meant to be a minimal example. It seems to be important that `Py_BuildValue` is returning a tuple, but the size of that tuple is not important.
`"O"` and `Py_None` are also not important, it still crashes with `"i"` and `42`.
The definition of `PY_SSIZE_T_CLEAN` also does not seem to be important; the only obvious difference it makes is whether I see `_Py_BuildValue_SizeT` or `Py_BuildValue` in the backtrace.

This seems to be a bit of an unlikely bug, so apologies in advance if I have missed something obvious. I tried to be thorough, but I do not have a lot of experience working with the Python C API.

----------
components: C API, Extension Modules, ctypes
messages: 412725
nosy: olupton
priority: normal
severity: normal
status: open
title: Py_BuildValue tuple creation segfaults in python3.9..3.11
type: crash
versions: Python 3.10, Python 3.11, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46673>
_______________________________________

From report at bugs.python.org  Mon Feb  7 04:44:17 2022
From: report at bugs.python.org (Ramil Nugmanov)
Date: Mon, 07 Feb 2022 09:44:17 +0000
Subject: [issue46674] Two if in a row in generators
Message-ID: <1644227057.33.0.630372921709.issue46674@roundup.psfhosted.org>


New submission from Ramil Nugmanov <rainugmanov at kpfu.ru>:

treat without error two if in generators.

>>>[x for x in [1, 2, 3] if 1 if 1]
[1, 2, 3]

>>>[x for x in [1, 2, 3] if 0 if 1]
[]

expected syntax error

----------
components: Parser
messages: 412726
nosy: lys.nikolaou, pablogsal, stsouko
priority: normal
severity: normal
status: open
title: Two if in a row in generators
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46674>
_______________________________________

From report at bugs.python.org  Mon Feb  7 04:47:20 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 07 Feb 2022 09:47:20 +0000
Subject: [issue46674] Two if in a row in generators
In-Reply-To: <1644227057.33.0.630372921709.issue46674@roundup.psfhosted.org>
Message-ID: <1644227240.13.0.901291083162.issue46674@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It is valid syntax.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46674>
_______________________________________

From report at bugs.python.org  Mon Feb  7 04:48:44 2022
From: report at bugs.python.org (Petr Viktorin)
Date: Mon, 07 Feb 2022 09:48:44 +0000
Subject: [issue46640] Python can now use the C99 NAN constant or
 __builtin_nan()
In-Reply-To: <1644006249.4.0.292742084923.issue46640@roundup.psfhosted.org>
Message-ID: <1644227324.74.0.336273770205.issue46640@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

Adding new C99 features needs a change in PEP 7 (https://www.python.org/dev/peps/pep-0007/#c-dialect)

----------
nosy: +petr.viktorin
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46640>
_______________________________________

From report at bugs.python.org  Mon Feb  7 05:20:12 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Mon, 07 Feb 2022 10:20:12 +0000
Subject: [issue46672] NameError in asyncio.gather when passing a invalid type
 as an arg with multiple awaitables
In-Reply-To: <1644211485.82.0.488303396987.issue46672@roundup.psfhosted.org>
Message-ID: <1644229212.0.0.847313105981.issue46672@roundup.psfhosted.org>


Change by Nikita Sobolev <mail at sobolevn.me>:


----------
keywords: +patch
nosy: +sobolevn
nosy_count: 3.0 -> 4.0
pull_requests: +29358
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31187

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46672>
_______________________________________

From report at bugs.python.org  Mon Feb  7 05:20:19 2022
From: report at bugs.python.org (Andreas Skaar)
Date: Mon, 07 Feb 2022 10:20:19 +0000
Subject: [issue41021] ctypes callback with structure crashes in Python 3.8 on
 Windows x86
In-Reply-To: <1592472376.78.0.985098642017.issue41021@roundup.psfhosted.org>
Message-ID: <1644229219.96.0.477007913451.issue41021@roundup.psfhosted.org>


Andreas Skaar <andreas.skaar at no.abb.com> added the comment:

Steve Dower do you have any links to the issues you mention? Are these now solved?

I am not able to see if the fix is straightforward, but from the information from Eryk Sun it sounds like it should be?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41021>
_______________________________________

From report at bugs.python.org  Mon Feb  7 05:36:12 2022
From: report at bugs.python.org (Alex Waygood)
Date: Mon, 07 Feb 2022 10:36:12 +0000
Subject: [issue46665] IDLE Windows shortcuts by default
In-Reply-To: <1644183835.83.0.808508877845.issue46665@roundup.psfhosted.org>
Message-ID: <1644230172.4.0.205603411715.issue46665@roundup.psfhosted.org>


Alex Waygood <Alex.Waygood at Gmail.com> added the comment:

As a longtime Windows user, I also generally expect ctrl+Y to redo an action in most programs, FWIW.

----------
nosy: +AlexWaygood

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46665>
_______________________________________

From report at bugs.python.org  Mon Feb  7 06:12:54 2022
From: report at bugs.python.org (Jakub Wilk)
Date: Mon, 07 Feb 2022 11:12:54 +0000
Subject: [issue38605] [typing] PEP 563: Postponed evaluation of annotations:
 enable it by default in Python 3.11
In-Reply-To: <1572192430.43.0.755831692199.issue38605@roundup.psfhosted.org>
Message-ID: <1644232374.55.0.195914804951.issue38605@roundup.psfhosted.org>


Change by Jakub Wilk <jwilk at jwilk.net>:


----------
nosy: +jwilk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38605>
_______________________________________

From report at bugs.python.org  Mon Feb  7 06:13:26 2022
From: report at bugs.python.org (Batuhan Taskaya)
Date: Mon, 07 Feb 2022 11:13:26 +0000
Subject: [issue46674] Two if in a row in generators
In-Reply-To: <1644227057.33.0.630372921709.issue46674@roundup.psfhosted.org>
Message-ID: <1644232406.15.0.596714679402.issue46674@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:

As Serhiy mentioned, this is a valid syntax.

----------
nosy: +BTaskaya
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46674>
_______________________________________

From report at bugs.python.org  Mon Feb  7 06:29:19 2022
From: report at bugs.python.org (Olli Lupton)
Date: Mon, 07 Feb 2022 11:29:19 +0000
Subject: [issue46673] Py_BuildValue tuple creation segfaults in python3.9..3.11
In-Reply-To: <1644225702.08.0.855610983498.issue46673@roundup.psfhosted.org>
Message-ID: <1644233359.41.0.585924077691.issue46673@roundup.psfhosted.org>


Olli Lupton <olli at lupton.ch> added the comment:

With apologies for the noise, I realise that the posted example does not handle the GIL correctly.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46673>
_______________________________________

From report at bugs.python.org  Mon Feb  7 06:31:50 2022
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 07 Feb 2022 11:31:50 +0000
Subject: [issue46159] Segfault when using trace functions in 3.11a3
In-Reply-To: <1640228846.77.0.888301890747.issue46159@roundup.psfhosted.org>
Message-ID: <1644233510.57.0.48110716048.issue46159@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

Can you reproduce this failure with just Python?
If not, with just cryptography and not tox?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46159>
_______________________________________

From report at bugs.python.org  Mon Feb  7 06:34:54 2022
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 07 Feb 2022 11:34:54 +0000
Subject: [issue46161] `class A(1, 2, 3, **d): pass` gives bad bytecode
In-Reply-To: <1640242986.51.0.0809941364169.issue46161@roundup.psfhosted.org>
Message-ID: <1644233694.8.0.164406215843.issue46161@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

Qiang Zhang, thanks for fixing this.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46161>
_______________________________________

From report at bugs.python.org  Mon Feb  7 06:52:04 2022
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 07 Feb 2022 11:52:04 +0000
Subject: [issue46675] Allow more than 16 items in split-keys dicts and
 "virtual" object dicts.
Message-ID: <1644234724.61.0.0969544850657.issue46675@roundup.psfhosted.org>


New submission from Mark Shannon <mark at hotpy.org>:

https://bugs.python.org/issue45340 and https://github.com/python/cpython/pull/28802 allowed "virtual" object dicts (see faster-cpython/ideas#72  for full details).

In order for this to work, we need to keep the insertion order on the values. The initial version (https://github.com/python/cpython/pull/28802) used a 64 bit value as a vector of 16 4-bit values, which allows only 16 items per values array.

Stats gathered from the standard benchmark suite and informal evidence from elsewhere suggests that this causes a significant (5% and upwards) of these dicts to be materialized due to exceeding the 16 item limit.

An alternative design that would allow up to ~254 items in the values array is to make the insertion order vector an array of bytes. The capacity is 254 as we need a byte for size, and another for capacity.
This will increase the size of the values a bit for sizes from 7 to 15, but save a lot of memory for sizes 17+, as keys could still be shared.

Pros:
    No need to materialize dicts of size 16+, saving ~3/4 of the memory per dict and helping specialization.

Cons:
    Extra memory write to store a value*
    1 extra word for values of size 7 to 14, 2 extra for size 15.
    Some extra complexity.

*In a hypothetical optimized JIT, the insertion order vector would be stored as a single write for several writes, so this would make no difference.

----------
assignee: Mark.Shannon
messages: 412735
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: Allow more than 16 items in split-keys dicts and "virtual" object dicts.
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46675>
_______________________________________

From report at bugs.python.org  Mon Feb  7 07:00:04 2022
From: report at bugs.python.org (Ramil Nugmanov)
Date: Mon, 07 Feb 2022 12:00:04 +0000
Subject: [issue46674] Two if in a row in generators
In-Reply-To: <1644227057.33.0.630372921709.issue46674@roundup.psfhosted.org>
Message-ID: <1644235204.81.0.640658969384.issue46674@roundup.psfhosted.org>


Ramil Nugmanov <nougmanoff at protonmail.com> added the comment:

Yes,

[x for x in [1, 2, 3] if 1 if 1]

can be replaced with:

for x in [1, 2, 3]:
    if 1:
        if 1:
            yield x

However this syntax is strange and leads to errors like:

[x for x in [1, 2, 3] if x is not None] >> [x for x in [1, 2, 3] if x if not None]

----------
resolution: not a bug -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46674>
_______________________________________

From report at bugs.python.org  Mon Feb  7 07:37:59 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Feb 2022 12:37:59 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644237479.32.0.730633597938.issue46323@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29359
pull_request: https://github.com/python/cpython/pull/31188

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Mon Feb  7 07:48:52 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Feb 2022 12:48:52 +0000
Subject: [issue46648] `test.test_urllib2.MiscTests.test_issue16464` flaky due
 to external connection
In-Reply-To: <1644061533.84.0.594817920054.issue46648@roundup.psfhosted.org>
Message-ID: <1644238132.91.0.904489345418.issue46648@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 8e98175a03fe03d62822d96007a74e5273013764 by Nikita Sobolev in branch 'main':
bpo-46648: Rewrite test_urllib2.test_issue16464() with a local HTTP server (GH-31186)
https://github.com/python/cpython/commit/8e98175a03fe03d62822d96007a74e5273013764


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46648>
_______________________________________

From report at bugs.python.org  Mon Feb  7 07:48:58 2022
From: report at bugs.python.org (miss-islington)
Date: Mon, 07 Feb 2022 12:48:58 +0000
Subject: [issue46648] `test.test_urllib2.MiscTests.test_issue16464` flaky due
 to external connection
In-Reply-To: <1644061533.84.0.594817920054.issue46648@roundup.psfhosted.org>
Message-ID: <1644238138.03.0.312940431334.issue46648@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29360
pull_request: https://github.com/python/cpython/pull/31189

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46648>
_______________________________________

From report at bugs.python.org  Mon Feb  7 07:49:04 2022
From: report at bugs.python.org (miss-islington)
Date: Mon, 07 Feb 2022 12:49:04 +0000
Subject: [issue46648] `test.test_urllib2.MiscTests.test_issue16464` flaky due
 to external connection
In-Reply-To: <1644061533.84.0.594817920054.issue46648@roundup.psfhosted.org>
Message-ID: <1644238144.3.0.265617107425.issue46648@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29361
pull_request: https://github.com/python/cpython/pull/31190

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46648>
_______________________________________

From report at bugs.python.org  Mon Feb  7 08:00:07 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Feb 2022 13:00:07 +0000
Subject: [issue46668] encodings: the "mbcs" alias doesn't work
In-Reply-To: <1644188809.05.0.861398707442.issue46668@roundup.psfhosted.org>
Message-ID: <1644238807.04.0.734899174957.issue46668@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I don't think that this fallback is needed anymore. Which Windows code page can be used as ANSI code page which is not already implemented as a Python codec?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46668>
_______________________________________

From report at bugs.python.org  Mon Feb  7 08:02:39 2022
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 07 Feb 2022 13:02:39 +0000
Subject: [issue46674] Two if in a row in generators
In-Reply-To: <1644227057.33.0.630372921709.issue46674@roundup.psfhosted.org>
Message-ID: <1644238959.48.0.634699007686.issue46674@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Please, stop reopening the issue.

The syntax is valid python syntax and we will not be able to make it invalid

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46674>
_______________________________________

From report at bugs.python.org  Mon Feb  7 08:14:18 2022
From: report at bugs.python.org (miss-islington)
Date: Mon, 07 Feb 2022 13:14:18 +0000
Subject: [issue46648] `test.test_urllib2.MiscTests.test_issue16464` flaky due
 to external connection
In-Reply-To: <1644061533.84.0.594817920054.issue46648@roundup.psfhosted.org>
Message-ID: <1644239658.72.0.737279903814.issue46648@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 0d74efc54fa811def386d2cde00986204ba18569 by Miss Islington (bot) in branch '3.9':
bpo-46648: Rewrite test_urllib2.test_issue16464() with a local HTTP server (GH-31186)
https://github.com/python/cpython/commit/0d74efc54fa811def386d2cde00986204ba18569


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46648>
_______________________________________

From report at bugs.python.org  Mon Feb  7 08:30:04 2022
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 07 Feb 2022 13:30:04 +0000
Subject: [issue46657] Add mimalloc memory allocator
In-Reply-To: <1644158952.9.0.443530192167.issue46657@roundup.psfhosted.org>
Message-ID: <1644240604.44.0.968990814269.issue46657@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

ICC might be a problem. Apparently some version have an incomplete stdatomic.h, see bpo-37415.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46657>
_______________________________________

From report at bugs.python.org  Mon Feb  7 08:33:44 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Feb 2022 13:33:44 +0000
Subject: [issue46663] test_math test_cmath test_complex fails on Fedora
 Rawhide buildbots
In-Reply-To: <1644179485.62.0.212038403809.issue46663@roundup.psfhosted.org>
Message-ID: <1644240824.93.0.399571062407.issue46663@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> @vstinner What was the change that caused the buildbots to start failing? Did the GCC version get updated on those machines between the last runs and this one, or was the change due to recent PRs in Python?

It's a GCC regression. GCC is updated frequently on the Rawhide buildbots.

It's unrelated to Python. It's just that Python uses (Py_HUGE_VAL * 0.) for Py_NAN and this code is impacted by the bug.

But I wrote https://github.com/python/cpython/pull/31134 since GCC 12 will no longer compute (Py_HUGE_VAL * 0.) during the compilation: it will be computed at runtime.

See also https://bugzilla.redhat.com/show_bug.cgi?id=2050736 for details.

--

The GCC regression is fixed in gcc-12.0.1-0.6.fc36 package. It will be deployed on buildbots shortly (and automatically).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46663>
_______________________________________

From report at bugs.python.org  Mon Feb  7 08:36:55 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Feb 2022 13:36:55 +0000
Subject: [issue24904] Provide a way for potentially long runtime difflib
 algorithms to be aborted by the caller (and report progress?)
In-Reply-To: <1440109087.94.0.522414876776.issue24904@psf.upfronthosting.co.za>
Message-ID: <1644241015.87.0.164762154401.issue24904@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24904>
_______________________________________

From report at bugs.python.org  Mon Feb  7 08:42:02 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Feb 2022 13:42:02 +0000
Subject: [issue46640] Python can now use the C99 NAN constant or
 __builtin_nan()
In-Reply-To: <1644006249.4.0.292742084923.issue46640@roundup.psfhosted.org>
Message-ID: <1644241322.63.0.875719829562.issue46640@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Adding new C99 features needs a change in PEP 7 (https://www.python.org/dev/peps/pep-0007/#c-dialect)

IMO this PEP is outdated for a long time.

C99 standard is wide. Do we have to explicitly list every single function, macro or constant used by Python? It doesn't sound reasonable to me. IMO saying that we use "C99 except of these few features: <...>" would be closer to the reality. I don't know which features are not used.

Well, if you ask me, I would simply require a C99 compiler. That's all :-)

Note: Python uses C11 <stdatomic.h>, but it remains an optional requirement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46640>
_______________________________________

From report at bugs.python.org  Mon Feb  7 08:45:45 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Feb 2022 13:45:45 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644241545.32.0.5762205759.issue46323@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

A benchmark on calling C functions using ctypes sounds better than a benchmark calling Python functions. For Python functions, Python objects are converted to C types, and then C types are convered back to Python objects, the Python result is converted to a C type, and then the C type is converted back to a Python object for the final result...

It would be nice to have a benchmark on different number of arguments. Like: 0, 1, 3, 5, 8, 10.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Mon Feb  7 08:53:23 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Feb 2022 13:53:23 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644242003.44.0.50020084869.issue46323@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 4cce1352bb47babaeefb68fcfcc48ffa073745c3 by Victor Stinner in branch 'main':
bpo-46323: _ctypes.CFuncPtr fails if _argtypes_ is too long (GH-31188)
https://github.com/python/cpython/commit/4cce1352bb47babaeefb68fcfcc48ffa073745c3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Mon Feb  7 09:00:20 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Feb 2022 14:00:20 +0000
Subject: [issue46670] Build Python with -Wundef: don't use undefined macros
In-Reply-To: <1644191556.12.0.192524677903.issue46670@roundup.psfhosted.org>
Message-ID: <1644242420.78.0.300003696898.issue46670@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29362
pull_request: https://github.com/python/cpython/pull/31192

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46670>
_______________________________________

From report at bugs.python.org  Mon Feb  7 09:02:37 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Feb 2022 14:02:37 +0000
Subject: [issue46670] Build Python with -Wundef: don't use undefined macros
In-Reply-To: <1644191556.12.0.192524677903.issue46670@roundup.psfhosted.org>
Message-ID: <1644242557.51.0.529175917029.issue46670@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29363
pull_request: https://github.com/python/cpython/pull/31193

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46670>
_______________________________________

From report at bugs.python.org  Mon Feb  7 09:04:49 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Feb 2022 14:04:49 +0000
Subject: [issue46670] Build Python with -Wundef: don't use undefined macros
In-Reply-To: <1644191556.12.0.192524677903.issue46670@roundup.psfhosted.org>
Message-ID: <1644242689.46.0.172544027583.issue46670@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29364
pull_request: https://github.com/python/cpython/pull/31194

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46670>
_______________________________________

From report at bugs.python.org  Mon Feb  7 09:05:59 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Feb 2022 14:05:59 +0000
Subject: [issue46670] Build Python with -Wundef: don't use undefined macros
In-Reply-To: <1644191556.12.0.192524677903.issue46670@roundup.psfhosted.org>
Message-ID: <1644242759.87.0.757792039096.issue46670@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

-Wexpansion-to-defined and -Wunused-macros options are also interesting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46670>
_______________________________________

From report at bugs.python.org  Mon Feb  7 09:10:58 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Feb 2022 14:10:58 +0000
Subject: [issue39277] _PyTime_FromDouble() fails to detect an integer overflow
 when converting a C double to a C int64_t
In-Reply-To: <1578581025.66.0.18478821427.issue39277@roundup.psfhosted.org>
Message-ID: <1644243058.51.0.962495264382.issue39277@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29365
pull_request: https://github.com/python/cpython/pull/31195

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39277>
_______________________________________

From report at bugs.python.org  Mon Feb  7 09:14:08 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Feb 2022 14:14:08 +0000
Subject: [issue46670] Build Python with -Wundef: don't use undefined macros
In-Reply-To: <1644191556.12.0.192524677903.issue46670@roundup.psfhosted.org>
Message-ID: <1644243248.94.0.868246697467.issue46670@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29366
pull_request: https://github.com/python/cpython/pull/31196

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46670>
_______________________________________

From report at bugs.python.org  Mon Feb  7 09:18:29 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Feb 2022 14:18:29 +0000
Subject: [issue46640] Python can now use the C99 NAN constant or
 __builtin_nan()
In-Reply-To: <1644006249.4.0.292742084923.issue46640@roundup.psfhosted.org>
Message-ID: <1644243509.44.0.611525066761.issue46640@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Well, if you ask me, I would simply require a C99 compiler. That's all :-)

Done in https://github.com/python/peps/pull/2309

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46640>
_______________________________________

From report at bugs.python.org  Mon Feb  7 09:18:49 2022
From: report at bugs.python.org (Petr Viktorin)
Date: Mon, 07 Feb 2022 14:18:49 +0000
Subject: [issue46640] Python can now use the C99 NAN constant or
 __builtin_nan()
In-Reply-To: <1644006249.4.0.292742084923.issue46640@roundup.psfhosted.org>
Message-ID: <1644243529.13.0.154875318177.issue46640@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

> IMO this PEP is outdated for a long time.

It is not. Even if it is, it should be marked as such, and that is not a decision that should be done in this issue.

Please, don't break the rules because you think they're outdated.

> Well, if you ask me, I would simply require a C99 compiler. That's all :-)

Please propose that change. Perhaps it would be a good change to make, but I don't even know how to determine that.
Nor can I list the places where the change should be made -- at least there should be a What's New entry like https://docs.python.org/3.10/whatsnew/3.6.html#build-and-c-api-changes

> Note: Python uses C11 <stdatomic.h>, but it remains an optional requirement.

That's fine. You can still build with an older compiler.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46640>
_______________________________________

From report at bugs.python.org  Mon Feb  7 09:24:45 2022
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 07 Feb 2022 14:24:45 +0000
Subject: [issue46657] Add mimalloc memory allocator
In-Reply-To: <1644158952.9.0.443530192167.issue46657@roundup.psfhosted.org>
Message-ID: <1644243885.22.0.923373582935.issue46657@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

References:

- C11 stdatomic.h https://en.cppreference.com/w/c/atomic
- mimalloc-atomic.h https://github.com/microsoft/mimalloc/blob/master/include/mimalloc-atomic.h
- MSVC Interlocked Variable Access https://docs.microsoft.com/de-de/windows/win32/sync/interlocked-variable-access

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46657>
_______________________________________

From report at bugs.python.org  Mon Feb  7 09:30:13 2022
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 07 Feb 2022 14:30:13 +0000
Subject: [issue46675] Allow more than 16 items in split-keys dicts and
 "virtual" object dicts.
In-Reply-To: <1644234724.61.0.0969544850657.issue46675@roundup.psfhosted.org>
Message-ID: <1644244213.38.0.0620711251535.issue46675@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
keywords: +patch
pull_requests: +29367
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31191

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46675>
_______________________________________

From report at bugs.python.org  Mon Feb  7 09:31:00 2022
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 07 Feb 2022 14:31:00 +0000
Subject: [issue46072] Unify handling of stats in the CPython VM
In-Reply-To: <1639498673.65.0.709719181358.issue46072@roundup.psfhosted.org>
Message-ID: <1644244260.65.0.966311961601.issue46072@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset 062460e8fd54e53c9a1a6f175ef49c9d730851b8 by Mark Shannon in branch 'main':
bpo-46072: Improve LOAD_METHOD stats (GH-31104)
https://github.com/python/cpython/commit/062460e8fd54e53c9a1a6f175ef49c9d730851b8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46072>
_______________________________________

From report at bugs.python.org  Mon Feb  7 09:40:19 2022
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 07 Feb 2022 14:40:19 +0000
Subject: [issue46072] Unify handling of stats in the CPython VM
In-Reply-To: <1639498673.65.0.709719181358.issue46072@roundup.psfhosted.org>
Message-ID: <1644244819.96.0.80715846424.issue46072@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
pull_requests: +29368
pull_request: https://github.com/python/cpython/pull/31197

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46072>
_______________________________________

From report at bugs.python.org  Mon Feb  7 09:54:59 2022
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 07 Feb 2022 14:54:59 +0000
Subject: [issue46639] Ceil division with math.ceildiv
In-Reply-To: <1644002723.68.0.838942257454.issue46639@roundup.psfhosted.org>
Message-ID: <1644245699.73.0.978537044364.issue46639@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

I don't understand why math.ceildiv couldn't ducktype. There's no rule that says it *must* convert arguments to float first, that's just a convention, and we've broken it before.

>>> math.prod([Fraction(1, 3), 7])
Fraction(7, 3)

Couldn't math.ceildiv(x, y) be implemented as -(-x//y) in a type-agnostic fashion?


Perhaps it is too late in the night for me, but I have no idea what ceilrem(x, y) would do or why anyone might want it.

I agree with Vladimir that the import thing is not an issue. If we can require an import for much more important functions as sin, cos, tan, log, etc, then requiring an import is not excessive for a function of secondary importance.

Feature-bloat: its taken 30 years for somebody to request ceildiv. At that rate, it will take another 500 years for us to catch up to mpz in terms of features/bloat. I'm not losing sleep over that :-)

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46639>
_______________________________________

From report at bugs.python.org  Mon Feb  7 10:01:52 2022
From: report at bugs.python.org (Jonathan)
Date: Mon, 07 Feb 2022 15:01:52 +0000
Subject: [issue46667] SequenceMatcher & autojunk - false negative
In-Reply-To: <1644184725.54.0.128225003107.issue46667@roundup.psfhosted.org>
Message-ID: <1644246112.45.0.216314907126.issue46667@roundup.psfhosted.org>


Jonathan <bugreports at lightpear.com> added the comment:

I still don't get how UNIQUESTRING is the longest even with autojunk=True, but that's an implementation detail and I'll trust you that it's working as expected.

Given this, I'd suggest the following then:

* `Autojunk=False` should be the default unless there's some reason to believe SequenceMatcher is mostly used for code comparisons.

* If - for whatever reason - the default can't be changed, I'd suggest a nice big docs "Warning" (at a minimum a "Note") saying something like "The default autojunk=True is not suitable for normal string comparison. See autojunk for more information".

* Human-friendly doc explanation for autojunk. The current explanation is only going to be helpful to the tiny fraction of users who understand the algorithm. Your explanation is a good start:
	"Autojunk was introduced as a way to greatly speed comparing files of code, viewing them as sequences of lines. But it more often backfires when comparing strings (viewed as sequences of characters)"

Put simply: The current docs aren't helpful to users who don't have text matching expertise, nor do they emphasise the huge caveat that autojunk=True raises.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46667>
_______________________________________

From report at bugs.python.org  Mon Feb  7 10:06:41 2022
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 07 Feb 2022 15:06:41 +0000
Subject: [issue46670] Build Python with -Wundef: don't use undefined macros
In-Reply-To: <1644191556.12.0.192524677903.issue46670@roundup.psfhosted.org>
Message-ID: <1644246401.59.0.16609106081.issue46670@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset 4b603f628207b380a8a2f22d7ff5d2dbb0853e2e by Victor Stinner in branch 'main':
bpo-46670: Remove unused macros in ceval.c (GH-31196)
https://github.com/python/cpython/commit/4b603f628207b380a8a2f22d7ff5d2dbb0853e2e


----------
nosy: +Mark.Shannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46670>
_______________________________________

From report at bugs.python.org  Mon Feb  7 10:21:14 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Feb 2022 15:21:14 +0000
Subject: [issue39277] _PyTime_FromDouble() fails to detect an integer overflow
 when converting a C double to a C int64_t
In-Reply-To: <1578581025.66.0.18478821427.issue39277@roundup.psfhosted.org>
Message-ID: <1644247274.08.0.0880002966122.issue39277@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset d3e53bc5321a9f08c7ed5b9383eefb2e03dfa6e2 by Victor Stinner in branch 'main':
bpo-39277: Fix PY_TIMEOUT_MAX cast in _threadmodule.c (GH-31195)
https://github.com/python/cpython/commit/d3e53bc5321a9f08c7ed5b9383eefb2e03dfa6e2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39277>
_______________________________________

From report at bugs.python.org  Mon Feb  7 10:21:35 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Feb 2022 15:21:35 +0000
Subject: [issue46670] Build Python with -Wundef: don't use undefined macros
In-Reply-To: <1644191556.12.0.192524677903.issue46670@roundup.psfhosted.org>
Message-ID: <1644247295.5.0.975001709639.issue46670@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 4f1d3f33dd8b37a151b73533f18b08b0500223e5 by Victor Stinner in branch 'main':
 bpo-46670: Remove unused macros in the Modules directory (GH-31194)
https://github.com/python/cpython/commit/4f1d3f33dd8b37a151b73533f18b08b0500223e5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46670>
_______________________________________

From report at bugs.python.org  Mon Feb  7 10:21:47 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Feb 2022 15:21:47 +0000
Subject: [issue46670] Build Python with -Wundef: don't use undefined macros
In-Reply-To: <1644191556.12.0.192524677903.issue46670@roundup.psfhosted.org>
Message-ID: <1644247307.22.0.118001095771.issue46670@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 760349198dbd8771629753e096a885c1aa28a1ca by Victor Stinner in branch 'main':
bpo-46670: Remove unused macros in the Objects directory (GH-31193)
https://github.com/python/cpython/commit/760349198dbd8771629753e096a885c1aa28a1ca


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46670>
_______________________________________

From report at bugs.python.org  Mon Feb  7 10:21:56 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Feb 2022 15:21:56 +0000
Subject: [issue46670] Build Python with -Wundef: don't use undefined macros
In-Reply-To: <1644191556.12.0.192524677903.issue46670@roundup.psfhosted.org>
Message-ID: <1644247316.62.0.989613227843.issue46670@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 7d8b69e1d1f125454d8cec81ff0dee72f2bef957 by Victor Stinner in branch 'main':
bpo-46670: Remove unused macros in the Python directory (GH-31192)
https://github.com/python/cpython/commit/7d8b69e1d1f125454d8cec81ff0dee72f2bef957


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46670>
_______________________________________

From report at bugs.python.org  Mon Feb  7 10:22:33 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Feb 2022 15:22:33 +0000
Subject: [issue46670] Build Python with -Wundef: don't use undefined macros
In-Reply-To: <1644191556.12.0.192524677903.issue46670@roundup.psfhosted.org>
Message-ID: <1644247353.06.0.221148422486.issue46670@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset f20ca766fe404a20daea29230f161a0eb71bb489 by Victor Stinner in branch 'main':
bpo-46670: Fix #ifdef in sha3module.c (GH-31180)
https://github.com/python/cpython/commit/f20ca766fe404a20daea29230f161a0eb71bb489


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46670>
_______________________________________

From report at bugs.python.org  Mon Feb  7 10:32:31 2022
From: report at bugs.python.org (hydroflask)
Date: Mon, 07 Feb 2022 15:32:31 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644247951.8.0.192004335342.issue46323@roundup.psfhosted.org>


hydroflask <hydroflask at yqxmail.com> added the comment:

> A benchmark on calling C functions using ctypes sounds better than a benchmark calling Python functions.

Calling C functions from Python is not the code path handled by _CallPythonObject() so no difference in run-time would theoretically be observed by that benchmark for this patch. This bug report pertains to code paths where a C function calls back into a Python function. A practical example is using Python with an event loop library written in C.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Mon Feb  7 10:59:09 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Feb 2022 15:59:09 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644249549.39.0.650101986907.issue46323@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Oh ok, thanks for the clarification :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Mon Feb  7 11:02:06 2022
From: report at bugs.python.org (Aaron Gokaslan)
Date: Mon, 07 Feb 2022 16:02:06 +0000
Subject: [issue46166] Get "self" args or non-null co_varnames from frame
 object with C-API
In-Reply-To: <1640288010.25.0.698839040509.issue46166@roundup.psfhosted.org>
Message-ID: <1644249726.24.0.529222346945.issue46166@roundup.psfhosted.org>


Aaron Gokaslan <aaronGokaslan at gmail.com> added the comment:

The frame object I am referring to was:

PyFrameObject *frame = PyThreadState_GetFrame(PyThreadState_Get());

This frame can not be used with PyObject_GetAttrString. Is there anyway to get the PyObject* associated with a PyFrameObject*? It seems weird that some functionality is just not accessible using the Stable ABI of PyThreadState_GetFrame . 

To elabroate: I was referring to the migration guide in the changelog btw:

    f_code: removed, use PyFrame_GetCode() instead. Warning: the function returns a strong reference, need to call Py_DECREF().

    f_back: changed (see below), use PyFrame_GetBack().

    f_builtins: removed, use PyObject_GetAttrString(frame, "f_builtins").
  
    // this frame object actually has to be a PyObject*, the old one was a  PyFrameObject* . Dropping this in does not work. 
    f_globals: removed, use PyObject_GetAttrString(frame, "f_globals").

    f_locals: removed, use PyObject_GetAttrString(frame, "f_locals").

    f_lasti: removed, use PyObject_GetAttrString(frame, "f_lasti").


I tried importing sys._getframe(), but that gave an attribute error interestingly enough. Run a full code snippit here works: https://github.com/pybind/pybind11/blob/96b943be1d39958661047eadac506745ba92b2bc/include/pybind11/pybind11.h#L2429, but is really slow and we would like avoid having to rely on it. Not to mention relying on a function that is an starts with an underscore seems like it really should be avoided.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46166>
_______________________________________

From report at bugs.python.org  Mon Feb  7 11:15:32 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Feb 2022 16:15:32 +0000
Subject: [issue46166] Get "self" args or non-null co_varnames from frame
 object with C-API
In-Reply-To: <1640288010.25.0.698839040509.issue46166@roundup.psfhosted.org>
Message-ID: <1644250532.57.0.985687695893.issue46166@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Example of C code that I added to _testcapi:
---
static PyObject *
get_caller_locals(PyObject *self, PyObject *Py_UNUSED(args))
{
    PyFrameObject *frame = PyThreadState_GetFrame(PyThreadState_Get());
    if (frame == NULL) {
        Py_RETURN_NONE;
    }
    return PyObject_GetAttrString(frame, "f_locals");
}
---

Python example:
---
import _testcapi

def f():
    x = 1
    y = 2
    print(_testcapi.get_caller_locals())

f()
---

Output on Python 3.11:
---
{'x': 1, 'y': 2}
---

=> it just works.

A PyFrameObject is a regular Python object, you can use functions like PyObject_GetAttrString().

Maybe I missed something, correct me if I'm wrong.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46166>
_______________________________________

From report at bugs.python.org  Mon Feb  7 11:17:09 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Feb 2022 16:17:09 +0000
Subject: [issue46166] Get "self" args or non-null co_varnames from frame
 object with C-API
In-Reply-To: <1640288010.25.0.698839040509.issue46166@roundup.psfhosted.org>
Message-ID: <1644250628.99.0.748255916239.issue46166@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Is there anyway to get the PyObject* associated with a PyFrameObject*?

Ah. I see. If you pass a PyFrameObject* frame to PyObject_GetAttrString(), you get a compiler warning.

You should cast it explicitly: PyObject_GetAttrString((PyObject*)frame, "f_locals").

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46166>
_______________________________________

From report at bugs.python.org  Mon Feb  7 11:19:23 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Feb 2022 16:19:23 +0000
Subject: [issue46166] Get "self" args or non-null co_varnames from frame
 object with C-API
In-Reply-To: <1640288010.25.0.698839040509.issue46166@roundup.psfhosted.org>
Message-ID: <1644250763.19.0.331082069857.issue46166@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +29369
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31198

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46166>
_______________________________________

From report at bugs.python.org  Mon Feb  7 11:19:53 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Feb 2022 16:19:53 +0000
Subject: [issue46166] Get "self" args or non-null co_varnames from frame
 object with C-API
In-Reply-To: <1640288010.25.0.698839040509.issue46166@roundup.psfhosted.org>
Message-ID: <1644250793.89.0.835643069513.issue46166@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I proposed GH-31198 to fix the compiler warnings in the doc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46166>
_______________________________________

From report at bugs.python.org  Mon Feb  7 11:20:33 2022
From: report at bugs.python.org (hydroflask)
Date: Mon, 07 Feb 2022 16:20:33 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644250833.7.0.0430515744046.issue46323@roundup.psfhosted.org>


hydroflask <hydroflask at yqxmail.com> added the comment:

Just to clarify further, the original benchmark by corona10 did indeed lead to `_CallPythonObject` being invoked but it was not quite the normal use-case. In the original benchmark it invoked the generated ctypes thunk via Python so as vstinner said it was doing this:

    Python -> converters -> thunk-> _CallPythonObject -> converters-> Python

Namely using `PyCFuncPtr_call` to invoke the thunk generated by `_ctypes_alloc_callback`. Normally when invoking C functions via `PyCFuncPtr_call` it looks like this:

    Python -> converters -> C_function

In the original benchmark setup no significant reduction in runtime was observed by this patch.  I noticed that it was not a typical use of `_CallPythonObject`, where instead it would be a top-level C function calling back into Python. Something like this:

    C -> thunk -> _CallPythonObject() -> Python

The benchmark I provided exercises that use case and the >=10% reduction in runtime was observed. Thanks to both corona10 and vstinner, I appreciate their effort in this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Mon Feb  7 11:20:35 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Feb 2022 16:20:35 +0000
Subject: [issue46166] [C API] Get "self" args or non-null co_varnames from
 frame object with C-API
In-Reply-To: <1640288010.25.0.698839040509.issue46166@roundup.psfhosted.org>
Message-ID: <1644250835.86.0.798060463528.issue46166@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: Get "self" args or non-null co_varnames from frame object with C-API -> [C API] Get "self" args or non-null co_varnames from frame object with C-API

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46166>
_______________________________________

From report at bugs.python.org  Mon Feb  7 11:22:04 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 07 Feb 2022 16:22:04 +0000
Subject: [issue46655] typing.TypeAlias is not in the list of allowed plain
 _SpecialForm typeforms
In-Reply-To: <1644132606.43.0.5970530565.issue46655@roundup.psfhosted.org>
Message-ID: <1644250924.94.0.609711778064.issue46655@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset e2eeffefed32bb8c47c09bdd94e27a4e949894ef by Gregory Beauregard in branch '3.10':
[3.10] bpo-46655: allow stringized TypeAlias with get_type_hints (GH-31156). (#31175)
https://github.com/python/cpython/commit/e2eeffefed32bb8c47c09bdd94e27a4e949894ef


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46655>
_______________________________________

From report at bugs.python.org  Mon Feb  7 11:41:25 2022
From: report at bugs.python.org (pmp-p)
Date: Mon, 07 Feb 2022 16:41:25 +0000
Subject: [issue45459] Limited API support for Py_buffer
In-Reply-To: <1634118913.79.0.141868262007.issue45459@roundup.psfhosted.org>
Message-ID: <1644252085.65.0.673275413459.issue45459@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/issue45459>
_______________________________________

From report at bugs.python.org  Mon Feb  7 11:44:19 2022
From: report at bugs.python.org (Hai Shi)
Date: Mon, 07 Feb 2022 16:44:19 +0000
Subject: [issue46647] `test_functools` unexpected failures when C
 `_functoolsmodule` is missing
In-Reply-To: <1644058014.78.0.386662810799.issue46647@roundup.psfhosted.org>
Message-ID: <1644252259.43.0.96631235532.issue46647@roundup.psfhosted.org>


Hai Shi <shihai1991 at 126.com> added the comment:

> _functoolsmodule is a core bootstrap module and defined in Modules/Setup.bootstrap. It has no external dependencies. There is no reason and no point to disable the module.

+1. 

> Cristian, in this case - is there a reason to keep `skipUnless(c_functools)` around? 
> If we are sure that it is always available - then it should be always tested. 

Hm. Personally, I suggest to keep the `skipUnless` to aovid the code churn.
Or maybe you have other cases to show the functools module will missing unexpectly?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46647>
_______________________________________

From report at bugs.python.org  Mon Feb  7 11:46:31 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Feb 2022 16:46:31 +0000
Subject: [issue46166] [C API] Get "self" args or non-null co_varnames from
 frame object with C-API
In-Reply-To: <1640288010.25.0.698839040509.issue46166@roundup.psfhosted.org>
Message-ID: <1644252391.65.0.489345171419.issue46166@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset a89772c79183e3e62bf61b92077a04f6ebcc4a2b by Victor Stinner in branch 'main':
bpo-46166: Fix compiler warnings in What's New in Python 3.11 (GH-31198)
https://github.com/python/cpython/commit/a89772c79183e3e62bf61b92077a04f6ebcc4a2b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46166>
_______________________________________

From report at bugs.python.org  Mon Feb  7 11:51:53 2022
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 07 Feb 2022 16:51:53 +0000
Subject: [issue46072] Unify handling of stats in the CPython VM
In-Reply-To: <1639498673.65.0.709719181358.issue46072@roundup.psfhosted.org>
Message-ID: <1644252713.03.0.961954577588.issue46072@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset 9c979d7afd839abbb080028bdfeb73727e5cf633 by Mark Shannon in branch 'main':
bpo-46072: Merge dxpairs into py_stats. (GH-31197)
https://github.com/python/cpython/commit/9c979d7afd839abbb080028bdfeb73727e5cf633


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46072>
_______________________________________

From report at bugs.python.org  Mon Feb  7 11:59:50 2022
From: report at bugs.python.org (miss-islington)
Date: Mon, 07 Feb 2022 16:59:50 +0000
Subject: [issue46638] Inconsistent registry virtualization in Windows Store
 package
In-Reply-To: <1643991370.43.0.929070469703.issue46638@roundup.psfhosted.org>
Message-ID: <1644253190.8.0.743413916662.issue46638@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: +29370
pull_request: https://github.com/python/cpython/pull/31199

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46638>
_______________________________________

From report at bugs.python.org  Mon Feb  7 11:59:55 2022
From: report at bugs.python.org (miss-islington)
Date: Mon, 07 Feb 2022 16:59:55 +0000
Subject: [issue46638] Inconsistent registry virtualization in Windows Store
 package
In-Reply-To: <1643991370.43.0.929070469703.issue46638@roundup.psfhosted.org>
Message-ID: <1644253195.55.0.705831060447.issue46638@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29371
pull_request: https://github.com/python/cpython/pull/31200

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46638>
_______________________________________

From report at bugs.python.org  Mon Feb  7 12:00:03 2022
From: report at bugs.python.org (Steve Dower)
Date: Mon, 07 Feb 2022 17:00:03 +0000
Subject: [issue46638] Inconsistent registry virtualization in Windows Store
 package
In-Reply-To: <1643991370.43.0.929070469703.issue46638@roundup.psfhosted.org>
Message-ID: <1644253203.01.0.680371972226.issue46638@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 3a5afc14e16370c1f4f72d43cb553298ad9a1fa4 by Steve Dower in branch 'main':
bpo-46638: Makes registry virtualisation setting stable when building MSIX packages (GH-31130)
https://github.com/python/cpython/commit/3a5afc14e16370c1f4f72d43cb553298ad9a1fa4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46638>
_______________________________________

From report at bugs.python.org  Mon Feb  7 12:22:23 2022
From: report at bugs.python.org (Steve Dower)
Date: Mon, 07 Feb 2022 17:22:23 +0000
Subject: [issue41021] ctypes callback with structure crashes in Python 3.8 on
 Windows x86
In-Reply-To: <1592472376.78.0.985098642017.issue41021@roundup.psfhosted.org>
Message-ID: <1644254543.8.0.908150839844.issue41021@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Only by following the link I posted and searching for issues that sound like this one.

Which I just did for you: https://github.com/libffi/libffi/issues/367

There may be more, though. I just grabbed the first one that looked like a match.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41021>
_______________________________________

From report at bugs.python.org  Mon Feb  7 12:27:50 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 07 Feb 2022 17:27:50 +0000
Subject: [issue46669] Add types.Self
In-Reply-To: <1644189171.85.0.34470950762.issue46669@roundup.psfhosted.org>
Message-ID: <1644254870.68.0.372483578551.issue46669@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

On a related note, is this the correct way to annotate __exit__?


Exc = TypeVar('Exc', bound=Exception)

def __exit__(self, exctype: Optional[Type[Exc]], excinst: Optional[Exc], exctb: Any) -> None:

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46669>
_______________________________________

From report at bugs.python.org  Mon Feb  7 12:31:47 2022
From: report at bugs.python.org (miss-islington)
Date: Mon, 07 Feb 2022 17:31:47 +0000
Subject: [issue46638] Inconsistent registry virtualization in Windows Store
 package
In-Reply-To: <1643991370.43.0.929070469703.issue46638@roundup.psfhosted.org>
Message-ID: <1644255107.79.0.951269445582.issue46638@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 9c45390208df712126c59f7c2b6f8d2b4e19ccf7 by Miss Islington (bot) in branch '3.10':
bpo-46638: Makes registry virtualisation setting stable when building MSIX packages (GH-31130)
https://github.com/python/cpython/commit/9c45390208df712126c59f7c2b6f8d2b4e19ccf7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46638>
_______________________________________

From report at bugs.python.org  Mon Feb  7 12:31:53 2022
From: report at bugs.python.org (=?utf-8?b?VsOhY2xhdiBEdm/FmcOhaw==?=)
Date: Mon, 07 Feb 2022 17:31:53 +0000
Subject: [issue12029] Allow catching virtual subclasses in except clauses
In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za>
Message-ID: <1644255113.8.0.918738567548.issue12029@roundup.psfhosted.org>


Change by V?clav Dvo??k <vashek at gmail.com>:


----------
nosy: +V?clav Dvo??k

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12029>
_______________________________________

From report at bugs.python.org  Mon Feb  7 12:36:18 2022
From: report at bugs.python.org (pmp-p)
Date: Mon, 07 Feb 2022 17:36:18 +0000
Subject: [issue45459] Limited API support for Py_buffer
In-Reply-To: <1634118913.79.0.141868262007.issue45459@roundup.psfhosted.org>
Message-ID: <1644255378.19.0.668865368207.issue45459@roundup.psfhosted.org>


pmp-p <pmpp.pub at gmail.com> added the comment:

There's some side effects with "buffer.h" inclusion in Panda3D when building againt 3.11a5, project manager concerns are here https://github.com/python/cpython/pull/29991#issuecomment-1031731100

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45459>
_______________________________________

From report at bugs.python.org  Mon Feb  7 12:37:15 2022
From: report at bugs.python.org (Steve Dower)
Date: Mon, 07 Feb 2022 17:37:15 +0000
Subject: [issue46638] Inconsistent registry virtualization in Windows Store
 package
In-Reply-To: <1643991370.43.0.929070469703.issue46638@roundup.psfhosted.org>
Message-ID: <1644255435.1.0.521313415834.issue46638@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 76b072717a160c44cb8d54be3d5e878bc31f2c38 by Miss Islington (bot) in branch '3.9':
bpo-46638: Makes registry virtualisation setting stable when building MSIX packages (GH-31130)
https://github.com/python/cpython/commit/76b072717a160c44cb8d54be3d5e878bc31f2c38


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46638>
_______________________________________

From report at bugs.python.org  Mon Feb  7 12:41:20 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Feb 2022 17:41:20 +0000
Subject: [issue45459] Limited API support for Py_buffer
In-Reply-To: <1634118913.79.0.141868262007.issue45459@roundup.psfhosted.org>
Message-ID: <1644255680.87.0.666460529384.issue45459@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> There's some side effects with "buffer.h" inclusion in Panda3D when building againt 3.11a5, project manager concerns are here https://github.com/python/cpython/pull/29991#issuecomment-1031731100

Copy of rdb's message:
"""
This change broke our project build because when cpython/object.h is including buffer.h it is forcing it to resolve along the search path, and the compiler is hitting the buffer.h in our project rather than the one in the Python include directory.

Should it not be using a relative include, ie. #include "../buffer.h" ? I think otherwise this change will cause breakage for many projects given how common the header name "buffer.h" may be.
"""

In Python.h, buffer.h is included before object.h. But object.h includes buffer.h. I suggest to include buffer.h before object.h and remove #include "buffer.h" from Include/cpython/buffer.h.

Also, I agree that renaming buffer.h to pybuffer.h would reduce issues like that. Moreover, this header file exposes the "Py_buffer" API, so "pybuffer.h" sounds like a better name ;-)

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45459>
_______________________________________

From report at bugs.python.org  Mon Feb  7 12:44:52 2022
From: report at bugs.python.org (=?utf-8?b?VsOhY2xhdiBEdm/FmcOhaw==?=)
Date: Mon, 07 Feb 2022 17:44:52 +0000
Subject: [issue12029] Allow catching virtual subclasses in except clauses
In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za>
Message-ID: <1644255892.12.0.0116334854329.issue12029@roundup.psfhosted.org>


Change by V?clav Dvo??k <vashek at gmail.com>:


----------
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12029>
_______________________________________

From report at bugs.python.org  Mon Feb  7 12:47:54 2022
From: report at bugs.python.org (rdb)
Date: Mon, 07 Feb 2022 17:47:54 +0000
Subject: [issue45459] Limited API support for Py_buffer
In-Reply-To: <1634118913.79.0.141868262007.issue45459@roundup.psfhosted.org>
Message-ID: <1644256074.16.0.651277885796.issue45459@roundup.psfhosted.org>


Change by rdb <rddeblois at gmail.com>:


----------
nosy: +rdb

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45459>
_______________________________________

From report at bugs.python.org  Mon Feb  7 12:48:06 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Feb 2022 17:48:06 +0000
Subject: [issue45459] Limited API support for Py_buffer
In-Reply-To: <1634118913.79.0.141868262007.issue45459@roundup.psfhosted.org>
Message-ID: <1644256086.7.0.805901637845.issue45459@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29372
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/31201

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45459>
_______________________________________

From report at bugs.python.org  Mon Feb  7 12:53:46 2022
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 07 Feb 2022 17:53:46 +0000
Subject: [issue46668] encodings: the "mbcs" alias doesn't work
In-Reply-To: <1644188809.05.0.861398707442.issue46668@roundup.psfhosted.org>
Message-ID: <1644256426.75.0.396130146485.issue46668@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> I don't think that this fallback is needed anymore. Which Windows
> code page can be used as ANSI code page which is not already 
> implemented as a Python codec?

Python has full coverage of the ANSI and OEM code pages in the standard Windows locales, but I don't have any experience with custom (i.e. supplemental or replacement) locales.

https://docs.microsoft.com/en-us/windows/win32/intl/custom-locales 

Here's a simple script to check the standard locales.

    import codecs
    import ctypes
    kernel32 = ctypes.WinDLL('kernel32', use_last_error=True)

    LOCALE_ALL = 0
    LOCALE_WINDOWS = 1
    LOCALE_IDEFAULTANSICODEPAGE = 0x1004
    LOCALE_IDEFAULTCODEPAGE = 0x000B # OEM

    EnumSystemLocalesEx = kernel32.EnumSystemLocalesEx
    GetLocaleInfoEx = kernel32.GetLocaleInfoEx
    GetCPInfoExW = kernel32.GetCPInfoExW

    EnumLocalesProcEx = ctypes.WINFUNCTYPE(ctypes.c_int,
        ctypes.c_wchar_p, ctypes.c_ulong, ctypes.c_void_p)

    class CPINFOEXW(ctypes.Structure):
         _fields_ = (('MaxCharSize', ctypes.c_uint),
                     ('DefaultChar', ctypes.c_ubyte * 2),
                     ('LeadByte', ctypes.c_ubyte * 12),
                     ('UnicodeDefaultChar', ctypes.c_wchar),
                     ('CodePage', ctypes.c_uint),
                     ('CodePageName', ctypes.c_wchar * 260))

    def get_all_locale_code_pages():
        result = []
        seen = set()
        info = (ctypes.c_wchar * 100)()

        @EnumLocalesProcEx
        def callback(locale, flags, param):
            for lctype in (LOCALE_IDEFAULTANSICODEPAGE, LOCALE_IDEFAULTCODEPAGE):
                if (GetLocaleInfoEx(locale, lctype, info, len(info)) and
                      info.value not in ('0', '1')):
                    cp = int(info.value)
                    if cp in seen:
                        continue
                    seen.add(cp)
                    cp_info = CPINFOEXW()
                    if not GetCPInfoExW(cp, 0, ctypes.byref(cp_info)):
                        cp_info.CodePage = cp
                        cp_info.CodePageName = str(cp)
                    result.append(cp_info)
            return True

        if not EnumSystemLocalesEx(callback, LOCALE_WINDOWS, None, None):
            raise ctypes.WinError(ctypes.get_last_error())

        result.sort(key=lambda x: x.CodePage)
        return result

    supported = []
    unsupported = []
    for cp_info in get_all_locale_code_pages():
        cp = cp_info.CodePage
        try:
            codecs.lookup(f'cp{cp}')
        except LookupError:
            unsupported.append(cp_info)
        else:
            supported.append(cp_info)

    if unsupported:
        print('Unsupported:\n')
        for cp_info in unsupported:
            print(cp_info.CodePageName)
        print('\nSupported:\n')
    else:
        print('All Supported:\n')
    for cp_info in supported:
        print(cp_info.CodePageName)


Output:

    All Supported:

    437   (OEM - United States)
    720   (Arabic - Transparent ASMO)
    737   (OEM - Greek 437G)
    775   (OEM - Baltic)
    850   (OEM - Multilingual Latin I)
    852   (OEM - Latin II)
    855   (OEM - Cyrillic)
    857   (OEM - Turkish)
    862   (OEM - Hebrew)
    866   (OEM - Russian)
    874   (ANSI/OEM - Thai)
    932   (ANSI/OEM - Japanese Shift-JIS)
    936   (ANSI/OEM - Simplified Chinese GBK)
    949   (ANSI/OEM - Korean)
    950   (ANSI/OEM - Traditional Chinese Big5)
    1250  (ANSI - Central Europe)
    1251  (ANSI - Cyrillic)
    1252  (ANSI - Latin I)
    1253  (ANSI - Greek)
    1254  (ANSI - Turkish)
    1255  (ANSI - Hebrew)
    1256  (ANSI - Arabic)
    1257  (ANSI - Baltic)
    1258  (ANSI/OEM - Viet Nam)

Some locales are Unicode only (e.g. Hindi-India) or have no OEM code page, which the above code skips by checking for "0" or "1" as the code page value. Windows 10+ allows setting the system locale to a Unicode-only locale, for which it uses UTF-8 (65001) for ANSI and OEM.

The OEM code page matters because the console input and output code pages default to OEM, e.g. for os.device_encoding(). The console's I/O code pages are used in Python by low-level os.read() and os.write(). Note that the console doesn't properly implement using UTF-8 (65001) as the input code page. In this case, input read from the console via ReadFile() or ReadConsoleA() has a null byte in place of each non-ASCII character.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46668>
_______________________________________

From report at bugs.python.org  Mon Feb  7 13:09:47 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 07 Feb 2022 18:09:47 +0000
Subject: [issue46669] Add types.Self
In-Reply-To: <1644189171.85.0.34470950762.issue46669@roundup.psfhosted.org>
Message-ID: <1644257387.68.0.901934208716.issue46669@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Implementing PEP 673 (Self type)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46669>
_______________________________________

From report at bugs.python.org  Mon Feb  7 13:12:44 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 07 Feb 2022 18:12:44 +0000
Subject: [issue12029] Allow catching virtual subclasses in except clauses
In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za>
Message-ID: <1644257564.52.0.187565902835.issue12029@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Fixing the version field. Since it's a feature, this could not go into any version before 3.11.

Maybe Irit can look through the discussion and patch and see if there's value to doing this? (Feel free to decline!)

----------
nosy: +iritkatriel
versions: +Python 3.11 -Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12029>
_______________________________________

From report at bugs.python.org  Mon Feb  7 13:14:16 2022
From: report at bugs.python.org (Tim Peters)
Date: Mon, 07 Feb 2022 18:14:16 +0000
Subject: [issue46667] SequenceMatcher & autojunk - false negative
In-Reply-To: <1644184725.54.0.128225003107.issue46667@roundup.psfhosted.org>
Message-ID: <1644257656.16.0.210171779182.issue46667@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

We can't change defaults without superb reason - Python has millions of users, and changing the output of code "that works" is almost always a non-starter.

Improvements to the docs are welcome.

In your example, try running this code after using autojunk=True:

    pending = ""
    for ch in first:
        if ch in sm.bpopular:
            if pending:
                print(repr(pending))
                pending = ""
        else:
            pending += ch
    print(repr(pending))

That shows how `first` is effectively broken into tiny pieces given that the "popular" chaaracters act like walls. Here's the start of the output:

'\nUN'
'QUESTR'
'NG\nL'
'x'
'f'
'.'
'L'
'b'
"'"
'x'
'v'
'1500'
','

and on & on. `QUESTER' is the longest common contiguous substring remaining.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46667>
_______________________________________

From report at bugs.python.org  Mon Feb  7 14:01:40 2022
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 07 Feb 2022 19:01:40 +0000
Subject: [issue46639] Ceil division with math.ceildiv
In-Reply-To: <1644002723.68.0.838942257454.issue46639@roundup.psfhosted.org>
Message-ID: <1644260500.76.0.502443775554.issue46639@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Couldn't math.ceildiv(x, y) be implemented as -(-x//y) in a type-agnostic fashion?

Ah, good point. Yes, that could work.

We'd have to decide what to do about Decimal if we took this approach, since the -(-x//y) trick doesn't work there. (Document the issue? Try to make things work for Decimal?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46639>
_______________________________________

From report at bugs.python.org  Mon Feb  7 14:16:53 2022
From: report at bugs.python.org (Gregory Beauregard)
Date: Mon, 07 Feb 2022 19:16:53 +0000
Subject: [issue46676] ParamSpec args and kwargs are not equal to themselves.
Message-ID: <1644261413.4.0.310987915665.issue46676@roundup.psfhosted.org>


New submission from Gregory Beauregard <greg at greg.red>:

from typing import ParamSpec
P = ParamSpec("P")
print(P.args == P.args)  # False
print(P.kwargs == P.kwargs)  # False

ParamSpec args and kwargs are not equal to themselves; this can cause problems for unit tests and type introspection w/ e.g. `get_type_hints`.

I will fix this by adding an __eq__ method like other places in typing.py

----------
components: Library (Lib)
messages: 412781
nosy: GBeauregard, Jelle Zijlstra
priority: normal
severity: normal
status: open
title: ParamSpec args and kwargs are not equal to themselves.
type: behavior
versions: Python 3.10, Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46676>
_______________________________________

From report at bugs.python.org  Mon Feb  7 14:19:11 2022
From: report at bugs.python.org (Gregory Beauregard)
Date: Mon, 07 Feb 2022 19:19:11 +0000
Subject: [issue46676] ParamSpec args and kwargs are not equal to themselves.
In-Reply-To: <1644261413.4.0.310987915665.issue46676@roundup.psfhosted.org>
Message-ID: <1644261551.47.0.664175070577.issue46676@roundup.psfhosted.org>


Change by Gregory Beauregard <greg at greg.red>:


----------
keywords: +patch
pull_requests: +29373
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31203

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46676>
_______________________________________

From report at bugs.python.org  Mon Feb  7 14:20:39 2022
From: report at bugs.python.org (Andy S)
Date: Mon, 07 Feb 2022 19:20:39 +0000
Subject: [issue42548] debugger stops at breakpoint of `pass` that is not
 actually reached
In-Reply-To: <1606948585.89.0.450511023817.issue42548@roundup.psfhosted.org>
Message-ID: <1644261639.05.0.628128477806.issue42548@roundup.psfhosted.org>


Andy S <gatekeeper.mail at gmail.com> added the comment:

Can reproduce this on 3.9. Is the fact 3.9 is in `bugfix` status enough to backport any fixing changes from 3.11 (if that's true and the bug was fixed)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42548>
_______________________________________

From report at bugs.python.org  Mon Feb  7 14:23:45 2022
From: report at bugs.python.org (Irit Katriel)
Date: Mon, 07 Feb 2022 19:23:45 +0000
Subject: [issue42548] debugger stops at breakpoint of `pass` that is not
 actually reached
In-Reply-To: <1606948585.89.0.450511023817.issue42548@roundup.psfhosted.org>
Message-ID: <1644261825.27.0.88426192708.issue42548@roundup.psfhosted.org>


Irit Katriel <iritkatriel at gmail.com> added the comment:

It depends how risky the 3.9 release manager would consider the fix to be. The first step would be to find out which commit(s) fixed it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42548>
_______________________________________

From report at bugs.python.org  Mon Feb  7 14:27:59 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Mon, 07 Feb 2022 19:27:59 +0000
Subject: [issue46677] TypedDict docs are incomplete
Message-ID: <1644262079.95.0.663870450502.issue46677@roundup.psfhosted.org>


New submission from Jelle Zijlstra <jelle.zijlstra at gmail.com>:

https://docs.python.org/3.10/library/typing.html#typing.TypedDict

It says:

> To allow using this feature with older versions of Python that do not support PEP 526, TypedDict supports two additional equivalent syntactic forms

But there is another reason to use the equivalent forms: if your keys aren't valid Python names. There's an example in typeshed that uses "in" (a keyword) as a TypedDict key, and I've seen others with keys that have hyphens in them.

Also:

- The docs mention attributes like `__required_keys__`, but don't clearly say what is in these attributes. We should document them explicitly with the standard syntax for attributes.
- There is no mention of one TypedDict inheriting from another.

----------
assignee: docs at python
components: Documentation
messages: 412784
nosy: 97littleleaf11, AlexWaygood, Jelle Zijlstra, docs at python, sobolevn
priority: normal
severity: normal
status: open
title: TypedDict docs are incomplete
versions: Python 3.10, Python 3.11, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46677>
_______________________________________

From report at bugs.python.org  Mon Feb  7 14:37:34 2022
From: report at bugs.python.org (Andy S)
Date: Mon, 07 Feb 2022 19:37:34 +0000
Subject: [issue42548] debugger stops at breakpoint of `pass` that is not
 actually reached
In-Reply-To: <1606948585.89.0.450511023817.issue42548@roundup.psfhosted.org>
Message-ID: <1644262654.17.0.0442317127042.issue42548@roundup.psfhosted.org>


Andy S <gatekeeper.mail at gmail.com> added the comment:

Then maybe those RMs (for 3.9 and 3.10) should decide on their own? That should mean the bug should be reopened for them to get assigned to.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42548>
_______________________________________

From report at bugs.python.org  Mon Feb  7 14:42:03 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Mon, 07 Feb 2022 19:42:03 +0000
Subject: [issue46669] Add types.Self
In-Reply-To: <1644189171.85.0.34470950762.issue46669@roundup.psfhosted.org>
Message-ID: <1644262923.67.0.331833321358.issue46669@roundup.psfhosted.org>


Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:

The conventional way is to write

def __exit__(
    self,
    __typ: type[BaseException] | None,
    __exc: BaseException | None,
    __tb: types.TracebackType | None,
) -> None: ...

But there are two invariants about how __exit__ works in practice that this doesn't capture:
1. The arguments are either all None, or none of them are
2. If they are not None, then the typ argument is the type of the exception passed to the exc argument

I believe these invariants are always true in 3.11 thanks to Irit's work, but previously there could be rare circumstances where they didn't hold. You probably know the details better than I do.

We could support the first invariant by using two overloads, one where the arguments are all None and one where they aren't. I don't think that's generally worth doing though: it's a lot of verbose code and doesn't fix many real problems.

Your suggested signature looks like it's trying to support the second invariant, but it doesn't quite: if the types don't match, the type checker will just set T to the common base type of the two arguments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46669>
_______________________________________

From report at bugs.python.org  Mon Feb  7 14:42:07 2022
From: report at bugs.python.org (Jaspar S.)
Date: Mon, 07 Feb 2022 19:42:07 +0000
Subject: [issue20779] Add pathlib.chown method
In-Reply-To: <1393408310.22.0.917230781145.issue20779@psf.upfronthosting.co.za>
Message-ID: <1644262927.07.0.677712976474.issue20779@roundup.psfhosted.org>


Jaspar S. <jaspar.loechte at greenbone.net> added the comment:

I would love to use chown for a pathlib Path, too.

It may not be used often, but if anyone want's to change all the os references from a file, it would be cool to have it on pathlib!

----------
nosy: +y0urself

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20779>
_______________________________________

From report at bugs.python.org  Mon Feb  7 14:42:16 2022
From: report at bugs.python.org (Irit Katriel)
Date: Mon, 07 Feb 2022 19:42:16 +0000
Subject: [issue42548] debugger stops at breakpoint of `pass` that is not
 actually reached
In-Reply-To: <1606948585.89.0.450511023817.issue42548@roundup.psfhosted.org>
Message-ID: <1644262936.65.0.410692867924.issue42548@roundup.psfhosted.org>


Irit Katriel <iritkatriel at gmail.com> added the comment:

Fine, I?ll reopen it for 3.9. However, realistically the release managers are unlikely to investigate how this bug got fixed between 3.9 and 3.11 so if you think this is important you might want to do that work.

----------
resolution: out of date -> 
status: closed -> open
versions: +Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42548>
_______________________________________

From report at bugs.python.org  Mon Feb  7 14:57:49 2022
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 07 Feb 2022 19:57:49 +0000
Subject: [issue46586] In documentation contents enum.property erroneously
 links to built-in property
In-Reply-To: <1643555525.86.0.209520180874.issue46586@roundup.psfhosted.org>
Message-ID: <1644263869.45.0.136946752703.issue46586@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> added the comment:

Using a substitution is necessary when we need code markup and a link.

For this bug, the simple ~ markup will be enough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46586>
_______________________________________

From report at bugs.python.org  Mon Feb  7 15:15:45 2022
From: report at bugs.python.org (miss-islington)
Date: Mon, 07 Feb 2022 20:15:45 +0000
Subject: [issue46648] `test.test_urllib2.MiscTests.test_issue16464` flaky due
 to external connection
In-Reply-To: <1644061533.84.0.594817920054.issue46648@roundup.psfhosted.org>
Message-ID: <1644264945.35.0.178458566336.issue46648@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 9539400390494f4930c245b3f98453592f4a1a8c by Miss Islington (bot) in branch '3.10':
[3.10] bpo-46648: Rewrite test_urllib2.test_issue16464() with a local HTTP server (GH-31186) (GH-31189)
https://github.com/python/cpython/commit/9539400390494f4930c245b3f98453592f4a1a8c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46648>
_______________________________________

From report at bugs.python.org  Mon Feb  7 15:30:36 2022
From: report at bugs.python.org (Jason Wilkes)
Date: Mon, 07 Feb 2022 20:30:36 +0000
Subject: [issue46678] Invalid cross device link in
 Lib/test/support/import_helper.py
Message-ID: <1644265836.23.0.316073606856.issue46678@roundup.psfhosted.org>


New submission from Jason Wilkes <notarealdeveloper at gmail.com>:

In Lib/test/support/import_helper.py, the function make_legacy_pyc makes a call to os.rename which can fail when the source and target live on different devices. This happens (for example) when PYTHONPYCACHEPREFIX is set to a directory on a different device from where temporary files are stored. Replacing os.rename with shutil.move fixes it. Will submit a PR.

----------
components: Tests
messages: 412791
nosy: notarealdeveloper
priority: normal
severity: normal
status: open
title: Invalid cross device link in Lib/test/support/import_helper.py
type: behavior
versions: Python 3.10, Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46678>
_______________________________________

From report at bugs.python.org  Mon Feb  7 15:47:59 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 07 Feb 2022 20:47:59 +0000
Subject: [issue46534] Implementing PEP 673 (Self type)
In-Reply-To: <1643194672.13.0.506968505606.issue46534@roundup.psfhosted.org>
Message-ID: <1644266879.28.0.214722678388.issue46534@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset 7ba1cc8049fbcb94ac039ab02522f78177130588 by James Hilton-Balfe in branch 'main':
bpo-46534: Implement PEP 673 Self in typing.py (GH-30924)
https://github.com/python/cpython/commit/7ba1cc8049fbcb94ac039ab02522f78177130588


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46534>
_______________________________________

From report at bugs.python.org  Mon Feb  7 16:00:00 2022
From: report at bugs.python.org (Jason Wilkes)
Date: Mon, 07 Feb 2022 21:00:00 +0000
Subject: [issue46678] Invalid cross device link in
 Lib/test/support/import_helper.py
In-Reply-To: <1644265836.23.0.316073606856.issue46678@roundup.psfhosted.org>
Message-ID: <1644267600.33.0.910199457695.issue46678@roundup.psfhosted.org>


Change by Jason Wilkes <notarealdeveloper at gmail.com>:


----------
keywords: +patch
pull_requests: +29374
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31204

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46678>
_______________________________________

From report at bugs.python.org  Mon Feb  7 16:22:25 2022
From: report at bugs.python.org (Jason Wilkes)
Date: Mon, 07 Feb 2022 21:22:25 +0000
Subject: [issue46679] test.support.wait_process ignores timeout argument
Message-ID: <1644268945.76.0.936309177383.issue46679@roundup.psfhosted.org>


New submission from Jason Wilkes <notarealdeveloper at gmail.com>:

The function wait_process in Lib/test/support/__init__.py ignores its timeout argument. This argument is useful, for example, in tests that need to determine whether a deadlock has been fixed (e.g., in PR-30310). Will submit a pull request to fix this.

----------
components: Tests
messages: 412793
nosy: notarealdeveloper
priority: normal
severity: normal
status: open
title: test.support.wait_process ignores timeout argument
type: behavior
versions: Python 3.10, Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46679>
_______________________________________

From report at bugs.python.org  Mon Feb  7 16:30:24 2022
From: report at bugs.python.org (Jason Wilkes)
Date: Mon, 07 Feb 2022 21:30:24 +0000
Subject: [issue46679] test.support.wait_process ignores timeout argument
In-Reply-To: <1644268945.76.0.936309177383.issue46679@roundup.psfhosted.org>
Message-ID: <1644269424.02.0.0713810892312.issue46679@roundup.psfhosted.org>


Change by Jason Wilkes <notarealdeveloper at gmail.com>:


----------
keywords: +patch
pull_requests: +29375
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31205

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46679>
_______________________________________

From report at bugs.python.org  Mon Feb  7 17:01:53 2022
From: report at bugs.python.org (Steve Dower)
Date: Mon, 07 Feb 2022 22:01:53 +0000
Subject: [issue45413] Add install scheme for virtual environments
In-Reply-To: <1633715402.49.0.434363843275.issue45413@roundup.psfhosted.org>
Message-ID: <1644271313.47.0.896354490014.issue45413@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I think we want the scheme to be static and accessible on all platforms, like the others. So it probably should be 'nt_venv' and 'posix_venv' with additional/improved logic to help apps determine when they need each.

----------
nosy: +steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45413>
_______________________________________

From report at bugs.python.org  Mon Feb  7 17:08:55 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Feb 2022 22:08:55 +0000
Subject: [issue46648] `test.test_urllib2.MiscTests.test_issue16464` flaky due
 to external connection
In-Reply-To: <1644061533.84.0.594817920054.issue46648@roundup.psfhosted.org>
Message-ID: <1644271735.18.0.0213909997808.issue46648@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I close again the issue. The 3.8 backport is waiting for the Python 3.8 Release Manager approval.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46648>
_______________________________________

From report at bugs.python.org  Mon Feb  7 17:35:15 2022
From: report at bugs.python.org (Neil Schemenauer)
Date: Mon, 07 Feb 2022 22:35:15 +0000
Subject: [issue46657] Add mimalloc memory allocator
In-Reply-To: <1644158952.9.0.443530192167.issue46657@roundup.psfhosted.org>
Message-ID: <1644273315.65.0.203327403692.issue46657@roundup.psfhosted.org>


Neil Schemenauer <nas-python at arctrix.com> added the comment:

My preference would be for --with-mimalloc=yes in an upcoming release. For platforms without the required stdatomic.h stuff, they can manually specify --with-mimalloc=no.  That will make them aware that a future release of Python might no longer build (if mimalloc is no longer optional).

A soft-landing for merging nogil is not a good enough reason to merge mimalloc, IMHO.  nogil may never be merged.  There should be some concrete and immediate advantage to switch to mimalloc.  The idea of using the "heap walking" to improve is cyclic GC is not concrete enough.  It's just an idea at this point.

I think the (small) performance win could be enough of a reason to merge.  This seems to be the most recent benchmark:

https://gist.github.com/pablogsal/8027937b71cd30f17aaaa5ef7c885d3e

There is also the long-term maintenance issue.  So far, mimalloc upstream has been responsive.  The mimalloc code is not so huge or complicated that we couldn't maintain it (if for some reason it gets abandoned upstream).  However, I think we would prefer to maintain obmalloc rather than mimalloc, all else being equal.  Abandonment by the upstream seems fairly unlikely.  So, I'm not too concerned about maintenance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46657>
_______________________________________

From report at bugs.python.org  Mon Feb  7 17:39:55 2022
From: report at bugs.python.org (Ned Batchelder)
Date: Mon, 07 Feb 2022 22:39:55 +0000
Subject: [issue46282] return value of builtins is not clearly indicated
In-Reply-To: <1641482082.12.0.793901620769.issue46282@roundup.psfhosted.org>
Message-ID: <1644273595.16.0.515378616436.issue46282@roundup.psfhosted.org>


Ned Batchelder <ned at nedbatchelder.com> added the comment:

> When you state the obvious...

Obvious to who? New learners coming to Python don't know the same things as people with experience.

----------
nosy: +nedbat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46282>
_______________________________________

From report at bugs.python.org  Mon Feb  7 18:00:58 2022
From: report at bugs.python.org (Michael McCoy)
Date: Mon, 07 Feb 2022 23:00:58 +0000
Subject: [issue12029] Allow catching virtual subclasses in except clauses
In-Reply-To: <1644257564.52.0.187565902835.issue12029@roundup.psfhosted.org>
Message-ID: <CA+VxGKB5pwmVG2zxZwuDrcEduve-cxcV8YEk8H2HkD6E8NPhRQ@mail.gmail.com>


Michael McCoy <michael.b.mccoy at gmail.com> added the comment:

Checking my comment history here, a past me was terribly bad at linking the
correct PR on github.This is the correct link:
https://github.com/python/cpython/pull/6461

On Mon, Feb 7, 2022 at 10:12 AM Guido van Rossum <report at bugs.python.org>
wrote:

>
> Guido van Rossum <guido at python.org> added the comment:
>
> Fixing the version field. Since it's a feature, this could not go into any
> version before 3.11.
>
> Maybe Irit can look through the discussion and patch and see if there's
> value to doing this? (Feel free to decline!)
>
> ----------
> nosy: +iritkatriel
> versions: +Python 3.11 -Python 3.4, Python 3.5, Python 3.6, Python 3.7,
> Python 3.8, Python 3.9
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue12029>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12029>
_______________________________________

From report at bugs.python.org  Mon Feb  7 18:23:46 2022
From: report at bugs.python.org (Irit Katriel)
Date: Mon, 07 Feb 2022 23:23:46 +0000
Subject: [issue12029] Allow catching virtual subclasses in except clauses
In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za>
Message-ID: <1644276226.51.0.256945359553.issue12029@roundup.psfhosted.org>


Irit Katriel <iritkatriel at gmail.com> added the comment:

To summarise the discussion so far:

The arguments in favour of changing exception matching to match on virtual base classes are:

1. It is confusing that it doesn't follow issubclass semantics.
2. Two use cases were presented as practical motivation.
   - one in msg135521, which can be solved with the pattern in msg200418
   - one in msg200829, which is typically done with
     except:
         if condition:
              handle
         raise

The arguments against the change are
1. safety - calling python code from the exception propagation code
2. possible performance impact


I am not too worried about the performance of exception handling. I am also not impressed by the use cases.

For me it's mostly between the safety issue and the aesthetic language consistency issue. 

The code path from when a RAISE opcode executes and until control passes to an except clause, is a very sensitive one and I have a lot of sympathy to the position that we should just change the documentation to say that matching is on non-virtual base classes.  It is much easier to implement this feature than to predict how it would behave in all cases.

If we do decide to implement this, then I don't think the patch is the way we should do it. If the IsSubclass call fails, this should result in a "goto error", like when the match type is invalid: 
https://github.com/python/cpython/blob/7ba1cc8049fbcb94ac039ab02522f78177130588/Python/ceval.c#L3831

This means that the failure to determine whether the exception is a match is the dominant error, rather than something we print to the ether via the unraisablehook and interpret as non-match.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12029>
_______________________________________

From report at bugs.python.org  Mon Feb  7 18:24:43 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Feb 2022 23:24:43 +0000
Subject: [issue46659] Deprecate locale.getdefaultlocale() function
In-Reply-To: <1644168794.44.0.0658923518102.issue46659@roundup.psfhosted.org>
Message-ID: <1644276283.37.0.696247681146.issue46659@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 7a0486eaa98083e0407ff491872db6d7a0da2635 by Victor Stinner in branch 'main':
bpo-46659: calendar uses locale.getlocale() (GH-31166)
https://github.com/python/cpython/commit/7a0486eaa98083e0407ff491872db6d7a0da2635


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46659>
_______________________________________

From report at bugs.python.org  Mon Feb  7 18:37:27 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Feb 2022 23:37:27 +0000
Subject: [issue43557] Deprecate getdefaultlocale(),
 getlocale() and normalize() functions
In-Reply-To: <1616160447.56.0.84902377628.issue43557@roundup.psfhosted.org>
Message-ID: <1644277047.67.0.124944564121.issue43557@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +29376
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31206

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43557>
_______________________________________

From report at bugs.python.org  Mon Feb  7 19:13:52 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 08 Feb 2022 00:13:52 +0000
Subject: [issue12029] Allow catching virtual subclasses in except clauses
In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za>
Message-ID: <1644279232.75.0.572693629236.issue12029@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Thanks you. I think it's reasonable to reject the feature request and instead update the docs, so let's do that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12029>
_______________________________________

From report at bugs.python.org  Mon Feb  7 19:15:41 2022
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Feb 2022 00:15:41 +0000
Subject: [issue46659] Deprecate locale.getdefaultlocale() function
In-Reply-To: <1644168794.44.0.0658923518102.issue46659@roundup.psfhosted.org>
Message-ID: <1644279341.93.0.145479484476.issue46659@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29377
pull_request: https://github.com/python/cpython/pull/31206

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46659>
_______________________________________

From report at bugs.python.org  Mon Feb  7 20:09:24 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 08 Feb 2022 01:09:24 +0000
Subject: [issue46678] Invalid cross device link in
 Lib/test/support/import_helper.py
In-Reply-To: <1644265836.23.0.316073606856.issue46678@roundup.psfhosted.org>
Message-ID: <1644282564.6.0.285154354982.issue46678@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: +29378
pull_request: https://github.com/python/cpython/pull/31207

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46678>
_______________________________________

From report at bugs.python.org  Mon Feb  7 20:09:27 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 08 Feb 2022 01:09:27 +0000
Subject: [issue46678] Invalid cross device link in
 Lib/test/support/import_helper.py
In-Reply-To: <1644265836.23.0.316073606856.issue46678@roundup.psfhosted.org>
Message-ID: <1644282567.74.0.043716405904.issue46678@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset da576e08296490e94924421af71001bcfbccb317 by Jason Wilkes in branch 'main':
bpo-46678: Fix Invalid cross device link in Lib/test/support/import_helper.py (GH-31204)
https://github.com/python/cpython/commit/da576e08296490e94924421af71001bcfbccb317


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46678>
_______________________________________

From report at bugs.python.org  Mon Feb  7 20:19:29 2022
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 08 Feb 2022 01:19:29 +0000
Subject: [issue46639] Ceil division with math.ceildiv
In-Reply-To: <1644260500.76.0.502443775554.issue46639@roundup.psfhosted.org>
Message-ID: <20220208011850.GT16660@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Decimal is a good question.

Why does floor division not do floor division on Decimal? The 
documentation says

    The integer division operator // behaves analogously, returning the 
    integer part of the true quotient (truncating towards zero) rather 
    than its floor, so as to preserve the usual identity 
    x == (x // y) * y + x % y

but it's not clear why that identity is more important than floor 
division returning the floor.

I guess we could just document the difference and maybe add a 
Decimal ceildiv method, although that makes me sad :-(

Could we "fix" Decimal?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46639>
_______________________________________

From report at bugs.python.org  Mon Feb  7 20:56:28 2022
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 08 Feb 2022 01:56:28 +0000
Subject: [issue46543] Add sys._getfunc
In-Reply-To: <1643255191.75.0.25013481924.issue46543@roundup.psfhosted.org>
Message-ID: <1644285388.89.0.72430511573.issue46543@roundup.psfhosted.org>


Barry A. Warsaw <barry at python.org> added the comment:

> Usually the calling function object should be enough.

I want to at least provide some historical context on why sys._getframe() exists.  I originally wrote that to support PEP 292 and internationalization in Mailman.  This has since been extracted into the flufl.i18n package.  Here is the use of sys._getframe() in that library:

https://gitlab.com/warsaw/flufl.i18n/-/blob/main/src/flufl/i18n/_translator.py#L65

You can see that the reason this exists is to dig out the local and globals of the context in which the _() function is invoked.  This greatly reduces the need to repeat yourself in i18n call sites.

https://flufli18n.readthedocs.io/en/stable/using.html#substitutions-and-placeholders

I'm not saying sys._getfunc() is or isn't useful, but it won't change original need for sys._getframe().

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46543>
_______________________________________

From report at bugs.python.org  Mon Feb  7 21:19:59 2022
From: report at bugs.python.org (=?utf-8?q?Filipe_La=C3=ADns?=)
Date: Tue, 08 Feb 2022 02:19:59 +0000
Subject: [issue45413] Add install scheme for virtual environments
In-Reply-To: <1633715402.49.0.434363843275.issue45413@roundup.psfhosted.org>
Message-ID: <1644286799.72.0.52825681199.issue45413@roundup.psfhosted.org>


Filipe La?ns <lains at riseup.net> added the comment:

I agree.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45413>
_______________________________________

From report at bugs.python.org  Mon Feb  7 21:59:15 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 08 Feb 2022 02:59:15 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644289155.89.0.666888831616.issue46323@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:

@vstinner

PR 31188 cause reference leak, please check

Raised RLIMIT_NOFILE: 256 -> 1024
0:00:00 load avg: 5.38 Run tests sequentially
0:00:00 load avg: 5.38 [1/1] test_ctypes
beginning 6 repetitions
123456
......
test_ctypes leaked [1028, 1026, 1028] references, sum=3082
test_ctypes leaked [2, 1, 3] memory blocks, sum=6
test_ctypes failed (reference leak)

== Tests result: FAILURE ==

1 test failed:
    test_ctypes

Total duration: 3.2 sec
Tests result: FAILURE

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Mon Feb  7 22:01:45 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 08 Feb 2022 03:01:45 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644289305.89.0.229331961633.issue46323@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:

No leak after if I revert PR 31188 on my local

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Mon Feb  7 22:44:13 2022
From: report at bugs.python.org (Ned Deily)
Date: Tue, 08 Feb 2022 03:44:13 +0000
Subject: [issue45948] Unexpected instantiation behavior for
 xml.etree.ElementTree.XMLParser(target=None)
In-Reply-To: <1638367672.95.0.357017255599.issue45948@roundup.psfhosted.org>
Message-ID: <1644291853.58.0.759884660239.issue45948@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
nosy: +eli.bendersky, scoder

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45948>
_______________________________________

From report at bugs.python.org  Mon Feb  7 22:47:56 2022
From: report at bugs.python.org (Ned Deily)
Date: Tue, 08 Feb 2022 03:47:56 +0000
Subject: [issue34191] argparse: Missing subparser error message should be more
 clear
In-Reply-To: <1532289510.54.0.56676864532.issue34191@psf.upfronthosting.co.za>
Message-ID: <1644292076.58.0.00279720092197.issue34191@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> argparse fails with required subparsers, un-named dest, and empty argv

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34191>
_______________________________________

From report at bugs.python.org  Mon Feb  7 22:51:53 2022
From: report at bugs.python.org (Ned Deily)
Date: Tue, 08 Feb 2022 03:51:53 +0000
Subject: [issue46662] Lib/sqlite3/dbapi2.py: convert_timestamp function failed
 to correctly parse timestamp
In-Reply-To: <1644174239.54.0.192057033337.issue46662@roundup.psfhosted.org>
Message-ID: <1644292313.64.0.113757980506.issue46662@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
nosy: +erlendaasland

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46662>
_______________________________________

From report at bugs.python.org  Mon Feb  7 23:09:47 2022
From: report at bugs.python.org (Alex Gaynor)
Date: Tue, 08 Feb 2022 04:09:47 +0000
Subject: [issue46159] Segfault when using trace functions in 3.11a3
In-Reply-To: <1640228846.77.0.888301890747.issue46159@roundup.psfhosted.org>
Message-ID: <1644293387.63.0.334689309828.issue46159@roundup.psfhosted.org>


Alex Gaynor <alex.gaynor at gmail.com> added the comment:

It seems to no longer be crashing with alpha5. Hopefully it's actually fixed and not merely having a more subtle failure mode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46159>
_______________________________________

From report at bugs.python.org  Mon Feb  7 23:43:59 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Tue, 08 Feb 2022 04:43:59 +0000
Subject: [issue46647] `test_functools` unexpected failures when C
 `_functoolsmodule` is missing
In-Reply-To: <1644058014.78.0.386662810799.issue46647@roundup.psfhosted.org>
Message-ID: <1644295439.91.0.67372164066.issue46647@roundup.psfhosted.org>


Nikita Sobolev <mail at sobolevn.me> added the comment:

> Or maybe you have other cases to show the functools module will missing unexpectly?

No, I can't think of any :)

Your argument about code churn also makes sense.
But, if we ever are going to refactor this test module, this is something to remember of.

Thanks everyone!

----------
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46647>
_______________________________________

From report at bugs.python.org  Mon Feb  7 23:59:03 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 08 Feb 2022 04:59:03 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644296343.87.0.404999487499.issue46323@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
pull_requests: +29379
pull_request: https://github.com/python/cpython/pull/31209

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Mon Feb  7 23:59:55 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 08 Feb 2022 04:59:55 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644296395.27.0.702917742032.issue46323@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:

@vstinner

PR 31209 is for fixing the leak.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Tue Feb  8 00:16:47 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 08 Feb 2022 05:16:47 +0000
Subject: [issue46282] return value of builtins is not clearly indicated
In-Reply-To: <1641482082.12.0.793901620769.issue46282@roundup.psfhosted.org>
Message-ID: <1644297407.63.0.71423307235.issue46282@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> New learners coming to Python don't know the same things
> as people with experience.

IMO, new learners will be worse off by adding "returns None" to all of the builtins.  At best it a distractor.

I work with new learners almost every day.  The issue never arises.  No one writes "x = print('hello world')" and they would be worse off if shown such a possibility.

One other consideration is that MyPy and the tools that use it (such as PyCharm) reject the idea of None as return value.  Their view is that no value is returned all.  We don't want the docs to contradict that world view.

  $ cat hello.py
  x = print('hello world')
  $ mypy hello.py
  hello.py:1: error: "print" does not return a value
  Found 1 error in 1 file (checked 1 source file)

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46282>
_______________________________________

From report at bugs.python.org  Tue Feb  8 00:22:37 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 08 Feb 2022 05:22:37 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644297757.28.0.0661351927947.issue46323@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:


New changeset e959dd9f5c1d8865d4e10c49eb30ee0a4fe2735d by Dong-hee Na in branch 'main':
bpo-46323 Fix ref leak if ctypes.CFuncPtr raises an error. (GH-31209)
https://github.com/python/cpython/commit/e959dd9f5c1d8865d4e10c49eb30ee0a4fe2735d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Tue Feb  8 00:25:38 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 08 Feb 2022 05:25:38 +0000
Subject: [issue46669] Add types.Self
In-Reply-To: <1644189171.85.0.34470950762.issue46669@roundup.psfhosted.org>
Message-ID: <1644297938.1.0.192506090226.issue46669@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> Your suggested signature looks like it's trying to support
> the second invariant, but it doesn't quite: if the types 
> don't match, the type checker will just set T to the 
> common base type of the two arguments.

Is there a way to write the second invariant correctly?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46669>
_______________________________________

From report at bugs.python.org  Tue Feb  8 01:05:10 2022
From: report at bugs.python.org (Tim Peters)
Date: Tue, 08 Feb 2022 06:05:10 +0000
Subject: [issue46639] Ceil division with math.ceildiv
In-Reply-To: <1644002723.68.0.838942257454.issue46639@roundup.psfhosted.org>
Message-ID: <1644300310.41.0.708719030746.issue46639@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

The `decimal` module intends to be a faithful implementation of external standards. The identity

x == (x // y) * y + x % y

isn't a minor detail, it's the dog on which all else is but a tail ;-)

It's why Guido picked -7 // 4 = -2 in Python[1]. That's really not all that useful on its own, and does surprise people. But it's necessary so that the identity implies -7 % 4 = 1, and _that's_ what drove it all, the desire that doing mod wrt a positive int always give a non-negative result.

The identity also implies that, under truncating division, mod returns a result with the sign of the dividend rather than of the divisor.

`decimal` implements what the external standards demand integer division do, and also integer modulus. The decimal context `divmod()` method returns both at once.

The behavior of int div and mod are linked by all standards I'm aware of, including by C89 (which didn't define what integer division did in all cases, but did demand that - whatever it did - % had to work in a way consistent with the named identity).

[1] http://python-history.blogspot.com/2010/08/why-pythons-integer-division-floors.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46639>
_______________________________________

From report at bugs.python.org  Tue Feb  8 02:28:32 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 08 Feb 2022 07:28:32 +0000
Subject: [issue46639] Ceil division with math.ceildiv
In-Reply-To: <1644002723.68.0.838942257454.issue46639@roundup.psfhosted.org>
Message-ID: <1644305312.65.0.658966089956.issue46639@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Round division would be useful not less than ceil division, if not more. In the stdlib it would be used in:

1. The datetime module.
2. Fraction.__round__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46639>
_______________________________________

From report at bugs.python.org  Tue Feb  8 02:41:11 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 08 Feb 2022 07:41:11 +0000
Subject: [issue45948] Unexpected instantiation behavior for
 xml.etree.ElementTree.XMLParser(target=None)
In-Reply-To: <1638367672.95.0.357017255599.issue45948@roundup.psfhosted.org>
Message-ID: <1644306071.62.0.401133768636.issue45948@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
components: +Extension Modules
nosy: +serhiy.storchaka
versions: +Python 3.10, Python 3.11, Python 3.9 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45948>
_______________________________________

From report at bugs.python.org  Tue Feb  8 02:47:05 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 08 Feb 2022 07:47:05 +0000
Subject: [issue46676] ParamSpec args and kwargs are not equal to themselves.
In-Reply-To: <1644261413.4.0.310987915665.issue46676@roundup.psfhosted.org>
Message-ID: <1644306425.89.0.174039986759.issue46676@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset c8b62bbe46e20d4b6dd556f2fa85960d1269aa45 by Gregory Beauregard in branch 'main':
bpo-46676: Make ParamSpec args and kwargs equal to themselves (GH-31203)
https://github.com/python/cpython/commit/c8b62bbe46e20d4b6dd556f2fa85960d1269aa45


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46676>
_______________________________________

From report at bugs.python.org  Tue Feb  8 02:51:36 2022
From: report at bugs.python.org (Gregory Beauregard)
Date: Tue, 08 Feb 2022 07:51:36 +0000
Subject: [issue46676] ParamSpec args and kwargs are not equal to themselves.
In-Reply-To: <1644261413.4.0.310987915665.issue46676@roundup.psfhosted.org>
Message-ID: <1644306696.1.0.484277297219.issue46676@roundup.psfhosted.org>


Change by Gregory Beauregard <greg at greg.red>:


----------
pull_requests: +29380
pull_request: https://github.com/python/cpython/pull/31210

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46676>
_______________________________________

From report at bugs.python.org  Tue Feb  8 02:54:44 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 08 Feb 2022 07:54:44 +0000
Subject: [issue46643] typing.Annotated cannot wrap typing.ParamSpec args/kwargs
In-Reply-To: <1644013165.99.0.0164231326825.issue46643@roundup.psfhosted.org>
Message-ID: <1644306884.25.0.792724485923.issue46643@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Should it? Annotated wraps types, and P.args/P.kwargs are not types.

If make Annotated accepting P.args/P.kwargs (and possible other non-types, e.g. P), it is a new feature which should be publicly discussed first and documented. I do not thing it requires a PEP.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46643>
_______________________________________

From report at bugs.python.org  Tue Feb  8 03:09:21 2022
From: report at bugs.python.org (Gregory Beauregard)
Date: Tue, 08 Feb 2022 08:09:21 +0000
Subject: [issue46643] typing.Annotated cannot wrap typing.ParamSpec args/kwargs
In-Reply-To: <1644013165.99.0.0164231326825.issue46643@roundup.psfhosted.org>
Message-ID: <1644307761.42.0.107350871901.issue46643@roundup.psfhosted.org>


Gregory Beauregard <greg at greg.red> added the comment:

My general understanding has been that since Annotated exists primarily to allow interoperability between typing and non-typing uses of annotation space, and that this is quite clear in the PEP, most cases where this is not allowed (_especially_ at the top level of the annotation, as in this case) are either a bug or unintentional. We fixed Annotated wrapping Final and ClassVar a couple weeks ago for arguments sorta along these lines after discussion on typing-sig, where the concern of what constitutes a type to wrap was specifically addressed: https://bugs.python.org/issue46491

But, I am not opposed to discussing this case too, or discussing the issue more broadly. Is typing-sig the appropriate place for me to make a thread, or do we wait for comments here? Even if we decide this particular issue is okay to fix, I think you bring up a good point about documenting our decision clearly once and for all so I agree we should do this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46643>
_______________________________________

From report at bugs.python.org  Tue Feb  8 03:36:30 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 08 Feb 2022 08:36:30 +0000
Subject: [issue46659] Deprecate locale.getdefaultlocale() function
In-Reply-To: <1644168794.44.0.0658923518102.issue46659@roundup.psfhosted.org>
Message-ID: <1644309390.18.0.451023804058.issue46659@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

getdefaultlocale() falls back to LANG and LANGUAGE. It allows also to specify a list of looked up environment variables. How could this use case be covered with getlocale()?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46659>
_______________________________________

From report at bugs.python.org  Tue Feb  8 03:41:35 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 08 Feb 2022 08:41:35 +0000
Subject: [issue46676] ParamSpec args and kwargs are not equal to themselves.
In-Reply-To: <1644261413.4.0.310987915665.issue46676@roundup.psfhosted.org>
Message-ID: <1644309695.69.0.11390335391.issue46676@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset cbdcae5ab90710e8d82c213f3798af1154670ff9 by Gregory Beauregard in branch '3.10':
[3.10] bpo-46676: Make ParamSpec args and kwargs equal to themselves (GH-31203) (GH-31210)
https://github.com/python/cpython/commit/cbdcae5ab90710e8d82c213f3798af1154670ff9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46676>
_______________________________________

From report at bugs.python.org  Tue Feb  8 03:41:51 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 08 Feb 2022 08:41:51 +0000
Subject: [issue46676] ParamSpec args and kwargs are not equal to themselves.
In-Reply-To: <1644261413.4.0.310987915665.issue46676@roundup.psfhosted.org>
Message-ID: <1644309711.14.0.708595146036.issue46676@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/issue46676>
_______________________________________

From report at bugs.python.org  Tue Feb  8 03:44:47 2022
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Feb 2022 08:44:47 +0000
Subject: [issue43882] [security] CVE-2022-0391: urllib.parse should sanitize
 urls containing ASCII newline and tabs.
In-Reply-To: <1618774620.3.0.412025280445.issue43882@roundup.psfhosted.org>
Message-ID: <1644309887.23.0.113492620504.issue43882@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Looks like that CVE isn't public yet.
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0391
> Any chance I can get access (I originally reported this vuln.).

Message from Gaurav Kamathe who requested the CVE:

"We've sent a request to MITRE to get this published and it'll be available on MITRE shortly."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43882>
_______________________________________

From report at bugs.python.org  Tue Feb  8 04:05:18 2022
From: report at bugs.python.org (Alex Waygood)
Date: Tue, 08 Feb 2022 09:05:18 +0000
Subject: [issue46066] Deprecate keyword args syntax for TypedDict definition
In-Reply-To: <1639409817.42.0.21314101687.issue46066@roundup.psfhosted.org>
Message-ID: <1644311118.88.0.235133266364.issue46066@roundup.psfhosted.org>


Change by Alex Waygood <Alex.Waygood at Gmail.com>:


----------
assignee: docs at python -> 
components: +Library (Lib) -Documentation
nosy:  -docs at python
title: Remove keyword args syntax for TypedDict definition -> Deprecate keyword args syntax for TypedDict definition
type:  -> behavior
versions: +Python 3.11 -Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46066>
_______________________________________

From report at bugs.python.org  Tue Feb  8 04:13:08 2022
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 08 Feb 2022 09:13:08 +0000
Subject: [issue45948] Unexpected instantiation behavior for
 xml.etree.ElementTree.XMLParser(target=None)
In-Reply-To: <1638367672.95.0.357017255599.issue45948@roundup.psfhosted.org>
Message-ID: <1644311588.99.0.830484270097.issue45948@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

This is a backwards incompatible change, but unlikely to have a wide impact.

I was thinking for a second if it's making the change in the right direction because it's not unreasonable to pass "None" for saying "I want no target". But it's documented this way and lxml does it the same, so I agree that this should be changed to make "None" behave the same as no argument.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45948>
_______________________________________

From report at bugs.python.org  Tue Feb  8 04:25:04 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 08 Feb 2022 09:25:04 +0000
Subject: [issue45948] Unexpected instantiation behavior for
 xml.etree.ElementTree.XMLParser(target=None)
In-Reply-To: <1638367672.95.0.357017255599.issue45948@roundup.psfhosted.org>
Message-ID: <1644312304.4.0.207603804465.issue45948@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I do not think it is a backwards incompatible change, but concur with the rest said by Stefan.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45948>
_______________________________________

From report at bugs.python.org  Tue Feb  8 04:52:52 2022
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 08 Feb 2022 09:52:52 +0000
Subject: [issue46648] `test.test_urllib2.MiscTests.test_issue16464` flaky due
 to external connection
In-Reply-To: <1644061533.84.0.594817920054.issue46648@roundup.psfhosted.org>
Message-ID: <1644313972.62.0.0613865833109.issue46648@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:


New changeset f87e616af038ee8963185e11b96841c81e8ef15a by Miss Islington (bot) in branch '3.8':
bpo-46648: Skip test_urllib2.test_issue16464() (GH-31161) (GH-31173)
https://github.com/python/cpython/commit/f87e616af038ee8963185e11b96841c81e8ef15a


----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46648>
_______________________________________

From report at bugs.python.org  Tue Feb  8 04:52:26 2022
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 08 Feb 2022 09:52:26 +0000
Subject: [issue46072] Unify handling of stats in the CPython VM
In-Reply-To: <1639498673.65.0.709719181358.issue46072@roundup.psfhosted.org>
Message-ID: <1644313946.15.0.856756819416.issue46072@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
pull_requests: +29381
pull_request: https://github.com/python/cpython/pull/31211

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46072>
_______________________________________

From report at bugs.python.org  Tue Feb  8 05:10:09 2022
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 08 Feb 2022 10:10:09 +0000
Subject: [issue46659] Deprecate locale.getdefaultlocale() function
In-Reply-To: <1644168794.44.0.0658923518102.issue46659@roundup.psfhosted.org>
Message-ID: <1644315009.26.0.639903835602.issue46659@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> getdefaultlocale() falls back to LANG and LANGUAGE.

_Py_SetLocaleFromEnv(LC_CTYPE) (e.g. setlocale(LC_CTYPE, "")) gets called at startup, except for the isolated configuration [1].

I think calendar.Locale*Calendar should try the LC_CTYPE locale if LC_TIME is "C", i.e. (None, None). Otherwise, it's introducing new default behavior. For example, with LC_ALL set to "ru_RU.utf8":

3.8:

    >>> locale.getlocale(locale.LC_TIME)
    (None, None)
    >>> locale.getlocale(locale.LC_CTYPE)
    ('ru_RU', 'UTF-8')
    >>> cal = calendar.LocaleTextCalendar()
    >>> cal.formatweekday(0, 15)
    '  ???????????  '

3.11.0a5+:

    >>> locale.getlocale(locale.LC_TIME)
    (None, None)
    >>> locale.getlocale(locale.LC_CTYPE)
    ('ru_RU', 'UTF-8')
    >>> cal = calendar.LocaleTextCalendar()
    >>> cal.formatweekday(0, 15)
    '     Monday    '
    >>> locale.setlocale(locale.LC_TIME, '')
    'ru_RU.utf8'
    >>> cal = calendar.LocaleTextCalendar()
    >>> cal.formatweekday(0, 15)
    '  ???????????  '

---

[1] https://docs.python.org/3/c-api/init_config.html?#isolated-configuration

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46659>
_______________________________________

From report at bugs.python.org  Tue Feb  8 05:20:19 2022
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Feb 2022 10:20:19 +0000
Subject: [issue46659] Deprecate locale.getdefaultlocale() function
In-Reply-To: <1644168794.44.0.0658923518102.issue46659@roundup.psfhosted.org>
Message-ID: <1644315619.17.0.277113475693.issue46659@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Serhiy: "getdefaultlocale() falls back to LANG and LANGUAGE. It allows also to specify a list of looked up environment variables. How could this use case be covered with getlocale()?"

What's your use case to use env vars rather than the current LC_CTYPE locale?

My concern is that when setlocale() is called, the current LC_CTYPE locale is inconsistent and you can get mojibake and others issues.

See for example:
https://bugs.python.org/issue43552#msg389069

Marc-Andre Lemburg wants to deprecate it:
https://bugs.python.org/issue43552#msg389076

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46659>
_______________________________________

From report at bugs.python.org  Tue Feb  8 05:26:06 2022
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Feb 2022 10:26:06 +0000
Subject: [issue46659] Deprecate locale.getdefaultlocale() function
In-Reply-To: <1644168794.44.0.0658923518102.issue46659@roundup.psfhosted.org>
Message-ID: <1644315966.41.0.0405016457715.issue46659@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> I think calendar.Locale*Calendar should try the LC_CTYPE locale if LC_TIME is "C", i.e. (None, None). Otherwise, it's introducing new default behavior. For example, with LC_ALL set to "ru_RU.utf8": (...)

Oh. Serhiy asked me to use LC_TIME rather than LC_CTYPE.

See also my example in the PR:
https://github.com/python/cpython/pull/31166#issuecomment-1030887394

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46659>
_______________________________________

From report at bugs.python.org  Tue Feb  8 05:54:25 2022
From: report at bugs.python.org (Erlend E. Aasland)
Date: Tue, 08 Feb 2022 10:54:25 +0000
Subject: [issue46662] Lib/sqlite3/dbapi2.py: convert_timestamp function failed
 to correctly parse timestamp
In-Reply-To: <1644174239.54.0.192057033337.issue46662@roundup.psfhosted.org>
Message-ID: <1644317665.3.0.667883627707.issue46662@roundup.psfhosted.org>


Erlend E. Aasland <erlend.aasland at innova.no> added the comment:

The sqlite3 timestamp converter is buggy, as already noted in the docs[^1]. Adding timezone support is out of the question[^2][^3][^4][^5], but fixing it to be able to discard any attached timezone info _may_ be ok; at first sight, I don't see how this could break existing applications (like, for example adding time zone support could do). I need to think it through. In the meanwhile, I suggest taking a look at the linked issues.


[^1]: https://docs.python.org/3/library/sqlite3.html#default-adapters-and-converters
[^2]: bpo-19065
[^3]: bpo-26651
[^4]: bpo-45858
[^5]: https://discuss.python.org/t/fixing-sqlite-timestamp-converter-to-handle-utc-offsets/10985

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46662>
_______________________________________

From report at bugs.python.org  Tue Feb  8 05:56:12 2022
From: report at bugs.python.org (Erlend E. Aasland)
Date: Tue, 08 Feb 2022 10:56:12 +0000
Subject: [issue46662] Lib/sqlite3/dbapi2.py: convert_timestamp function failed
 to correctly parse timestamp
In-Reply-To: <1644174239.54.0.192057033337.issue46662@roundup.psfhosted.org>
Message-ID: <1644317772.61.0.895843417374.issue46662@roundup.psfhosted.org>


Change by Erlend E. Aasland <erlend.aasland at innova.no>:


----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46662>
_______________________________________

From report at bugs.python.org  Tue Feb  8 05:58:48 2022
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 08 Feb 2022 10:58:48 +0000
Subject: [issue46659] Deprecate locale.getdefaultlocale() function
In-Reply-To: <1644168794.44.0.0658923518102.issue46659@roundup.psfhosted.org>
Message-ID: <1644317928.84.0.128293031747.issue46659@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> Oh. Serhiy asked me to use LC_TIME rather than LC_CTYPE.

Since Locale*Calendar is documented as not being thread safe, __init__() could get the real default via setlocale(LC_TIME, "") when locale=None and the current LC_TIME is "C". Restore it back to "C" after getting the default. That should usually match the behavior from previous versions that called getdefaultlocale(). In cases where it differs, it's fixing a bug because the default LC_TIME is the correct default.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46659>
_______________________________________

From report at bugs.python.org  Tue Feb  8 06:17:25 2022
From: report at bugs.python.org (Jaspar S.)
Date: Tue, 08 Feb 2022 11:17:25 +0000
Subject: [issue20779] Add pathlib.chown method
In-Reply-To: <1393408310.22.0.917230781145.issue20779@psf.upfronthosting.co.za>
Message-ID: <1644319045.95.0.595828220856.issue20779@roundup.psfhosted.org>


Change by Jaspar S. <jaspar.loechte at greenbone.net>:


----------
pull_requests: +29382
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31212

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20779>
_______________________________________

From report at bugs.python.org  Tue Feb  8 06:50:43 2022
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 08 Feb 2022 11:50:43 +0000
Subject: [issue46675] Allow more than 16 items in split-keys dicts and
 "virtual" object dicts.
In-Reply-To: <1644234724.61.0.0969544850657.issue46675@roundup.psfhosted.org>
Message-ID: <1644321043.51.0.503377847627.issue46675@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset 25db2b361beb865192a3424830ddcb0ae4b17318 by Mark Shannon in branch 'main':
bpo-46675: Allow object value arrays and split key dictionaries larger than 16 (GH-31191)
https://github.com/python/cpython/commit/25db2b361beb865192a3424830ddcb0ae4b17318


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46675>
_______________________________________

From report at bugs.python.org  Tue Feb  8 06:52:04 2022
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Tue, 08 Feb 2022 11:52:04 +0000
Subject: [issue29240] PEP 540: Add a new UTF-8 mode
In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za>
Message-ID: <1644321124.51.0.320951393629.issue29240@roundup.psfhosted.org>


Change by Chih-Hsuan Yen <yan12125+foss at gmail.com>:


----------
nosy:  -yan12125

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29240>
_______________________________________

From report at bugs.python.org  Tue Feb  8 06:54:42 2022
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 08 Feb 2022 11:54:42 +0000
Subject: [issue46521] codeop._maybe_compile passes code with error + triple
 quotes
In-Reply-To: <1643123376.15.0.69468893853.issue46521@roundup.psfhosted.org>
Message-ID: <1644321282.38.0.369856943383.issue46521@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 69e10976b2e7682c6d57f4272932ebc19f8e8859 by Pablo Galindo Salgado in branch 'main':
bpo-46521: Fix codeop to use a new partial-input mode of the parser (GH-31010)
https://github.com/python/cpython/commit/69e10976b2e7682c6d57f4272932ebc19f8e8859


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46521>
_______________________________________

From report at bugs.python.org  Tue Feb  8 06:57:26 2022
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 08 Feb 2022 11:57:26 +0000
Subject: [issue46521] codeop._maybe_compile passes code with error + triple
 quotes
In-Reply-To: <1643123376.15.0.69468893853.issue46521@roundup.psfhosted.org>
Message-ID: <1644321446.51.0.0115481874435.issue46521@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +29383
pull_request: https://github.com/python/cpython/pull/31213

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46521>
_______________________________________

From report at bugs.python.org  Tue Feb  8 07:25:24 2022
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 08 Feb 2022 12:25:24 +0000
Subject: [issue46521] codeop._maybe_compile passes code with error + triple
 quotes
In-Reply-To: <1643123376.15.0.69468893853.issue46521@roundup.psfhosted.org>
Message-ID: <1644323124.89.0.491584270682.issue46521@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 5b58db75291cfbb9b6785c9845824b3e2da01c1c by Pablo Galindo Salgado in branch '3.10':
[3.10] bpo-46521: Fix codeop to use a new partial-input mode of the parser (GH-31010). (GH-31213)
https://github.com/python/cpython/commit/5b58db75291cfbb9b6785c9845824b3e2da01c1c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46521>
_______________________________________

From report at bugs.python.org  Tue Feb  8 07:26:02 2022
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 08 Feb 2022 12:26:02 +0000
Subject: [issue46521] codeop._maybe_compile passes code with error + triple
 quotes
In-Reply-To: <1643123376.15.0.69468893853.issue46521@roundup.psfhosted.org>
Message-ID: <1644323162.34.0.798391938695.issue46521@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I am not backporting to 3.9 because the parser is different enough that introducing this would also introduce some unintended side effects.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46521>
_______________________________________

From report at bugs.python.org  Tue Feb  8 07:33:23 2022
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 08 Feb 2022 12:33:23 +0000
Subject: [issue43366] Unclosed bracket bug in code.interact prevents
 identifying syntax errors
In-Reply-To: <1614683419.24.0.792898358866.issue43366@roundup.psfhosted.org>
Message-ID: <1644323603.14.0.00699608656278.issue43366@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

This has been fixed by commit 69e10976b2e7682c6d57f4272932ebc19f8e8859:

Python 3.11.0a5+ (heads/main:69e10976b2, Feb  8 2022, 12:30:20) [Clang 12.0.0 (clang-1200.0.32.29)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import code
>>> code.interact()
Python 3.11.0a5+ (heads/main:69e10976b2, Feb  8 2022, 12:30:20) [Clang 12.0.0 (clang-1200.0.32.29)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> [
... def foo():
  File "<console>", line 1
    [
    ^
SyntaxError: '[' was never closed


Please, check that everything is in order and reopen the issue if we have missed something.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43366>
_______________________________________

From report at bugs.python.org  Tue Feb  8 07:33:39 2022
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 08 Feb 2022 12:33:39 +0000
Subject: [issue43366] Unclosed bracket bug in code.interact prevents
 identifying syntax errors
In-Reply-To: <1614683419.24.0.792898358866.issue43366@roundup.psfhosted.org>
Message-ID: <1644323619.64.0.641595783025.issue43366@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43366>
_______________________________________

From report at bugs.python.org  Tue Feb  8 08:04:17 2022
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 08 Feb 2022 13:04:17 +0000
Subject: [issue46657] Add mimalloc memory allocator
In-Reply-To: <1644158952.9.0.443530192167.issue46657@roundup.psfhosted.org>
Message-ID: <1644325457.6.0.357744827861.issue46657@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

New benchmark:

| Benchmark               | 2022-02-08_11-54-master-69e10976b2e7 | 2022-02-08_11-57-master-d6f5f010b586 |
|-------------------------|:------------------------------------:|:------------------------------------:|
| mako                    | 8.85 ms                              | 7.83 ms: 1.13x faster                |
| hexiom                  | 6.04 ms                              | 5.54 ms: 1.09x faster                |
| spectral_norm           | 81.4 ms                              | 75.2 ms: 1.08x faster                |
| pyflate                 | 380 ms                               | 352 ms: 1.08x faster                 |
| scimark_sparse_mat_mult | 4.05 ms                              | 3.76 ms: 1.08x faster                |
| pickle_pure_python      | 312 us                               | 290 us: 1.07x faster                 |
| unpickle_pure_python    | 238 us                               | 222 us: 1.07x faster                 |
| float                   | 63.1 ms                              | 59.5 ms: 1.06x faster                |
| tornado_http            | 90.3 ms                              | 86.0 ms: 1.05x faster                |
| html5lib                | 62.8 ms                              | 60.2 ms: 1.04x faster                |
| regex_compile           | 121 ms                               | 116 ms: 1.04x faster                 |
| scimark_lu              | 106 ms                               | 102 ms: 1.04x faster                 |
| nqueens                 | 70.9 ms                              | 68.4 ms: 1.04x faster                |
| crypto_pyaes            | 70.1 ms                              | 67.8 ms: 1.03x faster                |
| logging_silent          | 97.5 ns                              | 94.4 ns: 1.03x faster                |
| sympy_integrate         | 17.2 ms                              | 16.7 ms: 1.03x faster                |
| sympy_str               | 260 ms                               | 252 ms: 1.03x faster                 |
| sympy_expand            | 441 ms                               | 427 ms: 1.03x faster                 |
| pathlib                 | 14.1 ms                              | 13.7 ms: 1.03x faster                |
| regex_dna               | 164 ms                               | 159 ms: 1.03x faster                 |
| regex_v8                | 21.1 ms                              | 20.6 ms: 1.02x faster                |
| sympy_sum               | 138 ms                               | 136 ms: 1.02x faster                 |
| scimark_fft             | 286 ms                               | 281 ms: 1.02x faster                 |
| pickle                  | 9.34 us                              | 9.19 us: 1.02x faster                |
| xml_etree_parse         | 126 ms                               | 124 ms: 1.01x faster                 |
| richards                | 43.0 ms                              | 42.4 ms: 1.01x faster                |
| xml_etree_generate      | 71.2 ms                              | 70.5 ms: 1.01x faster                |
| scimark_monte_carlo     | 58.8 ms                              | 58.3 ms: 1.01x faster                |
| deltablue               | 3.60 ms                              | 3.58 ms: 1.01x faster                |
| chaos                   | 64.6 ms                              | 64.3 ms: 1.01x faster                |
| 2to3                    | 216 ms                               | 215 ms: 1.00x faster                 |
| pidigits                | 155 ms                               | 154 ms: 1.00x faster                 |
| nbody                   | 76.4 ms                              | 77.0 ms: 1.01x slower                |
| python_startup_no_site  | 3.96 ms                              | 3.99 ms: 1.01x slower                |
| xml_etree_iterparse     | 82.5 ms                              | 83.1 ms: 1.01x slower                |
| scimark_sor             | 103 ms                               | 104 ms: 1.01x slower                 |
| unpickle                | 11.3 us                              | 11.4 us: 1.01x slower                |
| telco                   | 5.53 ms                              | 5.58 ms: 1.01x slower                |
| python_startup          | 5.56 ms                              | 5.62 ms: 1.01x slower                |
| json_loads              | 20.6 us                              | 20.8 us: 1.01x slower                |
| json_dumps              | 9.61 ms                              | 9.77 ms: 1.02x slower                |
| dulwich_log             | 60.9 ms                              | 62.1 ms: 1.02x slower                |
| logging_format          | 5.47 us                              | 5.62 us: 1.03x slower                |
| pickle_list             | 3.06 us                              | 3.15 us: 1.03x slower                |
| django_template         | 30.2 ms                              | 31.2 ms: 1.03x slower                |
| meteor_contest          | 80.7 ms                              | 84.1 ms: 1.04x slower                |
| pickle_dict             | 21.9 us                              | 23.4 us: 1.07x slower                |
| logging_simple          | 4.84 us                              | 5.20 us: 1.07x slower                |
| Geometric mean          | (ref)                                | 1.01x faster                         |

Benchmark hidden because not significant (9): unpack_sequence, go, raytrace, chameleon, xml_etree_process, fannkuch, sqlite_synth, regex_effbot, unpickle_list

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46657>
_______________________________________

From report at bugs.python.org  Tue Feb  8 08:06:19 2022
From: report at bugs.python.org (Ned Batchelder)
Date: Tue, 08 Feb 2022 13:06:19 +0000
Subject: [issue46282] return value of builtins is not clearly indicated
In-Reply-To: <1641482082.12.0.793901620769.issue46282@roundup.psfhosted.org>
Message-ID: <1644325579.83.0.708150394656.issue46282@roundup.psfhosted.org>


Ned Batchelder <ned at nedbatchelder.com> added the comment:

What we're debating here is a micro-cosm of the broader "documentation philosophy" questions that I'm hoping the Documentation WG can iron out.  

What is "obvious"? Is it obvious that print returns None when file.write does not? Why does "exec" explicitly say it returns None, and no beginners were harmed, but having "print" say it returns None would be bad?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46282>
_______________________________________

From report at bugs.python.org  Tue Feb  8 08:09:29 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 08 Feb 2022 13:09:29 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644325769.36.0.556910883665.issue46323@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:


New changeset b5527688aae11d0b5af58176267a9943576e71e5 by Dong-hee Na in branch 'main':
bpo-46323: Use PyObject_Vectorcall while calling ctypes callback function (GH-31138)
https://github.com/python/cpython/commit/b5527688aae11d0b5af58176267a9943576e71e5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Tue Feb  8 08:11:46 2022
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 08 Feb 2022 13:11:46 +0000
Subject: [issue46282] return value of builtins is not clearly indicated
In-Reply-To: <1641482082.12.0.793901620769.issue46282@roundup.psfhosted.org>
Message-ID: <1644325906.02.0.245910207445.issue46282@roundup.psfhosted.org>


Irit Katriel <iritkatriel at gmail.com> added the comment:

I should have said "redundant information" rather than "obvious". 

I consider it redundant to specify that the default behavior applies to some specific case. If I read redundant information I may pause to think why it was necessary to explicitly state it, and whether I am misunderstanding something.

(Let's not make my bad choice of word turn this into a discussion about "what is obvious". The issue will probably never be closed if we do that.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46282>
_______________________________________

From report at bugs.python.org  Tue Feb  8 08:25:11 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 08 Feb 2022 13:25:11 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644326711.28.0.103174629193.issue46323@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:

@hydroflask

All patches are merged!
Thanks for all your suggestions :)

----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Tue Feb  8 08:57:09 2022
From: report at bugs.python.org (renzo)
Date: Tue, 08 Feb 2022 13:57:09 +0000
Subject: [issue46680] file calls itself
Message-ID: <1644328629.41.0.0810880607536.issue46680@roundup.psfhosted.org>


New submission from renzo <renzo71.cavallini at gmail.com>:

good morning
I created a file called prova.py

inside I put 3 lines
import test
a = 2
print (a)

d questions
why does a file have to call itself .. is it intended?
  how come it prints the value of a twice and does not enter the loop?

----------
components: Build
messages: 412840
nosy: lallo
priority: normal
severity: normal
status: open
title: file calls itself
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46680>
_______________________________________

From report at bugs.python.org  Tue Feb  8 09:02:49 2022
From: report at bugs.python.org (Dennis Sweeney)
Date: Tue, 08 Feb 2022 14:02:49 +0000
Subject: [issue46680] file calls itself
In-Reply-To: <1644328629.41.0.0810880607536.issue46680@roundup.psfhosted.org>
Message-ID: <1644328969.54.0.601814948799.issue46680@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

https://stackoverflow.com/ or https://discuss.python.org/c/users/ are better places for this question.

----------
nosy: +Dennis Sweeney
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46680>
_______________________________________

From report at bugs.python.org  Tue Feb  8 09:39:02 2022
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Feb 2022 14:39:02 +0000
Subject: [issue46659] Deprecate locale.getdefaultlocale() function
In-Reply-To: <1644168794.44.0.0658923518102.issue46659@roundup.psfhosted.org>
Message-ID: <1644331142.07.0.481845253829.issue46659@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29384
pull_request: https://github.com/python/cpython/pull/31214

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46659>
_______________________________________

From report at bugs.python.org  Tue Feb  8 09:40:54 2022
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Feb 2022 14:40:54 +0000
Subject: [issue46659] Deprecate locale.getdefaultlocale() function
In-Reply-To: <1644168794.44.0.0658923518102.issue46659@roundup.psfhosted.org>
Message-ID: <1644331254.42.0.846335653928.issue46659@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Eryk: I created GH-31214 which uses the user preferred locale if the current LC_TIME locale is "C" or "POSIX".

Moreover, it no longer gets the current locale when the class is created. If locale=locale is passed, just use the current LC_TIME (or the user preferred is the locale is "C" or "POSIX").

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46659>
_______________________________________

From report at bugs.python.org  Tue Feb  8 09:52:52 2022
From: report at bugs.python.org (Ilya Leoshkevich)
Date: Tue, 08 Feb 2022 14:52:52 +0000
Subject: [issue46681] gzip.compress does not forward compresslevel to
 zlib.compress
Message-ID: <1644331972.38.0.86974192008.issue46681@roundup.psfhosted.org>


New submission from Ilya Leoshkevich <iii at linux.ibm.com>:

Started with:

commit ea23e7820f02840368569db8082bd0ca4d59b62a
Author: Ruben Vorderman <r.h.p.vorderman at lumc.nl>
Date:   Thu Sep 2 17:02:59 2021 +0200

    bpo-43613: Faster implementation of gzip.compress and gzip.decompress (GH-27941)
    
    Co-authored-by: ?ukasz Langa <lukasz at langa.pl>

The fix is quite trivial:

--- a/Lib/gzip.py
+++ b/Lib/gzip.py
@@ -587,7 +587,8 @@ def compress(data, compresslevel=_COMPRESS_LEVEL_BEST, *, mtime=None):
     header = _create_simple_gzip_header(compresslevel, mtime)
     trailer = struct.pack("<LL", zlib.crc32(data), (len(data) & 0xffffffff))
     # Wbits=-15 creates a raw deflate block.
-    return header + zlib.compress(data, wbits=-15) + trailer
+    return (header + zlib.compress(data, level=compresslevel, wbits=-15) +
+            trailer)

I'll send a PR.

----------
components: Library (Lib)
messages: 412843
nosy: iii-i
priority: normal
severity: normal
status: open
title: gzip.compress does not forward compresslevel to zlib.compress
type: behavior
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46681>
_______________________________________

From report at bugs.python.org  Tue Feb  8 10:16:28 2022
From: report at bugs.python.org (Ilya Leoshkevich)
Date: Tue, 08 Feb 2022 15:16:28 +0000
Subject: [issue46681] gzip.compress does not forward compresslevel to
 zlib.compress
In-Reply-To: <1644331972.38.0.86974192008.issue46681@roundup.psfhosted.org>
Message-ID: <1644333388.8.0.332962787817.issue46681@roundup.psfhosted.org>


Change by Ilya Leoshkevich <iii at linux.ibm.com>:


----------
keywords: +patch
pull_requests: +29385
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31215

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46681>
_______________________________________

From report at bugs.python.org  Tue Feb  8 10:30:53 2022
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 08 Feb 2022 15:30:53 +0000
Subject: [issue46586] In documentation contents enum.property erroneously
 links to built-in property
In-Reply-To: <1643555525.86.0.209520180874.issue46586@roundup.psfhosted.org>
Message-ID: <1644334253.52.0.479754141968.issue46586@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
nosy: +python-dev
nosy_count: 6.0 -> 7.0
pull_requests: +29386
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31216

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46586>
_______________________________________

From report at bugs.python.org  Tue Feb  8 10:46:35 2022
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Feb 2022 15:46:35 +0000
Subject: [issue44006] symbol documentation still exists
In-Reply-To: <1619925800.83.0.907647536987.issue44006@roundup.psfhosted.org>
Message-ID: <1644335195.1.0.0804935290752.issue44006@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I reopen the issue for binhex.

https://docs.python.org/dev/library/binhex.html is still there whereas https://github.com/python/cpython/blob/main/Doc/library/binxhex.rst is gone.

----------
nosy: +vstinner
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44006>
_______________________________________

From report at bugs.python.org  Tue Feb  8 10:57:55 2022
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 08 Feb 2022 15:57:55 +0000
Subject: [issue45436] test_tk.test_configure_type() fails with Tcl/Tk 8.6.11
In-Reply-To: <1633984027.59.0.32532195896.issue45436@roundup.psfhosted.org>
Message-ID: <1644335875.64.0.123909128523.issue45436@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

> Can issue be closed now?

I think so; if others disagree they can reopen it :)

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45436>
_______________________________________

From report at bugs.python.org  Tue Feb  8 11:21:27 2022
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Feb 2022 16:21:27 +0000
Subject: [issue45490] [meta][C API] Avoid C macro pitfalls and usage of static
 inline functions
In-Reply-To: <1634319805.82.0.902360778503.issue45490@roundup.psfhosted.org>
Message-ID: <1644337287.9.0.22584290037.issue45490@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29387
pull_request: https://github.com/python/cpython/pull/31217

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45490>
_______________________________________

From report at bugs.python.org  Tue Feb  8 11:46:38 2022
From: report at bugs.python.org (Alan WiIliams)
Date: Tue, 08 Feb 2022 16:46:38 +0000
Subject: [issue28159] Deprecate isdst argument in email.utils.localtime
In-Reply-To: <1473890113.79.0.964863330823.issue28159@psf.upfronthosting.co.za>
Message-ID: <1644338798.01.0.8054836112.issue28159@roundup.psfhosted.org>


Alan WiIliams <astropiloto at gmail.com> added the comment:

Hi, I'd like to work on this issue. Based on the discussion, the main thing to do here is to raise a deprecation warning when isdst is used?

----------
nosy: +Alan.Williams

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28159>
_______________________________________

From report at bugs.python.org  Tue Feb  8 12:08:16 2022
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Feb 2022 17:08:16 +0000
Subject: [issue46659] Deprecate locale.getdefaultlocale() function
In-Reply-To: <1644168794.44.0.0658923518102.issue46659@roundup.psfhosted.org>
Message-ID: <1644340096.75.0.116511977703.issue46659@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29388
pull_request: https://github.com/python/cpython/pull/31218

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46659>
_______________________________________

From report at bugs.python.org  Tue Feb  8 12:09:32 2022
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Feb 2022 17:09:32 +0000
Subject: [issue46668] encodings: the "mbcs" alias doesn't work
In-Reply-To: <1644188809.05.0.861398707442.issue46668@roundup.psfhosted.org>
Message-ID: <1644340172.24.0.660998041216.issue46668@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I created GH-31218 which basically restores Python 3.10 code but enhances the test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46668>
_______________________________________

From report at bugs.python.org  Tue Feb  8 12:39:09 2022
From: report at bugs.python.org (Paul Jaggi)
Date: Tue, 08 Feb 2022 17:39:09 +0000
Subject: [issue46682] python 3.10 Py_Initialize/Py_Main std path no longer
 includes site-packages
Message-ID: <1644341949.29.0.882181976417.issue46682@roundup.psfhosted.org>


New submission from Paul Jaggi <pjaggi1 at yahoo.com>:

Have the following simple program:
#include <iostream>
#include <Python.h>

using namespace std;

int main(int argc, char** argv) {
  wchar_t* args[argc];
  for(int i = 0; i < argc; ++i) {
    args[i] = Py_DecodeLocale(argv[i], nullptr);
  }

  Py_Initialize();
  const int exit_code = Py_Main(argc, args);
  cout << "Exit code: " << exit_code << endl;
  cout << "press any key to exit" << endl;
  cin.get();
  return 0;
}

When you run this program and in the console:
import sys
sys.path

for Python versions between 3.7-3.9, you get the installed python site-packages by default.  For Python 3.10, you don't.  This happens on both windows and Mac.  Is this an intentional change?

----------
components: C API
messages: 412848
nosy: pjaggi1
priority: normal
severity: normal
status: open
title: python 3.10 Py_Initialize/Py_Main std path no longer includes site-packages
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46682>
_______________________________________

From report at bugs.python.org  Tue Feb  8 12:55:55 2022
From: report at bugs.python.org (German Salazar)
Date: Tue, 08 Feb 2022 17:55:55 +0000
Subject: [issue46683] Python 3.6.15 source tarball installs 3.6.8?
Message-ID: <1644342955.93.0.0263962479248.issue46683@roundup.psfhosted.org>


New submission from German Salazar <salgerman at gmail.com>:

wanted to install 3.6.15, but the source tarball installs 3.6.8

----------
messages: 412849
nosy: salgerman
priority: normal
severity: normal
status: open
title: Python 3.6.15 source tarball installs 3.6.8?
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46683>
_______________________________________

From report at bugs.python.org  Tue Feb  8 12:56:07 2022
From: report at bugs.python.org (German Salazar)
Date: Tue, 08 Feb 2022 17:56:07 +0000
Subject: [issue46683] Python 3.6.15 source tarball installs 3.6.8?
In-Reply-To: <1644342955.93.0.0263962479248.issue46683@roundup.psfhosted.org>
Message-ID: <1644342967.41.0.629379007833.issue46683@roundup.psfhosted.org>


Change by German Salazar <salgerman at gmail.com>:


----------
versions:  -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46683>
_______________________________________

From report at bugs.python.org  Tue Feb  8 12:56:52 2022
From: report at bugs.python.org (Julien Palard)
Date: Tue, 08 Feb 2022 17:56:52 +0000
Subject: [issue44006] symbol documentation still exists
In-Reply-To: <1619925800.83.0.907647536987.issue44006@roundup.psfhosted.org>
Message-ID: <1644343012.75.0.464808875431.issue44006@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:

Oh, it's ~unrelated, but thanks for the heads up, I overlooked a Sentry error :D

It's related to: https://github.com/python/docsbuild-scripts/issues/122, let's track it there.

(The visible effects are the same: the full build, reponsible for deleting the file is failing, while the quick (html only, not removing files) build succeed, so the old HTML files are kept if PDF builds are failing...)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44006>
_______________________________________

From report at bugs.python.org  Tue Feb  8 12:59:06 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 08 Feb 2022 17:59:06 +0000
Subject: [issue46683] Python 3.6.15 source tarball installs 3.6.8?
In-Reply-To: <1644342955.93.0.0263962479248.issue46683@roundup.psfhosted.org>
Message-ID: <1644343146.76.0.310737031892.issue46683@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Where did you get the tarball?

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46683>
_______________________________________

From report at bugs.python.org  Tue Feb  8 13:05:06 2022
From: report at bugs.python.org (German Salazar)
Date: Tue, 08 Feb 2022 18:05:06 +0000
Subject: [issue46683] Python 3.6.15 source tarball installs 3.6.8?
In-Reply-To: <1644342955.93.0.0263962479248.issue46683@roundup.psfhosted.org>
Message-ID: <1644343506.59.0.942449884908.issue46683@roundup.psfhosted.org>


German Salazar <salgerman at gmail.com> added the comment:

From 
https://www.python.org/downloads/release/python-3615/

Downloaded the XZ one:
https://www.python.org/ftp/python/3.6.15/Python-3.6.15.tar.xz

I am currently building the Gzipped one, let's see what it turns out.

----------
nosy:  -eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46683>
_______________________________________

From report at bugs.python.org  Tue Feb  8 13:06:11 2022
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 08 Feb 2022 18:06:11 +0000
Subject: [issue46683] Python 3.6.15 source tarball installs 3.6.8?
In-Reply-To: <1644342955.93.0.0263962479248.issue46683@roundup.psfhosted.org>
Message-ID: <1644343571.42.0.910241585878.issue46683@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

I've just confirmed that both tarballs (gzip and xz) on the official download page (https://www.python.org/downloads/release/python-3615/) contain 3.6.15.

Note that 3.6.8 was the last bugfix release that included Windows and macOS installers.  If you're on one of those platforms, you may need to go through some extra steps to replace an existing 3.6.8 install with 3.6.15, and at that point you would likely be better off upgrading to 3.10 (or at least 3.9, which is the oldest release that still has a current binary installer).

----------
nosy: +eric.smith, zach.ware
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46683>
_______________________________________

From report at bugs.python.org  Tue Feb  8 13:08:49 2022
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 08 Feb 2022 18:08:49 +0000
Subject: [issue46683] Python 3.6.15 source tarball installs 3.6.8?
In-Reply-To: <1644342955.93.0.0263962479248.issue46683@roundup.psfhosted.org>
Message-ID: <1644343729.28.0.704100703743.issue46683@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Also note that 3.6 is now EOL, so an upgrade is highly recommended anyway :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46683>
_______________________________________

From report at bugs.python.org  Tue Feb  8 13:09:22 2022
From: report at bugs.python.org (Eric Snow)
Date: Tue, 08 Feb 2022 18:09:22 +0000
Subject: [issue45952] Tools/c-analyzer is out-of-date.
In-Reply-To: <1638380962.78.0.734744265271.issue45952@roundup.psfhosted.org>
Message-ID: <1644343762.24.0.263622314659.issue45952@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
pull_requests: +29389
pull_request: https://github.com/python/cpython/pull/31219

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45952>
_______________________________________

From report at bugs.python.org  Tue Feb  8 13:15:11 2022
From: report at bugs.python.org (German Salazar)
Date: Tue, 08 Feb 2022 18:15:11 +0000
Subject: [issue46683] Python 3.6.15 source tarball installs 3.6.8?
In-Reply-To: <1644342955.93.0.0263962479248.issue46683@roundup.psfhosted.org>
Message-ID: <1644344111.43.0.925112073247.issue46683@roundup.psfhosted.org>


German Salazar <salgerman at gmail.com> added the comment:

I hear you, but I continue to need 3.6 for a bit longer.
I am on Linux, Centos 7; building from sources in a sandbox, no installation conflict with any else...

How do you confirm that the tarball indeed contains that it says? 

I build it and then I do "./python --version" and I get 3.6.8, instead of 3.6.15   

I also have 3.7, and 3.8 installs (I also need them) and working on installing 3.9 and 3.10

----------
resolution: not a bug -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46683>
_______________________________________

From report at bugs.python.org  Tue Feb  8 13:28:24 2022
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 08 Feb 2022 18:28:24 +0000
Subject: [issue46683] Python 3.6.15 source tarball installs 3.6.8?
In-Reply-To: <1644342955.93.0.0263962479248.issue46683@roundup.psfhosted.org>
Message-ID: <1644344904.82.0.538036556895.issue46683@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

I confirmed by downloading a fresh copy of each, extracting, and looking at Include/patchlevel.h.  You could further check by downloading a 3.6.8 tarball and comparing it against the 3.6.15 tarball.

Is 3.6.8 the version you already have installed, and are you building with `./configure --enable-shared`?  If so, my best guess would be that your new `./python` binary is picking up the system `libpython3.6.so`.  Try `LD_LIBRARY_PATH=$(pwd) ./python --version`.

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46683>
_______________________________________

From report at bugs.python.org  Tue Feb  8 13:30:13 2022
From: report at bugs.python.org (German Salazar)
Date: Tue, 08 Feb 2022 18:30:13 +0000
Subject: [issue46683] Python 3.6.15 source tarball installs 3.6.8?
In-Reply-To: <1644342955.93.0.0263962479248.issue46683@roundup.psfhosted.org>
Message-ID: <1644345013.51.0.296447422008.issue46683@roundup.psfhosted.org>


German Salazar <salgerman at gmail.com> added the comment:

Pre-post-edit: you are right, just saw your answer as I was typing this one. 


Aaaahhhh....

./python --version

is not enough, I guess I need to properly setup PATH, LD_LIBRARY_PATH and possibly PKG_CONFIG_PATH.

Sorry for the bother, guys. All is good. My apologies and thank you very much for the super fast response, it prompted to question and double question what I was doing.

----------
resolution: not a bug -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46683>
_______________________________________

From report at bugs.python.org  Tue Feb  8 13:22:32 2022
From: report at bugs.python.org (Joshua Bronson)
Date: Tue, 08 Feb 2022 18:22:32 +0000
Subject: [issue46684] Expose frozenset._hash classmethod
Message-ID: <1644344552.11.0.546290047749.issue46684@roundup.psfhosted.org>


New submission from Joshua Bronson <jabronson at gmail.com>:

collections.abc.Set provides a _hash() method that includes the following in its docstring:

"""
Note that we don't define __hash__: not all sets are hashable.
But if you define a hashable set type, its __hash__ should
call this function.
...
We match the algorithm used by the built-in frozenset type.
"""

Because Set._hash() is currently implemented in pure Python, users face having to make a potentially challenging decision between whether to trade off runtime efficiency vs. space efficiency:

>>> hash(frozenset(x))  # Should I use this?
>>> Set._hash(x)        # Or this?

The former requires O(n) memory to create the frozenset, merely to throw it immediately away, but on the other hand gets to use frozenset's __hash__ implementation, which is implemented in C.

The latter requires only O(1) memory, but does not get the performance benefit of using the C implementation of this algorithm.

Why not expose the C implementation via a frozenset._hash() classmethod, and change Set._hash() to merely call that?

Then it would be much clearer that using Set._hash() is always the right answer.

----------
messages: 412856
nosy: jab
priority: normal
severity: normal
status: open
title: Expose frozenset._hash classmethod

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46684>
_______________________________________

From report at bugs.python.org  Tue Feb  8 13:42:26 2022
From: report at bugs.python.org (Eric Snow)
Date: Tue, 08 Feb 2022 18:42:26 +0000
Subject: [issue45952] Tools/c-analyzer is out-of-date.
In-Reply-To: <1638380962.78.0.734744265271.issue45952@roundup.psfhosted.org>
Message-ID: <1644345746.74.0.897877404011.issue45952@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:


New changeset 1e6214dbd6a980b47123229aefd60bb2c9341b53 by Eric Snow in branch 'main':
bpo-45952: Get the C analyzer tool working again. (gh-31219)
https://github.com/python/cpython/commit/1e6214dbd6a980b47123229aefd60bb2c9341b53


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45952>
_______________________________________

From report at bugs.python.org  Tue Feb  8 13:46:48 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 08 Feb 2022 18:46:48 +0000
Subject: [issue46683] Python 3.6.15 source tarball installs 3.6.8?
In-Reply-To: <1644342955.93.0.0263962479248.issue46683@roundup.psfhosted.org>
Message-ID: <1644346008.36.0.970878749028.issue46683@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46683>
_______________________________________

From report at bugs.python.org  Tue Feb  8 13:50:33 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 08 Feb 2022 18:50:33 +0000
Subject: [issue46475] typing.Never and typing.assert_never
In-Reply-To: <1642891701.69.0.92347893734.issue46475@roundup.psfhosted.org>
Message-ID: <1644346233.14.0.742783002429.issue46475@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset 243436f3779c1e7bed1fd4b23d5a8ec5eff40699 by Jelle Zijlstra in branch 'main':
bpo-46475: Add typing.Never and typing.assert_never (GH-30842)
https://github.com/python/cpython/commit/243436f3779c1e7bed1fd4b23d5a8ec5eff40699


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46475>
_______________________________________

From report at bugs.python.org  Tue Feb  8 14:05:52 2022
From: report at bugs.python.org (Eric Snow)
Date: Tue, 08 Feb 2022 19:05:52 +0000
Subject: [issue45952] Tools/c-analyzer is out-of-date.
In-Reply-To: <1638380962.78.0.734744265271.issue45952@roundup.psfhosted.org>
Message-ID: <1644347152.05.0.760476724128.issue45952@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
pull_requests: +29390
pull_request: https://github.com/python/cpython/pull/31220

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45952>
_______________________________________

From report at bugs.python.org  Tue Feb  8 14:07:21 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Tue, 08 Feb 2022 19:07:21 +0000
Subject: [issue46475] typing.Never and typing.assert_never
In-Reply-To: <1642891701.69.0.92347893734.issue46475@roundup.psfhosted.org>
Message-ID: <1644347241.15.0.770131417794.issue46475@roundup.psfhosted.org>


Change by Jelle Zijlstra <jelle.zijlstra at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46475>
_______________________________________

From report at bugs.python.org  Tue Feb  8 14:15:41 2022
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Feb 2022 19:15:41 +0000
Subject: [issue45490] [C API] PEP 670: Convert macros to functions in the
 Python C API
In-Reply-To: <1634319805.82.0.902360778503.issue45490@roundup.psfhosted.org>
Message-ID: <1644347741.38.0.318763264853.issue45490@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I will use this issue to track changes related to PEP 670.

----------
title: [meta][C API] Avoid C macro pitfalls and usage of static inline functions -> [C API]  PEP 670: Convert macros to functions in the Python C API

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45490>
_______________________________________

From report at bugs.python.org  Tue Feb  8 14:38:00 2022
From: report at bugs.python.org (Eric Snow)
Date: Tue, 08 Feb 2022 19:38:00 +0000
Subject: [issue45952] Tools/c-analyzer is out-of-date.
In-Reply-To: <1638380962.78.0.734744265271.issue45952@roundup.psfhosted.org>
Message-ID: <1644349080.95.0.580208483775.issue45952@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:


New changeset c018d3037b5b62e6d48d5985d1a37b91762fbffb by Eric Snow in branch 'main':
bpo-45952: Get the C analyzer tool working again. (gh-31220)
https://github.com/python/cpython/commit/c018d3037b5b62e6d48d5985d1a37b91762fbffb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45952>
_______________________________________

From report at bugs.python.org  Tue Feb  8 14:39:26 2022
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 08 Feb 2022 19:39:26 +0000
Subject: [issue12029] [doc] clarify that except does not match virtual
 subclasses of the specified exception type
In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za>
Message-ID: <1644349166.06.0.283583100588.issue12029@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
title: Allow catching virtual subclasses in except clauses -> [doc] clarify that except does not match virtual subclasses of the specified exception type
versions: +Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12029>
_______________________________________

From report at bugs.python.org  Tue Feb  8 14:49:23 2022
From: report at bugs.python.org (Cyril Jouve)
Date: Tue, 08 Feb 2022 19:49:23 +0000
Subject: [issue46159] Segfault when using trace functions in 3.11a3
In-Reply-To: <1640228846.77.0.888301890747.issue46159@roundup.psfhosted.org>
Message-ID: <1644349763.38.0.964013071402.issue46159@roundup.psfhosted.org>


Cyril Jouve <jv.cyril at gmail.com> added the comment:

this looks related to https://github.com/nedbat/coveragepy/issues/1294 / https://github.com/nedbat/coveragepy/issues/1316 related to binary incompatibility in coverage (6.2) binary wheel built with 3.11alpha2 and running on 3.11alpha3 or later.

Latest release of coverage (6.3) do not ship binary wheel for python 3.11 anymore, so it's installed and built with your current python.

----------
nosy: +Cyril Jouve

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46159>
_______________________________________

From report at bugs.python.org  Tue Feb  8 14:51:02 2022
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 08 Feb 2022 19:51:02 +0000
Subject: [issue12029] [doc] clarify that except does not match virtual
 subclasses of the specified exception type
In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za>
Message-ID: <1644349862.88.0.407666062455.issue12029@roundup.psfhosted.org>


Change by Georg Brandl <georg at python.org>:


----------
nosy:  -georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12029>
_______________________________________

From report at bugs.python.org  Tue Feb  8 14:51:42 2022
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Feb 2022 19:51:42 +0000
Subject: [issue45490] [C API] PEP 670: Convert macros to functions in the
 Python C API
In-Reply-To: <1634319805.82.0.902360778503.issue45490@roundup.psfhosted.org>
Message-ID: <1644349902.33.0.581456431491.issue45490@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29391
pull_request: https://github.com/python/cpython/pull/31221

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45490>
_______________________________________

From report at bugs.python.org  Tue Feb  8 15:02:28 2022
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Feb 2022 20:02:28 +0000
Subject: [issue46656] Compile fails if Py_NO_NAN is defined
In-Reply-To: <1644141275.01.0.967715714071.issue46656@roundup.psfhosted.org>
Message-ID: <1644350548.57.0.770070523733.issue46656@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Requiring IEEE 754 support is being discussed on python-dev: https://mail.python.org/archives/list/python-dev at python.org/thread/J5FSP6J4EITPY5C2UJI7HSL2GQCTCUWN/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46656>
_______________________________________

From report at bugs.python.org  Tue Feb  8 15:03:46 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Tue, 08 Feb 2022 20:03:46 +0000
Subject: [issue46685] Add additional tests for new features in `typing.py`
Message-ID: <1644350626.56.0.225939389842.issue46685@roundup.psfhosted.org>


New submission from Nikita Sobolev <mail at sobolevn.me>:

New features (like `Self` type and `Never` type), in my opinion, require some extra testing.

Things that were not covered:
- Inheritance from `Self`, only `type(Self)` is covered: https://github.com/python/cpython/blob/c018d3037b5b62e6d48d5985d1a37b91762fbffb/Lib/test/test_typing.py#L193-L196
- Equality and non-equality for `Self` and `Never`. We should be sure that `NoReturn` is not equal to `Never`, but they are equal to themselfs
- `get_type_hints` with `Never`
- `get_origin` with `Self` and `Never` types, it should return `None` for both cases
- (not exactly related) I've also noticed that this line is not covered at all: https://github.com/python/cpython/blob/c018d3037b5b62e6d48d5985d1a37b91762fbffb/Lib/typing.py#L725

Maybe there are some other cases? 

I will send a PR :)

----------
components: Tests
messages: 412865
nosy: AlexWaygood, Jelle Zijlstra, gvanrossum, kj, sobolevn
priority: normal
severity: normal
status: open
title: Add additional tests for new features in `typing.py`
type: behavior
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46685>
_______________________________________

From report at bugs.python.org  Tue Feb  8 15:04:36 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Tue, 08 Feb 2022 20:04:36 +0000
Subject: [issue46685] Add additional tests for new features in `typing.py`
In-Reply-To: <1644350626.56.0.225939389842.issue46685@roundup.psfhosted.org>
Message-ID: <1644350676.15.0.657215177594.issue46685@roundup.psfhosted.org>


Change by Nikita Sobolev <mail at sobolevn.me>:


----------
keywords: +patch
pull_requests: +29392
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31222

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46685>
_______________________________________

From report at bugs.python.org  Tue Feb  8 15:05:08 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Tue, 08 Feb 2022 20:05:08 +0000
Subject: [issue46685] Add additional tests for new features in `typing.py`
In-Reply-To: <1644350626.56.0.225939389842.issue46685@roundup.psfhosted.org>
Message-ID: <1644350708.48.0.298723695935.issue46685@roundup.psfhosted.org>


Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:

Thanks for catching these details! Please send a PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46685>
_______________________________________

From report at bugs.python.org  Tue Feb  8 15:14:07 2022
From: report at bugs.python.org (Cyril Jouve)
Date: Tue, 08 Feb 2022 20:14:07 +0000
Subject: [issue45713] gcc warning when compiling Modules/expat/xmltok_ns.c
In-Reply-To: <1636033117.93.0.543536023335.issue45713@roundup.psfhosted.org>
Message-ID: <1644351247.75.0.51344242953.issue45713@roundup.psfhosted.org>


Change by Cyril Jouve <jv.cyril at gmail.com>:


----------
keywords: +patch
nosy: +Cyril Jouve
nosy_count: 2.0 -> 3.0
pull_requests: +29393
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31022

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45713>
_______________________________________

From report at bugs.python.org  Tue Feb  8 15:36:37 2022
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 08 Feb 2022 20:36:37 +0000
Subject: [issue46657] Add mimalloc memory allocator
In-Reply-To: <1644158952.9.0.443530192167.issue46657@roundup.psfhosted.org>
Message-ID: <1644352597.91.0.872101511299.issue46657@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

I re-ran the benchmark of d6f5f010b586:

| Benchmark               | 2022-02-08_11-54-master-69e10976b2e7 | 2022-02-08_11-57-master-d6f5f010b586 |
|-------------------------|:------------------------------------:|:------------------------------------:|
| pickle_pure_python      | 312 us                               | 281 us: 1.11x faster                 |
| unpickle_pure_python    | 238 us                               | 216 us: 1.10x faster                 |
| pyflate                 | 380 ms                               | 349 ms: 1.09x faster                 |
| hexiom                  | 6.04 ms                              | 5.55 ms: 1.09x faster                |
| logging_silent          | 97.5 ns                              | 89.8 ns: 1.09x faster                |
| float                   | 63.1 ms                              | 59.3 ms: 1.07x faster                |
| html5lib                | 62.8 ms                              | 59.1 ms: 1.06x faster                |
| crypto_pyaes            | 70.1 ms                              | 66.1 ms: 1.06x faster                |
| json_loads              | 20.6 us                              | 19.4 us: 1.06x faster                |
| tornado_http            | 90.3 ms                              | 86.1 ms: 1.05x faster                |
| mako                    | 8.85 ms                              | 8.45 ms: 1.05x faster                |
| richards                | 43.0 ms                              | 41.1 ms: 1.05x faster                |
| xml_etree_parse         | 126 ms                               | 120 ms: 1.05x faster                 |
| logging_format          | 5.47 us                              | 5.25 us: 1.04x faster                |
| sympy_integrate         | 17.2 ms                              | 16.5 ms: 1.04x faster                |
| sympy_str               | 260 ms                               | 251 ms: 1.04x faster                 |
| fannkuch                | 325 ms                               | 314 ms: 1.04x faster                 |
| regex_v8                | 21.1 ms                              | 20.4 ms: 1.04x faster                |
| sympy_expand            | 441 ms                               | 425 ms: 1.04x faster                 |
| regex_compile           | 121 ms                               | 117 ms: 1.03x faster                 |
| sympy_sum               | 138 ms                               | 134 ms: 1.03x faster                 |
| scimark_lu              | 106 ms                               | 103 ms: 1.03x faster                 |
| go                      | 128 ms                               | 125 ms: 1.03x faster                 |
| pathlib                 | 14.1 ms                              | 13.7 ms: 1.02x faster                |
| scimark_monte_carlo     | 58.8 ms                              | 57.9 ms: 1.02x faster                |
| nqueens                 | 70.9 ms                              | 69.9 ms: 1.02x faster                |
| pidigits                | 155 ms                               | 153 ms: 1.01x faster                 |
| pickle                  | 9.34 us                              | 9.22 us: 1.01x faster                |
| raytrace                | 278 ms                               | 275 ms: 1.01x faster                 |
| 2to3                    | 216 ms                               | 213 ms: 1.01x faster                 |
| deltablue               | 3.60 ms                              | 3.56 ms: 1.01x faster                |
| logging_simple          | 4.84 us                              | 4.78 us: 1.01x faster                |
| xml_etree_iterparse     | 82.5 ms                              | 81.7 ms: 1.01x faster                |
| regex_dna               | 164 ms                               | 162 ms: 1.01x faster                 |
| unpack_sequence         | 32.7 ns                              | 32.4 ns: 1.01x faster                |
| telco                   | 5.53 ms                              | 5.48 ms: 1.01x faster                |
| python_startup          | 5.56 ms                              | 5.58 ms: 1.00x slower                |
| xml_etree_generate      | 71.2 ms                              | 71.6 ms: 1.01x slower                |
| unpickle_list           | 4.08 us                              | 4.12 us: 1.01x slower                |
| chameleon               | 6.07 ms                              | 6.14 ms: 1.01x slower                |
| chaos                   | 64.6 ms                              | 65.3 ms: 1.01x slower                |
| json_dumps              | 9.61 ms                              | 9.75 ms: 1.01x slower                |
| xml_etree_process       | 49.9 ms                              | 50.7 ms: 1.01x slower                |
| meteor_contest          | 80.7 ms                              | 82.0 ms: 1.02x slower                |
| scimark_sparse_mat_mult | 4.05 ms                              | 4.12 ms: 1.02x slower                |
| unpickle                | 11.3 us                              | 11.5 us: 1.02x slower                |
| django_template         | 30.2 ms                              | 31.0 ms: 1.02x slower                |
| scimark_sor             | 103 ms                               | 106 ms: 1.02x slower                 |
| spectral_norm           | 81.4 ms                              | 84.9 ms: 1.04x slower                |
| pickle_dict             | 21.9 us                              | 23.5 us: 1.08x slower                |
| Geometric mean          | (ref)                                | 1.02x faster                         |

Benchmark hidden because not significant (7): scimark_fft, dulwich_log, python_startup_no_site, regex_effbot, sqlite_synth, nbody, pickle_list

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46657>
_______________________________________

From report at bugs.python.org  Tue Feb  8 15:39:34 2022
From: report at bugs.python.org (Eric Snow)
Date: Tue, 08 Feb 2022 20:39:34 +0000
Subject: [issue46541] Replace _Py_IDENTIFIER() with statically initialized
 objects.
In-Reply-To: <1643234464.46.0.949364478641.issue46541@roundup.psfhosted.org>
Message-ID: <1644352774.63.0.213514974188.issue46541@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:


New changeset 81c72044a181dbbfbf689d7a977d0d99090f26a8 by Eric Snow in branch 'main':
bpo-46541: Replace core use of _Py_IDENTIFIER() with statically initialized global objects. (gh-30928)
https://github.com/python/cpython/commit/81c72044a181dbbfbf689d7a977d0d99090f26a8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46541>
_______________________________________

From report at bugs.python.org  Tue Feb  8 15:43:39 2022
From: report at bugs.python.org (Gregory Beauregard)
Date: Tue, 08 Feb 2022 20:43:39 +0000
Subject: [issue46643] typing.Annotated cannot wrap typing.ParamSpec args/kwargs
In-Reply-To: <1644013165.99.0.0164231326825.issue46643@roundup.psfhosted.org>
Message-ID: <1644353019.86.0.11100714338.issue46643@roundup.psfhosted.org>


Gregory Beauregard <greg at greg.red> added the comment:

I have made a thread on typing-sig to discuss this: https://mail.python.org/archives/list/typing-sig at python.org/thread/WZ4BCFO4VZ7U4CZ4FSDQNFAKPG2KOGCL/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46643>
_______________________________________

From report at bugs.python.org  Tue Feb  8 15:46:51 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Tue, 08 Feb 2022 20:46:51 +0000
Subject: [issue46685] Add additional tests for new features in `typing.py`
In-Reply-To: <1644350626.56.0.225939389842.issue46685@roundup.psfhosted.org>
Message-ID: <1644353211.2.0.774184243857.issue46685@roundup.psfhosted.org>


Change by Nikita Sobolev <mail at sobolevn.me>:


----------
pull_requests: +29394
pull_request: https://github.com/python/cpython/pull/31223

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46685>
_______________________________________

From report at bugs.python.org  Tue Feb  8 16:01:45 2022
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 08 Feb 2022 21:01:45 +0000
Subject: [issue46556] pathlib.Path.__enter__() should emit DeprecationWarning
In-Reply-To: <1643324841.78.0.0628599303644.issue46556@roundup.psfhosted.org>
Message-ID: <1644354105.43.0.954823896507.issue46556@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:


New changeset 06e1701ad3956352bc0f42b8f51c2f8cc85bf378 by Barney Gale in branch 'main':
bpo-46556: emit `DeprecationWarning` from `pathlib.Path.__enter__()` (GH-30971)
https://github.com/python/cpython/commit/06e1701ad3956352bc0f42b8f51c2f8cc85bf378


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46556>
_______________________________________

From report at bugs.python.org  Tue Feb  8 16:02:04 2022
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 08 Feb 2022 21:02:04 +0000
Subject: [issue46556] pathlib.Path.__enter__() should emit DeprecationWarning
In-Reply-To: <1643324841.78.0.0628599303644.issue46556@roundup.psfhosted.org>
Message-ID: <1644354124.6.0.575885366201.issue46556@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/issue46556>
_______________________________________

From report at bugs.python.org  Tue Feb  8 16:04:12 2022
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 08 Feb 2022 21:04:12 +0000
Subject: [issue46678] Invalid cross device link in
 Lib/test/support/import_helper.py
In-Reply-To: <1644265836.23.0.316073606856.issue46678@roundup.psfhosted.org>
Message-ID: <1644354252.6.0.762614059309.issue46678@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:


New changeset c2735b75afd530631efde4ddd3cb24bbdc285559 by Miss Islington (bot) in branch '3.10':
bpo-46678: Fix Invalid cross device link in Lib/test/support/import_helper.py (GH-31204) (GH-31207)
https://github.com/python/cpython/commit/c2735b75afd530631efde4ddd3cb24bbdc285559


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46678>
_______________________________________

From report at bugs.python.org  Tue Feb  8 16:04:21 2022
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 08 Feb 2022 21:04:21 +0000
Subject: [issue46678] Invalid cross device link in
 Lib/test/support/import_helper.py
In-Reply-To: <1644265836.23.0.316073606856.issue46678@roundup.psfhosted.org>
Message-ID: <1644354261.63.0.936275664457.issue46678@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/issue46678>
_______________________________________

From report at bugs.python.org  Tue Feb  8 16:06:57 2022
From: report at bugs.python.org (hydroflask)
Date: Tue, 08 Feb 2022 21:06:57 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644354417.33.0.455876886735.issue46323@roundup.psfhosted.org>


hydroflask <hydroflask at yqxmail.com> added the comment:

Two things, one is a nit pick the other is more serious. I think vstinner mentioned this in his review of your patch but on this line:

https://github.com/python/cpython/commit/b5527688aae11d0b5af58176267a9943576e71e5#diff-706e65ee28911740bf638707e19578b8182e57c6a8a9a4a91105d825f95a139dR180

Instead of using PySequence_Fast_ITEMS(), you can just use PyTuple_GET_ITEM() since you know the converters are a tuple. In terms of runtime efficiency it doesn't change anything but is consistent with this line: https://github.com/python/cpython/commit/b5527688aae11d0b5af58176267a9943576e71e5#diff-706e65ee28911740bf638707e19578b8182e57c6a8a9a4a91105d825f95a139dR157

Though on second thought I think PySequence_Fast_ITEMS() is probably a better API overall in terms of efficiency if PyTuple_GET_ITEM() would eventually become a real function call given the long term push toward a stable API.

The other issue is more serious, you are always allocating an array of CTYPES_MAX_ARGCOUNT pointers on the stack on every C callback. This could cause stack overflows in situations where a relatively deep set of callbacks are invoked. This usage of CTYPES_MAX_ARGCOUNT differs its usage in callproc.c, where in that case `alloca()` is used to allocate the specific number of array entries on the stack. To avoid an unintended stack overflow I would use alloca() or if you don't like alloca() I would only allocate a relatively small constant number on the stack.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Tue Feb  8 17:24:51 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 08 Feb 2022 22:24:51 +0000
Subject: [issue46684] Expose frozenset._hash classmethod
In-Reply-To: <1644344552.11.0.546290047749.issue46684@roundup.psfhosted.org>
Message-ID: <1644359091.37.0.275176805641.issue46684@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> Why not expose the C implementation via a frozenset._hash()
> classmethod, and change Set._hash() to merely call that?

The frozenset.__hash__ method is tightly bound to the internals of real sets to take advantage of the hash values already being known for real sets.  So we can't just expose it to ABC sets.

Also, the ABC sets need to be kept in sync with an __eq__ method, so users really need to see what Set._hash is actually doing.

Lastly, pure python hashable sets based on the ABC are not common, so it doesn't warrant a C fast path.  If C fast paths were offered, the union, intersection, and difference methods would more important targets.

So, thanks for the suggestion but it isn't as straight-forward as exposing existing code and it might make it harder for implementer to stay synced with an __eq__ method.

Tangential thought:  If you do implement __hash__ with Set._hash, consider using a cached_property decorator.

----------
nosy: +rhettinger
resolution:  -> rejected
stage:  -> resolved
status: open -> closed
type:  -> performance
versions: +Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46684>
_______________________________________

From report at bugs.python.org  Tue Feb  8 17:48:39 2022
From: report at bugs.python.org (Kesh Ikuma)
Date: Tue, 08 Feb 2022 22:48:39 +0000
Subject: [issue46686] [venv / PC/launcher] issue with a space in the installed
 python path
Message-ID: <1644360519.94.0.220947714115.issue46686@roundup.psfhosted.org>


New submission from Kesh Ikuma <tikuma at hotmail.com>:

After months of proper operation, my per-user Python install started to error out when I attempt `python -m venv .venv` with 

"Error: Command '['C:\\Users\\kesh\\test\\.venv\\Scripts\\python.exe', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 101."

Following the StackOverflow solution, I reinstalled Python for all users and it was working OK. I recently looked into it deeper and found the root issue in the function PC/launcher.c/run_child(). The path to the "...\Python\Python310\python.exe" contains a space, and the CreateProcessW() call on Line 811 is passing the path without quoting the path, causing the process creation to fail.

I fixed my issue by using the Windows short path convention on my path env. variable, but there must be a more permanent fix possible.

Here is the link to my question and self-answering to the problem:

https://stackoverflow.com/questions/71039131/troubleshooting-the-windows-venv-error-101

----------
components: Windows
messages: 412874
nosy: hokiedsp, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: [venv / PC/launcher] issue with a space in the installed python path
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46686>
_______________________________________

From report at bugs.python.org  Tue Feb  8 17:51:53 2022
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 08 Feb 2022 22:51:53 +0000
Subject: [issue46586] In documentation contents enum.property erroneously
 links to built-in property
In-Reply-To: <1643555525.86.0.209520180874.issue46586@roundup.psfhosted.org>
Message-ID: <1644360713.77.0.238075257678.issue46586@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> added the comment:

The same problem exists for any attribute that has the same name as a builtin, see for example https://docs.python.org/3/library/sys.html#sys.float_info

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46586>
_______________________________________

From report at bugs.python.org  Tue Feb  8 17:53:39 2022
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 08 Feb 2022 22:53:39 +0000
Subject: [issue46614] Add option to output UTC datetimes as "Z" in
 `.isoformat()`
In-Reply-To: <1643823106.57.0.535855742317.issue46614@roundup.psfhosted.org>
Message-ID: <1644360819.64.0.883621017187.issue46614@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> added the comment:

Would it be horrible to have the timezone instance control this?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46614>
_______________________________________

From report at bugs.python.org  Tue Feb  8 17:54:16 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 08 Feb 2022 22:54:16 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644360856.63.0.13717875775.issue46323@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
pull_requests: +29395
pull_request: https://github.com/python/cpython/pull/31224

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Tue Feb  8 17:56:03 2022
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 08 Feb 2022 22:56:03 +0000
Subject: [issue46622] Support decorating a coroutine with
 functools.cached_property
In-Reply-To: <1643873308.65.0.92890586202.issue46622@roundup.psfhosted.org>
Message-ID: <1644360963.94.0.294482821115.issue46622@roundup.psfhosted.org>


Change by ?ric Araujo <merwok at netwok.org>:


----------
versions:  -Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46622>
_______________________________________

From report at bugs.python.org  Tue Feb  8 17:57:39 2022
From: report at bugs.python.org (Joshua Bronson)
Date: Tue, 08 Feb 2022 22:57:39 +0000
Subject: [issue46684] Expose frozenset._hash classmethod
In-Reply-To: <1644344552.11.0.546290047749.issue46684@roundup.psfhosted.org>
Message-ID: <1644361059.78.0.46178012579.issue46684@roundup.psfhosted.org>


Joshua Bronson <jabronson at gmail.com> added the comment:

Thanks for the explanation, Raymond.

Regarding:

> Lastly, pure python hashable sets based on the ABC are not common

This would have implications for other use cases though, that are perhaps more common.

See, for example, the following code: https://github.com/jab/bidict/blob/ae9d06/bidict/_frozenbidict.py#L36-L38

This example demonstrates an implementation of a hashable, immutable Mapping type, whose __hash__ implementation returns collections.abc.ItemsView(self)._hash(). Since there are several other libraries I know of that implement hashable/immutable mapping types as well, I thought this might be beneficial enough to users to warrant consideration.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46684>
_______________________________________

From report at bugs.python.org  Tue Feb  8 18:08:14 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 08 Feb 2022 23:08:14 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644361694.98.0.922941660915.issue46323@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:

@hydroflask

Sound reasonable, I submitted a new patch to use alloca which is already used in _ctypes module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Tue Feb  8 18:08:31 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 08 Feb 2022 23:08:31 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644361711.22.0.619044077104.issue46323@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:

And it even better from performance view

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Tue Feb  8 18:45:05 2022
From: report at bugs.python.org (Steve Dower)
Date: Tue, 08 Feb 2022 23:45:05 +0000
Subject: [issue46687] Update pyexpat for CVE-2021-45960
Message-ID: <1644363905.53.0.879497437531.issue46687@roundup.psfhosted.org>


New submission from Steve Dower <steve.dower at python.org>:

libexpat recently fixed a security issue relating to some arithmetic: https://github.com/libexpat/libexpat/pull/534

I assume we should take this fix, either by updating our entire bundled copy or just backporting the patch.

----------
components: XML
messages: 412880
nosy: steve.dower
priority: normal
severity: normal
stage: needs patch
status: open
title: Update pyexpat for CVE-2021-45960
type: security
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46687>
_______________________________________

From report at bugs.python.org  Tue Feb  8 19:01:05 2022
From: report at bugs.python.org (Ned Deily)
Date: Wed, 09 Feb 2022 00:01:05 +0000
Subject: [issue46687] Update pyexpat for CVE-2021-45960
In-Reply-To: <1644363905.53.0.879497437531.issue46687@roundup.psfhosted.org>
Message-ID: <1644364865.43.0.087387270325.issue46687@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Duplicate of Issue46400 ?

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46687>
_______________________________________

From report at bugs.python.org  Tue Feb  8 19:15:07 2022
From: report at bugs.python.org (hydroflask)
Date: Wed, 09 Feb 2022 00:15:07 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644365707.01.0.694875708559.issue46323@roundup.psfhosted.org>


hydroflask <hydroflask at yqxmail.com> added the comment:

I don't have github so I can't comment there but just as a nitpick, alloca() never returns NULL, so you don't have to check that. I know that is inconsistent with its use in callproc.c so for consistency's sake the NULL check should stay but I would remove both checks in a future change.

More importantly you can completely avoid the args_stack variable since alloca() has the same end affect. I would also add an assert that the number of args is <= CTYPES_MAX_ARGCOUNT, that should be the case since GH 31188

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Tue Feb  8 19:29:18 2022
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 09 Feb 2022 00:29:18 +0000
Subject: [issue46686] [venv / PC/launcher] issue with a space in the installed
 python path
In-Reply-To: <1644360519.94.0.220947714115.issue46686@roundup.psfhosted.org>
Message-ID: <1644366558.51.0.816865997619.issue46686@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

run_child() expects `cmdline` to be correctly quoted, and normally it is.

I can't reproduce this problem with Python 3.10.2. I created a user account with a space in the account name, logged on, and installed 3.10.2 for the current user, with the option enabled to add Python to PATH. Next I opened a command prompt in the user profile directory and created a virtual environment via `python.exe -m venv .venv`. Running ".venv\Scripts\python.exe -X utf8" worked. The command line used by the venv "python.exe" launcher was properly quoted and thus properly parsed in the original list of command-line arguments, sys.orig_argv.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46686>
_______________________________________

From report at bugs.python.org  Tue Feb  8 19:39:04 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Feb 2022 00:39:04 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644367144.65.0.792129809306.issue46323@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I suggest to use PyTuple_GET_ITEM(), but PySequence_Fast_ITEMS() is more effecient. It's hard to beat an array in C.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Tue Feb  8 19:42:11 2022
From: report at bugs.python.org (Kesh Ikuma)
Date: Wed, 09 Feb 2022 00:42:11 +0000
Subject: [issue46686] [venv / PC/launcher] issue with a space in the installed
 python path
In-Reply-To: <1644360519.94.0.220947714115.issue46686@roundup.psfhosted.org>
Message-ID: <1644367331.1.0.89872362907.issue46686@roundup.psfhosted.org>


Kesh Ikuma <tikuma at hotmail.com> added the comment:

@eryksun - I knew the reproducibility is the issue with this bug. On the same PC I've been having a problem with, I created another dummy account with a space in its username, and it worked flawlessly... So, it's something I've done to my account which triggered this behavior. 

Is there anything that I can try and report on my machine? I'd be happy to do so

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46686>
_______________________________________

From report at bugs.python.org  Tue Feb  8 20:19:33 2022
From: report at bugs.python.org (Eric Snow)
Date: Wed, 09 Feb 2022 01:19:33 +0000
Subject: [issue36876] [subinterpreters] Global C variables are a problem
In-Reply-To: <1557514902.13.0.853517754348.issue36876@roundup.psfhosted.org>
Message-ID: <1644369573.57.0.957229112209.issue36876@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
pull_requests: +29396
pull_request: https://github.com/python/cpython/pull/31225

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36876>
_______________________________________

From report at bugs.python.org  Tue Feb  8 20:31:08 2022
From: report at bugs.python.org (Hai Shi)
Date: Wed, 09 Feb 2022 01:31:08 +0000
Subject: [issue46613] Add PyType_GetModuleByDef to the public & limited API
In-Reply-To: <1643820922.83.0.000906972876287.issue46613@roundup.psfhosted.org>
Message-ID: <1644370268.78.0.853735517171.issue46613@roundup.psfhosted.org>


Change by Hai Shi <shihai1991 at 126.com>:


----------
nosy: +shihai1991

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46613>
_______________________________________

From report at bugs.python.org  Tue Feb  8 20:38:05 2022
From: report at bugs.python.org (Eric Snow)
Date: Wed, 09 Feb 2022 01:38:05 +0000
Subject: [issue36876] [subinterpreters] Global C variables are a problem
In-Reply-To: <1557514902.13.0.853517754348.issue36876@roundup.psfhosted.org>
Message-ID: <1644370685.09.0.696406619898.issue36876@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:


New changeset 77bab59c8a1f04922bb975cc4f11e5323d1d379d by Eric Snow in branch 'main':
bpo-36876: Update the c-analyzer whitelist. (gh-31225)
https://github.com/python/cpython/commit/77bab59c8a1f04922bb975cc4f11e5323d1d379d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36876>
_______________________________________

From report at bugs.python.org  Tue Feb  8 22:06:04 2022
From: report at bugs.python.org (German Salazar)
Date: Wed, 09 Feb 2022 03:06:04 +0000
Subject: [issue46683] Python 3.6.15 source tarball installs 3.6.8?
In-Reply-To: <1644342955.93.0.0263962479248.issue46683@roundup.psfhosted.org>
Message-ID: <1644375964.09.0.110313547538.issue46683@roundup.psfhosted.org>


German Salazar <salgerman at gmail.com> added the comment:

So, help me understand, please. 


if I use "--enable-shared":
the build produces a rather small python executable; but, 
the build produces a dynamic library, too
and the path to the dynamic library must be included into LD_LIBRARY_PATH for the python executable to work correctly.

if I do NOT use "--enable-shared"
the build produces a larger python executable; and,
it does not produce a dynamic library, but
it produces an static library.
Does this mean that I do not have to worry about setting up LD_LIBRARY_PATH?

In the non-shared, static case, I thought the static library would be inside the executable, but, funny enough, I noticed that the python executable is smaller than the static library, so...I am confused. 

I would like to have 3.6, next to 3.7 and 3.8 with minimal setup, thus the static route.

Please advise.

----------
components: +Installation
resolution: not a bug -> 
status: closed -> open
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46683>
_______________________________________

From report at bugs.python.org  Tue Feb  8 22:17:22 2022
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 09 Feb 2022 03:17:22 +0000
Subject: [issue46683] Python 3.6.15 source tarball installs 3.6.8?
In-Reply-To: <1644342955.93.0.0263962479248.issue46683@roundup.psfhosted.org>
Message-ID: <1644376642.79.0.846170359444.issue46683@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

That's a question better suited to a forum such as the Users category of discuss.python.org, the python-list at python.org mailing list, or StackOverflow, not a bug tracker issue.

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46683>
_______________________________________

From report at bugs.python.org  Tue Feb  8 23:29:51 2022
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 09 Feb 2022 04:29:51 +0000
Subject: [issue46686] [venv / PC/launcher] issue with a space in the installed
 python path
In-Reply-To: <1644360519.94.0.220947714115.issue46686@roundup.psfhosted.org>
Message-ID: <1644380991.91.0.379272960434.issue46686@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

I checked the source code in PC/launcher.c process(). It turns out that `executable` is not getting quoted in the venv launcher case.

CreateProcessW() tries to get around this. If the command isn't quoted, it has a loop that consumes up to a space (or tab) and checks for an existing file (not a directory). If it finds a file, it rewrites the command line to quote the path of the file.

My test happened to work. But it's simple enough to create an example that fails. For example, as an elevated admin, create a file named "C:\Program". Now the venv launcher won't be able to execute a base interpreter that's installed in "C:\Program Files":

    C:\Temp>echo >C:\Program
    
    C:\Temp>"C:\Program Files\Python310\python.exe" -m venv env
    Error: Command '['C:\\Temp\\env\\Scripts\\python.exe', '-Im', 
    'ensurepip', '--upgrade', '--default-pip']' returned non-zero 
    exit status 101.

----------
priority: normal -> critical
stage:  -> needs patch
versions: +Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46686>
_______________________________________

From report at bugs.python.org  Wed Feb  9 00:01:17 2022
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 09 Feb 2022 05:01:17 +0000
Subject: [issue46688] Add sys.is_interned
Message-ID: <1644382877.05.0.348106052559.issue46688@roundup.psfhosted.org>


New submission from Inada Naoki <songofacandy at gmail.com>:

deepfreeze.py needs to know the unicode object is interned.

Ref: https://bugs.python.org/issue46430

----------
components: Interpreter Core
messages: 412890
nosy: methane
priority: normal
severity: normal
status: open
title: Add sys.is_interned
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46688>
_______________________________________

From report at bugs.python.org  Wed Feb  9 00:19:33 2022
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 09 Feb 2022 05:19:33 +0000
Subject: [issue46688] Add sys.is_interned
In-Reply-To: <1644382877.05.0.348106052559.issue46688@roundup.psfhosted.org>
Message-ID: <1644383973.38.0.504017522152.issue46688@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
keywords: +patch
pull_requests: +29397
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31227

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46688>
_______________________________________

From report at bugs.python.org  Wed Feb  9 00:32:53 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 09 Feb 2022 05:32:53 +0000
Subject: [issue46684] Expose frozenset._hash classmethod
In-Reply-To: <1644344552.11.0.546290047749.issue46684@roundup.psfhosted.org>
Message-ID: <1644384773.44.0.616757079252.issue46684@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/issue46684>
_______________________________________

From report at bugs.python.org  Wed Feb  9 00:41:20 2022
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 09 Feb 2022 05:41:20 +0000
Subject: [issue46688] Add sys.is_interned
In-Reply-To: <1644382877.05.0.348106052559.issue46688@roundup.psfhosted.org>
Message-ID: <1644385280.88.0.0841032753834.issue46688@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

I thought sys.is_interned() is needed to implement bpo-46430, but GH-30683 looks nice to me.
I will close this issue after GH-30683 is merged.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46688>
_______________________________________

From report at bugs.python.org  Wed Feb  9 00:43:06 2022
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 09 Feb 2022 05:43:06 +0000
Subject: [issue46688] Add sys.is_interned
In-Reply-To: <1644382877.05.0.348106052559.issue46688@roundup.psfhosted.org>
Message-ID: <1644385386.2.0.690493938797.issue46688@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

See also https://bugs.python.org/issue34392

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46688>
_______________________________________

From report at bugs.python.org  Wed Feb  9 00:52:10 2022
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 09 Feb 2022 05:52:10 +0000
Subject: [issue46688] Add sys.is_interned
In-Reply-To: <1644382877.05.0.348106052559.issue46688@roundup.psfhosted.org>
Message-ID: <1644385930.49.0.686179703963.issue46688@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

Thank you, I can not find it because it is too old.

----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> Add sys.isinterned()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46688>
_______________________________________

From report at bugs.python.org  Wed Feb  9 01:28:54 2022
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 09 Feb 2022 06:28:54 +0000
Subject: [issue46686] [venv / PC/launcher] issue with a space in the installed
 python path
In-Reply-To: <1644360519.94.0.220947714115.issue46686@roundup.psfhosted.org>
Message-ID: <1644388134.4.0.337532353418.issue46686@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

The venv launcher can quote the executable path either always or only when it contains spaces. The following is a suggestion for implementing the latter.

Before allocating `executable`, use memchr() (include <memory.h>) to search the UTF-8 source for a space. If found, increment the character count by two. After allocating `executable`, add the initial quote character, and increment the pointer.

        BOOL add_quotes = FALSE;
        if (memchr(start, ' ', (size_t)len) != NULL) {
            add_quotes = TRUE;
            cch += 2;
        }

        executable = (wchar_t *)malloc(cch * sizeof(wchar_t));
        if (executable == NULL) {
            error(RC_NO_MEMORY, L"A memory allocation failed");
        }
        
        if (add_quotes) {
            *executable++ = L'\"';
        }

Later, after checking the existence via GetFileAttributesW(), add the trailing quote and null, and decrement the pointer:

        if (GetFileAttributesW(executable) == INVALID_FILE_ATTRIBUTES) {
            error(RC_NO_PYTHON, L"No Python at '%ls'", executable);
        }

        if (add_quotes) {
            size_t n = wcslen(executable);
            executable[n] = L'\"';
            executable[n + 1] = L'\0';
            executable--;
        }

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46686>
_______________________________________

From report at bugs.python.org  Wed Feb  9 03:46:18 2022
From: report at bugs.python.org (Alex Waygood)
Date: Wed, 09 Feb 2022 08:46:18 +0000
Subject: [issue46333] ForwardRef.__eq__ does not respect module parameter
In-Reply-To: <1641828029.13.0.319383260427.issue46333@roundup.psfhosted.org>
Message-ID: <1644396378.39.0.656992680172.issue46333@roundup.psfhosted.org>


Change by Alex Waygood <Alex.Waygood at Gmail.com>:


----------
nosy: +Jelle Zijlstra, sobolevn

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46333>
_______________________________________

From report at bugs.python.org  Wed Feb  9 04:36:33 2022
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 09 Feb 2022 09:36:33 +0000
Subject: [issue46662] Lib/sqlite3/dbapi2.py: convert_timestamp function failed
 to correctly parse timestamp
In-Reply-To: <1644317665.3.0.667883627707.issue46662@roundup.psfhosted.org>
Message-ID: <7f85873b-9ec0-92d6-1fda-f8afb4ee32c5@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 08.02.2022 11:54, Erlend E. Aasland wrote:
> 
> The sqlite3 timestamp converter is buggy, as already noted in the docs[^1]. Adding timezone support is out of the question[^2][^3][^4][^5], but fixing it to be able to discard any attached timezone info _may_ be ok; at first sight, I don't see how this could break existing applications (like, for example adding time zone support could do). I need to think it through.

I think it's better to deprecate these converters and let users implement
their own.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46662>
_______________________________________

From report at bugs.python.org  Wed Feb  9 05:25:48 2022
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 09 Feb 2022 10:25:48 +0000
Subject: [issue45413] Add install scheme for virtual environments
In-Reply-To: <1633715402.49.0.434363843275.issue45413@roundup.psfhosted.org>
Message-ID: <1644402348.99.0.927963324676.issue45413@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

> I think we want the scheme to be static and accessible on all platforms, like the others. So it probably should be 'nt_venv' and 'posix_venv' with additional/improved logic to help apps determine when they need each.

Why? (This is a real question, I genuinely don't know.)

To put this in context, this has been discussed since October, and there was agreement on how to change it.
Now a PR exists. It is tested. Also, since this fixes urgent breaking changes, patches for "venv" is already in Fedora and Ubuntu deadsnakes PPA, and virtualenv also supports it. Changing direction now will mean lots of work changing and re-testing anything. That's definitely possible, just frustrating, but if someone calls to change something again, we risk not making it in 3.11.

How can we ensure the decision won't change again?
How can these discussions be made more effective?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45413>
_______________________________________

From report at bugs.python.org  Wed Feb  9 06:31:51 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Wed, 09 Feb 2022 11:31:51 +0000
Subject: [issue46689] `list(FunctionType(a.gi_code, {})(0))` crashes Python
Message-ID: <1644406311.26.0.616936444493.issue46689@roundup.psfhosted.org>


New submission from Nikita Sobolev <mail at sobolevn.me>:

Here's the simplest reproduction:

```
from types import FunctionType
a = (x for x in [1])
list(FunctionType(a.gi_code, {})(0))
```

I understand that the code above does not make much sense, but I still think it should not crash.

Demo:

```
? PYTHONFAULTHANDLER=1 ./python.exe
Python 3.11.0a5+ (heads/issue-46647-dirty:88819357a5, Feb  5 2022, 18:19:59) [Clang 11.0.0 (clang-1100.0.33.16)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from types import FunctionType
>>> a = (x for x in [1])
>>> list(FunctionType(a.gi_code, {})(0))
Fatal Python error: Segmentation fault

Current thread 0x0000000112ece5c0 (most recent call first):
  File "<stdin>", line 1 in <genexpr>
  File "<stdin>", line 1 in <module>
[1]    22662 segmentation fault  PYTHONFAULTHANDLER=1 ./python.exe
```

I can reproduce this on 3.9 and 3.10 as well.

----------
components: Interpreter Core
messages: 412897
nosy: sobolevn
priority: normal
severity: normal
status: open
title: `list(FunctionType(a.gi_code, {})(0))` crashes Python
type: crash
versions: Python 3.10, Python 3.11, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46689>
_______________________________________

From report at bugs.python.org  Wed Feb  9 06:40:17 2022
From: report at bugs.python.org (Mariusz Felisiak)
Date: Wed, 09 Feb 2022 11:40:17 +0000
Subject: [issue43882] [security] CVE-2022-0391: urllib.parse should sanitize
 urls containing ASCII newline and tabs.
In-Reply-To: <1618774620.3.0.412025280445.issue43882@roundup.psfhosted.org>
Message-ID: <1644406817.25.0.78647755271.issue43882@roundup.psfhosted.org>


Change by Mariusz Felisiak <felisiak.mariusz at gmail.com>:


----------
nosy: +felixxm

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43882>
_______________________________________

From report at bugs.python.org  Wed Feb  9 06:48:38 2022
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 09 Feb 2022 11:48:38 +0000
Subject: [issue46072] Unify handling of stats in the CPython VM
In-Reply-To: <1639498673.65.0.709719181358.issue46072@roundup.psfhosted.org>
Message-ID: <1644407318.15.0.356361442865.issue46072@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
pull_requests: +29398
pull_request: https://github.com/python/cpython/pull/31228

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46072>
_______________________________________

From report at bugs.python.org  Wed Feb  9 06:54:00 2022
From: report at bugs.python.org (James Marchant)
Date: Wed, 09 Feb 2022 11:54:00 +0000
Subject: [issue46690] create_autospec() doesn't respect configure_mock style
 kwargs
Message-ID: <1644407640.16.0.14753457907.issue46690@roundup.psfhosted.org>


New submission from James Marchant <marchant.jm at gmail.com>:

When using `create_autospec()` to create a mock object, it doesn't respect values passed through in the style described for passing mock configurations in the Mock constructor (https://docs.python.org/3.8/library/unittest.mock.html#unittest.mock.Mock.configure_mock). Instead, they seem to get discarded somewhere here (https://github.com/python/cpython/blob/77bab59c8a1f04922bb975cc4f11e5323d1d379d/Lib/unittest/mock.py#L2693-L2741).

Here's a simple test case:
```
from unittest.mock import create_autospec

class Test:
    def test_method(self):
        pass

autospec_mock = create_autospec(Test, instance=True, **{"test_method.side_effect": ValueError})

# Should throw a ValueError exception
autospec_mock.test_method()

# Assign manually
autospec_mock.test_method.side_effect = ValueError
# Throws as expected
autospec_mock.test_method()
```

----------
components: Tests
messages: 412898
nosy: marchant.jm
priority: normal
severity: normal
status: open
title: create_autospec() doesn't respect configure_mock style kwargs
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46690>
_______________________________________

From report at bugs.python.org  Wed Feb  9 07:09:55 2022
From: report at bugs.python.org (Ben Griffin)
Date: Wed, 09 Feb 2022 12:09:55 +0000
Subject: [issue39860] configparser - no support for cascading defaults (as
 defined by MySQL)
In-Reply-To: <1583399277.82.0.801521222284.issue39860@roundup.psfhosted.org>
Message-ID: <1644408595.02.0.429577850059.issue39860@roundup.psfhosted.org>


Ben Griffin <ben at redsnapper.net> added the comment:

This is still being ignored.  
It's a bug, because it prevents the ini file from being used by other clients.

----------
versions: +Python 3.10, Python 3.11, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39860>
_______________________________________

From report at bugs.python.org  Wed Feb  9 07:16:49 2022
From: report at bugs.python.org (Duncan Macleod)
Date: Wed, 09 Feb 2022 12:16:49 +0000
Subject: [issue46691] sysconfig.get_platform() raises ValueError on macOS if
 '-arch' is present in CFLAGS but doesn't refer to the '-arch' compiler flag
Message-ID: <1644409009.26.0.313805274681.issue46691@roundup.psfhosted.org>


New submission from Duncan Macleod <macleoddm at cardiff.ac.uk>:

The `sysconfig.get_platform()` function raises a `ValueError` if the `cflags` config value (e.g. the `CFLAGS` used at build time) includes the text `-arch` where that doesn't refer to the compiler flag of the same name.

Consider the following example build:

$ sw_vers
ProductName:    macOS
ProductVersion: 11.6.3
BuildVersion:   20G415
$ curl -LO https://www.python.org/ftp/python/3.10.2/Python-3.10.2.tar.xz
$ tar -xf Python-3.10.2.tar.xz
$ cd Python-3.10.2
$ export CFLAGS="-Itest-arch/fake"  # just something that includes -arch
$ ./configure --prefix=$(pwd)/test-arch
$ make -j

Here the build fails with the following error:


./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
Traceback (most recent call last):
  File "/Users/duncanmacleod/src/Python-3.10.2/Lib/runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/Users/duncanmacleod/src/Python-3.10.2/Lib/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/Users/duncanmacleod/src/Python-3.10.2/Lib/sysconfig.py", line 803, in <module>
    _main()
  File "/Users/duncanmacleod/src/Python-3.10.2/Lib/sysconfig.py", line 791, in _main
    _generate_posix_vars()
  File "/Users/duncanmacleod/src/Python-3.10.2/Lib/sysconfig.py", line 457, in _generate_posix_vars
    pybuilddir = f'build/lib.{get_platform()}-{_PY_VERSION_SHORT}'
  File "/Users/duncanmacleod/src/Python-3.10.2/Lib/sysconfig.py", line 744, in get_platform
    osname, release, machine = _osx_support.get_platform_osx(
  File "/Users/duncanmacleod/src/Python-3.10.2/Lib/_osx_support.py", line 556, in get_platform_osx
    raise ValueError(
ValueError: Don't know machine value for archs=()
generate-posix-vars failed

Sorry if this is a duplicate of an existing issue.

----------
components: Library (Lib)
messages: 412900
nosy: duncanmmacleod
priority: normal
severity: normal
status: open
title: sysconfig.get_platform() raises ValueError on macOS if '-arch' is present in CFLAGS but doesn't refer to the '-arch' compiler flag
type: crash
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46691>
_______________________________________

From report at bugs.python.org  Wed Feb  9 07:23:52 2022
From: report at bugs.python.org (Ali Rn)
Date: Wed, 09 Feb 2022 12:23:52 +0000
Subject: [issue46692] match case does not support regex
Message-ID: <1644409432.19.0.449385513127.issue46692@roundup.psfhosted.org>


Change by Ali Rn <alirn1997 at gmail.com>:


----------
components: Regular Expressions
nosy: AliRn, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: match case does not support regex
type: behavior
versions: Python 3.10, Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46692>
_______________________________________

From report at bugs.python.org  Wed Feb  9 07:30:39 2022
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 09 Feb 2022 12:30:39 +0000
Subject: [issue46072] Unify handling of stats in the CPython VM
In-Reply-To: <1639498673.65.0.709719181358.issue46072@roundup.psfhosted.org>
Message-ID: <1644409839.55.0.141514174308.issue46072@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset f71a69aa9209cf67cc1060051b147d6afa379bba by Mark Shannon in branch 'main':
bpo-46072: Output stats as markdown with collapsible sections. (GH-31228)
https://github.com/python/cpython/commit/f71a69aa9209cf67cc1060051b147d6afa379bba


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46072>
_______________________________________

From report at bugs.python.org  Wed Feb  9 07:39:39 2022
From: report at bugs.python.org (firewave)
Date: Wed, 09 Feb 2022 12:39:39 +0000
Subject: [issue45789] Python execution broken after update via Windows Store
In-Reply-To: <1636661843.78.0.241514284598.issue45789@roundup.psfhosted.org>
Message-ID: <1644410379.25.0.056265644012.issue45789@roundup.psfhosted.org>


firewave <oliverst at online.de> added the comment:

A few weeks ago I was able to re-install Python 3.9 and 3.10 after manually removing the %LocalAppData%\Microsoft\WindowsApps\PythonSoftwareFoundation.Python.3.* and disabling/enabling the applinks manually and uninstalling/installing a few times to get rid of all left-over applinks on the disk.

I still had two entries by "App Installer" for python.exe and python3.exe in the UI. But I assume those have been there for ages now.

But as soon as the next update was installed both version broke again.

So I tried the same again and uninstalling and manually deleting the folders is no longer enough. I still have applinks in that folder which I cannot delete. And I can no longer install the apps at all. They fail with

Installation Failure: Windows failed to install the following update with error 0x80070020: 9P7QFQMJRFP7-PythonSoftwareFoundation.Python.3.9.

So now it's completely broken.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45789>
_______________________________________

From report at bugs.python.org  Wed Feb  9 08:34:39 2022
From: report at bugs.python.org (Alex Waygood)
Date: Wed, 09 Feb 2022 13:34:39 +0000
Subject: [issue46622] Support decorating a coroutine with
 functools.cached_property
In-Reply-To: <1643873308.65.0.92890586202.issue46622@roundup.psfhosted.org>
Message-ID: <1644413679.94.0.823748755902.issue46622@roundup.psfhosted.org>


Change by Alex Waygood <Alex.Waygood at Gmail.com>:


----------
nosy: +asvetlov, rhettinger, yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46622>
_______________________________________

From report at bugs.python.org  Wed Feb  9 08:38:54 2022
From: report at bugs.python.org (Meer Suri)
Date: Wed, 09 Feb 2022 13:38:54 +0000
Subject: [issue46586] In documentation contents enum.property erroneously
 links to built-in property
In-Reply-To: <1643555525.86.0.209520180874.issue46586@roundup.psfhosted.org>
Message-ID: <1644413934.88.0.605893793747.issue46586@roundup.psfhosted.org>


Meer Suri <meersuri at gmail.com> added the comment:

I looked through the sys.float_info docs and I guess that you are referring to the max and min attributes of sys.float_info that are linking to the built-in max() and min() functions?

In that case as there is no documentation for the max and min attributes of sys.float_info, should they not link to anything?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46586>
_______________________________________

From report at bugs.python.org  Wed Feb  9 09:03:31 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 09 Feb 2022 14:03:31 +0000
Subject: [issue46692] match case does not support regex
Message-ID: <1644415411.36.0.255696971678.issue46692@roundup.psfhosted.org>


New submission from Eric V. Smith <eric at trueblade.com>:

You need to provide more information.

Is your concern that re.match objects aren't matched like dicts are, despite looking like a mapping?

import re

def f(map):
    print(f'input={m["one"]} {m["two"]}')
    match map:
        case {'one': x, 'two': y}:
            print(f"match {x} {y}")
        case _:
            print("no match")

m = re.match("(?P<one>a)b(?P<two>c)", "abc")
d = {'one':0, 'two':1}
f(d)
f(m)

produces:
input=a c
match 0 1
input=a c
no match

I assume you're not reporting a bug, so I'm going to mark this as a feature request.

----------
nosy: +eric.smith
type: behavior -> enhancement
versions:  -Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46692>
_______________________________________

From report at bugs.python.org  Wed Feb  9 09:03:43 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 09 Feb 2022 14:03:43 +0000
Subject: [issue46692] match case does not support regex
In-Reply-To: <1644415411.36.0.255696971678.issue46692@roundup.psfhosted.org>
Message-ID: <1644415423.38.0.00524573729898.issue46692@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
components: +Interpreter Core

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46692>
_______________________________________

From report at bugs.python.org  Wed Feb  9 09:13:51 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 09 Feb 2022 14:13:51 +0000
Subject: [issue46692] match case does not support regex
In-Reply-To: <1644415411.36.0.255696971678.issue46692@roundup.psfhosted.org>
Message-ID: <1644416031.79.0.491671597569.issue46692@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Oops, slight bug in my code. Use this:

import re

def f(map):
    print(f'input={map["one"]} {map["two"]}')
    match map:
        case {'one': x, 'two': y}:
            print(f"match {x} {y}")
        case _:
            print("no match")

d = {'one':0, 'two':1}
f(d)
m = re.match("(?P<one>a)b(?P<two>c)", "abc")
f(m)

With this output:
input=0 1
match 0 1
input=a c
no match

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46692>
_______________________________________

From report at bugs.python.org  Wed Feb  9 09:21:42 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 09 Feb 2022 14:21:42 +0000
Subject: [issue46622] Support decorating a coroutine with
 functools.cached_property
In-Reply-To: <1643873308.65.0.92890586202.issue46622@roundup.psfhosted.org>
Message-ID: <1644416502.02.0.319743440559.issue46622@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Pull Request is welcome!
I would say that the PR should not use asyncio directly but 'async def', 'await', and `inspect.iscoroutine()` / `inspect.iscoroutinefunction()` instead.
The property should work with any async framework, not asyncio only.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46622>
_______________________________________

From report at bugs.python.org  Wed Feb  9 09:23:20 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 09 Feb 2022 14:23:20 +0000
Subject: [issue46685] Add additional tests for new features in `typing.py`
In-Reply-To: <1644350626.56.0.225939389842.issue46685@roundup.psfhosted.org>
Message-ID: <1644416600.27.0.613677339286.issue46685@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:


New changeset d2d1d49eaccaa83eb8873ba15f2fc9562143bc56 by Nikita Sobolev in branch 'main':
bpo-46685: cover `TypeError` of `ForwardRef(1)` in `test_typing` (GH-31223)
https://github.com/python/cpython/commit/d2d1d49eaccaa83eb8873ba15f2fc9562143bc56


----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46685>
_______________________________________

From report at bugs.python.org  Wed Feb  9 09:23:27 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 09 Feb 2022 14:23:27 +0000
Subject: [issue46685] Add additional tests for new features in `typing.py`
In-Reply-To: <1644350626.56.0.225939389842.issue46685@roundup.psfhosted.org>
Message-ID: <1644416607.37.0.255480484907.issue46685@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: +29399
pull_request: https://github.com/python/cpython/pull/31229

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46685>
_______________________________________

From report at bugs.python.org  Wed Feb  9 09:23:31 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 09 Feb 2022 14:23:31 +0000
Subject: [issue46685] Add additional tests for new features in `typing.py`
In-Reply-To: <1644350626.56.0.225939389842.issue46685@roundup.psfhosted.org>
Message-ID: <1644416611.72.0.148482290146.issue46685@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29400
pull_request: https://github.com/python/cpython/pull/31230

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46685>
_______________________________________

From report at bugs.python.org  Wed Feb  9 09:25:47 2022
From: report at bugs.python.org (Steve Dower)
Date: Wed, 09 Feb 2022 14:25:47 +0000
Subject: [issue46687] Update pyexpat for CVE-2021-45960
In-Reply-To: <1644363905.53.0.879497437531.issue46687@roundup.psfhosted.org>
Message-ID: <1644416747.72.0.00590669733242.issue46687@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Probably. I searched for the CVE number and didn't find it anywhere, but that issue only mentions the new release version.

----------
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> Please update bundled libexpat to 2.4.4 with security fixes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46687>
_______________________________________

From report at bugs.python.org  Wed Feb  9 09:34:31 2022
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 09 Feb 2022 14:34:31 +0000
Subject: [issue46586] In documentation contents enum.property erroneously
 links to built-in property
In-Reply-To: <1643555525.86.0.209520180874.issue46586@roundup.psfhosted.org>
Message-ID: <1644417271.81.0.772967880911.issue46586@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> added the comment:

Yes, I was referring to these two attributes.
They should not link to anything: the place I linked *is* the documentation for them.
Other instances of this problem could be listed in this ticket and fixed by the same PR (doesn?t matter than enum.property is only for 3.11, the backport PRs can be a little different), or tracked in a separate ticket if that seems more convenient.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46586>
_______________________________________

From report at bugs.python.org  Wed Feb  9 09:42:02 2022
From: report at bugs.python.org (Steve Dower)
Date: Wed, 09 Feb 2022 14:42:02 +0000
Subject: [issue45789] Python execution broken after update via Windows Store
In-Reply-To: <1636661843.78.0.241514284598.issue45789@roundup.psfhosted.org>
Message-ID: <1644417722.21.0.35465398652.issue45789@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

It still unfortunately sounds like a Windows issue. All we do is specify that there should be a file there, we have nothing to do with creating or removing them. I'm not sure there's anything else we can do to help.

You could try reporting the issue using the Windows Feedback app. This at least will get it straight into the correct team's issue tracker, along with whatever logs you let it collect, though unless a number of people have been reporting it, it may not get a lot of attention unfortunately.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45789>
_______________________________________

From report at bugs.python.org  Wed Feb  9 09:52:38 2022
From: report at bugs.python.org (Steve Dower)
Date: Wed, 09 Feb 2022 14:52:38 +0000
Subject: [issue45413] Add install scheme for virtual environments
In-Reply-To: <1633715402.49.0.434363843275.issue45413@roundup.psfhosted.org>
Message-ID: <1644418358.5.0.141654044217.issue45413@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

All I can say is that I wasn't aware of this discussion, or it blurred into the other discussions and didn't seem to need any attention from me. 
Once I was pinged on the pull request (and I'm *trying* to be better at checking GitHub notifications, though CPython is still the repo that makes it very hard), I took a look.

I definitely don't want to say that I must be consulted on every sysconfig/site/getpath change (because I don't want to be!), but I hesitate to say that this was the wrong way for it to be caught. It's only "too late" after a release has included it, and up until then it's fine.

So I guess it can be avoided in the future by checking the surrounding code and seeing how it's used? In this case, the schemes are all approximately static (for a given version of Python), and the *selection* of a scheme is based on the platform. The proposed venv scheme itself is based on the platform, while selection is static. That stands out to me as a difference.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45413>
_______________________________________

From report at bugs.python.org  Wed Feb  9 10:12:30 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 09 Feb 2022 15:12:30 +0000
Subject: [issue46685] Add additional tests for new features in `typing.py`
In-Reply-To: <1644350626.56.0.225939389842.issue46685@roundup.psfhosted.org>
Message-ID: <1644419550.98.0.497347816663.issue46685@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset d29bbc22b08551afce24e933f43bfcb6e980cb08 by Miss Islington (bot) in branch '3.10':
bpo-46685: cover `TypeError` of `ForwardRef(1)` in `test_typing` (GH-31223)
https://github.com/python/cpython/commit/d29bbc22b08551afce24e933f43bfcb6e980cb08


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46685>
_______________________________________

From report at bugs.python.org  Wed Feb  9 10:12:36 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 09 Feb 2022 15:12:36 +0000
Subject: [issue46685] Add additional tests for new features in `typing.py`
In-Reply-To: <1644350626.56.0.225939389842.issue46685@roundup.psfhosted.org>
Message-ID: <1644419556.12.0.759687640596.issue46685@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset bde3765a3fd21e2ecf595a57998b285e3045f744 by Miss Islington (bot) in branch '3.9':
bpo-46685: cover `TypeError` of `ForwardRef(1)` in `test_typing` (GH-31223)
https://github.com/python/cpython/commit/bde3765a3fd21e2ecf595a57998b285e3045f744


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46685>
_______________________________________

From report at bugs.python.org  Wed Feb  9 10:32:46 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 09 Feb 2022 15:32:46 +0000
Subject: [issue46692] match case does not support regex
In-Reply-To: <1644415411.36.0.255696971678.issue46692@roundup.psfhosted.org>
Message-ID: <1644420766.02.0.397774642249.issue46692@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Looking at PEP 634, the obvious way to add support for this is to have the re.Match object specify Py_TPFLAGS_MAPPING. But I tried that, and then I get this error when using an re.Match object in a match statement:

    case {'one': x, 'two': y}:
         ^^^^^^^^^^^^^^^^^^^^
TypeError: object of type 're.Match' has no len()


Add len() to re.Match objects was rejected when __getitem__ was added to re.Match, in issue 24454.

I haven't explored other ways to support re.Match objects in the match statement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46692>
_______________________________________

From report at bugs.python.org  Wed Feb  9 10:35:13 2022
From: report at bugs.python.org (Meer Suri)
Date: Wed, 09 Feb 2022 15:35:13 +0000
Subject: [issue46494] Mention typing_extensions in the typing documentation
In-Reply-To: <1642985496.62.0.269697400688.issue46494@roundup.psfhosted.org>
Message-ID: <1644420913.76.0.284953163979.issue46494@roundup.psfhosted.org>


Meer Suri <meersuri at gmail.com> added the comment:

(First time contributor looking for guidance) Is this diff okay? I'm not sure if the package name should be typing-extensions, or if the formatting is okay

diff --git a/Doc/library/typing.rst b/Doc/library/typing.rst
index 94a46b01a1..c0fe656c1c 100644
--- a/Doc/library/typing.rst
+++ b/Doc/library/typing.rst
@@ -32,6 +32,11 @@ In the function ``greeting``, the argument ``name`` is expected to be of type
 :class:`str` and the return type :class:`str`. Subtypes are accepted as
 arguments.

+New features have been added to the typing module in each major version of
+Python. The `typing_extensions <https://pypi.org/project/typing-extensions/>`_
+package provides backports to all supported versions of Python 3 for almost
+all of these features.
+
 .. _relevant-peps:

 Relevant PEPs

----------
nosy: +meersuri

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46494>
_______________________________________

From report at bugs.python.org  Wed Feb  9 10:39:24 2022
From: report at bugs.python.org (firewave)
Date: Wed, 09 Feb 2022 15:39:24 +0000
Subject: [issue45789] Python execution broken after update via Windows Store
In-Reply-To: <1636661843.78.0.241514284598.issue45789@roundup.psfhosted.org>
Message-ID: <1644421164.22.0.839853470605.issue45789@roundup.psfhosted.org>


firewave <oliverst at online.de> added the comment:

I figured it out.

I tried to delete the files using PowerShell and I got the following:

Remove-Item : Cannot remove item C:\Users\Username\AppData\Local\Microsoft\WindowsApps\python.exe: The
process cannot access the file 'C:\Users\Username\AppData\Local\Microsoft\WindowsApps\python.exe' because it
is being used by another process.

Using the "Resource Monitor" via the "CPU" tab and "Associated Handles" I was able the process which was using those. Somehow the handle search in "Process Explorer" was not returning this.

After closing the process I was able to remove the files and install Python again.

So it is exactly as I suspected before. When an update/uninstall is performed and the files are in use they cannot be updated/removed.

It should probably check this early and fail in case the files are in use so it doesn't perform a partial operation leaving the app unusable/not installable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45789>
_______________________________________

From report at bugs.python.org  Wed Feb  9 10:41:56 2022
From: report at bugs.python.org (firewave)
Date: Wed, 09 Feb 2022 15:41:56 +0000
Subject: [issue45789] Python execution broken after update via Windows Store
In-Reply-To: <1636661843.78.0.241514284598.issue45789@roundup.psfhosted.org>
Message-ID: <1644421316.13.0.711603099861.issue45789@roundup.psfhosted.org>


firewave <oliverst at online.de> added the comment:

Actually "Process Explorer" finds the handle as well. No idea why it didn't come up in my last search.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45789>
_______________________________________

From report at bugs.python.org  Wed Feb  9 11:01:34 2022
From: report at bugs.python.org (Kesh Ikuma)
Date: Wed, 09 Feb 2022 16:01:34 +0000
Subject: [issue46686] [venv / PC/launcher] issue with a space in the installed
 python path
In-Reply-To: <1644360519.94.0.220947714115.issue46686@roundup.psfhosted.org>
Message-ID: <1644422494.03.0.0956799650588.issue46686@roundup.psfhosted.org>


Kesh Ikuma <tikuma at hotmail.com> added the comment:

> a file named "C:\Program". Now the venv launcher won't be able to execute

This is exactly what happened on my PC, and the behavior was triggered by Microsoft Visual C++ 2015-2022 Redistributable installer. The installer left a log file "C:\Users\Kesh" with my account "C:\Users\Kesh Ikuma".

Thank you for quickly addressing the issue

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46686>
_______________________________________

From report at bugs.python.org  Wed Feb  9 11:15:34 2022
From: report at bugs.python.org (Steve Dower)
Date: Wed, 09 Feb 2022 16:15:34 +0000
Subject: [issue46638] Inconsistent registry virtualization in Windows Store
 package
In-Reply-To: <1643991370.43.0.929070469703.issue46638@roundup.psfhosted.org>
Message-ID: <1644423334.16.0.330473642714.issue46638@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/issue46638>
_______________________________________

From report at bugs.python.org  Wed Feb  9 11:19:26 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 09 Feb 2022 16:19:26 +0000
Subject: [issue44289] tarfile.is_tarfile() and tarfile.open() when used with
 file object may cause tarfile operations to fail
In-Reply-To: <1622646545.23.0.614350359918.issue44289@roundup.psfhosted.org>
Message-ID: <1644423566.17.0.0721043880872.issue44289@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset 128ab092cad984b73a117f58fa0e9b4105051a04 by Andrzej Mateja in branch 'main':
bpo-44289: Keep argument file object's current position in tarfile.is_tarfile (GH-26488)
https://github.com/python/cpython/commit/128ab092cad984b73a117f58fa0e9b4105051a04


----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44289>
_______________________________________

From report at bugs.python.org  Wed Feb  9 11:20:06 2022
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 09 Feb 2022 16:20:06 +0000
Subject: [issue46532] Improve efficiency of PRECALL/CALL instructions
In-Reply-To: <1643190282.99.0.74296903316.issue46532@roundup.psfhosted.org>
Message-ID: <1644423606.94.0.732280176458.issue46532@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
title: Improve effeciency of PRECALL/CALL instructions -> Improve efficiency of PRECALL/CALL instructions

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46532>
_______________________________________

From report at bugs.python.org  Wed Feb  9 11:21:25 2022
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 09 Feb 2022 16:21:25 +0000
Subject: [issue46532] Improve efficiency of PRECALL/CALL instructions
In-Reply-To: <1643190282.99.0.74296903316.issue46532@roundup.psfhosted.org>
Message-ID: <1644423685.91.0.199054048302.issue46532@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
keywords: +patch
pull_requests: +29401
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31231

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46532>
_______________________________________

From report at bugs.python.org  Wed Feb  9 11:52:54 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 09 Feb 2022 16:52:54 +0000
Subject: [issue46430] intern strings in deepfrozen modules
In-Reply-To: <1642590983.92.0.896257318647.issue46430@roundup.psfhosted.org>
Message-ID: <1644425574.64.0.849002698825.issue46430@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset c0a5ebeb1239020f2ecc199053bb1a70d78841a1 by Kumar Aditya in branch 'main':
bpo-46430: Intern strings in deep-frozen modules  (GH-30683)
https://github.com/python/cpython/commit/c0a5ebeb1239020f2ecc199053bb1a70d78841a1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46430>
_______________________________________

From report at bugs.python.org  Wed Feb  9 12:02:29 2022
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 09 Feb 2022 17:02:29 +0000
Subject: [issue46692] match case does not support regex
In-Reply-To: <1644415411.36.0.255696971678.issue46692@roundup.psfhosted.org>
Message-ID: <1644426149.13.0.702153676076.issue46692@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

> There were ideas for exotic matchers such as IsInstance(), InRange(), RegexMatchingGroup() and so on.

https://www.python.org/dev/peps/pep-0622/#custom-matching-protocol

The PEP has some mention about a similar use case in custom match protocol section.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46692>
_______________________________________

From report at bugs.python.org  Wed Feb  9 12:04:27 2022
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 09 Feb 2022 17:04:27 +0000
Subject: [issue46690] create_autospec() doesn't respect configure_mock style
 kwargs
In-Reply-To: <1644407640.16.0.14753457907.issue46690@roundup.psfhosted.org>
Message-ID: <1644426267.09.0.571116399952.issue46690@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/issue46690>
_______________________________________

From report at bugs.python.org  Wed Feb  9 12:05:13 2022
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 09 Feb 2022 17:05:13 +0000
Subject: [issue46430] intern strings in deepfrozen modules
In-Reply-To: <1642590983.92.0.896257318647.issue46430@roundup.psfhosted.org>
Message-ID: <1644426313.18.0.320700129222.issue46430@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

I noticed that the new interning code lacks proper error reporting. There are only asserts. _PyCode_New() checks the return value of intern_strings.

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46430>
_______________________________________

From report at bugs.python.org  Wed Feb  9 12:06:29 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Feb 2022 17:06:29 +0000
Subject: [issue45863] tarfile zeroes ustar header fields unnecessarily
In-Reply-To: <1637568080.9.0.260845551853.issue45863@roundup.psfhosted.org>
Message-ID: <1644426389.28.0.226478023217.issue45863@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset bf2d44ffb06e8f49aacc6b1c140a6717df5cf897 by Joshua Root in branch 'main':
bpo-45863: tarfile: don't zero out header fields unnecessarily (GH-29693)
https://github.com/python/cpython/commit/bf2d44ffb06e8f49aacc6b1c140a6717df5cf897


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45863>
_______________________________________

From report at bugs.python.org  Wed Feb  9 12:06:51 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 09 Feb 2022 17:06:51 +0000
Subject: [issue45863] tarfile zeroes ustar header fields unnecessarily
In-Reply-To: <1637568080.9.0.260845551853.issue45863@roundup.psfhosted.org>
Message-ID: <1644426411.79.0.439039702627.issue45863@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: +29402
pull_request: https://github.com/python/cpython/pull/31232

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45863>
_______________________________________

From report at bugs.python.org  Wed Feb  9 12:06:55 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 09 Feb 2022 17:06:55 +0000
Subject: [issue45863] tarfile zeroes ustar header fields unnecessarily
In-Reply-To: <1637568080.9.0.260845551853.issue45863@roundup.psfhosted.org>
Message-ID: <1644426415.83.0.863673831677.issue45863@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29403
pull_request: https://github.com/python/cpython/pull/31233

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45863>
_______________________________________

From report at bugs.python.org  Wed Feb  9 12:12:50 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 09 Feb 2022 17:12:50 +0000
Subject: [issue46692] match case does not support regex
In-Reply-To: <1644415411.36.0.255696971678.issue46692@roundup.psfhosted.org>
Message-ID: <1644426770.63.0.524535508937.issue46692@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Good catch, @xtreak. I think something like the discussed (but not implemented) custom matching protocol would be required here. __match_args__ won't work, because it's a special attribute only checked on classes, not instances.

Of course, I'm still not sure this is what the original poster is requesting!

But assuming so, this would require a PEP, and should be discussed with the PEP 634 authors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46692>
_______________________________________

From report at bugs.python.org  Wed Feb  9 12:16:17 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Wed, 09 Feb 2022 17:16:17 +0000
Subject: [issue46494] Mention typing_extensions in the typing documentation
In-Reply-To: <1642985496.62.0.269697400688.issue46494@roundup.psfhosted.org>
Message-ID: <1644426977.26.0.0507292944207.issue46494@roundup.psfhosted.org>


Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:

Welcome to this project, Meer!

That looks pretty good, feel free to submit a PR. We can then perhaps get feedback from more people to improve the wording.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46494>
_______________________________________

From report at bugs.python.org  Wed Feb  9 12:16:46 2022
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 09 Feb 2022 17:16:46 +0000
Subject: [issue46689] `list(FunctionType(a.gi_code, {})(0))` crashes Python
In-Reply-To: <1644406311.26.0.616936444493.issue46689@roundup.psfhosted.org>
Message-ID: <1644427006.32.0.668250627485.issue46689@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

See also https://bugs.python.org/issue36956

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46689>
_______________________________________

From report at bugs.python.org  Wed Feb  9 12:18:08 2022
From: report at bugs.python.org (Bruce Eckel)
Date: Wed, 09 Feb 2022 17:18:08 +0000
Subject: [issue46693] dataclass generated __str__ does not use overridden
 member __str__
Message-ID: <1644427088.92.0.407820887742.issue46693@roundup.psfhosted.org>


New submission from Bruce Eckel <bruceteckel at gmail.com>:

When creating a dataclass using members of other classes that have overridden their __str__ methods, the __str__ method synthesized by the dataclass ignores the overridden __str__ methods in its component members.

Demonstrated in attached file.

----------
components: Interpreter Core
files: DataClassStrBug.py
messages: 412927
nosy: Bruce Eckel
priority: normal
severity: normal
status: open
title: dataclass generated __str__ does not use overridden member __str__
type: behavior
versions: Python 3.10
Added file: https://bugs.python.org/file50611/DataClassStrBug.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46693>
_______________________________________

From report at bugs.python.org  Wed Feb  9 12:20:43 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 09 Feb 2022 17:20:43 +0000
Subject: [issue46693] dataclass generated __str__ does not use overridden
 member __str__
In-Reply-To: <1644427088.92.0.407820887742.issue46693@roundup.psfhosted.org>
Message-ID: <1644427243.02.0.407905135746.issue46693@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I believe dataclasses uses repr() of the members, not str(). Can you try using specifying __repr__ in Teacup? Just __repr__ = __str__ should work.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46693>
_______________________________________

From report at bugs.python.org  Wed Feb  9 12:20:50 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 09 Feb 2022 17:20:50 +0000
Subject: [issue46693] dataclass generated __str__ does not use overridden
 member __str__
In-Reply-To: <1644427088.92.0.407820887742.issue46693@roundup.psfhosted.org>
Message-ID: <1644427250.54.0.14195578001.issue46693@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
assignee:  -> eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46693>
_______________________________________

From report at bugs.python.org  Wed Feb  9 12:26:34 2022
From: report at bugs.python.org (Bruce Eckel)
Date: Wed, 09 Feb 2022 17:26:34 +0000
Subject: [issue46693] dataclass generated __str__ does not use overridden
 member __str__
In-Reply-To: <1644427243.02.0.407905135746.issue46693@roundup.psfhosted.org>
Message-ID: <CAFmL1SAzQxLjSPgxgGUPj_eWhppsG_H+STdGvE=fji0m3x24yw@mail.gmail.com>


Bruce Eckel <bruceteckel at gmail.com> added the comment:

Oops. That does in fact work. How do I remove the bug report?

*Bruce Eckel*
HappyPathProgramming.com
SummerTechForum.com
MindViewLLC.com
Blog: BruceEckel.com
EvolveWork.co
WinterTechForum.com <http://www.WinterTechForum.com>
OnJava8.com <http://www.OnJava8.com>
www.AtomicKotlin.com
Reinventing-Business.com <http://www.Reinventing-Business.com>

On Wed, Feb 9, 2022 at 10:20 AM Eric V. Smith <report at bugs.python.org>
wrote:

>
> Eric V. Smith <eric at trueblade.com> added the comment:
>
> I believe dataclasses uses repr() of the members, not str(). Can you try
> using specifying __repr__ in Teacup? Just __repr__ = __str__ should work.
>
> ----------
> nosy: +eric.smith
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue46693>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46693>
_______________________________________

From report at bugs.python.org  Wed Feb  9 12:31:21 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 09 Feb 2022 17:31:21 +0000
Subject: [issue45863] tarfile zeroes ustar header fields unnecessarily
In-Reply-To: <1637568080.9.0.260845551853.issue45863@roundup.psfhosted.org>
Message-ID: <1644427881.53.0.57164660638.issue45863@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 42f87d435ebe4f2834c8fd0b4ce38f0b1627f3ed by Miss Islington (bot) in branch '3.10':
bpo-45863: tarfile: don't zero out header fields unnecessarily (GH-29693)
https://github.com/python/cpython/commit/42f87d435ebe4f2834c8fd0b4ce38f0b1627f3ed


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45863>
_______________________________________

From report at bugs.python.org  Wed Feb  9 12:36:28 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 09 Feb 2022 17:36:28 +0000
Subject: [issue45863] tarfile zeroes ustar header fields unnecessarily
In-Reply-To: <1637568080.9.0.260845551853.issue45863@roundup.psfhosted.org>
Message-ID: <1644428188.32.0.99239011329.issue45863@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b0517a12179a9fe444ca6ce1f31c307883e81c0c by Miss Islington (bot) in branch '3.9':
bpo-45863: tarfile: don't zero out header fields unnecessarily (GH-29693)
https://github.com/python/cpython/commit/b0517a12179a9fe444ca6ce1f31c307883e81c0c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45863>
_______________________________________

From report at bugs.python.org  Wed Feb  9 12:37:25 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Feb 2022 17:37:25 +0000
Subject: [issue45863] tarfile zeroes ustar header fields unnecessarily
In-Reply-To: <1637568080.9.0.260845551853.issue45863@roundup.psfhosted.org>
Message-ID: <1644428245.05.0.756267981525.issue45863@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thanks Joshua Root for the bug report and the fix!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45863>
_______________________________________

From report at bugs.python.org  Wed Feb  9 12:49:23 2022
From: report at bugs.python.org (=?utf-8?q?Filipe_La=C3=ADns?=)
Date: Wed, 09 Feb 2022 17:49:23 +0000
Subject: [issue45413] Add install scheme for virtual environments
In-Reply-To: <1633715402.49.0.434363843275.issue45413@roundup.psfhosted.org>
Message-ID: <1644428963.68.0.103999736976.issue45413@roundup.psfhosted.org>


Filipe La?ns <lains at riseup.net> added the comment:

I don't think the proposal is incompatible with what I discussed.

I haven't been super clear on my opinions on the implementation, so let me try to clarify them.

- I think that we should use a static scheme, accessible on all platforms.
- If this scheme needs to be independently defined for each platform, we should have different variants, available on all platforms, but still keep a generic named one, as an alias to the platform specific scheme
- We should not be re-using/aliasing existing schemes, particularly ones that are prone to downstream patching

So, my proposal would be to define a single static scheme, and changing the interpreter path initialization logic to hardcode its paths when on virtual environments.
If this presents any issue, and requires the scheme to be different for different platforms, we should add platform specific schemes and make the main one an alias to the correct scheme.

Hopefully that clarifies things up a bit. We should sort it out as soon as possible and update the PR, I don't think the PR as-is is the best approach.

What do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45413>
_______________________________________

From report at bugs.python.org  Wed Feb  9 12:55:00 2022
From: report at bugs.python.org (Nonsense)
Date: Wed, 09 Feb 2022 17:55:00 +0000
Subject: [issue46694] isdigit/isnumeric vs int()
Message-ID: <1644429300.87.0.85125786773.issue46694@roundup.psfhosted.org>


New submission from Nonsense <smtplukas.tanner.test at gmail.com>:

When typing in "?".isdigit() or "?".isnumeric() it gives True
but when typing in int("?") it errors out:
ValueError: invalid literal for int() with base 10: '?'

----------
components: Interpreter Core
messages: 412934
nosy: smtplukas.tanner.test
priority: normal
severity: normal
status: open
title: isdigit/isnumeric vs int()
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46694>
_______________________________________

From report at bugs.python.org  Wed Feb  9 13:00:50 2022
From: report at bugs.python.org (mirabilos)
Date: Wed, 09 Feb 2022 18:00:50 +0000
Subject: [issue46695] _io_TextIOWrapper_reconfigure_impl errors out too early
Message-ID: <1644429650.43.0.90241756772.issue46695@roundup.psfhosted.org>


New submission from mirabilos <tg at debian.org>:

The following is not possible:

with open('/tmp/x.ssv', 'r', newline='\n') as f:
    f.readline()
    # imagine a library call boundary here
    if hasattr(f, 'reconfigure'):
        f.reconfigure(newline='\n')

The .reconfigure() call would not do anything, but it errors out nevertheless, simply because it is called (from reading the _io_TextIOWrapper_reconfigure_impl code in Modules/_io/textio.c).

Unfortunately, I *have* to call this in my library because I have to rely on ?newline='\n'? behaviour (the hasattr avoids erroring out on binary streams), and the normal behaviour of erroring out if it?s too late to change is also good for me.

But the behaviour of erroring out if called at all when anything has already been read is a problem. This can easily be solved without breaking backwards compatibility, as the operation is a nop.

To clarify: I wish for?

with open('/tmp/x.ssv', 'r', newline='\n') as f:
    f.readline()
    # imagine a library call boundary here
    if hasattr(f, 'reconfigure'):
        f.reconfigure(newline='\n')

? to work, but for?

with open('/tmp/x.ssv', 'r') as f:
    f.readline()
    # imagine a library call boundary here
    if hasattr(f, 'reconfigure'):
        f.reconfigure(newline='\n')

? (line 1 is the only changed one) to continue to error out.

----------
components: IO
messages: 412935
nosy: mirabilos
priority: normal
severity: normal
status: open
title: _io_TextIOWrapper_reconfigure_impl errors out too early
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46695>
_______________________________________

From report at bugs.python.org  Wed Feb  9 13:10:20 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 09 Feb 2022 18:10:20 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644430220.83.0.581743782776.issue46323@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:


New changeset d18120cd67b4297f78bfc9bf7b36774cf0bf15f2 by Dong-hee Na in branch 'main':
bpo-46323: Reduce stack usage of ctypes python callback function. (GH-31224)
https://github.com/python/cpython/commit/d18120cd67b4297f78bfc9bf7b36774cf0bf15f2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Wed Feb  9 13:17:34 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 09 Feb 2022 18:17:34 +0000
Subject: [issue46430] intern strings in deepfrozen modules
In-Reply-To: <1642590983.92.0.896257318647.issue46430@roundup.psfhosted.org>
Message-ID: <1644430654.62.0.228433791444.issue46430@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

We discussed that and found that a lot of errors are ignored during interning anyway.

But it's not too late to change if you want to (sending a PR would probably be quicker than arguing :-).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46430>
_______________________________________

From report at bugs.python.org  Wed Feb  9 13:26:00 2022
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 09 Feb 2022 18:26:00 +0000
Subject: [issue46072] Unify handling of stats in the CPython VM
In-Reply-To: <1639498673.65.0.709719181358.issue46072@roundup.psfhosted.org>
Message-ID: <1644431160.34.0.281506863385.issue46072@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
pull_requests: +29404
pull_request: https://github.com/python/cpython/pull/31234

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46072>
_______________________________________

From report at bugs.python.org  Wed Feb  9 13:38:03 2022
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 09 Feb 2022 18:38:03 +0000
Subject: [issue46694] isdigit/isnumeric vs int()
In-Reply-To: <1644429300.87.0.85125786773.issue46694@roundup.psfhosted.org>
Message-ID: <1644431883.77.0.739001620373.issue46694@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This is by design: int looks for characters with the Unicode Decimal (De) numeric type, corresponding to str.isdecimal(), rather than for the Digit (Di) or Numeric (Nu) numeric types.

>>> "?".isdecimal()
False

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46694>
_______________________________________

From report at bugs.python.org  Wed Feb  9 13:51:41 2022
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 09 Feb 2022 18:51:41 +0000
Subject: [issue46694] isdigit/isnumeric vs int()
In-Reply-To: <1644429300.87.0.85125786773.issue46694@roundup.psfhosted.org>
Message-ID: <1644432701.22.0.0558319134088.issue46694@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46694>
_______________________________________

From report at bugs.python.org  Wed Feb  9 14:31:15 2022
From: report at bugs.python.org (Brandt Bucher)
Date: Wed, 09 Feb 2022 19:31:15 +0000
Subject: [issue46528] Simplify the VM's stack manipulations
In-Reply-To: <1643161199.78.0.253250267538.issue46528@roundup.psfhosted.org>
Message-ID: <1644435075.83.0.990762533718.issue46528@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:


New changeset 46328d8ae6529db916ccaabb9247fb0327ce0c1e by Brandt Bucher in branch 'main':
bpo-46528: Check PyMem_Malloc for NULL (GH-30998)
https://github.com/python/cpython/commit/46328d8ae6529db916ccaabb9247fb0327ce0c1e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46528>
_______________________________________

From report at bugs.python.org  Wed Feb  9 15:00:00 2022
From: report at bugs.python.org (Henry Schreiner)
Date: Wed, 09 Feb 2022 20:00:00 +0000
Subject: [issue43532] Add keyword-only fields to dataclasses
In-Reply-To: <1616002761.92.0.652624260802.issue43532@roundup.psfhosted.org>
Message-ID: <1644436800.86.0.583952543309.issue43532@roundup.psfhosted.org>


Change by Henry Schreiner <henryschreineriii at gmail.com>:


----------
nosy: +Henry Schreiner
nosy_count: 9.0 -> 10.0
pull_requests: +29405
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31235

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43532>
_______________________________________

From report at bugs.python.org  Wed Feb  9 15:17:07 2022
From: report at bugs.python.org (hydroflask)
Date: Wed, 09 Feb 2022 20:17:07 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644437827.87.0.613074477532.issue46323@roundup.psfhosted.org>


hydroflask <hydroflask at yqxmail.com> added the comment:

@corona10

I really hope I am not being annoying at this point :) One final nit, in this line:

https://github.com/python/cpython/pull/31224/files#diff-706e65ee28911740bf638707e19578b8182e57c6a8a9a4a91105d825f95a139dR168

You do not have to check if nargs > 0. alloca() can handle the case when nargs == 0. The usage of alloca() in callproc.c does not check for nargs > 0 either.

Otherwise thanks for this enhancement!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Wed Feb  9 15:23:45 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Feb 2022 20:23:45 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644438225.98.0.625485159596.issue46323@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I failed to find the doc about alloca(0). It seems like the existing _ctypes_callproc() function *can* call alloca(0) if argtuple is empty and pIunk is 0 (pIunk is specific to Windows).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Wed Feb  9 15:31:20 2022
From: report at bugs.python.org (hydroflask)
Date: Wed, 09 Feb 2022 20:31:20 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644438680.84.0.303927632555.issue46323@roundup.psfhosted.org>


hydroflask <hydroflask at yqxmail.com> added the comment:

For reference, here are MSDN, Linux, OpenBSD, and GCC docs on alloca:

https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/alloca?view=msvc-170

https://www.man7.org/linux/man-pages/man3/alloca.3.html

https://man.openbsd.org/alloca.3

https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-_002a_005f_005fbuiltin_005falloca

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Wed Feb  9 15:56:17 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 09 Feb 2022 20:56:17 +0000
Subject: [issue43532] Add keyword-only fields to dataclasses
In-Reply-To: <1616002761.92.0.652624260802.issue43532@roundup.psfhosted.org>
Message-ID: <1644440177.98.0.338377749829.issue43532@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 5a3f97291eea96037cceee097ebc00bba44bc9ed by Henry Schreiner in branch 'main':
bpo-43532: add version added to KW_ONLY (GH-31235)
https://github.com/python/cpython/commit/5a3f97291eea96037cceee097ebc00bba44bc9ed


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43532>
_______________________________________

From report at bugs.python.org  Wed Feb  9 15:56:22 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 09 Feb 2022 20:56:22 +0000
Subject: [issue43532] Add keyword-only fields to dataclasses
In-Reply-To: <1616002761.92.0.652624260802.issue43532@roundup.psfhosted.org>
Message-ID: <1644440182.18.0.866754604536.issue43532@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29406
pull_request: https://github.com/python/cpython/pull/31236

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43532>
_______________________________________

From report at bugs.python.org  Wed Feb  9 16:19:01 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 09 Feb 2022 21:19:01 +0000
Subject: [issue43532] Add keyword-only fields to dataclasses
In-Reply-To: <1616002761.92.0.652624260802.issue43532@roundup.psfhosted.org>
Message-ID: <1644441541.45.0.624769889253.issue43532@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 7445949a4399ab19fbdd5a0b0aca53a690c3251b by Miss Islington (bot) in branch '3.10':
bpo-43532: add version added to KW_ONLY (GH-31235)
https://github.com/python/cpython/commit/7445949a4399ab19fbdd5a0b0aca53a690c3251b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43532>
_______________________________________

From report at bugs.python.org  Wed Feb  9 16:37:28 2022
From: report at bugs.python.org (David CARLIER)
Date: Wed, 09 Feb 2022 21:37:28 +0000
Subject: [issue46696] socketmodule add Linux SO_INCOMING_CPU constasn
Message-ID: <1644442648.93.0.9885945576.issue46696@roundup.psfhosted.org>


Change by David CARLIER <devnexen at gmail.com>:


----------
nosy: devnexen
priority: normal
severity: normal
status: open
title: socketmodule add Linux SO_INCOMING_CPU constasn

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46696>
_______________________________________

From report at bugs.python.org  Wed Feb  9 16:38:42 2022
From: report at bugs.python.org (David CARLIER)
Date: Wed, 09 Feb 2022 21:38:42 +0000
Subject: [issue46696] socketmodule add Linux SO_INCOMING_CPU constant
Message-ID: <1644442722.76.0.524140706411.issue46696@roundup.psfhosted.org>


New submission from David CARLIER <devnexen at gmail.com>:

Adding Linux's SO_INCOMING_CPU constant for setsockopt.

----------
components: +Library (Lib)
keywords: +patch
message_count: None -> 1.0
pull_requests: +29407
stage:  -> patch review
title: socketmodule add Linux SO_INCOMING_CPU constasn -> socketmodule add Linux SO_INCOMING_CPU constant
type:  -> enhancement
pull_request: https://github.com/python/cpython/pull/31237

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46696>
_______________________________________

From report at bugs.python.org  Wed Feb  9 16:49:39 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 09 Feb 2022 21:49:39 +0000
Subject: [issue43532] Add keyword-only fields to dataclasses
In-Reply-To: <1616002761.92.0.652624260802.issue43532@roundup.psfhosted.org>
Message-ID: <1644443379.67.0.842241953255.issue43532@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Thanks, Henry Schreiner!

----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43532>
_______________________________________

From report at bugs.python.org  Wed Feb  9 17:05:40 2022
From: report at bugs.python.org (hydroflask)
Date: Wed, 09 Feb 2022 22:05:40 +0000
Subject: [issue46697] _ctypes_simple_instance returns inverted logic
Message-ID: <1644444340.15.0.469712253239.issue46697@roundup.psfhosted.org>


New submission from hydroflask <hydroflask at yqxmail.com>:

`_ctypes_simple_instance` in _ctypes.c returns the opposite logic of what its documentation claims. It is supposed to return true when the argument (a type object) is a direct subclass of `Simple_Type` (`_SimpleCData` in Python code). However it returns false instead.

No bugs have manifested from this because all of the call sites ( `callproc.c::GetResult`, `callbacks.c::_CallPythonObject`,_`ctypes.c::PyCData_get`, `_ctypes.c::Simple_from_outparm`) invert the return value of this function. The last example, `ctypes.c::Simple_from_outparm` only calls `Simple_get_value()` when `_ctypes_simple_instance` returns false, which makes sense because otherwise the invocation of `_ctypes.c::Simple_from_outparm()` could trigger an assertion error.

This is not just simply an issue of inverted logic because the logic isn't inverted in all cases. In `_ctypes_simple_instance` in the case when `PyCSimpleTypeObject_Check(type)` returns false, if this were supposed to be perfect inverted logic then the whole routine would return 1 (True) not 0. Fortunately, due to the way the code is structured, I don't think there is a case when `PyCSimpleTypeObject_Check(type)` returns false so the incorrect case where it returns a constant 0 is effectively dead code.

I have compiled a version of Python with the attached patch and run "make test" with no issues.

----------
components: ctypes
files: _ctypes_simple_instance_inverted.patch
keywords: patch
messages: 412947
nosy: hydroflask
priority: normal
severity: normal
status: open
title: _ctypes_simple_instance returns inverted logic
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file50612/_ctypes_simple_instance_inverted.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46697>
_______________________________________

From report at bugs.python.org  Wed Feb  9 17:13:20 2022
From: report at bugs.python.org (hydroflask)
Date: Wed, 09 Feb 2022 22:13:20 +0000
Subject: [issue46697] _ctypes_simple_instance returns inverted logic
In-Reply-To: <1644444340.15.0.469712253239.issue46697@roundup.psfhosted.org>
Message-ID: <1644444800.03.0.990254860436.issue46697@roundup.psfhosted.org>


hydroflask <hydroflask at yqxmail.com> added the comment:

I place that patch into the public domain, I claim no ownership over that patch. The patch is attached purely for demonstration purposes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46697>
_______________________________________

From report at bugs.python.org  Wed Feb  9 17:15:04 2022
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 09 Feb 2022 22:15:04 +0000
Subject: [issue46697] _ctypes_simple_instance returns inverted logic
In-Reply-To: <1644444340.15.0.469712253239.issue46697@roundup.psfhosted.org>
Message-ID: <1644444904.38.0.448935905722.issue46697@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
stage:  -> patch review
versions:  -Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46697>
_______________________________________

From report at bugs.python.org  Wed Feb  9 17:24:29 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 09 Feb 2022 22:24:29 +0000
Subject: [issue46693] dataclass generated __str__ does not use overridden
 member __str__
In-Reply-To: <1644427088.92.0.407820887742.issue46693@roundup.psfhosted.org>
Message-ID: <1644445468.99.0.0907253518452.issue46693@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I'll close it.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46693>
_______________________________________

From report at bugs.python.org  Wed Feb  9 17:29:19 2022
From: report at bugs.python.org (mirabilos)
Date: Wed, 09 Feb 2022 22:29:19 +0000
Subject: [issue46700] wrong nomenclature (options vs. arguments) in argparse
Message-ID: <1644445759.27.0.125748612313.issue46700@roundup.psfhosted.org>


New submission from mirabilos <tg at debian.org>:

The argparse documentation and tutorial as well as its default option groups speak of "positional arguments" and "optional arguments". These are not used correctly, though.

Elements of the argument vector (past item #0) are distinguished as options and (positional) arguments.

Options are either flags (ls "-l", cmd "/c") or GNU long options ("--help"). They are usually optional ("[-h]") but may be mandatory (such as -o/-i/-p for cpio(1)). They may have option arguments (cpio(1) "-H format").

Arguments (also called positional arguments) may be mandatory ("file") or optional ("[file]"). They are also called operands (mostly in POSIX, not very common).

The argparse documentation confused the hell out of me at first because I only saw argument documentation and could not find option documentation?

----------
components: Library (Lib)
messages: 412952
nosy: mirabilos
priority: normal
severity: normal
status: open
title: wrong nomenclature (options vs. arguments) in argparse
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46700>
_______________________________________

From report at bugs.python.org  Wed Feb  9 17:31:16 2022
From: report at bugs.python.org (mirabilos)
Date: Wed, 09 Feb 2022 22:31:16 +0000
Subject: [issue46701] cannot use typographical quotation marks in bug
 description
Message-ID: <1644445876.51.0.942967500006.issue46701@roundup.psfhosted.org>


New submission from mirabilos <tg at debian.org>:

When trying to use typographical quotation marks (U+201C, U+201D) in the Comment field trying to submit a bug here, I get a red-background error message saying:

Error: 'utf8' codec can't decode bytes in position 198-199: invalid continuation byte

----------
messages: 412953
nosy: mirabilos
priority: normal
severity: normal
status: open
title: cannot use typographical quotation marks in bug description

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46701>
_______________________________________

From report at bugs.python.org  Wed Feb  9 17:38:01 2022
From: report at bugs.python.org (Gregory Beauregard)
Date: Wed, 09 Feb 2022 22:38:01 +0000
Subject: [issue46643] typing.Annotated cannot wrap typing.ParamSpec args/kwargs
In-Reply-To: <1644013165.99.0.0164231326825.issue46643@roundup.psfhosted.org>
Message-ID: <1644446281.68.0.828653604183.issue46643@roundup.psfhosted.org>


Change by Gregory Beauregard <greg at greg.red>:


----------
keywords: +patch
pull_requests: +29408
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31238

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46643>
_______________________________________

From report at bugs.python.org  Wed Feb  9 18:15:52 2022
From: report at bugs.python.org (Brandt Bucher)
Date: Wed, 09 Feb 2022 23:15:52 +0000
Subject: [issue46528] Simplify the VM's stack manipulations
In-Reply-To: <1643161199.78.0.253250267538.issue46528@roundup.psfhosted.org>
Message-ID: <1644448552.88.0.187204599997.issue46528@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:


New changeset 78ae4cc6dc949e8bc39fab25fea5efe983dc0ad1 by Brandt Bucher in branch 'main':
bpo-46528: Attempt SWAPs at compile-time (GH-30970)
https://github.com/python/cpython/commit/78ae4cc6dc949e8bc39fab25fea5efe983dc0ad1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46528>
_______________________________________

From report at bugs.python.org  Wed Feb  9 18:16:39 2022
From: report at bugs.python.org (Brandt Bucher)
Date: Wed, 09 Feb 2022 23:16:39 +0000
Subject: [issue46528] Simplify the VM's stack manipulations
In-Reply-To: <1643161199.78.0.253250267538.issue46528@roundup.psfhosted.org>
Message-ID: <1644448599.09.0.967793227002.issue46528@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/issue46528>
_______________________________________

From report at bugs.python.org  Wed Feb  9 18:26:00 2022
From: report at bugs.python.org (Eric Snow)
Date: Wed, 09 Feb 2022 23:26:00 +0000
Subject: [issue36876] [subinterpreters] Global C variables are a problem
In-Reply-To: <1557514902.13.0.853517754348.issue36876@roundup.psfhosted.org>
Message-ID: <1644449160.19.0.683611329277.issue36876@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
pull_requests: +29409
pull_request: https://github.com/python/cpython/pull/31239

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36876>
_______________________________________

From report at bugs.python.org  Wed Feb  9 18:28:02 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 09 Feb 2022 23:28:02 +0000
Subject: [issue46701] cannot use typographical quotation marks in bug
 description
In-Reply-To: <1644445876.51.0.942967500006.issue46701@roundup.psfhosted.org>
Message-ID: <1644449282.55.0.768403476915.issue46701@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Please report bug tracker bugs at https://github.com/python/bugs.python.org

Although to be honest I doubt this will be fixed, since we're moving to Github issues.

----------
nosy: +eric.smith
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46701>
_______________________________________

From report at bugs.python.org  Wed Feb  9 19:03:34 2022
From: report at bugs.python.org (Eric Snow)
Date: Thu, 10 Feb 2022 00:03:34 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting and
 immortal objects
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1644451414.86.0.765103904502.issue40255@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

@Eddie, what can I do to push this forward?  FYI, in addition to the python-dev thread a few weeks back, I've brought the matter up with the steering council. [1]

Also, if we can get back to performance-neutral (currently at about 4% slower) then there would be a lot less controversy.  Even at 2% it may be enough.


[1] https://github.com/python/steering-council/issues/103

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Wed Feb  9 19:11:02 2022
From: report at bugs.python.org (Eric Snow)
Date: Thu, 10 Feb 2022 00:11:02 +0000
Subject: [issue36876] [subinterpreters] Global C variables are a problem
In-Reply-To: <1557514902.13.0.853517754348.issue36876@roundup.psfhosted.org>
Message-ID: <1644451862.14.0.450381089218.issue36876@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:


New changeset cb68788dcadf43b47292bab7816a5ed9efa69730 by Eric Snow in branch 'main':
bpo-36876: Minor cleanup to c-analyzer "ignored" data.' (gh-31239)
https://github.com/python/cpython/commit/cb68788dcadf43b47292bab7816a5ed9efa69730


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36876>
_______________________________________

From report at bugs.python.org  Wed Feb  9 19:15:54 2022
From: report at bugs.python.org (Ned Deily)
Date: Thu, 10 Feb 2022 00:15:54 +0000
Subject: [issue46691] sysconfig.get_platform() raises ValueError on macOS if
 '-arch' is present in CFLAGS but doesn't refer to the '-arch' compiler flag
In-Reply-To: <1644409009.26.0.313805274681.issue46691@roundup.psfhosted.org>
Message-ID: <1644452154.43.0.018677485424.issue46691@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Thanks for the report; I don't recall this coming up before. Of course, the easy workaround is to avoid using "arch" in CFLAGS paths and the like, but we should fix this.

----------
components: +macOS
nosy: +ned.deily, ronaldoussoren
type: crash -> compile error
versions: +Python 3.11, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46691>
_______________________________________

From report at bugs.python.org  Wed Feb  9 19:19:22 2022
From: report at bugs.python.org (Ned Deily)
Date: Thu, 10 Feb 2022 00:19:22 +0000
Subject: [issue46691] sysconfig.get_platform() raises ValueError on macOS if
 '-arch' is present in CFLAGS but doesn't refer to the '-arch' compiler flag
In-Reply-To: <1644409009.26.0.313805274681.issue46691@roundup.psfhosted.org>
Message-ID: <1644452362.4.0.0371742366028.issue46691@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Thanks for the report; I don't recall this coming up before. Of course, the easy workaround is to avoid using "-arch" in CFLAGS paths and the like, but we should fix this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46691>
_______________________________________

From report at bugs.python.org  Wed Feb  9 19:19:34 2022
From: report at bugs.python.org (Ned Deily)
Date: Thu, 10 Feb 2022 00:19:34 +0000
Subject: [issue46691] sysconfig.get_platform() raises ValueError on macOS if
 '-arch' is present in CFLAGS but doesn't refer to the '-arch' compiler flag
In-Reply-To: <1644409009.26.0.313805274681.issue46691@roundup.psfhosted.org>
Message-ID: <1644452374.97.0.997147385125.issue46691@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
Removed message: https://bugs.python.org/msg412958

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46691>
_______________________________________

From report at bugs.python.org  Wed Feb  9 19:35:53 2022
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 10 Feb 2022 00:35:53 +0000
Subject: [issue46702] Specialize UNPACK_SEQUENCE
Message-ID: <1644453353.53.0.226399964433.issue46702@roundup.psfhosted.org>


New submission from Brandt Bucher <brandtbucher at gmail.com>:

UNPACK_SEQUENCE already has fast paths for tuples and lists, which make up (literally) 99% of unpackings in the benchmark suite. What's more, two-element tuples make up about two-thirds of all unpackings (though I actually suspect it's even higher, since the unpack_sequence benchmark is definitely skewing the results towards 10-element lists and tuples).

These specializations are trivial to implement and result in a solid 1% improvement overall.

----------
assignee: brandtbucher
components: Interpreter Core
messages: 412960
nosy: Mark.Shannon, brandtbucher
priority: normal
severity: normal
stage: patch review
status: open
title: Specialize UNPACK_SEQUENCE
type: performance
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46702>
_______________________________________

From report at bugs.python.org  Wed Feb  9 19:41:16 2022
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 10 Feb 2022 00:41:16 +0000
Subject: [issue46702] Specialize UNPACK_SEQUENCE
In-Reply-To: <1644453353.53.0.226399964433.issue46702@roundup.psfhosted.org>
Message-ID: <1644453676.62.0.478140616936.issue46702@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
keywords: +patch
pull_requests: +29410
pull_request: https://github.com/python/cpython/pull/31240

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46702>
_______________________________________

From report at bugs.python.org  Wed Feb  9 19:55:12 2022
From: report at bugs.python.org (jung mo sohn)
Date: Thu, 10 Feb 2022 00:55:12 +0000
Subject: [issue46703] boolean operation issue (True == False == False)
Message-ID: <1644454512.3.0.572499319459.issue46703@roundup.psfhosted.org>


New submission from jung mo sohn <jmsohn.x at gmail.com>:

In python 3.6.8, 3.7.3, 3.7.4, 3.7.5, 3.7.12, 3.8.8 versions, the output is False as shown below.

Python 3.7.5 (tags/v3.7.5:5c02a39a0b, Oct 15 2019, 00:11:34) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> print(True == False == False)
False

However, in the openjdk1.8 version, the output is "true" as shown below. 

public class Test {
	public static void main(String[] args) throws Exception{
		System.out.println(true == false == false);
	}
}

> java Test
true

In my opinion, "True" seems to be correct.

----------
components: Parser
messages: 412961
nosy: jmsohn.x, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: boolean operation issue (True == False == False)
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46703>
_______________________________________

From report at bugs.python.org  Wed Feb  9 20:00:03 2022
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 10 Feb 2022 01:00:03 +0000
Subject: [issue46702] Specialize UNPACK_SEQUENCE
In-Reply-To: <1644453353.53.0.226399964433.issue46702@roundup.psfhosted.org>
Message-ID: <1644454803.24.0.831260008932.issue46702@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

(I also plan on looking into an adaptive super-duper-instruction for UNPACK_SEQUENCE_TWO_TUPLE__STORE_FAST__STORE_FAST after the current PR has landed).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46702>
_______________________________________

From report at bugs.python.org  Wed Feb  9 20:08:20 2022
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 10 Feb 2022 01:08:20 +0000
Subject: [issue46703] boolean operation issue (True == False == False)
In-Reply-To: <1644454512.3.0.572499319459.issue46703@roundup.psfhosted.org>
Message-ID: <1644455300.86.0.730653680327.issue46703@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

This is not a bug. Please check the docs on the ternary operator:

https://docs.python.org/3/reference/expressions.html#comparisons

In particular:

Comparisons can be chained arbitrarily, e.g., x < y <= z is equivalent to x < y and y <= z, except that y is evaluated only once (but in both cases z is not evaluated at all when x < y is found to be false).



THis means that

True == False == False is really True == False and True == False wich is False and False which is False

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46703>
_______________________________________

From report at bugs.python.org  Wed Feb  9 20:08:46 2022
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 10 Feb 2022 01:08:46 +0000
Subject: [issue46703] boolean operation issue (True == False == False)
In-Reply-To: <1644454512.3.0.572499319459.issue46703@roundup.psfhosted.org>
Message-ID: <1644455326.82.0.895611594469.issue46703@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
Removed message: https://bugs.python.org/msg412963

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46703>
_______________________________________

From report at bugs.python.org  Wed Feb  9 20:09:08 2022
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 10 Feb 2022 01:09:08 +0000
Subject: [issue46703] boolean operation issue (True == False == False)
In-Reply-To: <1644454512.3.0.572499319459.issue46703@roundup.psfhosted.org>
Message-ID: <1644455348.78.0.804763446464.issue46703@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

This is not a bug. Please check the docs on the ternary operator:

https://docs.python.org/3/reference/expressions.html#comparisons

In particular:

Comparisons can be chained arbitrarily, e.g., x < y <= z is equivalent to x < y and y <= z, except that y is evaluated only once (but in both cases z is not evaluated at all when x < y is found to be false).



THis means that

True == False == False is really True == False and False == False wich is False and True which is False

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46703>
_______________________________________

From report at bugs.python.org  Wed Feb  9 20:23:04 2022
From: report at bugs.python.org (anthony shaw)
Date: Thu, 10 Feb 2022 01:23:04 +0000
Subject: [issue46704] Parser API not checking for null-terminator
Message-ID: <1644456184.13.0.709670971668.issue46704@roundup.psfhosted.org>


New submission from anthony shaw <anthonyshaw at apache.org>:

In tokenizer.c, the translate_newlines() function does a `strlen()` on the input string, if the string is not null-terminated, e.g. 
'\xbe' this leads to a heap-buffer-overflow. The overflow is not exploitable, but if there are further changes to the parser, it might be worth using a strlen() alternative, like strnlen().

static char *
translate_newlines(const char *s, int exec_input, struct tok_state *tok) {
    int skip_next_lf = 0;
    size_t needed_length = strlen(s) + 2, final_length;


This leads to a heap-buffer-overflow detected by ASAN in a simple reproducible example, calling PyRun_StringFlags() from the LLVM fuzzer:


fuzz_target(47084,0x11356f600) malloc: nano zone abandoned due to inability to preallocate reserved vm space.
Dictionary: 35 entries
INFO: Running with entropic power schedule (0xFF, 100).
INFO: Seed: 3034498392
INFO: Loaded 1 modules   (43 inline 8-bit counters): 43 [0x10a2b71e8, 0x10a2b7213), 
INFO: Loaded 1 PC tables (43 PCs): 43 [0x10a2b7218,0x10a2b74c8), 
INFO:        1 files found in ../Tests/fuzzing/corpus
INFO: -max_len is not provided; libFuzzer will not generate inputs larger than 4096 bytes
=================================================================
==47084==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000003131 at pc 0x00010bd1d555 bp 0x7ff7b5da0590 sp 0x7ff7b5d9fd50
READ of size 2 at 0x602000003131 thread T0
    #0 0x10bd1d554 in wrap_strlen+0x184 (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x15554)
    #1 0x10b12132b in translate_newlines+0x1b (Python:x86_64+0x5d32b)
    #2 0x10b12071c in _PyParser_ASTFromString+0x1ac (Python:x86_64+0x5c71c)
    #3 0x10b2f86de in PyRun_StringFlags+0x5e (Python:x86_64+0x2346de)
    #4 0x10a25ec6b in CompileCode(char const*) fuzz_target.cpp:54
    #5 0x10a25f247 in LLVMFuzzerTestOneInput fuzz_target.cpp:68
    #6 0x10a27aff3 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) FuzzerLoop.cpp:611
    #7 0x10a27c3c4 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__1::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) FuzzerLoop.cpp:804
    #8 0x10a27c859 in fuzzer::Fuzzer::Loop(std::__1::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) FuzzerLoop.cpp:857
    #9 0x10a26aa5f in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) FuzzerDriver.cpp:906
    #10 0x10a298e42 in main FuzzerMain.cpp:20
    #11 0x1134f44fd in start+0x1cd (dyld:x86_64+0x54fd)

0x602000003131 is located 0 bytes to the right of 1-byte region [0x602000003130,0x602000003131)
allocated by thread T0 here:
    #0 0x10bd58a0d in wrap__Znam+0x7d (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x50a0d)
    #1 0x10a27af02 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) FuzzerLoop.cpp:596
    #2 0x10a27c3c4 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__1::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) FuzzerLoop.cpp:804
    #3 0x10a27c859 in fuzzer::Fuzzer::Loop(std::__1::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) FuzzerLoop.cpp:857
    #4 0x10a26aa5f in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) FuzzerDriver.cpp:906
    #5 0x10a298e42 in main FuzzerMain.cpp:20
    #6 0x1134f44fd in start+0x1cd (dyld:x86_64+0x54fd)

SUMMARY: AddressSanitizer: heap-buffer-overflow (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x15554) in wrap_strlen+0x184
Shadow bytes around the buggy address:
  0x1c04000005d0: fa fa 02 fa fa fa 02 fa fa fa 02 fa fa fa 02 fa
  0x1c04000005e0: fa fa 02 fa fa fa 02 fa fa fa 02 fa fa fa 02 fa
  0x1c04000005f0: fa fa 03 fa fa fa 03 fa fa fa 03 fa fa fa 03 fa
  0x1c0400000600: fa fa 01 fa fa fa 01 fa fa fa 01 fa fa fa 01 fa
  0x1c0400000610: fa fa 00 00 fa fa 00 fa fa fa 00 fa fa fa 00 00
=>0x1c0400000620: fa fa 00 fa fa fa[01]fa fa fa fd fa fa fa fd fd
  0x1c0400000630: fa fa fd fa fa fa fd fa fa fa 00 fa fa fa 04 fa
  0x1c0400000640: fa fa 00 00 fa fa 01 fa fa fa 01 fa fa fa 01 fa
  0x1c0400000650: fa fa fd fa fa fa fd fa fa fa fd fd fa fa 01 fa
  0x1c0400000660: fa fa 00 00 fa fa 01 fa fa fa fd fa fa fa fd fa
  0x1c0400000670: fa fa 01 fa fa fa 06 fa fa fa 00 00 fa fa 06 fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==47084==ABORTING
MS: 0 ; base unit: 0000000000000000000000000000000000000000


artifact_prefix='./'; Test unit written to ./crash-da39a3ee5e6b4b0d3255bfef95601890afd80709
Base64: 
zsh: abort      ./fuzz_target -dict=../Tests/fuzzing/python.dict -only_ascii=1

----------
components: Parser
messages: 412965
nosy: anthonypjshaw, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Parser API not checking for null-terminator
versions: Python 3.10, Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46704>
_______________________________________

From report at bugs.python.org  Wed Feb  9 20:24:46 2022
From: report at bugs.python.org (Jack Nguyen)
Date: Thu, 10 Feb 2022 01:24:46 +0000
Subject: [issue46705] Memory optimization for set.issubset
Message-ID: <1644456286.75.0.570469463639.issue46705@roundup.psfhosted.org>


New submission from Jack Nguyen <jackyeenguyen at gmail.com>:

I noticed that the set.issubset cpython implementation casts its iterable argument to a set. In some cases, casting the whole iterable to a set is unnecessary (see https://bugs.python.org/issue18032). Although the latter suggestion is to perform early termination, my suggestion is to use the intersection instead.

    # PyAnySet_Check coming from the cpython source code.
    def issubset(self, other):
        # Intersection suggestion:
        if not PyAnySet_Check(other):
            return len(self.intersection(other)) == len(self)
        # Usual implementation for sets.
        else:
            return ...

The main advantage that this implementation has is its memory performance, using only O(min(len(self), len(other))) memory, since it never stores elements it does not need.

I'm assuming that set construction costs O(n) set.__contains__ calls. This implementation uses len(other) calls to self.__contains__ and tmp.__contains__, where tmp = set(other). The current implementation uses len(self) + len(other) calls to tmp.__contains__.

Thus, I suspect the current implementation only has a chance at running noticeably faster when len(self) << len(other), where it performs fewer calls to set.__contains__. This is, however, also where the proposed implementation has significantly superior memory performance.

----------
components: Interpreter Core
messages: 412966
nosy: panda1200
priority: normal
severity: normal
status: open
title: Memory optimization for set.issubset
type: performance
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46705>
_______________________________________

From report at bugs.python.org  Wed Feb  9 20:30:50 2022
From: report at bugs.python.org (claude-alexandre cabana)
Date: Thu, 10 Feb 2022 01:30:50 +0000
Subject: [issue46706] AxelRacer
Message-ID: <1644456650.45.0.239619008803.issue46706@roundup.psfhosted.org>


Change by claude-alexandre cabana <claudealexcabana at gmail.com>:


----------
components: Build
nosy: claudealexcabana
priority: normal
severity: normal
status: open
title: AxelRacer
type: performance
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46706>
_______________________________________

From report at bugs.python.org  Wed Feb  9 20:33:49 2022
From: report at bugs.python.org (Dennis Sweeney)
Date: Thu, 10 Feb 2022 01:33:49 +0000
Subject: [issue46705] Memory optimization for set.issubset
In-Reply-To: <1644456286.75.0.570469463639.issue46705@roundup.psfhosted.org>
Message-ID: <1644456829.66.0.231673484346.issue46705@roundup.psfhosted.org>


Change by Dennis Sweeney <sweeney.dennis650 at gmail.com>:


----------
nosy: +rhettinger, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46705>
_______________________________________

From report at bugs.python.org  Wed Feb  9 20:38:37 2022
From: report at bugs.python.org (Dennis Sweeney)
Date: Thu, 10 Feb 2022 01:38:37 +0000
Subject: [issue46706] AxelRacer
Message-ID: <1644457117.36.0.32985338107.issue46706@roundup.psfhosted.org>


New submission from Dennis Sweeney <sweeney.dennis650 at gmail.com>:

I'm closing this -- if you found a bug in Python, please be sure to describe thoroughly what bug you found, steps to reproduce the bug, and what behavior you expected.

----------
nosy: +Dennis Sweeney
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46706>
_______________________________________

From report at bugs.python.org  Wed Feb  9 21:03:08 2022
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 10 Feb 2022 02:03:08 +0000
Subject: [issue46703] boolean operation issue (True == False == False)
In-Reply-To: <1644454512.3.0.572499319459.issue46703@roundup.psfhosted.org>
Message-ID: <1644458588.38.0.972202883937.issue46703@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> True == False == False is really True == False and False == False 
> wich is False and True which is False

Moreover, since the left-hand comparison is `True == False`, which evaluates to False, the right-hand comparison doesn't even get evaluated. 

In the following example, print(3) doesn't get called because the left-hand comparison, `None != None`, is False:

    >>> print(1) != print(2) == print(3)
    1
    2
    False

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46703>
_______________________________________

From report at bugs.python.org  Wed Feb  9 21:34:57 2022
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 10 Feb 2022 02:34:57 +0000
Subject: [issue46704] Parser API not checking for null-terminator
In-Reply-To: <1644456184.13.0.709670971668.issue46704@roundup.psfhosted.org>
Message-ID: <1644460497.4.0.665476226755.issue46704@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Could you please provide an example input to reproduce this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46704>
_______________________________________

From report at bugs.python.org  Wed Feb  9 21:38:13 2022
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 10 Feb 2022 02:38:13 +0000
Subject: [issue46704] Parser API not checking for null-terminator
In-Reply-To: <1644456184.13.0.709670971668.issue46704@roundup.psfhosted.org>
Message-ID: <1644460693.73.0.62631948457.issue46704@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

The contract of that interface is to receive null-terminated strings, so I am a bit clueless on how this could receive a non-null terminated string.

Notice that calling CompileCode with a non-null terminated string is out of contract.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46704>
_______________________________________

From report at bugs.python.org  Wed Feb  9 21:38:47 2022
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 10 Feb 2022 02:38:47 +0000
Subject: [issue46704] Parser API not checking for null-terminator
In-Reply-To: <1644456184.13.0.709670971668.issue46704@roundup.psfhosted.org>
Message-ID: <1644460727.11.0.963349688893.issue46704@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
Removed message: https://bugs.python.org/msg412970

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46704>
_______________________________________

From report at bugs.python.org  Wed Feb  9 21:39:02 2022
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 10 Feb 2022 02:39:02 +0000
Subject: [issue46704] Parser API not checking for null-terminator
In-Reply-To: <1644456184.13.0.709670971668.issue46704@roundup.psfhosted.org>
Message-ID: <1644460742.25.0.814044777498.issue46704@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

The contract of that interface is to receive null-terminated strings, so I am a bit clueless on how this could receive a non-null terminated string.

Notice that calling PyRun_StringFlags with a non-null terminated string is out of contract.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46704>
_______________________________________

From report at bugs.python.org  Wed Feb  9 22:00:43 2022
From: report at bugs.python.org (anthony shaw)
Date: Thu, 10 Feb 2022 03:00:43 +0000
Subject: [issue46707] Parser hanging on stacked { tokens
Message-ID: <1644462043.51.0.510568323188.issue46707@roundup.psfhosted.org>


New submission from anthony shaw <anthonyshaw at apache.org>:

Providing an (invalid) input to the parser causes an exponentially-slow DoS to the Python executable in 3.10.

e.g.

python3.10 -c "{{{{{{{{{{{{{{{{{{{{{:"

takes ~2 seconds

python3.10 -c "{{{{{{{{{{{{{{{{{{{{{{{{:"

takes ~22 seconds

Tested this all the way up to 
d{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{```{{{{{{{ef f():y

which took over an hour

----------
components: Parser
keywords: 3.10regression
messages: 412972
nosy: anthonypjshaw, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Parser hanging on stacked { tokens
type: crash

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46707>
_______________________________________

From report at bugs.python.org  Wed Feb  9 22:01:02 2022
From: report at bugs.python.org (anthony shaw)
Date: Thu, 10 Feb 2022 03:01:02 +0000
Subject: [issue46707] Parser hanging on stacked { tokens
In-Reply-To: <1644462043.51.0.510568323188.issue46707@roundup.psfhosted.org>
Message-ID: <1644462062.23.0.777286302499.issue46707@roundup.psfhosted.org>


Change by anthony shaw <anthonyshaw at apache.org>:


----------
versions: +Python 3.10, Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46707>
_______________________________________

From report at bugs.python.org  Wed Feb  9 22:14:46 2022
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 10 Feb 2022 03:14:46 +0000
Subject: [issue46707] Parser hanging on stacked { tokens
In-Reply-To: <1644462043.51.0.510568323188.issue46707@roundup.psfhosted.org>
Message-ID: <1644462886.56.0.16308415416.issue46707@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +29411
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31241

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46707>
_______________________________________

From report at bugs.python.org  Wed Feb  9 22:19:47 2022
From: report at bugs.python.org (Gregory Beauregard)
Date: Thu, 10 Feb 2022 03:19:47 +0000
Subject: [issue46643] typing.Annotated cannot wrap typing.ParamSpec args/kwargs
In-Reply-To: <1644013165.99.0.0164231326825.issue46643@roundup.psfhosted.org>
Message-ID: <1644463187.3.0.0144985696733.issue46643@roundup.psfhosted.org>


Gregory Beauregard <greg at greg.red> added the comment:

I wrote a PR that fixes the underlying issue here, but I'm leaving it as a draft while the discussion plays out. I think the stuff currently in the patch should be okay regardless of the discussion decision, because the underlying issue is that P.args and P.kwargs didn't pass typing._type_check, which is needed for reasons unrelated to Annotated (such as if they were stringified and had get_type_hints called on them).

If the result of the discussion is that we need to start supporting limitations on where Annotated is used, I'll add another PR that introduces support for this pattern in whatever locations that are decided it shouldn't be allowed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46643>
_______________________________________

From report at bugs.python.org  Wed Feb  9 22:37:26 2022
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 10 Feb 2022 03:37:26 +0000
Subject: [issue46707] Parser hanging on stacked { tokens
In-Reply-To: <1644462043.51.0.510568323188.issue46707@roundup.psfhosted.org>
Message-ID: <1644464246.04.0.147645132872.issue46707@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset b71dc71905ab674ccaa4a56230d17a28f61c325c by Pablo Galindo Salgado in branch 'main':
bpo-46707: Avoid potential exponential backtracking in some syntax errors (GH-31241)
https://github.com/python/cpython/commit/b71dc71905ab674ccaa4a56230d17a28f61c325c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46707>
_______________________________________

From report at bugs.python.org  Wed Feb  9 22:39:11 2022
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 10 Feb 2022 03:39:11 +0000
Subject: [issue46707] Parser hanging on stacked { tokens
In-Reply-To: <1644462043.51.0.510568323188.issue46707@roundup.psfhosted.org>
Message-ID: <1644464351.97.0.204689601294.issue46707@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +29412
pull_request: https://github.com/python/cpython/pull/31242

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46707>
_______________________________________

From report at bugs.python.org  Wed Feb  9 22:39:56 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 10 Feb 2022 03:39:56 +0000
Subject: [issue46705] Memory optimization for set.issubset
In-Reply-To: <1644456286.75.0.570469463639.issue46705@roundup.psfhosted.org>
Message-ID: <1644464396.8.0.307421957299.issue46705@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/issue46705>
_______________________________________

From report at bugs.python.org  Wed Feb  9 22:40:27 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 10 Feb 2022 03:40:27 +0000
Subject: [issue46705] Memory optimization for set.issubset
In-Reply-To: <1644456286.75.0.570469463639.issue46705@roundup.psfhosted.org>
Message-ID: <1644464427.45.0.623784471953.issue46705@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
versions:  -Python 3.10, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46705>
_______________________________________

From report at bugs.python.org  Wed Feb  9 22:54:55 2022
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 10 Feb 2022 03:54:55 +0000
Subject: [issue46707] Parser hanging on stacked { tokens
In-Reply-To: <1644462043.51.0.510568323188.issue46707@roundup.psfhosted.org>
Message-ID: <1644465295.22.0.196153248901.issue46707@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 9b23f8f78fdb0d7eba016616ae7a97abbfc65aa6 by Pablo Galindo Salgado in branch '3.10':
[3.10] bpo-46707: Avoid potential exponential backtracking in some syntax errors (GH-31241). (GH-31242)
https://github.com/python/cpython/commit/9b23f8f78fdb0d7eba016616ae7a97abbfc65aa6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46707>
_______________________________________

From report at bugs.python.org  Wed Feb  9 22:54:55 2022
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 10 Feb 2022 03:54:55 +0000
Subject: [issue46707] Parser hanging on stacked { tokens
In-Reply-To: <1644462043.51.0.510568323188.issue46707@roundup.psfhosted.org>
Message-ID: <1644465295.02.0.764193758839.issue46707@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/issue46707>
_______________________________________

From report at bugs.python.org  Wed Feb  9 22:55:09 2022
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 10 Feb 2022 03:55:09 +0000
Subject: [issue46707] Parser hanging on stacked { tokens
In-Reply-To: <1644462043.51.0.510568323188.issue46707@roundup.psfhosted.org>
Message-ID: <1644465309.31.0.0950599544037.issue46707@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Thanks Anthony for the report!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46707>
_______________________________________

From report at bugs.python.org  Wed Feb  9 23:27:12 2022
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 10 Feb 2022 04:27:12 +0000
Subject: [issue45923] Improve performance of sys.settracing based tools.
In-Reply-To: <1638185877.94.0.453545318764.issue45923@roundup.psfhosted.org>
Message-ID: <1644467232.13.0.710860847646.issue45923@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
nosy: +brandtbucher
nosy_count: 3.0 -> 4.0
pull_requests: +29413
pull_request: https://github.com/python/cpython/pull/31244

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45923>
_______________________________________

From report at bugs.python.org  Thu Feb 10 00:19:06 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 10 Feb 2022 05:19:06 +0000
Subject: [issue46705] Memory optimization for set.issubset
In-Reply-To: <1644456286.75.0.570469463639.issue46705@roundup.psfhosted.org>
Message-ID: <1644470346.96.0.798475393558.issue46705@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

We care more about the running speed than the memory usage.  Since sets only store pointers to data, they are typically smaller than the data they refer to.

I've attached some instrumentation code for running experiments to verify the workload under various scenarios.

----------
Added file: https://bugs.python.org/file50613/instrument_issubset.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46705>
_______________________________________

From report at bugs.python.org  Thu Feb 10 01:03:26 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 10 Feb 2022 06:03:26 +0000
Subject: [issue46705] Memory optimization for set.issubset
In-Reply-To: <1644456286.75.0.570469463639.issue46705@roundup.psfhosted.org>
Message-ID: <1644473006.59.0.423132137499.issue46705@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I've run a few more experiments and this looks like a net win more often than not.  Go ahead and submit a PR so we can evaluate it further.

----------
Added file: https://bugs.python.org/file50614/instrument_issubset.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46705>
_______________________________________

From report at bugs.python.org  Thu Feb 10 01:03:35 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 10 Feb 2022 06:03:35 +0000
Subject: [issue46705] Memory optimization for set.issubset
In-Reply-To: <1644456286.75.0.570469463639.issue46705@roundup.psfhosted.org>
Message-ID: <1644473015.73.0.57811261429.issue46705@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


Removed file: https://bugs.python.org/file50613/instrument_issubset.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46705>
_______________________________________

From report at bugs.python.org  Thu Feb 10 01:04:49 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 10 Feb 2022 06:04:49 +0000
Subject: [issue46705] Memory optimization for set.issubset
In-Reply-To: <1644456286.75.0.570469463639.issue46705@roundup.psfhosted.org>
Message-ID: <1644473089.31.0.00743542959277.issue46705@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


Removed file: https://bugs.python.org/file50614/instrument_issubset.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46705>
_______________________________________

From report at bugs.python.org  Thu Feb 10 01:05:22 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 10 Feb 2022 06:05:22 +0000
Subject: [issue46705] Memory optimization for set.issubset
In-Reply-To: <1644456286.75.0.570469463639.issue46705@roundup.psfhosted.org>
Message-ID: <1644473122.37.0.659264932342.issue46705@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


Added file: https://bugs.python.org/file50615/instrument_issubset.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46705>
_______________________________________

From report at bugs.python.org  Thu Feb 10 02:00:34 2022
From: report at bugs.python.org (Stanley)
Date: Thu, 10 Feb 2022 07:00:34 +0000
Subject: [issue21910] [doc] File protocol should document if writelines must
 handle generators sensibly
In-Reply-To: <1404380309.75.0.473808735546.issue21910@psf.upfronthosting.co.za>
Message-ID: <1644476434.24.0.510790238117.issue21910@roundup.psfhosted.org>


Change by Stanley <ostanley.lee at gmail.com>:


----------
keywords: +patch
pull_requests: +29414
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31245

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21910>
_______________________________________

From report at bugs.python.org  Thu Feb 10 02:48:39 2022
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 10 Feb 2022 07:48:39 +0000
Subject: [issue45393] help() on operator precedence has confusing entries
 "await" "x" and "not" "x"
In-Reply-To: <1633534428.51.0.112977953361.issue45393@roundup.psfhosted.org>
Message-ID: <1644479319.84.0.960785393586.issue45393@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 5.0 -> 6.0
pull_requests: +29415
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31246

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45393>
_______________________________________

From report at bugs.python.org  Thu Feb 10 02:54:15 2022
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 10 Feb 2022 07:54:15 +0000
Subject: [issue45393] help() on operator precedence has confusing entries
 "await" "x" and "not" "x"
In-Reply-To: <1633534428.51.0.112977953361.issue45393@roundup.psfhosted.org>
Message-ID: <1644479655.8.0.282480099195.issue45393@roundup.psfhosted.org>


Zackery Spytz <zspytz at gmail.com> added the comment:

I have created a patch for this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45393>
_______________________________________

From report at bugs.python.org  Thu Feb 10 02:59:12 2022
From: report at bugs.python.org (Julien Palard)
Date: Thu, 10 Feb 2022 07:59:12 +0000
Subject: [issue42238] Deprecate suspicious.py?
In-Reply-To: <1604274563.95.0.828690163802.issue42238@roundup.psfhosted.org>
Message-ID: <1644479952.68.0.134047908801.issue42238@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:


New changeset b878b3af0b3a9e3ab3ffcaf90a4066dfb3bb7cac by Julien Palard in branch 'main':
bpo-42238: [doc] moving from rstlint.py to sphinx-lint. (GH-31097)
https://github.com/python/cpython/commit/b878b3af0b3a9e3ab3ffcaf90a4066dfb3bb7cac


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42238>
_______________________________________

From report at bugs.python.org  Thu Feb 10 03:18:12 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 10 Feb 2022 08:18:12 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644481092.98.0.780862652921.issue46323@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:

@hydroflask @vstinner

Okay let's remove if statement, I will send a patch soon.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Thu Feb 10 03:35:24 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 10 Feb 2022 08:35:24 +0000
Subject: [issue46705] Memory optimization for set.issubset
In-Reply-To: <1644456286.75.0.570469463639.issue46705@roundup.psfhosted.org>
Message-ID: <1644482124.77.0.201138473982.issue46705@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Would not testing len(self.difference(other)) == 0 be more efficient? Making a copy of a set and removing elements one by one may be faster than add elements one by one, because we only need to allocate a single chunk of memory for a set.

It depends on relative values of len(self), len(other) and len(set(other)). For example, the following code may be optimal in some cases:

    tmp = set()
    it = iter(other)
    for item in it:
        # if item in self: ?
        tmp.add(item)
        if len(tmp) >= len(self):
            self = self.difference(tmp, it)
            if not self:
                return True
            self.difference_update(other)
            return not self
    else:
        return False  # len(self) > len(set(other))

The disadvantage of such optimizations is that they make the code much more bigger. The current code is small and simple, and good enough in most cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46705>
_______________________________________

From report at bugs.python.org  Thu Feb 10 03:51:43 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Thu, 10 Feb 2022 08:51:43 +0000
Subject: [issue45863] tarfile zeroes ustar header fields unnecessarily
In-Reply-To: <1637568080.9.0.260845551853.issue45863@roundup.psfhosted.org>
Message-ID: <1644483103.64.0.176288325501.issue45863@roundup.psfhosted.org>


Change by Nikita Sobolev <mail at sobolevn.me>:


----------
nosy: +sobolevn
nosy_count: 4.0 -> 5.0
pull_requests: +29416
pull_request: https://github.com/python/cpython/pull/31248

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45863>
_______________________________________

From report at bugs.python.org  Thu Feb 10 03:51:44 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Thu, 10 Feb 2022 08:51:44 +0000
Subject: [issue46430] intern strings in deepfrozen modules
In-Reply-To: <1642590983.92.0.896257318647.issue46430@roundup.psfhosted.org>
Message-ID: <1644483104.15.0.136201976914.issue46430@roundup.psfhosted.org>


Change by Nikita Sobolev <mail at sobolevn.me>:


----------
nosy: +sobolevn
nosy_count: 3.0 -> 4.0
pull_requests: +29417
pull_request: https://github.com/python/cpython/pull/31248

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46430>
_______________________________________

From report at bugs.python.org  Thu Feb 10 04:08:59 2022
From: report at bugs.python.org (miss-islington)
Date: Thu, 10 Feb 2022 09:08:59 +0000
Subject: [issue46430] intern strings in deepfrozen modules
In-Reply-To: <1642590983.92.0.896257318647.issue46430@roundup.psfhosted.org>
Message-ID: <1644484139.39.0.120901468759.issue46430@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset dee020a6f5bf29f95bec6294da9bcd577114f592 by Nikita Sobolev in branch 'main':
Fix sphinx-lint after #31097 and b878b3a (GH-31248)
https://github.com/python/cpython/commit/dee020a6f5bf29f95bec6294da9bcd577114f592


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46430>
_______________________________________

From report at bugs.python.org  Thu Feb 10 04:08:59 2022
From: report at bugs.python.org (miss-islington)
Date: Thu, 10 Feb 2022 09:08:59 +0000
Subject: [issue45863] tarfile zeroes ustar header fields unnecessarily
In-Reply-To: <1637568080.9.0.260845551853.issue45863@roundup.psfhosted.org>
Message-ID: <1644484139.48.0.892629795895.issue45863@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset dee020a6f5bf29f95bec6294da9bcd577114f592 by Nikita Sobolev in branch 'main':
Fix sphinx-lint after #31097 and b878b3a (GH-31248)
https://github.com/python/cpython/commit/dee020a6f5bf29f95bec6294da9bcd577114f592


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45863>
_______________________________________

From report at bugs.python.org  Thu Feb 10 04:23:17 2022
From: report at bugs.python.org (Tzu-ping Chung)
Date: Thu, 10 Feb 2022 09:23:17 +0000
Subject: [issue46622] Support decorating a coroutine with
 functools.cached_property
In-Reply-To: <1643873308.65.0.92890586202.issue46622@roundup.psfhosted.org>
Message-ID: <1644484997.64.0.607393944456.issue46622@roundup.psfhosted.org>


Tzu-ping Chung <uranusjr at gmail.com> added the comment:

> should not use asyncio directly but 'async def', 'await', and `inspect.iscoroutine()` / `inspect.iscoroutinefunction()` instead.

Hmm, this introduces some difficulties. Since a coroutine can only be awaited once, a new coroutine needs to be returned (that simply return the result when awaited) each time __get__ is called. But this means we need a way to somehow get the result in __get__. If there?s a separate `cached_property_async` it?s possible to make __get__ a coroutine function, but personally I?d prefer the interface to match the PyPI cached_property.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46622>
_______________________________________

From report at bugs.python.org  Thu Feb 10 04:27:44 2022
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 10 Feb 2022 09:27:44 +0000
Subject: [issue46657] Add mimalloc memory allocator
In-Reply-To: <1644158952.9.0.443530192167.issue46657@roundup.psfhosted.org>
Message-ID: <1644485264.4.0.677242241579.issue46657@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

ICC 2021 has full support for stdatomic.h and compiles mimalloc just fine:

$ CC="icc" ./configure -C --with-pydebug
$ make
$ ./python
Python 3.11.0a5+ (main, Feb  9 2022, 15:57:40) [GCC Intel(R) C++ gcc 7.5 mode] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys._malloc_info
sys._malloc_info(allocator='mimalloc_debug', with_pymalloc=True, with_mimalloc=True, mimalloc_secure=4, mimalloc_debug=2)


AIX xlc is still a problem. It does not support C11 stdatomic.h. But it comes with older GCC atomic memory access __sync function family, https://www.ibm.com/docs/en/xl-c-and-cpp-aix/13.1.3?topic=cbif-gcc-atomic-memory-access-built-in-functions-extension . It might be possible to re-implement mimalloc's atomics with __sync functions (e.g. https://gist.github.com/nhatminhle/5181506). The implementation would be less efficient, though. The __sync functions don't have memory order, atomic_load_explicit(v) becomes __sync_fetch_and_add(v, 0), and atomic_store_explicit() requires two full memory barriers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46657>
_______________________________________

From report at bugs.python.org  Thu Feb 10 04:46:13 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 10 Feb 2022 09:46:13 +0000
Subject: [issue46622] Support decorating a coroutine with
 functools.cached_property
In-Reply-To: <1643873308.65.0.92890586202.issue46622@roundup.psfhosted.org>
Message-ID: <1644486373.14.0.772649199724.issue46622@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

You can return a wrapper from __get__ that awaits the inner function and saves the result somewhere.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46622>
_______________________________________

From report at bugs.python.org  Thu Feb 10 04:47:13 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 10 Feb 2022 09:47:13 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644486433.24.0.769984197816.issue46323@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
pull_requests: +29418
pull_request: https://github.com/python/cpython/pull/31249

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Thu Feb 10 05:04:54 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 10 Feb 2022 10:04:54 +0000
Subject: [issue46622] Support decorating a coroutine with
 functools.cached_property
In-Reply-To: <1643873308.65.0.92890586202.issue46622@roundup.psfhosted.org>
Message-ID: <1644487494.07.0.194906114846.issue46622@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Something like:

_unset = ['unset']
class CachedAwaitable:
    def __init__(self, awaitable):
        self.awaitable = awaitable
        self.result = _unset
    def __await__(self):
        if self.result is _unset:
            self.result = yield from self.awaitable.__await__()
        return self.result

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46622>
_______________________________________

From report at bugs.python.org  Thu Feb 10 05:10:11 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 10 Feb 2022 10:10:11 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644487811.37.0.913582448403.issue46323@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:


New changeset db052851a70fd95d047c6263fc16a75e4d47b3ed by Dong-hee Na in branch 'main':
bpo-46323: Allow alloca(0) for python callback function of ctypes (GH-31249)
https://github.com/python/cpython/commit/db052851a70fd95d047c6263fc16a75e4d47b3ed


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Thu Feb 10 05:48:23 2022
From: report at bugs.python.org (Alex Waygood)
Date: Thu, 10 Feb 2022 10:48:23 +0000
Subject: [issue46066] Deprecate keyword args syntax for TypedDict definition
In-Reply-To: <1639409817.42.0.21314101687.issue46066@roundup.psfhosted.org>
Message-ID: <1644490103.91.0.274261800927.issue46066@roundup.psfhosted.org>


Alex Waygood <Alex.Waygood at Gmail.com> added the comment:

Just so that all the discussion related to this issue can be found in one place, here's a summary:

- After opening this ticket, OP opened an issue in the python/typing repository, where the idea of deprecating this syntax received many thumbs-up reactions, and where there were no dissenting voices: https://github.com/python/typing/issues/981
- The initial impetus for this change was this mypy bug report: https://github.com/python/mypy/issues/11555
- Mypy's policy since January 2020 has been that it would be more trouble than it's worth to attempt to support the kwargs-based syntax: https://github.com/python/mypy/issues/2492#issuecomment-579500959

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46066>
_______________________________________

From report at bugs.python.org  Thu Feb 10 06:12:19 2022
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 10 Feb 2022 11:12:19 +0000
Subject: [issue46072] Unify handling of stats in the CPython VM
In-Reply-To: <1639498673.65.0.709719181358.issue46072@roundup.psfhosted.org>
Message-ID: <1644491539.57.0.283277795304.issue46072@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
pull_requests: +29419
pull_request: https://github.com/python/cpython/pull/31250

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46072>
_______________________________________

From report at bugs.python.org  Thu Feb 10 06:45:45 2022
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 10 Feb 2022 11:45:45 +0000
Subject: [issue46072] Unify handling of stats in the CPython VM
In-Reply-To: <1639498673.65.0.709719181358.issue46072@roundup.psfhosted.org>
Message-ID: <1644493545.88.0.604361702481.issue46072@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
pull_requests: +29420
pull_request: https://github.com/python/cpython/pull/31251

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46072>
_______________________________________

From report at bugs.python.org  Thu Feb 10 06:53:56 2022
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Feb 2022 11:53:56 +0000
Subject: [issue46708] test_asyncio: test_sock_client_fail() changes
 asyncio.events._event_loop_policy
Message-ID: <1644494036.19.0.505794618548.issue46708@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Seen on s390x RHEL7 Refleaks 3.x:
https://buildbot.python.org/all/#/builders/129/builds/300

== Tests result: FAILURE ==
(...)
3 tests failed:
    test_asyncio test_importlib test_unittest
(...)
0:36:44 load avg: 0.50 Re-running test_asyncio in verbose mode (matching: test_sock_client_fail)
beginning 6 repetitions
123456
test_sock_client_fail (test.test_asyncio.test_sock_lowlevel.EPollEventLoopTests) ... ok
test_sock_client_fail (test.test_asyncio.test_sock_lowlevel.PollEventLoopTests) ... ok
test_sock_client_fail (test.test_asyncio.test_sock_lowlevel.SelectEventLoopTests) ... ok

----------------------------------------------------------------------
Ran 3 tests in 0.062s

OK
test_sock_client_fail (test.test_asyncio.test_sock_lowlevel.EPollEventLoopTests) ... ok
test_sock_client_fail (test.test_asyncio.test_sock_lowlevel.PollEventLoopTests) ... ok
test_sock_client_fail (test.test_asyncio.test_sock_lowlevel.SelectEventLoopTests) ... ok

----------------------------------------------------------------------
Ran 3 tests in 0.061s

OK
test_sock_client_fail (test.test_asyncio.test_sock_lowlevel.EPollEventLoopTests) ... ok
test_sock_client_fail (test.test_asyncio.test_sock_lowlevel.PollEventLoopTests) ... ok
test_sock_client_fail (test.test_asyncio.test_sock_lowlevel.SelectEventLoopTests) ... ok

----------------------------------------------------------------------
Ran 3 tests in 0.055s

OK
test_sock_client_fail (test.test_asyncio.test_sock_lowlevel.EPollEventLoopTests) ... ok
test_sock_client_fail (test.test_asyncio.test_sock_lowlevel.PollEventLoopTests) ... ok
test_sock_client_fail (test.test_asyncio.test_sock_lowlevel.SelectEventLoopTests) ... ok

----------------------------------------------------------------------
Ran 3 tests in 0.053s

OK
test_sock_client_fail (test.test_asyncio.test_sock_lowlevel.EPollEventLoopTests) ... ok
test_sock_client_fail (test.test_asyncio.test_sock_lowlevel.PollEventLoopTests) ... ok
test_sock_client_fail (test.test_asyncio.test_sock_lowlevel.SelectEventLoopTests) ... ok

----------------------------------------------------------------------
Ran 3 tests in 0.060s

OK
test_sock_client_fail (test.test_asyncio.test_sock_lowlevel.EPollEventLoopTests) ... ok
test_sock_client_fail (test.test_asyncio.test_sock_lowlevel.PollEventLoopTests) ... ok
test_sock_client_fail (test.test_asyncio.test_sock_lowlevel.SelectEventLoopTests) ... ok

----------------------------------------------------------------------
Ran 3 tests in 0.060s

OK
......
Warning -- asyncio.events._event_loop_policy was modified by test_asyncio
Warning --   Before: None
Warning --   After:  <asyncio.unix_events._UnixDefaultEventLoopPolicy object at 0x3ff9cac3f80>

----------
components: Tests, asyncio
messages: 412991
nosy: asvetlov, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: test_asyncio: test_sock_client_fail() changes asyncio.events._event_loop_policy
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46708>
_______________________________________

From report at bugs.python.org  Thu Feb 10 06:55:12 2022
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Feb 2022 11:55:12 +0000
Subject: [issue46708] test_asyncio: test_sock_client_fail() changes
 asyncio.events._event_loop_policy
In-Reply-To: <1644494036.19.0.505794618548.issue46708@roundup.psfhosted.org>
Message-ID: <1644494112.15.0.125118944314.issue46708@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

By default, asyncio.events._event_loop_policy is None:

$ ./python -i
>>> import asyncio; asyncio.events._event_loop_policy is None
True


After running the test, it changes:

vstinner at apu$ ./python -i
Python 3.11.0a5+ (heads/main:46328d8ae6, Feb  9 2022, 21:25:58) [GCC 11.2.1 20211203 (Red Hat 11.2.1-7)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import asyncio; asyncio.events._event_loop_policy is None
True
>>> 
vstinner at apu$ ./python -i -m test test_asyncio -m test_sock_client_fail
(...)
Tests result: SUCCESS
(...)
SystemExit: 0
>>> import asyncio; asyncio.events._event_loop_policy
<asyncio.unix_events._UnixDefaultEventLoopPolicy object at 0x7ff7286e7530>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46708>
_______________________________________

From report at bugs.python.org  Thu Feb 10 07:04:16 2022
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Feb 2022 12:04:16 +0000
Subject: [issue46709] test_urllib: testInterruptCaught() has a race condition
 and fails randomly
Message-ID: <1644494656.37.0.2113700788.issue46709@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

test_urllib failed and then passed when re-run on s390x RHEL7 Refleaks 3.x:
https://buildbot.python.org/all/#builders/129/builds/300

I can reproduce the issue on my Linux laptop:

$ ./python -m test -m unittest.test.test_break.TestBreakDefaultIntHandler.testInterruptCaught test_unittest -F
0:00:00 load avg: 1.52 Run tests sequentially
0:00:00 load avg: 1.52 [  1] test_unittest
0:00:00 load avg: 1.52 [  2] test_unittest
0:00:00 load avg: 1.52 [  3] test_unittest
0:00:00 load avg: 1.52 [  4] test_unittest
0:00:00 load avg: 1.52 [  5] test_unittest
0:00:01 load avg: 1.52 [  6] test_unittest
0:00:01 load avg: 1.52 [  7] test_unittest
0:00:01 load avg: 1.52 [  8] test_unittest
test test_unittest failed -- Traceback (most recent call last):
  File "/home/vstinner/python/main/Lib/unittest/test/test_break.py", line 66, in testInterruptCaught
    test(result)
    ^^^^^^^^^^^^
  File "/home/vstinner/python/main/Lib/unittest/test/test_break.py", line 63, in test
    self.assertTrue(result.shouldStop)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: False is not true

test_unittest failed (1 failure)

== Tests result: FAILURE ==

7 tests OK.

1 test failed:
    test_unittest

Total duration: 1.7 sec
Tests result: FAILURE

----------
components: Tests
messages: 412993
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_urllib: testInterruptCaught() has a race condition and fails randomly
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46709>
_______________________________________

From report at bugs.python.org  Thu Feb 10 07:24:04 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 10 Feb 2022 12:24:04 +0000
Subject: [issue46708] test_asyncio: test_sock_client_fail() changes
 asyncio.events._event_loop_policy
In-Reply-To: <1644494036.19.0.505794618548.issue46708@roundup.psfhosted.org>
Message-ID: <1644495844.67.0.467244127497.issue46708@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Thanks for the report!
Let me make a fix PR in a few minutes

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46708>
_______________________________________

From report at bugs.python.org  Thu Feb 10 07:36:27 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 10 Feb 2022 12:36:27 +0000
Subject: [issue46708] test_asyncio: test_sock_client_fail() changes
 asyncio.events._event_loop_policy
In-Reply-To: <1644494036.19.0.505794618548.issue46708@roundup.psfhosted.org>
Message-ID: <1644496587.07.0.357367710805.issue46708@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
keywords: +patch
pull_requests: +29421
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31253

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46708>
_______________________________________

From report at bugs.python.org  Thu Feb 10 07:50:37 2022
From: report at bugs.python.org (Erlend E. Aasland)
Date: Thu, 10 Feb 2022 12:50:37 +0000
Subject: [issue45490] [C API] PEP 670: Convert macros to functions in the
 Python C API
In-Reply-To: <1634319805.82.0.902360778503.issue45490@roundup.psfhosted.org>
Message-ID: <1644497437.29.0.136418300645.issue45490@roundup.psfhosted.org>


Erlend E. Aasland <erlend.aasland at innova.no> added the comment:

I made a list of macros that reuse their argument some time around February/March 2021. (Each macro is squashed into a single line for some reason I can't remember.) See attachment, or check out the gist version:

https://gist.github.com/erlend-aasland/a7ca3cff95b136e272ff5b03447aff21

----------
Added file: https://bugs.python.org/file50616/macros-that-reuse-args.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45490>
_______________________________________

From report at bugs.python.org  Thu Feb 10 07:56:12 2022
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 10 Feb 2022 12:56:12 +0000
Subject: [issue46072] Unify handling of stats in the CPython VM
In-Reply-To: <1639498673.65.0.709719181358.issue46072@roundup.psfhosted.org>
Message-ID: <1644497772.67.0.0973826488078.issue46072@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
pull_requests: +29422
pull_request: https://github.com/python/cpython/pull/31254

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46072>
_______________________________________

From report at bugs.python.org  Thu Feb 10 07:57:59 2022
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 10 Feb 2022 12:57:59 +0000
Subject: [issue46532] Improve efficiency of PRECALL/CALL instructions
In-Reply-To: <1643190282.99.0.74296903316.issue46532@roundup.psfhosted.org>
Message-ID: <1644497879.45.0.391801845223.issue46532@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset 2cea8c29cf975a8ad7d8c3ff19d1e836c2d54707 by Mark Shannon in branch 'main':
bpo-46532: Reduce number of memory writes to update call_shape.kwnames. (GH-31231)
https://github.com/python/cpython/commit/2cea8c29cf975a8ad7d8c3ff19d1e836c2d54707


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46532>
_______________________________________

From report at bugs.python.org  Thu Feb 10 07:59:17 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 10 Feb 2022 12:59:17 +0000
Subject: [issue46708] test_asyncio: test_sock_client_fail() changes
 asyncio.events._event_loop_policy
In-Reply-To: <1644494036.19.0.505794618548.issue46708@roundup.psfhosted.org>
Message-ID: <1644497957.28.0.563116055604.issue46708@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
pull_requests: +29423
pull_request: https://github.com/python/cpython/pull/31255

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46708>
_______________________________________

From report at bugs.python.org  Thu Feb 10 08:00:03 2022
From: report at bugs.python.org (Marcus Fillipe Groetares Rocha Siqueira)
Date: Thu, 10 Feb 2022 13:00:03 +0000
Subject: [issue46710] Install launcher for all users on the domain
Message-ID: <1644498003.71.0.314795481937.issue46710@roundup.psfhosted.org>


New submission from Marcus Fillipe Groetares Rocha Siqueira <marcus.siqueira at ort.org.br>:

In Python 3.9.6 (64 bits) Windows Installer, the first page show a checkbox for "install launcher for all users (recommended)", but i'd like to now why the box is not currently allowed to check.

In "customize installation" option, exist other "Install for all users" options and its not working also.

I tried to install with my local admin account and with my AD Admin account as well.

can somebody help me please?

----------
components: Windows
files: Sem t?tulo.jpg
messages: 412997
nosy: marcus.siqueira, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Install launcher for all users on the domain
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file50617/Sem t?tulo.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46710>
_______________________________________

From report at bugs.python.org  Thu Feb 10 08:03:34 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 10 Feb 2022 13:03:34 +0000
Subject: [issue46708] test_asyncio: test_sock_client_fail() changes
 asyncio.events._event_loop_policy
In-Reply-To: <1644494036.19.0.505794618548.issue46708@roundup.psfhosted.org>
Message-ID: <1644498214.26.0.264697946126.issue46708@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
pull_requests: +29424
pull_request: https://github.com/python/cpython/pull/31256

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46708>
_______________________________________

From report at bugs.python.org  Thu Feb 10 08:17:09 2022
From: report at bugs.python.org (Steve Dower)
Date: Thu, 10 Feb 2022 13:17:09 +0000
Subject: [issue46710] Install launcher for all users on the domain
In-Reply-To: <1644498003.71.0.314795481937.issue46710@roundup.psfhosted.org>
Message-ID: <d56c6637-6706-a19c-9646-e407abaaa8cb@python.org>


Steve Dower <steve.dower at python.org> added the comment:

This option may be disabled if you have already installed the launcher 
for only the current user. In this case, we aren't able to replace it 
with an all-users install.

Open Programs and Features and find the Python launcher, uninstall it, 
and then try again.

If it doesn't appear to be installed, you may have another issue. We'd 
need to see the log files created in %TEMP% when you run the installer 
(only up until the checkbox is shown, there should be enough information 
in the log files by then to see what's going on).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46710>
_______________________________________

From report at bugs.python.org  Thu Feb 10 08:22:07 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 10 Feb 2022 13:22:07 +0000
Subject: [issue46708] test_asyncio: test_sock_client_fail() changes
 asyncio.events._event_loop_policy
In-Reply-To: <1644494036.19.0.505794618548.issue46708@roundup.psfhosted.org>
Message-ID: <1644499327.31.0.453413112283.issue46708@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
versions: +Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46708>
_______________________________________

From report at bugs.python.org  Thu Feb 10 08:25:08 2022
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 10 Feb 2022 13:25:08 +0000
Subject: [issue46072] Unify handling of stats in the CPython VM
In-Reply-To: <1639498673.65.0.709719181358.issue46072@roundup.psfhosted.org>
Message-ID: <1644499508.4.0.664621882555.issue46072@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
pull_requests: +29425
pull_request: https://github.com/python/cpython/pull/31259

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46072>
_______________________________________

From report at bugs.python.org  Thu Feb 10 08:29:11 2022
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Feb 2022 13:29:11 +0000
Subject: [issue46708] test_asyncio: test_sock_client_fail() changes
 asyncio.events._event_loop_policy
In-Reply-To: <1644494036.19.0.505794618548.issue46708@roundup.psfhosted.org>
Message-ID: <1644499751.68.0.703432191357.issue46708@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

With PR 31253 fix, I confirm that it fix my bug explained in msg412992.

commit 012e77eb5c3ba3d411f5967a7f368ebdb42ab88c
Author: Andrew Svetlov <andrew.svetlov at gmail.com>
Date:   Thu Feb 10 14:57:20 2022 +0200

    Fix warning: asyncio.events._event_loop_policy was modified by test_asyncio (GH-31253)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46708>
_______________________________________

From report at bugs.python.org  Thu Feb 10 08:32:35 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 10 Feb 2022 13:32:35 +0000
Subject: [issue46708] test_asyncio: test_sock_client_fail() changes
 asyncio.events._event_loop_policy
In-Reply-To: <1644494036.19.0.505794618548.issue46708@roundup.psfhosted.org>
Message-ID: <1644499955.49.0.112357221793.issue46708@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/issue46708>
_______________________________________

From report at bugs.python.org  Thu Feb 10 08:43:47 2022
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Feb 2022 13:43:47 +0000
Subject: [issue46711] test_logging: test_post_fork_child_no_deadlock() failed
 with timeout on AMD64 Arch Linux Asan Debug 3.10
Message-ID: <1644500627.85.0.365242228935.issue46711@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

The test calls support.wait_process() which uses SHORT_TIMEOUT.

wait_process() should use LONG_TIMEOUT, or the ASAN buildbot should increase its timeout (regrtest --timeout parameter).

IMO using LONG_TIMEOUT is fine: it's ok if the test takes 2 minutes instead of 1 second, it's only important that it completes :-) The test should not measure the *performance* of the code, only if the code is valid. When tests are run in parallel, the buildbot system load can be very high. In this case, the system load was 1.70:

0:35:49 load avg: 1.70 [255/421/1] test_logging failed (1 failure) (1 min 18 sec)


AMD64 Arch Linux Asan Debug 3.10:
https://buildbot.python.org/all/#/builders/621/builds/466

======================================================================
FAIL: test_post_fork_child_no_deadlock (test.test_logging.HandlerTest)
Ensure child logging locks are not held; bpo-6721 & bpo-36533.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/buildbot/buildarea/3.10.pablogsal-arch-x86_64.asan_debug/build/Lib/test/test_logging.py", line 750, in test_post_fork_child_no_deadlock
    support.wait_process(pid, exitcode=0)
  File "/buildbot/buildarea/3.10.pablogsal-arch-x86_64.asan_debug/build/Lib/test/support/__init__.py", line 1971, in wait_process
    raise AssertionError(f"process {pid} is still running "
AssertionError: process 406366 is still running after 52.5 seconds

----------
components: Tests
messages: 413000
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_logging: test_post_fork_child_no_deadlock() failed with timeout on AMD64 Arch Linux Asan Debug 3.10
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46711>
_______________________________________

From report at bugs.python.org  Thu Feb 10 08:44:04 2022
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 10 Feb 2022 13:44:04 +0000
Subject: [issue46690] create_autospec() doesn't respect configure_mock style
 kwargs
In-Reply-To: <1644407640.16.0.14753457907.issue46690@roundup.psfhosted.org>
Message-ID: <1644500644.46.0.906291074683.issue46690@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I guess the problem is that during the initial mock creation kwargs is passed so calling test_method immediately after mock creation raises ValueError. But as we loop through the attributes and create new child mock for the attributes the original configured mock for the method that raises ValueError is overridden by another object without the configuration info. Probably it makes sense to call configure_mock again after all children mock are constructed. Something like below works and I don't see any test failures in mock related test cases.

index 2719f74d6f..585e875c95 100644
--- a/Lib/unittest/mock.py
+++ b/Lib/unittest/mock.py
@@ -2637,6 +2637,7 @@ def create_autospec(spec, spec_set=False, instance=False, _parent=None,
                                f'[object={spec!r}]')
     is_async_func = _is_async_func(spec)
     _kwargs = {'spec': spec}
+    original_kwargs = kwargs
     if spec_set:
         _kwargs = {'spec_set': spec}
     elif spec is None:
@@ -2740,6 +2741,9 @@ def create_autospec(spec, spec_set=False, instance=False, _parent=None,
         if isinstance(new, FunctionTypes):
             setattr(mock, entry, new)
 
+    if _is_instance_mock(mock):
+        mock.configure_mock(**original_kwargs)
+
     return mock

----------
components: +Library (Lib) -Tests
nosy: +cjw296, lisroach, mariocj89, michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46690>
_______________________________________

From report at bugs.python.org  Thu Feb 10 08:50:10 2022
From: report at bugs.python.org (Meer Suri)
Date: Thu, 10 Feb 2022 13:50:10 +0000
Subject: [issue46494] Mention typing_extensions in the typing documentation
In-Reply-To: <1642985496.62.0.269697400688.issue46494@roundup.psfhosted.org>
Message-ID: <1644501010.77.0.260965892772.issue46494@roundup.psfhosted.org>


Change by Meer Suri <meersuri at gmail.com>:


----------
keywords: +patch
pull_requests: +29426
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31260

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46494>
_______________________________________

From report at bugs.python.org  Thu Feb 10 08:58:21 2022
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 10 Feb 2022 13:58:21 +0000
Subject: [issue46709] test_urllib: testInterruptCaught() has a race condition
 and fails randomly
In-Reply-To: <1644494656.37.0.2113700788.issue46709@roundup.psfhosted.org>
Message-ID: <1644501501.46.0.842501465868.issue46709@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/issue46709>
_______________________________________

From report at bugs.python.org  Thu Feb 10 09:03:20 2022
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 10 Feb 2022 14:03:20 +0000
Subject: [issue46681] gzip.compress does not forward compresslevel to
 zlib.compress
In-Reply-To: <1644331972.38.0.86974192008.issue46681@roundup.psfhosted.org>
Message-ID: <1644501800.39.0.395390937296.issue46681@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46681>
_______________________________________

From report at bugs.python.org  Thu Feb 10 09:11:07 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Thu, 10 Feb 2022 14:11:07 +0000
Subject: [issue46430] intern strings in deepfrozen modules
In-Reply-To: <1642590983.92.0.896257318647.issue46430@roundup.psfhosted.org>
Message-ID: <1644502267.05.0.193322997939.issue46430@roundup.psfhosted.org>


Kumar Aditya <rahuladitya303 at gmail.com> added the comment:

I consider this done so closing it as improving the error handling of interning it out of scope of this issue.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46430>
_______________________________________

From report at bugs.python.org  Thu Feb 10 09:11:41 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Thu, 10 Feb 2022 14:11:41 +0000
Subject: [issue46608] Exclude marshalled-frozen data if deep-freezing to save
 300 KB space
In-Reply-To: <1643792907.85.0.286906427988.issue46608@roundup.psfhosted.org>
Message-ID: <1644502301.19.0.258168743167.issue46608@roundup.psfhosted.org>


Change by Kumar Aditya <rahuladitya303 at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46608>
_______________________________________

From report at bugs.python.org  Thu Feb 10 09:18:03 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Thu, 10 Feb 2022 14:18:03 +0000
Subject: [issue46712] Share global string identifiers in deepfreeze
Message-ID: <1644502683.1.0.673362326219.issue46712@roundup.psfhosted.org>


New submission from Kumar Aditya <rahuladitya303 at gmail.com>:

Since bpo-46541, the global strings are statically allocated so they can now be referenced by deep-frozen modules just like any other singleton. Sharing identifiers with deepfreeze will reduce the duplicated strings hence it would save space.

See https://github.com/faster-cpython/ideas/issues/218
See https://github.com/faster-cpython/ideas/issues/230

----------
messages: 413003
nosy: gvanrossum, kumaraditya303
priority: normal
severity: normal
status: open
title: Share global string identifiers in deepfreeze
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46712>
_______________________________________

From report at bugs.python.org  Thu Feb 10 09:18:11 2022
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 10 Feb 2022 14:18:11 +0000
Subject: [issue46430] intern strings in deepfrozen modules
In-Reply-To: <1642590983.92.0.896257318647.issue46430@roundup.psfhosted.org>
Message-ID: <1644502691.71.0.327119516844.issue46430@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Please leave the ticket open until we have an agreement how to handle the missing error checks.

----------
resolution: fixed -> 
stage: resolved -> 
status: closed -> open
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46430>
_______________________________________

From report at bugs.python.org  Thu Feb 10 09:27:25 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Thu, 10 Feb 2022 14:27:25 +0000
Subject: [issue46712] Share global string identifiers in deepfreeze
In-Reply-To: <1644502683.1.0.673362326219.issue46712@roundup.psfhosted.org>
Message-ID: <1644503245.44.0.850046305669.issue46712@roundup.psfhosted.org>


Kumar Aditya <rahuladitya303 at gmail.com> added the comment:

I have refactored generate_global_objects.py, and now instead of hard-coding every identifier manually, it now scans *.c files extracts the identifiers used in it and then generate the header file. This has multiple advantages:

- No need to manually add identifiers, as soon as it is used in a c file it is added to the global identifiers struct.
- It simplifies the codegen a lot.
- Remove the need of special casing certain file for checking now it is just a set of identifiers and auto removes unused global strings.

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46712>
_______________________________________

From report at bugs.python.org  Thu Feb 10 09:27:52 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Thu, 10 Feb 2022 14:27:52 +0000
Subject: [issue46712] Share global string identifiers in deepfreeze
In-Reply-To: <1644502683.1.0.673362326219.issue46712@roundup.psfhosted.org>
Message-ID: <1644503272.78.0.863028737129.issue46712@roundup.psfhosted.org>


Change by Kumar Aditya <rahuladitya303 at gmail.com>:


----------
keywords: +patch
pull_requests: +29427
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31261

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46712>
_______________________________________

From report at bugs.python.org  Thu Feb 10 09:30:37 2022
From: report at bugs.python.org (Marcus Fillipe Groetares Rocha Siqueira)
Date: Thu, 10 Feb 2022 14:30:37 +0000
Subject: [issue46710] Install launcher for all users on the domain
In-Reply-To: <1644498003.71.0.314795481937.issue46710@roundup.psfhosted.org>
Message-ID: <1644503437.97.0.486146971855.issue46710@roundup.psfhosted.org>


Marcus Fillipe Groetares Rocha Siqueira <marcus.siqueira at ort.org.br> added the comment:

Thanks Steve, it worked.
Hava a nice day :)

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46710>
_______________________________________

From report at bugs.python.org  Thu Feb 10 09:33:43 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Thu, 10 Feb 2022 14:33:43 +0000
Subject: [issue46541] Replace _Py_IDENTIFIER() with statically initialized
 objects.
In-Reply-To: <1643234464.46.0.949364478641.issue46541@roundup.psfhosted.org>
Message-ID: <1644503623.56.0.203528728828.issue46541@roundup.psfhosted.org>


Change by Kumar Aditya <rahuladitya303 at gmail.com>:


----------
pull_requests: +29428
pull_request: https://github.com/python/cpython/pull/31261

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46541>
_______________________________________

From report at bugs.python.org  Thu Feb 10 09:45:41 2022
From: report at bugs.python.org (Meer Suri)
Date: Thu, 10 Feb 2022 14:45:41 +0000
Subject: [issue46586] In documentation contents enum.property erroneously
 links to built-in property
In-Reply-To: <1643555525.86.0.209520180874.issue46586@roundup.psfhosted.org>
Message-ID: <1644504341.6.0.276685605344.issue46586@roundup.psfhosted.org>


Meer Suri <meersuri at gmail.com> added the comment:

It took me some time to figure out how to prevent the creation of a reference/hyperlink using the ! prefix. I've made the change to remove the references to the max and min attributes of sys.float_info and pushed.

How do I find other instances of this problem? Is there a systematic way to look for such references?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46586>
_______________________________________

From report at bugs.python.org  Thu Feb 10 10:17:12 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Thu, 10 Feb 2022 15:17:12 +0000
Subject: [issue46586] In documentation contents enum.property erroneously
 links to built-in property
In-Reply-To: <1643555525.86.0.209520180874.issue46586@roundup.psfhosted.org>
Message-ID: <1644506232.62.0.0333774034554.issue46586@roundup.psfhosted.org>


Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:

> How do I find other instances of this problem? Is there a systematic way to look for such references?

You could write a script that goes something like this, iterating over all the docs RST files:

- Find all definitions in the file (e.g. `.. decorator:: property`)
- Filter to those that have names that also appear in builtins
- Find any links using those names within the same file

That would catch the enum.property case, but not the float_info one ?ric noticed, because sys.rst doesn't define `max` at all. To catch that one, you could look at the link role: sys.rst links to it with :const:`max`, but functions.rst defines it as `.. function:: max`. Mismatches like that could be another clue that something is wrong (but there are some legitimate reasons why the roles won't match perfectly, like "decorator" in the definition vs. "func" in the link).

----------
nosy: +Jelle Zijlstra

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46586>
_______________________________________

From report at bugs.python.org  Thu Feb 10 10:20:56 2022
From: report at bugs.python.org (Meer Suri)
Date: Thu, 10 Feb 2022 15:20:56 +0000
Subject: [issue46586] In documentation contents enum.property erroneously
 links to built-in property
In-Reply-To: <1643555525.86.0.209520180874.issue46586@roundup.psfhosted.org>
Message-ID: <1644506456.66.0.629862311752.issue46586@roundup.psfhosted.org>


Meer Suri <meersuri at gmail.com> added the comment:

Can someone guide me on why I'm getting a no-new-line at end of file error for the NEWS entry when I didnt change this file in the last commit and it passed the Azure checks earlier

Error: [1] ../Misc/NEWS.d/next/Documentation/2022-02-08-15-38-16.bpo-46586.6qVFVL.rst:0: No newline at end of file (no-newline-at-end-of-file). Do I need to manually add the new line?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46586>
_______________________________________

From report at bugs.python.org  Thu Feb 10 10:34:09 2022
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 10 Feb 2022 15:34:09 +0000
Subject: [issue46586] In documentation contents enum.property erroneously
 links to built-in property
In-Reply-To: <1643555525.86.0.209520180874.issue46586@roundup.psfhosted.org>
Message-ID: <1644507249.91.0.612391985872.issue46586@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

An updated reST linting check was added between the time you created the PR and your last update.  As Jelle noted on the PR, there doesn't need to be a NEWS entry for this anyway.

We might have an issue there if sphinx-lint is going to have an issue with no trailing newline and blurb-it isn't going to add a trailing newline, though. (+mdk)

----------
nosy: +mdk, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46586>
_______________________________________

From report at bugs.python.org  Thu Feb 10 10:48:14 2022
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 10 Feb 2022 15:48:14 +0000
Subject: [issue46586] In documentation contents enum.property erroneously
 links to built-in property
In-Reply-To: <1643555525.86.0.209520180874.issue46586@roundup.psfhosted.org>
Message-ID: <1644508094.25.0.89692059627.issue46586@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> added the comment:

Thinking about it again: The issue is that these tables (for sys.float_info and other named tuples / structseqs) use the const role, which is not meant to identify attributes but to link to them (similar to func, mod, data, etc).  In other words we are fixing an issue that a wrong target is used, but we should not be linking for a target at all, this is the target.  So if we can?t use the equivalent of directives function, module, etc (that define the targets of func, mod, etc), then maybe they should be just ``name``, not :role:`name`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46586>
_______________________________________

From report at bugs.python.org  Thu Feb 10 11:37:30 2022
From: report at bugs.python.org (Petr Viktorin)
Date: Thu, 10 Feb 2022 16:37:30 +0000
Subject: [issue46433] _PyType_GetModuleByDef optimization is incorrect
In-Reply-To: <1642607197.61.0.0970144809853.issue46433@roundup.psfhosted.org>
Message-ID: <1644511050.87.0.619981384177.issue46433@roundup.psfhosted.org>


Change by Petr Viktorin <encukou at gmail.com>:


----------
pull_requests: +29429
stage: backport needed -> patch review
pull_request: https://github.com/python/cpython/pull/31262

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46433>
_______________________________________

From report at bugs.python.org  Thu Feb 10 11:41:58 2022
From: report at bugs.python.org (Petr Viktorin)
Date: Thu, 10 Feb 2022 16:41:58 +0000
Subject: [issue46433] _PyType_GetModuleByDef optimization is incorrect
In-Reply-To: <1642607197.61.0.0970144809853.issue46433@roundup.psfhosted.org>
Message-ID: <1644511318.21.0.394361777732.issue46433@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

Just 3.10, after all. 3.9 doesn't have the function yet.

I did the backport, but I'd welcome a review by a fresh set of eyes!

----------
versions:  -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46433>
_______________________________________

From report at bugs.python.org  Thu Feb 10 12:22:25 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 10 Feb 2022 17:22:25 +0000
Subject: [issue46066] Deprecate keyword args syntax for TypedDict definition
In-Reply-To: <1644490103.91.0.274261800927.issue46066@roundup.psfhosted.org>
Message-ID: <CAP7+vJLp+RFsQ-vMnd_cWNd9Fonwm+hiX8cvpp=47PAZWUo2Xw@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

Go ahead and send a or to deprecate it.--
--Guido (mobile)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46066>
_______________________________________

From report at bugs.python.org  Thu Feb 10 12:31:47 2022
From: report at bugs.python.org (Chris Larson)
Date: Thu, 10 Feb 2022 17:31:47 +0000
Subject: [issue13305] datetime.strftime("%Y") not consistent for years < 1000
In-Reply-To: <1320091957.61.0.759691422668.issue13305@psf.upfronthosting.co.za>
Message-ID: <1644514307.63.0.933693579862.issue13305@roundup.psfhosted.org>


Chris Larson <cklarson at gmail.com> added the comment:

Has there been any work/progress on this? Alternatively, what suggested work around/mitigations are suggested?

----------
nosy: +cklarson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13305>
_______________________________________

From report at bugs.python.org  Thu Feb 10 12:31:40 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 10 Feb 2022 17:31:40 +0000
Subject: [issue46066] Deprecate keyword args syntax for TypedDict definition
In-Reply-To: <CAP7+vJLp+RFsQ-vMnd_cWNd9Fonwm+hiX8cvpp=47PAZWUo2Xw@mail.gmail.com>
Message-ID: <CAP7+vJLCTYi5a2fwTZCbCMLFb0nbvQtYNwhY-fnq4OimbCngfA@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

"PR"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46066>
_______________________________________

From report at bugs.python.org  Thu Feb 10 12:34:53 2022
From: report at bugs.python.org (Alex Waygood)
Date: Thu, 10 Feb 2022 17:34:53 +0000
Subject: [issue46066] Deprecate keyword args syntax for TypedDict definition
In-Reply-To: <1639409817.42.0.21314101687.issue46066@roundup.psfhosted.org>
Message-ID: <1644514493.0.0.120065869257.issue46066@roundup.psfhosted.org>


Alex Waygood <Alex.Waygood at Gmail.com> added the comment:

@Guido, OP already has ? Jelle and I have both reviewed and approved it :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46066>
_______________________________________

From report at bugs.python.org  Thu Feb 10 12:50:23 2022
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 10 Feb 2022 17:50:23 +0000
Subject: [issue45923] Improve performance of sys.settracing based tools.
In-Reply-To: <1638185877.94.0.453545318764.issue45923@roundup.psfhosted.org>
Message-ID: <1644515423.48.0.469421684235.issue45923@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset d7a5aca982def155a9255893cefcc1493c127c9c by Brandt Bucher in branch 'main':
bpo-45923: Add `RESUME_QUICK` (GH-31244)
https://github.com/python/cpython/commit/d7a5aca982def155a9255893cefcc1493c127c9c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45923>
_______________________________________

From report at bugs.python.org  Thu Feb 10 13:05:49 2022
From: report at bugs.python.org (hydroflask)
Date: Thu, 10 Feb 2022 18:05:49 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644516349.64.0.755002832674.issue46323@roundup.psfhosted.org>


hydroflask <hydroflask at yqxmail.com> added the comment:

Thanks again everyone, very much appreciated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Thu Feb 10 14:08:31 2022
From: report at bugs.python.org (Adrian Chaves)
Date: Thu, 10 Feb 2022 19:08:31 +0000
Subject: [issue33017] Special set-cookie setting will bypass Cookielib
In-Reply-To: <1520392643.04.0.467229070634.issue33017@psf.upfronthosting.co.za>
Message-ID: <1644520111.69.0.980122421605.issue33017@roundup.psfhosted.org>


Adrian Chaves <adrian at zyte.com> added the comment:

So, PoC shows how an empty domain attribute (Domain=) is erroneously turned into a dot (.).

I want to add that a dot (Domain=.) should be turned into an empty string (the specification asks to remove a leading dot if found).

----------
nosy: +adrian2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33017>
_______________________________________

From report at bugs.python.org  Thu Feb 10 14:19:45 2022
From: report at bugs.python.org (Joshua Bronson)
Date: Thu, 10 Feb 2022 19:19:45 +0000
Subject: [issue46713] Provide a C implementation of collections.abc.KeysView
 and friends
Message-ID: <1644520785.16.0.447466630814.issue46713@roundup.psfhosted.org>


New submission from Joshua Bronson <jabronson at gmail.com>:

As suggested by @rhettinger in https://bugs.python.org/msg409443, I'm creating a feature request for C implementations of collections.abc.KeysView, ValuesView, and ItemsView.

Because these do not currently benefit from C speedups, they're a lot slower than their dict_keys, dict_values, and dict_items counterparts. As a result, libraries that implement custom Mapping types that are backed by dicts are incentivized to override the implementations of keys(), values(), and items() they inherit from collections.abc.Mapping to instead return their backing dicts' mapping views, causing a potential abstraction leak.

An example can be found in https://github.com/jab/bidict, which implements bidirectional mapping types that wrap a forward and an inverse dict which are kept in sync with one another.

>>> from bidict import *
>>> bi = bidict({1: 'one', 2: 'two'})
>>> bi.items()  # Overridden for performance:
dict_items([(1, 'one'), (2, 'two')])

Ditto for OrderedBidict:

>>> OrderedBidict(bi).keys()
_OrderedBidictItemsView(OrderedBidict([(1, 'one'), (2, 'two')]))


(The _OrderedBidictItemsView is a custom view whose __iter__ uses the implementation inherited by its collections.abc.ItemsView base class so that the correct order is respected, but proxies other method calls through to the backing dict's dict_items object: https://github.com/jab/bidict/blob/2ab42a/bidict/_orderedbidict.py#L90-L150)


Here is a microbenchmark of calling __eq__ on an _OrderedBidictItemsView vs. a collections.abc.ItemsView, to estimate the performance impact (using Python 3.10):

? set setup '
    from collections.abc import ItemsView
    from bidict import OrderedBidict
    d = dict(zip(range(9999), range(9999)))
    ob = OrderedBidict(d)'

? python -m pyperf timeit -s $setup 'ob.items() == d.items()' -o 1.json

? python -m pyperf timeit -s $setup 'ItemsView(ob) == d.items()' -o 2.json

? pyperf compare_to 2.json 1.json
Mean +- std dev: [2] 4.21 ms +- 1.10 ms -> [1] 168 us +- 6 us: 25.13x faster


This demonstrates a potentially significant speedup. Similar microbenchmarks for ItemsView vs. dict_items, as well as KeysView vs. both dict_keys and _OrderedBidictKeysView, also indicate similarly significant potential.

Note that the performance benefits of this may propagate to other code as well. For example, bidicts' __eq__ methods are implemented in terms of their itemsviews (see https://github.com/jab/bidict/blob/2ab42a/bidict/_base.py#L285-L286), so speeding up bidict.items().__eq__ speeds up bidict.__eq__ commensurately.

----------
messages: 413020
nosy: jab
priority: normal
severity: normal
status: open
title: Provide a C implementation of collections.abc.KeysView and friends

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46713>
_______________________________________

From report at bugs.python.org  Thu Feb 10 14:47:24 2022
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 10 Feb 2022 19:47:24 +0000
Subject: [issue13305] datetime.strftime("%Y") not consistent for years < 1000
In-Reply-To: <1320091957.61.0.759691422668.issue13305@psf.upfronthosting.co.za>
Message-ID: <1644522444.49.0.137071942776.issue13305@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

The tempora library implements a [portable strftime](https://tempora.readthedocs.io/en/latest/index.html#tempora.strftime).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13305>
_______________________________________

From report at bugs.python.org  Thu Feb 10 15:37:34 2022
From: report at bugs.python.org (richd)
Date: Thu, 10 Feb 2022 20:37:34 +0000
Subject: [issue46714] Python 3.10 - Users (except from the one who installed)
 not able to see python in add remove programs.
Message-ID: <1644525454.7.0.0618238851907.issue46714@roundup.psfhosted.org>


New submission from richd <richard.dong at ivanti.com>:

Experiencing the same issue as reported in https://bugs.python.org/issue31011

When Python is deployed using an enterprise solution, Python is not displayed in Programs and Features.

Examples:
1. Using PSExec as System to install Python 3.10.x, logged in users will not see Python installed. The Python launcher does appear however.

2. Deployment of Python through SCCM has the same behavior, where logged in users do not see the installed Python version in Programs and Features.

----------
components: Windows
messages: 413022
nosy: paul.moore, richd, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python 3.10 - Users (except from the one who installed) not able to see python in add remove programs.
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46714>
_______________________________________

From report at bugs.python.org  Thu Feb 10 15:48:44 2022
From: report at bugs.python.org (Joshua Bronson)
Date: Thu, 10 Feb 2022 20:48:44 +0000
Subject: [issue45670] New .mapping attribute is broken for some existing uses
 of dict views
In-Reply-To: <1635525410.44.0.846161043783.issue45670@roundup.psfhosted.org>
Message-ID: <1644526124.97.0.327985085857.issue45670@roundup.psfhosted.org>


Joshua Bronson <jabronson at gmail.com> added the comment:

Thank you for confirming that ChainMap.__iter__() would be in the same boat as bidict if a similar .mapping attribute were ever added to dict_keyiterators. The specifics of this issue are interesting, but even more interesting to me is whatever learnings we can generalize from this.


After testing that the performance impact would be significant, I created the feature request you suggested in https://bugs.python.org/issue46713. Thanks for suggesting that.


In the meantime, I've updated the relevant docstrings:

>>> help(b.keys)
keys() -> KeysView[~KT] method of bidict.bidict instance
    A set-like object providing a view on the contained keys.
    
    When *b._fwdm* is a :class:`dict`, *b.keys()* returns a
    *dict_keys* object that behaves exactly the same as
    *collections.abc.KeysView(b)*, except for
    
      - offering better performance
    
      - being reversible on Python 3.8+
    
      - having a .mapping attribute in Python 3.10+
        that exposes a mappingproxy to *b._fwdm*.

>>> help(b.values)
values() -> bidict.BidictKeysView[~VT] method of bidict.bidict instance
    A set-like object providing a view on the contained values.
    
    Since the values of a bidict are equivalent to the keys of its inverse,
    this method returns a set-like object for this bidict's values
    rather than just a collections.abc.ValuesView.
    This object supports set operations like union and difference,
    and constant- rather than linear-time containment checks,
    and is no more expensive to provide than the less capable
    collections.abc.ValuesView would be.
    
    See :meth:`keys` for more information.

etc.


Regarding:
> The values() call unexpectedly returns an instance of dict_keys(). At first, I was surprised that this got past the type checker -- you can do set operations with KeysView but not with a ValuesView.

Check out https://github.com/jab/bidict/blob/82f931/bidict/_base.py#L38-L45:

```
class BidictKeysView(t.KeysView[KT], t.ValuesView[KT]):
    """Since the keys of a bidict are the values of its inverse (and vice versa),
    the ValuesView result of calling *bi.values()* is also a KeysView of *bi.inverse*.
    """


dict_keys: t.Type[t.KeysView[t.Any]] = type({}.keys())
BidictKeysView.register(dict_keys)
```

See also https://github.com/python/typeshed/issues/4435 for a request that typeshed use a Protocol (structural typing) here.


Thanks again for taking the time to look at my code and discuss so generously.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45670>
_______________________________________

From report at bugs.python.org  Thu Feb 10 15:53:56 2022
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Thu, 10 Feb 2022 20:53:56 +0000
Subject: [issue38119] resource tracker destroys shared memory segments when
 other processes should still have valid access
In-Reply-To: <1568217506.85.0.770661201111.issue38119@roundup.psfhosted.org>
Message-ID: <1644526436.78.0.911774633076.issue38119@roundup.psfhosted.org>


Change by G?ry <gery.ogam at gmail.com>:


----------
nosy: +maggyero

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38119>
_______________________________________

From report at bugs.python.org  Thu Feb 10 15:54:28 2022
From: report at bugs.python.org (Steve Dower)
Date: Thu, 10 Feb 2022 20:54:28 +0000
Subject: [issue46714] Python 3.10 - Users (except from the one who installed)
 not able to see python in add remove programs.
In-Reply-To: <1644525454.7.0.0618238851907.issue46714@roundup.psfhosted.org>
Message-ID: <1644526468.66.0.770220474874.issue46714@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Thanks. This is being tracked in issue25166, and is waiting on a fix from our installer toolset, who have previously indicated that they're not interested in fixing it, but wouldn't rule it out in their next major version.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Windows All Users installation places uninstaller in user profile

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46714>
_______________________________________

From report at bugs.python.org  Thu Feb 10 16:24:36 2022
From: report at bugs.python.org (John Snow)
Date: Thu, 10 Feb 2022 21:24:36 +0000
Subject: [issue46715] asyncio.create_unix_server has an off-by-one error
 concerning the backlog parameter
Message-ID: <1644528275.99.0.104636658968.issue46715@roundup.psfhosted.org>


New submission from John Snow <jsnow at redhat.com>:

Hi, asyncio.create_unix_server appears to treat the "backlog" parameter as where 0 means that *no connection will ever possibly be pending*, which (at the very least for UNIX sockets on my machine) is untrue.

Consider a (non-asyncio) server:

```python
import os, socket, sys, time

sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
sock.bind('test.sock')

sock.listen(backlog=0)

while True:
    print('.', end='', file=sys.stderr)
    time.sleep(1)
```

This server never calls accept(), and uses a backlog of zero. However, a client can actually still successfully call connect against such a server:

```python
import os, socket, time

sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
sock.setblocking(False)

sock.connect('test.sock')
print("Connected!")
```

When run against the server example, the first invocation of this client will actually connect successfully (Surprising, but that's how the C syscalls work too, so... alright) but the second invocation of this client will raise BlockingIOError (EAGAIN).

Further, if we amend the first server example to actually call accept(), it will succeed when the first client connects -- demonstrating that the actual total queue length here was actually effectively 1, not 0.

(i.e. there's always room for at least one connection to be considered, and the backlog counts everybody else.)

However, in asyncio.BaseSelectorEventLoop._accept_connection(...), the code uses `for _ in range(backlog)` to determine the maximum number of accept calls to make. When backlog is set to zero, this means we will *never* call accept, even when there are pending connections.

Note that when backlog=1, this actually allows for *two* pending connections before clients are rejected, but this loop will only fire once. This behavior is surprising, because backlog==0 means we'll accept no clients, but backlog==1 means we will allow for two to enqueue before accepting both. There is seemingly no way with asyncio to actually specify "Exactly one pending connection".

I think this loop should be amended to reflect the actual truth of the backlog parameter, and it should iterate over `backlog + 1`. This does necessitate a change to `Lib/test/test_asyncio/test_selector_events.py` which believes that backlog=100 means that accept() should be called 100 times (instead of 101.)

A (very) simple fix is attached here; if it seems sound, I can spin a real PR on GitHub.

----------
components: asyncio
files: issue.patch
keywords: patch
messages: 413025
nosy: asvetlov, jnsnow, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.create_unix_server has an off-by-one error concerning the backlog parameter
type: behavior
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file50618/issue.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46715>
_______________________________________

From report at bugs.python.org  Thu Feb 10 16:58:08 2022
From: report at bugs.python.org (Dennis Sweeney)
Date: Thu, 10 Feb 2022 21:58:08 +0000
Subject: [issue44953] Add vectorcall on operator.itemgetter and attrgetter
 objects
In-Reply-To: <1629365029.54.0.100452744635.issue44953@roundup.psfhosted.org>
Message-ID: <1644530288.06.0.0922410526878.issue44953@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:


New changeset 0a145069e807fdafd1fa0315b9bc22da363d2d39 by Dennis Sweeney in branch 'main':
bpo-44953: Add vectorcall for itemgetter and attrgetter instances (GH-27828)
https://github.com/python/cpython/commit/0a145069e807fdafd1fa0315b9bc22da363d2d39


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44953>
_______________________________________

From report at bugs.python.org  Thu Feb 10 17:01:51 2022
From: report at bugs.python.org (Eric Snow)
Date: Thu, 10 Feb 2022 22:01:51 +0000
Subject: [issue36876] [subinterpreters] Global C variables are a problem
In-Reply-To: <1557514902.13.0.853517754348.issue36876@roundup.psfhosted.org>
Message-ID: <1644530511.62.0.893268080583.issue36876@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
pull_requests: +29430
pull_request: https://github.com/python/cpython/pull/31264

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36876>
_______________________________________

From report at bugs.python.org  Thu Feb 10 17:32:24 2022
From: report at bugs.python.org (Alex Waygood)
Date: Thu, 10 Feb 2022 22:32:24 +0000
Subject: [issue46713] Provide a C implementation of collections.abc.KeysView
 and friends
In-Reply-To: <1644520785.16.0.447466630814.issue46713@roundup.psfhosted.org>
Message-ID: <1644532344.16.0.151275081863.issue46713@roundup.psfhosted.org>


Change by Alex Waygood <Alex.Waygood at Gmail.com>:


----------
nosy: +rhettinger
type:  -> performance
versions: +Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46713>
_______________________________________

From report at bugs.python.org  Thu Feb 10 17:39:47 2022
From: report at bugs.python.org (Dennis Sweeney)
Date: Thu, 10 Feb 2022 22:39:47 +0000
Subject: [issue44953] Add vectorcall on operator.itemgetter and attrgetter
 objects
In-Reply-To: <1629365029.54.0.100452744635.issue44953@roundup.psfhosted.org>
Message-ID: <1644532787.14.0.485615313422.issue44953@roundup.psfhosted.org>


Change by Dennis Sweeney <sweeney.dennis650 at gmail.com>:


----------
pull_requests: +29431
pull_request: https://github.com/python/cpython/pull/31265

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44953>
_______________________________________

From report at bugs.python.org  Thu Feb 10 17:57:28 2022
From: report at bugs.python.org (Dennis Sweeney)
Date: Thu, 10 Feb 2022 22:57:28 +0000
Subject: [issue44953] Add vectorcall on operator.itemgetter and attrgetter
 objects
In-Reply-To: <1629365029.54.0.100452744635.issue44953@roundup.psfhosted.org>
Message-ID: <1644533848.38.0.268825647368.issue44953@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:


New changeset 035414a878a772d1d293cdecdc4470bcce5e5d7a by Dennis Sweeney in branch 'main':
bpo-44953: Add newline at end of NEWS entry (GH-31265)
https://github.com/python/cpython/commit/035414a878a772d1d293cdecdc4470bcce5e5d7a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44953>
_______________________________________

From report at bugs.python.org  Thu Feb 10 18:09:17 2022
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Feb 2022 23:09:17 +0000
Subject: [issue46716] regrtest didn't respect the timeout on AMD64 Windows11
 3.x
Message-ID: <1644534557.28.0.000333882929265.issue46716@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

regrtest was run with --timeout 900 on AMD64 Windows11 3.x: timeout confirmed by "(timeout: 15 min, worker timeout: 20 min)" log. But then test_subprocss was only stopped after "4 hour 55 min".

If the regrtest main process is able to display an update 2x per minutes (every 30 sec), it should be able to stop the test worker process (test_subprocess) after 20 minutes. How is it possible that the process took so long?

There are multiple guards:

* (1) in the worker process: _runtest() calls faulthandler.dump_traceback_later(ns.timeout, exit=True)
* (2) libregrtest/runtest_mp.py: TestWorkerProcess._run_process() thread uses popen.communicate(timeout=self.timeout)
* (3) faulthandler.dump_traceback_later(MAIN_PROCESS_TIMEOUT, exit=True): kill the parent process if it is blocked for longer than 5 minutes

Guards (1) and (2) didn't work.

Maybe the parent process should implement a 4th guard using the 20 minute timeout: almost 5 hours is way longer than 20 minutes!


C:\buildbot\3.x.kloth-win11\build>"C:\buildbot\3.x.kloth-win11\build\PCbuild\amd64\python_d.exe"  -u -Wd -E -bb -m test  -uall -rwW --slowest --timeout 1200 --fail-env-changed -j1 -j2 --junit-xml test-results.xml -j40 --timeout 900
== CPython 3.11.0a5+ (main, Feb 10 2022, 04:03:24) [MSC v.1930 64 bit (AMD64)]
== Windows-10-10.0.22000-SP0 little-endian
== cwd: C:\buildbot\3.x.kloth-win11\build\build\test_python_5732?
== CPU count: 32
== encodings: locale=cp1252, FS=utf-8
Using random seed 6320493
0:00:00 Run tests in parallel using 40 child processes (timeout: 15 min, worker timeout: 20 min)
(...)
0:03:13 load avg: 0.76 [431/432] test_multiprocessing_spawn passed (3 min 13 sec) -- running: test_subprocess (3 min 11 sec)
0:03:43 load avg: 0.46 running: test_subprocess (3 min 41 sec)
(...)
4:53:17 load avg: 0.00 running: test_subprocess (4 hour 53 min)
4:53:47 load avg: 0.00 running: test_subprocess (4 hour 53 min)
4:54:17 load avg: 0.09 running: test_subprocess (4 hour 54 min)
4:54:47 load avg: 0.35 running: test_subprocess (4 hour 54 min)
4:55:17 load avg: 0.48 running: test_subprocess (4 hour 55 min)
4:55:46 load avg: 0.50 [432/432/1] test_subprocess timed out (4 hour 55 min) (4 hour 55 min)

== Tests result: FAILURE ==

397 tests OK.

10 slowest tests:
- test_subprocess: 4 hour 55 min
- test_multiprocessing_spawn: 3 min 13 sec
- test_concurrent_futures: 2 min 46 sec
- test_peg_generator: 2 min 32 sec
- test_compileall: 1 min 34 sec
- test_unparse: 1 min 31 sec
- test_distutils: 1 min 23 sec
- test_asyncio: 1 min 22 sec
- test_tokenize: 1 min 8 sec
- test_io: 1 min 5 sec

1 test failed:
    test_subprocess

----------
components: Tests
messages: 413028
nosy: vstinner
priority: normal
severity: normal
status: open
title: regrtest didn't respect the timeout on AMD64 Windows11 3.x
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46716>
_______________________________________

From report at bugs.python.org  Thu Feb 10 18:10:14 2022
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Feb 2022 23:10:14 +0000
Subject: [issue46716] regrtest didn't respect the timeout when running
 test_subprocess on AMD64 Windows11 3.x
In-Reply-To: <1644534557.28.0.000333882929265.issue46716@roundup.psfhosted.org>
Message-ID: <1644534614.74.0.44764534135.issue46716@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: regrtest didn't respect the timeout on AMD64 Windows11 3.x -> regrtest didn't respect the timeout when running test_subprocess on AMD64 Windows11 3.x

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46716>
_______________________________________

From report at bugs.python.org  Thu Feb 10 18:14:23 2022
From: report at bugs.python.org (Eric Snow)
Date: Thu, 10 Feb 2022 23:14:23 +0000
Subject: [issue36876] [subinterpreters] Global C variables are a problem
In-Reply-To: <1557514902.13.0.853517754348.issue36876@roundup.psfhosted.org>
Message-ID: <1644534863.03.0.0448166439823.issue36876@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:


New changeset 80e4f262aa27a39abf3fadc19a6323fea4607a8f by Eric Snow in branch 'main':
bpo-36876: Make sure the c-analyzer is checking all the source files.' (gh-31264)
https://github.com/python/cpython/commit/80e4f262aa27a39abf3fadc19a6323fea4607a8f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36876>
_______________________________________

From report at bugs.python.org  Thu Feb 10 18:26:38 2022
From: report at bugs.python.org (Jack Nguyen)
Date: Thu, 10 Feb 2022 23:26:38 +0000
Subject: [issue46705] Memory optimization for set.issubset
In-Reply-To: <1644456286.75.0.570469463639.issue46705@roundup.psfhosted.org>
Message-ID: <1644535598.68.0.405595385724.issue46705@roundup.psfhosted.org>


Jack Nguyen <jackyeenguyen at gmail.com> added the comment:

As you say, which implementation performs better likely depends on the nature of the sets. I would suspect that using set.difference won't be substantially faster than using set.intersection in the best case, but it would be much slower if len(self) is much larger than len(self.intersection(other)) e.g. set(range(1_000_000)).issubset(range(10)). Overall I think that using set.intersection will have more well-rounded performance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46705>
_______________________________________

From report at bugs.python.org  Thu Feb 10 19:05:17 2022
From: report at bugs.python.org (Jack Nguyen)
Date: Fri, 11 Feb 2022 00:05:17 +0000
Subject: [issue46705] Memory optimization for set.issubset
In-Reply-To: <1644456286.75.0.570469463639.issue46705@roundup.psfhosted.org>
Message-ID: <1644537917.05.0.170707431149.issue46705@roundup.psfhosted.org>


Change by Jack Nguyen <jackyeenguyen at gmail.com>:


----------
keywords: +patch
pull_requests: +29432
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31267

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46705>
_______________________________________

From report at bugs.python.org  Thu Feb 10 19:45:19 2022
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 11 Feb 2022 00:45:19 +0000
Subject: [issue46246] importlib.metadata.DeprecatedList appears to be missing
 __slots__
In-Reply-To: <1641235148.56.0.272435496464.issue46246@roundup.psfhosted.org>
Message-ID: <1644540319.11.0.743248774164.issue46246@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I'm pretty sure both EntryPoints and DeprecatedList were introduced in Python 3.10, so 3.9 and 3.8 aren't relevant.

----------
versions:  -Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46246>
_______________________________________

From report at bugs.python.org  Thu Feb 10 19:56:25 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 11 Feb 2022 00:56:25 +0000
Subject: [issue46246] importlib.metadata.DeprecatedList appears to be missing
 __slots__
In-Reply-To: <1641235148.56.0.272435496464.issue46246@roundup.psfhosted.org>
Message-ID: <1644540985.04.0.367922979433.issue46246@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset dd76b3f7d332dd6eced5cbc2ad2adfc397700b3d by Arie Bovenberg in branch 'main':
bpo-46246: add missing __slots__ to importlib.metadata.DeprecatedList (GH-30452)
https://github.com/python/cpython/commit/dd76b3f7d332dd6eced5cbc2ad2adfc397700b3d


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46246>
_______________________________________

From report at bugs.python.org  Thu Feb 10 19:56:38 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 11 Feb 2022 00:56:38 +0000
Subject: [issue46246] importlib.metadata.DeprecatedList appears to be missing
 __slots__
In-Reply-To: <1641235148.56.0.272435496464.issue46246@roundup.psfhosted.org>
Message-ID: <1644540998.2.0.280323997753.issue46246@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29433
pull_request: https://github.com/python/cpython/pull/31269

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46246>
_______________________________________

From report at bugs.python.org  Thu Feb 10 20:03:57 2022
From: report at bugs.python.org (Jeremy Kloth)
Date: Fri, 11 Feb 2022 01:03:57 +0000
Subject: [issue46716] regrtest didn't respect the timeout when running
 test_subprocess on AMD64 Windows11 3.x
In-Reply-To: <1644534557.28.0.000333882929265.issue46716@roundup.psfhosted.org>
Message-ID: <1644541437.15.0.328252359733.issue46716@roundup.psfhosted.org>


Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com> added the comment:

The test only completed once I purposefully terminated the offending Python process.  The only identifying information I noticed was the command-line of `-c "while True: pass"`, indicating it was stuck in either
test_call_timeout() or test_timeout() in test_subprocess.py.

Something to note is that Windows does not, by default, have a concept of process trees whereas terminating a parent automatically kills the children.  Eryk Sun may have additional ideas on how this desired behavior could be accomplished.

----------
nosy: +eryksun, jkloth

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46716>
_______________________________________

From report at bugs.python.org  Thu Feb 10 20:18:31 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 11 Feb 2022 01:18:31 +0000
Subject: [issue46246] importlib.metadata.DeprecatedList appears to be missing
 __slots__
In-Reply-To: <1641235148.56.0.272435496464.issue46246@roundup.psfhosted.org>
Message-ID: <1644542311.2.0.987983765191.issue46246@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1124ab6d1d15dc5058e03b63fd1d95e6f1009cc3 by Miss Islington (bot) in branch '3.10':
bpo-46246: add missing __slots__ to importlib.metadata.DeprecatedList (GH-30452)
https://github.com/python/cpython/commit/1124ab6d1d15dc5058e03b63fd1d95e6f1009cc3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46246>
_______________________________________

From report at bugs.python.org  Thu Feb 10 21:55:26 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Feb 2022 02:55:26 +0000
Subject: [issue46400] Please update bundled libexpat to 2.4.4 with security
 fixes (CVE-2021-45960)
In-Reply-To: <1642350760.98.0.31451148779.issue46400@roundup.psfhosted.org>
Message-ID: <1644548126.68.0.20534954398.issue46400@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: Please update bundled libexpat to 2.4.4 with security fixes -> Please update bundled libexpat to 2.4.4 with security fixes (CVE-2021-45960)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46400>
_______________________________________

From report at bugs.python.org  Thu Feb 10 21:59:51 2022
From: report at bugs.python.org (George Gensure)
Date: Fri, 11 Feb 2022 02:59:51 +0000
Subject: [issue46717] Raising exception multiple times leaks memory
Message-ID: <1644548391.27.0.391231331567.issue46717@roundup.psfhosted.org>


New submission from George Gensure <ggensure at fb.com>:

Instantiating an exception and raising it multiple times causes 1 frame and 2 traceback objects to remain allocated for each raise. The attached example causes python to consume 8GB of ram after a few seconds of execution on Windows/Linux.

----------
components: Interpreter Core
files: exc.py
messages: 413035
nosy: ggensure
priority: normal
severity: normal
status: open
title: Raising exception multiple times leaks memory
type: resource usage
versions: Python 3.11
Added file: https://bugs.python.org/file50619/exc.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46717>
_______________________________________

From report at bugs.python.org  Thu Feb 10 22:38:22 2022
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 11 Feb 2022 03:38:22 +0000
Subject: [issue46717] Raising exception multiple times leaks memory
In-Reply-To: <1644548391.27.0.391231331567.issue46717@roundup.psfhosted.org>
Message-ID: <1644550702.18.0.318747286508.issue46717@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/issue46717>
_______________________________________

From report at bugs.python.org  Thu Feb 10 23:26:22 2022
From: report at bugs.python.org (Dennis Sweeney)
Date: Fri, 11 Feb 2022 04:26:22 +0000
Subject: [issue46717] Raising exception multiple times leaks memory
In-Reply-To: <1644548391.27.0.391231331567.issue46717@roundup.psfhosted.org>
Message-ID: <1644553582.45.0.226608378726.issue46717@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

I reproduced as far back as Python 3.6 with this:

-----------------------------------
import gc

exc = Exception()
deltas = []

for i in range(2, 15):
    ref1 = len(gc.get_objects())
    for j in range(2**i):
        try:
            raise exc
        except Exception:
            pass
    ref2 = len(gc.get_objects())
    deltas.append(ref2 - ref1)

print(deltas)
# [4, 8, 16, 9, 64, 128, 256, 512, 1024, 2048, 4072, 8192, 16384]
-----------------------------------


Note that the memory does get freed up once the exception is deleted:

-----------------------------------
import gc

deltas = []

for i in range(2, 15):
    ref1 = len(gc.get_objects())

    exc = Exception()
    for j in range(2**i):
        try:
            raise exc
        except Exception:
            pass
    del exc  # <<<<<<<<<<<<<<<<<<<<<<<<<<<

    ref2 = len(gc.get_objects())
    deltas.append(ref2 - ref1)

print(deltas)
# [0, 0, 0, 0, 0, -14, 0, 0, 0, 0, -14, 0, 0]
-----------------------------------

----------
nosy: +Dennis Sweeney, iritkatriel

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46717>
_______________________________________

From report at bugs.python.org  Fri Feb 11 00:18:56 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 11 Feb 2022 05:18:56 +0000
Subject: [issue46705] Memory optimization for set.issubset
In-Reply-To: <1644456286.75.0.570469463639.issue46705@roundup.psfhosted.org>
Message-ID: <1644556736.66.0.98596906428.issue46705@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> Would not testing len(self.difference(other)) == 0 
> be more efficient?

Yes, I think so.

----------
Added file: https://bugs.python.org/file50620/instrument_issubset.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46705>
_______________________________________

From report at bugs.python.org  Fri Feb 11 00:22:55 2022
From: report at bugs.python.org (Ashleigh Woods)
Date: Fri, 11 Feb 2022 05:22:55 +0000
Subject: [issue45451] IDLE - modify text frame and widget borders
In-Reply-To: <1634087096.76.0.0471723883661.issue45451@roundup.psfhosted.org>
Message-ID: <1644556975.09.0.273793004502.issue45451@roundup.psfhosted.org>


Ashleigh Woods <pulsiedulsie at gmail.com> added the comment:

At a minimum, I think that there should be a toggle for whether this should be present or not, without having to dig in and change the values in IDLE (with, I'd like to note, absolutely no clue where to do that!). This is particularly an issue for beginners.

It'd also be nice to control the color scheme/size etc, but I can understand if that's more complicated.

----------
nosy: +pulsiedulsie

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45451>
_______________________________________

From report at bugs.python.org  Fri Feb 11 00:24:53 2022
From: report at bugs.python.org (Ashlyn Woods)
Date: Fri, 11 Feb 2022 05:24:53 +0000
Subject: [issue45451] IDLE - modify text frame and widget borders
In-Reply-To: <1634087096.76.0.0471723883661.issue45451@roundup.psfhosted.org>
Message-ID: <1644557093.45.0.36861831174.issue45451@roundup.psfhosted.org>


Ashlyn Woods <pulsiedulsie at gmail.com> added the comment:

In addition, I would encourage that people in future try to get a bigger gauge of how many people actually want a feature like this, how many don't, and then make a decision about whether to put it in- considering that there have been a fair few cases where people have clearly reacted negatively to this, maybe you should have checked if people'd dislike it before rolling it out w/o any easy way of undoing it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45451>
_______________________________________

From report at bugs.python.org  Fri Feb 11 02:43:20 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Fri, 11 Feb 2022 07:43:20 +0000
Subject: [issue46709] test_urllib: testInterruptCaught() has a race condition
 and fails randomly
In-Reply-To: <1644494656.37.0.2113700788.issue46709@roundup.psfhosted.org>
Message-ID: <1644565400.59.0.325972445249.issue46709@roundup.psfhosted.org>


Nikita Sobolev <mail at sobolevn.me> added the comment:

I am trying to debug this.

Several intersting notes:
1. `time.sleep()` does not help
2. It always fails on `8`th turn
3. Changing `self.assertTrue(result.shouldStop)` to

```
msg = f'{type(result)} {vars(result)}'
self.assertTrue(result.shouldStop, msg)
```

fixes the problem.

----------
nosy: +sobolevn

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46709>
_______________________________________

From report at bugs.python.org  Fri Feb 11 02:46:08 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Fri, 11 Feb 2022 07:46:08 +0000
Subject: [issue46709] test_urllib: testInterruptCaught() has a race condition
 and fails randomly
In-Reply-To: <1644494656.37.0.2113700788.issue46709@roundup.psfhosted.org>
Message-ID: <1644565568.57.0.812146532048.issue46709@roundup.psfhosted.org>


Nikita Sobolev <mail at sobolevn.me> added the comment:

I think this might be a side effect of https://docs.python.org/3/library/signal.html#execution-of-python-signal-handlers

> A Python signal handler does not get executed inside the low-level (C) signal handler. Instead, the low-level signal handler sets a flag which tells the virtual machine to execute the corresponding Python signal handler at a later point(for example at the next bytecode instruction). This has consequences

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46709>
_______________________________________

From report at bugs.python.org  Fri Feb 11 02:50:13 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Feb 2022 07:50:13 +0000
Subject: [issue46717] Raising exception multiple times leaks memory
In-Reply-To: <1644548391.27.0.391231331567.issue46717@roundup.psfhosted.org>
Message-ID: <1644565813.55.0.112945384399.issue46717@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Did you try to print a traceback of the exception?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46717>
_______________________________________

From report at bugs.python.org  Fri Feb 11 02:52:35 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Fri, 11 Feb 2022 07:52:35 +0000
Subject: [issue46709] test_urllib: testInterruptCaught() has a race condition
 and fails randomly
In-Reply-To: <1644494656.37.0.2113700788.issue46709@roundup.psfhosted.org>
Message-ID: <1644565955.41.0.839710061742.issue46709@roundup.psfhosted.org>


Nikita Sobolev <mail at sobolevn.me> added the comment:

Other tests are also affected:
- `./python.exe -m test -m unittest.test.test_break.TestBreakDefaultIntHandler.testSecondInterrupt test_unittest -F`
- `./python.exe -m test -m unittest.test.test_break.TestBreakDefaultIntHandler.testTwoResults test_unittest -F`
- `./python.exe -m test -m unittest.test.test_break.TestBreakDefaultIntHandler.testHandlerReplacedButCalled test_unittest -F`
- etc

I think that we need a universal solution, I am going to write a helper method and add it to all tests there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46709>
_______________________________________

From report at bugs.python.org  Fri Feb 11 03:15:42 2022
From: report at bugs.python.org (hydroflask)
Date: Fri, 11 Feb 2022 08:15:42 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644567342.19.0.640151311465.issue46323@roundup.psfhosted.org>


hydroflask <hydroflask at yqxmail.com> added the comment:

Was reviewing the code and noticed that a double-free was introduced in the recent changes:

https://github.com/python/cpython/blob/dd76b3f7d332dd6eced5cbc2ad2adfc397700b3d/Modules/_ctypes/callbacks.c#L192

That line should have been removed in https://github.com/python/cpython/commit/b5527688aae11d0b5af58176267a9943576e71e5 but it was missed!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Fri Feb 11 03:21:24 2022
From: report at bugs.python.org (hydroflask)
Date: Fri, 11 Feb 2022 08:21:24 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644567684.17.0.479926422838.issue46323@roundup.psfhosted.org>


hydroflask <hydroflask at yqxmail.com> added the comment:

Another bug, the array returned by alloca() should be zero-initialized. If an early return happens because of an intermediate error, Py_DECREF() will be called on uninitialized memory. Also it should be Py_XDECREF() I think.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Fri Feb 11 03:24:31 2022
From: report at bugs.python.org (hydroflask)
Date: Fri, 11 Feb 2022 08:24:31 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644567871.97.0.910971394911.issue46323@roundup.psfhosted.org>


hydroflask <hydroflask at yqxmail.com> added the comment:

Ignore the previous comment :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Fri Feb 11 03:26:42 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 11 Feb 2022 08:26:42 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644568002.47.0.469914594831.issue46323@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
pull_requests: +29434
pull_request: https://github.com/python/cpython/pull/31272

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Fri Feb 11 03:36:25 2022
From: report at bugs.python.org (Christoph Reiter)
Date: Fri, 11 Feb 2022 08:36:25 +0000
Subject: [issue46541] Replace _Py_IDENTIFIER() with statically initialized
 objects.
In-Reply-To: <1643234464.46.0.949364478641.issue46541@roundup.psfhosted.org>
Message-ID: <1644568585.0.0.541114039344.issue46541@roundup.psfhosted.org>


Christoph Reiter <reiter.christoph at gmail.com> added the comment:

Sorry if off topic, but I noticed that CPython doesn't deprecate macros in code, while with gcc/clang it's possible to show compiler warnings for them using some pragma magic:

$ gcc a.c
a.c: In function 'main':
a.c:29:13: warning: Deprecated pre-processor symbol
   29 |     PySomethingDeprecated (0);
      |             ^~~~~~~~~~~~~~~~~~
a.c:30:13: warning: Deprecated pre-processor symbol: replace with "SomethingCompletelyDifferent"
   30 |     PySomethingDeprecated2 (42);
      |             ^~~~~~~~~~~~~~~~~~~~

Here is how glib implements this for example: https://gist.github.com/lazka/4749c74249a3918a059d944040aca4a3

Maybe that makes getting rid of them easier in the long run?

----------
nosy: +lazka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46541>
_______________________________________

From report at bugs.python.org  Fri Feb 11 03:37:50 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 11 Feb 2022 08:37:50 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644568670.01.0.715349672024.issue46323@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:

> Was reviewing the code and noticed that a double-free was introduced in the recent changes:

Thanks, that looks like my mistake

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Fri Feb 11 03:46:13 2022
From: report at bugs.python.org (hydroflask)
Date: Fri, 11 Feb 2022 08:46:13 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644569173.16.0.568661964802.issue46323@roundup.psfhosted.org>


hydroflask <hydroflask at yqxmail.com> added the comment:

Easy one to make, might be worth adding a test that would have exercised that code path.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Fri Feb 11 03:49:08 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 11 Feb 2022 08:49:08 +0000
Subject: [issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c
In-Reply-To: <1641787281.46.0.018565492634.issue46323@roundup.psfhosted.org>
Message-ID: <1644569348.5.0.463661596537.issue46323@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:


New changeset 0ac5372bf6b937ed44a8f9c4e402d024fcd80870 by Dong-hee Na in branch 'main':
bpo-46323: Fix double-free issue for borrowed refs (GH-31272)
https://github.com/python/cpython/commit/0ac5372bf6b937ed44a8f9c4e402d024fcd80870


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46323>
_______________________________________

From report at bugs.python.org  Fri Feb 11 03:49:32 2022
From: report at bugs.python.org (Irit Katriel)
Date: Fri, 11 Feb 2022 08:49:32 +0000
Subject: [issue46717] Raising exception multiple times leaks memory
In-Reply-To: <1644548391.27.0.391231331567.issue46717@roundup.psfhosted.org>
Message-ID: <1644569372.21.0.398583370378.issue46717@roundup.psfhosted.org>


Irit Katriel <iritkatriel at gmail.com> added the comment:

"raise exc" adds the current frame to the traceback of exc. If you want to clear the previous traceback before raising you can do that with

raise exc.with_traceback(None)

----------
resolution:  -> not a bug

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46717>
_______________________________________

From report at bugs.python.org  Fri Feb 11 04:09:23 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Fri, 11 Feb 2022 09:09:23 +0000
Subject: [issue46709] test_urllib: testInterruptCaught() has a race condition
 and fails randomly
In-Reply-To: <1644494656.37.0.2113700788.issue46709@roundup.psfhosted.org>
Message-ID: <1644570563.5.0.0367803224287.issue46709@roundup.psfhosted.org>


Change by Nikita Sobolev <mail at sobolevn.me>:


----------
keywords: +patch
pull_requests: +29435
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31273

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46709>
_______________________________________

From report at bugs.python.org  Fri Feb 11 04:29:59 2022
From: report at bugs.python.org (hydroflask)
Date: Fri, 11 Feb 2022 09:29:59 +0000
Subject: [issue42698] Deadlock in pysqlite_connection_dealloc()
In-Reply-To: <1608511484.37.0.765804145287.issue42698@roundup.psfhosted.org>
Message-ID: <1644571799.48.0.942225000707.issue42698@roundup.psfhosted.org>


hydroflask <hydroflask at yqxmail.com> added the comment:

Any update on this? I know you wanted to repro but even in the absence of the repro, I think calling sqlite3_close() without releasing the GIL is error-prone. If there is no immediate plan to make this change you may close the issue :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42698>
_______________________________________

From report at bugs.python.org  Fri Feb 11 04:35:22 2022
From: report at bugs.python.org (Erlend E. Aasland)
Date: Fri, 11 Feb 2022 09:35:22 +0000
Subject: [issue42698] Deadlock in pysqlite_connection_dealloc()
In-Reply-To: <1608511484.37.0.765804145287.issue42698@roundup.psfhosted.org>
Message-ID: <1644572122.03.0.754607700594.issue42698@roundup.psfhosted.org>


Erlend E. Aasland <erlend.aasland at innova.no> added the comment:

> Any update on this?

I was unable to reproduce this last time we visited this issue, but I'll give it another try.

> If there is no immediate plan to make this change you may close the issue :)

I do not want to close it until I can a) either prove that it is _not_ an issue, or b) prove that it _is_ an issue _and_ we've got a fix :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42698>
_______________________________________

From report at bugs.python.org  Fri Feb 11 04:42:36 2022
From: report at bugs.python.org (Charlie Zhao)
Date: Fri, 11 Feb 2022 09:42:36 +0000
Subject: [issue46677] TypedDict docs are incomplete
In-Reply-To: <1644262079.95.0.663870450502.issue46677@roundup.psfhosted.org>
Message-ID: <1644572556.31.0.811251478029.issue46677@roundup.psfhosted.org>


Charlie Zhao <zhaoyu_hit at qq.com> added the comment:

Indeed, if you use Python keywords or other invalid Python names as keys of TypedDict, we must use the equivalent forms as follows: 

```
Point2D = TypedDict('Point2D', {'x': int, 'y': int, 'in': str})  # OK

Point2D = TypedDict('Point2D', x=int, y=int, in=str)  # Error
```

Maybe we should add this to the docs.


And, it seems that adding examples for inheritance and attributes of TypedDict would make the docs clearer.

Would you mind if I submit a PR for those changes. :)

----------
nosy: +CharlieZhao

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46677>
_______________________________________

From report at bugs.python.org  Fri Feb 11 04:48:27 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Fri, 11 Feb 2022 09:48:27 +0000
Subject: [issue46711] test_logging: test_post_fork_child_no_deadlock() failed
 with timeout on AMD64 Arch Linux Asan Debug 3.10
In-Reply-To: <1644500627.85.0.365242228935.issue46711@roundup.psfhosted.org>
Message-ID: <1644572907.35.0.105111575926.issue46711@roundup.psfhosted.org>


Change by Nikita Sobolev <mail at sobolevn.me>:


----------
keywords: +patch
nosy: +sobolevn
nosy_count: 1.0 -> 2.0
pull_requests: +29436
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31274

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46711>
_______________________________________

From report at bugs.python.org  Fri Feb 11 05:41:15 2022
From: report at bugs.python.org (Erlend E. Aasland)
Date: Fri, 11 Feb 2022 10:41:15 +0000
Subject: =?utf-8?q?=5Bissue39355=5D_The_Python_library_will_not_compile_with_a_C++?=
 =?utf-8?q?2020_compiler_because_the_code_uses_the_reserved_=E2=80=9Cmodul?=
 =?utf-8?b?ZeKAnSBrZXl3b3Jk?=
In-Reply-To: <1579166721.74.0.203064876936.issue39355@roundup.psfhosted.org>
Message-ID: <1644576075.98.0.345811395963.issue39355@roundup.psfhosted.org>


Erlend E. Aasland <erlend.aasland at innova.no> added the comment:

> There will be huge changes for this issue as this keyword has been used in a lot of places.

It should be sufficient to change only the exposed headers; that is Include/*.h and Include/cpython/*.h. We should also change the AC tool, since that may be used by external projects.

----------
nosy: +erlendaasland

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39355>
_______________________________________

From report at bugs.python.org  Fri Feb 11 05:41:58 2022
From: report at bugs.python.org (Erlend E. Aasland)
Date: Fri, 11 Feb 2022 10:41:58 +0000
Subject: =?utf-8?q?=5Bissue39355=5D_The_Python_library_will_not_compile_with_a_C++?=
 =?utf-8?q?2020_compiler_because_the_code_uses_the_reserved_=E2=80=9Cmodul?=
 =?utf-8?b?ZeKAnSBrZXl3b3Jk?=
In-Reply-To: <1579166721.74.0.203064876936.issue39355@roundup.psfhosted.org>
Message-ID: <1644576118.54.0.605438329932.issue39355@roundup.psfhosted.org>


Change by Erlend E. Aasland <erlend.aasland at innova.no>:


----------
Removed message: https://bugs.python.org/msg413055

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39355>
_______________________________________

From report at bugs.python.org  Fri Feb 11 05:42:11 2022
From: report at bugs.python.org (Erlend E. Aasland)
Date: Fri, 11 Feb 2022 10:42:11 +0000
Subject: =?utf-8?q?=5Bissue39355=5D_The_Python_library_will_not_compile_with_a_C++?=
 =?utf-8?q?2020_compiler_because_the_code_uses_the_reserved_=E2=80=9Cmodul?=
 =?utf-8?b?ZeKAnSBrZXl3b3Jk?=
In-Reply-To: <1579166721.74.0.203064876936.issue39355@roundup.psfhosted.org>
Message-ID: <1644576131.55.0.37080296307.issue39355@roundup.psfhosted.org>


Erlend E. Aasland <erlend.aasland at innova.no> added the comment:

> There will be huge changes for this issue as this keyword has been used in a lot of places.

For external extension modules, it should be sufficient to change only the exposed headers; that is Include/*.h and Include/cpython/*.h. We should also change the AC tool, since that may be used by external projects.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39355>
_______________________________________

From report at bugs.python.org  Fri Feb 11 06:03:34 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Fri, 11 Feb 2022 11:03:34 +0000
Subject: [issue46709] test_urllib: testInterruptCaught() has a race condition
 and fails randomly
In-Reply-To: <1644494656.37.0.2113700788.issue46709@roundup.psfhosted.org>
Message-ID: <1644577414.16.0.921315694566.issue46709@roundup.psfhosted.org>


Kumar Aditya <rahuladitya303 at gmail.com> added the comment:

Same issue as https://bugs.python.org/issue46465, PR https://github.com/python/cpython/pull/30826 fixes this.

----------
nosy: +kumaraditya303

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46709>
_______________________________________

From report at bugs.python.org  Fri Feb 11 06:25:49 2022
From: report at bugs.python.org (Petr Viktorin)
Date: Fri, 11 Feb 2022 11:25:49 +0000
Subject: [issue46433] _PyType_GetModuleByDef optimization is incorrect
In-Reply-To: <1642607197.61.0.0970144809853.issue46433@roundup.psfhosted.org>
Message-ID: <1644578749.34.0.411852581485.issue46433@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:


New changeset 8b8673fe940c4ebc4512bff5af180b66def3d1ae by Petr Viktorin in branch '3.10':
[3.10] bpo-46433: _PyType_GetModuleByDef: handle static types in MRO (GH-30696) (GH-31262)
https://github.com/python/cpython/commit/8b8673fe940c4ebc4512bff5af180b66def3d1ae


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46433>
_______________________________________

From report at bugs.python.org  Fri Feb 11 06:26:15 2022
From: report at bugs.python.org (Petr Viktorin)
Date: Fri, 11 Feb 2022 11:26:15 +0000
Subject: [issue46433] _PyType_GetModuleByDef optimization is incorrect
In-Reply-To: <1642607197.61.0.0970144809853.issue46433@roundup.psfhosted.org>
Message-ID: <1644578775.89.0.00956383818418.issue46433@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/issue46433>
_______________________________________

From report at bugs.python.org  Fri Feb 11 06:31:07 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Fri, 11 Feb 2022 11:31:07 +0000
Subject: [issue44525] Implement CALL_FUNCTION adaptive interpreter
 optimizations
In-Reply-To: <1624890138.2.0.824780513801.issue44525@roundup.psfhosted.org>
Message-ID: <1644579067.35.0.343005491175.issue44525@roundup.psfhosted.org>


Change by Nikita Sobolev <mail at sobolevn.me>:


----------
nosy: +sobolevn
nosy_count: 4.0 -> 5.0
pull_requests: +29437
pull_request: https://github.com/python/cpython/pull/31273

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44525>
_______________________________________

From report at bugs.python.org  Fri Feb 11 06:43:52 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Fri, 11 Feb 2022 11:43:52 +0000
Subject: [issue43216] Removal of @asyncio.coroutine in Python 3.11
In-Reply-To: <1613234875.25.0.783359316655.issue43216@roundup.psfhosted.org>
Message-ID: <1644579832.69.0.433694766403.issue43216@roundup.psfhosted.org>


Kumar Aditya <rahuladitya303 at gmail.com> added the comment:

Can this be closed now?

----------
nosy: +kumaraditya303

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43216>
_______________________________________

From report at bugs.python.org  Fri Feb 11 06:47:33 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 11 Feb 2022 11:47:33 +0000
Subject: [issue43216] Removal of @asyncio.coroutine in Python 3.11
In-Reply-To: <1613234875.25.0.783359316655.issue43216@roundup.psfhosted.org>
Message-ID: <1644580053.87.0.275130252281.issue43216@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Closed.
Thanks for the reminder!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43216>
_______________________________________

From report at bugs.python.org  Fri Feb 11 07:08:56 2022
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Fri, 11 Feb 2022 12:08:56 +0000
Subject: [issue46718] Feature: iptertools: add batches
Message-ID: <1644581336.38.0.660450208507.issue46718@roundup.psfhosted.org>


New submission from ???? ????????? <socketpair at gmail.com>:

I want a new function introduced in intertools. Something like this, but more optimal, and in C:

=======================
from itertools import chain, islice
from typing import Iterable, TypeVar

T = TypeVar('T')  # pylint: disable=invalid-name


def batches(items: Iterable[T], num: int) -> Iterable[Iterable[T]]:
    items = iter(items)
    while True:
        try:
            first_item = next(items)
        except StopIteration:
            break
        yield chain((first_item,), islice(items, 0, num - 1))
=======================

Splits big arrays to iterable chunks of fixed size (except the last one). Similar to `group_by`, but spawns new iterable group based on the group size.

For example, when passing many record to a database, passing one by one is obviously too slow. Passing all the records at once may increase latency. So, a good solution is to pass, say, 1000 records in one transaction. The smae in REST API batches.

P.S. Yes, I saw solution  https://docs.python.org/3/library/itertools.html#itertools-recipes `def grouper`, but it is not optimal for big `n` values.

----------
components: Library (Lib)
messages: 413061
nosy: socketpair
priority: normal
severity: normal
status: open
title: Feature: iptertools: add batches
type: enhancement
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46718>
_______________________________________

From report at bugs.python.org  Fri Feb 11 07:13:56 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Fri, 11 Feb 2022 12:13:56 +0000
Subject: [issue44011] Borrow asyncio ssl implementation from uvloop
In-Reply-To: <1619987620.01.0.201978044819.issue44011@roundup.psfhosted.org>
Message-ID: <1644581636.82.0.723722494706.issue44011@roundup.psfhosted.org>


Kumar Aditya <rahuladitya303 at gmail.com> added the comment:

Since it was reverted as it was beta period, Can this be committed again as 3.11 is in alpha currently?  @asvetlov

----------
nosy: +kumaraditya303

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44011>
_______________________________________

From report at bugs.python.org  Fri Feb 11 07:17:31 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Feb 2022 12:17:31 +0000
Subject: [issue46433] _PyType_GetModuleByDef optimization is incorrect
In-Reply-To: <1642607197.61.0.0970144809853.issue46433@roundup.psfhosted.org>
Message-ID: <1644581851.38.0.144776634934.issue46433@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> It also adds a precondition that's not feasible public API, which this was meant to become

Do you plan to make the function public? It would be nice!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46433>
_______________________________________

From report at bugs.python.org  Fri Feb 11 07:20:21 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Fri, 11 Feb 2022 12:20:21 +0000
Subject: [issue44011] Borrow asyncio ssl implementation from uvloop
In-Reply-To: <1619987620.01.0.201978044819.issue44011@roundup.psfhosted.org>
Message-ID: <1644582021.36.0.655861021658.issue44011@roundup.psfhosted.org>


Change by Kumar Aditya <rahuladitya303 at gmail.com>:


----------
pull_requests: +29438
pull_request: https://github.com/python/cpython/pull/31275

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44011>
_______________________________________

From report at bugs.python.org  Fri Feb 11 07:23:43 2022
From: report at bugs.python.org (Erlend E. Aasland)
Date: Fri, 11 Feb 2022 12:23:43 +0000
Subject: [issue46433] _PyType_GetModuleByDef optimization is incorrect
In-Reply-To: <1642607197.61.0.0970144809853.issue46433@roundup.psfhosted.org>
Message-ID: <1644582223.7.0.957478220107.issue46433@roundup.psfhosted.org>


Erlend E. Aasland <erlend.aasland at innova.no> added the comment:

> Do you plan to make the function public? It would be nice!

See https://github.com/python/cpython/pull/31081

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46433>
_______________________________________

From report at bugs.python.org  Fri Feb 11 07:23:49 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Fri, 11 Feb 2022 12:23:49 +0000
Subject: [issue44011] Borrow asyncio ssl implementation from uvloop
In-Reply-To: <1619987620.01.0.201978044819.issue44011@roundup.psfhosted.org>
Message-ID: <1644582229.7.0.884402116526.issue44011@roundup.psfhosted.org>


Kumar Aditya <rahuladitya303 at gmail.com> added the comment:

I created a draft PR by rebasing the old implementation of 3.10 for 3.11 so we can investigate the build-bots failure and fix them so this can be committed for 3.11.

See https://github.com/python/cpython/pull/31275

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44011>
_______________________________________

From report at bugs.python.org  Fri Feb 11 07:38:08 2022
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 11 Feb 2022 12:38:08 +0000
Subject: [issue44011] Borrow asyncio ssl implementation from uvloop
In-Reply-To: <1619987620.01.0.201978044819.issue44011@roundup.psfhosted.org>
Message-ID: <1644583088.99.0.125206366448.issue44011@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
nosy:  -christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44011>
_______________________________________

From report at bugs.python.org  Fri Feb 11 07:56:26 2022
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 11 Feb 2022 12:56:26 +0000
Subject: [issue46337] urllib.parse: Allow more flexibility in schemes and URL
 resolution behavior
In-Reply-To: <1641851456.34.0.342855463339.issue46337@roundup.psfhosted.org>
Message-ID: <1644584186.33.0.260301575851.issue46337@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> added the comment:

I remember a discussion about this years ago.
urllib is a module that pre-dates the idea of universal parsing for URIs, where the delimiters (like ://) are enough to determine the parts of a URI and give them meaning (host, port, user, path, etc).
Backward compat for urllib is always a concern; someone said at the time that it could be good to have a new module for modern, generic parsing, but that hasn?t happened.  Maybe a new parse function, or new parameter to the existing one, could be easier to add.

----------
nosy: +brett.cannon, eric.araujo, lukasz.langa, orsenthil
versions: +Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46337>
_______________________________________

From report at bugs.python.org  Fri Feb 11 07:59:13 2022
From: report at bugs.python.org (Alex Waygood)
Date: Fri, 11 Feb 2022 12:59:13 +0000
Subject: [issue46718] Feature: itertools: add batches
In-Reply-To: <1644581336.38.0.660450208507.issue46718@roundup.psfhosted.org>
Message-ID: <1644584353.73.0.85195368663.issue46718@roundup.psfhosted.org>


Change by Alex Waygood <Alex.Waygood at Gmail.com>:


----------
nosy: +rhettinger, tim.peters
title: Feature: iptertools: add batches -> Feature: itertools: add batches

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46718>
_______________________________________

From report at bugs.python.org  Fri Feb 11 08:08:16 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Fri, 11 Feb 2022 13:08:16 +0000
Subject: [issue44011] Borrow asyncio ssl implementation from uvloop
In-Reply-To: <1619987620.01.0.201978044819.issue44011@roundup.psfhosted.org>
Message-ID: <1644584896.73.0.579372812152.issue44011@roundup.psfhosted.org>


Change by Kumar Aditya <rahuladitya303 at gmail.com>:


----------
versions: +Python 3.11 -Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44011>
_______________________________________

From report at bugs.python.org  Fri Feb 11 08:11:23 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 11 Feb 2022 13:11:23 +0000
Subject: [issue46718] Feature: itertools: add batches
In-Reply-To: <1644581336.38.0.660450208507.issue46718@roundup.psfhosted.org>
Message-ID: <1644585083.75.0.85790313661.issue46718@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

For large n, I don't think a C implementation would do much better than your Python version where most of the work is done by chain() and islice() which are already in C.  The best that could be done is to eliminate the overhead of chain() which is likely about a third of the cost.

For smaller n, the grouper recipe is already very close to optimal.

----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46718>
_______________________________________

From report at bugs.python.org  Fri Feb 11 08:20:16 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Feb 2022 13:20:16 +0000
Subject: [issue46709] test_urllib: testInterruptCaught() has a race condition
 and fails randomly
In-Reply-To: <1644494656.37.0.2113700788.issue46709@roundup.psfhosted.org>
Message-ID: <1644585616.29.0.384299586984.issue46709@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Oops, I forgot about my own bpo-46465. I failed to find it when I searched for "test_urllib".

----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> Regression caused by CALL_FUNCTION specialization for C function calls

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46709>
_______________________________________

From report at bugs.python.org  Fri Feb 11 08:20:31 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Feb 2022 13:20:31 +0000
Subject: [issue46465] Regression caused by CALL_FUNCTION specialization for C
 function calls (test_urllib fails when run multiple times)
In-Reply-To: <1642815009.1.0.251080855194.issue46465@roundup.psfhosted.org>
Message-ID: <1644585631.48.0.0507481646837.issue46465@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: Regression caused by CALL_FUNCTION specialization for C function calls -> Regression caused by CALL_FUNCTION specialization for C function calls (test_urllib fails when run multiple times)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46465>
_______________________________________

From report at bugs.python.org  Fri Feb 11 08:29:14 2022
From: report at bugs.python.org (David Castells-Rufas)
Date: Fri, 11 Feb 2022 13:29:14 +0000
Subject: [issue46719] Call not visited in ast.NodeTransformer
Message-ID: <1644586154.7.0.293922264327.issue46719@roundup.psfhosted.org>


New submission from David Castells-Rufas <david.castells at uab.cat>:

If I create a class derived from ast.NodeTransformer and implement the visit_Call.
When run on the below code, the visit_Call function is only called once (for the print function, and not for ord). It looks like calls in function arguments are ignored.

def main():
    print(ord('A'))


On the other hand, on the following code it correctly visits both functions (print and ord).

def main():
    c = org('A')
    print(c)

----------
components: Library (Lib)
messages: 413069
nosy: davidcastells
priority: normal
severity: normal
status: open
title: Call not visited in ast.NodeTransformer
type: behavior
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46719>
_______________________________________

From report at bugs.python.org  Fri Feb 11 08:36:46 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Fri, 11 Feb 2022 13:36:46 +0000
Subject: [issue46119] Update bundled pip to 21.3.1 and setuptools to 59.7.0
Message-ID: <1644586606.84.0.602061651426.issue46119@roundup.psfhosted.org>


Change by Kumar Aditya <rahuladitya303 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/issue46119>
_______________________________________

From report at bugs.python.org  Fri Feb 11 08:40:39 2022
From: report at bugs.python.org (Batuhan Taskaya)
Date: Fri, 11 Feb 2022 13:40:39 +0000
Subject: [issue46719] Call not visited in ast.NodeTransformer
In-Reply-To: <1644586154.7.0.293922264327.issue46719@roundup.psfhosted.org>
Message-ID: <1644586839.18.0.144681409719.issue46719@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:

> It looks like calls in function arguments are ignored.

Please share a small, self-contained reproducer.

>From what I can assume by this message, the problem is that you are not calling self.generic_visit(node) on the first call you are handling. If you don't call visit/generic_visit on the rood node that you are handling (print(ord('A')), then it will never visit ord('A') in a standalone fashion.

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46719>
_______________________________________

From report at bugs.python.org  Fri Feb 11 08:48:50 2022
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 11 Feb 2022 13:48:50 +0000
Subject: [issue27777] cgi.FieldStorage can't parse simple body with
 Content-Length and no Content-Disposition
In-Reply-To: <1471355745.98.0.805545529346.issue27777@psf.upfronthosting.co.za>
Message-ID: <1644587330.62.0.233778119806.issue27777@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> added the comment:

Both active PRs have comments pointing out issues, that?s why this is still open.  A clean fix with unit tests and no regression is needed.

----------
nosy: +eric.araujo
versions: +Python 3.10, Python 3.11, Python 3.9 -Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27777>
_______________________________________

From report at bugs.python.org  Fri Feb 11 09:45:10 2022
From: report at bugs.python.org (Diego Ramirez)
Date: Fri, 11 Feb 2022 14:45:10 +0000
Subject: [issue33436] Add an interactive shell for Sqlite3
In-Reply-To: <1525657620.33.0.682650639539.issue33436@psf.upfronthosting.co.za>
Message-ID: <1644590710.3.0.189953823228.issue33436@roundup.psfhosted.org>


Diego Ramirez <dr01191115 at gmail.com> added the comment:

Do we still want to do this? See https://discuss.python.org/t/titling-sqlite3-table-columns-with-number/13656/3.

----------
nosy: +DiddiLeija
versions: +Python 3.10, Python 3.11, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33436>
_______________________________________

From report at bugs.python.org  Fri Feb 11 09:57:09 2022
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Fri, 11 Feb 2022 14:57:09 +0000
Subject: [issue46720] Add support of path-like objects to
 multiprocessing.set_executable for Windows to match Unix-like systems
Message-ID: <1644591429.6.0.540789984747.issue46720@roundup.psfhosted.org>


New submission from G?ry <gery.ogam at gmail.com>:

Any [path-like object](https://docs.python.org/3/glossary.html) can be passed to `multiprocessing.set_executable`, i.e. objects with `str`, `bytes`, or `os.PathLike` type.

For instance these work (tested on MacOS with all start methods: ?spawn?, ?fork?, and ?forkserver?):

- `multiprocessing.set_executable(sys.executable)` (`str`);
- `multiprocessing.set_executable(sys.executable.encode())` (`bytes`);
- `multiprocessing.set_executable(pathlib.Path(sys.executable))` (`os.PathLike`).

This is because the ?fork? start method does not exec any program in the subprocess, the ?spawn? start method converts its path argument to `bytes` with `os.fsencode` before passing to [`_posixsubprocess.fork_exec`](https://github.com/python/cpython/blob/v3.10.2/Lib/multiprocessing/util.py#L452-L455), and the ?forkserver? start method spawns a server process (like with the ?spawn? start method) which then forks itself at each request (like the ?fork? start method):

```
        return _posixsubprocess.fork_exec(
            args, [os.fsencode(path)], True, passfds, None, None,
            -1, -1, -1, -1, -1, -1, errpipe_read, errpipe_write,
            False, False, None, None, None, -1, None)
```

Linux (and other Unix-like systems) uses the same code than MacOS for the three start methods so it should work for it too.

However I have not tested this on Windows which uses the function [`_winapi.CreateProcess`](https://github.com/python/cpython/blob/v3.10.2/Lib/multiprocessing/popen_spawn_win32.py#L73-L75) for the ?spawn? start method (the only start method available on this OS) but I noticed that no conversion to `str` (not to `bytes` this time, since [the function expects `str`](https://github.com/python/cpython/blob/v3.10.2/Modules/_winapi.c#L1049)) of the path argument with `os.fsdecode` (not `os.fsencode` this time) is performed before passing it to the function:

```
                hp, ht, pid, tid = _winapi.CreateProcess(
                    python_exe, cmd,
                    None, None, False, 0, env, None, None)
```

So on Windows only `str` path can be passed to `multiprocessing.set_executable`. This PR fixes this to be on a par with Unix-like systems which accept any path-like objects.

----------
components: Library (Lib)
messages: 413073
nosy: maggyero
priority: normal
severity: normal
status: open
title: Add support of path-like objects to multiprocessing.set_executable for Windows to match Unix-like systems
versions: Python 3.10, Python 3.11, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46720>
_______________________________________

From report at bugs.python.org  Fri Feb 11 09:57:24 2022
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Fri, 11 Feb 2022 14:57:24 +0000
Subject: [issue46720] Add support of path-like objects to
 multiprocessing.set_executable for Windows to match Unix-like systems
In-Reply-To: <1644591429.6.0.540789984747.issue46720@roundup.psfhosted.org>
Message-ID: <1644591444.62.0.833759135736.issue46720@roundup.psfhosted.org>


Change by G?ry <gery.ogam at gmail.com>:


----------
keywords: +patch
pull_requests: +29439
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31279

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46720>
_______________________________________

From report at bugs.python.org  Fri Feb 11 10:01:10 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Feb 2022 15:01:10 +0000
Subject: [issue46705] Memory optimization for set.issubset
In-Reply-To: <1644456286.75.0.570469463639.issue46705@roundup.psfhosted.org>
Message-ID: <1644591670.31.0.909411378624.issue46705@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

See also issue18032.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46705>
_______________________________________

From report at bugs.python.org  Fri Feb 11 10:15:23 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Feb 2022 15:15:23 +0000
Subject: [issue46721] Optimize set.issuperset() for non-set argument
Message-ID: <1644592523.91.0.460084742995.issue46721@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

If the argument of set.issuperset() is not a set, it is first converted to a set. It is equivalent to the following code:

    if not isinstance(other, (set, frozenset)):
        other = set(other)
    # The following is equivalent to:
    # return set.issubset(other, self)
    for x in other:
        if x not in self
            return False
    return True

Two drawbacks of this algorithm:

1. It creates a new set, which takes O(len(other)) time and consumes O(len(set(other))) memory.
2. It needs to iterate other to the end, even if the result is known earlier.

The proposed PR straightforward the code. The C code is now larger, but it no longer need additional memory, performs less operations and can stop earlier.

----------
components: Interpreter Core
messages: 413075
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Optimize set.issuperset() for non-set argument
type: performance
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46721>
_______________________________________

From report at bugs.python.org  Fri Feb 11 10:17:17 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Feb 2022 15:17:17 +0000
Subject: [issue46721] Optimize set.issuperset() for non-set argument
In-Reply-To: <1644592523.91.0.460084742995.issue46721@roundup.psfhosted.org>
Message-ID: <1644592637.95.0.228929169814.issue46721@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +29440
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31280

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46721>
_______________________________________

From report at bugs.python.org  Fri Feb 11 10:23:35 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Feb 2022 15:23:35 +0000
Subject: [issue46721] Optimize set.issuperset() for non-set argument
In-Reply-To: <1644592523.91.0.460084742995.issue46721@roundup.psfhosted.org>
Message-ID: <1644593015.03.0.0887266937742.issue46721@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The new code is similar to the code of set.isdisjoint(), so we can share the code if generalize it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46721>
_______________________________________

From report at bugs.python.org  Fri Feb 11 10:26:49 2022
From: report at bugs.python.org (Iliya Zinoviev)
Date: Fri, 11 Feb 2022 15:26:49 +0000
Subject: [issue46722] Different behavior for functiools.partial between
 inspect.isfunction() and other inspect.is*function()
Message-ID: <1644593209.5.0.742878484415.issue46722@roundup.psfhosted.org>


New submission from Iliya Zinoviev <mrmar333 at yandex.ru>:

1) isfunction() returns `True` for partial object only when one passes `func` attribute of it.
2) For instance, `isgeneratorfunction()` and `iscoroutinefunction()` for partial obj work with passing partial obj as well as with passing `func` attr of this obj, when obj is partially applied generator function or partially applied coroutine function respectively.

I offer to unify behavior for handling partial object for r'inspect.is*function()' by the next way:
1) Add `functools._unwrap_partial()` to `inspect.isfunction()` as well as it were done in other r'inspect.is*function()'.

P.S.I'm ready to deal with this issue.  

Python 3.10.2 (main, Jan 15 2022, 19:56:27) [GCC 11.1.0]
Type 'copyright', 'credits' or 'license' for more information

Operating System: Manjaro Linux
KDE Plasma Version: 5.23.5
KDE Frameworks Version: 5.90.0
Qt Version: 5.15.2
Kernel Version: 5.4.176-1-MANJARO (64-bit)
Graphics Platform: X11
Processors: 4 ? Intel? Core? i5-6200U CPU @ 2.30GHz
Memory: 11.6 GiB of RAM
Graphics Processor: Mesa Intel? HD Graphics 520

----------
components: Library (Lib)
files: isfuncs_behavior.py
messages: 413077
nosy: IliyaZinoviev
priority: normal
severity: normal
status: open
title: Different behavior for functiools.partial between inspect.isfunction() and other inspect.is*function()
type: behavior
versions: Python 3.10
Added file: https://bugs.python.org/file50621/isfuncs_behavior.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46722>
_______________________________________

From report at bugs.python.org  Fri Feb 11 10:37:28 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Fri, 11 Feb 2022 15:37:28 +0000
Subject: [issue46677] TypedDict docs are incomplete
In-Reply-To: <1644262079.95.0.663870450502.issue46677@roundup.psfhosted.org>
Message-ID: <1644593848.2.0.869580002327.issue46677@roundup.psfhosted.org>


Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:

Please do submit a PR! Agree that more examples of inheritance and attributes would be useful.

Note that we're about to deprecate the keyword argument syntax (issue46066).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46677>
_______________________________________

From report at bugs.python.org  Fri Feb 11 10:40:11 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Feb 2022 15:40:11 +0000
Subject: [issue46721] Optimize set.issuperset() for non-set argument
In-Reply-To: <1644592523.91.0.460084742995.issue46721@roundup.psfhosted.org>
Message-ID: <1644594010.99.0.125170864707.issue46721@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
dependencies: +Use-after-free by mutating set during set operations

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46721>
_______________________________________

From report at bugs.python.org  Fri Feb 11 11:01:26 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Feb 2022 16:01:26 +0000
Subject: [issue45490] [C API] PEP 670: Convert macros to functions in the
 Python C API
In-Reply-To: <1634319805.82.0.902360778503.issue45490@roundup.psfhosted.org>
Message-ID: <1644595286.96.0.909690954509.issue45490@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset e0bcfd0e4db193743d4bafc48d10f15ae9ed7b2b by Victor Stinner in branch 'main':
bpo-45490: Rename static inline functions (GH-31217)
https://github.com/python/cpython/commit/e0bcfd0e4db193743d4bafc48d10f15ae9ed7b2b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45490>
_______________________________________

From report at bugs.python.org  Fri Feb 11 11:08:12 2022
From: report at bugs.python.org (Eddie Elizondo)
Date: Fri, 11 Feb 2022 16:08:12 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting and
 immortal objects
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1644595692.63.0.282675633279.issue40255@roundup.psfhosted.org>


Eddie Elizondo <eduardo.elizondorueda at gmail.com> added the comment:

@eric.snow great to hear about this update! I'll start looking at some of the techniques that we talked about to improve performance, I'm optimistic that we'll be able to close down the gap to 2%.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Fri Feb 11 11:13:53 2022
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=)
Date: Fri, 11 Feb 2022 16:13:53 +0000
Subject: [issue40379] multiprocessing's default start method of
 fork()-without-exec() is broken
In-Reply-To: <1587752543.41.0.119768714545.issue40379@roundup.psfhosted.org>
Message-ID: <1644596033.88.0.0690722690434.issue40379@roundup.psfhosted.org>


Micha? G?rny <mgorny at gentoo.org> added the comment:

After updating PyPy3 to use Python 3.9's stdlib, we hit very bad hangs because of this ? literally compiling a single file with "parallel" compileall could hang.  In the end, we had to revert the change in how Python 3.9 starts workers because otherwise multiprocessing would be impossible to use:

https://foss.heptapod.net/pypy/pypy/-/commit/c594b6c48a48386e8ac1f3f52d4b82f9c3e34784

This is a very bad default and what's even worse is that it often causes deadlocks that are hard to reproduce or debug.  Furthermore, since "fork" is the default, people are unintentionally relying on its support for passing non-pickleable projects and are creating non-portable code.  The code often becomes complex and hard to change before they discover the problem.

Before we managed to figure out how to workaround the deadlocks in PyPy3, we were experimenting with switching the default to "spawn".  Unfortunately, we've hit multiple projects that didn't work with this method, precisely because of pickling problems.  Furthermore, they were surprised to learn that their code wouldn't work on macOS (in the end, many people perceive Python as a language for writing portable software).

Finally, back in 2018 I've made one of my projects do parallel work using multiprocessing.  It gave its users great speedup but for some it caused deadlocks that I couldn't reproduce nor debug.  In the end, I had to revert it.  Now that I've learned about this problem, I'm wondering if this wasn't precisely because of "fork" method.

----------
nosy: +mgorny

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40379>
_______________________________________

From report at bugs.python.org  Fri Feb 11 11:16:33 2022
From: report at bugs.python.org (Dennis Sweeney)
Date: Fri, 11 Feb 2022 16:16:33 +0000
Subject: [issue44953] Add vectorcall on operator.itemgetter and attrgetter
 objects
In-Reply-To: <1629365029.54.0.100452744635.issue44953@roundup.psfhosted.org>
Message-ID: <1644596193.9.0.88612048069.issue44953@roundup.psfhosted.org>


Change by Dennis Sweeney <sweeney.dennis650 at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44953>
_______________________________________

From report at bugs.python.org  Fri Feb 11 11:22:16 2022
From: report at bugs.python.org (Petr Viktorin)
Date: Fri, 11 Feb 2022 16:22:16 +0000
Subject: [issue46613] Add PyType_GetModuleByDef to the public & limited API
In-Reply-To: <1643820922.83.0.000906972876287.issue46613@roundup.psfhosted.org>
Message-ID: <1644596536.39.0.102830807479.issue46613@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:


New changeset 204946986feee7bc80b233350377d24d20fcb1b8 by Petr Viktorin in branch 'main':
bpo-46613: Add PyType_GetModuleByDef to the public API (GH-31081)
https://github.com/python/cpython/commit/204946986feee7bc80b233350377d24d20fcb1b8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46613>
_______________________________________

From report at bugs.python.org  Fri Feb 11 11:22:47 2022
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Fri, 11 Feb 2022 16:22:47 +0000
Subject: [issue46720] Add support of path-like objects to
 multiprocessing.set_executable for Windows to match Unix-like systems
In-Reply-To: <1644591429.6.0.540789984747.issue46720@roundup.psfhosted.org>
Message-ID: <1644596567.08.0.483451910185.issue46720@roundup.psfhosted.org>


Change by G?ry <gery.ogam at gmail.com>:


----------
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46720>
_______________________________________

From report at bugs.python.org  Fri Feb 11 11:23:15 2022
From: report at bugs.python.org (Petr Viktorin)
Date: Fri, 11 Feb 2022 16:23:15 +0000
Subject: [issue46613] Add PyType_GetModuleByDef to the public & limited API
In-Reply-To: <1643820922.83.0.000906972876287.issue46613@roundup.psfhosted.org>
Message-ID: <1644596595.14.0.153636175937.issue46613@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

It's in public API, adding it to limited is still pending.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46613>
_______________________________________

From report at bugs.python.org  Fri Feb 11 11:24:18 2022
From: report at bugs.python.org (Lincoln Auster)
Date: Fri, 11 Feb 2022 16:24:18 +0000
Subject: [issue46337] urllib.parse: Allow more flexibility in schemes and URL
 resolution behavior
In-Reply-To: <1644584186.33.0.260301575851.issue46337@roundup.psfhosted.org>
Message-ID: <YgaNrNvvDPmK0Rgt@desktop.marx>


Lincoln Auster <lincolnauster at gmail.com> added the comment:

> Maybe a new parse function, or new parameter to the existing one,
> could be easier to add.

If I'm understanding you right, that's what this (and the PR) is - an
extra optional parameter to urllib.parse to supplement the existing
(legacy?) hard-coded list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46337>
_______________________________________

From report at bugs.python.org  Fri Feb 11 11:24:18 2022
From: report at bugs.python.org (Iliya Zinoviev)
Date: Fri, 11 Feb 2022 16:24:18 +0000
Subject: [issue46722] Different behavior for functiools.partial between
 inspect.isfunction() and other inspect.is*function()
In-Reply-To: <1644593209.5.0.742878484415.issue46722@roundup.psfhosted.org>
Message-ID: <1644596658.97.0.648982181011.issue46722@roundup.psfhosted.org>


Change by Iliya Zinoviev <mrmar333 at yandex.ru>:


Added file: https://bugs.python.org/file50622/isfuncs_behavior.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46722>
_______________________________________

From report at bugs.python.org  Fri Feb 11 11:24:32 2022
From: report at bugs.python.org (Iliya Zinoviev)
Date: Fri, 11 Feb 2022 16:24:32 +0000
Subject: [issue46722] Different behavior for functiools.partial between
 inspect.isfunction() and other inspect.is*function()
In-Reply-To: <1644593209.5.0.742878484415.issue46722@roundup.psfhosted.org>
Message-ID: <1644596672.92.0.00759030122543.issue46722@roundup.psfhosted.org>


Change by Iliya Zinoviev <mrmar333 at yandex.ru>:


Removed file: https://bugs.python.org/file50622/isfuncs_behavior.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46722>
_______________________________________

From report at bugs.python.org  Fri Feb 11 11:25:17 2022
From: report at bugs.python.org (Dennis Sweeney)
Date: Fri, 11 Feb 2022 16:25:17 +0000
Subject: [issue46615] Use-after-free by mutating set during set operations
In-Reply-To: <1643824882.75.0.278611227582.issue46615@roundup.psfhosted.org>
Message-ID: <1644596717.76.0.178752252114.issue46615@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:


New changeset 4a66615ba736f84eadf9456bfd5d32a94cccf117 by Dennis Sweeney in branch 'main':
bpo-46615: Don't crash when set operations mutate the sets (GH-31120)
https://github.com/python/cpython/commit/4a66615ba736f84eadf9456bfd5d32a94cccf117


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46615>
_______________________________________

From report at bugs.python.org  Fri Feb 11 11:29:50 2022
From: report at bugs.python.org (Eric Snow)
Date: Fri, 11 Feb 2022 16:29:50 +0000
Subject: [issue46541] Replace _Py_IDENTIFIER() with statically initialized
 objects.
In-Reply-To: <1644568585.0.0.541114039344.issue46541@roundup.psfhosted.org>
Message-ID: <CALFfu7CqB1oYMqnkPcb=oA6hTg05BqLQ=Ho0xbDKCwqpJovt7Q@mail.gmail.com>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

On Fri, Feb 11, 2022 at 1:36 AM Christoph Reiter <report at bugs.python.org> wrote:
> Sorry if off topic, but I noticed that CPython doesn't deprecate macros in code, while with gcc/clang it's possible to show compiler warnings for them using some pragma magic:
> [snip]
> Maybe that makes getting rid of them easier in the long run?

That's a good question.  We do have Py_DEPRECATED() (in
Include/pyport.h), which is used for symbols.  I'm not sure anyone has
given much thought to deprecating macros, but it's probably worth
considering.  I recommend that you post something about this to
python-dev at python.org.

FWIW, here are other explanations of how to deprecate macros:

* https://stackoverflow.com/questions/57478368/what-is-the-best-way-to-mark-macro-as-deprecated/57479189#57479189
* https://stackoverflow.com/questions/2681259/how-to-deprecate-a-c-pre-processor-macro-in-gcc/29297970#29297970

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46541>
_______________________________________

From report at bugs.python.org  Fri Feb 11 11:37:38 2022
From: report at bugs.python.org (Alex Waygood)
Date: Fri, 11 Feb 2022 16:37:38 +0000
Subject: [issue46483] `pathlib.PurePath.__class_getitem__` does not return
 `GenericAlias`
In-Reply-To: <1642925790.59.0.879604059643.issue46483@roundup.psfhosted.org>
Message-ID: <1644597458.1.0.226235273128.issue46483@roundup.psfhosted.org>


Change by Alex Waygood <Alex.Waygood at Gmail.com>:


----------
pull_requests: +29441
pull_request: https://github.com/python/cpython/pull/31281

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46483>
_______________________________________

From report at bugs.python.org  Fri Feb 11 12:12:33 2022
From: report at bugs.python.org (Antony Cardazzi)
Date: Fri, 11 Feb 2022 17:12:33 +0000
Subject: [issue46723] SimpleQueue.put_nowait() documentation error
Message-ID: <1644599553.87.0.456089916352.issue46723@roundup.psfhosted.org>


New submission from Antony Cardazzi <antonycardazzi at gmail.com>:

SimpleQueue.put_nowait(item) documentation says it is equivalent to SimpleQueue.put(item) when it's actually equivalent to Simple que.put(item, block=False)

----------
assignee: docs at python
components: Documentation
messages: 413087
nosy: antonycardazzi, docs at python
priority: normal
severity: normal
status: open
title: SimpleQueue.put_nowait() documentation error
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46723>
_______________________________________

From report at bugs.python.org  Fri Feb 11 12:22:26 2022
From: report at bugs.python.org (Saul Shanabrook)
Date: Fri, 11 Feb 2022 17:22:26 +0000
Subject: [issue46724] Odd Bytecode Generation in 3.10
Message-ID: <1644600146.24.0.968453673832.issue46724@roundup.psfhosted.org>


New submission from Saul Shanabrook <s.shanabrook at gmail.com>:

I noticed that in Python 3.10, and also in main, a certain control flow construct produces some very odd bytecode (showing on main but same on python 3.10 tags):

```
./python.exe -c 'import dis; dis.dis("while not (a < b < c): pass")'
              0 RESUME                   0

  1           2 LOAD_NAME                0 (a)
              4 LOAD_NAME                1 (b)
              6 SWAP                     2
              8 COPY                     2
             10 COMPARE_OP               0 (<)
             12 POP_JUMP_IF_FALSE       11 (to 22)
             14 LOAD_NAME                2 (c)
             16 COMPARE_OP               0 (<)
             18 POP_JUMP_IF_TRUE        28 (to 56)
             20 JUMP_FORWARD             1 (to 24)
        >>   22 POP_TOP
        >>   24 LOAD_NAME                0 (a)
             26 LOAD_NAME                1 (b)
             28 SWAP                     2
             30 COPY                     2
             32 COMPARE_OP               0 (<)
             34 POP_JUMP_IF_FALSE       23 (to 46)
             36 LOAD_NAME                2 (c)
             38 COMPARE_OP               0 (<)
             40 POP_JUMP_IF_FALSE       12 (to 24)
             42 LOAD_CONST               0 (None)
             44 RETURN_VALUE
        >>   46 POP_TOP
             48 EXTENDED_ARG           255
             50 EXTENDED_ARG         65535
             52 EXTENDED_ARG         16777215
             54 JUMP_FORWARD         4294967280 (to 8589934616)
        >>   56 LOAD_CONST               0 (None)
             58 RETURN_VALUE
```

The last JUMP_FORWARD has a rather larger argument! This was the minimal example I could find to replicate this.

However, this is an example of some runnable code that also encounters it:

```
a = b = c = 1
while not (a < b < c):
    if c == 1:
        c = 3
    else:
        b = 2
    print(a, b, c)
```

This actually executes fine, but I notice that when it's executing it does execute that very large arg, but that the `oparg` to JUMP_FORWARD ends up being negative! By adding some tracing, I was able to see that the `oparg` variable in the `TARGET(JUMP_FORWARD)` case is `-32`.

I am not sure if this is a bug or intended behavior. It does seem a bit odd to have this unnecessarily large argument that ends up turning into a negative jump! But the behavior seems fine.

At the least, maybe `dis` should be modified so that it properly sees this as a negative jump and debugs it properly? I am happy to submit a PR to modify `dis` to handle this case, but I also wanted to flag that maybe it's a bug to being with.

----------
components: Interpreter Core
messages: 413088
nosy: saulshanabrook
priority: normal
severity: normal
status: open
title: Odd Bytecode Generation in 3.10
versions: Python 3.10, Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46724>
_______________________________________

From report at bugs.python.org  Fri Feb 11 12:28:41 2022
From: report at bugs.python.org (Hasan)
Date: Fri, 11 Feb 2022 17:28:41 +0000
Subject: =?utf-8?q?=5Bissue39355=5D_The_Python_library_will_not_compile_with_a_C++?=
 =?utf-8?q?2020_compiler_because_the_code_uses_the_reserved_=E2=80=9Cmodul?=
 =?utf-8?b?ZeKAnSBrZXl3b3Jk?=
In-Reply-To: <1579166721.74.0.203064876936.issue39355@roundup.psfhosted.org>
Message-ID: <1644600521.26.0.861823763268.issue39355@roundup.psfhosted.org>


Change by Hasan <hasan.aleeyev at gmail.com>:


----------
pull_requests: +29442
pull_request: https://github.com/python/cpython/pull/31282

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39355>
_______________________________________

From report at bugs.python.org  Fri Feb 11 12:33:07 2022
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 11 Feb 2022 17:33:07 +0000
Subject: [issue46724] Odd Bytecode Generation in 3.10
In-Reply-To: <1644600146.24.0.968453673832.issue46724@roundup.psfhosted.org>
Message-ID: <1644600787.08.0.916738386317.issue46724@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +Mark.Shannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46724>
_______________________________________

From report at bugs.python.org  Fri Feb 11 13:10:30 2022
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 11 Feb 2022 18:10:30 +0000
Subject: [issue46725] Unpacking without parentheses is allowed since 3.9
Message-ID: <1644603030.68.0.559962279778.issue46725@roundup.psfhosted.org>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

Seems that this is allowed since the PEG parser rewrite:

for x in *a, *b:
    print(x)

but I cannot find anywhere were we discussed this. I am not sure if we should keep it or treat it as a bug and fix it.

----------
components: Parser
messages: 413089
nosy: BTaskaya, gvanrossum, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Unpacking without parentheses is allowed since 3.9
versions: Python 3.10, Python 3.11, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46725>
_______________________________________

From report at bugs.python.org  Fri Feb 11 13:13:13 2022
From: report at bugs.python.org (Batuhan Taskaya)
Date: Fri, 11 Feb 2022 18:13:13 +0000
Subject: [issue46725] Unpacking without parentheses is allowed since 3.9
In-Reply-To: <1644603030.68.0.559962279778.issue46725@roundup.psfhosted.org>
Message-ID: <1644603193.97.0.662000255574.issue46725@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:

Since this was already allowed in 3.9 and 3.10 stable relases, and since it is consistent with the RHS of an assignment (something = *a, *b); I'd lean towards keeping it (and maybe fixing the old parser's grammar to reflect that) and documenting this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46725>
_______________________________________

From report at bugs.python.org  Fri Feb 11 13:13:35 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Fri, 11 Feb 2022 18:13:35 +0000
Subject: [issue46725] Unpacking without parentheses is allowed since 3.9
In-Reply-To: <1644603030.68.0.559962279778.issue46725@roundup.psfhosted.org>
Message-ID: <1644603215.22.0.852465550571.issue46725@roundup.psfhosted.org>


Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:

I'd lean towards keeping this syntax:
- It's already been out for two releases, so there's user code out there relying on it. (In fact we found out about this because somebody complained that Black's parser couldn't handle this code.)
- The syntax isn't obviously confusing and the meaning is clear.
- It's not hard to parse; it was easy to adjust Black's parser to allow it.

----------
nosy: +Jelle Zijlstra

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46725>
_______________________________________

From report at bugs.python.org  Fri Feb 11 13:17:41 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 11 Feb 2022 18:17:41 +0000
Subject: [issue46721] Optimize set.issuperset() for non-set argument
In-Reply-To: <1644592523.91.0.460084742995.issue46721@roundup.psfhosted.org>
Message-ID: <1644603461.35.0.470838606005.issue46721@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/issue46721>
_______________________________________

From report at bugs.python.org  Fri Feb 11 13:36:36 2022
From: report at bugs.python.org (Erlend E. Aasland)
Date: Fri, 11 Feb 2022 18:36:36 +0000
Subject: [issue46725] Unpacking without parentheses is allowed since 3.9
In-Reply-To: <1644603030.68.0.559962279778.issue46725@roundup.psfhosted.org>
Message-ID: <1644604596.45.0.194382200228.issue46725@roundup.psfhosted.org>


Erlend E. Aasland <erlend.aasland at innova.no> added the comment:

+1 (what Jelle said)

----------
nosy: +erlendaasland

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46725>
_______________________________________

From report at bugs.python.org  Fri Feb 11 13:54:05 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Fri, 11 Feb 2022 18:54:05 +0000
Subject: [issue46724] Odd Bytecode Generation in 3.10
In-Reply-To: <1644600146.24.0.968453673832.issue46724@roundup.psfhosted.org>
Message-ID: <1644605645.14.0.503142116569.issue46724@roundup.psfhosted.org>


Change by Jelle Zijlstra <jelle.zijlstra at gmail.com>:


----------
nosy: +Jelle Zijlstra

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46724>
_______________________________________

From report at bugs.python.org  Fri Feb 11 13:55:55 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 11 Feb 2022 18:55:55 +0000
Subject: [issue46713] Provide a C implementation of collections.abc.KeysView
 and friends
In-Reply-To: <1644520785.16.0.447466630814.issue46713@roundup.psfhosted.org>
Message-ID: <1644605755.51.0.150706496764.issue46713@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Some thoughts:

* Other than set operations, most of the pure python code in the dict view ABCs are fast pass throughs.  There is no point in rewriting these in C:

    def __contains__(self, key):
        return key in self._mapping

    def __iter__(self):
        yield from self._mapping

    def __len__(self):
        return len(self._mapping)

* For the set operations, the pure python code has only a simple for-loop and contains test.  There isn't much fat to be cut:

    def __ge__(self, other):
        if not isinstance(other, Set):
            return NotImplemented
        if len(self) < len(other):
            return False
        for elem in other:
            if elem not in self:
                return False
        return True

* Possibly the eval-loop overhead can be eliminated with Python by using itertools:

    def __ge__(self, other):
        if not isinstance(other, Set):
            return NotImplemented
        if len(self) < len(other):
            return False
        for elem in filterfalse(self.__contains__, other):
            return False
        return True

* That leaves the question of why the dict views are so much faster (presuming that the posted timings are representative).  I haven't looked in detail, but the first candidate that comes to mind is that dictviews_to_set() has a fast path for exact dicts.  That lets it bypass the mapping proxy and exploit the fast path in PySet_New for exact dicts.  That fast path reuses the stored hash values and exploits knowing that the input has no duplicates.  Off-hand, I don't see how that can generalize to the arbitrary mappings supports by the view ABCs.  

* Summary:  A first look, it doesn't seem like a C rewrite of the view ABCs would bear fruit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46713>
_______________________________________

From report at bugs.python.org  Fri Feb 11 14:22:33 2022
From: report at bugs.python.org (Gregory Beauregard)
Date: Fri, 11 Feb 2022 19:22:33 +0000
Subject: [issue46511] dataclasses: Allow typing.Annotated to wrap
 dataclasses-specific annotations
In-Reply-To: <1643101368.65.0.575407689959.issue46511@roundup.psfhosted.org>
Message-ID: <1644607353.75.0.951716063406.issue46511@roundup.psfhosted.org>


Gregory Beauregard <greg at greg.red> added the comment:

It occurred to be that we do need to add the __call__ to KW_ONLY, but for a different reason than this bpo:

If you call get_type_hints on a dataclass with a KW_ONLY parameter when PEP 563 is enabled, the entire call will fail if KW_ONLY isn't callable(). This can also happen if you stringize KW_ONLY without PEP 563. I made a bpo to suggest removing the callable() check entirely, but it's waiting discussion currently: https://bugs.python.org/issue46644

My feeling is you probably wanted to wait on making changes of this kind for the 5.11 PEP 563 et al decision to play out, but on the other hand I think the KW_ONLY (and similar __call__ method for InitVar this patch already adds) change would likely be backportable so we may want to make them anyway for that purpose. Do you have an opinion on this?

This patch might be backportable to mirror https://bugs.python.org/issue46491 but I don't have a strong opinion on that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46511>
_______________________________________

From report at bugs.python.org  Fri Feb 11 14:59:43 2022
From: report at bugs.python.org (Andreas H.)
Date: Fri, 11 Feb 2022 19:59:43 +0000
Subject: [issue46333] ForwardRef.__eq__ does not respect module parameter
In-Reply-To: <1641828029.13.0.319383260427.issue46333@roundup.psfhosted.org>
Message-ID: <1644609583.51.0.516740737972.issue46333@roundup.psfhosted.org>


Change by Andreas H. <ahangauer at gmx.net>:


----------
pull_requests: +29443
pull_request: https://github.com/python/cpython/pull/31283

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46333>
_______________________________________

From report at bugs.python.org  Fri Feb 11 15:09:01 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 11 Feb 2022 20:09:01 +0000
Subject: [issue46615] Use-after-free by mutating set during set operations
In-Reply-To: <1643824882.75.0.278611227582.issue46615@roundup.psfhosted.org>
Message-ID: <1644610141.74.0.07442570375.issue46615@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: +29444
pull_request: https://github.com/python/cpython/pull/31284

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46615>
_______________________________________

From report at bugs.python.org  Fri Feb 11 15:10:43 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 11 Feb 2022 20:10:43 +0000
Subject: [issue46713] Provide a C implementation of collections.abc.KeysView
 and friends
In-Reply-To: <1644520785.16.0.447466630814.issue46713@roundup.psfhosted.org>
Message-ID: <1644610243.97.0.688773966376.issue46713@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

- arbitrary mappings supports by the view ABCs
+ arbitrary mappings supported by the view ABCs

- A first look,
+ At first glance,

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46713>
_______________________________________

From report at bugs.python.org  Fri Feb 11 15:39:41 2022
From: report at bugs.python.org (Saul Shanabrook)
Date: Fri, 11 Feb 2022 20:39:41 +0000
Subject: [issue46724] Odd Bytecode Generation in 3.10
In-Reply-To: <1644600146.24.0.968453673832.issue46724@roundup.psfhosted.org>
Message-ID: <1644611981.74.0.527273285108.issue46724@roundup.psfhosted.org>


Change by Saul Shanabrook <s.shanabrook at gmail.com>:


----------
keywords: +patch
pull_requests: +29445
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31285

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46724>
_______________________________________

From report at bugs.python.org  Fri Feb 11 15:39:48 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Feb 2022 20:39:48 +0000
Subject: [issue46483] `pathlib.PurePath.__class_getitem__` does not return
 `GenericAlias`
In-Reply-To: <1642925790.59.0.879604059643.issue46483@roundup.psfhosted.org>
Message-ID: <1644611988.66.0.768278678695.issue46483@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset e0bc8ee945af96f9395659bbe3cc30b082e7a361 by Alex Waygood in branch 'main':
bpo-46483: [doc] pathlib classes no longer support parameterized generics (GH-31281)
https://github.com/python/cpython/commit/e0bc8ee945af96f9395659bbe3cc30b082e7a361


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46483>
_______________________________________

From report at bugs.python.org  Fri Feb 11 15:39:52 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 11 Feb 2022 20:39:52 +0000
Subject: [issue46483] `pathlib.PurePath.__class_getitem__` does not return
 `GenericAlias`
In-Reply-To: <1642925790.59.0.879604059643.issue46483@roundup.psfhosted.org>
Message-ID: <1644611992.7.0.529617622629.issue46483@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: +29446
pull_request: https://github.com/python/cpython/pull/31286

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46483>
_______________________________________

From report at bugs.python.org  Fri Feb 11 15:42:20 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 11 Feb 2022 20:42:20 +0000
Subject: [issue46483] `pathlib.PurePath.__class_getitem__` does not return
 `GenericAlias`
In-Reply-To: <1642925790.59.0.879604059643.issue46483@roundup.psfhosted.org>
Message-ID: <1644612140.02.0.686389134442.issue46483@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29447
pull_request: https://github.com/python/cpython/pull/31287

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46483>
_______________________________________

From report at bugs.python.org  Fri Feb 11 15:44:24 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 11 Feb 2022 20:44:24 +0000
Subject: [issue46615] Use-after-free by mutating set during set operations
In-Reply-To: <1643824882.75.0.278611227582.issue46615@roundup.psfhosted.org>
Message-ID: <1644612264.91.0.627884722413.issue46615@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1f5fe9962f768c8bfd4ed06a22532d31d3424dc9 by Miss Islington (bot) in branch '3.10':
bpo-46615: Don't crash when set operations mutate the sets (GH-31120)
https://github.com/python/cpython/commit/1f5fe9962f768c8bfd4ed06a22532d31d3424dc9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46615>
_______________________________________

From report at bugs.python.org  Fri Feb 11 15:56:50 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 11 Feb 2022 20:56:50 +0000
Subject: [issue46725] Unpacking without parentheses is allowed since 3.9
In-Reply-To: <1644603030.68.0.559962279778.issue46725@roundup.psfhosted.org>
Message-ID: <1644613010.94.0.461990191212.issue46725@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Let's just document it for 3.11.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46725>
_______________________________________

From report at bugs.python.org  Fri Feb 11 16:03:57 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 11 Feb 2022 21:03:57 +0000
Subject: [issue46483] `pathlib.PurePath.__class_getitem__` does not return
 `GenericAlias`
In-Reply-To: <1642925790.59.0.879604059643.issue46483@roundup.psfhosted.org>
Message-ID: <1644613437.22.0.87905450809.issue46483@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a7c1cc41696740bb528f4d24816c59e38b8be345 by Miss Islington (bot) in branch '3.9':
bpo-46483: [doc] pathlib classes no longer support parameterized generics (GH-31281)
https://github.com/python/cpython/commit/a7c1cc41696740bb528f4d24816c59e38b8be345


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46483>
_______________________________________

From report at bugs.python.org  Fri Feb 11 16:04:05 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 11 Feb 2022 21:04:05 +0000
Subject: [issue46483] `pathlib.PurePath.__class_getitem__` does not return
 `GenericAlias`
In-Reply-To: <1642925790.59.0.879604059643.issue46483@roundup.psfhosted.org>
Message-ID: <1644613445.29.0.930528536625.issue46483@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset f2fbfbe0ec57ec39b3099dae62571a48d5fe8729 by Miss Islington (bot) in branch '3.10':
bpo-46483: [doc] pathlib classes no longer support parameterized generics (GH-31281)
https://github.com/python/cpython/commit/f2fbfbe0ec57ec39b3099dae62571a48d5fe8729


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46483>
_______________________________________

From report at bugs.python.org  Fri Feb 11 16:14:16 2022
From: report at bugs.python.org (Erlend E. Aasland)
Date: Fri, 11 Feb 2022 21:14:16 +0000
Subject: [issue46355] [C API] Document PyFrameObject and PyThreadState changes
 and explain how to port code to Python 3.11
In-Reply-To: <1641996684.93.0.427230565464.issue46355@roundup.psfhosted.org>
Message-ID: <1644614056.03.0.00348933152038.issue46355@roundup.psfhosted.org>


Change by Erlend E. Aasland <erlend.aasland at innova.no>:


----------
nosy: +erlendaasland
nosy_count: 4.0 -> 5.0
pull_requests: +29448
pull_request: https://github.com/python/cpython/pull/31288

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46355>
_______________________________________

From report at bugs.python.org  Fri Feb 11 16:44:53 2022
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 11 Feb 2022 21:44:53 +0000
Subject: [issue46725] Unpacking without parentheses is allowed since 3.9
In-Reply-To: <1644603030.68.0.559962279778.issue46725@roundup.psfhosted.org>
Message-ID: <1644615893.22.0.49477606323.issue46725@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Will prepare a PR

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46725>
_______________________________________

From report at bugs.python.org  Fri Feb 11 17:01:57 2022
From: report at bugs.python.org (Brandt Bucher)
Date: Fri, 11 Feb 2022 22:01:57 +0000
Subject: [issue46072] Unify handling of stats in the CPython VM
In-Reply-To: <1639498673.65.0.709719181358.issue46072@roundup.psfhosted.org>
Message-ID: <1644616917.97.0.329727249639.issue46072@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
nosy: +brandtbucher
nosy_count: 2.0 -> 3.0
pull_requests: +29449
pull_request: https://github.com/python/cpython/pull/31289

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46072>
_______________________________________

From report at bugs.python.org  Fri Feb 11 17:16:24 2022
From: report at bugs.python.org (Matt Wozniski)
Date: Fri, 11 Feb 2022 22:16:24 +0000
Subject: [issue46614] Add option to output UTC datetimes as "Z" in
 `.isoformat()`
In-Reply-To: <1643823106.57.0.535855742317.issue46614@roundup.psfhosted.org>
Message-ID: <1644617784.4.0.54442434784.issue46614@roundup.psfhosted.org>


Matt Wozniski <godlygeek at gmail.com> added the comment:

> I feel like "If the offset is 00:00, use Z" is the wrong rule to use conceptually

This is a really good point that I hadn't considered: `+00:00` and `Z` are semantically different, and just because a datetime has a UTC offset of 0 doesn't mean it should get a `Z`; `Z` is reserved specifically for UTC.

It seems like the most semantically correct thing would be to only use `Z` if `tzname()` returns exactly "UTC". That would do the right thing for your London example for every major timezone library I'm aware of:

>>> datetime.datetime.now(zoneinfo.ZoneInfo("Europe/London")).tzname()
'GMT'
>>> datetime.datetime.now(zoneinfo.ZoneInfo("UTC")).tzname()
'UTC'
>>> datetime.datetime.now(datetime.timezone.utc).tzname()
'UTC'

>>> datetime.datetime.now(dateutil.tz.gettz("Europe/London")).tzname()
'GMT'
>>> datetime.datetime.now(dateutil.tz.UTC).tzname()
'UTC'

>>> datetime.datetime.now(pytz.timezone("Europe/London")).tzname()
'GMT'
>>> datetime.datetime.now(pytz.UTC).tzname()
'UTC'

I think the right rule to use conceptually is "if `use_utc_designator` is true and the timezone name is 'UTC' then use Z". We could also check the offset, but I'm not convinced we need to.

----------
nosy: +godlygeek

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46614>
_______________________________________

From report at bugs.python.org  Fri Feb 11 17:19:34 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 11 Feb 2022 22:19:34 +0000
Subject: [issue46708] test_asyncio: test_sock_client_fail() changes
 asyncio.events._event_loop_policy
In-Reply-To: <1644494036.19.0.505794618548.issue46708@roundup.psfhosted.org>
Message-ID: <1644617974.14.0.374121450664.issue46708@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Heh, I just ran into this for test_taskgroups as well. (Alas, I had debugged and fixed it independently before I found this. :-)

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46708>
_______________________________________

From report at bugs.python.org  Fri Feb 11 17:25:00 2022
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Fri, 11 Feb 2022 22:25:00 +0000
Subject: [issue46720] Add support for path-like objects to
 multiprocessing.set_executable for Windows to be on a par with Unix-like
 systems
In-Reply-To: <1644591429.6.0.540789984747.issue46720@roundup.psfhosted.org>
Message-ID: <1644618300.2.0.127935067189.issue46720@roundup.psfhosted.org>


Change by G?ry <gery.ogam at gmail.com>:


----------
title: Add support of path-like objects to multiprocessing.set_executable for Windows to match Unix-like systems -> Add support for path-like objects to multiprocessing.set_executable for Windows to be on a par with Unix-like systems

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46720>
_______________________________________

From report at bugs.python.org  Fri Feb 11 17:48:17 2022
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 11 Feb 2022 22:48:17 +0000
Subject: [issue46716] regrtest didn't respect the timeout when running
 test_subprocess on AMD64 Windows11 3.x
In-Reply-To: <1644534557.28.0.000333882929265.issue46716@roundup.psfhosted.org>
Message-ID: <1644619697.64.0.370975792974.issue46716@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> test_call_timeout() or test_timeout() in test_subprocess.py.

These tests don't override the standard files, and they only spawn a single child with no descendants. I don't see why this would hang. It shouldn't be a problem with leaked pipe handles (see bpo-43346). It probably will need to be diagnosed by attaching a debugger, or offline with a dump file.

> process trees whereas terminating a parent automatically kills the children

One can use a job object to manage a child process and all of its descendants, including resource usage and termination. A process can belong to multiple job objects in Windows 8+, which is required by Python 3.9+.

For reliability, the child has to be created in a suspended state via CREATE_SUSPENDED. It can be resumed with ResumeThread() after adding it to the job with AssignProcessToJobObject().

You can try to terminate a job cleanly, which is similar in effect to sending SIGTERM to a process group in POSIX. In Windows, this has to be approached differently for console vs graphical processes.

To handle console apps, assuming the child inherits the current console, spawn it as a new process group via creationflags=subprocess.CREATE_NEW_PROCESS_GROUP. You can request an exit by sending a Ctrl+Break event to the group via os.kill(p.pid, signal.CTRL_BREAK_EVENT) [1]. The request might be ignored, but typically the default handler is called, which calls ExitProcess().

To handle GUI apps, assuming the child inherits the current desktop (usually "WinSta0\Default"), first enumerate the top-level and message-only windows on the current desktop via EnumWindows() and FindWindowExW(). Use GetWindowThreadProcessId() to filter the list to include only windows that belong to the job. Post WM_CLOSE to each window in the job. A process might ignore a request to close. It could keep the window open or continue running in the background.

After an internal timeout, you can call TerminateJobObject() to kill any process in the job that remains alive. This is a forced and abrupt termination, which is similar to sending SIGKILL to a process group in POSIX.

---

[1] This usage of os.kill() is what we're stuck with. Rightfully, we should be using os.killpg(p.pid, signal.SIGBREAK) or os.kill(-p.pid, signal.SIGBREAK) (note the negative pid value).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46716>
_______________________________________

From report at bugs.python.org  Fri Feb 11 17:50:53 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 11 Feb 2022 22:50:53 +0000
Subject: [issue46661] Duplicate deprecation warnings in docs for asyncio
In-Reply-To: <1644173025.54.0.0182116442771.issue46661@roundup.psfhosted.org>
Message-ID: <1644619853.48.0.819212587465.issue46661@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
title: Duplicat deprecation warnings in docs for asyncio -> Duplicate deprecation warnings in docs for asyncio

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46661>
_______________________________________

From report at bugs.python.org  Fri Feb 11 18:27:20 2022
From: report at bugs.python.org (primexx)
Date: Fri, 11 Feb 2022 23:27:20 +0000
Subject: [issue46666] IDLE Add indent guide
In-Reply-To: <1644184367.6.0.417629376487.issue46666@roundup.psfhosted.org>
Message-ID: <1644622040.14.0.340789945156.issue46666@roundup.psfhosted.org>


primexx <primexx at gmail.com> added the comment:

very informative discussion. i'll just say that if it's not possible to do purely visually, and it can only be done by modifying the textual content, then it probably should not be done at all. preserving the code (and copy+paste integrity) is more important. maybe this is actually something to raise with Tk first?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46666>
_______________________________________

From report at bugs.python.org  Fri Feb 11 18:47:13 2022
From: report at bugs.python.org (Kevin Shweh)
Date: Fri, 11 Feb 2022 23:47:13 +0000
Subject: [issue46726] Thread spuriously marked dead after interrupting a join
 call
Message-ID: <1644623233.63.0.43795348291.issue46726@roundup.psfhosted.org>


New submission from Kevin Shweh <kevin.shweh at gmail.com>:

This code in Thread._wait_for_tstate_lock:

    try:
        if lock.acquire(block, timeout):
            lock.release()
            self._stop()
    except:
        if lock.locked():
            # bpo-45274: lock.acquire() acquired the lock, but the function
            # was interrupted with an exception before reaching the
            # lock.release(). It can happen if a signal handler raises an
            # exception, like CTRL+C which raises KeyboardInterrupt.
            lock.release()
            self._stop()
        raise

has a bug. The "if lock.locked()" check doesn't check whether this code managed to acquire the lock. It checks if *anyone at all* is holding the lock. The lock is almost always locked, so this code will perform a spurious call to self._stop() if it gets interrupted while trying to acquire the lock.

Thread.join uses this method to wait for a thread to finish, so a thread will spuriously be marked dead if you interrupt a join call with Ctrl-C while it's trying to acquire the lock. Here's a reproducer:


import time
import threading
 
event = threading.Event()
 
def target():
    event.wait()
    print('thread done')
 
t = threading.Thread(target=target)
t.start()
print('joining now')
try:
    t.join()
except KeyboardInterrupt:
    pass
print(t.is_alive())
event.set()


Interrupt this code with Ctrl-C during the join(), and print(t.is_alive()) will print False.

----------
components: Library (Lib)
messages: 413106
nosy: Kevin Shweh
priority: normal
severity: normal
status: open
title: Thread spuriously marked dead after interrupting a join call
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46726>
_______________________________________

From report at bugs.python.org  Fri Feb 11 19:00:05 2022
From: report at bugs.python.org (Ben)
Date: Sat, 12 Feb 2022 00:00:05 +0000
Subject: [issue45274] Race condition in Thread._wait_for_tstate_lock()
In-Reply-To: <1632427989.48.0.0399900831112.issue45274@roundup.psfhosted.org>
Message-ID: <1644624005.7.0.123609571898.issue45274@roundup.psfhosted.org>


Change by Ben <benjsimner at gmail.com>:


----------
nosy: +bjs
nosy_count: 6.0 -> 7.0
pull_requests: +29450
pull_request: https://github.com/python/cpython/pull/31290

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45274>
_______________________________________

From report at bugs.python.org  Fri Feb 11 19:06:37 2022
From: report at bugs.python.org (Ben)
Date: Sat, 12 Feb 2022 00:06:37 +0000
Subject: [issue46726] Thread spuriously marked dead after interrupting a join
 call
In-Reply-To: <1644623233.63.0.43795348291.issue46726@roundup.psfhosted.org>
Message-ID: <1644624397.81.0.0920435185869.issue46726@roundup.psfhosted.org>


Ben <benjsimner at gmail.com> added the comment:

This is a duplicate of https://bugs.python.org/issue45274
but the patch there did not fix it

I've just added a PR there (or should it go here?) that (i think) fixes this.

The issue is that the lock.locked() call just checks that *someone* has the lock, not that the previous acquire() is what got the lock.
If it's just that the tstate lock is held because the thread is still running,  then it's premature to release() the lock.

----------
nosy: +bjs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46726>
_______________________________________

From report at bugs.python.org  Fri Feb 11 19:07:37 2022
From: report at bugs.python.org (Ben)
Date: Sat, 12 Feb 2022 00:07:37 +0000
Subject: [issue46726] Thread spuriously marked dead after interrupting a join
 call
In-Reply-To: <1644623233.63.0.43795348291.issue46726@roundup.psfhosted.org>
Message-ID: <1644624457.84.0.221063215731.issue46726@roundup.psfhosted.org>


Change by Ben <benjsimner at gmail.com>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46726>
_______________________________________

From report at bugs.python.org  Fri Feb 11 19:10:05 2022
From: report at bugs.python.org (James Gerity)
Date: Sat, 12 Feb 2022 00:10:05 +0000
Subject: [issue46726] Thread spuriously marked dead after interrupting a join
 call
In-Reply-To: <1644623233.63.0.43795348291.issue46726@roundup.psfhosted.org>
Message-ID: <1644624605.02.0.981417645978.issue46726@roundup.psfhosted.org>


Change by James Gerity <snoop.jedi at gmail.com>:


----------
nosy: +SnoopJeDi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46726>
_______________________________________

From report at bugs.python.org  Fri Feb 11 19:12:39 2022
From: report at bugs.python.org (Kevin Shweh)
Date: Sat, 12 Feb 2022 00:12:39 +0000
Subject: [issue46726] Thread spuriously marked dead after interrupting a join
 call
In-Reply-To: <1644623233.63.0.43795348291.issue46726@roundup.psfhosted.org>
Message-ID: <1644624759.52.0.480341067237.issue46726@roundup.psfhosted.org>


Kevin Shweh <kevin.shweh at gmail.com> added the comment:

Issue 45274 was a subtly different issue. That was a problem that happened if the thread got interrupted *between* the acquire and the release, causing it to *not* release the lock and *not* perform end-of-thread cleanup.

The fix for that issue caused this issue, which happens if the thread gets interrupted *during* the acquire, in which case it *does* release the lock (that someone else is holding) and *does* perform end-of-thread cleanup even though it's not supposed to do either of those things.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46726>
_______________________________________

From report at bugs.python.org  Fri Feb 11 19:20:03 2022
From: report at bugs.python.org (Kevin Shweh)
Date: Sat, 12 Feb 2022 00:20:03 +0000
Subject: [issue46726] Thread spuriously marked dead after interrupting a join
 call
In-Reply-To: <1644623233.63.0.43795348291.issue46726@roundup.psfhosted.org>
Message-ID: <1644625203.88.0.931500257147.issue46726@roundup.psfhosted.org>


Kevin Shweh <kevin.shweh at gmail.com> added the comment:

The PR you submitted doesn't work, unfortunately. It essentially reintroduces issue 45274. If this line:

    if locked := lock.acquire(block, timeout):

gets interrupted between the acquire and the assignment, locked is still False. That's rare, but so is an interruption between the acquire and the release, which is the original form of issue 45274.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46726>
_______________________________________

From report at bugs.python.org  Fri Feb 11 19:33:05 2022
From: report at bugs.python.org (Ben)
Date: Sat, 12 Feb 2022 00:33:05 +0000
Subject: [issue46726] Thread spuriously marked dead after interrupting a join
 call
In-Reply-To: <1644623233.63.0.43795348291.issue46726@roundup.psfhosted.org>
Message-ID: <1644625985.49.0.545314334135.issue46726@roundup.psfhosted.org>


Ben <benjsimner at gmail.com> added the comment:

You are right,

What one really needs here is a way to know *who* owns the lock,
but threading.Lock does not provide that.

The race on := is much smaller than the original race and I suspect in practice will be very hard to hit.

As the original bpo notes, it may not be possible to write a complete fix for this in pure Python, after all there may always be another interrupt between the `except` and the second attempted `release`.

The issue with the solution was that it turned a relatively hard-to-hit race condition into a really easy-to-hit one,  but perhaps the outcome is slightly less worse?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46726>
_______________________________________

From report at bugs.python.org  Fri Feb 11 19:35:37 2022
From: report at bugs.python.org (Kevin Shweh)
Date: Sat, 12 Feb 2022 00:35:37 +0000
Subject: [issue46722] Different behavior for functiools.partial between
 inspect.isfunction() and other inspect.is*function()
In-Reply-To: <1644593209.5.0.742878484415.issue46722@roundup.psfhosted.org>
Message-ID: <1644626137.73.0.221708965419.issue46722@roundup.psfhosted.org>


Kevin Shweh <kevin.shweh at gmail.com> added the comment:

Frankly, it doesn't make sense that isgeneratorfunction or iscoroutinefunction unwrap partials at all. The original justification for making them do that back in https://bugs.python.org/issue34890 was invalid - the original argument was that isfunction unwraps partials, but it doesn't, and I don't think it ever did.

isfunction is supposed to be a very specific check for Python function objects. It rejects all sorts of other callables, like sum (a built-in function), super (a type), or method objects (which wrap functions in a very similar way to partial). Having it be a check for *either* a Python function object *or* a partial object wrapping a Python function object seems to just make it less useful.

----------
nosy: +Kevin Shweh

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46722>
_______________________________________

From report at bugs.python.org  Fri Feb 11 19:48:33 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 12 Feb 2022 00:48:33 +0000
Subject: [issue46355] [C API] Document PyFrameObject and PyThreadState changes
 and explain how to port code to Python 3.11
In-Reply-To: <1641996684.93.0.427230565464.issue46355@roundup.psfhosted.org>
Message-ID: <1644626913.25.0.486051697108.issue46355@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset ba5725171d9c411fc4764349205eff5cfc028797 by Erlend Egeberg Aasland in branch 'main':
bpo-46355: Amend What's New in Python 3.11 C API wording (GH-31288)
https://github.com/python/cpython/commit/ba5725171d9c411fc4764349205eff5cfc028797


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46355>
_______________________________________

From report at bugs.python.org  Fri Feb 11 20:02:48 2022
From: report at bugs.python.org (Ben)
Date: Sat, 12 Feb 2022 01:02:48 +0000
Subject: [issue46726] Thread spuriously marked dead after interrupting a join
 call
In-Reply-To: <1644623233.63.0.43795348291.issue46726@roundup.psfhosted.org>
Message-ID: <1644627768.92.0.713340074173.issue46726@roundup.psfhosted.org>


Change by Ben <benjsimner at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46726>
_______________________________________

From report at bugs.python.org  Fri Feb 11 20:20:07 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 12 Feb 2022 01:20:07 +0000
Subject: [issue46282] return value of builtins is not clearly indicated
In-Reply-To: <1641482082.12.0.793901620769.issue46282@roundup.psfhosted.org>
Message-ID: <1644628807.19.0.988658604944.issue46282@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/issue46282>
_______________________________________

From report at bugs.python.org  Fri Feb 11 20:43:24 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Sat, 12 Feb 2022 01:43:24 +0000
Subject: [issue46727] Should shutil functions support bytes paths?
Message-ID: <1644630204.06.0.284247645765.issue46727@roundup.psfhosted.org>


New submission from Jelle Zijlstra <jelle.zijlstra at gmail.com>:

The shutil documentation doesn't say anything about bytes paths, and the CPython unit tests don't test them. But some functions do work with bytes paths in practice, and on typeshed we've received some requests to add support for them in the type stubs.

Links:
- https://github.com/python/typeshed/pull/7165/files (shutil.unpack_archive works with bytes paths, but only sometimes)
- https://github.com/python/typeshed/pull/6868 (shutil.make_archive)
- https://github.com/python/typeshed/pull/6832 (shutil.move accepts bytes paths, except when moving into an existing directory)

My overall impression is that bytes paths sometimes work by accident because they happen to not hit any code paths where we do os.path.join or string concatenation, but relying on them is risky because minor changes in the call site or in the file system can cause the call to break.

Here's three possible proposals:

(1) We document in the shutil docs that only str paths are officially supported. Bytes paths may sometimes work, but do it at your own risk.

(2) We add this documentation, but also make code changes to deprecate or even remove any support for bytes paths.

(3) We decide that bytes paths are officially supported, and we add tests for them and fix any cases where they don't work.

My preference is for (1). (2) feels like gratuitously breaking backward compatibility, and (3) is more work and there is little indication that bytes path support is a desired feature.

----------
components: Library (Lib)
messages: 413113
nosy: AlexWaygood, Jelle Zijlstra, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Should shutil functions support bytes paths?
type: behavior
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46727>
_______________________________________

From report at bugs.python.org  Fri Feb 11 21:42:44 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 12 Feb 2022 02:42:44 +0000
Subject: [issue46666] IDLE Add indent guide
In-Reply-To: <1644184367.6.0.417629376487.issue46666@roundup.psfhosted.org>
Message-ID: <1644633764.59.0.269342879288.issue46666@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I am guessing that N++ or its GUI framework uses a transparent overlay.  For tkinter, that would mean a transparent Canvas on which one could draw vertical dotted gray lines 1-pixel wide.  However, Serhiy Storchaka in msg213643 of #20920 said: "Tk supports alpha only for photo images and as an attribute of top-level window. It doesn't support alpha component in colors."

I searched 'tkinter transparent canvas'.

For pixel positioning, photos with transparent backgrounds can only be used on a canvas.  This was one of the answers to https://stackoverflow.com/questions/53021603/how-to-make-a-tkinter-canvas-background-transparent
More details, using pil(low) to make images, are in the following:
https://www.tutorialspoint.com/how-to-make-a-tkinter-canvas-rectangle-transparent
https://www.javaer101.com/en/article/921105.html

Another answer to the SO question, for Windows only, was to pip install pywin32 and use various calls to make a canvas layered with a transparent colorkey.  Perhaps the same could be done, at least on Windows, with ctypes.

A top-level background is made (partially) transparent with "top.attributes('-alpha', d)" where d in [0.0-1.0].  On Windows, 'top.wm_attributes('-transparentcolor', keycolor) makes that keycolor actually be transparent, like the green/blue screen used in television and movies. But any keycolor pixel in the toplevel exposes the screen beneath the toplevel, not the widget in the toplevel.  This detail is not clear in the tk docs.
https://www.youtube.com/watch?v=75jbNpc8vN4
What also is not clear is whether the keycolor applies only to the one toplevel or all toplevels, nor what happens when one toplevel is over another.

I summarized the above so I or anyone else can find the information.  I am closing this issue for now, but someone can reopen if the situation changes.

----------
resolution:  -> third party
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46666>
_______________________________________

From report at bugs.python.org  Fri Feb 11 23:21:41 2022
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 12 Feb 2022 04:21:41 +0000
Subject: [issue46586] In documentation contents enum.property erroneously
 links to built-in property
In-Reply-To: <1643555525.86.0.209520180874.issue46586@roundup.psfhosted.org>
Message-ID: <1644639701.99.0.108662403708.issue46586@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:


New changeset 9d9cfd61ec3cbe84dbc25c74f664877f3d02b8ef by Meer Suri in branch 'main':
bpo-46586: Fix documentation links (GH-31216)
https://github.com/python/cpython/commit/9d9cfd61ec3cbe84dbc25c74f664877f3d02b8ef


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46586>
_______________________________________

From report at bugs.python.org  Sat Feb 12 01:30:26 2022
From: report at bugs.python.org (Inada Naoki)
Date: Sat, 12 Feb 2022 06:30:26 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting and
 immortal objects
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1644647426.31.0.821826330582.issue40255@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

I think making more objects immortal by default will reduce the gap, although I am not sure it can be 2%. (I guess 3% and I think it is acceptable gap.)

* Code attributes (contents of co_consts, co_names, etc...) in deep frozen modules.
  * only if subinterpreter shares them.
* Statically allocated strings (previously _Py_IDENTIFIER)

To reduce gap more, we need to reduce Python stack operation in ceval in some way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Sat Feb 12 03:18:24 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 12 Feb 2022 08:18:24 +0000
Subject: [issue46726] Thread spuriously marked dead after interrupting a join
 call
In-Reply-To: <1644623233.63.0.43795348291.issue46726@roundup.psfhosted.org>
Message-ID: <1644653904.42.0.654155489926.issue46726@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46726>
_______________________________________

From report at bugs.python.org  Sat Feb 12 03:27:14 2022
From: report at bugs.python.org (miss-islington)
Date: Sat, 12 Feb 2022 08:27:14 +0000
Subject: [issue45948] Unexpected instantiation behavior for
 xml.etree.ElementTree.XMLParser(target=None)
In-Reply-To: <1638367672.95.0.357017255599.issue45948@roundup.psfhosted.org>
Message-ID: <1644654434.53.0.243051685753.issue45948@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: +29451
pull_request: https://github.com/python/cpython/pull/31292

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45948>
_______________________________________

From report at bugs.python.org  Sat Feb 12 03:27:09 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 12 Feb 2022 08:27:09 +0000
Subject: [issue45948] Unexpected instantiation behavior for
 xml.etree.ElementTree.XMLParser(target=None)
In-Reply-To: <1638367672.95.0.357017255599.issue45948@roundup.psfhosted.org>
Message-ID: <1644654429.53.0.136670531812.issue45948@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 168fd6453b5de15236116f9261d64601d92571ac by Jacob Walls in branch 'main':
bpo-45948: Remove constructor discrepancy in C version of ElementTree.XMLParser (GH-31152)
https://github.com/python/cpython/commit/168fd6453b5de15236116f9261d64601d92571ac


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45948>
_______________________________________

From report at bugs.python.org  Sat Feb 12 03:46:07 2022
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 12 Feb 2022 08:46:07 +0000
Subject: [issue46726] Thread spuriously marked dead after interrupting a join
 call
In-Reply-To: <1644623233.63.0.43795348291.issue46726@roundup.psfhosted.org>
Message-ID: <1644655567.56.0.12209884858.issue46726@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> The race on := is much smaller than the original race 
> and I suspect in practice will be very hard to hit.

In Windows, the acquire() method of a lock can't be interrupted. Thus, in the main thread, an exception from Ctrl+C gets raised as soon as acquire() returns. This exception definitely will interrupt the assignment. Here's a workaround:

global scope:

    _WINDOWS = _sys.platform == 'win32'

in _wait_for_tstate_lock():

            acquired = None

            try:
                if acquired := lock.acquire(block, timeout):
                    lock.release()
                    self._stop()
            except:
                if _WINDOWS and acquired is None:
                    acquired = True
                if acquired:
                    lock.release()
                    self._stop()
                raise
                
This doesn't help in POSIX if the STORE_FAST instruction that assigns `acquired` gets interrupted. This can't be distinguished from acquire() itself getting interrupted. But at least the window for this is as small as possible.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46726>
_______________________________________

From report at bugs.python.org  Sat Feb 12 03:50:18 2022
From: report at bugs.python.org (miss-islington)
Date: Sat, 12 Feb 2022 08:50:18 +0000
Subject: [issue45948] Unexpected instantiation behavior for
 xml.etree.ElementTree.XMLParser(target=None)
In-Reply-To: <1638367672.95.0.357017255599.issue45948@roundup.psfhosted.org>
Message-ID: <1644655818.79.0.73777630152.issue45948@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b7a65c939c93e7910abc8c9d4a129ff385714824 by Miss Islington (bot) in branch '3.10':
bpo-45948: Remove constructor discrepancy in C version of ElementTree.XMLParser (GH-31152)
https://github.com/python/cpython/commit/b7a65c939c93e7910abc8c9d4a129ff385714824


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45948>
_______________________________________

From report at bugs.python.org  Sat Feb 12 04:13:23 2022
From: report at bugs.python.org (DongGeon Lee)
Date: Sat, 12 Feb 2022 09:13:23 +0000
Subject: [issue46728] Docstring of combinations_with_replacement for
 consistency
Message-ID: <1644657203.94.0.089626219133.issue46728@roundup.psfhosted.org>


New submission from DongGeon Lee <secmatth1996 at gmail.com>:

I've found that there is an unnecessary double quote. It lost its another pair. It needs to be removed.

And I would like to suggest changing its output format in docstring for consistency with similar kinds of other methods, if it was not intentional.

----------
components: Argument Clinic
messages: 413120
nosy: LeeDongGeon1996, larry
priority: normal
severity: normal
status: open
title: Docstring of combinations_with_replacement for consistency
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46728>
_______________________________________

From report at bugs.python.org  Sat Feb 12 04:25:24 2022
From: report at bugs.python.org (DongGeon Lee)
Date: Sat, 12 Feb 2022 09:25:24 +0000
Subject: [issue46728] Docstring of combinations_with_replacement for
 consistency
In-Reply-To: <1644657203.94.0.089626219133.issue46728@roundup.psfhosted.org>
Message-ID: <1644657924.13.0.704127055953.issue46728@roundup.psfhosted.org>


Change by DongGeon Lee <secmatth1996 at gmail.com>:


----------
keywords: +patch
pull_requests: +29452
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31293

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46728>
_______________________________________

From report at bugs.python.org  Sat Feb 12 05:59:52 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 12 Feb 2022 10:59:52 +0000
Subject: [issue46728] Docstring of combinations_with_replacement for
 consistency
In-Reply-To: <1644657203.94.0.089626219133.issue46728@roundup.psfhosted.org>
Message-ID: <1644663592.89.0.489857203773.issue46728@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46728>
_______________________________________

From report at bugs.python.org  Sat Feb 12 06:02:01 2022
From: report at bugs.python.org (Irit Katriel)
Date: Sat, 12 Feb 2022 11:02:01 +0000
Subject: [issue46729] Better str() for BaseExceptionGroup
Message-ID: <1644663721.5.0.89729285647.issue46729@roundup.psfhosted.org>


New submission from Irit Katriel <iritkatriel at gmail.com>:

The str() of exception groups currently contains just the msg as passed to the constructor. This turned out to be confusing (see https://github.com/python/cpython/pull/31270#issuecomment-1036418346).

We should consider whether it is possible to design a more informative str().

Note that the str() is included in the standard traceback, which include the line:

f"{type(e)}: {str(e)}"

So str() should not repeat the type, and should not clutter this too much. Probably just the msg plus the number of contained leaf exceptions.

PEP 654 needs to be updated with what we do here, and the change needs to be approved by the SC.

----------
components: Interpreter Core
keywords: 3.2regression
messages: 413121
nosy: iritkatriel
priority: normal
severity: normal
status: open
title: Better str() for BaseExceptionGroup
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46729>
_______________________________________

From report at bugs.python.org  Sat Feb 12 06:03:13 2022
From: report at bugs.python.org (Irit Katriel)
Date: Sat, 12 Feb 2022 11:03:13 +0000
Subject: [issue46729] Better str() for BaseExceptionGroup
In-Reply-To: <1644663721.5.0.89729285647.issue46729@roundup.psfhosted.org>
Message-ID: <1644663793.91.0.248822836682.issue46729@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at gmail.com>:


----------
keywords: +patch
pull_requests: +29453
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31294

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46729>
_______________________________________

From report at bugs.python.org  Sat Feb 12 06:08:05 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 12 Feb 2022 11:08:05 +0000
Subject: [issue46718] Feature: itertools: add batches
In-Reply-To: <1644581336.38.0.660450208507.issue46718@roundup.psfhosted.org>
Message-ID: <1644664085.81.0.279608795498.issue46718@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46718>
_______________________________________

From report at bugs.python.org  Sat Feb 12 06:15:48 2022
From: report at bugs.python.org (Neil Girdhar)
Date: Sat, 12 Feb 2022 11:15:48 +0000
Subject: [issue46730] Please consider mentioning property without setter when
 an attribute can't be set
Message-ID: <1644664548.7.0.814482728123.issue46730@roundup.psfhosted.org>


New submission from Neil Girdhar <mistersheik at gmail.com>:

class C:
    @property
    def f(self) -> int:
        return 2

class D(C):
    pass

D().f = 2

Gives:

Traceback (most recent call last):
  File "/home/neil/src/cmm/a.py", line 10, in <module>
    D().f = 2
AttributeError: can't set attribute 'f'

This can be a pain to debug when the property is buried in a base class.  Would it make sense to mention the reason why the attribute can't be set, namely that it's on a property without a setter?

----------
components: Interpreter Core
messages: 413122
nosy: NeilGirdhar
priority: normal
severity: normal
status: open
title: Please consider mentioning property without setter when an attribute can't be set
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46730>
_______________________________________

From report at bugs.python.org  Sat Feb 12 06:47:38 2022
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Feb 2022 11:47:38 +0000
Subject: [issue46337] urllib.parse: Allow more flexibility in schemes and URL
 resolution behavior
In-Reply-To: <1641851456.34.0.342855463339.issue46337@roundup.psfhosted.org>
Message-ID: <1644666458.18.0.34393655828.issue46337@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> added the comment:

In my idea it would not be a list of things that you have to pass piecemeal to request specific behaviour, but another function or a new param (like `parse(string, universal=True)`) that implements universal parsing.

We could even handle things like #22852 in that mode (although ironically, correct behaviour for that requires having a registry of schemes).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46337>
_______________________________________

From report at bugs.python.org  Sat Feb 12 06:48:41 2022
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Feb 2022 11:48:41 +0000
Subject: [issue22852] urllib.parse wrongly strips empty #fragment, ?query,
 //netloc
In-Reply-To: <1415787811.02.0.365080072485.issue22852@psf.upfronthosting.co.za>
Message-ID: <1644666521.14.0.0486286266901.issue22852@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> added the comment:

See also #46337

----------
nosy: +eric.araujo
versions: +Python 3.11 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22852>
_______________________________________

From report at bugs.python.org  Sat Feb 12 07:17:20 2022
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Feb 2022 12:17:20 +0000
Subject: [issue46646] `address` arg can be `bytes` for `ip_*` functions in
 `ipaddress` module
In-Reply-To: <1644044752.78.0.400898810491.issue46646@roundup.psfhosted.org>
Message-ID: <1644668240.75.0.947057486321.issue46646@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> added the comment:

Can you dig more to find if the problem is in the code or in the doc?
The PEP to add ipaddress should specify this.

----------
nosy: +eric.araujo, pmoody

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46646>
_______________________________________

From report at bugs.python.org  Sat Feb 12 07:28:55 2022
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Feb 2022 12:28:55 +0000
Subject: [issue46700] wrong nomenclature (options vs. arguments) in argparse
In-Reply-To: <1644445759.27.0.125748612313.issue46700@roundup.psfhosted.org>
Message-ID: <1644668935.69.0.738211061753.issue46700@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> added the comment:

I?m afraid this is a basic decision of argparse, and one of its reasons for existing as an rework of optparse.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46700>
_______________________________________

From report at bugs.python.org  Sat Feb 12 07:47:25 2022
From: report at bugs.python.org (Iliya Zinoviev)
Date: Sat, 12 Feb 2022 12:47:25 +0000
Subject: [issue46722] Different behavior for functiools.partial between
 inspect.isfunction() and other inspect.is*function()
In-Reply-To: <1644593209.5.0.742878484415.issue46722@roundup.psfhosted.org>
Message-ID: <1644670045.59.0.999677309151.issue46722@roundup.psfhosted.org>


Iliya Zinoviev <mrmar333 at yandex.ru> added the comment:

Kevin, thanks for answer!

In that case, I may conclude isgeneratorfunction,
iscoroutinefunction, isasyncgenfunction from python3.7 are more determinated, in my view, cause partial obj has `func` attr for interaction with these funcs anyway, so it isn't need of an alternative.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46722>
_______________________________________

From report at bugs.python.org  Sat Feb 12 08:23:19 2022
From: report at bugs.python.org (Iliya Zinoviev)
Date: Sat, 12 Feb 2022 13:23:19 +0000
Subject: [issue46722] Different behavior for functiools.partial between
 inspect.isfunction() and other inspect.is*function()
In-Reply-To: <1644593209.5.0.742878484415.issue46722@roundup.psfhosted.org>
Message-ID: <1644672199.29.0.988761724422.issue46722@roundup.psfhosted.org>


Iliya Zinoviev <mrmar333 at yandex.ru> added the comment:

I suppose isgeneratorfunction,
iscoroutinefunction, isasyncgenfunction were modified to treat partial obj like regular function. But then without modifying isfunction as well, this approach won't work in full measure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46722>
_______________________________________

From report at bugs.python.org  Sat Feb 12 08:25:15 2022
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 12 Feb 2022 13:25:15 +0000
Subject: [issue46704] Parser API not checking for null-terminator
In-Reply-To: <1644456184.13.0.709670971668.issue46704@roundup.psfhosted.org>
Message-ID: <1644672315.0.0.545692793364.issue46704@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Closing as not a bug. Please, feel free to reopen if we missed something.

Thanks for the report!

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46704>
_______________________________________

From report at bugs.python.org  Sat Feb 12 08:56:56 2022
From: report at bugs.python.org (Saul Shanabrook)
Date: Sat, 12 Feb 2022 13:56:56 +0000
Subject: [issue46724] Odd Bytecode Generation in 3.10
In-Reply-To: <1644600146.24.0.968453673832.issue46724@roundup.psfhosted.org>
Message-ID: <1644674216.71.0.455738351814.issue46724@roundup.psfhosted.org>


Saul Shanabrook <s.shanabrook at gmail.com> added the comment:

I added a patch to make `dis` work with the overflow format.

I am looking into why the bytecode is emitted like this in the first place now. 

I see that currently, Python is trying to write a negative bytecode arg for the JUMP_ABSOLUTE and `instrsize` is saying this requires 4 args (which is not true, it only requires one). Is it intended behavior that the bytecode args will be negative? If so, then `instrsize` might have to be updated to handle this. It takes in an `unsigned int` but the oparg is actually a signed int.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46724>
_______________________________________

From report at bugs.python.org  Sat Feb 12 09:24:13 2022
From: report at bugs.python.org (Saul Shanabrook)
Date: Sat, 12 Feb 2022 14:24:13 +0000
Subject: [issue46724] Odd Bytecode Generation in 3.10
In-Reply-To: <1644600146.24.0.968453673832.issue46724@roundup.psfhosted.org>
Message-ID: <1644675853.08.0.718879915371.issue46724@roundup.psfhosted.org>


Saul Shanabrook <s.shanabrook at gmail.com> added the comment:

Ah, I see that to represent a negative 4 byte signed integer as an arg, we actually do need the 4 instructions, since each is a byte, to get the most significant bit to a 1?

I wasn't able to find anything anywhere which says if the bytecode should or should not contain negative opargs, so I am not sure if this is a bug or intended behavior, to emit the three EXTENDED_ARGs in order to represent

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46724>
_______________________________________

From report at bugs.python.org  Sat Feb 12 09:35:54 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 12 Feb 2022 14:35:54 +0000
Subject: [issue46400] Please update bundled libexpat to 2.4.4 with security
 fixes (CVE-2021-45960)
In-Reply-To: <1642350760.98.0.31451148779.issue46400@roundup.psfhosted.org>
Message-ID: <1644676554.56.0.0219036701809.issue46400@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
versions:  -Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46400>
_______________________________________

From report at bugs.python.org  Sat Feb 12 09:48:24 2022
From: report at bugs.python.org (sping)
Date: Sat, 12 Feb 2022 14:48:24 +0000
Subject: [issue46400] Please update bundled libexpat to 2.4.4 with security
 fixes (CVE-2021-45960)
In-Reply-To: <1642350760.98.0.31451148779.issue46400@roundup.psfhosted.org>
Message-ID: <1644677304.05.0.798024238994.issue46400@roundup.psfhosted.org>


sping <sebastian at pipping.org> added the comment:

Just to understand, why has Python 3.7 and 3.8 been dropped?  Neither seems to be end-of-life but affected.  Thank you!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46400>
_______________________________________

From report at bugs.python.org  Sat Feb 12 10:29:52 2022
From: report at bugs.python.org (miss-islington)
Date: Sat, 12 Feb 2022 15:29:52 +0000
Subject: [issue46400] Please update bundled libexpat to 2.4.4 with security
 fixes (CVE-2021-45960)
In-Reply-To: <1642350760.98.0.31451148779.issue46400@roundup.psfhosted.org>
Message-ID: <1644679792.79.0.204605483242.issue46400@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: +29454
pull_request: https://github.com/python/cpython/pull/31295

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46400>
_______________________________________

From report at bugs.python.org  Sat Feb 12 10:30:03 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 12 Feb 2022 15:30:03 +0000
Subject: [issue46400] Please update bundled libexpat to 2.4.4 with security
 fixes (CVE-2021-45960)
In-Reply-To: <1642350760.98.0.31451148779.issue46400@roundup.psfhosted.org>
Message-ID: <1644679803.42.0.706509944431.issue46400@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:


New changeset 8aaaf7e182e22026c3487a3b86d4d7d4f0f5f778 by Cyril Jouve in branch 'main':
bpo-46400: Update libexpat from 2.4.1 to 2.4.4 (GH-31022)
https://github.com/python/cpython/commit/8aaaf7e182e22026c3487a3b86d4d7d4f0f5f778


----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46400>
_______________________________________

From report at bugs.python.org  Sat Feb 12 10:31:10 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 12 Feb 2022 15:31:10 +0000
Subject: [issue46400] Please update bundled libexpat to 2.4.4 with security
 fixes (CVE-2021-45960)
In-Reply-To: <1642350760.98.0.31451148779.issue46400@roundup.psfhosted.org>
Message-ID: <1644679870.79.0.230461057803.issue46400@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
nosy:  -corona10
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46400>
_______________________________________

From report at bugs.python.org  Sat Feb 12 10:36:01 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 12 Feb 2022 15:36:01 +0000
Subject: [issue46333] ForwardRef.__eq__ does not respect module parameter
In-Reply-To: <1641828029.13.0.319383260427.issue46333@roundup.psfhosted.org>
Message-ID: <1644680161.09.0.114329107204.issue46333@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset b70690bb37cc4bac695051484734eede0c1f9ada by aha79 in branch 'main':
bpo-46333: include `module` in `ForwardRef.__repr__` (#31283)
https://github.com/python/cpython/commit/b70690bb37cc4bac695051484734eede0c1f9ada


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46333>
_______________________________________

From report at bugs.python.org  Sat Feb 12 10:37:41 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 12 Feb 2022 15:37:41 +0000
Subject: [issue46400] Please update bundled libexpat to 2.4.4 with security
 fixes (CVE-2021-45960)
In-Reply-To: <1642350760.98.0.31451148779.issue46400@roundup.psfhosted.org>
Message-ID: <1644680261.21.0.291615839781.issue46400@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
nosy: +corona10
nosy_count: 4.0 -> 5.0
pull_requests: +29455
pull_request: https://github.com/python/cpython/pull/31296

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46400>
_______________________________________

From report at bugs.python.org  Sat Feb 12 10:41:40 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 12 Feb 2022 15:41:40 +0000
Subject: [issue46400] Please update bundled libexpat to 2.4.4 with security
 fixes (CVE-2021-45960)
In-Reply-To: <1642350760.98.0.31451148779.issue46400@roundup.psfhosted.org>
Message-ID: <1644680500.78.0.782022297526.issue46400@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
pull_requests: +29456
pull_request: https://github.com/python/cpython/pull/31297

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46400>
_______________________________________

From report at bugs.python.org  Sat Feb 12 10:44:57 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 12 Feb 2022 15:44:57 +0000
Subject: [issue46400] Please update bundled libexpat to 2.4.4 with security
 fixes (CVE-2021-45960)
In-Reply-To: <1642350760.98.0.31451148779.issue46400@roundup.psfhosted.org>
Message-ID: <1644680697.92.0.0980463863117.issue46400@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
pull_requests: +29457
pull_request: https://github.com/python/cpython/pull/31298

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46400>
_______________________________________

From report at bugs.python.org  Sat Feb 12 10:50:45 2022
From: report at bugs.python.org (Jacob Walls)
Date: Sat, 12 Feb 2022 15:50:45 +0000
Subject: [issue45948] Unexpected instantiation behavior for
 xml.etree.ElementTree.XMLParser(target=None)
In-Reply-To: <1638367672.95.0.357017255599.issue45948@roundup.psfhosted.org>
Message-ID: <1644681045.35.0.866947379464.issue45948@roundup.psfhosted.org>


Change by Jacob Walls <jacobtylerwalls at gmail.com>:


----------
pull_requests: +29458
pull_request: https://github.com/python/cpython/pull/31299

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45948>
_______________________________________

From report at bugs.python.org  Sat Feb 12 10:56:55 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 12 Feb 2022 15:56:55 +0000
Subject: [issue46700] wrong nomenclature (options vs. arguments) in argparse
In-Reply-To: <1644445759.27.0.125748612313.issue46700@roundup.psfhosted.org>
Message-ID: <1644681415.07.0.210900712125.issue46700@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

?ric is correct.  There is not much that can be done about this.  The nomenclature is deeply baked into the code and the docs.

We did change the help output to list "options" rather than "optional arguments".  That helps the end users so that "optional" doesn't imply the opposite of "required".

----------
nosy: +rhettinger
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46700>
_______________________________________

From report at bugs.python.org  Sat Feb 12 11:13:23 2022
From: report at bugs.python.org (mirabilos)
Date: Sat, 12 Feb 2022 16:13:23 +0000
Subject: [issue46700] wrong nomenclature (options vs. arguments) in argparse
In-Reply-To: <1644445759.27.0.125748612313.issue46700@roundup.psfhosted.org>
Message-ID: <1644682403.76.0.115384619393.issue46700@roundup.psfhosted.org>


mirabilos <tg at debian.org> added the comment:

Hm, the change helps indeed. I did this in my code:

    p = argparse.ArgumentParser(description='?', add_help=False)
    g = p.add_argument_group('Options')
    g.add_argument('-h', action='help', help='show this help message and exit')
    g.add_argument(???
    g = p.add_argument_group('Arguments')
    g.add_argument('file', ???
    args = p.parse_args()

Maybe adjust the documentation to match? As it stands, https://docs.python.org/3/library/argparse.html is somewhat helpful, but https://docs.python.org/3/howto/argparse.html is totally confusing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46700>
_______________________________________

From report at bugs.python.org  Sat Feb 12 11:48:33 2022
From: report at bugs.python.org (David CARLIER)
Date: Sat, 12 Feb 2022 16:48:33 +0000
Subject: [issue46731] posix._fcopyfile flags addition
Message-ID: <1644684513.75.0.553009105622.issue46731@roundup.psfhosted.org>


New submission from David CARLIER <devnexen at gmail.com>:

Exposing more flags for direct calls, shutil fastcopy still only using COPYFILE_DATA one.

----------
components: Library (Lib)
messages: 413137
nosy: devnexen
priority: normal
pull_requests: 29459
severity: normal
status: open
title: posix._fcopyfile flags addition
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46731>
_______________________________________

From report at bugs.python.org  Sat Feb 12 12:52:50 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 12 Feb 2022 17:52:50 +0000
Subject: [issue46729] Better str() for BaseExceptionGroup
In-Reply-To: <1644663721.5.0.89729285647.issue46729@roundup.psfhosted.org>
Message-ID: <1644688370.53.0.169345970188.issue46729@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Should it show the number of immediate subexceptions (i.e., len(eg.exceptions)) or the number of leaf exceptions? I'd be happy with the former (since that's what EdgeDb's MultiError does), which would not require adding an extra field to the base exception group struct.

----------
nosy: +gvanrossum, yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46729>
_______________________________________

From report at bugs.python.org  Sat Feb 12 13:11:25 2022
From: report at bugs.python.org (Lincoln Auster)
Date: Sat, 12 Feb 2022 18:11:25 +0000
Subject: [issue46337] urllib.parse: Allow more flexibility in schemes and URL
 resolution behavior
In-Reply-To: <1644666458.18.0.34393655828.issue46337@roundup.psfhosted.org>
Message-ID: <Ygf4RySK9tL5iWZO@desktop.marx>


Lincoln Auster <lincolnauster at gmail.com> added the comment:

> In my idea it would not be a list of things that you have to pass
> piecemeal to request specific behaviour, but another function or a new
> param (like `parse(string, universal=True)`) that implements universal
> parsing.

If I'm correct in my understanding of a universal parse function (a
function with all the SchemeClasses enabled unilaterally), some
parse_universal function would be a pretty trivial thing to add with the
API I've already got here (though it wouldn't address 22852 without some
extra work afaict). I do think keeping the 'piecemeal' options exposed
has some utility, though, especially since the uses_* lists already
treat them on such a granular level.

Do we think a parse_universal function would be helpful to add on top of
this, or just repetitive?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46337>
_______________________________________

From report at bugs.python.org  Sat Feb 12 13:58:50 2022
From: report at bugs.python.org (Tim Peters)
Date: Sat, 12 Feb 2022 18:58:50 +0000
Subject: [issue46726] Thread spuriously marked dead after interrupting a join
 call
In-Reply-To: <1644623233.63.0.43795348291.issue46726@roundup.psfhosted.org>
Message-ID: <1644692330.68.0.487421460638.issue46726@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Eryk, I don't think that workaround is solid on Windows in all cases. For example, if .join() is called with a timeout, the same timeout is passed to lock.acquire(block, timeout). If the acquire() in fact times out, but the store to the `acquired` variable is interrupted, `if _WINDOWS and acquired is None` will succeed, despite that the lock is still locked. Then we go on to - again - incorrectly release the lock and call _stop().

But please don't "repair" that: platform-specific tricks aren't on a path to an actual solution ;-) If the latter requires some new C code, fine.

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46726>
_______________________________________

From report at bugs.python.org  Sat Feb 12 14:10:01 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Sat, 12 Feb 2022 19:10:01 +0000
Subject: [issue46732] object.__bool__ docstring is wrong
Message-ID: <1644693001.93.0.383788579819.issue46732@roundup.psfhosted.org>


New submission from Jelle Zijlstra <jelle.zijlstra at gmail.com>:

>>> None.__bool__.__doc__
'self != 0'

This isn't true, since None does not equal 0. I suggest rewording it to "True if self else False".

----------
assignee: Jelle Zijlstra
components: Interpreter Core
messages: 413141
nosy: Jelle Zijlstra
priority: normal
severity: normal
status: open
title: object.__bool__ docstring is wrong
type: behavior
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46732>
_______________________________________

From report at bugs.python.org  Sat Feb 12 14:18:54 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Sat, 12 Feb 2022 19:18:54 +0000
Subject: [issue46732] object.__bool__ docstring is wrong
In-Reply-To: <1644693001.93.0.383788579819.issue46732@roundup.psfhosted.org>
Message-ID: <1644693534.79.0.532474835269.issue46732@roundup.psfhosted.org>


Change by Jelle Zijlstra <jelle.zijlstra at gmail.com>:


----------
keywords: +patch
pull_requests: +29460
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31301

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46732>
_______________________________________

From report at bugs.python.org  Sat Feb 12 14:35:13 2022
From: report at bugs.python.org (Barney Gale)
Date: Sat, 12 Feb 2022 19:35:13 +0000
Subject: [issue46733] pathlib.Path methods can raise NotImplementedError
Message-ID: <1644694513.05.0.985214969865.issue46733@roundup.psfhosted.org>


New submission from Barney Gale <barney.gale at gmail.com>:

The docs for NotImplementedError say:

> In user defined base classes, abstract methods should raise this exception when they require derived classes to override the method, or while the class is being developed to indicate that the real implementation still needs to be added.

pathlib's use of NotImplementedError appears to be more broad. It can be raised in the following circumstances:

1. When attempting to construct a WindowsPath from a non-Windows system, and vice-versa. This is the only case where NotImplementedError is mentioned in the pathlib docs (in a repl example)
2. In glob() and rglob() when an absolute path is supplied as a pattern
3. In owner() if the pwd module isn't available
4. In group() if the grp module isn't available
5. In readlink() if os.readlink() isn't available
6. In symlink_to() if os.symlink() isn't available
7. In hardlink_to() if os.hardlink() isn't available
8. In WindowsPath.is_mount(), unconditionally

I suspect there are better choices for exception types in all these cases.

----------
components: Library (Lib)
messages: 413142
nosy: barneygale
priority: normal
severity: normal
status: open
title: pathlib.Path methods can raise NotImplementedError
type: behavior
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46733>
_______________________________________

From report at bugs.python.org  Sat Feb 12 14:38:00 2022
From: report at bugs.python.org (Barney Gale)
Date: Sat, 12 Feb 2022 19:38:00 +0000
Subject: [issue46733] pathlib.Path methods can raise NotImplementedError
In-Reply-To: <1644694513.05.0.985214969865.issue46733@roundup.psfhosted.org>
Message-ID: <1644694680.04.0.0953477509139.issue46733@roundup.psfhosted.org>


Change by Barney Gale <barney.gale at gmail.com>:


----------
keywords: +patch
pull_requests: +29461
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31085

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46733>
_______________________________________

From report at bugs.python.org  Sat Feb 12 15:14:54 2022
From: report at bugs.python.org (Alex Waygood)
Date: Sat, 12 Feb 2022 20:14:54 +0000
Subject: [issue46733] pathlib.Path methods can raise NotImplementedError
In-Reply-To: <1644694513.05.0.985214969865.issue46733@roundup.psfhosted.org>
Message-ID: <1644696894.02.0.999761252077.issue46733@roundup.psfhosted.org>


Change by Alex Waygood <Alex.Waygood at Gmail.com>:


----------
pull_requests:  -29461

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46733>
_______________________________________

From report at bugs.python.org  Sat Feb 12 15:15:13 2022
From: report at bugs.python.org (Alex Waygood)
Date: Sat, 12 Feb 2022 20:15:13 +0000
Subject: [issue46733] pathlib.Path methods can raise NotImplementedError
In-Reply-To: <1644694513.05.0.985214969865.issue46733@roundup.psfhosted.org>
Message-ID: <1644696913.74.0.0767478027761.issue46733@roundup.psfhosted.org>


Change by Alex Waygood <Alex.Waygood at Gmail.com>:


----------
keywords:  -patch
stage: patch review -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46733>
_______________________________________

From report at bugs.python.org  Sat Feb 12 15:24:53 2022
From: report at bugs.python.org (Alex Waygood)
Date: Sat, 12 Feb 2022 20:24:53 +0000
Subject: [issue46733] pathlib.Path methods can raise NotImplementedError
In-Reply-To: <1644694513.05.0.985214969865.issue46733@roundup.psfhosted.org>
Message-ID: <1644697493.78.0.699430088078.issue46733@roundup.psfhosted.org>


Alex Waygood <Alex.Waygood at Gmail.com> added the comment:

Here's my two cents, as a non-expert when it comes to pathlib:

I'm not really sure why `is_mount()` exists on WindowsPath objects, given that it unconditionally raises `NotImplementedError` on WindowsPath objects -- that seems *very* strange to me. It seems to me like it should probably be a method on the `PosixPath` class rather than on the `Path` class.

The other methods that raise NotImplementedError don't seem as egregious, because none of them *unconditionally* raise NotImplementedError. We could debate whether some of them would raise different errors in an ideal world, but changing them now might have implications for backwards compatibility, and it doesn't seem like a *major* issue to me.

----------
nosy: +AlexWaygood

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46733>
_______________________________________

From report at bugs.python.org  Sat Feb 12 15:28:10 2022
From: report at bugs.python.org (Alex Waygood)
Date: Sat, 12 Feb 2022 20:28:10 +0000
Subject: [issue46733] pathlib.Path methods can raise NotImplementedError
In-Reply-To: <1644694513.05.0.985214969865.issue46733@roundup.psfhosted.org>
Message-ID: <1644697690.26.0.43084223831.issue46733@roundup.psfhosted.org>


Alex Waygood <Alex.Waygood at Gmail.com> added the comment:

I suppose it might also be worth considering moving `owner()` and `group()` to PosixPath. In practice, these unconditionally raise NotImplementedError on Windows, since the pwd and grp modules are not available on Windows. So, in an ideal world, they probably wouldn't exist on the common base class.

Again, though, that needs to be weighed against backwards-compatibility considerations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46733>
_______________________________________

From report at bugs.python.org  Sat Feb 12 15:53:52 2022
From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=)
Date: Sat, 12 Feb 2022 20:53:52 +0000
Subject: [issue22295] Clarify available commands for package installation
In-Reply-To: <1409258945.79.0.640887405807.issue22295@psf.upfronthosting.co.za>
Message-ID: <1644699232.58.0.736577467827.issue22295@roundup.psfhosted.org>


Change by Ville Skytt? <ville.skytta at iki.fi>:


----------
nosy: +scop
nosy_count: 4.0 -> 5.0
pull_requests: +29462
pull_request: https://github.com/python/cpython/pull/24003

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22295>
_______________________________________

From report at bugs.python.org  Sat Feb 12 17:21:50 2022
From: report at bugs.python.org (Stephen Gildea)
Date: Sat, 12 Feb 2022 22:21:50 +0000
Subject: [issue46734] Add Maildir.get_flags() to access message flags without
 opening the file
Message-ID: <1644704510.06.0.116254271482.issue46734@roundup.psfhosted.org>


New submission from Stephen Gildea <stepheng-bpo at gildea.com>:

A message's flags are stored in its filename by Maildir, so the flags
are available without reading the message file itself.  The structured
message file name makes it efficient to scan a large mailbox to select
only messages that are, for example, not Trashed.

The mailbox.Maildir interface does not expose these flags, however.  The
only way to access the flags through the mailbox library is to create a
mailbox.MaildirMessage object, which has a get_flags() method.  But
creating a MaildirMessage requires opening the message file, which is slow.

I propose adding a parallel get_flags(key) method to mailbox.Maildir,
so that the flags are available without having to create a
MaildirMessage object.

In iterating through a mailbox with thousands of messages, I find that
this proposed Maildir.get_flags() method is 50 times faster than
MaildirMessage.get_flags().

----------
components: Library (Lib)
messages: 413145
nosy: gildea
priority: normal
severity: normal
status: open
title: Add Maildir.get_flags() to access message flags without opening the file
type: enhancement
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46734>
_______________________________________

From report at bugs.python.org  Sat Feb 12 17:49:37 2022
From: report at bugs.python.org (Stephen Gildea)
Date: Sat, 12 Feb 2022 22:49:37 +0000
Subject: [issue46734] Add Maildir.get_flags() to access message flags without
 opening the file
In-Reply-To: <1644704510.06.0.116254271482.issue46734@roundup.psfhosted.org>
Message-ID: <1644706177.46.0.852989021095.issue46734@roundup.psfhosted.org>


Change by Stephen Gildea <stepheng-bpo at gildea.com>:


----------
keywords: +patch
pull_requests: +29463
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31302

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46734>
_______________________________________

From report at bugs.python.org  Sat Feb 12 18:21:11 2022
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 12 Feb 2022 23:21:11 +0000
Subject: [issue46726] Thread spuriously marked dead after interrupting a join
 call
In-Reply-To: <1644623233.63.0.43795348291.issue46726@roundup.psfhosted.org>
Message-ID: <1644708071.17.0.771256708667.issue46726@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> If the acquire() in fact times out, but the store to the `acquired` 
> variable is interrupted, `if _WINDOWS and acquired is None` will
> succeed, despite that the lock is still locked

Yeah, my proposed workaround is no good, so we can't resolve this without a more fundamental solution. Are you looking into a way to prevent the STORE_FAST instruction from getting interrupted by an asynchronous exception?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46726>
_______________________________________

From report at bugs.python.org  Sat Feb 12 19:04:56 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 13 Feb 2022 00:04:56 +0000
Subject: [issue45447] Make IDLE recognize .pyi stub files (and .pyw) as python
 source
In-Reply-To: <1634052276.56.0.989526823091.issue45447@roundup.psfhosted.org>
Message-ID: <1644710696.43.0.704199650973.issue45447@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 50cf4991c49e19f917305dd7b9c71085c11edddb by Alex Waygood in branch 'main':
bpo-45447: Add syntax highlighting for `.pyi` files in IDLE (GH-28950)
https://github.com/python/cpython/commit/50cf4991c49e19f917305dd7b9c71085c11edddb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45447>
_______________________________________

From report at bugs.python.org  Sat Feb 12 19:16:39 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 13 Feb 2022 00:16:39 +0000
Subject: [issue45948] Unexpected instantiation behavior for
 xml.etree.ElementTree.XMLParser(target=None)
In-Reply-To: <1638367672.95.0.357017255599.issue45948@roundup.psfhosted.org>
Message-ID: <1644711399.52.0.830923506555.issue45948@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset cc6d8f88289917d67237a10f7a0e2439fde7a573 by Jacob Walls in branch '3.9':
[3.9] bpo-45948: Remove constructor discrepancy in C version of ElementTree.XMLParser (GH-31152) (GH-31299)
https://github.com/python/cpython/commit/cc6d8f88289917d67237a10f7a0e2439fde7a573


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45948>
_______________________________________

From report at bugs.python.org  Sat Feb 12 19:17:02 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 13 Feb 2022 00:17:02 +0000
Subject: [issue45948] Unexpected instantiation behavior for
 xml.etree.ElementTree.XMLParser(target=None)
In-Reply-To: <1638367672.95.0.357017255599.issue45948@roundup.psfhosted.org>
Message-ID: <1644711422.12.0.741622536302.issue45948@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/issue45948>
_______________________________________

From report at bugs.python.org  Sat Feb 12 19:25:08 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 13 Feb 2022 00:25:08 +0000
Subject: [issue45447] Make IDLE recognize .pyi stub files (and .pyw) as python
 source
In-Reply-To: <1634052276.56.0.989526823091.issue45447@roundup.psfhosted.org>
Message-ID: <1644711908.29.0.424046407872.issue45447@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +29464
pull_request: https://github.com/python/cpython/pull/31303

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45447>
_______________________________________

From report at bugs.python.org  Sat Feb 12 19:47:26 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 13 Feb 2022 00:47:26 +0000
Subject: [issue45447] Make IDLE recognize .pyi stub files (and .pyw) as python
 source
In-Reply-To: <1634052276.56.0.989526823091.issue45447@roundup.psfhosted.org>
Message-ID: <1644713246.32.0.615961244541.issue45447@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +29465
pull_request: https://github.com/python/cpython/pull/31304

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45447>
_______________________________________

From report at bugs.python.org  Sat Feb 12 19:51:52 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 13 Feb 2022 00:51:52 +0000
Subject: [issue45447] Make IDLE recognize .pyi stub files (and .pyw) as python
 source
In-Reply-To: <1634052276.56.0.989526823091.issue45447@roundup.psfhosted.org>
Message-ID: <1644713512.17.0.109536743085.issue45447@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +29466
pull_request: https://github.com/python/cpython/pull/31305

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45447>
_______________________________________

From report at bugs.python.org  Sat Feb 12 19:52:45 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 13 Feb 2022 00:52:45 +0000
Subject: [issue45447] Make IDLE recognize .pyi stub files (and .pyw) as python
 source
In-Reply-To: <1634052276.56.0.989526823091.issue45447@roundup.psfhosted.org>
Message-ID: <1644713565.25.0.361447886615.issue45447@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 9fabcfbe68ff81ef5f17f86a93daf9cce9d83876 by Terry Jan Reedy in branch '3.10':
bpo-45447: Add syntax highlighting for `.pyi` files in IDLE (GH-28950)
https://github.com/python/cpython/commit/9fabcfbe68ff81ef5f17f86a93daf9cce9d83876


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45447>
_______________________________________

From report at bugs.python.org  Sat Feb 12 19:52:47 2022
From: report at bugs.python.org (miss-islington)
Date: Sun, 13 Feb 2022 00:52:47 +0000
Subject: [issue45447] Make IDLE recognize .pyi stub files (and .pyw) as python
 source
In-Reply-To: <1634052276.56.0.989526823091.issue45447@roundup.psfhosted.org>
Message-ID: <1644713567.25.0.689202084902.issue45447@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: +29467
pull_request: https://github.com/python/cpython/pull/31306

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45447>
_______________________________________

From report at bugs.python.org  Sat Feb 12 19:59:34 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 13 Feb 2022 00:59:34 +0000
Subject: [issue45447] Make IDLE recognize .pyi stub files (and .pyw) as python
 source
In-Reply-To: <1634052276.56.0.989526823091.issue45447@roundup.psfhosted.org>
Message-ID: <1644713974.27.0.338380672405.issue45447@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +29468
pull_request: https://github.com/python/cpython/pull/31307

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45447>
_______________________________________

From report at bugs.python.org  Sat Feb 12 20:19:32 2022
From: report at bugs.python.org (miss-islington)
Date: Sun, 13 Feb 2022 01:19:32 +0000
Subject: [issue45447] Make IDLE recognize .pyi stub files (and .pyw) as python
 source
In-Reply-To: <1634052276.56.0.989526823091.issue45447@roundup.psfhosted.org>
Message-ID: <1644715172.85.0.735340505696.issue45447@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1d4d44c385414042cbdd2a1e9504cd8e9d69c0ae by Miss Islington (bot) in branch '3.9':
bpo-45447: Add syntax highlighting for `.pyi` files in IDLE (GH-28950)
https://github.com/python/cpython/commit/1d4d44c385414042cbdd2a1e9504cd8e9d69c0ae


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45447>
_______________________________________

From report at bugs.python.org  Sat Feb 12 20:33:53 2022
From: report at bugs.python.org (unmellow the gamer)
Date: Sun, 13 Feb 2022 01:33:53 +0000
Subject: [issue46735] gettext.translations crashes when locale is unset
Message-ID: <1644716033.71.0.382285385303.issue46735@roundup.psfhosted.org>


New submission from unmellow the gamer <amazingminecrafter2015 at gmail.com>:

The issue listed below contains an example of this problem
I assume python programs crashing when an environment variable is unset
is unintended and thought after all this time i should probably bring it to your attention
https://github.com/k4yt3x/video2x/issues/349

----------
components: Parser
messages: 413151
nosy: amazingminecrafter2015, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: gettext.translations crashes when locale is unset
type: crash
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46735>
_______________________________________

From report at bugs.python.org  Sat Feb 12 20:37:19 2022
From: report at bugs.python.org (Alexander)
Date: Sun, 13 Feb 2022 01:37:19 +0000
Subject: [issue46730] Please consider mentioning property without setter when
 an attribute can't be set
In-Reply-To: <1644664548.7.0.814482728123.issue46730@roundup.psfhosted.org>
Message-ID: <1644716239.68.0.488332543701.issue46730@roundup.psfhosted.org>


Alexander <lakeevveekal at gmail.com> added the comment:

Indeed, the error message does not help to identify the problem. Moreover, it collides with similar errors in namedtuple and DynamicClassAttribute which may lead to even more confusion.

I made a draft patch that could help with it (https://github.com/Alex-Blade/cpython/commit/06df3a72dfe462c8fe4eac60dce0ef059b1738f8), but I have a concern related to backwards compatibility (that's why no PR). I don't really understand if according to PEP 387 a change in an exception message should be considered compatibility breaking?

----------
nosy: +Alex-Blade

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46730>
_______________________________________

From report at bugs.python.org  Sat Feb 12 20:50:38 2022
From: report at bugs.python.org (Neil Girdhar)
Date: Sun, 13 Feb 2022 01:50:38 +0000
Subject: [issue46730] Please consider mentioning property without setter when
 an attribute can't be set
In-Reply-To: <1644716239.68.0.488332543701.issue46730@roundup.psfhosted.org>
Message-ID: <CAA68w_mQ_kX-oVdHRedRfzuD=2Lew1Nrb2Sx8ZWCqaK5x2nDcg@mail.gmail.com>


Neil Girdhar <mistersheik at gmail.com> added the comment:

Thank you, this would have saved me a lot of time!

On Sat, Feb 12, 2022 at 8:37 PM Alexander <report at bugs.python.org> wrote:

>
> Alexander <lakeevveekal at gmail.com> added the comment:
>
> Indeed, the error message does not help to identify the problem. Moreover,
> it collides with similar errors in namedtuple and DynamicClassAttribute
> which may lead to even more confusion.
>
> I made a draft patch that could help with it (
> https://github.com/Alex-Blade/cpython/commit/06df3a72dfe462c8fe4eac60dce0ef059b1738f8),
> but I have a concern related to backwards compatibility (that's why no PR).
> I don't really understand if according to PEP 387 a change in an exception
> message should be considered compatibility breaking?
>
> ----------
> nosy: +Alex-Blade
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue46730>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46730>
_______________________________________

From report at bugs.python.org  Sat Feb 12 20:58:28 2022
From: report at bugs.python.org (Dennis Sweeney)
Date: Sun, 13 Feb 2022 01:58:28 +0000
Subject: [issue46730] Please consider mentioning property without setter when
 an attribute can't be set
In-Reply-To: <1644664548.7.0.814482728123.issue46730@roundup.psfhosted.org>
Message-ID: <1644717508.87.0.0841103472186.issue46730@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

Go ahead and open a PR -- it makes it easier to discuss particular changes.

Regarding backwards-compatibility, error messages improvements are fair game for Python 3.11, we just shouldn't backport them to earlier versions.

We can also consider including the type of the relevant object in the error messages.

----------
nosy: +Dennis Sweeney

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46730>
_______________________________________

From report at bugs.python.org  Sat Feb 12 21:06:38 2022
From: report at bugs.python.org (Tim Peters)
Date: Sun, 13 Feb 2022 02:06:38 +0000
Subject: [issue46726] Thread spuriously marked dead after interrupting a join
 call
In-Reply-To: <1644623233.63.0.43795348291.issue46726@roundup.psfhosted.org>
Message-ID: <1644717998.28.0.250218103264.issue46726@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Na, we've been doing excruciatingly clever stuff to deal with thread shutdown for decades, and it always proves to be wrong in some way. Even if code like

except:
    if lock.locked():
        lock.release()
        self._stop()
    raise

did work as hoped for, it would still be broken, but in a different way: suppose we really did acquire the tstate lock because the thread actually ended while we were in acquire(). But then a signal dumped us into the `except` block before doing the release. Oops! There's nothing I can see to stop _another_ (say) KeyboardInterrupt preventing us from doing the "failsafe" release too. So the lock remains locked forever after (we hold the lock now, and missed our chances to release it). And I think that's pretty likely: if I don't see an instant response to Ctrl-C, I'm likely to do another very soon after.

So I don't think catching exceptions can be made to work for this. Or `finally` blocks either. Indeed, it appears that any way whatsoever of spelling `lock.release()` in Python can be defeated by an unfortunately timed signal.

Which isn't unique to this code, of course. The failure modes of this code just happen to be unusually visible ;-)

Two other approaches come to mind:

- Wrap everything needed in a custom C function. CPython can't interfere with its control flow.

- Add new sys gimmicks to suppress and re-enable raising Python level exceptions for signals. Then, e.g., something here like:

with sys.delay_signal_exceptions():
    # Dead simple code, like _before_ we "fixed" it ;-)
    # In particular, while Ctrl-C may terminate the `acquire()` call,
    # KeyboardInterrupt will not be raised until the `with` block
    # exits.
    # Possibly intractable: arranging then for the traceback to
    # point at the code where the exception would have been raised
    # had temporary suspension not been enabled. Then again, since
    # it's not _actually_ raised there at the Python level, maybe
    # it's a Good Thing to ignore.
    if lock.acquire(block, timeout):
        lock.release()
        self._stop()

The second way is more general, but would probably require a PEP.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46726>
_______________________________________

From report at bugs.python.org  Sat Feb 12 21:10:41 2022
From: report at bugs.python.org (miss-islington)
Date: Sun, 13 Feb 2022 02:10:41 +0000
Subject: [issue45447] Make IDLE recognize .pyi stub files (and .pyw) as python
 source
In-Reply-To: <1634052276.56.0.989526823091.issue45447@roundup.psfhosted.org>
Message-ID: <1644718241.11.0.685038376079.issue45447@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29469
pull_request: https://github.com/python/cpython/pull/31308

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45447>
_______________________________________

From report at bugs.python.org  Sat Feb 12 21:10:49 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 13 Feb 2022 02:10:49 +0000
Subject: [issue45447] Make IDLE recognize .pyi stub files (and .pyw) as python
 source
In-Reply-To: <1634052276.56.0.989526823091.issue45447@roundup.psfhosted.org>
Message-ID: <1644718249.38.0.398665962989.issue45447@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 2d98433549be358d1c192e30e51b8d345d618cc7 by Terry Jan Reedy in branch 'main':
bpo-45447: Add entry to What's new 3.10 (GH-31304)
https://github.com/python/cpython/commit/2d98433549be358d1c192e30e51b8d345d618cc7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45447>
_______________________________________

From report at bugs.python.org  Sat Feb 12 21:11:24 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 13 Feb 2022 02:11:24 +0000
Subject: [issue45447] Make IDLE recognize .pyi stub files (and .pyw) as python
 source
In-Reply-To: <1634052276.56.0.989526823091.issue45447@roundup.psfhosted.org>
Message-ID: <1644718284.37.0.37191472625.issue45447@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset cef91ca80c41749824eca1d4b2c99731e3d5f64c by Terry Jan Reedy in branch 'main':
bpo-45447: Add entry to What's new 3.9 (GH-31305)
https://github.com/python/cpython/commit/cef91ca80c41749824eca1d4b2c99731e3d5f64c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45447>
_______________________________________

From report at bugs.python.org  Sat Feb 12 21:11:29 2022
From: report at bugs.python.org (miss-islington)
Date: Sun, 13 Feb 2022 02:11:29 +0000
Subject: [issue45447] Make IDLE recognize .pyi stub files (and .pyw) as python
 source
In-Reply-To: <1634052276.56.0.989526823091.issue45447@roundup.psfhosted.org>
Message-ID: <1644718289.14.0.0160308181626.issue45447@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29470
pull_request: https://github.com/python/cpython/pull/31309

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45447>
_______________________________________

From report at bugs.python.org  Sat Feb 12 21:11:33 2022
From: report at bugs.python.org (miss-islington)
Date: Sun, 13 Feb 2022 02:11:33 +0000
Subject: [issue45447] Make IDLE recognize .pyi stub files (and .pyw) as python
 source
In-Reply-To: <1634052276.56.0.989526823091.issue45447@roundup.psfhosted.org>
Message-ID: <1644718293.79.0.667787095588.issue45447@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29471
pull_request: https://github.com/python/cpython/pull/31310

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45447>
_______________________________________

From report at bugs.python.org  Sat Feb 12 21:12:25 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 13 Feb 2022 02:12:25 +0000
Subject: [issue45447] Make IDLE recognize .pyi stub files (and .pyw) as python
 source
In-Reply-To: <1634052276.56.0.989526823091.issue45447@roundup.psfhosted.org>
Message-ID: <1644718345.34.0.188893191694.issue45447@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 6331c08d1c3248ff47a7b8e0045c9023c9af672c by Terry Jan Reedy in branch 'main':
bpo-45447: Fix entry in What's New 3.11 (GH-31307)
https://github.com/python/cpython/commit/6331c08d1c3248ff47a7b8e0045c9023c9af672c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45447>
_______________________________________

From report at bugs.python.org  Sat Feb 12 21:43:12 2022
From: report at bugs.python.org (Alexander)
Date: Sun, 13 Feb 2022 02:43:12 +0000
Subject: [issue46730] Please consider mentioning property without setter when
 an attribute can't be set
In-Reply-To: <1644664548.7.0.814482728123.issue46730@roundup.psfhosted.org>
Message-ID: <1644720192.52.0.411095943424.issue46730@roundup.psfhosted.org>


Change by Alexander <lakeevveekal at gmail.com>:


----------
keywords: +patch
pull_requests: +29472
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31311

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46730>
_______________________________________

From report at bugs.python.org  Sat Feb 12 21:47:09 2022
From: report at bugs.python.org (Dennis Sweeney)
Date: Sun, 13 Feb 2022 02:47:09 +0000
Subject: [issue46615] Use-after-free by mutating set during set operations
In-Reply-To: <1643824882.75.0.278611227582.issue46615@roundup.psfhosted.org>
Message-ID: <1644720429.46.0.139442693405.issue46615@roundup.psfhosted.org>


Change by Dennis Sweeney <sweeney.dennis650 at gmail.com>:


----------
pull_requests: +29473
pull_request: https://github.com/python/cpython/pull/31312

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46615>
_______________________________________

From report at bugs.python.org  Sat Feb 12 21:50:16 2022
From: report at bugs.python.org (Alexander)
Date: Sun, 13 Feb 2022 02:50:16 +0000
Subject: [issue46730] Please consider mentioning property without setter when
 an attribute can't be set
In-Reply-To: <1644664548.7.0.814482728123.issue46730@roundup.psfhosted.org>
Message-ID: <1644720616.68.0.308500318748.issue46730@roundup.psfhosted.org>


Alexander <lakeevveekal at gmail.com> added the comment:

Added the PR. (I have signed the CLA, just haven't got the response yet, doesn't affect the discussion I guess)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46730>
_______________________________________

From report at bugs.python.org  Sat Feb 12 21:53:53 2022
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 13 Feb 2022 02:53:53 +0000
Subject: [issue46730] Please consider mentioning property without setter when
 an attribute can't be set
In-Reply-To: <1644664548.7.0.814482728123.issue46730@roundup.psfhosted.org>
Message-ID: <1644720833.56.0.40582484554.issue46730@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/issue46730>
_______________________________________

From report at bugs.python.org  Sat Feb 12 22:10:06 2022
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 13 Feb 2022 03:10:06 +0000
Subject: [issue46726] Thread spuriously marked dead after interrupting a join
 call
In-Reply-To: <1644623233.63.0.43795348291.issue46726@roundup.psfhosted.org>
Message-ID: <1644721806.61.0.563935595936.issue46726@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> Wrap everything needed in a custom C function. 

Maybe add an `acquire_and_release()` method:

    static PyObject *
    lock_PyThread_acquire_and_release_lock(
            lockobject *self, PyObject *args, PyObject *kwds)
    {
        _PyTime_t timeout;

        if (lock_acquire_parse_args(args, kwds, &timeout) < 0)
            return NULL;

        PyLockStatus r = acquire_timed(self->lock_lock, timeout);

        if (r == PY_LOCK_INTR) {
            return NULL;
        }

        if (r == PY_LOCK_ACQUIRED) {
            PyThread_release_lock(self->lock_lock);
            self->locked = 0;
        }
        
        return PyBool_FromLong(r == PY_LOCK_ACQUIRED);
    }

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46726>
_______________________________________

From report at bugs.python.org  Sat Feb 12 22:18:15 2022
From: report at bugs.python.org (Numerlor)
Date: Sun, 13 Feb 2022 03:18:15 +0000
Subject: [issue39805] Copying functions doesn't actually copy them
In-Reply-To: <1583034162.79.0.0576327457429.issue39805@roundup.psfhosted.org>
Message-ID: <1644722295.37.0.0419518891041.issue39805@roundup.psfhosted.org>


Numerlor <miso1038 at gmail.com> added the comment:

Ran into this myself today; do you have any plans on implementing the proposed change?

----------
nosy: +Numerlor

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39805>
_______________________________________

From report at bugs.python.org  Sat Feb 12 22:46:09 2022
From: report at bugs.python.org (Tim Peters)
Date: Sun, 13 Feb 2022 03:46:09 +0000
Subject: [issue46726] Thread spuriously marked dead after interrupting a join
 call
In-Reply-To: <1644623233.63.0.43795348291.issue46726@roundup.psfhosted.org>
Message-ID: <1644723969.41.0.796863567588.issue46726@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

> Maybe add an `acquire_and_release()` method

Bingo - that should do the trick, in an "obviously correct" way. Of course it's of limited applicability, but fine by me.

Will you open a PR with this code?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46726>
_______________________________________

From report at bugs.python.org  Sat Feb 12 23:29:46 2022
From: report at bugs.python.org (Jeremy Kloth)
Date: Sun, 13 Feb 2022 04:29:46 +0000
Subject: [issue46716] regrtest didn't respect the timeout when running
 test_subprocess on AMD64 Windows11 3.x
In-Reply-To: <1644534557.28.0.000333882929265.issue46716@roundup.psfhosted.org>
Message-ID: <1644726586.19.0.306762647891.issue46716@roundup.psfhosted.org>


Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com> added the comment:

I've been able locally to reproduce the test_subprocess hang.  The responsible function is subprocess.run().  The test case, test_timeout(), uses a small timeout value (0.0001), which, when given enough load, can cause the run() call to hang.

A judicious use of prints in subprocess.py, reveals that the timeout passed to wait() ends up being negative.  That value, once cast to a DWORD, ultimately causes a very long wait (0xfffffff2, in my testing).

It does seem that only the Windows Popen._wait() cannot handle negative timeout values, so the fix should be as simple as coercing the timeout values to >= 0.

----------
Added file: https://bugs.python.org/file50623/process.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46716>
_______________________________________

From report at bugs.python.org  Sat Feb 12 23:31:41 2022
From: report at bugs.python.org (Tim Peters)
Date: Sun, 13 Feb 2022 04:31:41 +0000
Subject: [issue46726] Thread spuriously marked dead after interrupting a join
 call
In-Reply-To: <1644623233.63.0.43795348291.issue46726@roundup.psfhosted.org>
Message-ID: <1644726701.8.0.607022763188.issue46726@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

While bundling the lock.release() into C makes that bulletproof, is there a bulletproof way to guarantee that `self._stop()` gets called if the acquire_and_release() succeeds? Offhand, I don't see a reason for why that isn't just as vulnerable to getting skipped due to an unfortunate signal.

Indeed, huge mounds of threading.py can leave things in insane states in the presence of by-magic exceptions. Even if code is very careful to put crucial cleanup code in `finally` blocks so it gets executed "no matter what", there's nothing to stop code in `finally` blocks from getting skipped over due to by-magic exceptions too.

It's an eternal marvel that anything ever works at all ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46726>
_______________________________________

From report at bugs.python.org  Sat Feb 12 23:59:28 2022
From: report at bugs.python.org (=?utf-8?b?6IOh5Li5?=)
Date: Sun, 13 Feb 2022 04:59:28 +0000
Subject: [issue35228] Index search in CHM help crashes viewer
In-Reply-To: <1542107217.87.0.788709270274.issue35228@psf.upfronthosting.co.za>
Message-ID: <1644728368.62.0.72362500822.issue35228@roundup.psfhosted.org>


?? <daniel1029 at 126.com> added the comment:

I found another workaround to alleviate this problem.

My envrionments: Win 10 Pro 2004, Python 3.9.6, cp936 locale

When I open the Python CHM help file, e.g. double click, Win10 actually uses the command: 
"C:\Windows\hh.exe" D:/Python/Python39/Doc/python396.chm
But when I try "C:\Windows\SysWOW64\hh.exe" D:/Python/Python39/Doc/python396.chm 
Magic happens, crash problem just vanished :)

----------
nosy: +danny1221

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35228>
_______________________________________

From report at bugs.python.org  Sun Feb 13 01:30:34 2022
From: report at bugs.python.org (miss-islington)
Date: Sun, 13 Feb 2022 06:30:34 +0000
Subject: [issue45447] Make IDLE recognize .pyi stub files (and .pyw) as python
 source
In-Reply-To: <1634052276.56.0.989526823091.issue45447@roundup.psfhosted.org>
Message-ID: <1644733834.77.0.532469404875.issue45447@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 5698e0be8e77bd4d7a1fda88005662f0b239dec8 by Miss Islington (bot) in branch '3.10':
bpo-45447: Add entry to What's new 3.9 (GH-31305)
https://github.com/python/cpython/commit/5698e0be8e77bd4d7a1fda88005662f0b239dec8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45447>
_______________________________________

From report at bugs.python.org  Sun Feb 13 01:30:39 2022
From: report at bugs.python.org (miss-islington)
Date: Sun, 13 Feb 2022 06:30:39 +0000
Subject: [issue45447] Make IDLE recognize .pyi stub files (and .pyw) as python
 source
In-Reply-To: <1634052276.56.0.989526823091.issue45447@roundup.psfhosted.org>
Message-ID: <1644733839.54.0.938541380938.issue45447@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ebe73e6095fc019fd1e31c9f41bc67d56ee003b6 by Miss Islington (bot) in branch '3.9':
bpo-45447: Add entry to What's new 3.9 (GH-31305)
https://github.com/python/cpython/commit/ebe73e6095fc019fd1e31c9f41bc67d56ee003b6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45447>
_______________________________________

From report at bugs.python.org  Sun Feb 13 01:31:10 2022
From: report at bugs.python.org (miss-islington)
Date: Sun, 13 Feb 2022 06:31:10 +0000
Subject: [issue45447] Make IDLE recognize .pyi stub files (and .pyw) as python
 source
In-Reply-To: <1634052276.56.0.989526823091.issue45447@roundup.psfhosted.org>
Message-ID: <1644733870.77.0.363408944055.issue45447@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 44666c3285a52c2a4632f89aeeddd7ca7d02c8df by Miss Islington (bot) in branch '3.10':
bpo-45447: Add entry to What's new 3.10 (GH-31304)
https://github.com/python/cpython/commit/44666c3285a52c2a4632f89aeeddd7ca7d02c8df


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45447>
_______________________________________

From report at bugs.python.org  Sun Feb 13 01:36:40 2022
From: report at bugs.python.org (Dennis Sweeney)
Date: Sun, 13 Feb 2022 06:36:40 +0000
Subject: [issue34890] Support functools.partial in inspect.is*function() checks
In-Reply-To: <1538638196.31.0.545547206417.issue34890@psf.upfronthosting.co.za>
Message-ID: <1644734200.85.0.715653288744.issue34890@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

See https://bugs.python.org/issue46722 for a concern about this change.

----------
nosy: +Dennis Sweeney

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34890>
_______________________________________

From report at bugs.python.org  Sun Feb 13 03:21:29 2022
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 13 Feb 2022 08:21:29 +0000
Subject: [issue46716] regrtest didn't respect the timeout when running
 test_subprocess on AMD64 Windows11 3.x
In-Reply-To: <1644534557.28.0.000333882929265.issue46716@roundup.psfhosted.org>
Message-ID: <1644740489.41.0.434020781195.issue46716@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> the fix should be as simple as coercing the timeout values to >= 0.

Popen._remaining_time() should return max(endtime - _time(), 0).

Popen._wait() should raise OverflowError if the timeout is too large for the implementation. In Windows, the upper limit in milliseconds is `_winapi.INFINITE - 1` (about 49.7 days). It's important to only allow the timeout in milliseconds to be _winapi.INFINITE when `timeout is None`.

The DWORD converter in _winapi needs to subclass unsigned_long_converter. The current implementation based on the legacy format unit "k" is too lenient. Negative values and values that are too large should fail. I updated it to use the following definition:

    class DWORD_converter(unsigned_long_converter):
        type = 'DWORD'

This produces the following improved results:

    >>> h = _winapi.GetCurrentProcess()
    >>> _winapi.WaitForSingleObject(h, _winapi.INFINITE + 1)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    OverflowError: Python int too large to convert to C unsigned long

    >>> _winapi.WaitForSingleObject(h, -1)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    ValueError: value must be positive

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46716>
_______________________________________

From report at bugs.python.org  Sun Feb 13 03:33:08 2022
From: report at bugs.python.org (Dominic Davis-Foster)
Date: Sun, 13 Feb 2022 08:33:08 +0000
Subject: [issue46736] Generate HTML 5 with
 SimpleHTTPRequestHandler.list_directory
Message-ID: <1644741188.03.0.745095490398.issue46736@roundup.psfhosted.org>


New submission from Dominic Davis-Foster <dom1310df at googlemail.com>:

Currently SimpleHTTPRequestHandler.list_directory (which is used with `python3 -m http.server` amongst other things) generates HTML with the doctype:

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

i.e. HTML 4.01.


I propose making the generated page HTML 5 instead. The only necessary change is in the doctype; the rest of the page is valid already. HTML 5 has been supported by Chrome, Firefox, Safari and Opera since 2013, and Edge since 2015 so there shouldn't be any issues with browser compatibility.

The generated page has been HTML 4.01 since https://bugs.python.org/issue13295 in 2011, where it was originally proposed to switch to HTML 5.


Switching to HTML 5 would also allow http.server to be used to serve a simple index for pip that's compliant with PEP 503.

There's some discussion in https://github.com/pypa/pip/issues/10825

----------
components: Library (Lib)
messages: 413173
nosy: dom1310df
priority: normal
severity: normal
status: open
title: Generate HTML 5 with SimpleHTTPRequestHandler.list_directory
type: enhancement
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46736>
_______________________________________

From report at bugs.python.org  Sun Feb 13 04:23:52 2022
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 13 Feb 2022 09:23:52 +0000
Subject: [issue46726] Thread spuriously marked dead after interrupting a join
 call
In-Reply-To: <1644623233.63.0.43795348291.issue46726@roundup.psfhosted.org>
Message-ID: <1644744232.33.0.343301155051.issue46726@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> is there a bulletproof way to guarantee that `self._stop()` gets 
> called if the acquire_and_release() succeeds? 

I don't think it's critical. But we still should deal with the common case in Windows in which a KeyboardInterrupt is raised immediately after the method returns. For example:

        try:
            if lock.acquire_and_release(block, timeout):
                self._stop
        except:
            if not lock.locked():
                self._stop()

The proposed acquire_and_release() method can also be used in threading._shutdown(), when it iterates _shutdown_locks to join non-daemon threads.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46726>
_______________________________________

From report at bugs.python.org  Sun Feb 13 05:30:20 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 13 Feb 2022 10:30:20 +0000
Subject: [issue46615] Use-after-free by mutating set during set operations
In-Reply-To: <1643824882.75.0.278611227582.issue46615@roundup.psfhosted.org>
Message-ID: <1644748220.43.0.657406940735.issue46615@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset c31b8a97a8a7e8255231c9e12ed581c6240c0d6c by Dennis Sweeney in branch '3.9':
bpo-46615: Don't crash when set operations mutate the sets (GH-31120) (GH-31312)
https://github.com/python/cpython/commit/c31b8a97a8a7e8255231c9e12ed581c6240c0d6c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46615>
_______________________________________

From report at bugs.python.org  Sun Feb 13 05:41:21 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 13 Feb 2022 10:41:21 +0000
Subject: [issue46615] Use-after-free by mutating set during set operations
In-Reply-To: <1643824882.75.0.278611227582.issue46615@roundup.psfhosted.org>
Message-ID: <1644748881.79.0.943839367549.issue46615@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thanks Dennis for your report and PRs.

Do you mind to analyze also uses of _PySet_NextEntry(), PyDict_Next() and _PyDict_Next()? Many of them look safe, but _pickle.c seems vulnerable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46615>
_______________________________________

From report at bugs.python.org  Sun Feb 13 06:27:05 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 13 Feb 2022 11:27:05 +0000
Subject: [issue46737] Default to the standard normal distribution
Message-ID: <1644751625.52.0.483632432415.issue46737@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

This is really minor, but it would convenient if we provided default arguments:

    random.gauss(mu=0.0, sigma=1.0)
    random.normalvariate(mu=0.0, sigma=1.0)

----------
components: Library (Lib)
messages: 413177
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Default to the standard normal distribution
type: enhancement
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46737>
_______________________________________

From report at bugs.python.org  Sun Feb 13 06:51:08 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 13 Feb 2022 11:51:08 +0000
Subject: [issue39805] Copying functions doesn't actually copy them
In-Reply-To: <1583034162.79.0.0576327457429.issue39805@roundup.psfhosted.org>
Message-ID: <1644753068.99.0.968583878958.issue39805@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It is by design. Functions and types are pickled by name. The copy module uses the pickling protocol and only use different methods for performance or for non-pickleable objects. Changing this will break existing code.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39805>
_______________________________________

From report at bugs.python.org  Sun Feb 13 07:57:58 2022
From: report at bugs.python.org (Tzu-ping Chung)
Date: Sun, 13 Feb 2022 12:57:58 +0000
Subject: [issue46738] Allow http.server to emit HTML 5
Message-ID: <1644757078.96.0.518529275585.issue46738@roundup.psfhosted.org>


New submission from Tzu-ping Chung <uranusjr at gmail.com>:

Currently, a directory listing page emitted by http.parser uses the HTML 4.01 doctype. While this is perfectly fine for most uses, the server tool is sometimes used for things that require another doctype; PEP 503[1], for example, requires an HTML 5 document.

>From what I can tell, http.parser is already emitting a valid HTML 5 page, so it should be possible to simply change the doctype declaration. Or, if backward compatibility is paramount, this could live behind a --doctype flag as well. If we go the latter route, more doctypes (e.g. XHTML) could potentially be supported as well with minimal modification.

[1]: https://www.python.org/dev/peps/pep-0503/

----------
components: Library (Lib)
messages: 413179
nosy: uranusjr
priority: normal
severity: normal
status: open
title: Allow http.server to emit HTML 5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46738>
_______________________________________

From report at bugs.python.org  Sun Feb 13 08:26:50 2022
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 13 Feb 2022 13:26:50 +0000
Subject: [issue39805] Copying functions doesn't actually copy them
In-Reply-To: <1644753068.99.0.968583878958.issue39805@roundup.psfhosted.org>
Message-ID: <20220213132541.GF12540@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

If we can't change the default behaviour of copying functions, can we 
add a specialised copy_function() function, for when we really need to 
make a genuine copy?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39805>
_______________________________________

From report at bugs.python.org  Sun Feb 13 08:51:29 2022
From: report at bugs.python.org (Tzu-ping Chung)
Date: Sun, 13 Feb 2022 13:51:29 +0000
Subject: [issue46622] Support decorating a coroutine with
 functools.cached_property
In-Reply-To: <1643873308.65.0.92890586202.issue46622@roundup.psfhosted.org>
Message-ID: <1644760289.56.0.670399383517.issue46622@roundup.psfhosted.org>


Change by Tzu-ping Chung <uranusjr at gmail.com>:


----------
keywords: +patch
pull_requests: +29476
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31314

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46622>
_______________________________________

From report at bugs.python.org  Sun Feb 13 09:05:48 2022
From: report at bugs.python.org (Meer Suri)
Date: Sun, 13 Feb 2022 14:05:48 +0000
Subject: [issue46586] In documentation contents enum.property erroneously
 links to built-in property
In-Reply-To: <1643555525.86.0.209520180874.issue46586@roundup.psfhosted.org>
Message-ID: <1644761148.07.0.687131805843.issue46586@roundup.psfhosted.org>


Meer Suri <meersuri at gmail.com> added the comment:

Thanks Jelle for the cool idea of the script to look for more instances of this problem. I've been working on this script and am still refining it, but one of the candidates that my program returned is in zipfile.rst - https://docs.python.org/3.11/library/zipfile.html?highlight=zipfile#zipfile.ZipFile.open 

Changed in version 3.6: open() can now be used to write files into the archive with the mode='w' option.
Changed in version 3.6: Calling open() on a closed ZipFile will raise a ValueError. Previously, a RuntimeError was raised.

Here the first instance of open() points to the builtins function rather than ZipFile.open(), whereas the second instance points to ZipFile.open(). Seems like a true positive to me, what do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46586>
_______________________________________

From report at bugs.python.org  Sun Feb 13 09:21:07 2022
From: report at bugs.python.org (Numerlor)
Date: Sun, 13 Feb 2022 14:21:07 +0000
Subject: [issue39805] Copying functions doesn't actually copy them
In-Reply-To: <1583034162.79.0.0576327457429.issue39805@roundup.psfhosted.org>
Message-ID: <1644762067.83.0.657292185417.issue39805@roundup.psfhosted.org>


Numerlor <Numerlor at gmail.com> added the comment:

Having copy be an identity function for anything mutable seems very bug prone, even if it's functions. If not changed in the copy interface I would say that at least a warning would be helpful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39805>
_______________________________________

From report at bugs.python.org  Sun Feb 13 09:28:14 2022
From: report at bugs.python.org (Meer Suri)
Date: Sun, 13 Feb 2022 14:28:14 +0000
Subject: [issue46586] In documentation contents enum.property erroneously
 links to built-in property
In-Reply-To: <1643555525.86.0.209520180874.issue46586@roundup.psfhosted.org>
Message-ID: <1644762494.58.0.196649532323.issue46586@roundup.psfhosted.org>


Meer Suri <meersuri at gmail.com> added the comment:

Also this one?- 

https://docs.python.org/3.11/library/urllib.request.html?highlight=urllib%20request#urllib.request.OpenerDirector.open

Arguments, return values and exceptions raised are the same as those of urlopen() (which simply calls the open() method on the currently installed global OpenerDirector).

open() points to the builtins function but the markup used is :meth:`open` and the logic of the sentence suggests the link was meant to be to OpenerDirector.open()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46586>
_______________________________________

From report at bugs.python.org  Sun Feb 13 09:31:05 2022
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 13 Feb 2022 14:31:05 +0000
Subject: [issue46735] gettext.translations crashes when locale is unset
In-Reply-To: <1644716033.71.0.382285385303.issue46735@roundup.psfhosted.org>
Message-ID: <1644762665.05.0.600052620865.issue46735@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
nosy:  -pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46735>
_______________________________________

From report at bugs.python.org  Sun Feb 13 09:41:07 2022
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 13 Feb 2022 14:41:07 +0000
Subject: [issue46737] Default to the standard normal distribution
In-Reply-To: <1644751625.52.0.483632432415.issue46737@roundup.psfhosted.org>
Message-ID: <1644763267.55.0.749686645299.issue46737@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

+1

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46737>
_______________________________________

From report at bugs.python.org  Sun Feb 13 09:47:37 2022
From: report at bugs.python.org (Meer Suri)
Date: Sun, 13 Feb 2022 14:47:37 +0000
Subject: [issue46586] In documentation contents enum.property erroneously
 links to built-in property
In-Reply-To: <1643555525.86.0.209520180874.issue46586@roundup.psfhosted.org>
Message-ID: <1644763657.86.0.0858008091044.issue46586@roundup.psfhosted.org>


Meer Suri <meersuri at gmail.com> added the comment:

Looks like another one - 
https://docs.python.org/3.11/library/fileinput.html#fileinput.hook_encoded

Deprecated since version 3.10: This function is deprecated since input() and FileInput now have encoding and errors parameters.

The input() here points to builtins which doesnt have the mentioned parameters

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46586>
_______________________________________

From report at bugs.python.org  Sun Feb 13 10:04:51 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 13 Feb 2022 15:04:51 +0000
Subject: [issue45976] Random._randbelow() loses time by caching an attribute
 lookup
In-Reply-To: <1638584456.65.0.012587553781.issue45976@roundup.psfhosted.org>
Message-ID: <1644764691.55.0.0362061243123.issue45976@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I'm thinking that we care more about the unhappy cases (the extreme values) than we care about a mild and implementation dependent improvement to the average case.

----------
resolution: later -> rejected

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45976>
_______________________________________

From report at bugs.python.org  Sun Feb 13 10:10:57 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 13 Feb 2022 15:10:57 +0000
Subject: [issue46622] Support decorating a coroutine with
 functools.cached_property
In-Reply-To: <1643873308.65.0.92890586202.issue46622@roundup.psfhosted.org>
Message-ID: <1644765057.13.0.673169405006.issue46622@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

I have a design question.
Does `print(await a.hello)` look awkward?
I'm not speaking about correction.

In asyncio code I have seen before, `await val` means waiting for a future object. `await func()` means async function call.

`await obj.attr` looks more like a future waiting but, in fact, it is not.
Should we encourage such syntax?
I have no strong opinion here and like to hear other devs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46622>
_______________________________________

From report at bugs.python.org  Sun Feb 13 11:35:46 2022
From: report at bugs.python.org (Craig Coleman)
Date: Sun, 13 Feb 2022 16:35:46 +0000
Subject: [issue46739] dataclasses __eq__ isn't logical
Message-ID: <1644770146.93.0.142732009848.issue46739@roundup.psfhosted.org>


New submission from Craig Coleman <craig.s.r.coleman at gmail.com>:

In a test, dataclasses generate an __eq__ function appears to be wrong.

@dataclass 
class C:
    pass
    
class K:
    pass

a = C()
b = C()
c = K()
d = K()

(a is b) # False
(a == b) # True # Incorrect, Why?
(c is d) # False
(c == d) # False # Correct

Using @dataclass(eq = False) for annotation of C would make (a == b) == False which I think is correct behaviour.

----------
components: Library (Lib)
messages: 413188
nosy: ccoleman
priority: normal
severity: normal
status: open
title: dataclasses __eq__ isn't logical
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46739>
_______________________________________

From report at bugs.python.org  Sun Feb 13 11:42:30 2022
From: report at bugs.python.org (Jeremy Kloth)
Date: Sun, 13 Feb 2022 16:42:30 +0000
Subject: [issue46716] regrtest didn't respect the timeout when running
 test_subprocess on AMD64 Windows11 3.x
In-Reply-To: <1644740489.41.0.434020781195.issue46716@roundup.psfhosted.org>
Message-ID: <CAGvrs3Jinx=wFZvDR8NJPwRMbw---cFA6z5BLK+nKHDT5jwCsQ@mail.gmail.com>


Jeremy Kloth <jeremy.kloth at gmail.com> added the comment:

> > the fix should be as simple as coercing the timeout values to >= 0.
>
> Popen._remaining_time() should return max(endtime - _time(), 0).

That was my first initial instinct as well, however, that change would
also affect more of the Popen behavior and need a much more thorough
investigation of the POSIX side of Popen.

> Popen._wait() should raise OverflowError if the timeout is too large for the implementation. In Windows, the upper limit in milliseconds is `_winapi.INFINITE - 1` (about 49.7 days). It's important to only allow the timeout in milliseconds to be _winapi.INFINITE when `timeout is None`.

I agree.

> The DWORD converter in _winapi needs to subclass unsigned_long_converter. The current implementation based on the legacy format unit "k" is too lenient. Negative values and values that are too large should fail.

Whilst I agree this is a correct solution, I fear the potential
3rd-party breakage alone should bump this to its own issue.

I believe that this then leads to the following action items for this issue:
1) modify Windows Popen._wait() to raise on out of bounds values [< 0
or >= INFINITE]
2) cap Popen._remaining_time() return value to >= 0
3) change _winapi DWORD converter be unsigned long
4) use Job objects to group Windows processes for termination

Have I missed anything?  I should be able to knock out PRs for these today.
-- 
Jeremy Kloth

----------
nosy: +jeremy.kloth

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46716>
_______________________________________

From report at bugs.python.org  Sun Feb 13 12:16:21 2022
From: report at bugs.python.org (Alex Waygood)
Date: Sun, 13 Feb 2022 17:16:21 +0000
Subject: [issue46739] dataclasses __eq__ isn't logical
In-Reply-To: <1644770146.93.0.142732009848.issue46739@roundup.psfhosted.org>
Message-ID: <1644772581.77.0.579206466745.issue46739@roundup.psfhosted.org>


Change by Alex Waygood <Alex.Waygood at Gmail.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46739>
_______________________________________

From report at bugs.python.org  Sun Feb 13 12:44:27 2022
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 13 Feb 2022 17:44:27 +0000
Subject: [issue46739] dataclasses __eq__ isn't logical
In-Reply-To: <1644770146.93.0.142732009848.issue46739@roundup.psfhosted.org>
Message-ID: <1644774267.56.0.26351037614.issue46739@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Can you explain why you think the result of `a == b` should be `False` rather than `True`? By default, equality for dataclasses is structural equality, and `True` is the result that I'd expect here.

>From the [docs](https://docs.python.org/3/library/dataclasses.html#dataclasses.dataclass) for `eq`: 

> If true (the default), an __eq__() method will be generated. This method compares the class as if it were a tuple of its fields, in order

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46739>
_______________________________________

From report at bugs.python.org  Sun Feb 13 13:12:42 2022
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 13 Feb 2022 18:12:42 +0000
Subject: [issue46733] pathlib.Path methods can raise NotImplementedError
In-Reply-To: <1644694513.05.0.985214969865.issue46733@roundup.psfhosted.org>
Message-ID: <1644775962.11.0.0199190861407.issue46733@roundup.psfhosted.org>


Change by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo, pitrou, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46733>
_______________________________________

From report at bugs.python.org  Sun Feb 13 13:41:15 2022
From: report at bugs.python.org (Tim Peters)
Date: Sun, 13 Feb 2022 18:41:15 +0000
Subject: [issue46726] Thread spuriously marked dead after interrupting a join
 call
In-Reply-To: <1644623233.63.0.43795348291.issue46726@roundup.psfhosted.org>
Message-ID: <1644777675.0.0.700563733952.issue46726@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

>> is there a bulletproof way to guarantee that `self._stop()` gets 
>> called if the acquire_and_release() succeeds? 

> I don't think it's critical.

Agreed! Anything at the Python level that cares whether the thread is still alive will call _wait_for_tstate_lock() again, and get another chance each time to notice that the tstate lock has been freed.

Instead of:

        try:
            if lock.acquire_and_release(block, timeout):
                self._stop
        except:
            if not lock.locked():
                self._stop()

I'd prefer:

        try:
            lock.acquire_and_release(block, timeout)
        finally:
            if not lock.locked():
                self._stop()

Because, at the Python level, whether acquire_and_release() succeeded at its task depends entirely on whether the lock is free afterward. That's what we're _really_ looking for, and is so on all possible platforms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46726>
_______________________________________

From report at bugs.python.org  Sun Feb 13 13:50:00 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 13 Feb 2022 18:50:00 +0000
Subject: [issue46739] dataclasses __eq__ isn't logical
In-Reply-To: <1644770146.93.0.142732009848.issue46739@roundup.psfhosted.org>
Message-ID: <1644778200.81.0.0439521398555.issue46739@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I agree with Mark. It's identical to:

>>> () == ()
True

As for the non-dataclass version, that's a normal object identity comparison if no __eq__ is defined: https://docs.python.org/3/reference/datamodel.html#object.__eq__ , third paragraph.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46739>
_______________________________________

From report at bugs.python.org  Sun Feb 13 14:18:12 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 13 Feb 2022 19:18:12 +0000
Subject: [issue46739] dataclasses __eq__ isn't logical
In-Reply-To: <1644770146.93.0.142732009848.issue46739@roundup.psfhosted.org>
Message-ID: <1644779892.32.0.332458580988.issue46739@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
assignee:  -> eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46739>
_______________________________________

From report at bugs.python.org  Sun Feb 13 14:55:37 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 13 Feb 2022 19:55:37 +0000
Subject: [issue43464] set intersections should short-circuit
In-Reply-To: <1615394359.7.0.616950024555.issue43464@roundup.psfhosted.org>
Message-ID: <1644782137.83.0.248450851868.issue43464@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
nosy: +serhiy.storchaka
nosy_count: 2.0 -> 3.0
pull_requests: +29477
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31316

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43464>
_______________________________________

From report at bugs.python.org  Sun Feb 13 14:59:21 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 13 Feb 2022 19:59:21 +0000
Subject: [issue43464] set intersections should short-circuit
In-Reply-To: <1615394359.7.0.616950024555.issue43464@roundup.psfhosted.org>
Message-ID: <1644782361.59.0.767495137356.issue43464@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

See also issue46721. set.issuperset() can get similar optimization.

And set.issubset() will benefit from this optimization if use set.intersection() in issue46705.

----------
keywords:  -patch
stage: patch review -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43464>
_______________________________________

From report at bugs.python.org  Sun Feb 13 15:01:30 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 13 Feb 2022 20:01:30 +0000
Subject: [issue46705] Memory optimization for set.issubset
In-Reply-To: <1644456286.75.0.570469463639.issue46705@roundup.psfhosted.org>
Message-ID: <1644782490.35.0.834399966916.issue46705@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It will be even more efficient after applying a set.intersection() optimization in issue43464.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46705>
_______________________________________

From report at bugs.python.org  Sun Feb 13 15:17:40 2022
From: report at bugs.python.org (Martin Kirchgessner)
Date: Sun, 13 Feb 2022 20:17:40 +0000
Subject: [issue46740] Improve Telnetlib's throughput
Message-ID: <1644783460.72.0.175033327075.issue46740@roundup.psfhosted.org>


New submission from Martin Kirchgessner <martin.kirch at gmail.com>:

While using `telnetlib` I sometimes received unusually "large" messages (around 1Mb) from another process on the same machine, and was surprised `read_until` took more than a second. After instrumenting I discovered such messages were received at roughly 500kbyte/s.

I think this low throughput comes from two implementation details:

 - `Telnet.fill_rawq` is calling `self.sock.recv(50)`, whereas 4096 is now recommended
 - the `Telnet.process_rawq` method is transferring from raw queue to cooked queue by appending byte per byte.

For the latter, transferring by slices looks much faster (I'm measuring at least 5x). I'm preparing a PR.

----------
components: Library (Lib)
messages: 413195
nosy: martin_kirch
priority: normal
severity: normal
status: open
title: Improve Telnetlib's throughput
type: resource usage
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46740>
_______________________________________

From report at bugs.python.org  Sun Feb 13 16:13:07 2022
From: report at bugs.python.org (Alex Waygood)
Date: Sun, 13 Feb 2022 21:13:07 +0000
Subject: [issue46741] Docstring for asyncio.protocols.BufferedProtocol appears
 out of date
Message-ID: <1644786787.46.0.446565917898.issue46741@roundup.psfhosted.org>


New submission from Alex Waygood <Alex.Waygood at Gmail.com>:

The docstring for asyncio.protocols.BufferedProtocol includes this paragraph:

"""
Important: this has been added to asyncio in Python 3.7
*on a provisional basis*!  Consider it as an experimental API that
might be changed or removed in Python 3.8.
"""

The main branch is now 3.11, and the class has not yet been removed, so I'm guessing it's now safe to say that it's here to stay?

----------
assignee: docs at python
components: Documentation, asyncio
messages: 413196
nosy: AlexWaygood, asvetlov, docs at python, yselivanov
priority: normal
severity: normal
status: open
title: Docstring for asyncio.protocols.BufferedProtocol appears out of date
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46741>
_______________________________________

From report at bugs.python.org  Sun Feb 13 16:39:31 2022
From: report at bugs.python.org (Charles Howes)
Date: Sun, 13 Feb 2022 21:39:31 +0000
Subject: [issue46742] Add '-d $fd' option to trace module,
 akin to bash -x feature
Message-ID: <1644788371.77.0.167561149161.issue46742@roundup.psfhosted.org>


New submission from Charles Howes <github.com at ch.pkts.ca>:

The 'trace' module logs trace output to stdout, intermingled with regular program output.  This is a problem when you want to read either the trace output or the normal output of the program separately.

To separate the trace output, it could be written to a file or to another file descriptor.

A pull request has been created that fixes this by mimicking bash's behaviour: bash can be told to write trace output to a different file descriptor using the BASH_XTRACEFD shell variable: `exec 42> xtrace.out; BASH_XTRACEFD=42; ...`

Usage of this new feature:

  python -m trace -t -d 111 your_program.py 111> /tmp/your_trace.txt

or:

  t = Trace(count=1, trace=1, trace_fd=1, countfuncs=0, countcallers=0, ignoremods=(), ignoredirs=(), infile=None, outfile=None, timing=False)

Notes:
* `bash -x` sends trace logs to stderr by default; `python -m trace -t` sends them to stdout.  I wanted to change Python to match, but was worried that this might break existing code.  

* Also considered writing trace logs to the file specified with the `-f FILE` option, but worried that it would mess up the count file if `-t` and `-c` were used together.

----------
components: Library (Lib)
messages: 413197
nosy: PenelopeFudd
priority: normal
severity: normal
status: open
title: Add '-d $fd' option to trace module, akin to bash -x feature
type: enhancement
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46742>
_______________________________________

From report at bugs.python.org  Sun Feb 13 17:23:56 2022
From: report at bugs.python.org (Charles Howes)
Date: Sun, 13 Feb 2022 22:23:56 +0000
Subject: [issue46742] Add '-d $fd' option to trace module,
 akin to bash -x feature
In-Reply-To: <1644788371.77.0.167561149161.issue46742@roundup.psfhosted.org>
Message-ID: <1644791036.12.0.114635779981.issue46742@roundup.psfhosted.org>


Change by Charles Howes <github.com at ch.pkts.ca>:


----------
keywords: +patch
pull_requests: +29478
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31319

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46742>
_______________________________________

From report at bugs.python.org  Sun Feb 13 18:49:55 2022
From: report at bugs.python.org (Gobot1234)
Date: Sun, 13 Feb 2022 23:49:55 +0000
Subject: [issue46743] Enable usage of object.__orig_class__ in __init__
Message-ID: <1644796195.73.0.52600427485.issue46743@roundup.psfhosted.org>


New submission from Gobot1234 <gobot1234yt at gmail.com>:

When using `__call__` on a `typing/types.GenericAlias` `__orig_class__` is set to the `GenericAlias` instance, however currently the mechanism for this does not allow the `__origin__` to access the `GenericAlias` from `__origin__.__init__` as it performs something akin to:
```py
def __call__(self, *args, **kwargs):
    object = self.__origin__(*args, **kwargs)
    object.__orig_class__ = self
    return object
```
I'd like to propose changing this to something like:
```py
def __call__(self, *args, **kwargs):
    object = self.__origin__.__new__(*args, **kwargs)
    object.__orig_class__ = self
    object.__init__(*args, **kwargs)
    return object
```
(Ideally `__orig_class__` should also be available in `__new__` but I'm not entirely sure if that's possible)

AFAICT this was possible in the typing version back in 3.6 (https://github.com/python/typing/issues/658 and maybe https://github.com/python/typing/issues/519). Was there a reason this was removed?

----------
components: Library (Lib)
messages: 413198
nosy: Gobot1234, gvanrossum, kj
priority: normal
severity: normal
status: open
title: Enable usage of object.__orig_class__ in __init__
type: enhancement
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46743>
_______________________________________

From report at bugs.python.org  Sun Feb 13 18:50:52 2022
From: report at bugs.python.org (conio)
Date: Sun, 13 Feb 2022 23:50:52 +0000
Subject: [issue46744] installers on ARM64 suggest wrong folders
Message-ID: <1644796252.37.0.322200421464.issue46744@roundup.psfhosted.org>


New submission from conio <conio.h+bugs.python.org at gmail.com>:

Thank you for your work on bringing Python to Windows on ARM64.

I recently installed it an noticed some strange behaviours.

On ARM64 Windows 11 the recent prerelease (3.11.0a5, post #33125) acts in a way I believe is wrong: Checking the _install for all users_ checkbox causes the installer to suggest the `C:\Program Files (Arm)\Python311-Arm64` folder, but the `C:\Program Files (Arm)` is intended for ARM32 programs, similarly to how the `C:\Program Files (x86)` is intended for x86 programs.

The folder for programs that are native for the platform is simply `C:\Program Files` - which is x86 on x86 Windows, x64 on x64 Windows and ARM64 on ARM64 Windows.

So on ARM64 Windows the ARM64 Python should go into the native Program Files folder which is `C:\Program Files`.

--

A closely related issue is that the installer for x64 Python wants to install into `C:\Program Files\Python311`, but I already installed the ARM64 version there.

The x86 acts as as should be expected and wants to install into `C:\Program Files (x86)\Python311-32`.

But there's no "Program Files (x64)", so where should the x64 version on ARM64 machines go?

I argue that the x64 version should go into `C:\Program Files\Python311-amd64" while the ARM64 version should go into `C:\Program Files\Python311`, because the ARM64 is the native on on this platform, while the x64 is foreign, and should get an elaborate name, like the x86, which is also foreign, gets.

(The dotnet team also had this problem, and they decided similarly.)

Internally `sys.winver` and the PEP 514 Registry structure can say whatever you like, but on the filesystem it's much more appropriate for the unqualified folder to be the system native one.

----------
components: Installation, Windows
messages: 413199
nosy: conio, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: installers on ARM64 suggest wrong folders
type: behavior
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46744>
_______________________________________

From report at bugs.python.org  Sun Feb 13 19:11:26 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 14 Feb 2022 00:11:26 +0000
Subject: [issue46743] Enable usage of object.__orig_class__ in __init__
In-Reply-To: <1644796195.73.0.52600427485.issue46743@roundup.psfhosted.org>
Message-ID: <1644797486.0.0.608711344635.issue46743@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

In the early days the design and implementation were changed so many times, your question (why was it changed) is unanswerable.

I do not actually understand your description of your problem -- you mention so many dunders that it obscures your use case.

Can you provide a small example use case that demonstrates code that currently doesn't work but that you think ought to work, and walk us through it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46743>
_______________________________________

From report at bugs.python.org  Sun Feb 13 19:23:28 2022
From: report at bugs.python.org (Gobot1234)
Date: Mon, 14 Feb 2022 00:23:28 +0000
Subject: [issue46743] Enable usage of object.__orig_class__ in __init__
In-Reply-To: <1644796195.73.0.52600427485.issue46743@roundup.psfhosted.org>
Message-ID: <1644798208.54.0.0439790034798.issue46743@roundup.psfhosted.org>


Gobot1234 <gobot1234yt at gmail.com> added the comment:

Currently I have code that uses the generic argument to a class as the constructor for its `items` https://github.com/Gobot1234/steam.py/blob/f99cb77d58b552f1d493663e7b3455f94977347e/steam/trade.py#L380. As this is called from `BaseInventory.__init__` it currently fails if I just subclass `GenericAlias`, so I had to implement `__call__` myself https://github.com/Gobot1234/steam.py/blob/f99cb77d58b552f1d493663e7b3455f94977347e/steam/trade.py#L299-L307.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46743>
_______________________________________

From report at bugs.python.org  Sun Feb 13 19:39:55 2022
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 14 Feb 2022 00:39:55 +0000
Subject: [issue46726] Thread spuriously marked dead after interrupting a join
 call
In-Reply-To: <1644623233.63.0.43795348291.issue46726@roundup.psfhosted.org>
Message-ID: <1644799195.69.0.720809671882.issue46726@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> Anything at the Python level that cares whether the thread is 
> still alive will call _wait_for_tstate_lock() again

It's nice that _maintain_shutdown_locks() gets called in _stop(), but the more important call site is in _set_tstate_lock().

I typed up the example initially with try/finally. Then I changed it to avoid the extra lock.locked() call when there's no exception, but I forgot to add a `raise` statement:

        try:
            if lock.acquire_and_release(block, timeout):
                self._stop
        except:
            if not lock.locked():
                self._stop()
            raise

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46726>
_______________________________________

From report at bugs.python.org  Sun Feb 13 20:03:05 2022
From: report at bugs.python.org (Tim Peters)
Date: Mon, 14 Feb 2022 01:03:05 +0000
Subject: [issue46726] Thread spuriously marked dead after interrupting a join
 call
In-Reply-To: <1644623233.63.0.43795348291.issue46726@roundup.psfhosted.org>
Message-ID: <1644800585.91.0.902729501528.issue46726@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

> It's nice that _maintain_shutdown_locks() gets
> called in _stop(), but the more important call site is in
> _set_tstate_lock().

I didn't have that in mind at all. What at the Python level cares whether the thread is alive? Well. is_alive() does, and it calls _wait_for_tstate_lock() __repr__() does, and it calls is_alive() (which I added years ago, else repr could keep claiming a thread was alive weeks ;-) after it actually ended). join() does, and it calls _wait_for_tstate_lock().

Anything else? Not off the top of my head. The point is that if _wait_for_tstate_lock() fails to call _stop() for some reason when it "should have" called it, it's not fatal. Anything that _cares_ will call it again. Indeed, it was all designed so that it could be called any number of times, redundantly or not, and without any explicit synchronization.

For the rest, I value clarity above all else here. This code has a long history of being the subject of bug reports. The cost of an "extra" call to .locked() is just trivial, especially given that calls to _wait_for_tstate_lock() are typically rare.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46726>
_______________________________________

From report at bugs.python.org  Sun Feb 13 20:14:27 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 14 Feb 2022 01:14:27 +0000
Subject: [issue46743] Enable usage of object.__orig_class__ in __init__
In-Reply-To: <1644796195.73.0.52600427485.issue46743@roundup.psfhosted.org>
Message-ID: <1644801267.51.0.427549093909.issue46743@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

I'm sorry, that's not a small example that I can follow, and I have no idea why you are doing all those things.

I fear that if you cannot be more articulate this will remain unfixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46743>
_______________________________________

From report at bugs.python.org  Sun Feb 13 20:39:22 2022
From: report at bugs.python.org (Gobot1234)
Date: Mon, 14 Feb 2022 01:39:22 +0000
Subject: [issue46743] Enable usage of object.__orig_class__ in __init__
In-Reply-To: <1644796195.73.0.52600427485.issue46743@roundup.psfhosted.org>
Message-ID: <1644802762.6.0.86533921793.issue46743@roundup.psfhosted.org>


Gobot1234 <gobot1234yt at gmail.com> added the comment:

```py
class DefaultBox(Generic[T]):
    def __init__(self, value: T | None = None):
        self.value = (
            value if value is not None else  # the arg
            self.__orig_class__.__args__[0]()  # or the default for the type argument 
        )

int_box = DefaultBox[int]()
print(int_box.value)  # should print 0
str_box = DefaultBox[str](value="this")
print(str_box.value)  # should print this
```
Currently this doesn't work, but I really think it should.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46743>
_______________________________________

From report at bugs.python.org  Sun Feb 13 20:43:02 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Mon, 14 Feb 2022 01:43:02 +0000
Subject: [issue46743] Enable usage of object.__orig_class__ in __init__
In-Reply-To: <1644796195.73.0.52600427485.issue46743@roundup.psfhosted.org>
Message-ID: <1644802982.16.0.797666615806.issue46743@roundup.psfhosted.org>


Change by Jelle Zijlstra <jelle.zijlstra at gmail.com>:


----------
nosy: +Jelle Zijlstra

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46743>
_______________________________________

From report at bugs.python.org  Sun Feb 13 20:47:31 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Mon, 14 Feb 2022 01:47:31 +0000
Subject: [issue46740] Improve Telnetlib's throughput
In-Reply-To: <1644783460.72.0.175033327075.issue46740@roundup.psfhosted.org>
Message-ID: <1644803251.78.0.0496681010861.issue46740@roundup.psfhosted.org>


Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:

Note that telnetlib is being proposed for deprecation in PEP 594. You may be better off using a third-party telnet implementation; the PEP lists https://pypi.org/project/telnetlib3/ and https://pypi.org/project/Exscript/.

----------
nosy: +Jelle Zijlstra

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46740>
_______________________________________

From report at bugs.python.org  Sun Feb 13 20:55:14 2022
From: report at bugs.python.org (Alex Waygood)
Date: Mon, 14 Feb 2022 01:55:14 +0000
Subject: [issue46743] Enable usage of object.__orig_class__ in __init__
In-Reply-To: <1644796195.73.0.52600427485.issue46743@roundup.psfhosted.org>
Message-ID: <1644803714.75.0.504731315468.issue46743@roundup.psfhosted.org>


Change by Alex Waygood <Alex.Waygood at Gmail.com>:


----------
nosy: +AlexWaygood

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46743>
_______________________________________

From report at bugs.python.org  Sun Feb 13 21:05:26 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 14 Feb 2022 02:05:26 +0000
Subject: [issue46743] Enable usage of object.__orig_class__ in __init__
In-Reply-To: <1644796195.73.0.52600427485.issue46743@roundup.psfhosted.org>
Message-ID: <1644804326.76.0.480942442326.issue46743@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Thanks for the small example, I understand what you are trying to do now.

I don't think it's possible in general, since you are blindly instantiating the type (self.__orig_class__.__args__[0]) without arguments. That doesn't work for all types.

But that aside, the problem with implementing what you wish is that we would have to refactor class instantiation to break it in two parts, one part that calls __new__() and produces the instance, and one part that (if certain conditions are satisifed) calls __init__().

I now also understand the two code fragments you gave, and breaking the construction in those two parts is exactly what you are doing there.

However. The "if certain conditions are satisfied" part is complex. For example, self.__origin__.__new__() could return an instance of a different type -- if that's not a subclass of self.__origin__, the call to __init__() will be skipped.

There may also be other that happen between __new__() and __init__(), and other things may happen before __new__() or after __init__() that we would skip by simply calling __new__() followed by __init__() ourselves -- someone else should research this.

And we may have the same issue in the C code in ga_call() in genericaliasobject.c. (I'm not sure if that's relevant.)

I'm also not sure what static type checkers would make of this. But I presume you don't care about that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46743>
_______________________________________

From report at bugs.python.org  Sun Feb 13 21:08:58 2022
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 14 Feb 2022 02:08:58 +0000
Subject: [issue46726] Thread spuriously marked dead after interrupting a join
 call
In-Reply-To: <1644623233.63.0.43795348291.issue46726@roundup.psfhosted.org>
Message-ID: <1644804538.44.0.608951312471.issue46726@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> I didn't have that in mind at all.

I understood what you had in mind, and I don't disagree. I was just highlighting that the only somewhat important work done in _stop() is to clean up the _shutdown_locks set, to keep it from growing too large. But that task is already handled when creating a new thread, and it's arguably more important to handle it there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46726>
_______________________________________

From report at bugs.python.org  Sun Feb 13 21:15:04 2022
From: report at bugs.python.org (=?utf-8?q?Robert-Andr=C3=A9_Mauchin?=)
Date: Mon, 14 Feb 2022 02:15:04 +0000
Subject: [issue46745] Typo in new PositionsIterator
Message-ID: <1644804903.84.0.228689662177.issue46745@roundup.psfhosted.org>


New submission from Robert-Andr? Mauchin <zebob.m at gmail.com>:

In Objects/codeobject.c, poisitions_iterator should read positions_iterator

----------
components: C API
messages: 413209
nosy: eclipseo
priority: normal
pull_requests: 29479
severity: normal
status: open
title: Typo in new PositionsIterator
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46745>
_______________________________________

From report at bugs.python.org  Sun Feb 13 22:33:18 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 14 Feb 2022 03:33:18 +0000
Subject: [issue46746] IDLE: Consistently handle non .py source files
Message-ID: <1644809598.08.0.43493225596.issue46746@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Python will attempt to execute any file it can decode to unicode text as a startup script.  It will only import .py files as a module.  #45447 turned on syntax coloring for .pyi stub files.  (.pyw files and files starting with "!#.*python" were already recognized as source (scripts).) It also added '.pyi' as a possible python extension in open and save dialogs.

For this issue, fix some other modules, as appropriate, for non-.py files.

Pathbrowser: Except for the files in sys.path, pathbrowser only shows .py files and directories including such.  It should be easy to also list .pyw and .pyi files and directories.  Perhaps a button could be added to list all files.

Open Module: Opens a module when given a valid import name.  So it cannot be used to open non-modules, which is to say, non .py files.  .pyi files are condensed modules, not startup files, but opening them would require considerable change since the import machinery is currently used.  We could add a message to the box saying, "To open a non-module (non .py) file, use File => Open."

Modulebrowser: This was originally called Classbrowser as it only browsed top-level classes and their methods.  It now browses all classes and def-ined functions and I renamed it to indicate the expanded scope. Since it only browses .py files, I did not know that I was theoretically narrowing the scope to exclude non-.py files.

Currently, when editing a non-.py file and trying to open a module browser, a window is opened and nothing happens.  This is the same as with a file with no classes or functions.  Either browse or display an error message.  The latter would include files with nothing to browse.

Anything else?

----------
assignee: terry.reedy
components: IDLE
messages: 413210
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: IDLE: Consistently handle non .py source files
type: enhancement
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46746>
_______________________________________

From report at bugs.python.org  Sun Feb 13 22:35:10 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 14 Feb 2022 03:35:10 +0000
Subject: [issue45447] Make IDLE recognize .pyi stub files as source for open, 
 save, and edit
In-Reply-To: <1634052276.56.0.989526823091.issue45447@roundup.psfhosted.org>
Message-ID: <1644809710.26.0.171220604488.issue45447@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Issue 46746 is the followup for browsers (currently restricted to .py files) and anything else.

----------
title: Make IDLE recognize .pyi stub files (and .pyw) as python source -> Make IDLE recognize .pyi stub files as source for open, save, and edit

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45447>
_______________________________________

From report at bugs.python.org  Sun Feb 13 23:09:32 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 14 Feb 2022 04:09:32 +0000
Subject: [issue46735] gettext.translations crashes when locale is unset
In-Reply-To: <1644716033.71.0.382285385303.issue46735@roundup.psfhosted.org>
Message-ID: <1644811772.67.0.897971298398.issue46735@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
components: +Library (Lib) -Parser
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46735>
_______________________________________

From report at bugs.python.org  Mon Feb 14 00:15:32 2022
From: report at bugs.python.org (Mehdi2277)
Date: Mon, 14 Feb 2022 05:15:32 +0000
Subject: [issue46743] Enable usage of object.__orig_class__ in __init__
In-Reply-To: <1644796195.73.0.52600427485.issue46743@roundup.psfhosted.org>
Message-ID: <1644815732.91.0.0719476209699.issue46743@roundup.psfhosted.org>


Mehdi2277 <med2277 at gmail.com> added the comment:

Hmm, I actually have code that does something very similar to that. But it does not set it in `__init__` and instead uses it in a property where it is available. Tweaking your code,

```py
class DefaultBox(Generic[T]):
    def __init__(self, value: T | None = None):
        self._default_value = value
        self._value_set = False
   
     @property
     def value(self) -> T:
       if not self._value_set:
         self._value = self._default_value if self._default_value is not None else self.__orig_class__.__args__[0]()  

       return self._value
```

I think should work fine. Any reason initializing value afterwards is an issue? Or is the main goal that the original code is simpler then this lazy initialization workaround.

----------
nosy: +med2277

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46743>
_______________________________________

From report at bugs.python.org  Mon Feb 14 02:09:36 2022
From: report at bugs.python.org (Stefan Pochmann)
Date: Mon, 14 Feb 2022 07:09:36 +0000
Subject: [issue46747] bisect.bisect/insort don't document key parameter
Message-ID: <1644822576.25.0.825142706397.issue46747@roundup.psfhosted.org>


New submission from Stefan Pochmann <stefan.pochmann at gmail.com>:

The signatures for the versions without "_right" suffix are missing the key parameter:

bisect.bisect_right(a, x, lo=0, hi=len(a), *, key=None)
bisect.bisect(a, x, lo=0, hi=len(a))?

bisect.insort_right(a, x, lo=0, hi=len(a), *, key=None)
bisect.insort(a, x, lo=0, hi=len(a))?

https://docs.python.org/3/library/bisect.html#bisect.bisect_right
https://docs.python.org/3/library/bisect.html#bisect.insort_right

----------
assignee: docs at python
components: Documentation
messages: 413213
nosy: Stefan Pochmann, docs at python
priority: normal
severity: normal
status: open
title: bisect.bisect/insort don't document key parameter
versions: Python 3.10, Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46747>
_______________________________________

From report at bugs.python.org  Mon Feb 14 03:14:01 2022
From: report at bugs.python.org (Zackery Spytz)
Date: Mon, 14 Feb 2022 08:14:01 +0000
Subject: [issue46747] bisect.bisect/insort don't document key parameter
In-Reply-To: <1644822576.25.0.825142706397.issue46747@roundup.psfhosted.org>
Message-ID: <1644826441.2.0.711189990472.issue46747@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 2.0 -> 3.0
pull_requests: +29480
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31323

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46747>
_______________________________________

From report at bugs.python.org  Mon Feb 14 03:21:27 2022
From: report at bugs.python.org (Zackery Spytz)
Date: Mon, 14 Feb 2022 08:21:27 +0000
Subject: [issue46747] bisect.bisect/insort don't document key parameter
In-Reply-To: <1644822576.25.0.825142706397.issue46747@roundup.psfhosted.org>
Message-ID: <1644826887.63.0.268216695417.issue46747@roundup.psfhosted.org>


Zackery Spytz <zspytz at gmail.com> added the comment:

Thank you for the report.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46747>
_______________________________________

From report at bugs.python.org  Mon Feb 14 04:27:18 2022
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 14 Feb 2022 09:27:18 +0000
Subject: [issue46716] regrtest didn't respect the timeout when running
 test_subprocess on AMD64 Windows11 3.x
In-Reply-To: <1644534557.28.0.000333882929265.issue46716@roundup.psfhosted.org>
Message-ID: <1644830838.55.0.519098782831.issue46716@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> I fear the potential 3rd-party breakage alone should bump
> this to its own issue.

The change to the DWORD converter in _winapi should only be in 3.11+. If this causes problems for other projects, they're probably depending on undefined behavior in the standard library. No third-party package or application should use _winapi directly.

> 1) modify Windows Popen._wait() to raise on out of bounds 
> values [< 0 or >= INFINITE]

I think raising ValueError would be best at this level. For example:

            if timeout is None:
                timeout_millis = _winapi.INFINITE
            else:
                timeout_millis = int(timeout * 1000)
                if timeout_millis >= _winapi.INFINITE:
                    raise ValueError("'timeout' exceeds the platform limit")
                if timeout_millis < 0:
                    raise ValueError("'timeout' must be non-negative")

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46716>
_______________________________________

From report at bugs.python.org  Mon Feb 14 04:28:19 2022
From: report at bugs.python.org (Petr Viktorin)
Date: Mon, 14 Feb 2022 09:28:19 +0000
Subject: [issue46748] Python.h includes stdbool.h
Message-ID: <1644830899.62.0.590844926135.issue46748@roundup.psfhosted.org>


New submission from Petr Viktorin <encukou at gmail.com>:

In main, cpython/pystate.h newly includes stdbool.h, providing a definition for `bool` that might be incompatible with other software.

See here: https://github.com/cmusphinx/sphinxbase/pull/90

Eric, is this necessary? Would an old-school `int` do?
Or should we say it's 2022 already and everyone needs to use stdbool.hfore bools?

----------
messages: 413216
nosy: eric.snow, petr.viktorin
priority: normal
severity: normal
status: open
title: Python.h includes stdbool.h
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46748>
_______________________________________

From report at bugs.python.org  Mon Feb 14 05:14:59 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 14 Feb 2022 10:14:59 +0000
Subject: [issue46748] Python.h includes stdbool.h
In-Reply-To: <1644830899.62.0.590844926135.issue46748@roundup.psfhosted.org>
Message-ID: <1644833699.89.0.558426288253.issue46748@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Is it compatible with C++?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46748>
_______________________________________

From report at bugs.python.org  Mon Feb 14 05:16:38 2022
From: report at bugs.python.org (Alex Waygood)
Date: Mon, 14 Feb 2022 10:16:38 +0000
Subject: [issue46747] bisect.bisect/insort don't document key parameter
In-Reply-To: <1644822576.25.0.825142706397.issue46747@roundup.psfhosted.org>
Message-ID: <1644833798.19.0.255452253021.issue46747@roundup.psfhosted.org>


Change by Alex Waygood <Alex.Waygood at Gmail.com>:


----------
nosy: +rhettinger
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46747>
_______________________________________

From report at bugs.python.org  Mon Feb 14 05:22:09 2022
From: report at bugs.python.org (Alex Waygood)
Date: Mon, 14 Feb 2022 10:22:09 +0000
Subject: [issue46745] Typo in new PositionsIterator
In-Reply-To: <1644804903.84.0.228689662177.issue46745@roundup.psfhosted.org>
Message-ID: <1644834129.03.0.131510111474.issue46745@roundup.psfhosted.org>


Change by Alex Waygood <Alex.Waygood at Gmail.com>:


----------
keywords: +patch
stage:  -> patch review
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46745>
_______________________________________

From report at bugs.python.org  Mon Feb 14 05:40:14 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 14 Feb 2022 10:40:14 +0000
Subject: [issue46741] Docstring for asyncio.protocols.BufferedProtocol appears
 out of date
In-Reply-To: <1644786787.46.0.446565917898.issue46741@roundup.psfhosted.org>
Message-ID: <1644835214.78.0.9734383016.issue46741@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Alex, you are right. BufferedProtocol is considered stable since 3.8
A pull request with docstring fix is welcome.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46741>
_______________________________________

From report at bugs.python.org  Mon Feb 14 05:41:10 2022
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 14 Feb 2022 10:41:10 +0000
Subject: [issue46716] regrtest didn't respect the timeout when running
 test_subprocess on AMD64 Windows11 3.x
In-Reply-To: <1644534557.28.0.000333882929265.issue46716@roundup.psfhosted.org>
Message-ID: <1644835270.35.0.721612331152.issue46716@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> 4) use Job objects to group Windows processes for termination

I think a separate issue should be created for this enhancement.

_winapi wrappers would be needed for CreateJobObjectW(), SetInformationJobObject(), AssignProcessToJobObject(), TerminatejobObject(), and ResumeThread(), plus the constant CREATE_SUSPENDED. I'd also prefer to make related changes to send_signal(), which would require GetConsoleProcessList() and GenerateConsoleCtrlEvent().

A new Popen option would be needed to configure whether the job allows descendants to break away via the process creation flag CREATE_BREAKAWAY_FROM_JOB. This should be allowed by default.

---

send_signal(): SIGKILL, SIGTERM, SIBREAK, SIGINT

Support Popen.kill(group=False) and Popen.terminate(group=False) on all platforms as Popen.send_signal(signal.SIGKILL, group=group) and Popen.send_signal(signal.SIGTERM, group=group).

The Universal CRT (ucrt) in Windows doesn't define SIGKILL. Even when it's not defined by the platform, signal.SIGKILL should always be defined, preferably as 9 (unused by ucrt), else as an unused value in the range up to NSIG, else as NSIG + 1.

The `group` keyword-only option broadens the scope to the process group or job. A process is a group leader if it was created with the flag CREATE_NEW_PROCESS_GROUP (save self._creationflags) and its process ID is in GetConsoleProcessList().

For SIGKILL, always use forced termination. For SIGTERM, use forced termination either if `group` is false or if `group` is true and the process is not a group leader. To force termination, call TerminateJobObject(self._job_handle, 1) if `group` is true, else TerminateProcess(self._handle, 1). 

For SIGTERM, SIGBREAK, and SIGINT, call GenerateConsoleCtrlEvent() if `group` is true and the process is a group leader. For SIGTERM and SIGBREAK, send CTRL_BREAK_EVENT. For SIGINT, send CTRL_C_EVENT. 

Behavior to deprecate:

When `group` is false and `sig` is CTRL_C_EVENT (0) or CTRL_BREAK_EVENT (1), send_signal() always calls os.kill(). This legacy behavior tries to handle a process as if it's a process group, and it combines POSIX kill() with Windows API constants. subprocess should distance itself from the fundamental problems with os.kill() in Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46716>
_______________________________________

From report at bugs.python.org  Mon Feb 14 05:42:50 2022
From: report at bugs.python.org (Petr Viktorin)
Date: Mon, 14 Feb 2022 10:42:50 +0000
Subject: [issue46748] Python.h includes stdbool.h
In-Reply-To: <1644830899.62.0.590844926135.issue46748@roundup.psfhosted.org>
Message-ID: <1644835370.39.0.9181439119.issue46748@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

Yes, stdbool.h is essentially a backport of C++'s bool type to C.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46748>
_______________________________________

From report at bugs.python.org  Mon Feb 14 06:06:07 2022
From: report at bugs.python.org (Gobot1234)
Date: Mon, 14 Feb 2022 11:06:07 +0000
Subject: [issue46743] Enable usage of object.__orig_class__ in __init__
In-Reply-To: <1644796195.73.0.52600427485.issue46743@roundup.psfhosted.org>
Message-ID: <1644836767.59.0.860191212667.issue46743@roundup.psfhosted.org>


Gobot1234 <gobot1234yt at gmail.com> added the comment:

On the general class instanciation point would there be anything wrong with just adding a big red warning saying (on the non-existent) docs for these classes that they don't follow normal class initization or is this too insignificant of an issue to bother?

> I don't think it's possible in general, since you are blindly instantiating the type (self.__orig_class__.__args__[0]) without arguments. That doesn't work for all types.

I think you could make this work with a Protocol as the bound TypeVar("T", bound=HasTheCorrectNewSignature)?

> I'm also not sure what static type checkers would make of this. But I presume you don't care about that.

Yeah considering this is only accessed in one place and how likely difficult it would be to implement it doesn't bother me much no. (You can avoid the attribute access errors using __orig_class__: GenericAlias if you know what your doing is always safe).

> Or is the main goal that the original code is simpler then this lazy initialization workaround.

Pretty much yeah I'd like the code to be much simplier and avoid this work around (although you could probably simplify it with a cached_property)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46743>
_______________________________________

From report at bugs.python.org  Mon Feb 14 06:30:00 2022
From: report at bugs.python.org (Tzu-ping Chung)
Date: Mon, 14 Feb 2022 11:30:00 +0000
Subject: [issue46622] Support decorating a coroutine with
 functools.cached_property
In-Reply-To: <1643873308.65.0.92890586202.issue46622@roundup.psfhosted.org>
Message-ID: <1644838200.18.0.991000957314.issue46622@roundup.psfhosted.org>


Tzu-ping Chung <uranusjr at gmail.com> added the comment:

I agree that `print(await a.hello)` does look awkward, although I know some would disagree. (Context: I submitted this BPO after a colleague of mine at $WORK pointed out the behavioural difference between `functools` and `cached_property to me.)

Personally I?d feel this more natural:

class Foo:
    @functools.cache
    async def go(self):
        print(1)

async def main():
    foo = Foo()
    await foo.go()
    await foo.go()

Although now I just noticed this actually does not work either.

Perhaps we should fix this instead and add a line in the documentation under cached_property to point people to the correct path?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46622>
_______________________________________

From report at bugs.python.org  Mon Feb 14 07:39:07 2022
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 14 Feb 2022 12:39:07 +0000
Subject: [issue46072] Unify handling of stats in the CPython VM
In-Reply-To: <1639498673.65.0.709719181358.issue46072@roundup.psfhosted.org>
Message-ID: <1644842347.9.0.255627290323.issue46072@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
pull_requests: +29481
pull_request: https://github.com/python/cpython/pull/31324

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46072>
_______________________________________

From report at bugs.python.org  Mon Feb 14 08:29:26 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 14 Feb 2022 13:29:26 +0000
Subject: [issue46622] Support decorating a coroutine with
 functools.cached_property
In-Reply-To: <1643873308.65.0.92890586202.issue46622@roundup.psfhosted.org>
Message-ID: <1644845366.81.0.150558271716.issue46622@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Agree. Let's start from async functions support by `functools.lru_cache`. 

If we will have an agreement that cached_property is an important use-case we can return to this issue.

I have a feeling that async lru_cache is much more important. https://pypi.org/project/async_lru/ has 0.5 million downloads per month: https://pypistats.org/packages/async-lru

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46622>
_______________________________________

From report at bugs.python.org  Mon Feb 14 09:23:11 2022
From: report at bugs.python.org (autoantwort)
Date: Mon, 14 Feb 2022 14:23:11 +0000
Subject: [issue46749] Support cross compilation on macOS
Message-ID: <1644848591.29.0.688015722934.issue46749@roundup.psfhosted.org>


New submission from autoantwort <Leander.Schulten at rwth-aachen.de>:

Currently you get the following output:
```
?  debug git:(main) ? ../configure --host=x86_64-apple-darwin --build=arm64-apple-darwin --with-build-python=./python3.11
checking for git... found
checking build system type... aarch64-apple-darwin
checking host system type... x86_64-apple-darwin
checking for --with-build-python... ./python3.11
checking for Python interpreter freezing... ./python3.11
checking for python3.11... (cached) ./python3.11
checking Python for regen version... Python 3.11.0a5+
checking for x86_64-apple-darwin-pkg-config... no
checking for pkg-config... /opt/homebrew/bin/pkg-config
configure: WARNING: using cross tools not prefixed with host triplet
checking pkg-config is at least version 0.9.0... yes
checking for --enable-universalsdk... no
checking for --with-universal-archs... no
checking MACHDEP... configure: error: cross build not supported for x86_64-apple-darwin
```

Is "needed" for https://github.com/microsoft/vcpkg/issues/22603

----------
components: Build
messages: 413224
nosy: autoantwort
priority: normal
severity: normal
status: open
title: Support cross compilation on macOS
type: enhancement
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46749>
_______________________________________

From report at bugs.python.org  Mon Feb 14 09:24:18 2022
From: report at bugs.python.org (autoantwort)
Date: Mon, 14 Feb 2022 14:24:18 +0000
Subject: [issue46749] Support cross compilation on macOS
In-Reply-To: <1644848591.29.0.688015722934.issue46749@roundup.psfhosted.org>
Message-ID: <1644848658.25.0.991841371375.issue46749@roundup.psfhosted.org>


Change by autoantwort <Leander.Schulten at rwth-aachen.de>:


----------
components: +Cross-Build -Build
nosy: +Alex.Willmer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46749>
_______________________________________

From report at bugs.python.org  Mon Feb 14 09:35:52 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 14 Feb 2022 14:35:52 +0000
Subject: [issue46622] Support decorating a coroutine with
 functools.cached_property
In-Reply-To: <1643873308.65.0.92890586202.issue46622@roundup.psfhosted.org>
Message-ID: <1644849352.23.0.647319191588.issue46622@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Note that there is a similar issue with cached generators.

>>> from functools import *
>>> @lru_cache()
... def g():
...     yield 1
... 
>>> list(g())
[1]
>>> list(g())
[]

I am not sure that it is safe to detect awaitables and iterables in caching decorators and automatically wrap them in re-awaitable and re-iterable objects. But we can add explicit decorators and combine them with arbitrary caching decorators. For example:

@lru_cache()
@reiterable
def g():
    yield 1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46622>
_______________________________________

From report at bugs.python.org  Mon Feb 14 09:46:21 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 14 Feb 2022 14:46:21 +0000
Subject: [issue46622] Support decorating a coroutine with
 functools.cached_property
In-Reply-To: <1643873308.65.0.92890586202.issue46622@roundup.psfhosted.org>
Message-ID: <1644849981.39.0.00996557612249.issue46622@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

>From my point of view, both sync and async functions can be cached.

Sync and async iterators/generators are other beasts: they don't return a value but generate a series of items. The series can be long and memory-consuming, I doubt if it should be cached safely.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46622>
_______________________________________

From report at bugs.python.org  Mon Feb 14 09:48:26 2022
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 14 Feb 2022 14:48:26 +0000
Subject: [issue46724] Odd Bytecode Generation in 3.10
In-Reply-To: <1644600146.24.0.968453673832.issue46724@roundup.psfhosted.org>
Message-ID: <1644850106.48.0.509932442762.issue46724@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
pull_requests: +29482
pull_request: https://github.com/python/cpython/pull/31326

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46724>
_______________________________________

From report at bugs.python.org  Mon Feb 14 09:56:24 2022
From: report at bugs.python.org (Alex Waygood)
Date: Mon, 14 Feb 2022 14:56:24 +0000
Subject: [issue46741] Docstring for asyncio.protocols.BufferedProtocol appears
 out of date
In-Reply-To: <1644786787.46.0.446565917898.issue46741@roundup.psfhosted.org>
Message-ID: <1644850584.89.0.747302523212.issue46741@roundup.psfhosted.org>


Change by Alex Waygood <Alex.Waygood at Gmail.com>:


----------
keywords: +patch
pull_requests: +29483
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31327

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46741>
_______________________________________

From report at bugs.python.org  Mon Feb 14 09:57:41 2022
From: report at bugs.python.org (Alex Waygood)
Date: Mon, 14 Feb 2022 14:57:41 +0000
Subject: [issue46741] Docstring for asyncio.protocols.BufferedProtocol appears
 out of date
In-Reply-To: <1644786787.46.0.446565917898.issue46741@roundup.psfhosted.org>
Message-ID: <1644850661.12.0.270253113964.issue46741@roundup.psfhosted.org>


Alex Waygood <Alex.Waygood at Gmail.com> added the comment:

Thanks, Andrew! I've submitted a patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46741>
_______________________________________

From report at bugs.python.org  Mon Feb 14 10:49:15 2022
From: report at bugs.python.org (Meer Suri)
Date: Mon, 14 Feb 2022 15:49:15 +0000
Subject: [issue46586] In documentation contents enum.property erroneously
 links to built-in property
In-Reply-To: <1643555525.86.0.209520180874.issue46586@roundup.psfhosted.org>
Message-ID: <1644853755.41.0.843148674876.issue46586@roundup.psfhosted.org>


Meer Suri <meersuri at gmail.com> added the comment:

https://docs.python.org/3.11/library/io.html?highlight=io#text-i-o -

The easiest way to create a text stream is with open(), optionally specifying an encoding:

https://docs.python.org/3.11/library/io.html?highlight=io#binary-i-o - 

The easiest way to create a binary stream is with open() with 'b' in the mode string:

For both of these cases, the markup for the open() is :meth:`open()` but it links to the builtins open(), which I see is an alias of io.open() so maybe it doesn't matter?
Another question is why do only these two instances use :meth: while the other instances in the file use :func: (some refer directly to builtins open() so its understandable, but not all instances)
I'm wondering if the above two should be left alone or changed to :meth:`~io.open` or even :func:`open`

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46586>
_______________________________________

From report at bugs.python.org  Mon Feb 14 10:55:15 2022
From: report at bugs.python.org (Shivaram Lingamneni)
Date: Mon, 14 Feb 2022 15:55:15 +0000
Subject: [issue46750] some code paths in ssl and _socket still import idna
 unconditionally
Message-ID: <1644854115.6.0.132786473021.issue46750@roundup.psfhosted.org>


New submission from Shivaram Lingamneni <slingamn at cs.stanford.edu>:

Importing the idna encoding has a significant time and memory cost. Therefore, the standard library tries to avoid importing it when it's not needed (i.e. when the domain name is already pure ASCII), e.g. in Lib/http/client.py and Modules/socketmodule.c with `idna_converter`.

However, there are code paths that still attempt to encode or decode as idna unconditionally, in particular Lib/ssl.py and _socket.getaddrinfo. Here's a one-line test case:

python3 -c "import sys, urllib.request; urllib.request.urlopen('https://www.google.com'); assert 'encodings.idna' not in sys.modules"

These code paths can be converted using existing code to do the import conditionally (I'll send a PR).

----------
assignee: christian.heimes
components: Interpreter Core, Library (Lib), SSL
messages: 413229
nosy: christian.heimes, slingamn
priority: normal
severity: normal
status: open
title: some code paths in ssl and _socket still import idna unconditionally
type: resource usage
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46750>
_______________________________________

From report at bugs.python.org  Mon Feb 14 11:06:41 2022
From: report at bugs.python.org (Shivaram Lingamneni)
Date: Mon, 14 Feb 2022 16:06:41 +0000
Subject: [issue46750] some code paths in ssl and _socket still import idna
 unconditionally
In-Reply-To: <1644854115.6.0.132786473021.issue46750@roundup.psfhosted.org>
Message-ID: <1644854801.48.0.372649762064.issue46750@roundup.psfhosted.org>


Change by Shivaram Lingamneni <slingamn at cs.stanford.edu>:


----------
keywords: +patch
pull_requests: +29484
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31328

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46750>
_______________________________________

From report at bugs.python.org  Mon Feb 14 11:16:59 2022
From: report at bugs.python.org (Dennis Sweeney)
Date: Mon, 14 Feb 2022 16:16:59 +0000
Subject: [issue46747] bisect.bisect/insort don't document key parameter
In-Reply-To: <1644822576.25.0.825142706397.issue46747@roundup.psfhosted.org>
Message-ID: <1644855419.85.0.984214840972.issue46747@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:


New changeset 96084f4256d2d523b0a4d7d900322b032326e3ed by Zackery Spytz in branch 'main':
bpo-46747: Add missing key parameters in the bisect docs (GH-31323)
https://github.com/python/cpython/commit/96084f4256d2d523b0a4d7d900322b032326e3ed


----------
nosy: +Dennis Sweeney

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46747>
_______________________________________

From report at bugs.python.org  Mon Feb 14 11:24:30 2022
From: report at bugs.python.org (Dennis Sweeney)
Date: Mon, 14 Feb 2022 16:24:30 +0000
Subject: [issue46747] bisect.bisect/insort don't document key parameter
In-Reply-To: <1644822576.25.0.825142706397.issue46747@roundup.psfhosted.org>
Message-ID: <1644855870.79.0.822597143512.issue46747@roundup.psfhosted.org>


Change by Dennis Sweeney <sweeney.dennis650 at gmail.com>:


----------
pull_requests: +29485
pull_request: https://github.com/python/cpython/pull/31329

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46747>
_______________________________________

From report at bugs.python.org  Mon Feb 14 11:32:14 2022
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 14 Feb 2022 16:32:14 +0000
Subject: [issue46750] some code paths in ssl and _socket still import idna
 unconditionally
In-Reply-To: <1644854115.6.0.132786473021.issue46750@roundup.psfhosted.org>
Message-ID: <1644856334.75.0.0937374375451.issue46750@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Please provide benchmarks and data for your claim that encodings.idna is a performance bottleneck.

encodings.idna is a simple, short module without state. On my system it takes about 0.15 msec to import the module. When unicodedata and stringprep aren't loaded yet, it still takes less than 0.5 msec. The stringprep and unicodedata modules are used by other modules, e.g. urllib parse. It's likely that any non-trivial program with network access has both imported already.

$ python3 -m timeit -s "import sys" "import encodings.idna; sys.modules.pop('encodings.idna'); sys.modules.pop('stringprep'); sys.modules.pop('unicodedata')"
500 loops, best of 5: 488 usec per loop


The IDNA codec performs additional verification of the input. You cannot replace it with a simple "try encode to ASCII" block:

>>> ("a"*65).encode('idna')
Traceback (most recent call last):
  File "/usr/lib64/python3.10/encodings/idna.py", line 167, in encode
    raise UnicodeError("label too long")
UnicodeError: label too long

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeError: encoding with 'idna' codec failed (UnicodeError: label too long)

----------
assignee: christian.heimes -> 
stage: patch review -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46750>
_______________________________________

From report at bugs.python.org  Mon Feb 14 11:34:58 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 14 Feb 2022 16:34:58 +0000
Subject: [issue46743] Enable usage of object.__orig_class__ in __init__
In-Reply-To: <1644796195.73.0.52600427485.issue46743@roundup.psfhosted.org>
Message-ID: <1644856498.55.0.697704605397.issue46743@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

> On the general class instanciation point would there be anything wrong with just adding a big red warning saying (on the non-existent) docs for these classes that they don't follow normal class initization or is this too insignificant of an issue to bother?

Which classes? Every class that inherits from Generic? That would be problematic -- we don't want the addition of typing information to change the behavior of a construct (or at least as little as possible).

> I think you could make this work with a Protocol as the bound TypeVar("T", bound=HasTheCorrectNewSignature)?

Sure.

But I am still inclined to reject the feature request as too obscure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46743>
_______________________________________

From report at bugs.python.org  Mon Feb 14 11:51:32 2022
From: report at bugs.python.org (Dennis Sweeney)
Date: Mon, 14 Feb 2022 16:51:32 +0000
Subject: [issue46747] bisect.bisect/insort don't document key parameter
In-Reply-To: <1644822576.25.0.825142706397.issue46747@roundup.psfhosted.org>
Message-ID: <1644857492.09.0.75616156928.issue46747@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:


New changeset 841c77d802e9ee8845fa3152700474021efe03fd by Dennis Sweeney in branch '3.10':
[3.10] bpo-46747: Add missing key parameters in the bisect docs (GH-31323) (GH-31329)
https://github.com/python/cpython/commit/841c77d802e9ee8845fa3152700474021efe03fd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46747>
_______________________________________

From report at bugs.python.org  Mon Feb 14 11:53:01 2022
From: report at bugs.python.org (Dennis Sweeney)
Date: Mon, 14 Feb 2022 16:53:01 +0000
Subject: [issue46747] bisect.bisect/insort don't document key parameter
In-Reply-To: <1644822576.25.0.825142706397.issue46747@roundup.psfhosted.org>
Message-ID: <1644857581.19.0.0253898560977.issue46747@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

Thanks for the report, Stefan!
Thanks for the PR, Zackery!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46747>
_______________________________________

From report at bugs.python.org  Mon Feb 14 11:54:52 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Mon, 14 Feb 2022 16:54:52 +0000
Subject: [issue46679] test.support.wait_process ignores timeout argument
In-Reply-To: <1644268945.76.0.936309177383.issue46679@roundup.psfhosted.org>
Message-ID: <1644857692.68.0.188957950483.issue46679@roundup.psfhosted.org>


Change by Nikita Sobolev <mail at sobolevn.me>:


----------
nosy: +sobolevn
nosy_count: 1.0 -> 2.0
pull_requests: +29486
pull_request: https://github.com/python/cpython/pull/31274

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46679>
_______________________________________

From report at bugs.python.org  Mon Feb 14 11:55:00 2022
From: report at bugs.python.org (Eric Snow)
Date: Mon, 14 Feb 2022 16:55:00 +0000
Subject: [issue46748] Python.h includes stdbool.h
In-Reply-To: <1644830899.62.0.590844926135.issue46748@roundup.psfhosted.org>
Message-ID: <CALFfu7BihNwjJ4jue5y1zgS6yMmD1d7DEAaWf-zmC4nTrL3vaQ@mail.gmail.com>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

On Mon, Feb 14, 2022 at 2:28 AM Petr Viktorin <report at bugs.python.org> wrote:
> Eric, is this necessary? Would an old-school `int` do?
> Or should we say it's 2022 already and everyone needs to use stdbool.hfore bools?

I started using ``bool`` (stdbool.h) when I saw it specified in PEP 7
(https://www.python.org/dev/peps/pep-0007/#c-dialect).  If it is a
problem then I think it should be answered relative to PEP 7.  I'm not
sure what the best route is though.  Personally, I'd argue that if
it's in C99 then it should probably be standard at this point. :)
However, I'm not opposed to going back to plain int.  (And I know
there are definitely a number of old-school folks who prefer plain
int. :) )

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46748>
_______________________________________

From report at bugs.python.org  Mon Feb 14 11:59:15 2022
From: report at bugs.python.org (Gobot1234)
Date: Mon, 14 Feb 2022 16:59:15 +0000
Subject: [issue46743] Enable usage of object.__orig_class__ in __init__
In-Reply-To: <1644796195.73.0.52600427485.issue46743@roundup.psfhosted.org>
Message-ID: <1644857955.15.0.849133724302.issue46743@roundup.psfhosted.org>


Gobot1234 <gobot1234yt at gmail.com> added the comment:

> Which classes? Every class that inherits from Generic? That would be problematic -- we don't want the addition of typing information to change the behavior of a construct (or at least as little as possible).

The class itself would remain unchanged, the only thing I propose changing is what happens when you subscript it and then attempt to instantiate it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46743>
_______________________________________

From report at bugs.python.org  Mon Feb 14 12:00:34 2022
From: report at bugs.python.org (Shivaram Lingamneni)
Date: Mon, 14 Feb 2022 17:00:34 +0000
Subject: [issue46750] some code paths in ssl and _socket still import idna
 unconditionally
In-Reply-To: <1644854115.6.0.132786473021.issue46750@roundup.psfhosted.org>
Message-ID: <1644858034.79.0.618526400496.issue46750@roundup.psfhosted.org>


Shivaram Lingamneni <slingamn at cs.stanford.edu> added the comment:

Thanks for the prompt response. As evidence that this was of concern to the development team in the past, here's an issue where the unnecessary import of idna was treated as a regression:

https://bugs.python.org/issue22127

The discussion there also examines the semantic change produced by the optimization (some invalid labels making it to a DNS lookup instead of being rejected) and doesn't consider it to be a breaking change (albeit a reason not to backport).

(I also see references in documentation to a discussion labeled "RFE #1472176", but am unable to find the actual bug tracker or database entry this refers to.)

A time cost of 15 milliseconds seems accurate to me. The RAM cost on my release build of Python 3.8.10 is about 600 KB in RSS (this is approximately 5% of the baseline interpreter usage).

I cannot reproduce the claim that `urllib.parse` imports stringprep or unicodedata:

    python3 -c "import sys, urllib.parse; assert 'stringprep' not in sys.modules"

    python3 -c "import sys, urllib.parse; assert 'unicodedata' not in sys.modules"

I am developing a new lightweight http library that does use urllib.parse; on my system, these patches allow it to function without importing stringprep, idna, or unicodedata:

https://github.com/slingamn/mureq

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46750>
_______________________________________

From report at bugs.python.org  Mon Feb 14 12:00:51 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 14 Feb 2022 17:00:51 +0000
Subject: [issue46743] Enable usage of object.__orig_class__ in __init__
In-Reply-To: <1644857955.15.0.849133724302.issue46743@roundup.psfhosted.org>
Message-ID: <CAP7+vJL3v71Y2uO6X_c6ocsJwij6_NyYnoEsXXsvR6ZAP6KbiA@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

Yeah, that should erase the type, not have special semantics.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46743>
_______________________________________

From report at bugs.python.org  Mon Feb 14 12:02:50 2022
From: report at bugs.python.org (Petr Viktorin)
Date: Mon, 14 Feb 2022 17:02:50 +0000
Subject: [issue46748] Python.h includes stdbool.h
In-Reply-To: <1644830899.62.0.590844926135.issue46748@roundup.psfhosted.org>
Message-ID: <1644858170.46.0.111928579838.issue46748@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

It is in C99, but in an optional header.
IMO, including the header in the internals is perfectly OK, but opting everyone else in isn't very nice.
i.e. it would probably be OK to use `_Bool`, the actual C99 keyword that `bool` is defined as. But that's ugly enough to prefer `int`...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46748>
_______________________________________

From report at bugs.python.org  Mon Feb 14 12:56:17 2022
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 14 Feb 2022 17:56:17 +0000
Subject: [issue46474] Inefficient regular expression complexity in
 EntryPoint.pattern
In-Reply-To: <1642879131.5.0.511561891701.issue46474@roundup.psfhosted.org>
Message-ID: <1644861377.27.0.188618388023.issue46474@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:


New changeset 8a84aef0123bd8c13cf81fbc3b5f6d45f96c2656 by Jason R. Coombs in branch '3.8':
[3.8] bpo-46474: Avoid REDoS in EntryPoint.pattern (sync with importlib_metadata 4.10.1) (GH-30803). (#30829)
https://github.com/python/cpython/commit/8a84aef0123bd8c13cf81fbc3b5f6d45f96c2656


----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46474>
_______________________________________

From report at bugs.python.org  Mon Feb 14 13:01:32 2022
From: report at bugs.python.org (Eric Snow)
Date: Mon, 14 Feb 2022 18:01:32 +0000
Subject: [issue46541] Replace _Py_IDENTIFIER() with statically initialized
 objects.
In-Reply-To: <1643234464.46.0.949364478641.issue46541@roundup.psfhosted.org>
Message-ID: <1644861692.65.0.564304644632.issue46541@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

With core code sorted out, stdlib and 3rd party extension modules are left to sort out.

I see the following possibilities:

* leave `_Py_IDENTIFIER()` alone (it is already disallowed in core code)
* change `_Py_IDENTIFIER()` to create static string objects (then get rid of global state)
* get rid of `_Py_IDENTIFIER()`
   a. provide a public alternative (needs a PEP)
   b. first work with 3rd party projects to stop using it

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46541>
_______________________________________

From report at bugs.python.org  Mon Feb 14 13:07:47 2022
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 14 Feb 2022 18:07:47 +0000
Subject: [issue46750] some code paths in ssl and _socket still import idna
 unconditionally
In-Reply-To: <1644854115.6.0.132786473021.issue46750@roundup.psfhosted.org>
Message-ID: <1644862067.58.0.283258020663.issue46750@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

It's 100 times faster. The initial import takes about 150 ?sec (0.15msec) and it's a one time cost. IDNA encoding of a typical hostname is about 70nsec. A DNS lookup is three magnitudes slower.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46750>
_______________________________________

From report at bugs.python.org  Mon Feb 14 13:08:52 2022
From: report at bugs.python.org (Dennis Sweeney)
Date: Mon, 14 Feb 2022 18:08:52 +0000
Subject: [issue46739] dataclasses __eq__ isn't logical
In-Reply-To: <1644770146.93.0.142732009848.issue46739@roundup.psfhosted.org>
Message-ID: <1644862132.12.0.420238671025.issue46739@roundup.psfhosted.org>


Change by Dennis Sweeney <sweeney.dennis650 at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46739>
_______________________________________

From report at bugs.python.org  Mon Feb 14 13:21:09 2022
From: report at bugs.python.org (Craig Coleman)
Date: Mon, 14 Feb 2022 18:21:09 +0000
Subject: [issue46739] dataclasses __eq__ isn't logical
In-Reply-To: <1644770146.93.0.142732009848.issue46739@roundup.psfhosted.org>
Message-ID: <1644862869.85.0.204242733095.issue46739@roundup.psfhosted.org>


Craig Coleman <craig.s.r.coleman at gmail.com> added the comment:

Seems I learned a python lesson today.

I've put myself back in python school and done some reading on a) the code behind dataclasses, b) PEP 557 and c) the doc'n for __eq__.

After all the reading I've realised this I'd been making some assumptions about how __eq__ works which have now been corrected.  Thanks for your help.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46739>
_______________________________________

From report at bugs.python.org  Mon Feb 14 13:24:08 2022
From: report at bugs.python.org (Craig Coleman)
Date: Mon, 14 Feb 2022 18:24:08 +0000
Subject: [issue46739] dataclasses __eq__ isn't logical
In-Reply-To: <1644770146.93.0.142732009848.issue46739@roundup.psfhosted.org>
Message-ID: <1644863048.68.0.0200071120567.issue46739@roundup.psfhosted.org>


Craig Coleman <craig.s.r.coleman at gmail.com> added the comment:

>From  https://docs.python.org/3/reference/datamodel.html#object.__hash__

User-defined classes have __eq__() and __hash__() methods by default; with them, all objects compare unequal (except with themselves) and x.__hash__() returns an appropriate value such that x == y implies both that x is y and hash(x) == hash(y).

It doesn't work like that for tuples, NamedTuples nor dataclasses because their behaviour isn't expected to be a "user-defined class".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46739>
_______________________________________

From report at bugs.python.org  Mon Feb 14 13:24:22 2022
From: report at bugs.python.org (Shivaram Lingamneni)
Date: Mon, 14 Feb 2022 18:24:22 +0000
Subject: [issue46750] some code paths in ssl and _socket still import idna
 unconditionally
In-Reply-To: <1644854115.6.0.132786473021.issue46750@roundup.psfhosted.org>
Message-ID: <1644863062.69.0.138675044387.issue46750@roundup.psfhosted.org>


Shivaram Lingamneni <slingamn at cs.stanford.edu> added the comment:

Sorry, I should have been more clear: I am including the initial costs of importing stringprep and unicodedata. On my system:

$ python3 -c "import time; start = time.time(); r = 'a'.encode('idna'); elapsed = time.time() - start; print(elapsed)"
0.0053806304931640625

So the earlier measurement of 15 milliseconds was excessive (I'm not sure what happened) but it's the right order of magnitude: I can reproduce 5 milliseconds reliably.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46750>
_______________________________________

From report at bugs.python.org  Mon Feb 14 13:33:48 2022
From: report at bugs.python.org (Eric Snow)
Date: Mon, 14 Feb 2022 18:33:48 +0000
Subject: [issue46541] Replace _Py_IDENTIFIER() with statically initialized
 objects.
In-Reply-To: <1643234464.46.0.949364478641.issue46541@roundup.psfhosted.org>
Message-ID: <1644863628.63.0.676386474215.issue46541@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
Removed message: https://bugs.python.org/msg413241

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46541>
_______________________________________

From report at bugs.python.org  Mon Feb 14 13:34:37 2022
From: report at bugs.python.org (Eric Snow)
Date: Mon, 14 Feb 2022 18:34:37 +0000
Subject: [issue46541] Replace _Py_IDENTIFIER() with statically initialized
 objects.
In-Reply-To: <1643234464.46.0.949364478641.issue46541@roundup.psfhosted.org>
Message-ID: <1644863677.38.0.180480915184.issue46541@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

With core code sorted out, stdlib and 3rd party extension modules are left to sort out.

I see the following possibilities:

1. leave `_Py_IDENTIFIER()` alone (it is already disallowed in core code)
2. change `_Py_IDENTIFIER()` to create static string objects (then get rid of global state)
3. get rid of `_Py_IDENTIFIER()`
   a. provide a public alternative (needs a PEP)
   b. first work with 3rd party projects to stop using it

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46541>
_______________________________________

From report at bugs.python.org  Mon Feb 14 13:42:01 2022
From: report at bugs.python.org (Mike Kaganski)
Date: Mon, 14 Feb 2022 18:42:01 +0000
Subject: [issue46751] Windows-style path is not recognized under cygwin
Message-ID: <1644864121.29.0.790596029405.issue46751@roundup.psfhosted.org>


New submission from Mike Kaganski <mikekaganski at hotmail.com>:

Using cyqwin 3.3.4-2, and python3:

Python 3.9.10 (main, Jan 20 2022, 21:37:52)
[GCC 11.2.0] on cygwin

Trying this bash command line:

> python3 C:/path/to/script.py

results in this error:

"python3: can't open file '/cygdrive/c/path/to/curdir/C:/path/to/script.py': [Errno 2] No such file or directory"

OTOH, calling it like

> python3 /cygdrive/c/path/to/script.py

gives the expected output:

"usage: script.py [-h] ..."

It seems that python3 doesn't recognize "C:/path/to/script.py" to be a proper full path under cygwin, while most other cygwin apps handle those fine. E.g.,

> nano C:/path/to/script.py

opens the script for editing without problems.

The mentioned path syntax is useful and supported under cygwin, so it would be nice if python3 could support it, too. Especially useful it is in mixed development environment, mixing Windows native tools and cygwin ones; using such path style allows to use same paths for both kinds of tools, simplifying scripts.

----------
components: Windows
messages: 413247
nosy: mikekaganski, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows-style path is not recognized under cygwin
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46751>
_______________________________________

From report at bugs.python.org  Mon Feb 14 13:58:30 2022
From: report at bugs.python.org (Mariatta)
Date: Mon, 14 Feb 2022 18:58:30 +0000
Subject: [issue38619] [Doc] UUID.hex is lowercase
In-Reply-To: <1572277818.51.0.346216542748.issue38619@roundup.psfhosted.org>
Message-ID: <1644865110.68.0.363764385819.issue38619@roundup.psfhosted.org>


Mariatta <mariatta at python.org> added the comment:


New changeset 5d53cf30f9cb3758849e859db5d4602cb7c521f7 by 180909 in branch 'main':
bpo-38619: Update the documentation for UUID.hex (GH-29830)
https://github.com/python/cpython/commit/5d53cf30f9cb3758849e859db5d4602cb7c521f7


----------
nosy: +Mariatta

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38619>
_______________________________________

From report at bugs.python.org  Mon Feb 14 13:58:31 2022
From: report at bugs.python.org (miss-islington)
Date: Mon, 14 Feb 2022 18:58:31 +0000
Subject: [issue38619] [Doc] UUID.hex is lowercase
In-Reply-To: <1572277818.51.0.346216542748.issue38619@roundup.psfhosted.org>
Message-ID: <1644865111.59.0.826152818037.issue38619@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: +29487
pull_request: https://github.com/python/cpython/pull/31334

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38619>
_______________________________________

From report at bugs.python.org  Mon Feb 14 13:58:35 2022
From: report at bugs.python.org (miss-islington)
Date: Mon, 14 Feb 2022 18:58:35 +0000
Subject: [issue38619] [Doc] UUID.hex is lowercase
In-Reply-To: <1572277818.51.0.346216542748.issue38619@roundup.psfhosted.org>
Message-ID: <1644865115.91.0.47407940171.issue38619@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29488
pull_request: https://github.com/python/cpython/pull/31335

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38619>
_______________________________________

From report at bugs.python.org  Mon Feb 14 13:59:39 2022
From: report at bugs.python.org (Mariatta)
Date: Mon, 14 Feb 2022 18:59:39 +0000
Subject: [issue38619] [Doc] UUID.hex is lowercase
In-Reply-To: <1572277818.51.0.346216542748.issue38619@roundup.psfhosted.org>
Message-ID: <1644865179.06.0.772641591228.issue38619@roundup.psfhosted.org>


Mariatta <mariatta at python.org> added the comment:

Thanks. I do think it is helpful to state that it is lowercase.
I have merged the PR, and will backport to 3.10 and 3.9.

Thanks.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10, Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38619>
_______________________________________

From report at bugs.python.org  Mon Feb 14 14:00:11 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 14 Feb 2022 19:00:11 +0000
Subject: [issue46751] Windows-style path is not recognized under cygwin
In-Reply-To: <1644864121.29.0.790596029405.issue46751@roundup.psfhosted.org>
Message-ID: <1644865211.42.0.644460501434.issue46751@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Are you running from bash (or another cygwin shell), or from cmd.exe, or something else?

How did you install the version of python you're executing in the examples you provided? To my knowledge, cygwin's installer doesn't have a 3.9 available.

I don't see this behavior on cygwin's python3.8, either from cmd.exe or from zsh.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46751>
_______________________________________

From report at bugs.python.org  Mon Feb 14 14:06:42 2022
From: report at bugs.python.org (Mateusz Loskot)
Date: Mon, 14 Feb 2022 19:06:42 +0000
Subject: [issue46502] Py_CompileString no longer allows to tell "incomplete
 input" from "invalid input"
In-Reply-To: <1643039336.79.0.892958421455.issue46502@roundup.psfhosted.org>
Message-ID: <1644865602.61.0.238948437811.issue46502@roundup.psfhosted.org>


Mateusz Loskot <mateusz at loskot.net> added the comment:

Possibly, the new partial-input mode of the parser (https://bugs.python.org/issue46521#msg412832) will improve this issue in 3.11. I'm going to play with it soon and I will report back.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46502>
_______________________________________

From report at bugs.python.org  Mon Feb 14 14:07:49 2022
From: report at bugs.python.org (Shivaram Lingamneni)
Date: Mon, 14 Feb 2022 19:07:49 +0000
Subject: [issue46750] some code paths in ssl and _socket still import idna
 unconditionally
In-Reply-To: <1644854115.6.0.132786473021.issue46750@roundup.psfhosted.org>
Message-ID: <1644865669.75.0.527828462481.issue46750@roundup.psfhosted.org>


Shivaram Lingamneni <slingamn at cs.stanford.edu> added the comment:

(Looks like it was 15 milliseconds when measuring inside `python -i`; I'm not sure what the root cause of the difference is, but clearly the 5 millisecond measurement from regular `python` is more accurate.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46750>
_______________________________________

From report at bugs.python.org  Mon Feb 14 14:14:23 2022
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 14 Feb 2022 19:14:23 +0000
Subject: [issue46502] Py_CompileString no longer allows to tell "incomplete
 input" from "invalid input"
In-Reply-To: <1643039336.79.0.892958421455.issue46502@roundup.psfhosted.org>
Message-ID: <1644866063.36.0.385020496013.issue46502@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Cool! Be aware that using it outside codeop is currently unsupported:

https://github.com/python/cpython/blob/5d53cf30f9cb3758849e859db5d4602cb7c521f7/Lib/codeop.py#L43-L47

So have in mind that the flag, mechanism and semantics can change without previous notice

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46502>
_______________________________________

From report at bugs.python.org  Mon Feb 14 14:20:57 2022
From: report at bugs.python.org (miss-islington)
Date: Mon, 14 Feb 2022 19:20:57 +0000
Subject: [issue38619] [Doc] UUID.hex is lowercase
In-Reply-To: <1572277818.51.0.346216542748.issue38619@roundup.psfhosted.org>
Message-ID: <1644866457.01.0.345302367568.issue38619@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 828253227efe16f0e759df36bbb2ca49083223c8 by Miss Islington (bot) in branch '3.10':
bpo-38619: Update the documentation for UUID.hex (GH-29830)
https://github.com/python/cpython/commit/828253227efe16f0e759df36bbb2ca49083223c8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38619>
_______________________________________

From report at bugs.python.org  Mon Feb 14 14:25:34 2022
From: report at bugs.python.org (miss-islington)
Date: Mon, 14 Feb 2022 19:25:34 +0000
Subject: [issue38619] [Doc] UUID.hex is lowercase
In-Reply-To: <1572277818.51.0.346216542748.issue38619@roundup.psfhosted.org>
Message-ID: <1644866734.41.0.692710027116.issue38619@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1953f03174c18f315aca883babc3819828f868d8 by Miss Islington (bot) in branch '3.9':
bpo-38619: Update the documentation for UUID.hex (GH-29830)
https://github.com/python/cpython/commit/1953f03174c18f315aca883babc3819828f868d8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38619>
_______________________________________

From report at bugs.python.org  Mon Feb 14 14:55:14 2022
From: report at bugs.python.org (Barney Gale)
Date: Mon, 14 Feb 2022 19:55:14 +0000
Subject: [issue46733] pathlib.Path methods can raise NotImplementedError
In-Reply-To: <1644694513.05.0.985214969865.issue46733@roundup.psfhosted.org>
Message-ID: <1644868514.77.0.741870693167.issue46733@roundup.psfhosted.org>


Change by Barney Gale <barney.gale at gmail.com>:


----------
keywords: +patch
pull_requests: +29489
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31338

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46733>
_______________________________________

From report at bugs.python.org  Mon Feb 14 14:55:29 2022
From: report at bugs.python.org (Barney Gale)
Date: Mon, 14 Feb 2022 19:55:29 +0000
Subject: [issue46733] pathlib.Path methods can raise NotImplementedError
In-Reply-To: <1644694513.05.0.985214969865.issue46733@roundup.psfhosted.org>
Message-ID: <1644868529.77.0.693491217334.issue46733@roundup.psfhosted.org>


Change by Barney Gale <barney.gale at gmail.com>:


----------
pull_requests: +29490
pull_request: https://github.com/python/cpython/pull/31339

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46733>
_______________________________________

From report at bugs.python.org  Mon Feb 14 14:55:37 2022
From: report at bugs.python.org (Barney Gale)
Date: Mon, 14 Feb 2022 19:55:37 +0000
Subject: [issue46733] pathlib.Path methods can raise NotImplementedError
In-Reply-To: <1644694513.05.0.985214969865.issue46733@roundup.psfhosted.org>
Message-ID: <1644868537.19.0.668741821261.issue46733@roundup.psfhosted.org>


Change by Barney Gale <barney.gale at gmail.com>:


----------
pull_requests: +29492
pull_request: https://github.com/python/cpython/pull/31341

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46733>
_______________________________________

From report at bugs.python.org  Mon Feb 14 14:55:33 2022
From: report at bugs.python.org (Barney Gale)
Date: Mon, 14 Feb 2022 19:55:33 +0000
Subject: [issue46733] pathlib.Path methods can raise NotImplementedError
In-Reply-To: <1644694513.05.0.985214969865.issue46733@roundup.psfhosted.org>
Message-ID: <1644868533.51.0.6770694668.issue46733@roundup.psfhosted.org>


Change by Barney Gale <barney.gale at gmail.com>:


----------
pull_requests: +29491
pull_request: https://github.com/python/cpython/pull/31340

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46733>
_______________________________________

From report at bugs.python.org  Mon Feb 14 15:04:57 2022
From: report at bugs.python.org (Mike Kaganski)
Date: Mon, 14 Feb 2022 20:04:57 +0000
Subject: [issue46751] Windows-style path is not recognized under cygwin
In-Reply-To: <1644864121.29.0.790596029405.issue46751@roundup.psfhosted.org>
Message-ID: <1644869097.74.0.801513266108.issue46751@roundup.psfhosted.org>


Mike Kaganski <mikekaganski at hotmail.com> added the comment:

Thanks for looking at this!

> Are you running from bash (or another cygwin shell), or from cmd.exe, or something else?

:) Citing myself:

> Trying this *bash* command line:

> To my knowledge, cygwin's installer doesn't have a 3.9 available.

It does: https://cygwin.com/packages/summary/python3.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46751>
_______________________________________

From report at bugs.python.org  Mon Feb 14 15:12:25 2022
From: report at bugs.python.org (Mariatta)
Date: Mon, 14 Feb 2022 20:12:25 +0000
Subject: [issue46436] Pass the -d/--directory command-line option to
 http.server.CGIHTTPRequestHandler
In-Reply-To: <1642613980.51.0.0570385311323.issue46436@roundup.psfhosted.org>
Message-ID: <1644869545.64.0.431139559278.issue46436@roundup.psfhosted.org>


Mariatta <mariatta at python.org> added the comment:


New changeset 502ad3930ee8fcf76026edfc06a33621363cebea by Miss Islington (bot) in branch '3.9':
bpo-46436: Fix command-line option -d/--directory in module http.server (GH-30701) 
https://github.com/python/cpython/commit/502ad3930ee8fcf76026edfc06a33621363cebea


----------
nosy: +Mariatta

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46436>
_______________________________________

From report at bugs.python.org  Mon Feb 14 15:12:41 2022
From: report at bugs.python.org (Mariatta)
Date: Mon, 14 Feb 2022 20:12:41 +0000
Subject: [issue46436] Pass the -d/--directory command-line option to
 http.server.CGIHTTPRequestHandler
In-Reply-To: <1642613980.51.0.0570385311323.issue46436@roundup.psfhosted.org>
Message-ID: <1644869561.01.0.993758076591.issue46436@roundup.psfhosted.org>


Mariatta <mariatta at python.org> added the comment:


New changeset b27195332e91e932501f16cf9877761b218a9c99 by Miss Islington (bot) in branch '3.10':
bpo-46436: Fix command-line option -d/--directory in module http.server (GH-30701)
https://github.com/python/cpython/commit/b27195332e91e932501f16cf9877761b218a9c99


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46436>
_______________________________________

From report at bugs.python.org  Mon Feb 14 15:24:05 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 14 Feb 2022 20:24:05 +0000
Subject: [issue46751] Windows-style path is not recognized under cygwin
In-Reply-To: <1644864121.29.0.790596029405.issue46751@roundup.psfhosted.org>
Message-ID: <1644870245.25.0.428665769457.issue46751@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

>:) Citing myself:

>> Trying this *bash* command line:

Oops, sorry for missing that.

As for 3.9: it's not available through the 64 bit installer (at least, I don't see it there). I'll look and see what's involved in installing it.

Are you running the 32- or 64-bit version?

Also: I suspect this is a cygwin problem that will need to be reported upstream.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46751>
_______________________________________

From report at bugs.python.org  Mon Feb 14 15:44:29 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 14 Feb 2022 20:44:29 +0000
Subject: [issue46752] Introduce task groups to asyncio and change task
 cancellation semantics
Message-ID: <1644871469.64.0.38816696304.issue46752@roundup.psfhosted.org>


New submission from Guido van Rossum <guido at python.org>:

After some conversations with Yury, and encouraged by the SC's approval of PEP 654, I am proposing to add a new class, asyncio.TaskGroup, which introduces structured concurrency similar to nurseries in Trio.

I started with EdgeDb's TaskGroup implementation (https://github.com/edgedb/edgedb/blob/master/edb/common/taskgroup.py) and tweaked it only slightly. I also changed a few things in asyncio.Task (see below).

The key change I made to EdgeDb's TaskGroup is that subtasks can keep spawning more subtasks while __aexit__ is running; __aexit__ exits once the last subtask is done. I made this change after consulting some Trio folks, who knew of real-world use cases for this behavior, and did not know of real-world code in need of prohibiting task creation as soon as __aexit__ starts running. I added some tests for the new behavior; none of the existing tests needed to be adjusted to accommodate this change.

(For other changes relative to the EdgeDb's TaskGroup, see GH-31270.)

In order to avoid the need to monkey-patch the parent task, I added two new methods to asyncio.Task, .cancelled() and .uncancel(), that manage a flag corresponding to __cancel_requested__ in EdgeDb's TaskGroup. 

**This introduces a change in behavior around task cancellation:**

* A task that catches CancelledError is allowed to run undisturbed (ignoring further .cancel() calls and allowing any number of await calls!) until it either exits or calls .uncancel().

This change in semantics did not cause any asyncio unittests to fail. However, it may be surprising (especially to Trio folks, where the semantics are pretty much the opposite, once a Trio task is cancelled all further await calls in that task fail unless explicitly shielded).

For the TaskGroup tests to pass, we require a flag that is not cleared. However, it is probably not really required to ignore subsequent .cancel() calls until .uncancel() is called. This just seemed more consistent, and it is what @asvetlov proposed above and implemented in GH-31313 (using a property .__cancel_requested__ as the API).

----------
assignee: gvanrossum
components: asyncio
keywords: needs review
messages: 413260
nosy: asvetlov, gvanrossum, iritkatriel, yselivanov
priority: normal
severity: normal
stage: patch review
status: open
title: Introduce task groups to asyncio and change task cancellation semantics
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46752>
_______________________________________

From report at bugs.python.org  Mon Feb 14 15:44:51 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 14 Feb 2022 20:44:51 +0000
Subject: [issue46752] Introduce task groups to asyncio and change task
 cancellation semantics
In-Reply-To: <1644871469.64.0.38816696304.issue46752@roundup.psfhosted.org>
Message-ID: <1644871491.6.0.234798427183.issue46752@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
keywords: +patch
pull_requests: +29493
pull_request: https://github.com/python/cpython/pull/31270

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46752>
_______________________________________

From report at bugs.python.org  Mon Feb 14 15:47:37 2022
From: report at bugs.python.org (Steve Dower)
Date: Mon, 14 Feb 2022 20:47:37 +0000
Subject: [issue46751] Windows-style path is not recognized under cygwin
In-Reply-To: <1644864121.29.0.790596029405.issue46751@roundup.psfhosted.org>
Message-ID: <d8738c4a-80ff-5daf-891e-60d19e2e1eb7@python.org>


Steve Dower <steve.dower at python.org> added the comment:

Does Cygwin not use : as a path list separator? (What would normally be 
; on Windows.)

Perhaps the CPython build needs to be patched specially here to handle 
different separator character.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46751>
_______________________________________

From report at bugs.python.org  Mon Feb 14 15:50:20 2022
From: report at bugs.python.org (Steve Dower)
Date: Mon, 14 Feb 2022 20:50:20 +0000
Subject: [issue46744] installers on ARM64 suggest wrong folders
In-Reply-To: <1644796252.37.0.322200421464.issue46744@roundup.psfhosted.org>
Message-ID: <e7d9bbe2-d7f1-a16d-fabf-dc2275d50489@python.org>


Steve Dower <steve.dower at python.org> added the comment:

Thanks for the additional info! I agree with the design you propose.

It would be much easier to make the ARM64 install use the tagged 
directory though (C:\Program Files\Python 3.11-arm64). I'd rather not 
get into the business of detecting platforms from the installer, and 
leave that to the OS (which can decide whether the MSI is suitable or not).

I'll try and take a look at what the detection code would be like and 
make a call.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46744>
_______________________________________

From report at bugs.python.org  Mon Feb 14 16:01:14 2022
From: report at bugs.python.org (Barney Gale)
Date: Mon, 14 Feb 2022 21:01:14 +0000
Subject: [issue46733] pathlib.Path methods can raise NotImplementedError
In-Reply-To: <1644694513.05.0.985214969865.issue46733@roundup.psfhosted.org>
Message-ID: <1644872474.52.0.363167070659.issue46733@roundup.psfhosted.org>


Barney Gale <barney.gale at gmail.com> added the comment:

Thanks very much Alex. I've added some PRs:

PR 31338 addresses owner(), group() and is_mount(). It moves those methods to PosixPath, and adds stubs in WindowsPath that raise deprecation warnings. I agree with your analysis that, for static typing purposes, these methods shouldn't even exist on WindowsPath!

PR 31339 addresses readlink(), symlink_to() and hardlink_to(). In this case I'm working towards making those methods unavailable if os.readlink(), symlink() and link() are unavailable. Not totally sold on this - thoughts?

PR 31340 addresses glob() and rglob(), switching the exception type to ValueError. I think this is a legitimate bugfix with minimal adverse effects.

PR 31341 addresses the Path constructor. This is a backwards incompatible change, and /probably/ not worth doing. I add it for completeness sake, as these four PRs cover all cases where pathlib raises NotImplementedError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46733>
_______________________________________

From report at bugs.python.org  Mon Feb 14 16:14:00 2022
From: report at bugs.python.org (conio)
Date: Mon, 14 Feb 2022 21:14:00 +0000
Subject: [issue46566] Support -3.11-arm64 in py.exe launcher
In-Reply-To: <1643388779.11.0.426548045355.issue46566@roundup.psfhosted.org>
Message-ID: <1644873240.96.0.103405271403.issue46566@roundup.psfhosted.org>


Change by conio <conio.h+bugs.python.org at gmail.com>:


----------
nosy: +conio

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46566>
_______________________________________

From report at bugs.python.org  Mon Feb 14 16:19:27 2022
From: report at bugs.python.org (Mike Kaganski)
Date: Mon, 14 Feb 2022 21:19:27 +0000
Subject: [issue46751] Windows-style path is not recognized under cygwin
In-Reply-To: <1644864121.29.0.790596029405.issue46751@roundup.psfhosted.org>
Message-ID: <1644873567.96.0.331095451947.issue46751@roundup.psfhosted.org>


Mike Kaganski <mikekaganski at hotmail.com> added the comment:

> As for 3.9: it's not available through the 64 bit installer (at least, I don't see it there). I'll look and see what's involved in installing it.

I don't remember if I did something special to install it; however, just maybe you need to install python39 directly.

> Are you running the 32- or 64-bit version?

64-bit.

> Does Cygwin not use : as a path list separator?

It uses : as path separator:

$ echo $PATH
/opt/lo/bin:/usr/local/bin:/usr/bin:/cygdrive/c/Program Files/AdoptOpenJDK/jdk-11.0.7.10-hotspot/bin:/cygdrive/c/Program Files (x86)/Common Files/Oracle/Java/javapath:/cygdrive/c/ProgramData/Oracle/Java/javapath:/cygdrive/c/Windows/System32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0:...

But obviously, it can't use Windows-style paths in the $PATH (for that reason?).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46751>
_______________________________________

From report at bugs.python.org  Mon Feb 14 16:24:58 2022
From: report at bugs.python.org (Ned Deily)
Date: Mon, 14 Feb 2022 21:24:58 +0000
Subject: [issue46749] Support cross compilation on macOS
In-Reply-To: <1644848591.29.0.688015722934.issue46749@roundup.psfhosted.org>
Message-ID: <1644873898.89.0.354229621904.issue46749@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

We don't currently support cross-building a single macOS architecture on another, i.e. building an x86_64 only build on an Apple Silicon Mac. However, we do support building a multi-architecture build on either on current releases of Python 3.9 and 3.10, with what is known as a universal or fat build. In this case, you'd want to add these two options:

./configure --enable-universalsdk --with-universal-archs=universal2 ...

For this to succeed, you will also need to provide universal builds of any of the third-party libraries used by standard modules you need and that are not otherwise provided by macOS, the most common being OpenSSL and XZ (and perhaps newer versions of SQLite and Tcl/Tk). For the most part, those are straightforward to build yourself but also may be available through some third-party distributors like MacPorts and possibly HomeBrew. The Mac/README.rst file in repo has some more details about universal builds and there may be some useful hints at building the third-party libraries in Mac/BuildScript/build-installer.py although it is not intended to be used for this purpose. The resulting universal2 build can be used as is on either Intel-64 or Apple Silicon Macs but, if you truly need to have only Intel binaries you should be able to use the macOS lipo command to separate out the desired architecture from the built executables and shared libraries into other files. If you want to run these binaries on a range of macOS versions, you can also set the MACOSX_DEPLOYMENT_TARGET environment variable when building the libs and Python; we currently test and support back to 10.9.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46749>
_______________________________________

From report at bugs.python.org  Mon Feb 14 16:25:38 2022
From: report at bugs.python.org (Ned Deily)
Date: Mon, 14 Feb 2022 21:25:38 +0000
Subject: [issue46749] Support cross compilation on macOS
In-Reply-To: <1644848591.29.0.688015722934.issue46749@roundup.psfhosted.org>
Message-ID: <1644873938.0.0.720410028543.issue46749@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
components: +macOS -Cross-Build
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46749>
_______________________________________

From report at bugs.python.org  Mon Feb 14 16:28:29 2022
From: report at bugs.python.org (conio)
Date: Mon, 14 Feb 2022 21:28:29 +0000
Subject: [issue46744] installers on ARM64 suggest wrong folders
In-Reply-To: <1644796252.37.0.322200421464.issue46744@roundup.psfhosted.org>
Message-ID: <1644874109.87.0.760507658067.issue46744@roundup.psfhosted.org>


conio <conio.h+bugs.python.org at gmail.com> added the comment:

I understand.

Though I think the naming scheme that includes platform identification is better, if *all* installers include the platform name unconditionally, including both amd64 and arm64, that's also an improvement. (So the names will be `Python311-32`, `Python311-amd64` and `Python311-arm64` - each in the appropriate Program Files folder.)

The convention would be uniform, there won't be a collision between arm64 and amd64 on the same system, and amd64 won't get preferential treatment even on non-amd64 systems.

Assuming `py.exe` will be fixed to recognize the arm64 versions in the Registry, I would be able to change the folder from `Python311-arm64` to `Python311` myself in the installer if it's so important to me and everything will work just the same.

I do wonder though - is there no platform detection code today in the installer? Would the x86 versions install into "PythonXY-32" even on 32-bit Windows? If there already is, then adding a call to `IsWow64Process2` doesn't sound that difficult. Especially since that's almost the same couple of lines that will have to added to the PyLauncher anyway. Could you please point me to where the code for the Windows Python installer is so I could also take a look?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46744>
_______________________________________

From report at bugs.python.org  Mon Feb 14 17:11:19 2022
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 14 Feb 2022 22:11:19 +0000
Subject: [issue46337] urllib.parse: Allow more flexibility in schemes and URL
 resolution behavior
In-Reply-To: <1641851456.34.0.342855463339.issue46337@roundup.psfhosted.org>
Message-ID: <1644876679.51.0.0263434842355.issue46337@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/issue46337>
_______________________________________

From report at bugs.python.org  Mon Feb 14 17:28:00 2022
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 14 Feb 2022 22:28:00 +0000
Subject: [issue46436] Pass the -d/--directory command-line option to
 http.server.CGIHTTPRequestHandler
In-Reply-To: <1642613980.51.0.0570385311323.issue46436@roundup.psfhosted.org>
Message-ID: <1644877680.23.0.665737291437.issue46436@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks again!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46436>
_______________________________________

From report at bugs.python.org  Mon Feb 14 17:37:42 2022
From: report at bugs.python.org (Eric Snow)
Date: Mon, 14 Feb 2022 22:37:42 +0000
Subject: [issue46541] Replace _Py_IDENTIFIER() with statically initialized
 objects.
In-Reply-To: <1643234464.46.0.949364478641.issue46541@roundup.psfhosted.org>
Message-ID: <1644878262.59.0.998941466551.issue46541@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
pull_requests: +29494
pull_request: https://github.com/python/cpython/pull/31344

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46541>
_______________________________________

From report at bugs.python.org  Mon Feb 14 17:40:07 2022
From: report at bugs.python.org (Eric Snow)
Date: Mon, 14 Feb 2022 22:40:07 +0000
Subject: [issue46753] Statically allocate and initialize the empty tuple.
Message-ID: <1644878407.77.0.113778164261.issue46753@roundup.psfhosted.org>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

Currently it is created dynamically from the tuple freelist.

----------
assignee: eric.snow
components: Interpreter Core
messages: 413268
nosy: eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: Statically allocate and initialize the empty tuple.
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46753>
_______________________________________

From report at bugs.python.org  Mon Feb 14 17:41:11 2022
From: report at bugs.python.org (Eric Snow)
Date: Mon, 14 Feb 2022 22:41:11 +0000
Subject: [issue46753] Statically allocate and initialize the empty tuple.
In-Reply-To: <1644878407.77.0.113778164261.issue46753@roundup.psfhosted.org>
Message-ID: <1644878471.49.0.0997895933572.issue46753@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Also see bpo-45953.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46753>
_______________________________________

From report at bugs.python.org  Mon Feb 14 17:52:59 2022
From: report at bugs.python.org (Vidhya)
Date: Mon, 14 Feb 2022 22:52:59 +0000
Subject: [issue20923] [doc] Explain ConfigParser 'valid section name' and
 .SECTCRE
In-Reply-To: <1394806905.89.0.637343755468.issue20923@psf.upfronthosting.co.za>
Message-ID: <1644879179.69.0.261723049626.issue20923@roundup.psfhosted.org>


Vidhya <vidhya.friend at gmail.com> added the comment:

I am newbie to Python developer group and have the document source build and compiled successfully.

Is this issue updated in the document.
I would like to work on this if this is not closed.
Please let me know.

Thanks

----------
nosy: +vidhya.friend

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20923>
_______________________________________

From report at bugs.python.org  Mon Feb 14 17:59:46 2022
From: report at bugs.python.org (Irit Katriel)
Date: Mon, 14 Feb 2022 22:59:46 +0000
Subject: [issue20923] [doc] Explain ConfigParser 'valid section name' and
 .SECTCRE
In-Reply-To: <1394806905.89.0.637343755468.issue20923@psf.upfronthosting.co.za>
Message-ID: <1644879586.21.0.237290932815.issue20923@roundup.psfhosted.org>


Irit Katriel <iritkatriel at gmail.com> added the comment:

It?s still open. Go for it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20923>
_______________________________________

From report at bugs.python.org  Mon Feb 14 18:06:33 2022
From: report at bugs.python.org (Eric Snow)
Date: Mon, 14 Feb 2022 23:06:33 +0000
Subject: [issue46753] Statically allocate and initialize the empty tuple.
In-Reply-To: <1644878407.77.0.113778164261.issue46753@roundup.psfhosted.org>
Message-ID: <1644879993.0.0.644155082402.issue46753@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
keywords: +patch
pull_requests: +29495
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31345

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46753>
_______________________________________

From report at bugs.python.org  Mon Feb 14 18:41:25 2022
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 14 Feb 2022 23:41:25 +0000
Subject: [issue46751] Windows-style path is not recognized under cygwin
In-Reply-To: <1644864121.29.0.790596029405.issue46751@roundup.psfhosted.org>
Message-ID: <1644882085.38.0.129689719261.issue46751@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

MSYS2 has basically the same problem when the script is passed as a Windows path, except it uses "/c" for the "C:" drive instead of "/cygdrive/c".

    # python3 -VV
    Python 3.9.9 (main, Dec 28 2021, 11:05:23)
    [GCC 11.2.0]

    # echo $PWD
    /proc

    # python3 C:/Temp/test.py
    python3: can't open file '/proc/C:/Temp/test.py': [Errno 2] No such file or directory

Windows paths in the command-line arguments appear to be passed without conversion:

    # python3 -ic 1 C:/Temp/test.py
    >>> import os
    >>> open(f'/proc/{os.getpid()}/cmdline').read().split('\0')
    ['python3', '-ic', '1', 'C:/Temp/test.py', '']

They're generally supported:

    >>> open('C:/Temp/test.py').read()
    'import sys\nprint(sys.executable)\n\n'

    >>> os.path.samefile('C:/Temp/test.py', '/c/Temp/test.py')
    True

    >>> os.path.abspath('C:/Temp/test.py')
    'C:/Temp/test.py'

realpath() doesn't support them:

    >>> os.path.realpath('C:/Temp/test.py')
    '/:/Temp/test.py'

But the C API _Py_wrealpath() does:

    >>> import ctypes
    >>> path = (ctypes.c_wchar * 1000)()
    >>> ctypes.pythonapi._Py_wrealpath('C:/Temp/test.py', path, 1000)
    1484496
    >>> path.value
    '/c/Temp/test.py'

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46751>
_______________________________________

From report at bugs.python.org  Mon Feb 14 18:49:39 2022
From: report at bugs.python.org (Eric Snow)
Date: Mon, 14 Feb 2022 23:49:39 +0000
Subject: [issue46541] Replace _Py_IDENTIFIER() with statically initialized
 objects.
In-Reply-To: <1643234464.46.0.949364478641.issue46541@roundup.psfhosted.org>
Message-ID: <1644882579.65.0.506461282674.issue46541@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
pull_requests: +29496
pull_request: https://github.com/python/cpython/pull/31346

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46541>
_______________________________________

From report at bugs.python.org  Mon Feb 14 19:02:29 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 15 Feb 2022 00:02:29 +0000
Subject: [issue46728] Docstring of combinations_with_replacement for
 consistency
In-Reply-To: <1644657203.94.0.089626219133.issue46728@roundup.psfhosted.org>
Message-ID: <1644883349.18.0.105395048499.issue46728@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:


New changeset 278fdd3e3a2492665b2c2888fd2f428f7f59a3f5 by DongGeon Lee in branch 'main':
bpo-46728: fix docstring of combinations_with_replacement for consistency (GH-31293)
https://github.com/python/cpython/commit/278fdd3e3a2492665b2c2888fd2f428f7f59a3f5


----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46728>
_______________________________________

From report at bugs.python.org  Mon Feb 14 19:36:59 2022
From: report at bugs.python.org (Eric Snow)
Date: Tue, 15 Feb 2022 00:36:59 +0000
Subject: [issue46541] Replace _Py_IDENTIFIER() with statically initialized
 objects.
In-Reply-To: <1643234464.46.0.949364478641.issue46541@roundup.psfhosted.org>
Message-ID: <1644885419.57.0.273652398717.issue46541@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:


New changeset 12360aa159c42c7798fd14225d271e6fd84db7eb by Eric Snow in branch 'main':
bpo-46541: Discover the global strings. (gh-31346)
https://github.com/python/cpython/commit/12360aa159c42c7798fd14225d271e6fd84db7eb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46541>
_______________________________________

From report at bugs.python.org  Mon Feb 14 20:19:11 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 15 Feb 2022 01:19:11 +0000
Subject: =?utf-8?q?=5Bissue46754=5D_Improve_Python_Language_Reference_based_on_=5B?=
 =?utf-8?b?S8O2aGwgMjAyMF0=?=
Message-ID: <1644887951.55.0.170879911355.issue46754@roundup.psfhosted.org>


New submission from Guido van Rossum <guido at python.org>:

In https://arxiv.org/pdf/2109.03139.pdf ("M K?hl, An Executable Structural Operational Formal Semantics for Python, Master Thesis 2020 Saarland University) there are some observations on cases where the Language Reference (referred to as PLR) is ambiguous or incorrect.

Somebody should go over the thesis, collect the issues, and then we can update the language reference.

See also https://github.com/faster-cpython/ideas/issues/208#issuecomment-1039612432

----------
messages: 413275
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: Improve Python Language Reference based on [K?hl 2020]

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46754>
_______________________________________

From report at bugs.python.org  Mon Feb 14 21:38:18 2022
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 15 Feb 2022 02:38:18 +0000
Subject: [issue46752] Introduce task groups to asyncio and change task
 cancellation semantics
In-Reply-To: <1644871469.64.0.38816696304.issue46752@roundup.psfhosted.org>
Message-ID: <1644892698.39.0.713841284513.issue46752@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +njs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46752>
_______________________________________

From report at bugs.python.org  Mon Feb 14 23:25:32 2022
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 15 Feb 2022 04:25:32 +0000
Subject: [issue46733] pathlib.Path methods can raise NotImplementedError
In-Reply-To: <1644694513.05.0.985214969865.issue46733@roundup.psfhosted.org>
Message-ID: <1644899132.03.0.765784722667.issue46733@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

WindowsPath.is_mount() should call ntpath.ismount(). This function needs a significant redesign, but it's fine to use it as long as it's documented that is_mount() is equivalent to os.path.ismount().

Since the owner() and group() methods return names instead of numeric IDs, technically we could implement them in WindowsPath. That said, in Windows, st_mode and chmod() are unrelated to a file's owner and group, plus object ownership is fundamentally different from POSIX. Unless chown() is also implemented, I don't think we would gain much from knowing the owner and group, other than making it easier to display them.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46733>
_______________________________________

From report at bugs.python.org  Tue Feb 15 01:36:26 2022
From: report at bugs.python.org (hongweipeng)
Date: Tue, 15 Feb 2022 06:36:26 +0000
Subject: [issue45756] mock raises exception when using a spec with an
 attribute that raises exception on access
In-Reply-To: <1636400873.51.0.88200985051.issue45756@roundup.psfhosted.org>
Message-ID: <1644906986.86.0.338355354168.issue45756@roundup.psfhosted.org>


Change by hongweipeng <hongweichen8888 at sina.com>:


----------
nosy: +hongweipeng
nosy_count: 5.0 -> 6.0
pull_requests: +29497
pull_request: https://github.com/python/cpython/pull/31348

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45756>
_______________________________________

From report at bugs.python.org  Tue Feb 15 01:43:24 2022
From: report at bugs.python.org (Charlie Zhao)
Date: Tue, 15 Feb 2022 06:43:24 +0000
Subject: [issue46677] TypedDict docs are incomplete
In-Reply-To: <1644262079.95.0.663870450502.issue46677@roundup.psfhosted.org>
Message-ID: <1644907404.61.0.13696610849.issue46677@roundup.psfhosted.org>


Change by Charlie Zhao <zhaoyu_hit at qq.com>:


----------
keywords: +patch
pull_requests: +29498
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31349

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46677>
_______________________________________

From report at bugs.python.org  Tue Feb 15 02:40:35 2022
From: report at bugs.python.org (Christoph Reiter)
Date: Tue, 15 Feb 2022 07:40:35 +0000
Subject: [issue46751] Windows-style path is not recognized under cygwin
In-Reply-To: <1644864121.29.0.790596029405.issue46751@roundup.psfhosted.org>
Message-ID: <1644910835.41.0.658774732726.issue46751@roundup.psfhosted.org>


Christoph Reiter <reiter.christoph at gmail.com> added the comment:

Afaik Cywin programs only work with native Windows paths if the paths happen to get directly passed to the OS APIs and not interpreted in any way before that. So I don't think this is a bug and expected behavior.

Use "cygpath C:/path/to/script.py" to convert the path to the right format first.

----------
nosy: +lazka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46751>
_______________________________________

From report at bugs.python.org  Tue Feb 15 03:36:55 2022
From: report at bugs.python.org (Erik Montnemery)
Date: Tue, 15 Feb 2022 08:36:55 +0000
Subject: [issue46755] QueueHandler logs stack_info twice
Message-ID: <1644914215.76.0.40425567068.issue46755@roundup.psfhosted.org>


New submission from Erik Montnemery <erik.montnemery at gmail.com>:

logging.handlers.QueueHandler logs stack twice when stack_info=True:

>>> import logging
>>> from logging.handlers import QueueHandler, QueueListener
>>> from queue import Queue
>>> q = Queue()
>>> logging.getLogger().addHandler(QueueHandler(q))
>>> listener = QueueListener(q, logging.StreamHandler())
>>> listener.start()
>>> _LOGGER.error("Hello", stack_info=True)
Hello
Stack (most recent call last):
  File "<stdin>", line 1, in <module>
Stack (most recent call last):
  File "<stdin>", line 1, in <module>


Reproduced on CPython 3.9.9, but the code is unchanged in 3.10 and 3.11, so the issue should exist there too.

Patching QueueHandler.prepare() to set stack_info to None seems to fix this:

diff --git a/Lib/logging/handlers.py b/Lib/logging/handlers.py
index d42c48de5f..7cd5646d85 100644
--- a/Lib/logging/handlers.py
+++ b/Lib/logging/handlers.py
@@ -1452,6 +1452,7 @@ def prepare(self, record):
         record.args = None
         record.exc_info = None
         record.exc_text = None
+        record.stack_info = None
         return record

     def emit(self, record):

Related issue: Issue34334, with patch https://github.com/python/cpython/pull/9537

----------
components: Library (Lib)
messages: 413278
nosy: erik.montnemery
priority: normal
severity: normal
status: open
title: QueueHandler logs stack_info twice
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46755>
_______________________________________

From report at bugs.python.org  Tue Feb 15 04:21:27 2022
From: report at bugs.python.org (DongGeon Lee)
Date: Tue, 15 Feb 2022 09:21:27 +0000
Subject: [issue46728] Docstring of combinations_with_replacement for
 consistency
In-Reply-To: <1644657203.94.0.089626219133.issue46728@roundup.psfhosted.org>
Message-ID: <1644916887.47.0.299538321495.issue46728@roundup.psfhosted.org>


Change by DongGeon Lee <secmatth1996 at gmail.com>:


----------
pull_requests: +29499
pull_request: https://github.com/python/cpython/pull/31350

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46728>
_______________________________________

From report at bugs.python.org  Tue Feb 15 04:35:28 2022
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 15 Feb 2022 09:35:28 +0000
Subject: [issue46724] Odd Bytecode Generation in 3.10
In-Reply-To: <1644600146.24.0.968453673832.issue46724@roundup.psfhosted.org>
Message-ID: <1644917728.93.0.469200355014.issue46724@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset 3be1a443ca8e7d4ba85f95b78df5c4122cae9ede by Mark Shannon in branch 'main':
bpo-46724: Use `JUMP_ABSOLUTE` for all backward jumps. (GH-31326)
https://github.com/python/cpython/commit/3be1a443ca8e7d4ba85f95b78df5c4122cae9ede


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46724>
_______________________________________

From report at bugs.python.org  Tue Feb 15 04:37:37 2022
From: report at bugs.python.org (Erlend E. Aasland)
Date: Tue, 15 Feb 2022 09:37:37 +0000
Subject: [issue46541] Replace _Py_IDENTIFIER() with statically initialized
 objects.
In-Reply-To: <1643234464.46.0.949364478641.issue46541@roundup.psfhosted.org>
Message-ID: <1644917857.35.0.381775425788.issue46541@roundup.psfhosted.org>


Change by Erlend E. Aasland <erlend.aasland at innova.no>:


----------
nosy: +erlendaasland
nosy_count: 5.0 -> 6.0
pull_requests: +29500
pull_request: https://github.com/python/cpython/pull/31351

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46541>
_______________________________________

From report at bugs.python.org  Tue Feb 15 04:43:18 2022
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 15 Feb 2022 09:43:18 +0000
Subject: [issue46724] Odd Bytecode Generation in 3.10
In-Reply-To: <1644600146.24.0.968453673832.issue46724@roundup.psfhosted.org>
Message-ID: <1644918198.48.0.233890877861.issue46724@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
pull_requests: +29501
pull_request: https://github.com/python/cpython/pull/31352

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46724>
_______________________________________

From report at bugs.python.org  Tue Feb 15 04:48:07 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Feb 2022 09:48:07 +0000
Subject: [issue46756] Incorrect
Message-ID: <1644918487.72.0.244898503691.issue46756@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

There is an error in determining a sub-URI in the urllib.request module. Due to it, if the user is authorized for example.org/foo, it gets also access to example.org/foobar.

----------
components: Library (Lib)
messages: 413280
nosy: orsenthil, serhiy.storchaka
priority: high
severity: normal
status: open
title: Incorrect
type: security
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46756>
_______________________________________

From report at bugs.python.org  Tue Feb 15 05:02:26 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Feb 2022 10:02:26 +0000
Subject: [issue46756] Incorrect
In-Reply-To: <1644918487.72.0.244898503691.issue46756@roundup.psfhosted.org>
Message-ID: <1644919346.55.0.387628250438.issue46756@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +29502
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31353

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46756>
_______________________________________

From report at bugs.python.org  Tue Feb 15 05:03:29 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Feb 2022 10:03:29 +0000
Subject: [issue46756] Incorrect authorization check in urllib.request
In-Reply-To: <1644918487.72.0.244898503691.issue46756@roundup.psfhosted.org>
Message-ID: <1644919409.84.0.360386772825.issue46756@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
title: Incorrect -> Incorrect authorization check in urllib.request

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46756>
_______________________________________

From report at bugs.python.org  Tue Feb 15 05:03:47 2022
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 15 Feb 2022 10:03:47 +0000
Subject: [issue46724] Odd Bytecode Generation in 3.10
In-Reply-To: <1644600146.24.0.968453673832.issue46724@roundup.psfhosted.org>
Message-ID: <1644919427.59.0.402912313413.issue46724@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
pull_requests: +29503
pull_request: https://github.com/python/cpython/pull/31354

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46724>
_______________________________________

From report at bugs.python.org  Tue Feb 15 05:06:05 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 15 Feb 2022 10:06:05 +0000
Subject: [issue46728] Docstring of combinations_with_replacement for
 consistency
In-Reply-To: <1644657203.94.0.089626219133.issue46728@roundup.psfhosted.org>
Message-ID: <1644919565.33.0.955776086567.issue46728@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
versions:  -Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46728>
_______________________________________

From report at bugs.python.org  Tue Feb 15 05:06:33 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 15 Feb 2022 10:06:33 +0000
Subject: [issue46728] Docstring of combinations_with_replacement for
 consistency
In-Reply-To: <1644657203.94.0.089626219133.issue46728@roundup.psfhosted.org>
Message-ID: <1644919593.0.0.804329123947.issue46728@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:

@LeeDongGeon1996

Please send the backported patch to 3.9 also

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46728>
_______________________________________

From report at bugs.python.org  Tue Feb 15 05:20:46 2022
From: report at bugs.python.org (Erik Montnemery)
Date: Tue, 15 Feb 2022 10:20:46 +0000
Subject: [issue31084] QueueHandler not formatting messages
In-Reply-To: <1501451530.82.0.0352443251136.issue31084@psf.upfronthosting.co.za>
Message-ID: <1644920446.63.0.36434849667.issue31084@roundup.psfhosted.org>


Change by Erik Montnemery <erik at montnemery.com>:


----------
nosy: +emontnemery
nosy_count: 2.0 -> 3.0
pull_requests: +29505
pull_request: https://github.com/python/cpython/pull/31355

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31084>
_______________________________________

From report at bugs.python.org  Tue Feb 15 05:20:46 2022
From: report at bugs.python.org (Erik Montnemery)
Date: Tue, 15 Feb 2022 10:20:46 +0000
Subject: [issue46755] QueueHandler logs stack_info twice
In-Reply-To: <1644914215.76.0.40425567068.issue46755@roundup.psfhosted.org>
Message-ID: <1644920446.57.0.521943049367.issue46755@roundup.psfhosted.org>


Change by Erik Montnemery <erik at montnemery.com>:


----------
keywords: +patch
nosy: +emontnemery
nosy_count: 1.0 -> 2.0
pull_requests: +29504
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31355

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46755>
_______________________________________

From report at bugs.python.org  Tue Feb 15 05:21:26 2022
From: report at bugs.python.org (DongGeon Lee)
Date: Tue, 15 Feb 2022 10:21:26 +0000
Subject: [issue46728] Docstring of combinations_with_replacement for
 consistency
In-Reply-To: <1644657203.94.0.089626219133.issue46728@roundup.psfhosted.org>
Message-ID: <1644920486.33.0.380387740013.issue46728@roundup.psfhosted.org>


Change by DongGeon Lee <secmatth1996 at gmail.com>:


----------
pull_requests: +29506
pull_request: https://github.com/python/cpython/pull/31356

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46728>
_______________________________________

From report at bugs.python.org  Tue Feb 15 05:24:12 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 15 Feb 2022 10:24:12 +0000
Subject: [issue46728] Docstring of combinations_with_replacement for
 consistency
In-Reply-To: <1644657203.94.0.089626219133.issue46728@roundup.psfhosted.org>
Message-ID: <1644920652.35.0.449819767087.issue46728@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:


New changeset ac55cea3cbee4d40cf7320bd691f5327cff30f13 by DongGeon Lee in branch '3.10':
[3.10] bpo-46728: fix docstring of combinations_with_replacement for consistency (GH-31293) (GH-31350)
https://github.com/python/cpython/commit/ac55cea3cbee4d40cf7320bd691f5327cff30f13


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46728>
_______________________________________

From report at bugs.python.org  Tue Feb 15 06:13:27 2022
From: report at bugs.python.org (Neil Girdhar)
Date: Tue, 15 Feb 2022 11:13:27 +0000
Subject: [issue46757] dataclasses should define an empty __post_init__
Message-ID: <1644923607.6.0.495534870715.issue46757@roundup.psfhosted.org>


New submission from Neil Girdhar <mistersheik at gmail.com>:

When defining a dataclass, it's possible to define a post-init (__post_init__) method to, for example, verify contracts.

Sometimes, when you inherit from another dataclass, that dataclass has its own post-init method.  If you want that method to also do its checks, you need to explicitly call it with super.  However, if that method doesn't exist calling it with super will crash.

Since you don't know whether your superclasses implement post-init or not, you're forced to check if the superclass has one or not, and call it if it does.

Essentially, post-init implements an "augmenting pattern" like __init__, ___enter__, __exit__, __array_finalize__, etc.  All such methods define an empty method at the top level so that child classes can safely call super.

Please consider adding such an empty method to dataclasses so that children who implement __post_init__ can safely call super.

----------
components: Library (Lib)
messages: 413283
nosy: NeilGirdhar
priority: normal
severity: normal
status: open
title: dataclasses should define an empty __post_init__

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46757>
_______________________________________

From report at bugs.python.org  Tue Feb 15 06:39:43 2022
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 15 Feb 2022 11:39:43 +0000
Subject: [issue46757] dataclasses should define an empty __post_init__
In-Reply-To: <1644923607.6.0.495534870715.issue46757@roundup.psfhosted.org>
Message-ID: <1644925183.37.0.0883460915584.issue46757@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46757>
_______________________________________

From report at bugs.python.org  Tue Feb 15 07:01:56 2022
From: report at bugs.python.org (SIGSEG V)
Date: Tue, 15 Feb 2022 12:01:56 +0000
Subject: [issue46758] Incorrect behaviour creating a Structure with
 ctypes.c_bool bitfields
Message-ID: <1644926516.47.0.674432386115.issue46758@roundup.psfhosted.org>


New submission from SIGSEG V <Noname.genial at alpenjodel.de>:

Setting/getting values in a Structure containing multiple c_bool bitfields like:
_fields_ = [
  ('one', c_bool, 1),
  ('two', c_bool, 1),
  ]
results in an unexpected behavior.
Setting any one of these fields to `True` results in ALL of these fields being set to `True` (i.e.: setting `struct.one` to `True` causes both `struct.one` as well as `struct.two` to be set to `True`.
This also results in the binary representation of the struct to be incorrect. The only possible outcomes for `bytes(struct)` are `b'\x00` and `b'\x01'`

Expected behavior should be that when setting `struct.one` only sets the desired field.
This is achievable when defining the same Structure with `c_byte` rather than `c_bool`.
When defining the struct like:
_fields_ = [
  ('one', c_byte, 1),
  ('two', c_byte, 1),
  ]
setting `struct.one` only affects `struct.one` and not `struct.two`.
The binary representation of the structure is also correct. When setting `struct.two` to `True`, `bytes(struct)` returns `b'\x02'` (aka. 0b10).

I've attached a Minimal Runnable Example that hopefully helps outline the issue.

----------
components: Windows, ctypes
files: mre.py
messages: 413284
nosy: dudenwatschn, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Incorrect behaviour creating a Structure with ctypes.c_bool bitfields
type: behavior
versions: Python 3.10, Python 3.9
Added file: https://bugs.python.org/file50624/mre.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46758>
_______________________________________

From report at bugs.python.org  Tue Feb 15 07:10:41 2022
From: report at bugs.python.org (Colin Watson)
Date: Tue, 15 Feb 2022 12:10:41 +0000
Subject: [issue46759] sys.excepthook documentation doesn't mention that it
 isn't called for SystemExit
Message-ID: <1644927041.52.0.688076844331.issue46759@roundup.psfhosted.org>


New submission from Colin Watson <cjwatson at users.sourceforge.net>:

In https://bugs.debian.org/1005803, Matthew Vernon reports that the library documentation for sys.excepthook doesn't mention the detail that that sys.excepthook isn't called for uncaught SystemExit exceptions, although help(sys) does mention this.

(He also mentions that help(sys.excepthook) doesn't mention this.  I think this would make less sense, since that gets the docstring of a particular implementation of an excepthook - on a given system it might not be Python's built-in version, for instance.  But adding information to the main library documentation seems reasonable.)

----------
assignee: docs at python
components: Documentation
messages: 413285
nosy: cjwatson, docs at python
priority: normal
severity: normal
status: open
title: sys.excepthook documentation doesn't mention that it isn't called for SystemExit
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46759>
_______________________________________

From report at bugs.python.org  Tue Feb 15 07:16:16 2022
From: report at bugs.python.org (Colin Watson)
Date: Tue, 15 Feb 2022 12:16:16 +0000
Subject: [issue46759] sys.excepthook documentation doesn't mention that it
 isn't called for SystemExit
In-Reply-To: <1644927041.52.0.688076844331.issue46759@roundup.psfhosted.org>
Message-ID: <1644927376.9.0.573995600225.issue46759@roundup.psfhosted.org>


Change by Colin Watson <cjwatson at users.sourceforge.net>:


----------
keywords: +patch
pull_requests: +29507
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31357

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46759>
_______________________________________

From report at bugs.python.org  Tue Feb 15 07:22:13 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 15 Feb 2022 12:22:13 +0000
Subject: [issue46728] Docstring of combinations_with_replacement for
 consistency
In-Reply-To: <1644657203.94.0.089626219133.issue46728@roundup.psfhosted.org>
Message-ID: <1644927733.13.0.057070026368.issue46728@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:


New changeset ad47db34be23c5cd75ed5d5c220d4b56a9b5683c by DongGeon Lee in branch '3.9':
[3.9] bpo-46728: fix docstring of combinations_with_replacement for consistency (GH-31293). (GH-31356)
https://github.com/python/cpython/commit/ad47db34be23c5cd75ed5d5c220d4b56a9b5683c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46728>
_______________________________________

From report at bugs.python.org  Tue Feb 15 07:22:32 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 15 Feb 2022 12:22:32 +0000
Subject: [issue46728] Docstring of combinations_with_replacement for
 consistency
In-Reply-To: <1644657203.94.0.089626219133.issue46728@roundup.psfhosted.org>
Message-ID: <1644927752.58.0.370522802813.issue46728@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:

Thank you DongGeon :)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46728>
_______________________________________

From report at bugs.python.org  Tue Feb 15 07:53:32 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 15 Feb 2022 12:53:32 +0000
Subject: [issue46541] Replace _Py_IDENTIFIER() with statically initialized
 objects.
In-Reply-To: <1643234464.46.0.949364478641.issue46541@roundup.psfhosted.org>
Message-ID: <1644929612.45.0.930558560441.issue46541@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/issue46541>
_______________________________________

From report at bugs.python.org  Tue Feb 15 08:04:08 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 15 Feb 2022 13:04:08 +0000
Subject: [issue44011] Borrow asyncio ssl implementation from uvloop
In-Reply-To: <1619987620.01.0.201978044819.issue44011@roundup.psfhosted.org>
Message-ID: <1644930248.94.0.495944512977.issue44011@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset 13c10bfb777483c7b02877aab029345a056b809c by Kumar Aditya in branch 'main':
bpo-44011: New asyncio ssl implementation (#31275)
https://github.com/python/cpython/commit/13c10bfb777483c7b02877aab029345a056b809c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44011>
_______________________________________

From report at bugs.python.org  Tue Feb 15 08:05:59 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 15 Feb 2022 13:05:59 +0000
Subject: [issue44011] Borrow asyncio ssl implementation from uvloop
In-Reply-To: <1619987620.01.0.201978044819.issue44011@roundup.psfhosted.org>
Message-ID: <1644930359.34.0.736790047929.issue44011@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

The code had landed.
Need a follow-up PR with documentation update (mention new ssl_shutdown_timeout arguments)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44011>
_______________________________________

From report at bugs.python.org  Tue Feb 15 08:06:10 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 15 Feb 2022 13:06:10 +0000
Subject: [issue44011] Borrow asyncio ssl implementation from uvloop
In-Reply-To: <1619987620.01.0.201978044819.issue44011@roundup.psfhosted.org>
Message-ID: <1644930370.14.0.164381469638.issue44011@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
priority: critical -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44011>
_______________________________________

From report at bugs.python.org  Tue Feb 15 08:10:48 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 15 Feb 2022 13:10:48 +0000
Subject: [issue46541] Replace _Py_IDENTIFIER() with statically initialized
 objects.
In-Reply-To: <1643234464.46.0.949364478641.issue46541@roundup.psfhosted.org>
Message-ID: <1644930648.06.0.136168001744.issue46541@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
pull_requests: +29508
pull_request: https://github.com/python/cpython/pull/31358

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46541>
_______________________________________

From report at bugs.python.org  Tue Feb 15 08:43:30 2022
From: report at bugs.python.org (DongGeon Lee)
Date: Tue, 15 Feb 2022 13:43:30 +0000
Subject: [issue46728] Docstring of combinations_with_replacement for
 consistency
In-Reply-To: <1644657203.94.0.089626219133.issue46728@roundup.psfhosted.org>
Message-ID: <1644932610.33.0.534667097618.issue46728@roundup.psfhosted.org>


DongGeon Lee <secmatth1996 at gmail.com> added the comment:

My pleasure :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46728>
_______________________________________

From report at bugs.python.org  Tue Feb 15 09:17:08 2022
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 15 Feb 2022 14:17:08 +0000
Subject: [issue46760] test_dis should test the dis module, not everything else
Message-ID: <1644934628.87.0.437399260946.issue46760@roundup.psfhosted.org>


New submission from Mark Shannon <mark at hotpy.org>:

<rant>

This is getting really annoying.
It takes longer to fix all the heavily coupled and poorly written tests in test_dis than to make the real changes.

Tiny changes in the calling sequence, or reordering CFGs, cause huge diffs in the test_dis module.
No one ever checks these changes, they are just noise.

I've put this under "enhancement" as there is no "wastes a huge amount of time" category.

</rant>

The test_dis should not:

Contain offsets; they turn one line diffs into 100 line diffs
Contain tests for the compiler; they belong elsewhere.
Contain big strings; write proper tests not just regex matches.
Tests for Instruction should should not depend on the compiler output; create the bytecode directly.


This is not a new problem, but it does seem to be getting progressively worse.

A lot of the irritation stems from
https://github.com/python/cpython/commit/b39fd0c9b8dc6683924205265ff43cc597d1dfb9
although the tests from before that still hardcode offsets.

----------
components: Tests
messages: 413291
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: test_dis should test the dis module, not everything else
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46760>
_______________________________________

From report at bugs.python.org  Tue Feb 15 10:31:20 2022
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 15 Feb 2022 15:31:20 +0000
Subject: [issue20923] [doc] Explain ConfigParser 'valid section name' and
 .SECTCRE
In-Reply-To: <1394806905.89.0.637343755468.issue20923@psf.upfronthosting.co.za>
Message-ID: <1644939080.9.0.145356352.issue20923@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
nosy: +python-dev
nosy_count: 10.0 -> 11.0
pull_requests: +29509
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31359

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20923>
_______________________________________

From report at bugs.python.org  Tue Feb 15 10:38:04 2022
From: report at bugs.python.org (Vidhya)
Date: Tue, 15 Feb 2022 15:38:04 +0000
Subject: [issue20923] [doc] Explain ConfigParser 'valid section name' and
 .SECTCRE
In-Reply-To: <1394806905.89.0.637343755468.issue20923@psf.upfronthosting.co.za>
Message-ID: <1644939484.59.0.909817457118.issue20923@roundup.psfhosted.org>


Vidhya <vidhya.friend at gmail.com> added the comment:

Thanks.
A pull request is created at https://github.com/python/cpython/pull/31359.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20923>
_______________________________________

From report at bugs.python.org  Tue Feb 15 10:42:29 2022
From: report at bugs.python.org (Zackery Spytz)
Date: Tue, 15 Feb 2022 15:42:29 +0000
Subject: [issue46737] Default to the standard normal distribution
In-Reply-To: <1644751625.52.0.483632432415.issue46737@roundup.psfhosted.org>
Message-ID: <1644939749.01.0.448941450386.issue46737@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 2.0 -> 3.0
pull_requests: +29510
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31360

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46737>
_______________________________________

From report at bugs.python.org  Tue Feb 15 11:11:14 2022
From: report at bugs.python.org (Zackery Spytz)
Date: Tue, 15 Feb 2022 16:11:14 +0000
Subject: [issue46737] Default to the standard normal distribution
In-Reply-To: <1644751625.52.0.483632432415.issue46737@roundup.psfhosted.org>
Message-ID: <1644941474.19.0.156063007421.issue46737@roundup.psfhosted.org>


Zackery Spytz <zspytz at gmail.com> added the comment:

I have created a patch for this issue.  Please consider having a look.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46737>
_______________________________________

From report at bugs.python.org  Tue Feb 15 11:16:30 2022
From: report at bugs.python.org (Steve Dower)
Date: Tue, 15 Feb 2022 16:16:30 +0000
Subject: [issue46744] installers on ARM64 suggest wrong folders
In-Reply-To: <1644874109.87.0.760507658067.issue46744@roundup.psfhosted.org>
Message-ID: <389aef88-a2c7-16d4-162b-c61edb164cbf@python.org>


Steve Dower <steve.dower at python.org> added the comment:

Yeah, currently the only detection that happens is OS version, and just 
so we can block (or at least log) users who are trying to install on 
supported versions. The install directories are unconditional.

Any dynamic detection code would have to go into 
Tools/msi/bundle/bootstrap/PythonBootstrapperApplication.cpp and would 
update variables defined in Tools/msi/bundle/bundle.wxs. If you find the 
code for getting the ProgramFiles(Arm) directory, you'll see an example 
(which is probably the right one to update to handle the range of 
platforms).

However, I think we should consider the 32/64-bit install directory 
names to be a compatibility concern, and shouldn't modify them generally 
out of some kind of sense of "fairness". If it's trivial and safe to 
detect 64-bit running on ARM64 (which, as you say, it ought to be), then 
we can update its directory name there by default.

We should probably also display a notice in the installer when 
installing the Intel builds on ARM. The 64-bit version is fine, but the 
32-bit version has issues, and my experience so far is that the native 
build is significantly faster than both. We can do that another time though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46744>
_______________________________________

From report at bugs.python.org  Tue Feb 15 11:39:40 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 15 Feb 2022 16:39:40 +0000
Subject: [issue46741] Docstring for asyncio.protocols.BufferedProtocol appears
 out of date
In-Reply-To: <1644786787.46.0.446565917898.issue46741@roundup.psfhosted.org>
Message-ID: <1644943180.15.0.161862932824.issue46741@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: +29511
pull_request: https://github.com/python/cpython/pull/31361

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46741>
_______________________________________

From report at bugs.python.org  Tue Feb 15 11:39:59 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 15 Feb 2022 16:39:59 +0000
Subject: [issue46741] Docstring for asyncio.protocols.BufferedProtocol appears
 out of date
In-Reply-To: <1644786787.46.0.446565917898.issue46741@roundup.psfhosted.org>
Message-ID: <1644943199.2.0.494461293205.issue46741@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset 1d81fdc4c004511c25f74db0e04ddbbb8a04ce6d by Alex Waygood in branch 'main':
bpo-46741: Update `asyncio.protocols.BufferedProtocol` docstring (31327)
https://github.com/python/cpython/commit/1d81fdc4c004511c25f74db0e04ddbbb8a04ce6d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46741>
_______________________________________

From report at bugs.python.org  Tue Feb 15 11:41:26 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 15 Feb 2022 16:41:26 +0000
Subject: [issue46741] Docstring for asyncio.protocols.BufferedProtocol appears
 out of date
In-Reply-To: <1644786787.46.0.446565917898.issue46741@roundup.psfhosted.org>
Message-ID: <1644943286.27.0.215995456528.issue46741@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29512
pull_request: https://github.com/python/cpython/pull/31362

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46741>
_______________________________________

From report at bugs.python.org  Tue Feb 15 12:08:40 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 15 Feb 2022 17:08:40 +0000
Subject: [issue46741] Docstring for asyncio.protocols.BufferedProtocol appears
 out of date
In-Reply-To: <1644786787.46.0.446565917898.issue46741@roundup.psfhosted.org>
Message-ID: <1644944920.51.0.0504960776465.issue46741@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c292118ef3528df85a9d76ad21029009b560b088 by Miss Islington (bot) in branch '3.9':
bpo-46741: Update `asyncio.protocols.BufferedProtocol` docstring (31327)
https://github.com/python/cpython/commit/c292118ef3528df85a9d76ad21029009b560b088


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46741>
_______________________________________

From report at bugs.python.org  Tue Feb 15 12:14:17 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 15 Feb 2022 17:14:17 +0000
Subject: [issue46741] Docstring for asyncio.protocols.BufferedProtocol appears
 out of date
In-Reply-To: <1644786787.46.0.446565917898.issue46741@roundup.psfhosted.org>
Message-ID: <1644945257.15.0.696146649649.issue46741@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset 72c46462aa9fd0a69317917ba127e62f94ce08d7 by Miss Islington (bot) in branch '3.10':
bpo-46741: Update `asyncio.protocols.BufferedProtocol` docstring (GH-31327) (GH-31362)
https://github.com/python/cpython/commit/72c46462aa9fd0a69317917ba127e62f94ce08d7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46741>
_______________________________________

From report at bugs.python.org  Tue Feb 15 12:14:30 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 15 Feb 2022 17:14:30 +0000
Subject: [issue46741] Docstring for asyncio.protocols.BufferedProtocol appears
 out of date
In-Reply-To: <1644786787.46.0.446565917898.issue46741@roundup.psfhosted.org>
Message-ID: <1644945270.34.0.537709216783.issue46741@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/issue46741>
_______________________________________

From report at bugs.python.org  Tue Feb 15 12:17:22 2022
From: report at bugs.python.org (Barney Gale)
Date: Tue, 15 Feb 2022 17:17:22 +0000
Subject: [issue46733] pathlib.Path methods can raise NotImplementedError
In-Reply-To: <1644694513.05.0.985214969865.issue46733@roundup.psfhosted.org>
Message-ID: <1644945442.62.0.794548272832.issue46733@roundup.psfhosted.org>


Barney Gale <barney.gale at gmail.com> added the comment:

I'm planning to learn more heavily on posixpath + ntpath in pathlib once bpo-44136 is done. I think that would be a good time to introduce is_mount() support on Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46733>
_______________________________________

From report at bugs.python.org  Tue Feb 15 12:50:58 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Tue, 15 Feb 2022 17:50:58 +0000
Subject: [issue46760] test_dis should test the dis module, not everything else
In-Reply-To: <1644934628.87.0.437399260946.issue46760@roundup.psfhosted.org>
Message-ID: <1644947458.61.0.940697507742.issue46760@roundup.psfhosted.org>


Change by Jelle Zijlstra <jelle.zijlstra at gmail.com>:


----------
nosy: +Jelle Zijlstra

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46760>
_______________________________________

From report at bugs.python.org  Tue Feb 15 13:06:14 2022
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 15 Feb 2022 18:06:14 +0000
Subject: [issue46761] functools.update_wrapper breaks the signature of
 functools.partial objects
Message-ID: <1644948374.87.0.765462873315.issue46761@roundup.psfhosted.org>


New submission from Larry Hastings <larry at hastings.org>:

It's considered good hygiene to use functools.update_wrapper() to make your wrapped functions look like the original.  However, when using functools.partial() to pre-supply arguments to a function, if you then call functools.update_wrapper() to update that partial object, inspect.signature() returns the *original* function's signature, not the *wrapped* function's signature.

To be precise: if you wrap a function with functools.partial() to pre-provide arguments, then immediately call inspect.signature() on that partial object, it returns the correct signature with the pre-filled parameters removed.  If you then call functools.update_wrapper() to update the partial from the original function, inspect.signature() now returns the *wrong* signature. 

I looked into it a little.  The specific thing changing inspect.signature()'s behavior is the '__wrapped__' attribute added by functools.update_wrapper().  By default inspect.signature() will unwrap partial objects, but only if it has a '__wrapped__' attribute.

This all looks pretty deliberate.  And it seems like there was some thought given to this wrinkle; inspect.signature() takes a "follow_wrapper_chains" parameter the user can supply to control this behavior.  But the default is True, meaning that by default it unwraps partial objects if they have a '__wrapped__'.

I admit I don't have any context for this.  Why do we want inspect.signature() to return the wrong signature by default?

----------
components: Library (Lib)
files: update_wrapper.breaks.partial.signature.test.py
messages: 413299
nosy: larry
priority: normal
severity: normal
stage: test needed
status: open
title: functools.update_wrapper breaks the signature of functools.partial objects
type: behavior
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file50625/update_wrapper.breaks.partial.signature.test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46761>
_______________________________________

From report at bugs.python.org  Tue Feb 15 14:33:37 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 15 Feb 2022 19:33:37 +0000
Subject: [issue46318] asyncio and ssl: ResourceWarning: unclosed transport
In-Reply-To: <1641740693.62.0.185226666966.issue46318@roundup.psfhosted.org>
Message-ID: <1644953617.97.0.195260760436.issue46318@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Please check against the latest master.
It has rewritten SSL protocol implementation borrowed from uvloop.
See #44011 for details

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46318>
_______________________________________

From report at bugs.python.org  Tue Feb 15 14:43:17 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Tue, 15 Feb 2022 19:43:17 +0000
Subject: [issue46738] Allow http.server to emit HTML 5
In-Reply-To: <1644757078.96.0.518529275585.issue46738@roundup.psfhosted.org>
Message-ID: <1644954197.17.0.0900651889145.issue46738@roundup.psfhosted.org>


Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:

Looks like this is a duplicate of issue46736. Seems like a good idea though!

----------
nosy: +Jelle Zijlstra
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46738>
_______________________________________

From report at bugs.python.org  Tue Feb 15 17:19:52 2022
From: report at bugs.python.org (Ammar Askar)
Date: Tue, 15 Feb 2022 22:19:52 +0000
Subject: [issue46762] assertion failure in f-string parsing
 Parser/string_parser.c
Message-ID: <1644963592.59.0.718749450454.issue46762@roundup.psfhosted.org>


New submission from Ammar Askar <ammar at ammaraskar.com>:

Similar to https://bugs.python.org/issue46503 found by the ast.literal_eval fuzzer

```
>>> f'{<'
python: Parser/string_parser.c:346: fstring_compile_expr: Assertion `*expr_end == '}' || *expr_end == '!' || *expr_end == ':' || *expr_end == '='' failed.
[1]    14060 abort      ./python
```

----------
assignee: eric.smith
components: Parser
messages: 413302
nosy: ammar2, eric.smith, gregory.p.smith, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: assertion failure in f-string parsing Parser/string_parser.c
type: crash
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46762>
_______________________________________

From report at bugs.python.org  Tue Feb 15 17:32:09 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 15 Feb 2022 22:32:09 +0000
Subject: [issue46762] assertion failure in f-string parsing
 Parser/string_parser.c
In-Reply-To: <1644963592.59.0.718749450454.issue46762@roundup.psfhosted.org>
Message-ID: <1644964329.23.0.967742935613.issue46762@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Good catch! I'll have a patch tonight.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46762>
_______________________________________

From report at bugs.python.org  Tue Feb 15 18:11:21 2022
From: report at bugs.python.org (Stefano Rivera)
Date: Tue, 15 Feb 2022 23:11:21 +0000
Subject: [issue43976] Allow Python distributors to add custom site install
 schemes
In-Reply-To: <1619713142.43.0.43081473036.issue43976@roundup.psfhosted.org>
Message-ID: <1644966681.86.0.584028725549.issue43976@roundup.psfhosted.org>


Change by Stefano Rivera <python at rivera.za.net>:


----------
nosy: +stefanor

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43976>
_______________________________________

From report at bugs.python.org  Tue Feb 15 18:12:20 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 15 Feb 2022 23:12:20 +0000
Subject: [issue46737] Default to the standard normal distribution
In-Reply-To: <1644751625.52.0.483632432415.issue46737@roundup.psfhosted.org>
Message-ID: <1644966740.95.0.422196910412.issue46737@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 08ec80113b3b7f7a9eaa3d217494536b63305181 by Zackery Spytz in branch 'main':
bpo-46737: Add default arguments to random.gauss and normalvariate (GH-31360)
https://github.com/python/cpython/commit/08ec80113b3b7f7a9eaa3d217494536b63305181


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46737>
_______________________________________

From report at bugs.python.org  Tue Feb 15 18:12:25 2022
From: report at bugs.python.org (Stefano Rivera)
Date: Tue, 15 Feb 2022 23:12:25 +0000
Subject: [issue44445] Add `site-include` install scheme path in sysconfig
In-Reply-To: <1623942208.43.0.621445516609.issue44445@roundup.psfhosted.org>
Message-ID: <1644966745.17.0.29262682588.issue44445@roundup.psfhosted.org>


Change by Stefano Rivera <python at rivera.za.net>:


----------
nosy: +stefanor

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44445>
_______________________________________

From report at bugs.python.org  Tue Feb 15 18:12:35 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 15 Feb 2022 23:12:35 +0000
Subject: [issue46737] Default to the standard normal distribution
In-Reply-To: <1644751625.52.0.483632432415.issue46737@roundup.psfhosted.org>
Message-ID: <1644966755.25.0.0475705090742.issue46737@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/issue46737>
_______________________________________

From report at bugs.python.org  Tue Feb 15 18:42:23 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 15 Feb 2022 23:42:23 +0000
Subject: [issue46752] Introduce task groups to asyncio and change task
 cancellation semantics
In-Reply-To: <1644871469.64.0.38816696304.issue46752@roundup.psfhosted.org>
Message-ID: <1644968543.73.0.0852278664327.issue46752@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset 602630ac1855e38ef06361c68f6e216375a06180 by Guido van Rossum in branch 'main':
bpo-46752: Add TaskGroup; add Task..cancelled(),.uncancel() (GH-31270)
https://github.com/python/cpython/commit/602630ac1855e38ef06361c68f6e216375a06180


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46752>
_______________________________________

From report at bugs.python.org  Tue Feb 15 18:45:51 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 15 Feb 2022 23:45:51 +0000
Subject: [issue46752] Introduce task groups to asyncio and change task
 cancellation semantics
In-Reply-To: <1644871469.64.0.38816696304.issue46752@roundup.psfhosted.org>
Message-ID: <1644968751.8.0.956133022055.issue46752@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Remaining TODO list:

- Add a test showing the need for the .uncancel() call in __aexit__()
  (currently on line 97). Dropping that line does not cause any tests
  to fail.
- Ensure the taskgroup tests are run with the C and Python Task
  implementations.
- Rename tests to have meaningful names.
- I have a few ideas for minor cleanups that I will do later.
- Documentation and What's New entry (in a separate PR, probably).
- Update the docs in a few places to de-prioritize asyncio.gather()
  and steer people towards TaskGroups.

(We could also add something like Trio's cancel scopes, e.g. based on
Andrew Svetlov's async-timeout, which has a mature API.
But that should be a separate bpo issue.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46752>
_______________________________________

From report at bugs.python.org  Tue Feb 15 20:05:27 2022
From: report at bugs.python.org (Eric Snow)
Date: Wed, 16 Feb 2022 01:05:27 +0000
Subject: [issue46541] Replace _Py_IDENTIFIER() with statically initialized
 objects.
In-Reply-To: <1643234464.46.0.949364478641.issue46541@roundup.psfhosted.org>
Message-ID: <1644973527.75.0.105153680638.issue46541@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
pull_requests: +29513
pull_request: https://github.com/python/cpython/pull/31363

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46541>
_______________________________________

From report at bugs.python.org  Tue Feb 15 20:21:36 2022
From: report at bugs.python.org (Eric Snow)
Date: Wed, 16 Feb 2022 01:21:36 +0000
Subject: [issue46541] Replace _Py_IDENTIFIER() with statically initialized
 objects.
In-Reply-To: <1643234464.46.0.949364478641.issue46541@roundup.psfhosted.org>
Message-ID: <1644974496.2.0.310127966633.issue46541@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
pull_requests: +29514
pull_request: https://github.com/python/cpython/pull/31364

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46541>
_______________________________________

From report at bugs.python.org  Tue Feb 15 20:25:07 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 16 Feb 2022 01:25:07 +0000
Subject: [issue46762] assertion failure in f-string parsing
 Parser/string_parser.c
In-Reply-To: <1644963592.59.0.718749450454.issue46762@roundup.psfhosted.org>
Message-ID: <1644974707.29.0.603754798923.issue46762@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
keywords: +patch
pull_requests: +29515
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31365

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46762>
_______________________________________

From report at bugs.python.org  Tue Feb 15 20:45:13 2022
From: report at bugs.python.org (Nick Venenga)
Date: Wed, 16 Feb 2022 01:45:13 +0000
Subject: [issue46763] os.path.samefile incorrect results for shadow copies
Message-ID: <1644975913.58.0.577499491465.issue46763@roundup.psfhosted.org>


New submission from Nick Venenga <nick at venenga.com>:

shutil.copy fails to copy a file from a shadow copy back to its original file since os.path.samefile returns True. os.path.samefile doesn't reliably detect these files are different since it relies on ino which is the same for both files

>>> sc = pathlib.Path('//?/GLOBALROOT/Device/HarddiskVolumeShadowCopy3/test.file')
>>> o = pathlib.Path("V:/test.file")
>>> os.path.samefile(sc, o)
True
>>> os.stat(sc)
os.stat_result(st_mode=33206, st_ino=3458764513820579328, st_dev=1792739134, st_nlink=1, st_uid=0, st_gid=0, st_size=1, st_atime=1644973968, st_mtime=1644974052, st_ctime=1644973968)
>>> os.stat(o)
os.stat_result(st_mode=33206, st_ino=3458764513820579328, st_dev=1792739134, st_nlink=1, st_uid=0, st_gid=0, st_size=2, st_atime=1644973968, st_mtime=1644974300, st_ctime=1644973968)
>>> open(sc, "r").read()
'1'
>>> open(o, "r").read()
'12'

In the above example, you can see the shadow copy file and the original file. Their mode and ino are the same, but their modified time and contents are different

----------
components: Windows
messages: 413307
nosy: nijave, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: os.path.samefile incorrect results for shadow copies
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46763>
_______________________________________

From report at bugs.python.org  Tue Feb 15 20:49:24 2022
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 16 Feb 2022 01:49:24 +0000
Subject: [issue46733] pathlib.Path methods can raise NotImplementedError
In-Reply-To: <1644694513.05.0.985214969865.issue46733@roundup.psfhosted.org>
Message-ID: <1644976164.81.0.378447377412.issue46733@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> I'm planning to learn more heavily on posixpath + ntpath in 
> pathlib once bpo-44136 is done. I think that would be a good 
> time to introduce is_mount() support on Windows.

In the long run, it would be better to migrate the implementations in the other direction. Rewrite genericpath, ntpath, posixpath, and parts of shutil to use PurePath and Path objects. Using path objects instead of generic strings should improve the implementation of os.path and shutil, in addition to ensuring consistency with pathlib. However, that's a long-term goal that doesn't preclude using os.path and shutil as needed now, such as relying on os.path.ismount().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46733>
_______________________________________

From report at bugs.python.org  Tue Feb 15 20:50:19 2022
From: report at bugs.python.org (Nick Venenga)
Date: Wed, 16 Feb 2022 01:50:19 +0000
Subject: [issue46763] os.path.samefile incorrect results for shadow copies
In-Reply-To: <1644975913.58.0.577499491465.issue46763@roundup.psfhosted.org>
Message-ID: <1644976219.19.0.506600722054.issue46763@roundup.psfhosted.org>


Nick Venenga <nick at venenga.com> added the comment:

This script can reproduce the issue. 

The computer must be a Windows computer with volume shadow copy service enabled
The computer must have shadow storage added to the drive being used
This script changes the host machine by creating a shadow copy (permissions to create shadow copies are required)

----------
Added file: https://bugs.python.org/file50626/shadow-repro.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46763>
_______________________________________

From report at bugs.python.org  Tue Feb 15 20:56:29 2022
From: report at bugs.python.org (Michael J. Sullivan)
Date: Wed, 16 Feb 2022 01:56:29 +0000
Subject: [issue46764] Wrapping a bound method with a @classmethod no longer
 works
Message-ID: <1644976589.23.0.130675982792.issue46764@roundup.psfhosted.org>


New submission from Michael J. Sullivan <sully at msully.net>:

class A:
    def foo(self, cls): return 1

class B: pass

class B:
    bar = classmethod(A().foo)

B.bar()


In Python 3.8 and prior, this worked. Since Python 3.9, it produces "TypeError: A.foo() missing 1 required positional argument: 'cls'"

I tracked it down, and the issue was introduced by https://github.com/python/cpython/pull/8405/files, which makes classmethod's tp_descr_get invoke its argument tp_descr_get when present instead of calling PyMethod_New. That this was a semantics change that could break existing code may have been missed (though it is a fairly obscure such change).

The reason it breaks this case in particular of bound methods, though, is that bound methods have a tp_descr_get that does nothing (increfs the method and then returns it). Dropping that tp_descr_get fixes this issue and doesn't introduce any test failures. Not sure if there is some potential downstream breakage of that?

(This issue was originally reported to me by Jared Hance)

----------
components: Interpreter Core
messages: 413310
nosy: msullivan
priority: normal
severity: normal
status: open
title: Wrapping a bound method with a @classmethod no longer works
versions: Python 3.10, Python 3.11, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46764>
_______________________________________

From report at bugs.python.org  Tue Feb 15 21:51:23 2022
From: report at bugs.python.org (Martin Panter)
Date: Wed, 16 Feb 2022 02:51:23 +0000
Subject: [issue46738] Allow http.server to emit HTML 5
In-Reply-To: <1644757078.96.0.518529275585.issue46738@roundup.psfhosted.org>
Message-ID: <1644979883.26.0.392053340402.issue46738@roundup.psfhosted.org>


Change by Martin Panter <vadmium+py at gmail.com>:


----------
superseder:  -> Generate HTML 5 with SimpleHTTPRequestHandler.list_directory

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46738>
_______________________________________

From report at bugs.python.org  Tue Feb 15 22:06:42 2022
From: report at bugs.python.org (Eric Snow)
Date: Wed, 16 Feb 2022 03:06:42 +0000
Subject: [issue46541] Replace _Py_IDENTIFIER() with statically initialized
 objects.
In-Reply-To: <1643234464.46.0.949364478641.issue46541@roundup.psfhosted.org>
Message-ID: <1644980802.73.0.320209137482.issue46541@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:


New changeset 6c8958948666403f2370ca7b4c0a52b2010ec16d by Eric Snow in branch 'main':
bpo-46541: Drop the check for orphaned global strings. (gh-31363)
https://github.com/python/cpython/commit/6c8958948666403f2370ca7b4c0a52b2010ec16d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46541>
_______________________________________

From report at bugs.python.org  Tue Feb 15 22:07:14 2022
From: report at bugs.python.org (Eric Snow)
Date: Wed, 16 Feb 2022 03:07:14 +0000
Subject: [issue46541] Replace _Py_IDENTIFIER() with statically initialized
 objects.
In-Reply-To: <1643234464.46.0.949364478641.issue46541@roundup.psfhosted.org>
Message-ID: <1644980834.78.0.742073001774.issue46541@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:


New changeset 4d8a515d193a4c9f3844704f974ddb870d7ee383 by Eric Snow in branch 'main':
bpo-46541: Scan Fewer Files in generate_global_objects.py (gh-31364)
https://github.com/python/cpython/commit/4d8a515d193a4c9f3844704f974ddb870d7ee383


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46541>
_______________________________________

From report at bugs.python.org  Tue Feb 15 22:15:26 2022
From: report at bugs.python.org (Alex Waygood)
Date: Wed, 16 Feb 2022 03:15:26 +0000
Subject: [issue46764] Wrapping a bound method with a @classmethod no longer
 works
In-Reply-To: <1644976589.23.0.130675982792.issue46764@roundup.psfhosted.org>
Message-ID: <1644981326.6.0.152749400595.issue46764@roundup.psfhosted.org>


Change by Alex Waygood <Alex.Waygood at Gmail.com>:


----------
nosy: +rhettinger
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46764>
_______________________________________

From report at bugs.python.org  Tue Feb 15 22:16:42 2022
From: report at bugs.python.org (Eric Snow)
Date: Wed, 16 Feb 2022 03:16:42 +0000
Subject: [issue46765] Replace Locally Cached Strings with Statically
 Initialized Objects
Message-ID: <1644981402.43.0.406024734296.issue46765@roundup.psfhosted.org>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

This removes a number of static variables and is a little more efficient.

----------
assignee: eric.snow
components: Interpreter Core
messages: 413313
nosy: eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: Replace Locally Cached Strings with Statically Initialized Objects
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46765>
_______________________________________

From report at bugs.python.org  Tue Feb 15 22:18:12 2022
From: report at bugs.python.org (Eric Snow)
Date: Wed, 16 Feb 2022 03:18:12 +0000
Subject: [issue46765] Replace Locally Cached Strings with Statically
 Initialized Objects
In-Reply-To: <1644981402.43.0.406024734296.issue46765@roundup.psfhosted.org>
Message-ID: <1644981492.85.0.415683551068.issue46765@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
keywords: +patch
pull_requests: +29516
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31366

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46765>
_______________________________________

From report at bugs.python.org  Tue Feb 15 22:22:23 2022
From: report at bugs.python.org (Michael J. Sullivan)
Date: Wed, 16 Feb 2022 03:22:23 +0000
Subject: [issue46764] Wrapping a bound method with a @classmethod no longer
 works
In-Reply-To: <1644976589.23.0.130675982792.issue46764@roundup.psfhosted.org>
Message-ID: <1644981743.79.0.0399680787568.issue46764@roundup.psfhosted.org>


Change by Michael J. Sullivan <sully at msully.net>:


----------
keywords: +patch
pull_requests: +29517
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31367

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46764>
_______________________________________

From report at bugs.python.org  Tue Feb 15 23:01:03 2022
From: report at bugs.python.org (karl)
Date: Wed, 16 Feb 2022 04:01:03 +0000
Subject: [issue46337] urllib.parse: Allow more flexibility in schemes and URL
 resolution behavior
In-Reply-To: <1641851456.34.0.342855463339.issue46337@roundup.psfhosted.org>
Message-ID: <1644984063.29.0.498998626012.issue46337@roundup.psfhosted.org>


karl <karl+pythonbugs at la-grange.net> added the comment:

Just to note that there is a maintained list of officially accepted schemes at IANA.
https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml

In addition there is a list of unofficial schemes on wikipedia 
https://en.wikipedia.org/wiki/List_of_URI_schemes#Unofficial_but_common_URI_schemes

----------
nosy: +karlcow

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46337>
_______________________________________

From report at bugs.python.org  Tue Feb 15 23:56:32 2022
From: report at bugs.python.org (Isaac Johnson)
Date: Wed, 16 Feb 2022 04:56:32 +0000
Subject: [issue46766] Add a class for file operations so a syntax such as
 open("file.img", File.Write | File.Binary | File.Disk) is possible.
Message-ID: <1644987392.44.0.618461662976.issue46766@roundup.psfhosted.org>


New submission from Isaac Johnson <isaacsjohnson22 at gmail.com>:

I think it would be great for something like this to be with the IO module. It will improve code readability.

----------
components: Library (Lib)
messages: 413315
nosy: isaacsjohnson22
priority: normal
severity: normal
status: open
title: Add a class for file operations so a syntax such as open("file.img", File.Write | File.Binary | File.Disk) is possible.
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46766>
_______________________________________

From report at bugs.python.org  Tue Feb 15 23:57:08 2022
From: report at bugs.python.org (Isaac Johnson)
Date: Wed, 16 Feb 2022 04:57:08 +0000
Subject: [issue46766] Add a class for file operations so a syntax such as
 open("file.img", File.Write | File.Binary | File.Disk) is possible.
In-Reply-To: <1644987392.44.0.618461662976.issue46766@roundup.psfhosted.org>
Message-ID: <1644987428.19.0.862103387498.issue46766@roundup.psfhosted.org>


Isaac Johnson <isaacsjohnson22 at gmail.com> added the comment:

I'm currently working on implementing this. It will probably be a few weeks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46766>
_______________________________________

From report at bugs.python.org  Wed Feb 16 00:42:13 2022
From: report at bugs.python.org (Isaac Johnson)
Date: Wed, 16 Feb 2022 05:42:13 +0000
Subject: [issue46766] Add a class for file operations so a syntax such as
 open("file.img", File.Write | File.Binary | File.Disk) is possible.
In-Reply-To: <1644987392.44.0.618461662976.issue46766@roundup.psfhosted.org>
Message-ID: <1644990133.59.0.272473341523.issue46766@roundup.psfhosted.org>


Change by Isaac Johnson <isaacsjohnson22 at gmail.com>:


----------
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46766>
_______________________________________

From report at bugs.python.org  Wed Feb 16 01:42:24 2022
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 16 Feb 2022 06:42:24 +0000
Subject: [issue46766] Add a class for file operations so a syntax such as
 open("file.img", File.Write | File.Binary | File.Disk) is possible.
In-Reply-To: <1644987392.44.0.618461662976.issue46766@roundup.psfhosted.org>
Message-ID: <1644993744.72.0.119748788358.issue46766@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

I'm sorry, I don't see why you think this will improve code readability. I also expect it will be harder to teach than the current code.

open("file.img", "wb") just needs the user to learn about reading and writing files, and the difference between binary and text files. It works the same way in probably dozens of different languages.

open("file.img", File.Write | File.Binary | File.Disk) needs the beginner to learn the same details, *plus* they have to learn about this mystery File object, classes, dot notation, `|` the bitwise-or operator, and how to import File from the io module.

My guess is that File.Write etc are just enums equivalent to strings 'w' and 'b', but what's File.Disk?

What else does this File object do?

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46766>
_______________________________________

From report at bugs.python.org  Wed Feb 16 02:07:43 2022
From: report at bugs.python.org (Dennis Sweeney)
Date: Wed, 16 Feb 2022 07:07:43 +0000
Subject: [issue46730] Please consider mentioning property without setter when
 an attribute can't be set
In-Reply-To: <1644664548.7.0.814482728123.issue46730@roundup.psfhosted.org>
Message-ID: <1644995263.97.0.034994764832.issue46730@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:


New changeset 0cb765b2cec9b020224af016a83bf35c45b71932 by Alex-Blade in branch 'main':
bpo-46730: Add more info to @property AttributeError messages (GH-31311)
https://github.com/python/cpython/commit/0cb765b2cec9b020224af016a83bf35c45b71932


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46730>
_______________________________________

From report at bugs.python.org  Wed Feb 16 02:16:46 2022
From: report at bugs.python.org (Dennis Sweeney)
Date: Wed, 16 Feb 2022 07:16:46 +0000
Subject: [issue46730] Please consider mentioning property without setter when
 an attribute can't be set
In-Reply-To: <1644664548.7.0.814482728123.issue46730@roundup.psfhosted.org>
Message-ID: <1644995806.22.0.816663135403.issue46730@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.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/issue46730>
_______________________________________

From report at bugs.python.org  Wed Feb 16 02:38:29 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 16 Feb 2022 07:38:29 +0000
Subject: [issue30267] Deprecate os.path.commonprefix
In-Reply-To: <1493913753.36.0.555235038331.issue30267@psf.upfronthosting.co.za>
Message-ID: <1644997109.87.0.282202764319.issue30267@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

For now, there are three uses of commonprefix() in the stdlib:

1. In urllib.request it causes a security issue (see issue46756). commonpath() or just str.startswith() should be used instead.

2. In lib2to3.main. The code contains a workaround around commonprefix(). It could be simplified by using commonpath().

3. In unittest.util. This is the only correct use of commonprefix(). It cannot be replaced by commonpath().

I think that we should add commonprefix() in the string module (or maybe in a new module for operations on sequences), deprecate os.path.commonprefix() in documentation only, several versions later add a deprecation warning in os.path.commonprefix(), and several versions later remove os.path.commonprefix().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30267>
_______________________________________

From report at bugs.python.org  Wed Feb 16 03:01:06 2022
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 16 Feb 2022 08:01:06 +0000
Subject: [issue34526] Path.relative_to() taking multiple arguments could be
 better documented
In-Reply-To: <1535445749.23.0.56676864532.issue34526@psf.upfronthosting.co.za>
Message-ID: <1644998466.65.0.957782041445.issue34526@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
nosy: +python-dev
nosy_count: 3.0 -> 4.0
pull_requests: +29518
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31368

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34526>
_______________________________________

From report at bugs.python.org  Wed Feb 16 03:35:37 2022
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 16 Feb 2022 08:35:37 +0000
Subject: [issue46766] Add a class for file operations so a syntax such as
 open("file.img", File.Write | File.Binary | File.Disk) is possible.
In-Reply-To: <1644987392.44.0.618461662976.issue46766@roundup.psfhosted.org>
Message-ID: <1645000537.78.0.0744350747387.issue46766@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This looks similar to a previous proposal

https://discuss.python.org/t/enum-for-open-modes/2445

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46766>
_______________________________________

From report at bugs.python.org  Wed Feb 16 03:42:33 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 16 Feb 2022 08:42:33 +0000
Subject: [issue46766] Add a class for file operations so a syntax such as
 open("file.img", File.Write | File.Binary | File.Disk) is possible.
In-Reply-To: <1644987392.44.0.618461662976.issue46766@roundup.psfhosted.org>
Message-ID: <1645000953.71.0.797711551168.issue46766@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

You can create a module on PyPI. If it becomes popular we could consider including in the stdlib.

----------
nosy: +serhiy.storchaka
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46766>
_______________________________________

From report at bugs.python.org  Wed Feb 16 04:57:52 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 16 Feb 2022 09:57:52 +0000
Subject: [issue46541] Replace _Py_IDENTIFIER() with statically initialized
 objects.
In-Reply-To: <1643234464.46.0.949364478641.issue46541@roundup.psfhosted.org>
Message-ID: <1645005472.7.0.962159533121.issue46541@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:


New changeset e59309b9d0969d5c8f493cb8df28afa6f38d6273 by Dong-hee Na in branch 'main':
bpo-46541: Remove usage of _Py_IDENTIFIER from dbms modules (GH-31358)
https://github.com/python/cpython/commit/e59309b9d0969d5c8f493cb8df28afa6f38d6273


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46541>
_______________________________________

From report at bugs.python.org  Wed Feb 16 05:41:09 2022
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 16 Feb 2022 10:41:09 +0000
Subject: [issue46760] test_dis should test the dis module, not everything else
In-Reply-To: <1644934628.87.0.437399260946.issue46760@roundup.psfhosted.org>
Message-ID: <1645008069.92.0.867685339991.issue46760@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
keywords: +patch
pull_requests: +29519
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31369

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46760>
_______________________________________

From report at bugs.python.org  Wed Feb 16 05:54:20 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 16 Feb 2022 10:54:20 +0000
Subject: [issue46762] assertion failure in f-string parsing
 Parser/string_parser.c
In-Reply-To: <1644963592.59.0.718749450454.issue46762@roundup.psfhosted.org>
Message-ID: <1645008860.14.0.159920504939.issue46762@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:


New changeset ffd9f8ff84ed53c956b16d027f7d2926ea631051 by Eric V. Smith in branch 'main':
bpo-46762: Fix an assert failure in f-strings where > or < is the last character if the f-string is missing a trailing right brace. (#31365)
https://github.com/python/cpython/commit/ffd9f8ff84ed53c956b16d027f7d2926ea631051


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46762>
_______________________________________

From report at bugs.python.org  Wed Feb 16 05:54:30 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 16 Feb 2022 10:54:30 +0000
Subject: [issue46762] assertion failure in f-string parsing
 Parser/string_parser.c
In-Reply-To: <1644963592.59.0.718749450454.issue46762@roundup.psfhosted.org>
Message-ID: <1645008870.17.0.939232588154.issue46762@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: +29520
pull_request: https://github.com/python/cpython/pull/31370

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46762>
_______________________________________

From report at bugs.python.org  Wed Feb 16 05:54:34 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 16 Feb 2022 10:54:34 +0000
Subject: [issue46762] assertion failure in f-string parsing
 Parser/string_parser.c
In-Reply-To: <1644963592.59.0.718749450454.issue46762@roundup.psfhosted.org>
Message-ID: <1645008874.83.0.923256533152.issue46762@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29521
pull_request: https://github.com/python/cpython/pull/31371

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46762>
_______________________________________

From report at bugs.python.org  Wed Feb 16 06:05:51 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 16 Feb 2022 11:05:51 +0000
Subject: [issue46541] Replace _Py_IDENTIFIER() with statically initialized
 objects.
In-Reply-To: <1643234464.46.0.949364478641.issue46541@roundup.psfhosted.org>
Message-ID: <1645009551.22.0.030822785267.issue46541@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
pull_requests: +29522
pull_request: https://github.com/python/cpython/pull/31372

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46541>
_______________________________________

From report at bugs.python.org  Wed Feb 16 06:16:11 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 16 Feb 2022 11:16:11 +0000
Subject: [issue46762] assertion failure in f-string parsing
 Parser/string_parser.c
In-Reply-To: <1644963592.59.0.718749450454.issue46762@roundup.psfhosted.org>
Message-ID: <1645010171.28.0.530797280494.issue46762@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 3d407b931156bc3ee5ae131de2f2babad831ccb2 by Miss Islington (bot) in branch '3.10':
bpo-46762: Fix an assert failure in f-strings where > or < is the last character if the f-string is missing a trailing right brace. (GH-31365)
https://github.com/python/cpython/commit/3d407b931156bc3ee5ae131de2f2babad831ccb2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46762>
_______________________________________

From report at bugs.python.org  Wed Feb 16 06:16:24 2022
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 16 Feb 2022 11:16:24 +0000
Subject: [issue46762] assertion failure in f-string parsing
 Parser/string_parser.c
In-Reply-To: <1644963592.59.0.718749450454.issue46762@roundup.psfhosted.org>
Message-ID: <1645010184.83.0.565792040305.issue46762@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Thanks for the quick fix, Eric!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46762>
_______________________________________

From report at bugs.python.org  Wed Feb 16 06:16:39 2022
From: report at bugs.python.org (Pierre Thierry)
Date: Wed, 16 Feb 2022 11:16:39 +0000
Subject: [issue46767] [Doc] sqlite3 Cursor.execute() return value is
 unspecified
Message-ID: <1645010199.07.0.291024534189.issue46767@roundup.psfhosted.org>


New submission from Pierre Thierry <pierre at nothos.net>:

In the documentation of the sqlite3 module, the return value for Connection.execute() is told to be the Cursor that was implicitly created, but nothing is said about the return value/type when using Cursor.execute().

----------
components: Library (Lib)
messages: 413327
nosy: kephas
priority: normal
severity: normal
status: open
title: [Doc] sqlite3 Cursor.execute() return value is unspecified
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46767>
_______________________________________

From report at bugs.python.org  Wed Feb 16 06:18:21 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 16 Feb 2022 11:18:21 +0000
Subject: [issue46762] assertion failure in f-string parsing
 Parser/string_parser.c
In-Reply-To: <1644963592.59.0.718749450454.issue46762@roundup.psfhosted.org>
Message-ID: <1645010301.3.0.777200523672.issue46762@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a657bff34945e40be24cd75d02560a93b7623cf5 by Miss Islington (bot) in branch '3.9':
bpo-46762: Fix an assert failure in f-strings where > or < is the last character if the f-string is missing a trailing right brace. (GH-31365)
https://github.com/python/cpython/commit/a657bff34945e40be24cd75d02560a93b7623cf5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46762>
_______________________________________

From report at bugs.python.org  Wed Feb 16 06:26:17 2022
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 16 Feb 2022 11:26:17 +0000
Subject: [issue46724] Odd Bytecode Generation in 3.10
In-Reply-To: <1644600146.24.0.968453673832.issue46724@roundup.psfhosted.org>
Message-ID: <1645010777.32.0.24873446033.issue46724@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset d4e4ef107a9fea257981d7701f023177b704a44f by Mark Shannon in branch '3.10':
[3.10] bpo-46724: Use `JUMP_ABSOLUTE` for all backward jumps. (GH-31326) (GH-31354)
https://github.com/python/cpython/commit/d4e4ef107a9fea257981d7701f023177b704a44f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46724>
_______________________________________

From report at bugs.python.org  Wed Feb 16 07:17:31 2022
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 16 Feb 2022 12:17:31 +0000
Subject: [issue46762] assertion failure in f-string parsing
 Parser/string_parser.c
In-Reply-To: <1644963592.59.0.718749450454.issue46762@roundup.psfhosted.org>
Message-ID: <1645013851.93.0.756895041642.issue46762@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/issue46762>
_______________________________________

From report at bugs.python.org  Wed Feb 16 07:46:38 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 16 Feb 2022 12:46:38 +0000
Subject: [issue29418] inspect.isroutine does not return True for some bound
 builtin methods
In-Reply-To: <1486027973.42.0.383629669841.issue29418@psf.upfronthosting.co.za>
Message-ID: <1645015598.36.0.858144503789.issue29418@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 562c13f5734d406b2283cfca673611f4b496fdc7 by Hakan ?elik in branch 'main':
bpo-29418: Implement inspect.ismethodwrapper and fix inspect.isroutine for cases where methodwrapper is given (GH-19261)
https://github.com/python/cpython/commit/562c13f5734d406b2283cfca673611f4b496fdc7


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29418>
_______________________________________

From report at bugs.python.org  Wed Feb 16 07:48:19 2022
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 16 Feb 2022 12:48:19 +0000
Subject: [issue46763] os.path.samefile incorrect results for shadow copies
In-Reply-To: <1644975913.58.0.577499491465.issue46763@roundup.psfhosted.org>
Message-ID: <1645015699.57.0.426740918945.issue46763@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

Python uses the volume serial number (VSN) and file ID for st_dev and st_ino. The OS allows the file ID to be 0 if the filesystem doesn't support file IDs. Also, it does not require or force the VSN to be a unique ID in the system, though if it's not 0 it's almost always a random 32-bit number for which the chance of collision is vanishingly small (notwithstanding a volume shadow copy, apparently). This means that (st_dev, st_ino) by itself is not sufficient to check whether two paths are the same file in Windows.

Proposal:

When comparing two file paths, if their (st_dev, st_ino) values differ, then they're not the same file. If their (st_dev, st_ino) values are the same, use the final NT paths from calling GetFinalPathNameByHandleW() with the flags VOLUME_NAME_NT | FILE_NAME_NORMALIZED. If only one of the paths supports FILE_NAME_NORMALIZED, then they're not the same file. If neither supports FILE_NAME_NORMALIZED, fall back on VOLUME_NAME_NT | FILE_NAME_OPENED. If either st_dev is 0 or st_ino is 0, the files are the same only if the final NT paths are the same. Else split out each device path. If the device paths are the same, then the paths are the same file. Otherwise they're different files.

We should probably special case the comparison of a multiple UNC provider path with a local volume path. For example r'\\localhost\C$\Windows' is the same as r'C:\Windows'. The corresponding NT paths are r'\Device\Mup\localhost\C$\Windows' and typically r'\Device\HarddiskVolume2\Windows'. The special case is that when one of the device paths is "\Device\Mup", the two device paths are not required to be the same. Of course, this is given that the (st_dev, st_ino) values are the same, and neither st_dev nor st_ino is zero.

That said, we would need to exclude volume shadow copies from the special case. I suppose we could just look for "VolumeShadowCopy" in the device name. Maybe we can do better. I've noticed that querying IOCTL_STORAGE_GET_DEVICE_NUMBER fails for a volume shadow copy, but that's probably going overboard.

----------
nosy: +eryksun
stage:  -> needs patch
versions: +Python 3.10, Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46763>
_______________________________________

From report at bugs.python.org  Wed Feb 16 07:55:31 2022
From: report at bugs.python.org (zjmxq)
Date: Wed, 16 Feb 2022 12:55:31 +0000
Subject: [issue45069] CVE-201-4160 Vulnerability Is Found in
 Lib/site-packages/cryptography/hazmat/bindings/_openssl.pyd for Cryptography
 Version 3.3.2
In-Reply-To: <1630466357.81.0.93174296975.issue45069@roundup.psfhosted.org>
Message-ID: <1645016131.51.0.8251080684.issue45069@roundup.psfhosted.org>


Change by zjmxq <zjmxq180 at 163.com>:


----------
components: +Library (Lib)
title: python 3.9.2 contains libcrypto-1_1.dll and libssl-1_1.dll associates CVE-2021-23840\CVE-2021-3450\CVE-2021-3711\CVE-2021-3712\CVE-2021-23841\CVE-2021-3449 of openssl-1.1.1i -> CVE-201-4160 Vulnerability Is Found in Lib/site-packages/cryptography/hazmat/bindings/_openssl.pyd for Cryptography Version 3.3.2
type:  -> security

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45069>
_______________________________________

From report at bugs.python.org  Wed Feb 16 07:57:14 2022
From: report at bugs.python.org (zjmxq)
Date: Wed, 16 Feb 2022 12:57:14 +0000
Subject: [issue46768] CVE-201-4160 Vulnerability Is Found in
 Lib/site-packages/cryptography/hazmat/bindings/_openssl.pyd for Cryptography
 Version 3.3.2
Message-ID: <1645016234.03.0.578869822824.issue46768@roundup.psfhosted.org>


Change by zjmxq <zjmxq180 at 163.com>:


----------
components: Library (Lib)
nosy: zjmxq
priority: normal
severity: normal
status: open
title: CVE-201-4160 Vulnerability Is Found in Lib/site-packages/cryptography/hazmat/bindings/_openssl.pyd for Cryptography Version 3.3.2
type: security
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46768>
_______________________________________

From report at bugs.python.org  Wed Feb 16 07:59:21 2022
From: report at bugs.python.org (zjmxq)
Date: Wed, 16 Feb 2022 12:59:21 +0000
Subject: [issue45069] python 3.9.2 contains libcrypto-1_1.dll and
 libssl-1_1.dll associates
 CVE-2021-23840\CVE-2021-3450\CVE-2021-3711\CVE-2021-3712\CVE-2021-23841\CVE-2021-3449
 of openssl-1.1.1i
In-Reply-To: <1630466357.81.0.93174296975.issue45069@roundup.psfhosted.org>
Message-ID: <1645016361.65.0.924253241222.issue45069@roundup.psfhosted.org>


Change by zjmxq <zjmxq180 at 163.com>:


----------
components:  -Library (Lib)
title: CVE-201-4160 Vulnerability Is Found in Lib/site-packages/cryptography/hazmat/bindings/_openssl.pyd for Cryptography Version 3.3.2 -> python 3.9.2 contains libcrypto-1_1.dll and libssl-1_1.dll associates CVE-2021-23840\CVE-2021-3450\CVE-2021-3711\CVE-2021-3712\CVE-2021-23841\CVE-2021-3449 of openssl-1.1.1i

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45069>
_______________________________________

From report at bugs.python.org  Wed Feb 16 08:10:35 2022
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 16 Feb 2022 13:10:35 +0000
Subject: [issue46329] Split up the CALL_NO_KW and CALL_KW instructions.
In-Reply-To: <1641819285.76.0.605357810946.issue46329@roundup.psfhosted.org>
Message-ID: <1645017035.93.0.18508029309.issue46329@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
pull_requests: +29523
pull_request: https://github.com/python/cpython/pull/31373

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46329>
_______________________________________

From report at bugs.python.org  Wed Feb 16 09:38:06 2022
From: report at bugs.python.org (Erlend E. Aasland)
Date: Wed, 16 Feb 2022 14:38:06 +0000
Subject: [issue46767] [Doc] sqlite3 Cursor.execute() return value is
 unspecified
In-Reply-To: <1645010199.07.0.291024534189.issue46767@roundup.psfhosted.org>
Message-ID: <1645022286.5.0.505229518334.issue46767@roundup.psfhosted.org>


Erlend E. Aasland <erlend.aasland at innova.no> added the comment:

Quoting the docs:

> This is a nonstandard shortcut that creates a cursor object by calling the
> cursor() method, calls the cursor?s execute() method with the parameters
> given, and returns the cursor.

There is already a backlink (or back reference) to the Connection.cursor() method, which again has a backlink to the Cursor class. What would you suggest to make things clearer?

How about the following rewording:

"[...] and returns the newly created cursor object".

(IMO this is too verbose; I'm fine with the current docs.)

----------
nosy: +erlendaasland

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46767>
_______________________________________

From report at bugs.python.org  Wed Feb 16 10:24:18 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 16 Feb 2022 15:24:18 +0000
Subject: [issue46541] Replace _Py_IDENTIFIER() with statically initialized
 objects.
In-Reply-To: <1643234464.46.0.949364478641.issue46541@roundup.psfhosted.org>
Message-ID: <1645025058.18.0.878087706771.issue46541@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:


New changeset d64f3caebe8f8e31ecd193e0bd25105400153ece by Dong-hee Na in branch 'main':
bpo-46541: Remove usage of _Py_IDENTIFIER from csv module (GH-31372)
https://github.com/python/cpython/commit/d64f3caebe8f8e31ecd193e0bd25105400153ece


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46541>
_______________________________________

From report at bugs.python.org  Wed Feb 16 10:24:48 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 16 Feb 2022 15:24:48 +0000
Subject: [issue46541] Replace _Py_IDENTIFIER() with statically initialized
 objects.
In-Reply-To: <1643234464.46.0.949364478641.issue46541@roundup.psfhosted.org>
Message-ID: <1645025088.66.0.960387086471.issue46541@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:


New changeset b2077117d125925210148294eefee28797b7ff4c by Erlend Egeberg Aasland in branch 'main':
bpo-46541: Replace _Py_IDENTIFIER with _Py_ID in sqlite3 (GH-31351)
https://github.com/python/cpython/commit/b2077117d125925210148294eefee28797b7ff4c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46541>
_______________________________________

From report at bugs.python.org  Wed Feb 16 10:29:01 2022
From: report at bugs.python.org (Dan Halbert)
Date: Wed, 16 Feb 2022 15:29:01 +0000
Subject: [issue46752] Introduce task groups to asyncio and change task
 cancellation semantics
In-Reply-To: <1644871469.64.0.38816696304.issue46752@roundup.psfhosted.org>
Message-ID: <1645025341.43.0.503627925386.issue46752@roundup.psfhosted.org>


Dan Halbert <halbert at halwitz.org> added the comment:

For your TODO list (not sure how else to communicate this):

I agree with the de-emphasis of gather(). I think adding another version of gather() that cancels all the remaining tasks if one fails would also be good, unless you think it is completely redundant due to TaskGroups. This idea was originally mentioned in https://bugs.python.org/issue31452 as a bug, and determined to be "works as designed". So now making an all-cancel() version of gather() is an idiom that people keep recoding, e.g. https://stackoverflow.com/questions/59073556/how-to-cancel-all-remaining-tasks-in-gather-if-one-fails.

----------
nosy: +dhalbert

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46752>
_______________________________________

From report at bugs.python.org  Wed Feb 16 10:37:49 2022
From: report at bugs.python.org (Isaac Johnson)
Date: Wed, 16 Feb 2022 15:37:49 +0000
Subject: [issue46766] Add a class for file operations so a syntax such as
 open("file.img", File.Write | File.Binary | File.Disk) is possible.
In-Reply-To: <1644987392.44.0.618461662976.issue46766@roundup.psfhosted.org>
Message-ID: <1645025869.8.0.642844324027.issue46766@roundup.psfhosted.org>


Isaac Johnson <isaacsjohnson22 at gmail.com> added the comment:

Well it wouldn't need to be imported. I was working on including it inside builtins like open(). It wouldn't be very convenient if it needed to be imported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46766>
_______________________________________

From report at bugs.python.org  Wed Feb 16 10:42:42 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 16 Feb 2022 15:42:42 +0000
Subject: [issue46541] Replace _Py_IDENTIFIER() with statically initialized
 objects.
In-Reply-To: <1643234464.46.0.949364478641.issue46541@roundup.psfhosted.org>
Message-ID: <1645026162.52.0.386929645717.issue46541@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
pull_requests: +29524
pull_request: https://github.com/python/cpython/pull/31375

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46541>
_______________________________________

From report at bugs.python.org  Wed Feb 16 11:04:42 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 16 Feb 2022 16:04:42 +0000
Subject: [issue46541] Replace _Py_IDENTIFIER() with statically initialized
 objects.
In-Reply-To: <1643234464.46.0.949364478641.issue46541@roundup.psfhosted.org>
Message-ID: <1645027482.34.0.0818645989165.issue46541@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:


New changeset e8a19b092fc0551581e10d6f310dd5feabac7609 by Dong-hee Na in branch 'main':
bpo-46541: Remove usage of _Py_IDENTIFIER from mmap module (GH-31375)
https://github.com/python/cpython/commit/e8a19b092fc0551581e10d6f310dd5feabac7609


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46541>
_______________________________________

From report at bugs.python.org  Wed Feb 16 11:09:44 2022
From: report at bugs.python.org (Tobias Oberstein)
Date: Wed, 16 Feb 2022 16:09:44 +0000
Subject: [issue29992] Expose parse_string in JSONDecoder
In-Reply-To: <1491380525.56.0.628505740968.issue29992@psf.upfronthosting.co.za>
Message-ID: <1645027784.83.0.531657394586.issue29992@roundup.psfhosted.org>


Tobias Oberstein <tobias.oberstein at gmail.com> added the comment:

> It's unlikely that you would want to parse every string that looks enough like a decimal as a decimal, or that you would want to pay the cost of checking every string in the whole document to see if it's a decimal.

fwiw, yes, that's what I do, and yes, it needs to check every string

https://github.com/crossbario/autobahn-python/blob/bc98e4ea5a2a81e41209ea22d9acc53258fb96be/autobahn/wamp/serializer.py#L410

> Returning a decimal as a string is becoming quite common in REST APIs to ensure there is no floating point errors.

exactly. it is simply required if money values are involved.

since JSON doesn't have a native Decimal, strings need to be used (the only scalar type in JSON that allows one to encode the needed arbitrary precision decimals)

CBOR has tagged decimal fraction encoding, as described in RFC7049 section 2.4.3.

fwiw, we've added roundtrip and crosstrip testing between CBOR <=> JSON in our hacked Python JSON, and it works

https://github.com/crossbario/autobahn-python/blob/bc98e4ea5a2a81e41209ea22d9acc53258fb96be/autobahn/wamp/test/test_wamp_serializer.py#L235

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29992>
_______________________________________

From report at bugs.python.org  Wed Feb 16 11:15:42 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 16 Feb 2022 16:15:42 +0000
Subject: [issue46541] Replace _Py_IDENTIFIER() with statically initialized
 objects.
In-Reply-To: <1643234464.46.0.949364478641.issue46541@roundup.psfhosted.org>
Message-ID: <1645028142.3.0.0121844876599.issue46541@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
pull_requests: +29525
pull_request: https://github.com/python/cpython/pull/31376

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46541>
_______________________________________

From report at bugs.python.org  Wed Feb 16 11:29:20 2022
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 16 Feb 2022 16:29:20 +0000
Subject: [issue46768] CVE-201-4160 Vulnerability Is Found in
 Lib/site-packages/cryptography/hazmat/bindings/_openssl.pyd for Cryptography
 Version 3.3.2
Message-ID: <1645028960.1.0.574337713344.issue46768@roundup.psfhosted.org>


New submission from Christian Heimes <lists at cheimes.de>:

The file is from 3rd party package PyCA cryptography and not maintained by us. 3.3.2 is an old version of cryptography and no longer supported. I recommend that you update to cryptography 36.0.1

----------
nosy: +christian.heimes
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46768>
_______________________________________

From report at bugs.python.org  Wed Feb 16 11:48:20 2022
From: report at bugs.python.org (Brandt Bucher)
Date: Wed, 16 Feb 2022 16:48:20 +0000
Subject: [issue46702] Specialize UNPACK_SEQUENCE
In-Reply-To: <1644453353.53.0.226399964433.issue46702@roundup.psfhosted.org>
Message-ID: <1645030100.49.0.156059214831.issue46702@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:


New changeset a9da085015db8cbb81f660158864ac94fe6c67a2 by Brandt Bucher in branch 'main':
bpo-46702: Specialize UNPACK_SEQUENCE (GH-31240)
https://github.com/python/cpython/commit/a9da085015db8cbb81f660158864ac94fe6c67a2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46702>
_______________________________________

From report at bugs.python.org  Wed Feb 16 11:50:02 2022
From: report at bugs.python.org (Brandt Bucher)
Date: Wed, 16 Feb 2022 16:50:02 +0000
Subject: [issue46072] Unify handling of stats in the CPython VM
In-Reply-To: <1639498673.65.0.709719181358.issue46072@roundup.psfhosted.org>
Message-ID: <1645030202.91.0.934577381397.issue46072@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:


New changeset 580cd9ab2992b7df6f4815020b5841e14a5a6977 by Brandt Bucher in branch 'main':
bpo-46072: Add detailed failure stats for BINARY_OP (GH-31289)
https://github.com/python/cpython/commit/580cd9ab2992b7df6f4815020b5841e14a5a6977


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46072>
_______________________________________

From report at bugs.python.org  Wed Feb 16 12:01:18 2022
From: report at bugs.python.org (Alex Waygood)
Date: Wed, 16 Feb 2022 17:01:18 +0000
Subject: [issue46769] Improve documentation for `typing.TypeVar`
Message-ID: <1645030878.3.0.822530505617.issue46769@roundup.psfhosted.org>


New submission from Alex Waygood <Alex.Waygood at Gmail.com>:

There are three variants of `TypeVar`s:

(1) TypeVars that are neither constrained nor bound: `T = TypeVar("T")`
(2) TypeVars that are bound: `U = TypeVar("U", bound=str)`
(3) TypeVars that are constrained: `V = TypeVar("V", str, bytes)`

The third variant is important for annotating certain functions, such as those in the `re` module. However, it has a number of issues (see https://github.com/python/typing/discussions/1080 for further discussion):

(1) It has somewhat surprising semantics in many situations.
(2) It is difficult for type checkers to deal with, leading to a number of bugs in mypy, for example.
(3) Many users (especially people relatively inexperienced with Python typing) reach for constrained TypeVars in situations where using bound TypeVars or the @overload decorator would be more appropriate.

Both PEP 484 and the documentation for the typing module, however:

(1) Give examples for variants (1) and (3), but not for variant (2), which is treated as something of an afterthought.
(2) Do not mention that TypeVars can be bound to a union of types, which is an important point: `T = TypeVar("T", str, bytes)` has different semantics to `T = TypeVar("T", bound=str|bytes)`, and often the latter is more appropriate.

----------
assignee: docs at python
components: Documentation
messages: 413342
nosy: AlexWaygood, Jelle Zijlstra, docs at python, gvanrossum, kj, sobolevn
priority: normal
severity: normal
stage: needs patch
status: open
title: Improve documentation for `typing.TypeVar`
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46769>
_______________________________________

From report at bugs.python.org  Wed Feb 16 12:17:23 2022
From: report at bugs.python.org (Mark Lonnemann)
Date: Wed, 16 Feb 2022 17:17:23 +0000
Subject: [issue46770] ConfigParser(dict_type=) not behaving as expected
Message-ID: <1645031843.76.0.82823546709.issue46770@roundup.psfhosted.org>


New submission from Mark Lonnemann <mlonnemann at msn.com>:

ConfigParser() is not using a custom dictionary class correctly, according to my understanding.  I have duplicate options in a config file that I want to rename uniquely.  The following code does not work.
x = 0
class MultiDict(dict):
    def __setitem__(self, key, value):
        if key == 'textsize':
            global x
            key += str(x)
            x += 1
        dict.__setitem__(self, key, value)

...

config1 = cp.ConfigParser(dict_type=MultiDict)
config1.read('ini_file.ini')

"textsize" is the option named twice in my config file.  When I run the code, I get a DuplicateOptionError for "textsize".  No one seems to know how to solve this, so it could be a bug.  If it's sloppy coding, I apoligize.

----------
components: Extension Modules
messages: 413343
nosy: malonn
priority: normal
severity: normal
status: open
title: ConfigParser(dict_type=) not behaving as expected
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46770>
_______________________________________

From report at bugs.python.org  Wed Feb 16 12:40:11 2022
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 16 Feb 2022 17:40:11 +0000
Subject: [issue46760] test_dis should test the dis module, not everything else
In-Reply-To: <1644934628.87.0.437399260946.issue46760@roundup.psfhosted.org>
Message-ID: <1645033211.12.0.837159038348.issue46760@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
nosy: +brandtbucher, iritkatriel

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46760>
_______________________________________

From report at bugs.python.org  Wed Feb 16 12:53:02 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 16 Feb 2022 17:53:02 +0000
Subject: [issue46752] Introduce task groups to asyncio and change task
 cancellation semantics
In-Reply-To: <1644871469.64.0.38816696304.issue46752@roundup.psfhosted.org>
Message-ID: <1645033982.9.0.993216050351.issue46752@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

@dhalbert, it's probably better to file a new issue if you want changes to gather(). Although I suppose that if we want to deemphasize it, we shouldn't be adding new features to it. My own new feature idea would be to have it wait for all tasks and then if there are any exceptions, raise an ExceptionGroup. That (like any new gather() behaviors) would require a new keyword-only flag to gather(). If we're going to deemphasize it I might not bother though.

There's one thing that gather() does that TaskGroup doesn't: it gives us the return values from the tasks. The question is whether that's useful. If it is maybe we should *not* deepmhasize gather() quite as much and then adding new features would be okay.

----------
nosy:  -dhalbert

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46752>
_______________________________________

From report at bugs.python.org  Wed Feb 16 12:59:12 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 16 Feb 2022 17:59:12 +0000
Subject: [issue46771] Add some form of cancel scopes
Message-ID: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>


New submission from Guido van Rossum <guido at python.org>:

Now that TaskGroup is merged (see bpo-46752) we might consider adding some form of cancel scopes (another Trio idea).

There's a sensible implementation we could use as a starting point in @asvetlov's async-timeout package (https://github.com/aio-libs/async-timeout).

----------
components: asyncio
messages: 413345
nosy: asvetlov, gvanrossum, iritkatriel, njs, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: Add some form of cancel scopes
type: enhancement
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Wed Feb 16 12:59:51 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 16 Feb 2022 17:59:51 +0000
Subject: [issue46752] Introduce task groups to asyncio and change task
 cancellation semantics
In-Reply-To: <1644871469.64.0.38816696304.issue46752@roundup.psfhosted.org>
Message-ID: <1645034391.98.0.376906663453.issue46752@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

I've created a separate issue for cancel scopes: bpo-46771.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46752>
_______________________________________

From report at bugs.python.org  Wed Feb 16 13:00:11 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 16 Feb 2022 18:00:11 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645034411.64.0.469414634053.issue46771@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
keywords: +patch
pull_requests: +29526
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31270

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Wed Feb 16 13:01:54 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 16 Feb 2022 18:01:54 +0000
Subject: [issue46752] Introduce task groups to asyncio and change task
 cancellation semantics
In-Reply-To: <1644871469.64.0.38816696304.issue46752@roundup.psfhosted.org>
Message-ID: <1645034514.56.0.310262733256.issue46752@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
nosy: +dhalbert

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46752>
_______________________________________

From report at bugs.python.org  Wed Feb 16 13:12:48 2022
From: report at bugs.python.org (=?utf-8?q?Tin_Tvrtkovi=C4=87?=)
Date: Wed, 16 Feb 2022 18:12:48 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645035168.46.0.808388594914.issue46771@roundup.psfhosted.org>


Tin Tvrtkovi? <tinchester at gmail.com> added the comment:

I've essentially forked `async-timeout` (a very good library) into Quattro cancel scopes: https://github.com/Tinche/quattro/blob/main/src/quattro/cancelscope.py.

The differences are:
* the API follows Trio, so instead of `timeout` you'd use `fail_after` or `move_on_after`
* instead of `async with timeout`, you use a normal context manager `with fail_after`. The Trio folks think this is important (less suspension points, less race conditions) and I agree
* it's somewhat composable (as much as possible under asyncio), each scope knows if the CancelError is meant for it or should be propagated further. This is implemented by using the CancelError message to carry a nonce. This only works on 3.9+, but here that's not a problem
* small deadline adjustment differences, I use a setter on the deadline instead of `update` and `shift`
* it's fully type annotated, but so is Andrew's

Let me know if this sounds interesting.

----------
nosy: +tinchester

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Wed Feb 16 13:14:17 2022
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 16 Feb 2022 18:14:17 +0000
Subject: [issue46752] Introduce task groups to asyncio and change task
 cancellation semantics
In-Reply-To: <1644871469.64.0.38816696304.issue46752@roundup.psfhosted.org>
Message-ID: <1645035257.77.0.426956287188.issue46752@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> There's one thing that gather() does that TaskGroup doesn't: it gives us the return values from the tasks.

That's easy to do with task groups too:

  async with TaskGroup() as g:
      r1 = g.create_task(coro1())
      r2 = g.create_task(coro2())

  print(r1.result())

  # or
  print(await r2)  # I *think* this should work

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46752>
_______________________________________

From report at bugs.python.org  Wed Feb 16 13:15:59 2022
From: report at bugs.python.org (=?utf-8?q?Tin_Tvrtkovi=C4=87?=)
Date: Wed, 16 Feb 2022 18:15:59 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645035359.98.0.483583097754.issue46771@roundup.psfhosted.org>


Tin Tvrtkovi? <tinchester at gmail.com> added the comment:

Oh, and Trio's `current_effective_deadline` is also in.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Wed Feb 16 13:19:57 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 16 Feb 2022 18:19:57 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645035597.68.0.0554054772283.issue46771@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Sure, we should create the best possible solution.

We have no CI in the stdlib that checks type annotations, so those should probably be moved to a stub file in typeshed. (Ditto for asyncio taskgroups.py.)

Using the new .cancelling()/.uncancel() API added to Task you might be able to avoid hacks using the cancel msg (check how it's used in the new TaskGroup).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Wed Feb 16 13:32:25 2022
From: report at bugs.python.org (Eric Snow)
Date: Wed, 16 Feb 2022 18:32:25 +0000
Subject: [issue46772] Statically Initialize PyArg_Parser in clinic.py
Message-ID: <1645036345.9.0.392519998688.issue46772@roundup.psfhosted.org>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

The code generated by clinic.py is already partially statically initialized.  Currently we init the other fields in Python/getargs.c:parser_init(), which runs the first time we try to use each parser.  AFAICS, that remaining init that could be done statically using the data we have available in clinic.py during code generation.

My primary interest is in static init of PyArg_Parser.kwtuple, which is a tuple containing only strings.

----------
assignee: eric.snow
components: Interpreter Core
messages: 413351
nosy: eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: Statically Initialize PyArg_Parser in clinic.py
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46772>
_______________________________________

From report at bugs.python.org  Wed Feb 16 13:34:50 2022
From: report at bugs.python.org (Eric Snow)
Date: Wed, 16 Feb 2022 18:34:50 +0000
Subject: [issue46773] Add a Private API for Looking Up Global Objects
Message-ID: <1645036490.54.0.531825126178.issue46773@roundup.psfhosted.org>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

We need this to statically initialize PyArg_Parser.kwtuple.  (See bpo-46772.)

For now this will be a "private" API (leading underscore).  Ultimately, we'll want a Public API, so we can eventually stop exposing *any* objects as symbols in the C-API.  However, that will need a PEP.

----------
assignee: eric.snow
components: Interpreter Core
messages: 413352
nosy: eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: Add a Private API for Looking Up Global Objects
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46773>
_______________________________________

From report at bugs.python.org  Wed Feb 16 13:36:54 2022
From: report at bugs.python.org (Eric Snow)
Date: Wed, 16 Feb 2022 18:36:54 +0000
Subject: [issue46772] Statically Initialize PyArg_Parser in clinic.py
In-Reply-To: <1645036345.9.0.392519998688.issue46772@roundup.psfhosted.org>
Message-ID: <1645036614.77.0.764892558316.issue46772@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
dependencies: +Add a Private API for Looking Up Global Objects, Statically allocate and initialize the empty tuple.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46772>
_______________________________________

From report at bugs.python.org  Wed Feb 16 13:37:34 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 16 Feb 2022 18:37:34 +0000
Subject: [issue46752] Introduce task groups to asyncio and change task
 cancellation semantics
In-Reply-To: <1644871469.64.0.38816696304.issue46752@roundup.psfhosted.org>
Message-ID: <1645036654.15.0.0451436064338.issue46752@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

I have a PR up to typeshed to add the new Task methods and a new stub file taskgroups.pyi: https://github.com/python/typeshed/pull/7240

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46752>
_______________________________________

From report at bugs.python.org  Wed Feb 16 13:38:38 2022
From: report at bugs.python.org (Batuhan Taskaya)
Date: Wed, 16 Feb 2022 18:38:38 +0000
Subject: [issue29418] inspect.isroutine does not return True for some bound
 builtin methods
In-Reply-To: <1486027973.42.0.383629669841.issue29418@psf.upfronthosting.co.za>
Message-ID: <1645036718.63.0.126216142504.issue29418@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/issue29418>
_______________________________________

From report at bugs.python.org  Wed Feb 16 13:56:12 2022
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Wed, 16 Feb 2022 18:56:12 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645037772.47.0.0665722279351.issue46771@roundup.psfhosted.org>


Alex Gr?nholm <alex.gronholm at nextday.fi> added the comment:

A brief explanation of cancel scopes for the uninitiated: A cancel scope can enclose just a part of a coroutine function, or an entire group of tasks. They can be nested within each other (by using them as context managers), and marked as shielded from cancellation, which means cancellation won't be propagated (i.e. raised in the coroutine function) from a cancelled outer scope until either the inner scope's shielding is disabled or the inner scope is exited or cancelled directly.

The fundamental problem in implementing these on top of asyncio is that native task cancellation can throw a wrench in these gears. Since a cancel scope works by catching a cancellation error and then (potentially) allowing the coroutine to proceed, it would have to know, when catching a cancellation error, if the cancellation error was targeted at a cancel scope or the task itself. A workaround for this, made possible in Python 3.9, is to (ab)use cancellation messages to include the ID of the target cancel scope. This only solves half of the problem, however. If the task is already pending a cancellation targeted at a cancel scope, the task itself cannot be cancelled anymore since calling cancel() again on the task is a no-op. This would be solved by updating the cancel message on the second call. The docs don't say anything about the behavior on the second call, so it's not strictly speaking a change in documented behavior.

Then, on the subject of level cancellation: level cancellation builds upon cancel scopes and changes cancellation behavior so that whenever a task yields while a cancelled cancel scope is in effect, it gets hit with a CancelledError every time, as opposed to just once in asyncio's "edge" style cancellation. Another very important difference is that with level cancellation, even a task that starts within a cancelled scope gets to run up until the first yield point. This gives it an opportunity to clean up any resources it was given ownership of (a connected socket in a socket server is a common, practical example of this).

This is what the asyncio documentation states about Task.cancel():

"This arranges for a CancelledError exception to be thrown into the wrapped coroutine on the next cycle of the event loop.

The coroutine then has a chance to clean up or even deny the request by suppressing the exception with a try ? ? except CancelledError ? finally block. Therefore, unlike Future.cancel(), Task.cancel() does not guarantee that the Task will be cancelled, although suppressing cancellation completely is not common and is actively discouraged."

This is, however, only true for a task that has started running. A Task that gets cancelled before even entering the coroutine is silently dropped.

As asyncio does not allow for custom task instances without overriding the entire task factory, it leaves libraries like AnyIO some less desirable options for implementing level cancellation:

1. Implementing a parallel task system using low level synchronous callbacks (con: such tasks won't show up in asyncio.all_tasks() or work with third party debugging tools)
2. Adding callbacks to continuously cancel tasks that yield inside a cancelled scope (con: ugly; potentially extra overhead?)
3. Adding a wrapper for the task that acts as a "controller" (con: adds an extra visible stack frame, messes with the default task name)

Having low level machinery for injecting a custom Task instance to the event loop would probably solve this problem.

----------
nosy: +alex.gronholm -tinchester

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Wed Feb 16 14:17:25 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 16 Feb 2022 19:17:25 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645039045.19.0.452887084443.issue46771@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
nosy: +tinchester

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Wed Feb 16 14:26:45 2022
From: report at bugs.python.org (Eric Snow)
Date: Wed, 16 Feb 2022 19:26:45 +0000
Subject: [issue46541] Replace _Py_IDENTIFIER() with statically initialized
 objects.
In-Reply-To: <1643234464.46.0.949364478641.issue46541@roundup.psfhosted.org>
Message-ID: <1645039605.75.0.925390720755.issue46541@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

(from https://github.com/python/cpython/pull/31376#issuecomment-1041836106)

[corona10]
> Should we create the separate bpo issue if module changes are too noisy?

I think it's fine to use the one issue.  There are only 26 modules with `NEEDS_PY_IDENTIFIER` and none have much risk with the change.  So it's unlikely that we'll get any discussion about any specific module.  If we do, we can easily create an issue then for the module in question.  If one of the modules had many uses of `_Py_IDENTIFIER()` then it might make sense to split it out, but IIRC none of them have very many.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46541>
_______________________________________

From report at bugs.python.org  Wed Feb 16 14:36:37 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 16 Feb 2022 19:36:37 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645040197.39.0.407285605311.issue46771@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Alex, the goal here is not to replicate every Trio feature or behavior. For example I don't think that asyncio is likely to get level cancellation in 3.11, but we can certainly see if we can do something about some of the edge cases you mention, like the case of a task that is cancelled before it has started running, where you say that the task should be allowed to run until its first await.

It would be nice to have a native asyncio example that demonstrates this, so we have a concrete goal.

I am thinking it is something like this:

async def send_from_open_file(f, s):
    data = f.read()
    f.close()
    await s.send(data)

async def send_filename(filename, s):
    f = open(filename)
    t = asyncio.create_task(send_from_open_file(f, s))
    t.cancel()
    await asyncio.sleep(1)

This is an interesting edge case and I can see why you'd rather see this run until the `await s.send(data)` line. The question is, can we do that without breaking other promises implicit or explicit? (Just because the docs don't mention some behavior that doesn't mean we can change it. We have to consider what happens to actual real world code.)

I don't even know if this would be easy to change if we decided it was a good change. Thoughts? (Possibly this discussion belongs in a new issue, since it's not directly related to adding cancel scopes.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Wed Feb 16 15:05:47 2022
From: report at bugs.python.org (Joshua Bronson)
Date: Wed, 16 Feb 2022 20:05:47 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645041947.1.0.128348312403.issue46771@roundup.psfhosted.org>


Change by Joshua Bronson <jabronson at gmail.com>:


----------
nosy: +jab

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Wed Feb 16 15:32:14 2022
From: report at bugs.python.org (=?utf-8?q?Hakan_=C3=87elik?=)
Date: Wed, 16 Feb 2022 20:32:14 +0000
Subject: [issue29418] inspect.isroutine does not return True for some bound
 builtin methods
In-Reply-To: <1486027973.42.0.383629669841.issue29418@psf.upfronthosting.co.za>
Message-ID: <1645043534.65.0.620689070015.issue29418@roundup.psfhosted.org>


Change by Hakan ?elik <hakancelik96 at outlook.com>:


----------
pull_requests: +29527
pull_request: https://github.com/python/cpython/pull/31377

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29418>
_______________________________________

From report at bugs.python.org  Wed Feb 16 16:07:07 2022
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 16 Feb 2022 21:07:07 +0000
Subject: [issue46766] Add a class for file operations so a syntax such as
 open("file.img", File.Write | File.Binary | File.Disk) is possible.
In-Reply-To: <1645025869.8.0.642844324027.issue46766@roundup.psfhosted.org>
Message-ID: <20220216210524.GZ12540@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

True, but you did say it would be with the io module in your original suggestion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46766>
_______________________________________

From report at bugs.python.org  Wed Feb 16 16:07:29 2022
From: report at bugs.python.org (Jacob Nilsson)
Date: Wed, 16 Feb 2022 21:07:29 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645045649.09.0.94650240614.issue46771@roundup.psfhosted.org>


Change by Jacob Nilsson <jacob.nilsson at ltu.se>:


----------
nosy: +ajoino

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Wed Feb 16 16:10:57 2022
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Wed, 16 Feb 2022 21:10:57 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645045857.43.0.37310327873.issue46771@roundup.psfhosted.org>


Alex Gr?nholm <alex.gronholm at nextday.fi> added the comment:

I'm not trying to argue that asyncio should be changed to have level cancellation or even cancel scopes as built-in (at this point), but expanding the low level API to make implementing these features possible in third party libraries without the awkward hacks we have now.

As for async-timeout, it suffers from the same problem as AnyIO and Quattro: that cancellations of the entire task can be inadvertently swallowed by the async context manager in edge cases. I hadn't even thought of the possibility of this happening until one of AnyIO's users reported just such a problem: https://github.com/agronholm/anyio/issues/374

I just couldn't think of any way to correctly support such things without at least _some_ changes to the task cancellation behavior, and allowing .cancel() to update the cancel message seemed like the least invasive option. I'm all ears if someone has a better solution.

----------
nosy:  -ajoino

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Wed Feb 16 16:14:11 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 16 Feb 2022 21:14:11 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645046051.32.0.18724499623.issue46771@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

OK.

1. Please have a look at how .cancelling()/.uncancel() works (there's an example of it in TaskGroup) to solve that particular problem without using the cancel message.

2. Suppose you could make (backwards compatible) changes to asyncio. What would you do? 3.11 feature freeze (aka beta 1) is still a few months away (late May) so now's the time to get your wishes in.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Wed Feb 16 16:20:24 2022
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Wed, 16 Feb 2022 21:20:24 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645046424.81.0.328602558044.issue46771@roundup.psfhosted.org>


Alex Gr?nholm <alex.gronholm at nextday.fi> added the comment:

Thanks, I will take a look at .uncancel() and .cancelling(). I saw that work happening in my email feed but couldn't figure out right away how it helped, but I will definitely look into the new TaskGroup code to see how it's used there and will get back to you after that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Wed Feb 16 16:22:01 2022
From: report at bugs.python.org (Irit Katriel)
Date: Wed, 16 Feb 2022 21:22:01 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645046521.81.0.0903010274685.issue46771@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at gmail.com>:


----------
nosy: +ajoino

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Wed Feb 16 16:27:54 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 16 Feb 2022 21:27:54 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645046874.52.0.651966010396.issue46771@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Oh, wait. The new Task.cancelling() API helps tell the difference between the *parent* task being cancelled "from outside" vs. the task group itself cancelling the parent task so as to break out of an await like the following:

async with TaskGroup() as g:
    g.create_task(...)
    await <something>

when the await is cancelled, __aexit__() is called with a CancelledError, and we need to tell whether it was cancelled from the outside or by the completion callback on one of the tasks managed by the task group.

The EdgeDB TaskGroup monkey-patched the parent task's cancel() method, and the new asyncio.TaskGroup instead checks parent.cancelled().

However, AFAICT when *any* of the task managed by the TaskGroup exits with CancelledError, this is *ignored* (in both the EdgeDB version and in asyncio.TaskGroup). The assumption here seems to be that the only reason a managed task raises CancelledError is because it was cancelled by the TaskGroup.

A fix for that would be to separately keep track (maybe in a separate weak dict, or some other data structure -- maybe a flag on the task itself?) of which tasks are successfully cancelled by the TaskGroup. We can then treat a CancelledError bubbling out of a managed task that we *didn't* cancel as any other exception, causing it to abort the task group (i.e., cancel all other tasks).

Is that what you are looking for? (But I think this could be solved even in 3.9 without resorting to cancel messages.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Wed Feb 16 16:53:18 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 16 Feb 2022 21:53:18 +0000
Subject: [issue46769] Improve documentation for `typing.TypeVar`
In-Reply-To: <1645030878.3.0.822530505617.issue46769@roundup.psfhosted.org>
Message-ID: <1645048398.88.0.626594595692.issue46769@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Maybe historically constrained type vars predated bound type vars. This could have influenced the way PEP 484 was written and then the docs were derived from the PEP.

But yes, this should be fixed in as many places as possible (including the mypy docs, probably).

I would even support a minor update to PEP 484 to help people find the right way (the PEP is still widely cited). It would have to be just be a textual change, not a spec change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46769>
_______________________________________

From report at bugs.python.org  Wed Feb 16 17:04:34 2022
From: report at bugs.python.org (Martin Panter)
Date: Wed, 16 Feb 2022 22:04:34 +0000
Subject: [issue46756] Incorrect authorization check in urllib.request
In-Reply-To: <1644918487.72.0.244898503691.issue46756@roundup.psfhosted.org>
Message-ID: <1645049074.33.0.705209331464.issue46756@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

Maybe the same as Issue 42766?

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46756>
_______________________________________

From report at bugs.python.org  Wed Feb 16 17:58:31 2022
From: report at bugs.python.org (Shivaram Lingamneni)
Date: Wed, 16 Feb 2022 22:58:31 +0000
Subject: [issue46750] some code paths in ssl and _socket still import idna
 unconditionally
In-Reply-To: <1644854115.6.0.132786473021.issue46750@roundup.psfhosted.org>
Message-ID: <1645052311.07.0.510066593594.issue46750@roundup.psfhosted.org>


Shivaram Lingamneni <slingamn at cs.stanford.edu> added the comment:

I wanted to check in about the status of this patch. Here's the case for the patch, as I understand it:

1. It is not a novel optimization, it just consistently applies design decisions that were made previously (RFE #1472176 and bpo-22127).
2. The performance impact of the initial import of encodings.idna and its transitive dependencies is in fact macroscopic relative to the baseline costs of the interpreter: 5 milliseconds to import the modules and 500 KB in increased RSS, relative to baselines of approximately 50 milliseconds to set up and tear down an interpreter and 10 MB in RSS.

Here are the relevant benchmarks, first for time:


```python
import time
start = time.time()
'a'.encode('idna')
print(time.time() - start)
```

and for memory:

```python
import os
def rss():
    os.system('grep VmRSS /proc/' + str(os.getpid()) + '/status')
rss()
'a'.encode('idna')
rss()
```

Are there potential changes to this patch that would mitigate your concerns?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46750>
_______________________________________

From report at bugs.python.org  Wed Feb 16 18:05:33 2022
From: report at bugs.python.org (=?utf-8?q?Tin_Tvrtkovi=C4=87?=)
Date: Wed, 16 Feb 2022 23:05:33 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645052733.03.0.349779492622.issue46771@roundup.psfhosted.org>


Tin Tvrtkovi? <tinchester at gmail.com> added the comment:

The use of the cancel message is a hack, yeah. But it's what I had to work with. We could introduce a new, proper cancellation context to Tasks instead, which could be attached to the CancelError when it's raised.

On the topic of multiple cancellations being applied to a task before it gets to run: could we just treat the cancellation context as a stack, and when the task gets to run, we throw them all in, one by one? Other options would involve somehow figuring out what the highest priority cancellation context is, or combining all the cancellation contexts into the CancelError somehow.

On the topic of a task getting to run at least once before being cancelled: sure, I guess. I've personally never needed this but I can see how it'd be useful. Either have a flag on the Task instance or build that logic into the cancellation context handling?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Wed Feb 16 18:23:00 2022
From: report at bugs.python.org (=?utf-8?q?Tin_Tvrtkovi=C4=87?=)
Date: Wed, 16 Feb 2022 23:23:00 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645053780.59.0.776102172661.issue46771@roundup.psfhosted.org>


Tin Tvrtkovi? <tinchester at gmail.com> added the comment:

On the topic of TaskGroups needing to know whether to swallow a child CancelledError or no: just use the same nonce/cancellation context trick?

I remember asking Nathaniel about why in Trio nurseries and cancel scopes were linked (nurseries contain a cancel scope there), whereas in Quattro they are completely separate, and not really understanding the answer. I think I'm getting it now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Wed Feb 16 18:27:41 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 16 Feb 2022 23:27:41 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645054061.49.0.744485018769.issue46771@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

I hesitate to add yet another stack at this fundamental level.

The Task.cancel() method returns a bool which indicates whether any state changed.

When multiple cancellations happen concurrently, all but the first will return False, and anything that would like to cancel a task but finds that t.cancel() returns False can know that the task was either already cancelled or has already terminated. (To tell the difference, check t.done() first.)

What would be the use case of wanting to cancel multiple times and having each cancellation be delivered separately?

I know of one use case, where a task somehow decides to catch and *ignore* CancelledError (this should not be done lightly but it is supported -- like shielding in Trio). An impatient user or task manager might want to cancel such a thread a second time. This is what .uncancel() is for -- the thread must call .uncancel() to signal that it has truly ignored the cancellation (as opposed to being busy with cleanup that it deems uncancellable).

But in this case the second cancellation (if it is to have any effect) should be delivered *after* .uncancel() is called.

Your proposal of a cancel context or stack seems to be suggesting that there's a use case for mutliple *concurrent* cancellations. But I find it difficult to imagine such a use case, so I need your help.

Even if we ignore the stack idea, could you provide some code showing how the cancel context would be used? I just learn better from code examples.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Wed Feb 16 18:42:20 2022
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 16 Feb 2022 23:42:20 +0000
Subject: [issue43275] [venv] Add a `.gitignore` file with content `*` in the
 root folder generated by venv module
In-Reply-To: <1613827043.02.0.761895659665.issue43275@roundup.psfhosted.org>
Message-ID: <1645054940.57.0.990421319783.issue43275@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
superseder:  -> [venv] Adding a .gitignore file to virtual environments

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43275>
_______________________________________

From report at bugs.python.org  Wed Feb 16 18:46:36 2022
From: report at bugs.python.org (=?utf-8?q?Tin_Tvrtkovi=C4=87?=)
Date: Wed, 16 Feb 2022 23:46:36 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645055196.48.0.0111042707009.issue46771@roundup.psfhosted.org>


Tin Tvrtkovi? <tinchester at gmail.com> added the comment:

Ok, first the happy path. We have a task running this:

async def a():
    with move_on_after(5):
        await a_long_op()
    await something_else()

`move_on_after` has scheduled a callback to run that calls `parent_task.cancel(msg=1)` 5 seconds after it was executed.

So now 5 seconds pass, the callback cancels the task, and `move_on_after` catches the CancelledError, sees the msg == 1, and swallows it. `something_else()` now runs. All good.


Sad path. Same scenario, except the event loop is kinda busy since we're running in production. Turns out this task was spawned by a web server, and there's a 5 second timeout (or the client disconnected, or something else). So now we have 2 callbacks that want to cancel this task: the one from `move_on_after` and the one from the web server.

The one from the web server is more important, since it's a higher level cancellation. But the callback from `move_on_after` runs first, and marks the task for cancellation, and sets the message to 1. Then, before the task gets to run, the webserver also cancels the task. But that does nothing: https://github.com/python/cpython/blob/6f1efd19a70839d480e4b1fcd9fecd3a8725824b/Lib/asyncio/tasks.py#L206.

So now the task actually gets to run, `move_on_after` swallows the CancelledError, and something_else() gets to run. But ideally, it shouldn't.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Wed Feb 16 19:10:50 2022
From: report at bugs.python.org (Ned Deily)
Date: Thu, 17 Feb 2022 00:10:50 +0000
Subject: [issue46755] QueueHandler logs stack_info twice
In-Reply-To: <1644914215.76.0.40425567068.issue46755@roundup.psfhosted.org>
Message-ID: <1645056650.3.0.880426805604.issue46755@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46755>
_______________________________________

From report at bugs.python.org  Wed Feb 16 19:18:03 2022
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Thu, 17 Feb 2022 00:18:03 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645057083.88.0.499394918378.issue46771@roundup.psfhosted.org>


Alex Gr?nholm <alex.gronholm at nextday.fi> added the comment:

I just tried to write a snippet to demonstrate the issue in TaskGroup, but that doesn't seem possible since TaskGroup never swallows a CancelledError. It always raises/propagates _some_ exception out of __aexit__() unless of course all the child tasks run to completion successfully.

I was also surprised to notice that TaskGroup doesn't have a .cancel() method, so in cases where one would launch multiple tasks and cancel the rest when one succeeds, one would have to store all the child tasks separately and then iterate over them and cancel one by one. The Happy Eyeballs algorithm is one such use case (also used in AnyIO this way).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Wed Feb 16 19:30:49 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 17 Feb 2022 00:30:49 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645057849.1.0.373268367055.issue46771@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

@Tin The sad path is just a race, right? If the web server had disconnected just a tad later, __aexit__() would already have returned and await something_else() would already be running. So you can't make any promises if you write your code that way anyway.

@Alex For "happy eyeballs" you could also raise an exception or cancel the parent task once you've saved the winning result somewhere. Maybe you could show example code written using different paradigms so we can compare.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Wed Feb 16 19:41:38 2022
From: report at bugs.python.org (=?utf-8?q?Tin_Tvrtkovi=C4=87?=)
Date: Thu, 17 Feb 2022 00:41:38 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645058498.31.0.834186224377.issue46771@roundup.psfhosted.org>


Tin Tvrtkovi? <tinchester at gmail.com> added the comment:

@Guido Imagine something_else() takes a long time and a lot of server resources (like a heavy query). If the web server disconnected a tad later and avoided the race condition, the task would have gotten cancelled very soon after the start of something_else() and stopped running it. But since the race did happen, the query avoids cancellation (potentially ~forever).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Wed Feb 16 20:05:51 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 17 Feb 2022 01:05:51 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645059951.74.0.525920522598.issue46771@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Hm, I see. So the problem is that in the interval between move_on's calls to t.cancel() and t.uncancel(), if the web server calls t.cancel() that will just return False. So the web server would have to implement some other mechanism for cancelling operations.

That's indeed unfortunate. Maybe we  should just roll back that aspect of the TaskGroup PR -- in particular, remove these two lines:

        if self._cancel_requested:
            return False

from Task.cancel(). These lines don't matter for TaskGroup (it works without them), and they weren't there before yesterday, so the fallout would be very localized.

@asvetlov What do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Wed Feb 16 20:12:34 2022
From: report at bugs.python.org (Isaac Johnson)
Date: Thu, 17 Feb 2022 01:12:34 +0000
Subject: [issue46766] Add a class for file operations so a syntax such as
 open("file.img", File.Write | File.Binary | File.Disk) is possible.
In-Reply-To: <1644987392.44.0.618461662976.issue46766@roundup.psfhosted.org>
Message-ID: <1645060354.82.0.817423387555.issue46766@roundup.psfhosted.org>


Isaac Johnson <isaacsjohnson22 at gmail.com> added the comment:

Well that is how it works with open. It is implemented in the io module and  added to builtins.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46766>
_______________________________________

From report at bugs.python.org  Wed Feb 16 20:29:04 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 17 Feb 2022 01:29:04 +0000
Subject: [issue46541] Replace _Py_IDENTIFIER() with statically initialized
 objects.
In-Reply-To: <1643234464.46.0.949364478641.issue46541@roundup.psfhosted.org>
Message-ID: <1645061344.9.0.799798466658.issue46541@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:

> I think it's fine to use the one issue.

Great! and thank you for all your efforts :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46541>
_______________________________________

From report at bugs.python.org  Wed Feb 16 20:36:31 2022
From: report at bugs.python.org (Jason Wilkes)
Date: Thu, 17 Feb 2022 01:36:31 +0000
Subject: [issue46541] Replace _Py_IDENTIFIER() with statically initialized
 objects.
In-Reply-To: <1643234464.46.0.949364478641.issue46541@roundup.psfhosted.org>
Message-ID: <1645061791.47.0.875704653643.issue46541@roundup.psfhosted.org>


Change by Jason Wilkes <notarealdeveloper at gmail.com>:


----------
nosy: +notarealdeveloper
nosy_count: 7.0 -> 8.0
pull_requests: +29528
pull_request: https://github.com/python/cpython/pull/30310

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46541>
_______________________________________

From report at bugs.python.org  Wed Feb 16 20:41:35 2022
From: report at bugs.python.org (Kevin Kirsche)
Date: Thu, 17 Feb 2022 01:41:35 +0000
Subject: [issue46774] Importlib.metadata.version picks first distribution not
 latest
Message-ID: <1645062095.18.0.489026763345.issue46774@roundup.psfhosted.org>


New submission from Kevin Kirsche <Kev.Kirsche+GitHub at gmail.com>:

When using importlib.metadata.version with tools such as poetry which may install the current package one or more times, importlib.metadata.version is not deterministic in returning the latest version of the package, instead returning the first one located.

As it's unclear if this behavior is desired by importlib, I'm creating this issue to determine if this is intentional behavior or a bug.

I have opened the following poetry issue:
* https://github.com/python-poetry/poetry/issues/5204

I have also created the following reproduction repository for the installation issue:
https://github.com/kkirsche/poetry-remove-untracked

When the after is modified to return the version, it returns the first one found (e.g. if you go 3.0.0 -> 3.0.1 -> 3.0.2, each would be installed and the library would return 3.0.0 to the caller)

Thank you for your time and consideration. I apologize if this is not something that requires action by the Python team.

I'd be open to trying to submit a PR, but want to verify whether this is intentional or not.

----------
components: Library (Lib)
messages: 413375
nosy: kkirsche2
priority: normal
severity: normal
status: open
title: Importlib.metadata.version picks first distribution not latest
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46774>
_______________________________________

From report at bugs.python.org  Wed Feb 16 20:42:11 2022
From: report at bugs.python.org (Kevin Kirsche)
Date: Thu, 17 Feb 2022 01:42:11 +0000
Subject: [issue46774] Importlib.metadata.version picks first distribution not
 latest
In-Reply-To: <1645062095.18.0.489026763345.issue46774@roundup.psfhosted.org>
Message-ID: <1645062131.16.0.408852399528.issue46774@roundup.psfhosted.org>


Change by Kevin Kirsche <Kev.Kirsche+GitHub at gmail.com>:


----------
nosy: +kkirsche

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46774>
_______________________________________

From report at bugs.python.org  Wed Feb 16 20:44:16 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 17 Feb 2022 01:44:16 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645062256.86.0.101988894746.issue46771@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

FWIW it looks like this part of taskgroups is vulnerable to a similar race:

https://github.com/python/cpython/blob/6f1efd19a70839d480e4b1fcd9fecd3a8725824b/Lib/asyncio/taskgroups.py#L212-L232

Deleting the two lines I mentioned won't fix it here; a hack using the cancel message might be more appropriate. (I note that there is no documented way to retrieve the cancel message; you're supposed to access the protected `_cancel_message` attribute, apparently. Looks like we forgot something there.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Wed Feb 16 20:49:37 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 17 Feb 2022 01:49:37 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645062577.92.0.955385064866.issue46771@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

> (I note that there is no documented way to retrieve the cancel message; you're supposed to access the protected `_cancel_message` attribute, apparently. Looks like we forgot something there.)

Oh, it's passed to the CancelledError() constructor. But that's not documented either (I had to find the original issue that introduced this to figure it out -- bpo-31033).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Wed Feb 16 21:41:39 2022
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 17 Feb 2022 02:41:39 +0000
Subject: [issue29992] Expose parse_string in JSONDecoder
In-Reply-To: <1491380525.56.0.628505740968.issue29992@psf.upfronthosting.co.za>
Message-ID: <1645065699.0.0.905664530959.issue29992@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

> Generally speaking, parsing some things as decimal or datetime are schema dependent.

Totally agree with this.

> In order to provide maximal flexibility it would be much nicer to have a streaming interface available (like SAX for XML parsing), but that is not what this is.

I think it is too difficult and complicated.
I think post-processing approach (e.g. dataclass_json, pydantic) is enough.

----------
nosy: +methane

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29992>
_______________________________________

From report at bugs.python.org  Wed Feb 16 22:26:17 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Thu, 17 Feb 2022 03:26:17 +0000
Subject: [issue46066] Deprecate keyword args syntax for TypedDict definition
In-Reply-To: <1639409817.42.0.21314101687.issue46066@roundup.psfhosted.org>
Message-ID: <1645068377.75.0.624808309442.issue46066@roundup.psfhosted.org>


Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:


New changeset de6043e596492201cc1a1eb28038970bb69f3107 by 97littleleaf11 in branch 'main':
bpo-46066: Deprecate kwargs syntax for TypedDict definitions (GH-31126)
https://github.com/python/cpython/commit/de6043e596492201cc1a1eb28038970bb69f3107


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46066>
_______________________________________

From report at bugs.python.org  Wed Feb 16 22:26:40 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Thu, 17 Feb 2022 03:26:40 +0000
Subject: [issue46066] Deprecate keyword args syntax for TypedDict definition
In-Reply-To: <1639409817.42.0.21314101687.issue46066@roundup.psfhosted.org>
Message-ID: <1645068400.8.0.600013288365.issue46066@roundup.psfhosted.org>


Change by Jelle Zijlstra <jelle.zijlstra at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46066>
_______________________________________

From report at bugs.python.org  Wed Feb 16 22:28:29 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Thu, 17 Feb 2022 03:28:29 +0000
Subject: [issue46333] ForwardRef.__eq__ does not respect module parameter
In-Reply-To: <1641828029.13.0.319383260427.issue46333@roundup.psfhosted.org>
Message-ID: <1645068509.19.0.0913467437655.issue46333@roundup.psfhosted.org>


Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:


New changeset 6e7b813195f9bd6a2a15c1f00ef2c0180f6c751a by aha79 in branch 'main':
bpo-46333: Honor `module` parameter in ForwardRef (GH-30536)
https://github.com/python/cpython/commit/6e7b813195f9bd6a2a15c1f00ef2c0180f6c751a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46333>
_______________________________________

From report at bugs.python.org  Wed Feb 16 22:28:42 2022
From: report at bugs.python.org (miss-islington)
Date: Thu, 17 Feb 2022 03:28:42 +0000
Subject: [issue46333] ForwardRef.__eq__ does not respect module parameter
In-Reply-To: <1641828029.13.0.319383260427.issue46333@roundup.psfhosted.org>
Message-ID: <1645068522.87.0.672982258583.issue46333@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 8.0 -> 9.0
pull_requests: +29529
pull_request: https://github.com/python/cpython/pull/31379

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46333>
_______________________________________

From report at bugs.python.org  Wed Feb 16 22:28:47 2022
From: report at bugs.python.org (miss-islington)
Date: Thu, 17 Feb 2022 03:28:47 +0000
Subject: [issue46333] ForwardRef.__eq__ does not respect module parameter
In-Reply-To: <1641828029.13.0.319383260427.issue46333@roundup.psfhosted.org>
Message-ID: <1645068527.84.0.391596756652.issue46333@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29530
pull_request: https://github.com/python/cpython/pull/31380

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46333>
_______________________________________

From report at bugs.python.org  Wed Feb 16 22:53:11 2022
From: report at bugs.python.org (miss-islington)
Date: Thu, 17 Feb 2022 03:53:11 +0000
Subject: [issue46333] ForwardRef.__eq__ does not respect module parameter
In-Reply-To: <1641828029.13.0.319383260427.issue46333@roundup.psfhosted.org>
Message-ID: <1645069991.87.0.727550838025.issue46333@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a17d59a6df146077b5420b36c35a1b82ab3f071a by Miss Islington (bot) in branch '3.10':
[3.10] bpo-46333: Honor `module` parameter in ForwardRef (GH-30536) (GH-31379)
https://github.com/python/cpython/commit/a17d59a6df146077b5420b36c35a1b82ab3f071a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46333>
_______________________________________

From report at bugs.python.org  Wed Feb 16 22:53:34 2022
From: report at bugs.python.org (miss-islington)
Date: Thu, 17 Feb 2022 03:53:34 +0000
Subject: [issue46333] ForwardRef.__eq__ does not respect module parameter
In-Reply-To: <1641828029.13.0.319383260427.issue46333@roundup.psfhosted.org>
Message-ID: <1645070014.77.0.332781088025.issue46333@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 29ae7d3996e073ec3f15c4e7486b17c1d0e3c8f5 by Miss Islington (bot) in branch '3.9':
bpo-46333: Honor `module` parameter in ForwardRef (GH-30536)
https://github.com/python/cpython/commit/29ae7d3996e073ec3f15c4e7486b17c1d0e3c8f5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46333>
_______________________________________

From report at bugs.python.org  Wed Feb 16 22:54:21 2022
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 17 Feb 2022 03:54:21 +0000
Subject: [issue46775] [Windows] OSError should unconditionally call
 winerror_to_errno
Message-ID: <1645070061.53.0.530684552502.issue46775@roundup.psfhosted.org>


New submission from Eryk Sun <eryksun at gmail.com>:

bpo-37705 overlooked fixing the OSError constructor. oserror_parse_args() in Objects/exceptions.c should unconditionally call winerror_to_errno(), which is defined in PC/errmap.h. 

winerror_to_errno() maps the Winsock range 10000-11999 directly, except for the 6 errors in this range that are based on C errno values: WSAEINTR, WSAEBADF, WSAEACCES, WSAEFAULT, WSAEINVAL, and WSAEMFILE. Otherwise, Windows error codes that aren't mapped explicitly get mapped by default to EINVAL.

----------
components: Interpreter Core, Windows
keywords: easy (C)
messages: 413383
nosy: eryksun, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: [Windows] OSError should unconditionally call winerror_to_errno
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46775>
_______________________________________

From report at bugs.python.org  Wed Feb 16 22:55:35 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Thu, 17 Feb 2022 03:55:35 +0000
Subject: [issue46333] ForwardRef.__eq__ does not respect module parameter
In-Reply-To: <1641828029.13.0.319383260427.issue46333@roundup.psfhosted.org>
Message-ID: <1645070135.68.0.299763335513.issue46333@roundup.psfhosted.org>


Change by Jelle Zijlstra <jelle.zijlstra at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46333>
_______________________________________

From report at bugs.python.org  Wed Feb 16 23:02:26 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 17 Feb 2022 04:02:26 +0000
Subject: [issue46541] Replace _Py_IDENTIFIER() with statically initialized
 objects.
In-Reply-To: <1643234464.46.0.949364478641.issue46541@roundup.psfhosted.org>
Message-ID: <1645070546.35.0.823363770376.issue46541@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:


New changeset 8cb5f707a841832aeac4b01c8b6a0e72dced52ae by Dong-hee Na in branch 'main':
bpo-46541: Remove usage of _Py_IDENTIFIER from array module (GH-31376)
https://github.com/python/cpython/commit/8cb5f707a841832aeac4b01c8b6a0e72dced52ae


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46541>
_______________________________________

From report at bugs.python.org  Wed Feb 16 23:37:03 2022
From: report at bugs.python.org (Christoph Reiter)
Date: Thu, 17 Feb 2022 04:37:03 +0000
Subject: [issue46541] Replace _Py_IDENTIFIER() with statically initialized
 objects.
In-Reply-To: <1643234464.46.0.949364478641.issue46541@roundup.psfhosted.org>
Message-ID: <1645072623.96.0.800789716459.issue46541@roundup.psfhosted.org>


Change by Christoph Reiter <reiter.christoph at gmail.com>:


----------
nosy:  -lazka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46541>
_______________________________________

From report at bugs.python.org  Wed Feb 16 23:52:54 2022
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 17 Feb 2022 04:52:54 +0000
Subject: [issue46763] os.path.samefile incorrect results for shadow copies
In-Reply-To: <1644975913.58.0.577499491465.issue46763@roundup.psfhosted.org>
Message-ID: <1645073574.78.0.275164761848.issue46763@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

Sample implementation:

    import os
    import msvcrt
    import win32file 

    def samefile(f1, f2):
        """Test whether two paths refer to the same file or directory."""
        s1 = os.stat(f1)
        s2 = os.stat(f2)
        return _common_same_file(f1, f2, s1, s2)


    def sameopenfile(fd1, fd2):
        """Test whether two file descriptors refer to the same file."""
        s1 = os.fstat(fd1)
        s2 = os.fstat(fd2)
        return _common_same_file(fd1, fd2, s1, s2)


    def _common_same_file(f1, f2, s1, s2):
        if s1.st_ino != s2.st_ino or s1.st_dev != s2.st_dev:
            return False

        # (st_dev, st_ino) may be insufficient on its own. Use the final
        # NT path of each file to refine the comparison.
        p = _get_final_nt_paths([f1, f2])
        
        # The stat result is unreliable if the volume serial number (st_dev)
        # or file ID (st_ino) is 0.
        if 0 in (s1.st_dev, s1.st_ino):
            if None in p:
                return False
            return p[0] == p[1]

        # A volume shadow copy has the same volume serial number as the
        # base volume. In this case, the device names have to be compared.
        d = _get_device_names(p)
        if any('volumeshadowcopy' in n for n in d if n):
            return d[0] == d[1]

        return True


    def _get_final_nt_paths(files):
        result = []
        nt_normal = 0x2 # VOLUME_NAME_NT | FILE_NAME_NORMALIZED
        nt_opened = 0xA # VOLUME_NAME_NT | FILE_NAME_OPENED
        for f in files:
            p = None
            if f is not None:
                try:
                    p = _getfinalpathname(f, nt_normal)
                except OSError:
                    try:
                        p = _getfinalpathname(f, nt_opened)
                    except OSError:
                        pass
            result.append(p)
        return result


    def _get_device_names(paths):
        # Look for "\Device\{device name}[\]".
        result = []
        for p in paths:
            d = None
            if p is not None:
                q = p.split('\\', 3)
                if len(q) > 2 and q[1].lower() == 'device' and q[2]:
                    d = q[2].lower()
            result.append(d)
        return result


    def _getfinalpathname(p, flags=0):
        try:
            if isinstance(p, int):
                h = msvcrt.get_osfhandle(p)
            else:
                h = win32file.CreateFile(p, 0, 0, None, win32file.OPEN_EXISTING,
                        win32file.FILE_FLAG_BACKUP_SEMANTICS, None)
            return win32file.GetFinalPathNameByHandle(h, flags)
        except win32file.error as e:
            strerror = e.strerror.rstrip('\r\n .')
            raise OSError(0, strerror, p, e.winerror) from None

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46763>
_______________________________________

From report at bugs.python.org  Thu Feb 17 00:20:13 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Thu, 17 Feb 2022 05:20:13 +0000
Subject: [issue46745] Typo in new PositionsIterator
In-Reply-To: <1644804903.84.0.228689662177.issue46745@roundup.psfhosted.org>
Message-ID: <1645075213.41.0.49088542089.issue46745@roundup.psfhosted.org>


Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:


New changeset 482a4b6c3f8ef60056e85647a1d84af2e6dfd3ef by Robert-Andr? Mauchin in branch 'main':
bpo-46745: Fix typo in PositionsIterator (#31322)
https://github.com/python/cpython/commit/482a4b6c3f8ef60056e85647a1d84af2e6dfd3ef


----------
nosy: +Jelle Zijlstra

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46745>
_______________________________________

From report at bugs.python.org  Thu Feb 17 00:38:24 2022
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 17 Feb 2022 05:38:24 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645076304.32.0.131016270255.issue46771@roundup.psfhosted.org>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

> I note that there is no documented way to retrieve the cancel message

Does retrieving it from the CancelledError that is bubbling up suffice? Or do you need to be able to obtain it from the future object?

----------
nosy: +chris.jerdonek

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Thu Feb 17 00:54:43 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 17 Feb 2022 05:54:43 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645077283.69.0.516029133063.issue46771@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

> > I note that there is no documented way to retrieve the cancel message

> Does retrieving it from the CancelledError that is bubbling up suffice? Or do you need to be able to obtain it from the future object?

I'm not sure yet (if anything I'd need it for a task, not a future). But it's also not documented that it gets passed to the exception (at least not in the Task docs -- I didn't check the Future docs).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Thu Feb 17 01:17:27 2022
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 17 Feb 2022 06:17:27 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645078647.5.0.120055219347.issue46771@roundup.psfhosted.org>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

> I'm not sure yet (if anything I'd need it for a task, not a future).

(By future, I also meant task, as task inherits from future.) For now, I think it would be safer to get the message from the CancelledError, if possible, since how it gets there truly is an implementation detail. It would be okay to document that the msg argument gets passed to the CancelledError via the constructor, as that was always the intent.

See also issue 45390 and the message I wrote there on how to make that API work better (given that the msg is only available from the leaf exception in the exception chain, and the current implementation creates intermediate exceptions, I believe unnecessarily): https://bugs.python.org/issue45390#msg403570

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Thu Feb 17 03:26:39 2022
From: report at bugs.python.org (Erlend E. Aasland)
Date: Thu, 17 Feb 2022 08:26:39 +0000
Subject: =?utf-8?q?=5Bissue46634=5D_=5Bsqlite3=5D=C2=A0speed_up_cursor=2Eexecute*?=
 =?utf-8?b?KCk=?=
In-Reply-To: <1643971133.68.0.0138168910429.issue46634@roundup.psfhosted.org>
Message-ID: <1645086399.84.0.856096387651.issue46634@roundup.psfhosted.org>


Erlend E. Aasland <erlend.aasland at innova.no> added the comment:

The change proposed in GH-31127 was included in GH-31351. Closing this.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46634>
_______________________________________

From report at bugs.python.org  Thu Feb 17 03:32:12 2022
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Thu, 17 Feb 2022 08:32:12 +0000
Subject: [issue44949] test_readline: test_auto_history_disabled() fails
 randomly on aarch64 RHEL8 Refleaks 3.9, 3.10 and 3.x
In-Reply-To: <1629299356.46.0.606067543476.issue44949@roundup.psfhosted.org>
Message-ID: <1645086732.86.0.58608668434.issue44949@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:


New changeset b1bc04df817ecb3fb9fdbefa3782efea54488e6f by Miss Islington (bot) in branch '3.8':
bpo-44949: Fix test_readline auto history tests (GH-27813) (GH-31118)
https://github.com/python/cpython/commit/b1bc04df817ecb3fb9fdbefa3782efea54488e6f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44949>
_______________________________________

From report at bugs.python.org  Thu Feb 17 03:35:48 2022
From: report at bugs.python.org (Adrian Freund)
Date: Thu, 17 Feb 2022 08:35:48 +0000
Subject: [issue31242] Add SSLContext.set_verify_callback()
In-Reply-To: <1503265756.53.0.967490588927.issue31242@psf.upfronthosting.co.za>
Message-ID: <1645086948.79.0.150589499668.issue31242@roundup.psfhosted.org>


Change by Adrian Freund <git at freundtech.com>:


----------
nosy: +freundTech

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31242>
_______________________________________

From report at bugs.python.org  Thu Feb 17 04:20:10 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 17 Feb 2022 09:20:10 +0000
Subject: [issue45390] asyncio.Task doesn't propagate CancelledError()
 exception correctly.
In-Reply-To: <1633519842.27.0.396754460358.issue45390@roundup.psfhosted.org>
Message-ID: <1645089610.13.0.146064044469.issue45390@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
versions: +Python 3.11 -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45390>
_______________________________________

From report at bugs.python.org  Thu Feb 17 04:20:19 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 17 Feb 2022 09:20:19 +0000
Subject: [issue45390] asyncio.Task doesn't propagate CancelledError()
 exception correctly.
In-Reply-To: <1633519842.27.0.396754460358.issue45390@roundup.psfhosted.org>
Message-ID: <1645089619.37.0.181007151679.issue45390@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
keywords: +patch
pull_requests: +29531
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31383

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45390>
_______________________________________

From report at bugs.python.org  Thu Feb 17 04:26:57 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 17 Feb 2022 09:26:57 +0000
Subject: [issue45390] asyncio.Task doesn't propagate CancelledError()
 exception correctly.
In-Reply-To: <1633519842.27.0.396754460358.issue45390@roundup.psfhosted.org>
Message-ID: <1645090017.54.0.598598572151.issue45390@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

I have a pull request for the issue.
It doesn't use `Future.set_exception()` but creates a new CancelledError() with propagated message.
The result is the same, except raised exceptions are not comparable by `is` check.
As a benefit, `_cancelled_exc` works with the patch, exc.__context__ is correctly set.

The patch is not backported because it changes existing behavior a little. I'd like to avoid a situation when third-party code works with Python 3.11+, 3.10.3+, and 3.9.11+ only.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45390>
_______________________________________

From report at bugs.python.org  Thu Feb 17 04:30:29 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 17 Feb 2022 09:30:29 +0000
Subject: [issue45099] asyncio.Task's documentation says that loop arg is
 removed when it's not
In-Reply-To: <1630775028.47.0.984741146051.issue45099@roundup.psfhosted.org>
Message-ID: <1645090229.85.0.503147320765.issue45099@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

User code should not create Task objects explicitly.
Please use `asyncio.create_task()` (or shiny new TaskGroup.create_task()) instead. They doesn't have 'loop' argument.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45099>
_______________________________________

From report at bugs.python.org  Thu Feb 17 04:34:03 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 17 Feb 2022 09:34:03 +0000
Subject: [issue45098] asyncio.CancelledError should contain more information
 on cancellations
In-Reply-To: <1630761463.35.0.712522138496.issue45098@roundup.psfhosted.org>
Message-ID: <1645090443.71.0.899317833686.issue45098@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

After TaskGroup merging, the second `cancel()` call returns `False` and doesn't initiate the actual cancellation if it was scheduled by the first `cancel()` call.

I believe it "fixes" async-timeout: the first canceller wins.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45098>
_______________________________________

From report at bugs.python.org  Thu Feb 17 04:37:54 2022
From: report at bugs.python.org (Marco Pagliaricci)
Date: Thu, 17 Feb 2022 09:37:54 +0000
Subject: [issue45390] asyncio.Task doesn't propagate CancelledError()
 exception correctly.
In-Reply-To: <1645090017.54.0.598598572151.issue45390@roundup.psfhosted.org>
Message-ID: <CAHWeiQUPJQEJuqkodinh4rECvCv0h7qiEro0KLqfyNFo9DUJcQ@mail.gmail.com>


Marco Pagliaricci <pagliaricci.m at gmail.com> added the comment:

Andrew,
many thanks for your time, solving this issue.
I think your solution is the best to fix this little problem and I agree
with you on backporting.

My Best Regards,
and thanks again.

Marco

On Thu, Feb 17, 2022 at 10:29 AM Andrew Svetlov <report at bugs.python.org>
wrote:

>
> Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:
>
> I have a pull request for the issue.
> It doesn't use `Future.set_exception()` but creates a new CancelledError()
> with propagated message.
> The result is the same, except raised exceptions are not comparable by
> `is` check.
> As a benefit, `_cancelled_exc` works with the patch, exc.__context__ is
> correctly set.
>
> The patch is not backported because it changes existing behavior a little.
> I'd like to avoid a situation when third-party code works with Python
> 3.11+, 3.10.3+, and 3.9.11+ only.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue45390>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45390>
_______________________________________

From report at bugs.python.org  Thu Feb 17 04:48:45 2022
From: report at bugs.python.org (jack1142)
Date: Thu, 17 Feb 2022 09:48:45 +0000
Subject: [issue45099] asyncio.Task's documentation says that loop arg is
 removed when it's not
In-Reply-To: <1630775028.47.0.984741146051.issue45099@roundup.psfhosted.org>
Message-ID: <1645091325.78.0.453167434877.issue45099@roundup.psfhosted.org>


jack1142 <kuba.kuczys at gmail.com> added the comment:

I'm aware, I'm reporting this because as long as the instantiation of a Task is documented, the documentation should still contain accurate up-to-date information.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45099>
_______________________________________

From report at bugs.python.org  Thu Feb 17 05:23:56 2022
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 17 Feb 2022 10:23:56 +0000
Subject: [issue45390] asyncio.Task doesn't propagate CancelledError()
 exception correctly.
In-Reply-To: <1633519842.27.0.396754460358.issue45390@roundup.psfhosted.org>
Message-ID: <1645093436.42.0.755271702097.issue45390@roundup.psfhosted.org>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Andrew, the approach I described would I feel be much better. It would result in more concise, less verbose tracebacks, as opposed to more verbose -- not just because the message won't be repeated, but also because it eliminates the unneeded creation of intermediate exceptions. It would also cause is checks to work, which is what we want since behaviorally it should be the same exception.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45390>
_______________________________________

From report at bugs.python.org  Thu Feb 17 05:46:59 2022
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 17 Feb 2022 10:46:59 +0000
Subject: [issue39327] shutil.rmtree using vagrant synched folder fails
In-Reply-To: <1578995152.92.0.0617677010821.issue39327@roundup.psfhosted.org>
Message-ID: <1645094819.66.0.479187578406.issue39327@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: +29532
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31384

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39327>
_______________________________________

From report at bugs.python.org  Thu Feb 17 05:51:52 2022
From: report at bugs.python.org (Walter Doekes)
Date: Thu, 17 Feb 2022 10:51:52 +0000
Subject: [issue9338] argparse optionals with nargs='?',
 '*' or '+' can't be followed by positionals
In-Reply-To: <1279881989.28.0.725806934086.issue9338@psf.upfronthosting.co.za>
Message-ID: <1645095112.6.0.250353377433.issue9338@roundup.psfhosted.org>


Change by Walter Doekes <walter+python at wjd.nu>:


----------
nosy: +wdoekes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9338>
_______________________________________

From report at bugs.python.org  Thu Feb 17 06:00:41 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Thu, 17 Feb 2022 11:00:41 +0000
Subject: [issue46745] Typo in new PositionsIterator
In-Reply-To: <1644804903.84.0.228689662177.issue46745@roundup.psfhosted.org>
Message-ID: <1645095641.56.0.0878727362571.issue46745@roundup.psfhosted.org>


Change by Nikita Sobolev <mail at sobolevn.me>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46745>
_______________________________________

From report at bugs.python.org  Thu Feb 17 07:18:13 2022
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Thu, 17 Feb 2022 12:18:13 +0000
Subject: [issue41086] Exception for uninstantiated interpolation (configparser)
In-Reply-To: <1592875721.54.0.0419083877118.issue41086@roundup.psfhosted.org>
Message-ID: <1645100293.67.0.969609075028.issue41086@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:


New changeset fc115c9bde52a58b4fb9be2b80c3d6be8a4d2454 by Brian Faherty in branch 'main':
bpo-41086: Add exception for uninstantiated interpolation (configparser) (GH-21062)
https://github.com/python/cpython/commit/fc115c9bde52a58b4fb9be2b80c3d6be8a4d2454


----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41086>
_______________________________________

From report at bugs.python.org  Thu Feb 17 07:22:23 2022
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Thu, 17 Feb 2022 12:22:23 +0000
Subject: [issue26831] ConfigParser parsing failures with default_section and
 ExtendedInterpolation options
In-Reply-To: <1461364657.99.0.761573071574.issue26831@psf.upfronthosting.co.za>
Message-ID: <1645100543.64.0.840283563999.issue26831@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

Note: the problem here was due to passing `ExtendedInterpolation` (the class) instead of `ExtendedInterpolation()` (the object). This is now fixed through BPO-41086.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26831>
_______________________________________

From report at bugs.python.org  Thu Feb 17 07:22:51 2022
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Thu, 17 Feb 2022 12:22:51 +0000
Subject: [issue26469] Bug in ConfigParser when setting new values in extended
 interpolation
In-Reply-To: <1456911640.56.0.456152786125.issue26469@psf.upfronthosting.co.za>
Message-ID: <1645100571.63.0.121951299491.issue26469@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

Note: the problem here was due to passing `ExtendedInterpolation` (the class) instead of `ExtendedInterpolation()` (the object). This is now fixed through BPO-41086.

----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26469>
_______________________________________

From report at bugs.python.org  Thu Feb 17 07:25:11 2022
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Thu, 17 Feb 2022 12:25:11 +0000
Subject: [issue41086] Exception for uninstantiated interpolation (configparser)
In-Reply-To: <1592875721.54.0.0419083877118.issue41086@roundup.psfhosted.org>
Message-ID: <1645100711.51.0.919881673245.issue41086@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

It's a behavioral change that tightens acceptable objects passed to `interpolation=`. In the past any object that provided the same interface as `Interpolation` instances would be accepted. No longer.

I think this is an acceptable compromise but it's definitely outside of the realm of backporting.

Thanks for your contribution, Brian! ? ? ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41086>
_______________________________________

From report at bugs.python.org  Thu Feb 17 07:30:07 2022
From: report at bugs.python.org (=?utf-8?q?Tin_Tvrtkovi=C4=87?=)
Date: Thu, 17 Feb 2022 12:30:07 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645101007.34.0.152770632486.issue46771@roundup.psfhosted.org>


Tin Tvrtkovi? <tinchester at gmail.com> added the comment:

@Guido @Chris

Instead of using the message for the nonce we could have a dedicated field for it.

I have a proposal though. It's about putting a little logic into the cancellation nonce handling.

Let's define the nonce as a float. If you just call Task.cancel(), the nonce defaults to 0.0. We add an argument to Task.cancel, so you can give it a nonce: task.cancel(nonce=nonce). The cancel() method has logic to keep track of the nonce with the smallest value.

When it's time for the CancelledError to be thrown into the task, this nonce (default 0.0 if not set by anthing) is attached to the error.

Then we change `move_on_after` (and all siblings) to do the following:

* in `__enter__`, use time.monotonic() to generate it's own nonce and remember it
* in `__exit__`, if the CancelledError has a nonce that is less than its own nonce, it propagates it, otherwise it handles it.

How this fixes the sad path in my example:

Both the web server and `move_on_after` cancel the task. The web server just calls `task.cancel()`, `move_on_after` calls `task.cancel(nonce=self.nonce)`. No matter the cancellation ordering, the nonce will end up set to 0.0. `move_on_after` will see the 0.0 nonce and propagate the error correctly to kill the task completely.

This also handles nested cancel scopes. I'm not sure how it works with the task catching the cancel to do a little cleanup.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Thu Feb 17 07:30:05 2022
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Thu, 17 Feb 2022 12:30:05 +0000
Subject: [issue41086] Exception for uninstantiated interpolation (configparser)
In-Reply-To: <1592875721.54.0.0419083877118.issue41086@roundup.psfhosted.org>
Message-ID: <1645101005.08.0.326976605709.issue41086@roundup.psfhosted.org>


Change by ?ukasz Langa <lukasz at langa.pl>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41086>
_______________________________________

From report at bugs.python.org  Thu Feb 17 07:48:24 2022
From: report at bugs.python.org (chen-y0y0)
Date: Thu, 17 Feb 2022 12:48:24 +0000
Subject: [issue46776] RecursionError when using property() inside classes
Message-ID: <1645102104.25.0.972023321131.issue46776@roundup.psfhosted.org>


New submission from chen-y0y0 <cyy144881 at icloud.com>:

A simple class definition:
class Foo: bar = property(lambda self: self.bar)
And get the value of Foo.bar, it returns correctly, <property object at 0x**********>.
And get the value of Foo().bar, it raises RecursionError:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 1, in <lambda>
  File "<stdin>", line 1, in <lambda>
  File "<stdin>", line 1, in <lambda>
  [Previous line repeated 996 more times]
RecursionError: maximum recursion depth exceeded

----------
components: Interpreter Core
messages: 413403
nosy: prasechen
priority: normal
severity: normal
status: open
title: RecursionError when using property() inside classes
type: behavior
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46776>
_______________________________________

From report at bugs.python.org  Thu Feb 17 07:54:16 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 17 Feb 2022 12:54:16 +0000
Subject: [issue46777] Fix incorrect use of directives in asyncio documentation
Message-ID: <1645102456.61.0.455925245808.issue46777@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

There are some issues with formatting added or removed parameters in the asyncio module.

1. "deprecated-removed" directives were used for already removed directives. It should be used for deprecated features with known term of removal. For removed features "versionchanged" is more appropriate.

2. Text for removed parameters was too verbose. "Removed the XXX parameter" would be enough.

3. "versionadded" directives were used for new parameters. "versionchanged" directive is more appropriate. It is a date of the change in existing function, not the date of adding the function itself.

4. Some directives were written not in order of increasing version number.

5. In some places parameters were marked up as ``name``. *name* is commonly used for parameters.

----------
assignee: docs at python
components: Documentation, asyncio
messages: 413404
nosy: asvetlov, docs at python, kj, serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: Fix incorrect use of directives in asyncio documentation
type: enhancement
versions: Python 3.10, Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46777>
_______________________________________

From report at bugs.python.org  Thu Feb 17 07:58:58 2022
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Thu, 17 Feb 2022 12:58:58 +0000
Subject: [issue45413] Add install scheme for virtual environments
In-Reply-To: <1633715402.49.0.434363843275.issue45413@roundup.psfhosted.org>
Message-ID: <1645102738.42.0.413173221466.issue45413@roundup.psfhosted.org>


Miro Hron?ok <miro at hroncok.cz> added the comment:

I've adapted the PR. See the latest commit (Instead of *venv* scheme, have *posix_venv* and *nt_venv*).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45413>
_______________________________________

From report at bugs.python.org  Thu Feb 17 08:13:30 2022
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 17 Feb 2022 13:13:30 +0000
Subject: [issue46776] RecursionError when using property() inside classes
In-Reply-To: <1645102104.25.0.972023321131.issue46776@roundup.psfhosted.org>
Message-ID: <1645103610.97.0.154211677909.issue46776@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

This is not a bug, Python is working correctly here. The interpreter is doing exactly what you told it to do, and then raising a RecursionError before you can crash the system.


You have a property instance.bar which returns instance.bar, which returns instance.bar, which returns instance.bar... forever, or until RecursionError is triggered.

Your class is the same as:

class Foo:
    @property
    def bar(self):
        return self.bar

So when you call instance.bar, it looks up bar, which is the property, which looks up bar, which is the property, which looks up bar, and so on.

What did you expect to happen?

----------
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46776>
_______________________________________

From report at bugs.python.org  Thu Feb 17 08:13:46 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 17 Feb 2022 13:13:46 +0000
Subject: [issue46777] Fix incorrect use of directives in asyncio documentation
In-Reply-To: <1645102456.61.0.455925245808.issue46777@roundup.psfhosted.org>
Message-ID: <1645103626.81.0.0614345917402.issue46777@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +29533
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31388

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46777>
_______________________________________

From report at bugs.python.org  Thu Feb 17 08:18:51 2022
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 17 Feb 2022 13:18:51 +0000
Subject: [issue46776] RecursionError when using property() inside classes
In-Reply-To: <1645102104.25.0.972023321131.issue46776@roundup.psfhosted.org>
Message-ID: <1645103931.29.0.720420504533.issue46776@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Maybe you expected to do this:

class C:
    def __init__(self):
        self._value = 999

    @property
    def bar(self):
        return self._value

obj = C()
obj.bar  # returns 999

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46776>
_______________________________________

From report at bugs.python.org  Thu Feb 17 08:29:04 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 17 Feb 2022 13:29:04 +0000
Subject: [issue46777] Fix incorrect use of directives in asyncio documentation
In-Reply-To: <1645102456.61.0.455925245808.issue46777@roundup.psfhosted.org>
Message-ID: <1645104544.76.0.0346251033025.issue46777@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

6. The loop parameter of Task() was documented as both removed and required (if there is no current event loop) in 3.10.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46777>
_______________________________________

From report at bugs.python.org  Thu Feb 17 08:34:34 2022
From: report at bugs.python.org (Alex Waygood)
Date: Thu, 17 Feb 2022 13:34:34 +0000
Subject: [issue46774] Importlib.metadata.version picks first distribution not
 latest
In-Reply-To: <1645062095.18.0.489026763345.issue46774@roundup.psfhosted.org>
Message-ID: <1645104874.1.0.382863908582.issue46774@roundup.psfhosted.org>


Change by Alex Waygood <Alex.Waygood at Gmail.com>:


----------
nosy: +jaraco

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46774>
_______________________________________

From report at bugs.python.org  Thu Feb 17 10:11:11 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 17 Feb 2022 15:11:11 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645110671.83.0.41667558618.issue46771@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

The discussion is hot, I see several interleaved threads.

Let me put my answers on all of them in order of appearance.

1. quattro cancellation scopes are implemented after async-timeout.
As the author of async-timeout I am happy to know it.
The module is pretty small (as async-timeout itself).
I'd like to concentrate on the differences between async-timeout and quattro.

  a) quattro has `fail_after()` / `fail_at()` context managers,
  that are similar to async-timeout's `timeout()` / `timeout_at()`
  The first function schedules timeout as a *relative* delay,
  the second uses *absolut monotonic* time. So far so good.

  `timeout()` better points on 'what happens' I believe (TimeoutError is raised).
  `fail_after` is not that bad at all but `timeout()` is easier I think.
  `timeout_at()` and `fail_at()` are minic to `loop.call_at()`, the prefix is perfect.
  Regarding `loop.call_later()` I found that `timeout_later()` is too long name
  (plus `timeout()` context manager appeared in 2015 as a part of aiohttp).

  My opinion is biased, sure.

  b) quattro has `move_on_after()` and `move_on_at()` context managers that doesn't
  raise TimeoutError but set a flag after certain period.
  asyncio has lower level primitives than trio (`loop.call_later()` and `loop.call_at()`).
  Not sure that `move_on_*` should be added, they are low-level building blocks.
  On the other hand, `move_on_after()` requires less code lines than `call_later()`.
  If we decide 'yes' I suggest changing naming: I have no idea what is *moved* without
  reading the documentation.

  c) `with fail_after()` vs `async with timeout()`.
  The first async-timeout version used `with timeout()` notation.
  I've changed it to async counterpart after many questions from newbies:
  "Why is sync context manages used in async code?". Questions arose when asyncio was not
  wide-spread as today.
  People made their first baby steps those days, I provided a dozen of asyncio offline courses
  and many conference talks.
  Thus, please consider `async with ...` design as a user feedback reaction.
  As a side effect, it prohibits `timeout()` usage in non-async functions (which is
  awkward at least).
  Regarding async context manager performance, I think it is good enough
  for timeout-related things. I didn't experience any problem with it.
  Moreover, async fast-path (async function is called and it returns a value without
  suspension on awaiting) can be optimized on Python level to make it as fast as a regular
  python function call, sure. It is not trivial and might require adding a new opcode
  (combine CALL + GET_AWAITABLE) but this optimization is out of the issue scope.

  d) `cm.deadline += 0.5` vs `cm.shift(0.5)` is a question of taste.  asyncio-timeout
  design motivation was "don't do complex things in property setter" but I can live with
  mutable `cm.deadline` attribute, sure

  e) cancellation stack and `current_effective_deadline` -- I'm with Guido, let's not
  add yet another stack.  It can be an interesting debug feature but I doubt
  if it is useful in production code.
  Also, the performance cost is not zero. Merging and slicing stack tuple on any
  timeout context enter/exit is not free. The implementation can be switched
  to a linked list but still, do we really need it?

2. Alex Gr?nholm, asyncio supports custom task instances without overriding the entire
task factory. You should provide a custom method for custom task creatuon, that's it.
`asyncio.all_tasks()` / `asyncio.current_task()` support is provided by
'_register_task()', '_unregister_task()', '_enter_task()', and '_leave_task()' calls.
These methods are part of non-user-faced public API, they are intentionally enumerated
by `asyncio.__all__`.
These methods are mentioned by changelog only, sorry. A pull request for documenting them
in asyncio low-level section is welcome!

3. The race condition between two `.cancel()` calls performed by the same loop iteration.
Sure, the race exists.
Before TaskGroup landing, the last `.cancel()` wins. After the change, the first `.cancel()`
wins and all subsequent `.cancel()` calls made on the same event loop iteration are rejected
with returning `False`.  I believe, the changed behavior is more consistent (and close to
`Future.cancel()` design).

Assume, we have two scheduled close but different timeouts for the same tasks.
Both are reached at the next event loop iteration (see the timeline below):

prev-iteration   timeout-a   timeout-b  current-iteration
     |              |           |              |
 >---+--------------+-----------+--------------+--------------> future

I prepared https://github.com/aio-libs/async-timeout/pull/295 to handle it (not merged
yet because the next Python alpha release it required; I've tested it against the latest
CPython main branch manually). Sorry for polluting source code by `sys.version_info` checks,
the library is supposed to work with Python 3.7+.

async-timeout handles the race as follows:
https://github.com/aio-libs/async-timeout/blob/master/async_timeout/__init__.py#L209-L239

  a) timeout-a and timeout-b TimeHandle's are scheduled for execution
  on the current iteration and executed.
  b) Both context managers set their own state to 'TIMEOUT'.
  c) timeout-a cancels the current task, timeout-b calls the cancel but it is
  skipped and rejected because timeout-a called `task.cancel()` earlier.
  d) The task is cancelled, async stack unwinds.
  e) The inner context manager converts CancelledError to TimeoutError and raises it.
  f) The outer context manager does nothing but bubbles-up TimeoutError from
  the inner context manager.

Doesn't matter what context manager (timeout-a or timeout-b) is inner and what is outer;
it the timeout occurs the TimeoutError is propagated from the inner code up along the stack
*unless* some code swallows it intentionally.
I don't think that we should prohibit swallowing.

Another edge case is the task explicit cancellation that is scheduled on the same event
loop iteration as timeout occurrence:

prev-iteration (explicit .cancel() called)   timeout  current-iteration
		   |                            |             |
 >-----------------+----------------------------+-------------+----------> future


  a) `loop.call_later()` registered callback (`_on_timeout`) is called first.
  Its `task.cancel()` is rejected (`False` returned) because the first cancellation
  was explicitly requested on the previous iteration.
  b) the task wakes up to handle `.cancel()` call from the prev iteration
  c) stack unwinds with CancelledError, it is not converted to TimeoutError because
  CancelledError has no required message. That's fine, because `.cancel()` call from
  the previous iteration is processed, not timeout itself.
  d) `.expired` property is `True` though because timeout is reached technically;
  the wall-clock time is greater than the deadline.


4. Tin Tvrtkovi?, I don't think that a separate field for 'nonce' is needed for the
proper cancellation.

It adds more complexity; I have no idea what to do with the nonce field if the
CancelledError comes not from timeout context manager but is rased by other logic.

As I demonstrated above, using cancellation message as nonce work perfectly fine.


P.S. It is a long letter, sorry. Please don't hesitate to discuss it, feel free to ask a
question if some of my words are not clear. English is not my mother language :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Thu Feb 17 10:21:17 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 17 Feb 2022 15:21:17 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645111277.2.0.856645197037.issue46771@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

I support Alex Gr?nholm: TaskGroup is not affected by cancellation races because it doesn't convert the exception or swallows it.
The code is safe from my understanding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Thu Feb 17 10:40:17 2022
From: report at bugs.python.org (=?utf-8?q?Sebasti=C3=A1n_Ram=C3=ADrez?=)
Date: Thu, 17 Feb 2022 15:40:17 +0000
Subject: [issue44834] contextvars.Context.run w/ coroutines gives inconsistent
 behavior
In-Reply-To: <1628100194.12.0.330262028027.issue44834@roundup.psfhosted.org>
Message-ID: <1645112417.56.0.482107298258.issue44834@roundup.psfhosted.org>


Change by Sebasti?n Ram?rez <tiangolo at gmail.com>:


----------
nosy: +tiangolo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44834>
_______________________________________

From report at bugs.python.org  Thu Feb 17 10:49:48 2022
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 17 Feb 2022 15:49:48 +0000
Subject: [issue46730] Please consider mentioning property without setter when
 an attribute can't be set
In-Reply-To: <1644664548.7.0.814482728123.issue46730@roundup.psfhosted.org>
Message-ID: <1645112988.56.0.135004590039.issue46730@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
nosy: +christian.heimes
nosy_count: 4.0 -> 5.0
pull_requests: +29534
pull_request: https://github.com/python/cpython/pull/31389

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46730>
_______________________________________

From report at bugs.python.org  Thu Feb 17 10:51:27 2022
From: report at bugs.python.org (=?utf-8?q?Tin_Tvrtkovi=C4=87?=)
Date: Thu, 17 Feb 2022 15:51:27 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645113087.11.0.190588874238.issue46771@roundup.psfhosted.org>


Tin Tvrtkovi? <tinchester at gmail.com> added the comment:

Hello Andrew, here's some followup.

About the names: the move_on_after and fail_after names are from Trio. I don't have strong feeling about them at all, whatever most people like.

About move_on_after vs loop.call_at and loop.call_later: move_on_after is much more usable in practice, since it doesn't require splitting your coroutine in several. And it's very useful in production code; when dealing with 3rd party APIs you want to wait a reasonable time and continue on your way if the 3rd party API stalls.

About `async with` vs `with`: I have strong feelings for `with`. It's not a performance issue; I don't care about that. `async with` to me says there are suspension points involved; this coroutine might or might not be suspended either entering or existing. With a bare `with` I *know* there is no suspension. This is important to keep my concurrent code more correct, which is hard enough.

About overriding the task factory: the default Task implementation is implemented in C, correct? I would be way too scared of putting my (Python) implementation in there because of performance. Spending years shaving microseconds off in my other libraries to risk losing it all because I want better cancellation in asyncio would feel really bad. Ideally we can get a good-enough solution in the stdlib so users don't have to do this.

About your point 3, first graph: you are right if both context managers propagate exceptions. If the inner one is set to swallow (`move_on_after`) OR the user plans on swallowing the inner one, the problem is *not* solved  (or at least I don't understand the solution). This is the code sample from https://bugs.python.org/issue46771#msg413368. And I think swallowing is an important use case, as I've already mentioned.

About the special field for nonce: I'm OK with smuggling the nonce in the message. But I stand by my proposal for making the nonce a monotonic number, and that would require a special field to be clean.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Thu Feb 17 11:21:05 2022
From: report at bugs.python.org (Eric Snow)
Date: Thu, 17 Feb 2022 16:21:05 +0000
Subject: [issue43974] Define Py_BUILD_CORE_MODULE in extensions instead of
 setup.py and Modules/Setup
In-Reply-To: <1619686946.42.0.670507836309.issue43974@roundup.psfhosted.org>
Message-ID: <1645114865.16.0.154642230005.issue43974@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43974>
_______________________________________

From report at bugs.python.org  Thu Feb 17 11:21:09 2022
From: report at bugs.python.org (Eric Snow)
Date: Thu, 17 Feb 2022 16:21:09 +0000
Subject: [issue41111] [C API] Convert a few stdlib extensions to the limited C
 API (PEP 384)
In-Reply-To: <1593075260.88.0.835474638855.issue41111@roundup.psfhosted.org>
Message-ID: <1645114869.58.0.17669893022.issue41111@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41111>
_______________________________________

From report at bugs.python.org  Thu Feb 17 11:24:10 2022
From: report at bugs.python.org (Jeremy Kloth)
Date: Thu, 17 Feb 2022 16:24:10 +0000
Subject: [issue46778] Enable parallel compilation on Windows builds
Message-ID: <1645115050.56.0.993068912752.issue46778@roundup.psfhosted.org>


New submission from Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com>:

While the current build does enable building of projects in parallel 
(msbuild -m), the compilation of each project's source files is done sequentially.  For large projects like pythoncore or _freeze_module this can take quite some time.

This simple PR speeds things up significantly, ~2x on machines that I have access.

----------
components: Build, Windows
messages: 413412
nosy: jkloth, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Enable parallel compilation on Windows builds
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46778>
_______________________________________

From report at bugs.python.org  Thu Feb 17 11:28:20 2022
From: report at bugs.python.org (Jeremy Kloth)
Date: Thu, 17 Feb 2022 16:28:20 +0000
Subject: [issue46778] Enable parallel compilation on Windows builds
In-Reply-To: <1645115050.56.0.993068912752.issue46778@roundup.psfhosted.org>
Message-ID: <1645115300.64.0.272829669094.issue46778@roundup.psfhosted.org>


Change by Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com>:


----------
keywords: +patch
pull_requests: +29535
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31390

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46778>
_______________________________________

From report at bugs.python.org  Thu Feb 17 11:31:44 2022
From: report at bugs.python.org (Jack O'Connor)
Date: Thu, 17 Feb 2022 16:31:44 +0000
Subject: [issue39298] add BLAKE3 to hashlib
In-Reply-To: <1578716860.16.0.194711020268.issue39298@roundup.psfhosted.org>
Message-ID: <1645115504.89.0.299895883707.issue39298@roundup.psfhosted.org>


Jack O'Connor <oconnor663 at gmail.com> added the comment:

What's the best way for me to help with the next steps of this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39298>
_______________________________________

From report at bugs.python.org  Thu Feb 17 11:34:48 2022
From: report at bugs.python.org (Adrian Freund)
Date: Thu, 17 Feb 2022 16:34:48 +0000
Subject: [issue31242] Add SSLContext.set_verify_callback()
In-Reply-To: <1503265756.53.0.967490588927.issue31242@psf.upfronthosting.co.za>
Message-ID: <1645115688.62.0.533304369006.issue31242@roundup.psfhosted.org>


Change by Adrian Freund <git at freundtech.com>:


----------
keywords: +patch
pull_requests: +29536
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31391

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31242>
_______________________________________

From report at bugs.python.org  Thu Feb 17 11:37:30 2022
From: report at bugs.python.org (Thomas Grainger)
Date: Thu, 17 Feb 2022 16:37:30 +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: <1645115850.4.0.890907160206.issue42752@roundup.psfhosted.org>


Change by Thomas Grainger <tagrain at gmail.com>:


----------
nosy: +graingert, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42752>
_______________________________________

From report at bugs.python.org  Thu Feb 17 11:43:33 2022
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 17 Feb 2022 16:43:33 +0000
Subject: [issue39298] add BLAKE3 to hashlib
In-Reply-To: <1578716860.16.0.194711020268.issue39298@roundup.psfhosted.org>
Message-ID: <1645116213.6.0.862631207299.issue39298@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

I thought someone volunteered to do it--if that's not happening, I could take a look at it next week.  Shouldn't be too hard... unless I have to touch autoconf, which I only barely understand.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39298>
_______________________________________

From report at bugs.python.org  Thu Feb 17 11:53:22 2022
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Thu, 17 Feb 2022 16:53:22 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645116802.14.0.665969156305.issue46771@roundup.psfhosted.org>


Alex Gr?nholm <alex.gronholm at nextday.fi> added the comment:

@Guido you asked for the AnyIO implementation of Happy Eyeballs; here it is: https://github.com/agronholm/anyio/blob/ac3e7c619913bd0ddf9c36b6e633b278d07405b7/src/anyio/_core/_sockets.py#L85

(I didn't paste the actual code here because it's way too long)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Thu Feb 17 11:53:40 2022
From: report at bugs.python.org (Adrian Freund)
Date: Thu, 17 Feb 2022 16:53:40 +0000
Subject: [issue46779] Add ssl.CERT_REQUIRED_NO_VERIFY as possible value for
 ssl.SSLContext.verify_mode
Message-ID: <1645116820.13.0.214856830596.issue46779@roundup.psfhosted.org>


New submission from Adrian Freund <git at freundtech.com>:

Some networked applications might require connecting to client with invalid certificates but still requiring the client to send a certificate.

ssl.SSLContext.verify_mode currently supports the following options:
ssl.CERT_NONE: Don't require the client to send a certificate and don't validate it if they send one anyways.
ssl.CERT_OPTIONAL: Don't require the client to send a certificate but validate it if they send one.
ssl.CERT_REQUIRED: Require the client to send a certificate and validate it.

There is currently no option for servers that want to require the client to send a certificate but don't validate it.

This would for example be needed it a server should accept clients with self-signed certificates and then store their certificates to recognize them again later.

A concrete example is the KDEConnect protocol.

An alternative solution would be bpo-31242. That would also solve this problem is a more general, but also more complicated way.

I think that the solution proposed here this issue is better for it's simplicity and also solves most usecases for bpo-31242.


Note that a ssl.CERT_REQUIRED_NO_VERIFY was already proposed in bpo-18293, but that issue was closed because it was specifically in relation to a deprecated api. The mentioned values are however also used in modern asyncio apis.

----------
assignee: christian.heimes
components: SSL
messages: 413416
nosy: christian.heimes, freundTech
priority: normal
severity: normal
status: open
title: Add ssl.CERT_REQUIRED_NO_VERIFY as possible value for ssl.SSLContext.verify_mode
type: enhancement
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46779>
_______________________________________

From report at bugs.python.org  Thu Feb 17 11:54:35 2022
From: report at bugs.python.org (Adrian Freund)
Date: Thu, 17 Feb 2022 16:54:35 +0000
Subject: [issue31242] Add SSLContext.set_verify_callback()
In-Reply-To: <1503265756.53.0.967490588927.issue31242@psf.upfronthosting.co.za>
Message-ID: <1645116875.54.0.472338647752.issue31242@roundup.psfhosted.org>


Adrian Freund <git at freundtech.com> added the comment:

I also need this feature for something I'm working on, so I looked into it a bit and pushed a small proof of concept implementation to GitHub (See PR 31391).

I'm not sure if I'll have enough time to finish and clean up this implementation, but at least there is a starting point.

I also opened bpo-46779 as a simpler method to solve most of the usecases  that would be solved by this api.

----------
versions: +Python 3.11 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31242>
_______________________________________

From report at bugs.python.org  Thu Feb 17 12:27:34 2022
From: report at bugs.python.org (Lee Newberg)
Date: Thu, 17 Feb 2022 17:27:34 +0000
Subject: [issue46780] Allow Fractions to return 1/6 for "0.17", "0.167",
 "0.1667", etc.
Message-ID: <1645118854.48.0.835738770183.issue46780@roundup.psfhosted.org>


New submission from Lee Newberg <github at quantconsulting.com>:

For example, a string such as "0.167" could be rounded from anything in [0.1665, 0.1675).  Within that interval, the fraction with the lowest numerator and denominator is 1/6.

Here it is proposed that we add a new flag to the Fractions constructor, perhaps called `_assume_rounded`, which defaults to False and then yields no change from current behavior.  However, when it is True, the constructed Fraction first computes the range of the values that the input string could have been rounded from, and then computes the fraction in that half-open interval with the lowest numerator and denominator.  This is described at https://en.wikipedia.org/wiki/Continued_fraction#Best_rational_within_an_interval, which uses continued fractions to arrive at the answer.

For extra bells and whistles, we'd support strings like "0x0.2AAB" which is hexadecimal for 1/6 rounded to that many places.  In this case, we'd find 1/6 as the fraction with lowest numerator and denominator in the interval [0x0.2AAA8, 0x0.2AAB8).  Likewise for binary, octal, and any other formats supported by Python.

----------
components: Library (Lib)
messages: 413418
nosy: Leengit
priority: normal
severity: normal
status: open
title: Allow Fractions to return 1/6 for "0.17", "0.167", "0.1667", etc.
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46780>
_______________________________________

From report at bugs.python.org  Thu Feb 17 12:58:11 2022
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 17 Feb 2022 17:58:11 +0000
Subject: [issue46780] Allow Fractions to return 1/6 for "0.17", "0.167",
 "0.1667", etc.
In-Reply-To: <1645118854.48.0.835738770183.issue46780@roundup.psfhosted.org>
Message-ID: <1645120691.71.0.0224292419652.issue46780@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

This sounds interesting, but also rather similar to what the `limit_denominator` method can get you.  Can you provide examples that can't be handled nicely by `limit_denominator` to strengthen your case?

----------
nosy: +mark.dickinson, rhettinger, zach.ware
versions: +Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46780>
_______________________________________

From report at bugs.python.org  Thu Feb 17 13:05:25 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 17 Feb 2022 18:05:25 +0000
Subject: [issue46780] Allow Fractions to return 1/6 for "0.17", "0.167",
 "0.1667", etc.
In-Reply-To: <1645118854.48.0.835738770183.issue46780@roundup.psfhosted.org>
Message-ID: <1645121125.74.0.428541486145.issue46780@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It would return 1/7 for "0.1" and 1/4 for "0.2". Is it what you expected?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46780>
_______________________________________

From report at bugs.python.org  Thu Feb 17 13:08:22 2022
From: report at bugs.python.org (Matthias Urlichs)
Date: Thu, 17 Feb 2022 18:08:22 +0000
Subject: [issue46781] Tracing: c_return doesn't report the result
Message-ID: <1645121302.3.0.866413840913.issue46781@roundup.psfhosted.org>


New submission from Matthias Urlichs <matthias at urlichs.de>:

When tracing/profiling, the "return" event reports the value returned by the exiting function.

However, this does not work for C functions. The profiler's "c_return" hook is called with the same C function object as "c_call". This unnecessarily complicates debugging and should be fixed.

https://stackoverflow.com/questions/61067303/get-return-value-of-python-builtin-functions-while-tracing

----------
components: C API
messages: 413421
nosy: smurfix
priority: normal
severity: normal
status: open
title: Tracing: c_return doesn't report the result
type: enhancement
versions: Python 3.10, Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46781>
_______________________________________

From report at bugs.python.org  Thu Feb 17 13:09:02 2022
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 17 Feb 2022 18:09:02 +0000
Subject: [issue31242] Add SSLContext.set_verify_callback()
In-Reply-To: <1503265756.53.0.967490588927.issue31242@psf.upfronthosting.co.za>
Message-ID: <1645121342.26.0.238417209539.issue31242@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Unfortunately a generic and future-proof verify callback is much more work. We need to expose and wrap X509_STORE_CTX, X509_STORE, X509 (include STACK_OF(X509)), and probably several other OpenSSL structures. We also need to expose error codes.

----------
superseder:  -> Expose SSL_CTX_set_cert_verify_callback

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31242>
_______________________________________

From report at bugs.python.org  Thu Feb 17 13:09:50 2022
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Feb 2022 18:09:50 +0000
Subject: [issue46780] Allow Fractions to return 1/6 for "0.17", "0.167",
 "0.1667", etc.
In-Reply-To: <1645118854.48.0.835738770183.issue46780@roundup.psfhosted.org>
Message-ID: <1645121390.52.0.015988907549.issue46780@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> the constructed Fraction first computes the range of the values that the input string could have been rounded from

There's too much magic and guesswork here for my liking; I don't really see this as feasible. Moreover, depending on which rounding mode was used (round-ties-to-even, round-ties-to-away), the interval may be half-open, open or closed.

For another problematic example, suppose the string supplied is "0.10". How are we to guess whether this was the result of rounding to two decimal places after the point (in which case the interval we need is [0.095, 0.105]), or whether it's the result of rounding to two significant figures (in which case the interval we need is [0.095, 0.15])?

> and then computes the fraction in that half-open interval with the lowest numerator and denominator

This part, however, is well-defined and can be done efficiently. You may be interested in the "simplefractions" module on PyPI, which solves the exact task "find the simplest fraction in a given interval".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46780>
_______________________________________

From report at bugs.python.org  Thu Feb 17 13:10:47 2022
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 17 Feb 2022 18:10:47 +0000
Subject: [issue31242] Add SSLContext.set_verify_callback()
In-Reply-To: <1503265756.53.0.967490588927.issue31242@psf.upfronthosting.co.za>
Message-ID: <1645121447.28.0.630576488903.issue31242@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

bpo-28747 was an older ticket for implementing a callback.

----------
assignee: christian.heimes -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31242>
_______________________________________

From report at bugs.python.org  Thu Feb 17 13:12:36 2022
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Feb 2022 18:12:36 +0000
Subject: [issue46780] Allow Fractions to return 1/6 for "0.17", "0.167",
 "0.1667", etc.
In-Reply-To: <1645118854.48.0.835738770183.issue46780@roundup.psfhosted.org>
Message-ID: <1645121556.83.0.20915670794.issue46780@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> in which case the interval we need is [0.095, 0.15]

Whoops, sorry; brain fail. If we're rounding to two sig figs, the next representable value up from 0.01 is 0.011, while the next one down is 0.099, so the interval we'd be interested in would be [0.0995, 0.105].

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46780>
_______________________________________

From report at bugs.python.org  Thu Feb 17 13:12:21 2022
From: report at bugs.python.org (sjndlnv brjkbn)
Date: Thu, 17 Feb 2022 18:12:21 +0000
Subject: [issue46782] Docs error for 3.10
Message-ID: <1645121541.07.0.568386298101.issue46782@roundup.psfhosted.org>


New submission from sjndlnv brjkbn <usetohandletrush at gmail.com>:

Document for 3.10 version seems auto convert 0o777 to 511. And it's correct for 3.9

(May be due to new version of Sphinx? Seems source code for docs are correct.)

[img]https://i.imgur.com/ByWSJ6A.png[/img]
[img]https://i.imgur.com/rK0romC.png[/img]
[img]https://i.imgur.com/WXYMcrT.png[/img]
[img]https://i.imgur.com/W5YskgQ.png[/img]

It may misleading user. If we use os.mkdir(mode=511), it's not equal to use os.mkdir(mode=0o777)

----------
assignee: docs at python
components: Documentation
messages: 413425
nosy: docs at python, usetohandletrush
priority: normal
severity: normal
status: open
title: Docs error for 3.10
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46782>
_______________________________________

From report at bugs.python.org  Thu Feb 17 13:13:33 2022
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Feb 2022 18:13:33 +0000
Subject: [issue46780] Allow Fractions to return 1/6 for "0.17", "0.167",
 "0.1667", etc.
In-Reply-To: <1645118854.48.0.835738770183.issue46780@roundup.psfhosted.org>
Message-ID: <1645121613.1.0.890735737699.issue46780@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Sigh:

> the next representable value up from 0.01 is 0.011

should say:

> the next representable value up from 0.10 is 0.11

I think I'll duck out and give my brain a rest before commenting further.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46780>
_______________________________________

From report at bugs.python.org  Thu Feb 17 13:37:45 2022
From: report at bugs.python.org (Hossein)
Date: Thu, 17 Feb 2022 18:37:45 +0000
Subject: [issue46783] Add a new feature to enumerate(iterable,
 start=0) built-in function
Message-ID: <1645123065.19.0.230809388528.issue46783@roundup.psfhosted.org>


New submission from Hossein <ranjbari.hossein9945 at gmail.com>:

Hi everyone. I have an idea which is add a new feature to enumerate(iterable, start=0) built-in function. I mean, "start" is ascending by default, we can add a feature to this function to change start in descending order.
for example:
enumerate(iterable, start=100, reverse=True)
reverse: If True, the start is reversed.
(100, iterable[0]), (99, iterable[1],), and so on.

----------
assignee: docs at python
components: Argument Clinic, Build, Demos and Tools, Documentation, Interpreter Core, Parser
messages: 413428
nosy: HosseinRanjbari, docs at python, larry, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Add a new feature to enumerate(iterable, start=0) built-in function
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46783>
_______________________________________

From report at bugs.python.org  Thu Feb 17 13:38:31 2022
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 17 Feb 2022 18:38:31 +0000
Subject: [issue46783] Add a new feature to enumerate(iterable,
 start=0) built-in function
In-Reply-To: <1645123065.19.0.230809388528.issue46783@roundup.psfhosted.org>
Message-ID: <1645123111.7.0.118331990595.issue46783@roundup.psfhosted.org>


Change by Larry Hastings <larry at hastings.org>:


----------
components:  -Argument Clinic
nosy:  -larry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46783>
_______________________________________

From report at bugs.python.org  Thu Feb 17 13:39:19 2022
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 17 Feb 2022 18:39:19 +0000
Subject: [issue46783] Add a new feature to enumerate(iterable,
 start=0) built-in function
In-Reply-To: <1645123065.19.0.230809388528.issue46783@roundup.psfhosted.org>
Message-ID: <1645123159.59.0.213412896928.issue46783@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

This has nothing to do with the parser so I'm removing the label. Please, next time make sure you select the appropriate categories when opening an issue

----------
components:  -Parser

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46783>
_______________________________________

From report at bugs.python.org  Thu Feb 17 13:40:04 2022
From: report at bugs.python.org (Lee Newberg)
Date: Thu, 17 Feb 2022 18:40:04 +0000
Subject: [issue46780] Allow Fractions to return 1/6 for "0.17", "0.167",
 "0.1667", etc.
In-Reply-To: <1645118854.48.0.835738770183.issue46780@roundup.psfhosted.org>
Message-ID: <1645123204.07.0.178037638926.issue46780@roundup.psfhosted.org>


Lee Newberg <github at quantconsulting.com> added the comment:

>This sounds interesting, but also rather similar to what the `limit_denominator` method can get you. 

`Fractions("0.17").limit_denominator()` and `Fractions("0.17").limit_denominator(n)`
for n > 28 do not give 1/6.  So, I'd have to guess at n until I get 1/6.  Instead, I'd like to have the digits actually presented "0.17" determine the interval [0.165, 0.175) which then determines the fraction.

In particular, "0.170" would give a different answer ... a fraction within [0.1695, 0.1705).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46780>
_______________________________________

From report at bugs.python.org  Thu Feb 17 13:41:07 2022
From: report at bugs.python.org (Steve Dower)
Date: Thu, 17 Feb 2022 18:41:07 +0000
Subject: [issue46778] Enable parallel compilation on Windows builds
In-Reply-To: <1645115050.56.0.993068912752.issue46778@roundup.psfhosted.org>
Message-ID: <1645123267.6.0.736377244283.issue46778@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Easy, and thanks for the PR!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46778>
_______________________________________

From report at bugs.python.org  Thu Feb 17 13:41:09 2022
From: report at bugs.python.org (Steve Dower)
Date: Thu, 17 Feb 2022 18:41:09 +0000
Subject: [issue46778] Enable parallel compilation on Windows builds
In-Reply-To: <1645115050.56.0.993068912752.issue46778@roundup.psfhosted.org>
Message-ID: <1645123269.29.0.318370388276.issue46778@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 98dd0aec2d0cb8971fb5363532c25041a5ba6fdc by Jeremy Kloth in branch 'main':
bpo-46778: Enable multiprocess compilation for source files when building on Windows (GH-31390)
https://github.com/python/cpython/commit/98dd0aec2d0cb8971fb5363532c25041a5ba6fdc


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46778>
_______________________________________

From report at bugs.python.org  Thu Feb 17 13:41:43 2022
From: report at bugs.python.org (Lee Newberg)
Date: Thu, 17 Feb 2022 18:41:43 +0000
Subject: [issue46780] Allow Fractions to return 1/6 for "0.17", "0.167",
 "0.1667", etc.
In-Reply-To: <1645118854.48.0.835738770183.issue46780@roundup.psfhosted.org>
Message-ID: <1645123303.9.0.123029642435.issue46780@roundup.psfhosted.org>


Lee Newberg <github at quantconsulting.com> added the comment:

>It would return 1/7 for "0.1" and 1/4 for "0.2". Is it what you expected?

Yes.  Or putting it another way, if that's not the right answer then whoever rounded the number should have retained more digits.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46780>
_______________________________________

From report at bugs.python.org  Thu Feb 17 13:43:09 2022
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 17 Feb 2022 18:43:09 +0000
Subject: [issue46783] Add a new feature to enumerate(iterable,
 start=0) built-in function
In-Reply-To: <1645123065.19.0.230809388528.issue46783@roundup.psfhosted.org>
Message-ID: <1645123389.89.0.322022654222.issue46783@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
assignee: docs at python -> 
components: +Library (Lib) -Build, Demos and Tools, Documentation, Interpreter Core
nosy:  -docs at python, lys.nikolaou
versions:  -Python 3.10, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46783>
_______________________________________

From report at bugs.python.org  Thu Feb 17 13:44:20 2022
From: report at bugs.python.org (Lee Newberg)
Date: Thu, 17 Feb 2022 18:44:20 +0000
Subject: [issue46780] Allow Fractions to return 1/6 for "0.17", "0.167",
 "0.1667", etc.
In-Reply-To: <1645118854.48.0.835738770183.issue46780@roundup.psfhosted.org>
Message-ID: <1645123460.45.0.473447213098.issue46780@roundup.psfhosted.org>


Lee Newberg <github at quantconsulting.com> added the comment:

> depending on which rounding mode was used (round-ties-to-even, round-ties-to-away), the interval may be half-open, open or closed.

I think we will get the majority of the use cases if we pick one rounding strategy and stick with it.  In later version we could support more if we found the demand: in addition to assume_rounded=True we could allow assume_rounded="round_towards_zero", etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46780>
_______________________________________

From report at bugs.python.org  Thu Feb 17 13:46:30 2022
From: report at bugs.python.org (Lee Newberg)
Date: Thu, 17 Feb 2022 18:46:30 +0000
Subject: [issue46780] Allow Fractions to return 1/6 for "0.17", "0.167",
 "0.1667", etc.
In-Reply-To: <1645118854.48.0.835738770183.issue46780@roundup.psfhosted.org>
Message-ID: <1645123590.38.0.765205325396.issue46780@roundup.psfhosted.org>


Lee Newberg <github at quantconsulting.com> added the comment:

> For another problematic example, suppose the string supplied is "0.10"

We would treat "0.1", "0.10", "0.100", etc. all differently.  In all cases we would assume rounding to compute the last digit.  Similarly for "3e-10", "3.0e-10" == "30e-11", "3.00e-11", etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46780>
_______________________________________

From report at bugs.python.org  Thu Feb 17 13:48:53 2022
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Feb 2022 18:48:53 +0000
Subject: [issue46780] Allow Fractions to return 1/6 for "0.17", "0.167",
 "0.1667", etc.
In-Reply-To: <1645118854.48.0.835738770183.issue46780@roundup.psfhosted.org>
Message-ID: <1645123733.32.0.392123174933.issue46780@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

One more example: what interval is implied by an input string of "1600"? Is it (1550, 1650)? Or (1595, 1605)? Or even (1599.5, 1600.5).

Sorry, I just don't see this working - there are two many arbitrary choices involved in guessing what interval the user intended. Much better to require the user to give that interval directly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46780>
_______________________________________

From report at bugs.python.org  Thu Feb 17 13:51:12 2022
From: report at bugs.python.org (Lee Newberg)
Date: Thu, 17 Feb 2022 18:51:12 +0000
Subject: [issue46780] Allow Fractions to return 1/6 for "0.17", "0.167",
 "0.1667", etc.
In-Reply-To: <1645118854.48.0.835738770183.issue46780@roundup.psfhosted.org>
Message-ID: <1645123872.52.0.392846931606.issue46780@roundup.psfhosted.org>


Lee Newberg <github at quantconsulting.com> added the comment:

> You may be interested in the "simplefractions" module on PyPI, which solves the exact task "find the simplest fraction in a given interval".

I haven't seen that code and I am interested; I will take a look.  Perhaps code from there can be imported / incorporated in our implementation here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46780>
_______________________________________

From report at bugs.python.org  Thu Feb 17 13:55:35 2022
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Thu, 17 Feb 2022 18:55:35 +0000
Subject: [issue41028] Move docs.python.org language and version switcher out
 of cpython
In-Reply-To: <1592516133.76.0.0424010515361.issue41028@roundup.psfhosted.org>
Message-ID: <1645124135.58.0.032704232559.issue41028@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:


New changeset 4c48cac1c44fbbfe3f5fd0c623b7768e2a709da8 by Miss Islington (bot) in branch '3.8':
bpo-41028: Doc: Move switchers to docsbuild-scripts. (GH-20969) (GH-30344)
https://github.com/python/cpython/commit/4c48cac1c44fbbfe3f5fd0c623b7768e2a709da8


----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41028>
_______________________________________

From report at bugs.python.org  Thu Feb 17 13:57:23 2022
From: report at bugs.python.org (Lee Newberg)
Date: Thu, 17 Feb 2022 18:57:23 +0000
Subject: [issue46780] Allow Fractions to return 1/6 for "0.17", "0.167",
 "0.1667", etc.
In-Reply-To: <1645118854.48.0.835738770183.issue46780@roundup.psfhosted.org>
Message-ID: <1645124243.0.0.890023894684.issue46780@roundup.psfhosted.org>


Lee Newberg <github at quantconsulting.com> added the comment:

> One more example: what interval is implied by an input string of "1600"? Is it (1550, 1650)? Or (1595, 1605)? Or even (1599.5, 1600.5).

The rule would be to look at the last digit supplied and assume that the rounding is there.  So "1600" gives [1599.5, 1600.5) and "16e2" gives [1550, 1650).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46780>
_______________________________________

From report at bugs.python.org  Thu Feb 17 14:03:32 2022
From: report at bugs.python.org (Lee Newberg)
Date: Thu, 17 Feb 2022 19:03:32 +0000
Subject: [issue46780] Allow Fractions to return 1/6 for "0.17", "0.167",
 "0.1667", etc.
In-Reply-To: <1645118854.48.0.835738770183.issue46780@roundup.psfhosted.org>
Message-ID: <1645124612.06.0.240840687352.issue46780@roundup.psfhosted.org>


Lee Newberg <github at quantconsulting.com> added the comment:

The example of "16e2" would yield the interval [1550, 1650).  The smallest denominator possible is 1.  The smallest numerator that works with that denominator is 1550, but I don't like 1550/1 as the answer.

To cover these edge cases, I'd modify the optimization to be that we continue to seek the smallest denominator, but in the case that multiple numerators would give ratios within the computed interval then we choose the numerator among these that gives the ratio closest to the input value.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46780>
_______________________________________

From report at bugs.python.org  Thu Feb 17 14:07:21 2022
From: report at bugs.python.org (Lee Newberg)
Date: Thu, 17 Feb 2022 19:07:21 +0000
Subject: [issue46780] Allow Fractions to return 1/6 for "0.17", "0.167",
 "0.1667", etc.
In-Reply-To: <1645118854.48.0.835738770183.issue46780@roundup.psfhosted.org>
Message-ID: <1645124841.29.0.590286274359.issue46780@roundup.psfhosted.org>


Lee Newberg <github at quantconsulting.com> added the comment:

>It would return 1/7 for "0.1" and 1/4 for "0.2". Is it what you expected?

I answered "yes" before, but I am now thinking "no".  In the case of "0.1", the smallest numerator achievable is 1, but there are multiple denominators that would give a value within [0.05, 0.15).  So, I'd choose the denominator that gives the ratio that is closet to the input value.

This is similar to the "16e2" example but with the roles of numerator and denominator reversed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46780>
_______________________________________

From report at bugs.python.org  Thu Feb 17 14:08:20 2022
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Feb 2022 19:08:20 +0000
Subject: [issue46780] Allow Fractions to return 1/6 for "0.17", "0.167",
 "0.1667", etc.
In-Reply-To: <1645118854.48.0.835738770183.issue46780@roundup.psfhosted.org>
Message-ID: <1645124900.26.0.851176175687.issue46780@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I'd modify the optimization to be that we continue to seek the smallest denominator, but in the case that multiple numerators would give ratios within the computed interval then we choose the numerator among these that gives the ratio closest to the input value.

Hmm. This is getting more DWIM-like (Do What I Mean) by the minute. :-)

What about for an input of "0.001"? Your current specification would give 1/667, but I'm betting that you'd actually prefer 1/1000.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46780>
_______________________________________

From report at bugs.python.org  Thu Feb 17 14:09:32 2022
From: report at bugs.python.org (Lee Newberg)
Date: Thu, 17 Feb 2022 19:09:32 +0000
Subject: [issue46780] Allow Fractions to return 1/6 for "0.17", "0.167",
 "0.1667", etc.
In-Reply-To: <1645118854.48.0.835738770183.issue46780@roundup.psfhosted.org>
Message-ID: <1645124972.41.0.299206967924.issue46780@roundup.psfhosted.org>


Lee Newberg <github at quantconsulting.com> added the comment:

> What about for an input of "0.001"? Your current specification would give 1/667, but I'm betting that you'd actually prefer 1/1000.

You would win that bet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46780>
_______________________________________

From report at bugs.python.org  Thu Feb 17 14:13:51 2022
From: report at bugs.python.org (Matthias Urlichs)
Date: Thu, 17 Feb 2022 19:13:51 +0000
Subject: [issue46781] Tracing: c_return doesn't report the result
In-Reply-To: <1645121302.3.0.866413840913.issue46781@roundup.psfhosted.org>
Message-ID: <1645125231.19.0.66751860351.issue46781@roundup.psfhosted.org>


Matthias Urlichs <matthias at urlichs.de> added the comment:

Likewise for c_exception, which should report the exception thruple -- and even has an XXX comment reminding us to fix that (ceval.c 4542).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46781>
_______________________________________

From report at bugs.python.org  Thu Feb 17 14:27:39 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 17 Feb 2022 19:27:39 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645126059.7.0.0140710117323.issue46771@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Lots of food for thought! There seem to be mostly two discussions: API design for the new asyncio cancel scopes (do we make it more like Trio or more like async-timeout?); and cancel semantics in edge cases.

I'll pass on the API design for now: I recommend that Tin and Andrew agree on some middle ground first. (Personally I could do without move_on(), I'd just add a try/except TimeoutError.)

On the cancel edge case, I am beginning to warm up to (ab)using the existing cancel message hack, rather than a separate nonce. I think the message argument could be the cancel scope or its id().

I think Andrew missed one case: in his second diagram, what if the explicit cancel() happened *after* the timeout (but still in the same iteration)? That's the case that makes me want to delete those two lines from Task.cancel() (see my earlier message).

(Sorry, I've gotta go play now.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Thu Feb 17 14:27:53 2022
From: report at bugs.python.org (Dennis Sweeney)
Date: Thu, 17 Feb 2022 19:27:53 +0000
Subject: [issue46730] Please consider mentioning property without setter when
 an attribute can't be set
In-Reply-To: <1644664548.7.0.814482728123.issue46730@roundup.psfhosted.org>
Message-ID: <1645126073.72.0.77260957886.issue46730@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:


New changeset 9e06d03672547041239812efe4901c06da6cbd2f by Christian Heimes in branch 'main':
bpo-46730: Fix refleak and tighten NULL checks (GH-31389)
https://github.com/python/cpython/commit/9e06d03672547041239812efe4901c06da6cbd2f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46730>
_______________________________________

From report at bugs.python.org  Thu Feb 17 14:46:14 2022
From: report at bugs.python.org (Batuhan Taskaya)
Date: Thu, 17 Feb 2022 19:46:14 +0000
Subject: [issue29418] inspect.isroutine does not return True for some bound
 builtin methods
In-Reply-To: <1486027973.42.0.383629669841.issue29418@psf.upfronthosting.co.za>
Message-ID: <1645127174.97.0.796452019732.issue29418@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:


New changeset 02815d939362d4093a95da650e7fbddabf147eb0 by Hakan ?elik in branch 'main':
bpo-29418: Add inspect.ismethodwrapper to whatsnew (GH-31377)
https://github.com/python/cpython/commit/02815d939362d4093a95da650e7fbddabf147eb0


----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29418>
_______________________________________

From report at bugs.python.org  Thu Feb 17 14:49:31 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 17 Feb 2022 19:49:31 +0000
Subject: [issue46783] Add a new feature to enumerate(iterable,
 start=0) built-in function
In-Reply-To: <1645123065.19.0.230809388528.issue46783@roundup.psfhosted.org>
Message-ID: <1645127371.9.0.626903714393.issue46783@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thank you for the suggestion, but we will decline.  We looked at this before and decided not to go down this path, preferring instead to the keep the builtin function simple and focused on its core task of enumeration.

To cover the rarer cases, it is a simple matter to fulfill the need with fast, clear code using itertools:

>>> from itertools import count
>>> names = ['eddard', 'catelyn', 'robb', 'sansa', 'arya', 'bram', 'rickon']
>>> for i, name in zip(count(start=7, step=-1), names):
        print(i, name)

7 eddard
6 catelyn
5 robb
4 sansa
3 arya
2 bram
1 rickon

----------
assignee:  -> rhettinger
nosy: +rhettinger
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46783>
_______________________________________

From report at bugs.python.org  Thu Feb 17 14:53:35 2022
From: report at bugs.python.org (Cyril Jouve)
Date: Thu, 17 Feb 2022 19:53:35 +0000
Subject: [issue46770] ConfigParser(dict_type=) not behaving as expected
In-Reply-To: <1645031843.76.0.82823546709.issue46770@roundup.psfhosted.org>
Message-ID: <1645127615.78.0.183817519155.issue46770@roundup.psfhosted.org>


Cyril Jouve <jv.cyril at gmail.com> added the comment:

you need to pass `strict=False` to ConfigParser :


        When `strict` is True, the parser won't allow for any section or option
        duplicates while reading from a single source (file, string or
        dictionary). Default is True.

----------
nosy: +Cyril Jouve

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46770>
_______________________________________

From report at bugs.python.org  Thu Feb 17 15:02:42 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 17 Feb 2022 20:02:42 +0000
Subject: [issue46764] Wrapping a bound method with a @classmethod no longer
 works
In-Reply-To: <1644976589.23.0.130675982792.issue46764@roundup.psfhosted.org>
Message-ID: <1645128162.06.0.0982532571903.issue46764@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

This seems like a reasonable fix.  I'll wait a bit so that others can comment as well.

FWIW, we looking a potentially reverting the whole line of development starting with that commit.  It has caused a number of problems and no longer looks tenable.  See https://bugs.python.org/issue45356

----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46764>
_______________________________________

From report at bugs.python.org  Thu Feb 17 15:03:40 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 17 Feb 2022 20:03:40 +0000
Subject: [issue45356] Calling `help` executes @classmethod @property decorated
 methods
In-Reply-To: <1633290355.98.0.210301350099.issue45356@roundup.psfhosted.org>
Message-ID: <1645128220.35.0.392860964714.issue45356@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

See also: https://bugs.python.org/issue46764

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45356>
_______________________________________

From report at bugs.python.org  Thu Feb 17 15:11:00 2022
From: report at bugs.python.org (Matthias Urlichs)
Date: Thu, 17 Feb 2022 20:11:00 +0000
Subject: [issue46781] Tracing: c_return doesn't report the result
In-Reply-To: <1645121302.3.0.866413840913.issue46781@roundup.psfhosted.org>
Message-ID: <1645128660.55.0.376370116977.issue46781@roundup.psfhosted.org>


Change by Matthias Urlichs <matthias at urlichs.de>:


----------
keywords: +patch
pull_requests: +29537
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31393

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46781>
_______________________________________

From report at bugs.python.org  Thu Feb 17 15:24:20 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 17 Feb 2022 20:24:20 +0000
Subject: [issue46780] Allow Fractions to return 1/6 for "0.17", "0.167",
 "0.1667", etc.
In-Reply-To: <1645118854.48.0.835738770183.issue46780@roundup.psfhosted.org>
Message-ID: <1645129460.25.0.540490429443.issue46780@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I don't think the standard library should go down this path.  

Mark's disinclinations all make sense to me, but I'm also concerned that the API would be almost unusable in practical situations.  Users would tend to know their input fraction and that they have a desire for "simplification", but it would be challenging for them to come with a surrounding interval that made sense.  We could attempt to infer an interval from the input, but a user is likely to have a poorly specified idea of what they actually want.  The operating principle here is, "refuse the temptation to guess".

Here's a little exercise for the API.  The 12 semitones in an octave are separated by a frequency ratio of 2**(1/12).  For example, if A is 440 Hz, then A# is 440*2**(1/12) = 466.16 Hz.  Note pairs sound the most harmonious when the ratio of their frequencies is a "near" a small fraction.  Determine the small fraction for each of the twelve notes.  For example, a perfect fifth has the frequency ratio of 2**(7/12) -> 1.498307 ? it it "perfect" because it "close-enough" to the small integer ratio of 3 : 2.  Notice the vague requirements of "near", "close-enough" and "small integer ratio".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46780>
_______________________________________

From report at bugs.python.org  Thu Feb 17 15:25:33 2022
From: report at bugs.python.org (Matthias Urlichs)
Date: Thu, 17 Feb 2022 20:25:33 +0000
Subject: [issue46781] Tracing: c_return doesn't report the result
In-Reply-To: <1645121302.3.0.866413840913.issue46781@roundup.psfhosted.org>
Message-ID: <1645129533.31.0.643121332007.issue46781@roundup.psfhosted.org>


Matthias Urlichs <matthias at urlichs.de> added the comment:

Added a github PR. Unfortunately it breaks the cprofile testcase, which apparently relies on the old argument value (for no good reason IMHO).

I don't know how the profiler works internally. If somebody who does could have a look at it and/or its testcase I'd be grateful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46781>
_______________________________________

From report at bugs.python.org  Thu Feb 17 15:31:11 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 17 Feb 2022 20:31:11 +0000
Subject: [issue46780] Allow Fractions to return 1/6 for "0.17", "0.167",
 "0.1667", etc.
In-Reply-To: <1645118854.48.0.835738770183.issue46780@roundup.psfhosted.org>
Message-ID: <1645129871.39.0.715949272959.issue46780@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Also note for the music example that the notion of "near enough" isn't equidistant about the "simple fraction".  The sense of nearness is logarithmic and is measured in "cents" which are hundredths of an equal-tempered semitone (i.e a one octave consists of 1200 cents).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46780>
_______________________________________

From report at bugs.python.org  Thu Feb 17 15:58:48 2022
From: report at bugs.python.org (Mark Lonnemann)
Date: Thu, 17 Feb 2022 20:58:48 +0000
Subject: [issue46770] ConfigParser(dict_type=) not behaving as expected
In-Reply-To: <1645031843.76.0.82823546709.issue46770@roundup.psfhosted.org>
Message-ID: <1645131528.62.0.988918055781.issue46770@roundup.psfhosted.org>


Mark Lonnemann <mlonnemann at msn.com> added the comment:

I know, thanks though.  I just thought there was a way to do it via dict_type=.  I've read it can be done, but is complex.  I've yet to see any examples of how.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46770>
_______________________________________

From report at bugs.python.org  Thu Feb 17 16:51:26 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 17 Feb 2022 21:51:26 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645134686.52.0.56329831698.issue46771@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
pull_requests: +29539
pull_request: https://github.com/python/cpython/pull/31394

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Thu Feb 17 16:58:12 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 17 Feb 2022 21:58:12 +0000
Subject: [issue46400] Please update bundled libexpat to 2.4.4 with security
 fixes (CVE-2021-45960)
In-Reply-To: <1642350760.98.0.31451148779.issue46400@roundup.psfhosted.org>
Message-ID: <1645135092.83.0.252018594425.issue46400@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:


New changeset cb7551d5663f35c6993f3c6d8e361bc73f1c43d4 by Dong-hee Na in branch '3.10':
bpo-46400: Update libexpat from 2.4.1 to 2.4.4 (GH-31022) (GH-31296)
https://github.com/python/cpython/commit/cb7551d5663f35c6993f3c6d8e361bc73f1c43d4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46400>
_______________________________________

From report at bugs.python.org  Thu Feb 17 16:58:29 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 17 Feb 2022 21:58:29 +0000
Subject: [issue46400] Please update bundled libexpat to 2.4.4 with security
 fixes (CVE-2021-45960)
In-Reply-To: <1642350760.98.0.31451148779.issue46400@roundup.psfhosted.org>
Message-ID: <1645135109.72.0.110142326605.issue46400@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:


New changeset e7828904f39588dad438c5d341a31e72e9cb1775 by Miss Islington (bot) in branch '3.9':
bpo-46400: Update libexpat from 2.4.1 to 2.4.4 (GH-31022) (GH-31295)
https://github.com/python/cpython/commit/e7828904f39588dad438c5d341a31e72e9cb1775


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46400>
_______________________________________

From report at bugs.python.org  Thu Feb 17 17:02:56 2022
From: report at bugs.python.org (Lee Newberg)
Date: Thu, 17 Feb 2022 22:02:56 +0000
Subject: [issue46780] Allow Fractions to return 1/6 for "0.17", "0.167",
 "0.1667", etc.
In-Reply-To: <1645118854.48.0.835738770183.issue46780@roundup.psfhosted.org>
Message-ID: <1645135376.49.0.694713196455.issue46780@roundup.psfhosted.org>


Lee Newberg <github at quantconsulting.com> added the comment:

> The 12 semitones in an octave are separated ...

Right, this functionality would not solve the semitones / cents problem.  Nor will it achieve world peace.  But if it solves enough use cases then it is worth discussing, yes?

I haven't written the string parsing, but once we know that "0.001" means to look in [0.0005, 0.0015) then we can invoke the attached as best_fraction(Fraction("0.001"), Fraction("0.0005"), Fraction("0.0015")) to get the output Fraction(1, 1000).

----------
Added file: https://bugs.python.org/file50627/best_fraction.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46780>
_______________________________________

From report at bugs.python.org  Thu Feb 17 17:12:11 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 17 Feb 2022 22:12:11 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645135931.36.0.307031083586.issue46771@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

https://github.com/python/cpython/pull/31394 is created for collaboration , Tin Tvrtkovi? is invited.
Core devs should have the write access already.
Non-core devs, please ask for github invite if you want to collaborate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Thu Feb 17 17:20:19 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 17 Feb 2022 22:20:19 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645136419.27.0.987701472751.issue46771@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

The PR is pretty empty, it has a scaffolding for `asyncio.timeouts` module and its test only. I'll try to add something real tomorrow.

My plan is:
- solve 'easy' questions with Tin during PR's discussion/reviews
- make something that we are both agree on if it is possible at this stage. I'm optimistic, seems like we both are able to compromise (and have the experience to work together on pytest-asyncio project).
- raise a hard question loudly if discussion on GitHub will need more people (participation in early stages are welcome, sure).

> I think Andrew missed one case: in his second diagram, what if the explicit cancel() happened *after* the timeout (but still in the same iteration)? That's the case that makes me want to delete those two lines from Task.cancel() (see my earlier message).

Please let me write a comprehensive answer (with a third diagram, I've found these simple pictures useful) tomorrow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Thu Feb 17 17:53:07 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 17 Feb 2022 22:53:07 +0000
Subject: [issue45099] asyncio.Task's documentation says that loop arg is
 removed when it's not
In-Reply-To: <1630775028.47.0.984741146051.issue45099@roundup.psfhosted.org>
Message-ID: <1645138387.53.0.713795059124.issue45099@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

I have a feeling that we need a low-level API section that describes *supported* API that is intended to task extenders only (guys who want to provide an alternative task factory for example).

I love to contribute but not sure when I can find time for this docs change. Please feel free to provide a pull request.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45099>
_______________________________________

From report at bugs.python.org  Thu Feb 17 18:29:30 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 17 Feb 2022 23:29:30 +0000
Subject: [issue46780] Allow Fractions to return 1/6 for "0.17", "0.167",
 "0.1667", etc.
In-Reply-To: <1645118854.48.0.835738770183.issue46780@roundup.psfhosted.org>
Message-ID: <1645140570.57.0.432112907455.issue46780@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

>  Nor will it achieve world peace.

Please watch the tone. It is borderline abusive and dismissive.

> we can invoke the attached as best_fraction(Fraction("0.001"),
> Fraction("0.0005"), Fraction("0.0015")) to get the output
> Fraction(1, 1000).

-1 I am solidly against this.  The other inputs to Fraction() are exact conversions.  The proposal works against a core concept behind the fraction module. 

Also, my expectation for Fraction("0.0015") would be to give Fraction(3, 2000), the same as would be given by Fraction(Decimal("0.0015")).

> But if it solves enough use cases then it is worth discussing, yes?

Perhaps this tracker issue should be closed and moved to python-ideas.  The notions are currently too immature to warrant more core developer time.

Also, it would be nice to have research into what other languages and libraries do for fractional approximations of decimal strings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46780>
_______________________________________

From report at bugs.python.org  Thu Feb 17 18:35:46 2022
From: report at bugs.python.org (Yilei Yang)
Date: Thu, 17 Feb 2022 23:35:46 +0000
Subject: [issue46784] Duplicated symbols when linking embedded Python with
 libexpat
Message-ID: <1645140945.97.0.0561003008604.issue46784@roundup.psfhosted.org>


New submission from Yilei Yang <yileiyang9 at gmail.com>:

The libexpat 2.4.1 upgrade from https://bugs.python.org/issue44394 introduced the following new exported symbols:

testingAccountingGetCountBytesDirect
testingAccountingGetCountBytesIndirect
unsignedCharToPrintable
XML_SetBillionLaughsAttackProtectionActivationThreshold
XML_SetBillionLaughsAttackProtectionMaximumAmplification

We need to adjust Modules/expat/pyexpatns.h

(The newer libexpat upgrade https://bugs.python.org/issue46400 has no new symbols).

I'll send a PR.

----------
components: XML
messages: 413464
nosy: yilei
priority: normal
severity: normal
status: open
title: Duplicated symbols when linking embedded Python with libexpat
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46784>
_______________________________________

From report at bugs.python.org  Thu Feb 17 18:41:02 2022
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 17 Feb 2022 23:41:02 +0000
Subject: [issue46784] Duplicated symbols when linking embedded Python with
 libexpat
In-Reply-To: <1645140945.97.0.0561003008604.issue46784@roundup.psfhosted.org>
Message-ID: <1645141262.62.0.663521703371.issue46784@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46784>
_______________________________________

From report at bugs.python.org  Thu Feb 17 18:47:18 2022
From: report at bugs.python.org (Yilei Yang)
Date: Thu, 17 Feb 2022 23:47:18 +0000
Subject: [issue46784] Duplicated symbols when linking embedded Python with
 libexpat
In-Reply-To: <1645140945.97.0.0561003008604.issue46784@roundup.psfhosted.org>
Message-ID: <1645141638.18.0.438557019435.issue46784@roundup.psfhosted.org>


Change by Yilei Yang <yileiyang9 at gmail.com>:


----------
keywords: +patch
pull_requests: +29540
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31397

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46784>
_______________________________________

From report at bugs.python.org  Thu Feb 17 18:58:33 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 17 Feb 2022 23:58:33 +0000
Subject: [issue46752] Introduce task groups to asyncio and change task
 cancellation semantics
In-Reply-To: <1644871469.64.0.38816696304.issue46752@roundup.psfhosted.org>
Message-ID: <1645142313.73.0.434854959483.issue46752@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
pull_requests: +29541
pull_request: https://github.com/python/cpython/pull/31398

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46752>
_______________________________________

From report at bugs.python.org  Thu Feb 17 18:58:33 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 17 Feb 2022 23:58:33 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645142313.85.0.236545854999.issue46771@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
pull_requests: +29542
pull_request: https://github.com/python/cpython/pull/31398

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Thu Feb 17 19:22:52 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 18 Feb 2022 00:22:52 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645143772.73.0.971033648324.issue46771@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

+1 on both aspects of the plan.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Thu Feb 17 23:36:48 2022
From: report at bugs.python.org (Ned Deily)
Date: Fri, 18 Feb 2022 04:36:48 +0000
Subject: [issue46784] Duplicated symbols when linking embedded Python with
 libexpat
In-Reply-To: <1645140945.97.0.0561003008604.issue46784@roundup.psfhosted.org>
Message-ID: <1645159008.32.0.233830454582.issue46784@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46784>
_______________________________________

From report at bugs.python.org  Thu Feb 17 23:54:22 2022
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 18 Feb 2022 04:54:22 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645160062.88.0.64962446632.issue46771@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Couple thoughts:

I'm +1 for adding TaskGroup.cancel() method.

I'd be -1 on abusing `Task.cancel()` to signal something with a nonce. Whatever problem we are trying to solve here, it should be solvable without resorting to hacks like this. It should be trivial to implement simple tracking of whether a child task was cancelled by the group or not to decide on how to handle a rogue CancelledError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Fri Feb 18 00:30:59 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 18 Feb 2022 05:30:59 +0000
Subject: [issue46752] Introduce task groups to asyncio and change task
 cancellation semantics
In-Reply-To: <1644871469.64.0.38816696304.issue46752@roundup.psfhosted.org>
Message-ID: <1645162259.0.0.655083406269.issue46752@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset d85121660ea50bbe8fbd31797aa6e4afe0850388 by Guido van Rossum in branch 'main':
bpo-46752: Slight improvements to TaskGroup API (GH-31398)
https://github.com/python/cpython/commit/d85121660ea50bbe8fbd31797aa6e4afe0850388


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46752>
_______________________________________

From report at bugs.python.org  Fri Feb 18 03:50:37 2022
From: report at bugs.python.org (Antony Lee)
Date: Fri, 18 Feb 2022 08:50:37 +0000
Subject: [issue46785] On Windows,
 os.stat() can fail if called while another process is creating or
 deleting the file
Message-ID: <1645174237.48.0.436213701589.issue46785@roundup.psfhosted.org>


New submission from Antony Lee <anntzer.lee at gmail.com>:

In a first Python process, repeatedly create and delete a file:

from pathlib import Path
while True:
    Path("foo").touch(); Path("foo").unlink()

In another process, repeatedly check for the path's existence:

from pathlib import Path
while True: print(Path("foo").exists())

On Linux, the second process prints a random series of True and False.  On Windows, it quickly fails after a few dozen iterations (likely machine-dependent) with

PermissionError: [WinError 5] Access is denied: 'foo'

which is actually raised by the stat() call.

I would suggest that this is not really desirable behavior?

----------
components: Windows
messages: 413468
nosy: Antony.Lee, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: On Windows, os.stat() can fail if called while another process is creating or deleting the file
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46785>
_______________________________________

From report at bugs.python.org  Fri Feb 18 03:59:02 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Feb 2022 08:59:02 +0000
Subject: [issue46777] Fix incorrect use of directives in asyncio documentation
In-Reply-To: <1645102456.61.0.455925245808.issue46777@roundup.psfhosted.org>
Message-ID: <1645174742.98.0.663164876538.issue46777@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: +29543
pull_request: https://github.com/python/cpython/pull/31403

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46777>
_______________________________________

From report at bugs.python.org  Fri Feb 18 03:59:19 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 18 Feb 2022 08:59:19 +0000
Subject: [issue46777] Fix incorrect use of directives in asyncio documentation
In-Reply-To: <1645102456.61.0.455925245808.issue46777@roundup.psfhosted.org>
Message-ID: <1645174759.26.0.908079000272.issue46777@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 2923d87ca258b9d421e8147b12f0d98295ee3f8e by Serhiy Storchaka in branch 'main':
bpo-46777: Fix incorrect use of directives in asyncio documentation (GH-31388)
https://github.com/python/cpython/commit/2923d87ca258b9d421e8147b12f0d98295ee3f8e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46777>
_______________________________________

From report at bugs.python.org  Fri Feb 18 04:30:53 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Feb 2022 09:30:53 +0000
Subject: [issue46777] Fix incorrect use of directives in asyncio documentation
In-Reply-To: <1645102456.61.0.455925245808.issue46777@roundup.psfhosted.org>
Message-ID: <1645176653.71.0.144792999761.issue46777@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 6eb34772fda2e46ba9a265e038b6e0f303bd790e by Miss Islington (bot) in branch '3.10':
bpo-46777: Fix incorrect use of directives in asyncio documentation (GH-31388)
https://github.com/python/cpython/commit/6eb34772fda2e46ba9a265e038b6e0f303bd790e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46777>
_______________________________________

From report at bugs.python.org  Fri Feb 18 04:52:04 2022
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 18 Feb 2022 09:52:04 +0000
Subject: [issue46780] Allow Fractions to return 1/6 for "0.17", "0.167",
 "0.1667", etc.
In-Reply-To: <1645118854.48.0.835738770183.issue46780@roundup.psfhosted.org>
Message-ID: <1645177924.69.0.324242031741.issue46780@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Okay, let's close here; as Raymond says, that doesn't prevent further discussion on python-ideas.

> The notions are currently too immature to warrant more core developer time.

Agreed. It seems that what Lee wants is some kind of blend between the simplest fraction and the closest fraction, and it's not clear exactly how that blend would work.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46780>
_______________________________________

From report at bugs.python.org  Fri Feb 18 04:56:31 2022
From: report at bugs.python.org (Mark Shannon)
Date: Fri, 18 Feb 2022 09:56:31 +0000
Subject: [issue46724] Odd Bytecode Generation in 3.10
In-Reply-To: <1644600146.24.0.968453673832.issue46724@roundup.psfhosted.org>
Message-ID: <1645178191.9.0.608781352144.issue46724@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset c3ce7781e3afe6f2dec5eef8e87fd5a664519ae9 by Saul Shanabrook in branch 'main':
bpo-46724: Fix dis support for overflow args (GH-31285)
https://github.com/python/cpython/commit/c3ce7781e3afe6f2dec5eef8e87fd5a664519ae9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46724>
_______________________________________

From report at bugs.python.org  Fri Feb 18 05:23:19 2022
From: report at bugs.python.org (jnns)
Date: Fri, 18 Feb 2022 10:23:19 +0000
Subject: [issue46786] embed, source, track,
 wbr HTML elements not considered empty
Message-ID: <1645179799.58.0.92424391054.issue46786@roundup.psfhosted.org>


New submission from jnns <jvajen at gmail.com>:

[According to the WHATWG][1], the elements `area`, `base`, `br`, `col`, `embed`, `hr`, `img`, `input`, `link`, `meta`, `param`, `source`, `track`, `wbr` are *void elements* that don't need and therefore shouldn't have a closing tag.

The source view of Firefox 96 shows a warning about an unexpected closing tag [1].

In Python 3.10.2 `xml.etree` seems to correctly recognize most of them as such and doesn't generate closing tags when using the `.tostring()` method. A few elements are serialized with a closing tag (`<embed></embed>` for example). 

```python
from xml.etree import ElementTree as etree

void_elements = [
    "area", "base","br", "col", "embed", "hr", "img", 
    "input", "link", "meta", "param", "source", "track", "wbr"
]
for el in void_elements:
    el = etree.Element(el)
    print(etree.tostring(el, method="html", encoding="unicode"))
```

```html
<area>
<base>
<br>
<col>
<embed></embed>
<hr>
<img>
<input>
<link>
<meta>
<param>
<source></source>
<track></track>
<wbr></wbr>
```

HTML_EMPTY in Lib/xml/etree/ElementTree.py only contains the following entries:

"area", "base", "basefont", "br", "col", "frame", "hr", "img", "input", "isindex", "link", "meta", "param"

I suppose "embed", "source", "track" and "wbr" should be added to that list.  

  [1]: https://html.spec.whatwg.org/multipage/syntax.html#void-elements
  [2]: https://i.stack.imgur.com/rBTHw.png

----------
components: XML
messages: 413473
nosy: jnns
priority: normal
severity: normal
status: open
title: embed, source, track, wbr HTML elements not considered empty
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46786>
_______________________________________

From report at bugs.python.org  Fri Feb 18 05:38:17 2022
From: report at bugs.python.org (=?utf-8?b?VsOhY2xhdiBCcm/FvsOtaw==?=)
Date: Fri, 18 Feb 2022 10:38:17 +0000
Subject: [issue45184] Add `pop` function to remove context manager from
 (Async)ExitStack
In-Reply-To: <1631544002.04.0.855227455654.issue45184@roundup.psfhosted.org>
Message-ID: <1645180697.75.0.258175670799.issue45184@roundup.psfhosted.org>


Change by V?clav Bro??k <vbrozik at gmail.com>:


----------
nosy: +vbrozik

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45184>
_______________________________________

From report at bugs.python.org  Fri Feb 18 05:40:45 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 18 Feb 2022 10:40:45 +0000
Subject: [issue46777] Fix incorrect use of directives in asyncio documentation
In-Reply-To: <1645102456.61.0.455925245808.issue46777@roundup.psfhosted.org>
Message-ID: <1645180845.4.0.104251111417.issue46777@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

> 6. The loop parameter of Task() was documented as both removed and required (if there is no current event loop) in 3.10.

I think we should drop Task() constructor definition from Task Object docs https://docs.python.org/3/library/asyncio-task.html#task-object but create 'asyncio-extending.rst' (suggest better name please) with low-level task documentation for guys who want to create their own task class.

Task constructor could be documented here along with `_register_task()`, `_enter_task()`, `_leave_task()`, `_unregister_task()`. They might be useful for ones who implements a custom task factories.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46777>
_______________________________________

From report at bugs.python.org  Fri Feb 18 05:57:37 2022
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Fri, 18 Feb 2022 10:57:37 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645181857.84.0.745336356573.issue46771@roundup.psfhosted.org>


Alex Gr?nholm <alex.gronholm at nextday.fi> added the comment:

I am also uncomfortable using the cancel message to deliver the token/nonce/whatever.

If TaskGroup.cancel() is implemented, would it also deliver a cancellation in the parent task like trio and AnyIO do? It should IMHO, because otherwise if the task group is cancelled, it could still get stuck waiting on whatever the parent task happens to be waiting on, if it's not at TaskGroup.__aexit__() yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Fri Feb 18 05:58:28 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Fri, 18 Feb 2022 10:58:28 +0000
Subject: [issue46709] test_urllib: testInterruptCaught() has a race condition
 and fails randomly
In-Reply-To: <1644494656.37.0.2113700788.issue46709@roundup.psfhosted.org>
Message-ID: <1645181908.14.0.483143743218.issue46709@roundup.psfhosted.org>


Change by Nikita Sobolev <mail at sobolevn.me>:


----------
pull_requests: +29544
pull_request: https://github.com/python/cpython/pull/31404

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46709>
_______________________________________

From report at bugs.python.org  Fri Feb 18 06:00:24 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Fri, 18 Feb 2022 11:00:24 +0000
Subject: [issue46465] Regression caused by CALL_FUNCTION specialization for C
 function calls (test_urllib fails when run multiple times)
In-Reply-To: <1642815009.1.0.251080855194.issue46465@roundup.psfhosted.org>
Message-ID: <1645182024.95.0.0523446293197.issue46465@roundup.psfhosted.org>


Change by Nikita Sobolev <mail at sobolevn.me>:


----------
nosy: +sobolevn
nosy_count: 7.0 -> 8.0
pull_requests: +29545
status: open -> pending
pull_request: https://github.com/python/cpython/pull/31404

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46465>
_______________________________________

From report at bugs.python.org  Fri Feb 18 06:00:44 2022
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 18 Feb 2022 11:00:44 +0000
Subject: [issue46785] On Windows,
 os.stat() can fail if called while another process is creating or
 deleting the file
In-Reply-To: <1645174237.48.0.436213701589.issue46785@roundup.psfhosted.org>
Message-ID: <1645182044.64.0.667681143691.issue46785@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

Windows filesystems disallow new opens for a file that has its delete disposition set (i.e. the file is marked for deletion). For example, CreateFileW() fails with ERROR_ACCESS_DENIED (5) in this case. A file with its delete disposition set is still visibly linked in its parent directory. 

The trigger to unlink a file that's marked for deletion depends on the delete mode. In Windows 10, DeleteFileW() uses a POSIX delete if it's supported by the filesystem (e.g. NTFS). This delete mode unlinks the file as soon the file object that was used to set the delete disposition is closed. There's still a small window of time, however, in which attempts to open the file will fail with an access-denied error.

In os.stat(), if CreateFileW() fails with access denied, FindFirstFileW() is called to try to get the stat data from the file's parent directory. But in this case it's likely that the file has been unlinked from the directory by the time FindFirstFileW() is called.

The original error code from CreateFileW() gets restored if FindFirstFileW() fails. This is generally the right thing to do. However, if FindFirstFileW() fails with ERROR_FILE_NOT_FOUND (2) or ERROR_PATH_NOT_FOUND (3), then I suggest that the previous error code should not be restored.

For example:

        switch (error) {
        case ERROR_ACCESS_DENIED:     /* Cannot sync or read attributes. */
        case ERROR_SHARING_VIOLATION: /* It's a paging file. */
            /* Try reading the parent directory. */
            if (!attributes_from_dir(path, &fileInfo, &tagInfo.ReparseTag)) {
                /* Cannot read the parent directory. */
                DWORD dir_error = GetLastError();
                if (dir_error != ERROR_FILE_NOT_FOUND &&
                      dir_error != ERROR_PATH_NOT_FOUND) {
                    SetLastError(error);
                }
                return -1;
            }

----------
nosy: +eryksun
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.11, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46785>
_______________________________________

From report at bugs.python.org  Fri Feb 18 06:08:40 2022
From: report at bugs.python.org (=?utf-8?b?VsOhY2xhdiBCcm/FvsOtaw==?=)
Date: Fri, 18 Feb 2022 11:08:40 +0000
Subject: [issue45184] Add `pop` function to remove context manager from
 (Async)ExitStack
In-Reply-To: <1631544002.04.0.855227455654.issue45184@roundup.psfhosted.org>
Message-ID: <1645182520.08.0.761514812023.issue45184@roundup.psfhosted.org>


V?clav Bro??k <vbrozik at gmail.com> added the comment:

There was an interesting discussion about this problem in 2015-12:
https://mail.python.org/archives/list/python-ideas at python.org/thread/Y3SLBJHJHAMBEZJWRXEJ5LE5JBVNE7XS/
(https://groups.google.com/g/python-ideas/c/l2FcErYbjfo - for the case the link above rots)

Certainly there are use cases for this functionality when you need to dynamically open multiple resources and close them when they are not needed any more. Keeping resources open till the very end of ExitStack is a bad practice which can lead to locking problems or overuse of resources.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45184>
_______________________________________

From report at bugs.python.org  Fri Feb 18 06:14:06 2022
From: report at bugs.python.org (jnns)
Date: Fri, 18 Feb 2022 11:14:06 +0000
Subject: [issue46786] embed, source, track,
 wbr HTML elements not considered empty
In-Reply-To: <1645179799.58.0.92424391054.issue46786@roundup.psfhosted.org>
Message-ID: <1645182846.39.0.289461562948.issue46786@roundup.psfhosted.org>


Change by jnns <jvajen at gmail.com>:


----------
keywords: +patch
pull_requests: +29546
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31406

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46786>
_______________________________________

From report at bugs.python.org  Fri Feb 18 06:52:09 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 18 Feb 2022 11:52:09 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645185129.97.0.773827898036.issue46771@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Guido, the third case:

The third edge case is: explicit cancel() happened *after* the timeout (but still in the
same iteration)?

   timeout  current-iteration (calls .cancel() after timeout)  next-iteration
     |                            |                                 |
 >---+----------------------------+---------------------------------+----------> future

  a) timeout occurs, `call_later()`' callback is called, the task cancellation is scheduled 
  on the next loop iteration by `task.cancel()` call
  b) other activity (e.g. socket-ready event that processed after timers in asyncio)
  explicitly calls `.cancel()`. The second request is ignored, `.cancel()` returns `False`.
  c) On the next iteration, the task wakes up with CancelledError with a message that points
  on the timeout context manager. 

It means that the timeout is processed, explicit `.cancel()` call that happens *after*
timeout is ignored. The first event wins, as usual.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Fri Feb 18 07:56:30 2022
From: report at bugs.python.org (Mark Shannon)
Date: Fri, 18 Feb 2022 12:56:30 +0000
Subject: [issue46709] test_urllib: testInterruptCaught() has a race condition
 and fails randomly
In-Reply-To: <1644494656.37.0.2113700788.issue46709@roundup.psfhosted.org>
Message-ID: <1645188990.81.0.753473467271.issue46709@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset e2c28616ce6c3cdb1013c415125220a0b86b86a1 by Nikita Sobolev in branch 'main':
bpo-46709: check eval breaker in specialized `CALL` opcodes (GH-31404)
https://github.com/python/cpython/commit/e2c28616ce6c3cdb1013c415125220a0b86b86a1


----------
nosy: +Mark.Shannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46709>
_______________________________________

From report at bugs.python.org  Fri Feb 18 08:06:09 2022
From: report at bugs.python.org (=?utf-8?q?Tin_Tvrtkovi=C4=87?=)
Date: Fri, 18 Feb 2022 13:06:09 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645189569.97.0.931402286792.issue46771@roundup.psfhosted.org>


Tin Tvrtkovi? <tinchester at gmail.com> added the comment:

Sure, I'll be glad to work with Andrew on getting something presentable.

Going through the discussion in the issue:

* it seems like folks don't think move_on is useful enough to be in the stdlib, I understand that point. Users can always catch the timeout error from `timeout`, and I can just keep `move_on` in Quattro. We can always add it later. So as far as I'm concerned we can drop it.
* `async with` vs `with`: if Andrew thinks `async with` is easier to teach and less error-prone, I'm ok with having the `async with` civilian version in the stdlib and I can keep the `with` expert versions in Quattro, no problem there.

So I'm most interested in the cancellation semantics, because those will be very hard to fix in a 3rd party package.

@Andrew, in your schema for the third case the behavior is wrong, the `.cancel()` should win over the timeout. Otherwise using the context manager becomes too risky in real-world situations. I also think your first graph has an issue if the user has a `try/except TimeoutError` between `timeout-a` and `timeout-b`, which is now more probable since we're dropping `move_on`. We can take the discussion to the forked repo; I can put together some tests if that would make it easier.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Fri Feb 18 08:12:51 2022
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Fri, 18 Feb 2022 13:12:51 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645189971.2.0.0142095896053.issue46771@roundup.psfhosted.org>


Alex Gr?nholm <alex.gronholm at nextday.fi> added the comment:

I propose the following, backwards compatible solution:

Add a new keyword argument to Task.cancel(): "scope: object = None".
The behavior would be as follows: the scope is saved, and included in the raised CancelledError. If Task.cancel() is called again, but with scope=None (the default), it clears out the saved scope, if any. Any other scope will be ignored.

This simple change would allow for proper implementation of any context manager that needs to swallow or transform a CancelledError raised in the task.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Fri Feb 18 08:49:35 2022
From: report at bugs.python.org (Lee Newberg)
Date: Fri, 18 Feb 2022 13:49:35 +0000
Subject: [issue46780] Allow Fractions to return 1/6 for "0.17", "0.167",
 "0.1667", etc.
In-Reply-To: <1645118854.48.0.835738770183.issue46780@roundup.psfhosted.org>
Message-ID: <1645192175.38.0.769489278225.issue46780@roundup.psfhosted.org>


Lee Newberg <github at quantconsulting.com> added the comment:

> Please watch the tone. It is borderline abusive and dismissive.

I apologize for the adverse impact there.  I will be more careful.

> Also, my expectation for Fraction("0.0015") would be to give Fraction(3, 2000), the same as would be given by Fraction(Decimal("0.0015")).

Yes, 0.0015 would be 3/2000.  However, in my example "0.0015" is the right endpoint of [0.0005, 0.0015), not the value "0.001" that we are seeking the fraction for.

> Perhaps this tracker issue should be closed and moved to python-ideas.  The notions are currently too immature to warrant more core developer time.

You have more experience with this than I.  I defer to you.

> Agreed. It seems that what Lee wants is some kind of blend between the simplest fraction and the closest fraction, and it's not clear exactly how that blend would work.

Drat.  I gave the code example in order to make that clear.  I guess we can continue to discuss this at "python-ideas".  My quick web search for that turns up a lot of things.  If you could give me a lead -- is there a web URL for that, is it an e-mail list, etc.?

Thank you all for your valuable comments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46780>
_______________________________________

From report at bugs.python.org  Fri Feb 18 09:05:08 2022
From: report at bugs.python.org (Lee Newberg)
Date: Fri, 18 Feb 2022 14:05:08 +0000
Subject: [issue46780] Allow Fractions to return 1/6 for "0.17", "0.167",
 "0.1667", etc.
In-Reply-To: <1645118854.48.0.835738770183.issue46780@roundup.psfhosted.org>
Message-ID: <1645193108.2.0.0419271533941.issue46780@roundup.psfhosted.org>


Lee Newberg <github at quantconsulting.com> added the comment:

In case there are others who are unsure about "python-ideas" ... I believe the discussion page https://discuss.python.org/c/ideas is what was meant.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46780>
_______________________________________

From report at bugs.python.org  Fri Feb 18 09:57:19 2022
From: report at bugs.python.org (Haz)
Date: Fri, 18 Feb 2022 14:57:19 +0000
Subject: [issue45559] pprint tests do not test pprint.pprint()
In-Reply-To: <1634847784.94.0.10912220069.issue45559@roundup.psfhosted.org>
Message-ID: <1645196239.61.0.682635391366.issue45559@roundup.psfhosted.org>


Haz <hp310780.code at gmail.com> added the comment:

Hi! Any chance I could take this on if it hasn't already been actioned please? I assume the scope is to test all the pprint options?

Thanks!

----------
nosy: +hp310780

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45559>
_______________________________________

From report at bugs.python.org  Fri Feb 18 10:16:10 2022
From: report at bugs.python.org (Vladimir Vinogradenko)
Date: Fri, 18 Feb 2022 15:16:10 +0000
Subject: [issue46787] ProcessPoolExecutor exception memory leak
Message-ID: <1645197370.76.0.740159578707.issue46787@roundup.psfhosted.org>


New submission from Vladimir Vinogradenko <themylogin at gmail.com>:

If an exception occurs in ProcessPoolExecutor work item, all the exception frame local variables are not garbage collected (or are garbage collected too lately) because they are referenced by the exception's traceback.

Attached file is a test case. With unpatched python 3.9 (debian bullseye) it prints:

root at truenas[~/freenas/freenas]# python test.py
At iteration 0 memory usage is 226070528
At iteration 1 memory usage is 318763008
At iteration 2 memory usage is 318509056
At iteration 3 memory usage is 321662976
At iteration 4 memory usage is 321404928
At iteration 5 memory usage is 324292608
At iteration 6 memory usage is 324296704
At iteration 7 memory usage is 326922240
At iteration 8 memory usage is 326922240
At iteration 9 memory usage is 329543680

With the proposed patch there is no memory usage growth:

At iteration 0 memory usage is 226410496
At iteration 1 memory usage is 226451456
At iteration 2 memory usage is 226451456
At iteration 3 memory usage is 226443264
At iteration 4 memory usage is 226443264
At iteration 5 memory usage is 226435072
At iteration 6 memory usage is 226426880
At iteration 7 memory usage is 226426880
At iteration 8 memory usage is 226435072
At iteration 9 memory usage is 226426880

----------
components: Library (Lib)
files: 1.py
messages: 413485
nosy: themylogin
priority: normal
severity: normal
status: open
title: ProcessPoolExecutor exception memory leak
type: resource usage
versions: Python 3.9
Added file: https://bugs.python.org/file50628/1.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46787>
_______________________________________

From report at bugs.python.org  Fri Feb 18 10:18:17 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 18 Feb 2022 15:18:17 +0000
Subject: [issue45559] pprint tests do not test pprint.pprint()
In-Reply-To: <1634847784.94.0.10912220069.issue45559@roundup.psfhosted.org>
Message-ID: <1645197497.39.0.993464311649.issue45559@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Sure, have a go at it!

Any testing of pprint.pprint() would be an improvement, but ideally all options should be tested.

It would probably be worthwhile to restructure the tests to run both pformat and pprint tests from the same logic, so that we only need to change one thing if new options are added. I haven't looked at the tests, so I'm not sure how much work this would be.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45559>
_______________________________________

From report at bugs.python.org  Fri Feb 18 10:23:21 2022
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 18 Feb 2022 15:23:21 +0000
Subject: [issue46787] ProcessPoolExecutor exception memory leak
In-Reply-To: <1645197370.76.0.740159578707.issue46787@roundup.psfhosted.org>
Message-ID: <1645197801.34.0.0310789442135.issue46787@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: +29548
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31408

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46787>
_______________________________________

From report at bugs.python.org  Fri Feb 18 10:24:28 2022
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 18 Feb 2022 15:24:28 +0000
Subject: [issue46780] Allow Fractions to return 1/6 for "0.17", "0.167",
 "0.1667", etc.
In-Reply-To: <1645118854.48.0.835738770183.issue46780@roundup.psfhosted.org>
Message-ID: <1645197868.41.0.726224276236.issue46780@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Re python-ideas: there's a mailing list: 

https://mail.python.org/archives/list/python-ideas at python.org/

But the https://discuss.python.org/c/ideas/ category also works for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46780>
_______________________________________

From report at bugs.python.org  Fri Feb 18 10:26:00 2022
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 18 Feb 2022 15:26:00 +0000
Subject: [issue46780] Allow Fractions to return 1/6 for "0.17", "0.167",
 "0.1667", etc.
In-Reply-To: <1645118854.48.0.835738770183.issue46780@roundup.psfhosted.org>
Message-ID: <1645197960.3.0.337993596974.issue46780@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I gave the code example in order to make that clear.

Yep, that didn't help: reverse engineering the intended behaviour from a complicated piece of code isn't easy. An up-front description of the intended behaviour would be better.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46780>
_______________________________________

From report at bugs.python.org  Fri Feb 18 10:28:38 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 18 Feb 2022 15:28:38 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645198118.51.0.519152040593.issue46771@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

> the third case the behavior is wrong, the `.cancel()` should win over the timeout. Otherwise using the context manager becomes too risky in real-world situations.

Please elaborate. The first code that calls `.cancel()` wins, doesn't matter what is the source. asyncio has no priorities.

> I also think your first graph has an issue if the user has a `try/except TimeoutError` between `timeout-a` and `timeout-b`, which is now more probable since we're dropping `move_on`. We can take the discussion to the forked repo; I can put together some tests if that would make it easier.

Ok, let's discuss on GitHub. I only would mention that no code could be executed between timeout-a and timeout-b, because both events are scheduled between the previous event loop iteration and the current one.
Sure, if we can start talking with code (and failed tests) -- it can raise the understanding level very much.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Fri Feb 18 10:38:34 2022
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 18 Feb 2022 15:38:34 +0000
Subject: [issue39298] add BLAKE3 to hashlib
In-Reply-To: <1578716860.16.0.194711020268.issue39298@roundup.psfhosted.org>
Message-ID: <1645198714.21.0.0690170333676.issue39298@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

Just checking--I can liberally pull code from https://github.com/BLAKE3-team/BLAKE3 yes?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39298>
_______________________________________

From report at bugs.python.org  Fri Feb 18 10:44:39 2022
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 18 Feb 2022 15:44:39 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645199079.9.0.959454208036.issue46771@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> * `async with` vs `with`: if Andrew thinks `async with` is easier to teach and less error-prone,

It has to be 'async with' like most asyncio apis to avoid user confusion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Fri Feb 18 11:09:41 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 18 Feb 2022 16:09:41 +0000
Subject: [issue46752] Introduce task groups to asyncio and change task
 cancellation semantics
In-Reply-To: <1644871469.64.0.38816696304.issue46752@roundup.psfhosted.org>
Message-ID: <1645200581.52.0.355998408777.issue46752@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
pull_requests: +29550
pull_request: https://github.com/python/cpython/pull/31409

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46752>
_______________________________________

From report at bugs.python.org  Fri Feb 18 11:19:59 2022
From: report at bugs.python.org (Lee Newberg)
Date: Fri, 18 Feb 2022 16:19:59 +0000
Subject: [issue46780] Allow Fractions to return 1/6 for "0.17", "0.167",
 "0.1667", etc.
In-Reply-To: <1645118854.48.0.835738770183.issue46780@roundup.psfhosted.org>
Message-ID: <1645201199.18.0.918935962453.issue46780@roundup.psfhosted.org>


Lee Newberg <github at quantconsulting.com> added the comment:

I have started a discussion at https://discuss.python.org/t/allow-fractions-fraction-to-return-1-6-for-0-17-0-167-0-1667-etc .  Your feedback there would be much appreciated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46780>
_______________________________________

From report at bugs.python.org  Fri Feb 18 11:36:09 2022
From: report at bugs.python.org (Jeremy Kloth)
Date: Fri, 18 Feb 2022 16:36:09 +0000
Subject: [issue46788] regrtest fails to start on missing performance counter
 names
Message-ID: <1645202169.41.0.134197812756.issue46788@roundup.psfhosted.org>


New submission from Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com>:

When attempting to run the test harness, I receive the following:

Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "C:\Public\Devel\cpython\main\Lib\test\__main__.py", line 2, in <module>
    main()
    ^^^^^^
  File "C:\Public\Devel\cpython\main\Lib\test\libregrtest\main.py", line 736, in main
    Regrtest().main(tests=tests, **kwargs)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Public\Devel\cpython\main\Lib\contextlib.py", line 155, in __exit__
    self.gen.throw(typ, value, traceback)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Public\Devel\cpython\main\Lib\contextlib.py", line 155, in __exit__
    self.gen.throw(typ, value, traceback)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Public\Devel\cpython\main\Lib\test\support\os_helper.py", line 396, in temp_dir
    yield path
    ^^^^^^^^^^
  File "C:\Public\Devel\cpython\main\Lib\contextlib.py", line 155, in __exit__
    self.gen.throw(typ, value, traceback)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Public\Devel\cpython\main\Lib\test\support\os_helper.py", line 427, in change_cwd
    yield os.getcwd()
    ^^^^^^^^^^^^^^^^^
  File "C:\Public\Devel\cpython\main\Lib\test\support\os_helper.py", line 449, in temp_cwd
    yield cwd_dir
    ^^^^^^^^^^^^^
  File "C:\Public\Devel\cpython\main\Lib\test\libregrtest\main.py", line 658, in main
    self._main(tests, kwargs)
    ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Public\Devel\cpython\main\Lib\test\libregrtest\main.py", line 704, in _main
    self.win_load_tracker = WindowsLoadTracker()
                            ^^^^^^^^^^^^^^^^^^^^
  File "C:\Public\Devel\cpython\main\Lib\test\libregrtest\win_utils.py", line 41, in __init__
    self.start()
    ^^^^^^^^^^^^
  File "C:\Public\Devel\cpython\main\Lib\test\libregrtest\win_utils.py", line 70, in start
    counter_name = self._get_counter_name()
                   ^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Public\Devel\cpython\main\Lib\test\libregrtest\win_utils.py", line 90, in _get_counter_name
    system = counters_dict['2']
             ~~~~~~~~~~~~~^^^^^
KeyError: '2'

This is due to my machine missing the localized names for the performance counters.  Other performance monitoring tools operate just fine.

While I have been working around this issue for some time, it has become difficult to seperate the workarounds from actually changes in the test harness.

The PR (https://github.com/python/cpython/pull/26578) from https://bugs.python.org/issue44336 also solves this issue by accessing the counters directly instead of relying on their localized names.

----------
components: Tests, Windows
messages: 413493
nosy: jkloth, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: regrtest fails to start on missing performance counter names
versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46788>
_______________________________________

From report at bugs.python.org  Fri Feb 18 11:36:49 2022
From: report at bugs.python.org (Jeremy Kloth)
Date: Fri, 18 Feb 2022 16:36:49 +0000
Subject: [issue46788] regrtest fails to start on missing performance counter
 names
In-Reply-To: <1645202169.41.0.134197812756.issue46788@roundup.psfhosted.org>
Message-ID: <1645202209.7.0.381100825146.issue46788@roundup.psfhosted.org>


Change by Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46788>
_______________________________________

From report at bugs.python.org  Fri Feb 18 12:00:25 2022
From: report at bugs.python.org (Jeremy Kloth)
Date: Fri, 18 Feb 2022 17:00:25 +0000
Subject: [issue46789] Restore caching of externals on Windows buildbots
Message-ID: <1645203625.57.0.7602685108.issue46789@roundup.psfhosted.org>


New submission from Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com>:

A recent change to the buildmaster config effectively disabled the caching of the externals for Windows buildbots:
   https://github.com/python/buildmaster-config/pull/255

If the caching is desired, a simple change to the buildmaster config is needed (define EXTERNALS_DIR in the build environment).  Or, to continue with fetching them each run, the buildbot scripts in Tools\buildbot can be simplified.

Once a course of action is determined I can develop the requisite PR(s) in the appropriate tracker.

----------
components: Build, Tests, Windows
messages: 413494
nosy: jkloth, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Restore caching of externals on Windows buildbots

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46789>
_______________________________________

From report at bugs.python.org  Fri Feb 18 12:00:52 2022
From: report at bugs.python.org (Jeremy Kloth)
Date: Fri, 18 Feb 2022 17:00:52 +0000
Subject: [issue46789] Restore caching of externals on Windows buildbots
In-Reply-To: <1645203625.57.0.7602685108.issue46789@roundup.psfhosted.org>
Message-ID: <1645203652.45.0.920837661916.issue46789@roundup.psfhosted.org>


Change by Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com>:


----------
nosy: +pablogsal, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46789>
_______________________________________

From report at bugs.python.org  Fri Feb 18 12:08:44 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 18 Feb 2022 17:08:44 +0000
Subject: [issue46752] Introduce task groups to asyncio and change task
 cancellation semantics
In-Reply-To: <1644871469.64.0.38816696304.issue46752@roundup.psfhosted.org>
Message-ID: <1645204124.59.0.542910803849.issue46752@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
pull_requests: +29551
pull_request: https://github.com/python/cpython/pull/31411

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46752>
_______________________________________

From report at bugs.python.org  Fri Feb 18 12:19:21 2022
From: report at bugs.python.org (Mark Shannon)
Date: Fri, 18 Feb 2022 17:19:21 +0000
Subject: [issue46329] Split up the CALL_NO_KW and CALL_KW instructions.
In-Reply-To: <1641819285.76.0.605357810946.issue46329@roundup.psfhosted.org>
Message-ID: <1645204761.49.0.916447925609.issue46329@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset cf345e945f48f54785799390c2e92c5310847bd4 by Mark Shannon in branch 'main':
bpo-46329: Change calling sequence (again) (GH-31373)
https://github.com/python/cpython/commit/cf345e945f48f54785799390c2e92c5310847bd4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46329>
_______________________________________

From report at bugs.python.org  Fri Feb 18 12:26:31 2022
From: report at bugs.python.org (Jeremy Kloth)
Date: Fri, 18 Feb 2022 17:26:31 +0000
Subject: [issue46790] Normalize handling of negative timeouts in subprocess.py
Message-ID: <1645205190.98.0.586198331999.issue46790@roundup.psfhosted.org>


New submission from Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com>:

As a follow on to bpo-46716, the various timeout parameters currently deal with negative values differently in POSIX and Windows.

On POSIX, a negative value is treated the same as 0; check completion and raise TimeoutExpired is still running.

On Windows, the negative value is treated as unsigned and ultimately waits for ~49 days.

While the Windows behavior is obviously wrong and will be fixed internally as part of bpo-46716, that still leaves what to do with timeouts coming from user-space.  The current documentation just states that after `timeout` seconds TimeoutExpired is raised.  A liberal reading of the documentation could lead one to believe any value <=0 would suffice for an "active" check (the POSIX behavior).

OR, the documentation could be amended and negative values are now invalid and apply range checking in the user-facing functions.

----------
components: Library (Lib)
messages: 413496
nosy: jkloth
priority: normal
severity: normal
status: open
title: Normalize handling of negative timeouts in subprocess.py
versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46790>
_______________________________________

From report at bugs.python.org  Fri Feb 18 12:26:53 2022
From: report at bugs.python.org (Jeremy Kloth)
Date: Fri, 18 Feb 2022 17:26:53 +0000
Subject: [issue46790] Normalize handling of negative timeouts in subprocess.py
In-Reply-To: <1645205190.98.0.586198331999.issue46790@roundup.psfhosted.org>
Message-ID: <1645205213.02.0.0962419885713.issue46790@roundup.psfhosted.org>


Change by Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com>:


----------
nosy: +eryksun, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46790>
_______________________________________

From report at bugs.python.org  Fri Feb 18 12:47:08 2022
From: report at bugs.python.org (Jeremy Kloth)
Date: Fri, 18 Feb 2022 17:47:08 +0000
Subject: [issue46790] Normalize handling of negative timeouts in subprocess.py
In-Reply-To: <1645205190.98.0.586198331999.issue46790@roundup.psfhosted.org>
Message-ID: <1645206428.85.0.243322729609.issue46790@roundup.psfhosted.org>


Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com> added the comment:

Oh, I forgot to add that I'm in favor of following the threading.py behavior of allowing <=0 to mean "non-blocking" (i.e., just check).  This would probably also benefit from a documentation update to clarify.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46790>
_______________________________________

From report at bugs.python.org  Fri Feb 18 12:52:35 2022
From: report at bugs.python.org (Jeremy Kloth)
Date: Fri, 18 Feb 2022 17:52:35 +0000
Subject: [issue46789] Restore caching of externals on Windows buildbots
In-Reply-To: <1645203625.57.0.7602685108.issue46789@roundup.psfhosted.org>
Message-ID: <1645206755.02.0.294533543873.issue46789@roundup.psfhosted.org>


Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com> added the comment:

I personally would like to see caching restored so as to keep the duration of buildbot runs as low as possible.  The repeated fetching effectively doubles compilation time for my Win11 builder.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46789>
_______________________________________

From report at bugs.python.org  Fri Feb 18 12:55:13 2022
From: report at bugs.python.org (Dan Snider)
Date: Fri, 18 Feb 2022 17:55:13 +0000
Subject: [issue46791] Allow os.remove to defer to rmdir
Message-ID: <1645206913.87.0.447648839641.issue46791@roundup.psfhosted.org>


New submission from Dan Snider <mr.assume.away at gmail.com>:

It appears sometime recently-ish that POSIX updated remove to the following:

    #include <stdio.h>
    int remove(const char *path);

If?path?does not name a directory,?remove(path) shall be equivalent to?unlink(path). If?path?names a directory,?remove(path) shall be equivalent to?rmdir(path).

----------
messages: 413499
nosy: bup
priority: normal
severity: normal
status: open
title: Allow os.remove to defer to rmdir
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46791>
_______________________________________

From report at bugs.python.org  Fri Feb 18 13:21:28 2022
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 18 Feb 2022 18:21:28 +0000
Subject: [issue46736] Generate HTML 5 with
 SimpleHTTPRequestHandler.list_directory
In-Reply-To: <1644741188.03.0.745095490398.issue46736@roundup.psfhosted.org>
Message-ID: <1645208488.24.0.420851454009.issue46736@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> added the comment:

Would you like to make a pull request?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46736>
_______________________________________

From report at bugs.python.org  Fri Feb 18 13:30:04 2022
From: report at bugs.python.org (Jakub Wilk)
Date: Fri, 18 Feb 2022 18:30:04 +0000
Subject: [issue46725] Unpacking without parentheses is allowed since 3.9
In-Reply-To: <1644603030.68.0.559962279778.issue46725@roundup.psfhosted.org>
Message-ID: <1645209004.99.0.934659643278.issue46725@roundup.psfhosted.org>


Change by Jakub Wilk <jwilk at jwilk.net>:


----------
nosy: +jwilk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46725>
_______________________________________

From report at bugs.python.org  Fri Feb 18 13:31:47 2022
From: report at bugs.python.org (Brandt Bucher)
Date: Fri, 18 Feb 2022 18:31:47 +0000
Subject: [issue46748] Python.h includes stdbool.h
In-Reply-To: <1644830899.62.0.590844926135.issue46748@roundup.psfhosted.org>
Message-ID: <1645209107.75.0.357614144873.issue46748@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
nosy: +brandtbucher

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46748>
_______________________________________

From report at bugs.python.org  Fri Feb 18 13:31:47 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Feb 2022 18:31:47 +0000
Subject: [issue46725] Unpacking without parentheses is allowed since 3.9
In-Reply-To: <1644603030.68.0.559962279778.issue46725@roundup.psfhosted.org>
Message-ID: <1645209107.81.0.534942315992.issue46725@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Allowing no parentheses is also consistent with the following:
  for x in 1,2,3: print(x)

----------
nosy: +terry.reedy -jwilk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46725>
_______________________________________

From report at bugs.python.org  Fri Feb 18 13:54:19 2022
From: report at bugs.python.org (Harshini)
Date: Fri, 18 Feb 2022 18:54:19 +0000
Subject: [issue46792] Indentation now preserved with
 ruamel.yaml.round_trip_dump
Message-ID: <1645210459.61.0.588712461043.issue46792@roundup.psfhosted.org>


New submission from Harshini <nvorugan at qti.qualcomm.com>:

I observed that the indentation is not preserved when I load and dump a YAML file using round_trip_dump from ruamel.yaml. For example, I have an input file with the data:

Inventory:
  - name: Apples
    count: 10
    vendors:
    - - vendor_name: xyz
        boxes: 2

  - name: Bananas
    number: 20
    vendors:
    - - vendor_name: abc
        boxes: 1
      - vendor_name: xyz
        boxes: 4


I wrote a simple script that just loads and dumps the same data into a new YAML file:

import sys
import os
import ruamel.yaml

yaml = ruamel.yaml.YAML()
input_file = sys.argv[1]
output_yaml =  r"data_output.yaml"
output = open(output_yaml, 'w+')
with open(input_file, 'r') as f:
    data = yaml.load(f)
    ruamel.yaml.round_trip_dump(data, output)    


I would expect the output yaml to be the same as the input yaml but what is see is:

Inventory:
- name: Apples
  count: 10
  vendors:
  - - vendor_name: xyz
      boxes: 2
- name: Bananas
  number: 20
  vendors:
  - - vendor_name: abc
      boxes: 1
    - vendor_name: xyz
      boxes: 4

It is missing the indentation under Inventory as there should be a tab before "- name" .

----------
components: Library (Lib)
files: input.yaml
messages: 413502
nosy: nvorugan
priority: normal
severity: normal
status: open
title: Indentation now preserved with ruamel.yaml.round_trip_dump
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file50629/input.yaml

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46792>
_______________________________________

From report at bugs.python.org  Fri Feb 18 13:59:21 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 18 Feb 2022 18:59:21 +0000
Subject: [issue46792] Indentation now preserved with
 ruamel.yaml.round_trip_dump
In-Reply-To: <1645210459.61.0.588712461043.issue46792@roundup.psfhosted.org>
Message-ID: <1645210761.11.0.629335135651.issue46792@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

This looks like an issue with ruamel.yaml, which is a third party package. You should report it to them.

Good luck!

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46792>
_______________________________________

From report at bugs.python.org  Fri Feb 18 14:00:53 2022
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 18 Feb 2022 19:00:53 +0000
Subject: [issue46792] Indentation now preserved with
 ruamel.yaml.round_trip_dump
In-Reply-To: <1645210459.61.0.588712461043.issue46792@roundup.psfhosted.org>
Message-ID: <1645210853.26.0.953831245576.issue46792@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46792>
_______________________________________

From report at bugs.python.org  Fri Feb 18 14:01:43 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 18 Feb 2022 19:01:43 +0000
Subject: [issue46792] Indentation not preserved with
 ruamel.yaml.round_trip_dump
In-Reply-To: <1645210459.61.0.588712461043.issue46792@roundup.psfhosted.org>
Message-ID: <1645210903.59.0.316284124098.issue46792@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
title: Indentation now preserved with ruamel.yaml.round_trip_dump -> Indentation not preserved with ruamel.yaml.round_trip_dump

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46792>
_______________________________________

From report at bugs.python.org  Fri Feb 18 14:10:42 2022
From: report at bugs.python.org (Jakub Wilk)
Date: Fri, 18 Feb 2022 19:10:42 +0000
Subject: [issue35897] Support list as argument to .startswith()
In-Reply-To: <1549355778.94.0.606894132692.issue35897@roundup.psfhosted.org>
Message-ID: <1645211442.08.0.841427606323.issue35897@roundup.psfhosted.org>


Change by Jakub Wilk <jwilk at jwilk.net>:


----------
nosy: +jwilk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35897>
_______________________________________

From report at bugs.python.org  Fri Feb 18 14:11:19 2022
From: report at bugs.python.org (Jakub Wilk)
Date: Fri, 18 Feb 2022 19:11:19 +0000
Subject: [issue34990] year 2038 problem in compileall.py
In-Reply-To: <1539602536.3.0.788709270274.issue34990@psf.upfronthosting.co.za>
Message-ID: <1645211479.02.0.949578562282.issue34990@roundup.psfhosted.org>


Change by Jakub Wilk <jwilk at jwilk.net>:


----------
nosy: +jwilk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34990>
_______________________________________

From report at bugs.python.org  Fri Feb 18 14:27:44 2022
From: report at bugs.python.org (Vidhya)
Date: Fri, 18 Feb 2022 19:27:44 +0000
Subject: [issue20923] [doc] Explain ConfigParser 'valid section name' and
 .SECTCRE
In-Reply-To: <1394806905.89.0.637343755468.issue20923@psf.upfronthosting.co.za>
Message-ID: <1645212464.59.0.639899609941.issue20923@roundup.psfhosted.org>


Change by Vidhya <vidhya.friend at gmail.com>:


----------
pull_requests: +29552
pull_request: https://github.com/python/cpython/pull/31413

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20923>
_______________________________________

From report at bugs.python.org  Fri Feb 18 14:39:09 2022
From: report at bugs.python.org (Andrzej Ratajczak)
Date: Fri, 18 Feb 2022 19:39:09 +0000
Subject: [issue46391] Library multiprocess leaks named resources.
In-Reply-To: <1642269897.29.0.322439501259.issue46391@roundup.psfhosted.org>
Message-ID: <1645213149.3.0.559221154064.issue46391@roundup.psfhosted.org>


Andrzej Ratajczak <andrzej.ratajczak98 at gmail.com> added the comment:

Also hitting this problem. Would be grateful for fixing it, since there is already PR created

----------
nosy: +BarkingBad

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46391>
_______________________________________

From report at bugs.python.org  Fri Feb 18 14:43:57 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Feb 2022 19:43:57 +0000
Subject: [issue46732] None.__bool__ docstring is wrong
In-Reply-To: <1644693001.93.0.383788579819.issue46732@roundup.psfhosted.org>
Message-ID: <1645213437.02.0.189111632704.issue46732@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

There is no object.__bool__.  None.__bool__.__doc__ appears to be an accidental copy of bool/int/float/complex.__bool__.__doc__.  It should just be 'False'.

----------
nosy: +terry.reedy
title: object.__bool__ docstring is wrong -> None.__bool__ docstring is wrong

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46732>
_______________________________________

From report at bugs.python.org  Fri Feb 18 14:48:41 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Feb 2022 19:48:41 +0000
Subject: [issue46733] pathlib.Path methods can raise NotImplementedError
In-Reply-To: <1644694513.05.0.985214969865.issue46733@roundup.psfhosted.org>
Message-ID: <1645213721.62.0.620450127819.issue46733@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I think pathlib should be raising TypeError, ValueError, or something else as appropriate.  Or not raising in situations Eryk indicated.  x/0 *could* be +- float('inf'), but we don't raise NotImplementedError for it.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46733>
_______________________________________

From report at bugs.python.org  Fri Feb 18 14:56:51 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 18 Feb 2022 19:56:51 +0000
Subject: [issue46725] Unpacking without parentheses is allowed since 3.9
In-Reply-To: <1644603030.68.0.559962279778.issue46725@roundup.psfhosted.org>
Message-ID: <1645214211.64.0.884242884344.issue46725@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Adding jwilk back (a bpo interaction with browser form caching makes this happen frequently).

----------
nosy: +jwilk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46725>
_______________________________________

From report at bugs.python.org  Fri Feb 18 15:13:14 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Feb 2022 20:13:14 +0000
Subject: [issue46735] gettext.translations crashes when locale is unset
In-Reply-To: <1644716033.71.0.382285385303.issue46735@roundup.psfhosted.org>
Message-ID: <1645215194.49.0.300569409854.issue46735@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

As 'crash', as used here, is when python exits abnormally *without* an exception traceback.  The traceback in the linked report is:

Traceback (most recent call last):
  File "video2x.py", line 53, in <module>
    from upscaler import AVAILABLE_DRIVERS
  File "/home/meltonmb/video2x-4.6.1/src/upscaler.py", line 48, in <module>
    language = gettext.translation(DOMAIN, LOCALE_DIRECTORY, [default_locale], fallback=True)
  File "/usr/lib/python3.8/gettext.py", line 583, in translation
    mofiles = find(domain, localedir, languages, all=True)
  File "/usr/lib/python3.8/gettext.py", line 554, in find
    for nelang in _expand_lang(lang):
  File "/usr/lib/python3.8/gettext.py", line 213, in _expand_lang
    loc = locale.normalize(loc)
  File "/usr/lib/python3.8/locale.py", line 401, in normalize
    code = localename.lower()
AttributeError: 'NoneType' object has no attribute 'lower'

Whether the bug is in the 3rd party module 'upscaler' or the stdlib module gettext depends on whether the DOMAIN, LOCALE_DIRECTORY, and [default_locale] arguments in upscaler's call to gettext.translation meet the documented requirements.  What are their values?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46735>
_______________________________________

From report at bugs.python.org  Fri Feb 18 15:15:37 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Feb 2022 20:15:37 +0000
Subject: [issue46740] Improve Telnetlib's throughput
In-Reply-To: <1644783460.72.0.175033327075.issue46740@roundup.psfhosted.org>
Message-ID: <1645215337.93.0.437447075806.issue46740@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Even if deprecated, it will be around for at least 2 versions.  A patch now might be worthwhile, but I don't know who would review it.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46740>
_______________________________________

From report at bugs.python.org  Fri Feb 18 15:51:43 2022
From: report at bugs.python.org (Fred)
Date: Fri, 18 Feb 2022 20:51:43 +0000
Subject: [issue35897] Support list as argument to .startswith()
In-Reply-To: <1549355778.94.0.606894132692.issue35897@roundup.psfhosted.org>
Message-ID: <1645217503.71.0.315060853772.issue35897@roundup.psfhosted.org>


Fred <eldmannen at gmail.com> added the comment:

> For subtle reasons, that would make us worse off.  Tuple of constants get precomputed but lists of constants have to be rebuilt.

So if a list is 20 times slower than a tuple, I can still do billions of computations in a second on a Raspberry Pi, so does it matter?

Being able to pass a list into .startswith() makes it more user-friendly and makes Python be more productive for the developer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35897>
_______________________________________

From report at bugs.python.org  Fri Feb 18 16:05:36 2022
From: report at bugs.python.org (Vidhya)
Date: Fri, 18 Feb 2022 21:05:36 +0000
Subject: [issue33601] [doc] Py_UTF8Mode is not documented
In-Reply-To: <1526996981.47.0.682650639539.issue33601@psf.upfronthosting.co.za>
Message-ID: <1645218336.26.0.991405985696.issue33601@roundup.psfhosted.org>


Vidhya <vidhya.friend at gmail.com> added the comment:

[Entry level contributor seeking guidance]The PR on this issue looks closed. I worked on this and attaching the updated html file.

I will open a pull request if this is not yet resolved.

----------
nosy: +vidhya.friend
Added file: https://bugs.python.org/file50630/init.html

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33601>
_______________________________________

From report at bugs.python.org  Fri Feb 18 16:19:36 2022
From: report at bugs.python.org (Brandt Bucher)
Date: Fri, 18 Feb 2022 21:19:36 +0000
Subject: [issue46702] Specialize UNPACK_SEQUENCE
In-Reply-To: <1644453353.53.0.226399964433.issue46702@roundup.psfhosted.org>
Message-ID: <1645219176.46.0.344010771776.issue46702@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

Closing as UNPACK_SEQUENCE_TWO_TUPLE__STORE_FAST__STORE_FAST results in lots of hits, but no performance improvement.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46702>
_______________________________________

From report at bugs.python.org  Fri Feb 18 16:27:31 2022
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 18 Feb 2022 21:27:31 +0000
Subject: [issue46793] expose expat XML billion laughs attack mitigation APIs
Message-ID: <1645219651.82.0.456438689192.issue46793@roundup.psfhosted.org>


New submission from Gregory P. Smith <greg at krypto.org>:

Quoting from https://github.com/python/cpython/pull/31397#issuecomment-1044796561

"""
XML_SetBillionLaughsAttackProtectionActivationThreshold

XML_SetBillionLaughsAttackProtectionMaximumAmplification

I still hope that someone can make those two^^ accessible (with additional glue code) to the user on pyexpat level in CPython.
""" - Sebastian Pipping @hartwork

----------
messages: 413513
nosy: gregory.p.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: expose expat XML billion laughs attack mitigation APIs
type: enhancement
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46793>
_______________________________________

From report at bugs.python.org  Fri Feb 18 16:38:39 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Feb 2022 21:38:39 +0000
Subject: [issue46760] test_dis should test the dis module, not everything else
In-Reply-To: <1644934628.87.0.437399260946.issue46760@roundup.psfhosted.org>
Message-ID: <1645220319.15.0.118727223685.issue46760@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

With IDLE, I have issues with trying to test IDLE code without retesting tkinter, as well as deciding on the proper units of behavior to test.

Some suggestions: 
1. Add a docstring to the module with guidelines, after review from a couple of others.
For instance,I believe you are saying that no test should explicitly call compile.  Rather the test writer should call compile and extract the bytecode to copy into a test.

2. Make yourself a module code owner so you get informed and can review.  Reviewing would be easier with guidelines to refer to, instead of repeating them.

3. An example issue is that some callables take many types of arguments.  If not already, tests that the function can extract the bytecode from various objects should be separate from tests that extracted bytecode is then handled properly.  Would any internal refactoring of dis and addition of _test functions make it easier to make test more independent of each other?

4. I would rather read the multiple long lists like

expected_opinfo_outer = [
  Instruction(opname='LOAD_CONST', opcode=100, arg=1, argval=3, argrepr='3', offset=0, starts_line=2, is_jump_target=False),
  Instruction(opname='LOAD_CONST', opcode=100, arg=2, argval=4, argrepr='4', offset=3, starts_line=None, is_jump_target=False),
  ...
]

condensed to

expected_opinfo_outer = [Instruction(opname, opcode, arg, argval, argrepr,
                                     offset, starts_line, is_jumps_target)
    for opname, opcode, arg, argval, argrepr, offset, starts_line, is_jumps_target in
(('LOAD_CONST', 100,    1,   3,     '3',      0,      2,           False),
 ('LOAD_CONST', 100,    2,   4,     '4',      3,      None,        False),
 ...
)]

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46760>
_______________________________________

From report at bugs.python.org  Fri Feb 18 17:33:15 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Feb 2022 22:33:15 +0000
Subject: [issue46784] Duplicated symbols when linking embedded Python with
 libexpat
In-Reply-To: <1645140945.97.0.0561003008604.issue46784@roundup.psfhosted.org>
Message-ID: <1645223595.45.0.704192621595.issue46784@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 6312c1052c0186b4596fc45c42fd3ade9f8f5911 by Yilei "Dolee" Yang in branch 'main':
bpo-46784: Add newly exported expat symbols to the namespace. (GH-31397)
https://github.com/python/cpython/commit/6312c1052c0186b4596fc45c42fd3ade9f8f5911


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46784>
_______________________________________

From report at bugs.python.org  Fri Feb 18 17:33:28 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Feb 2022 22:33:28 +0000
Subject: [issue46784] Duplicated symbols when linking embedded Python with
 libexpat
In-Reply-To: <1645140945.97.0.0561003008604.issue46784@roundup.psfhosted.org>
Message-ID: <1645223608.02.0.829807480938.issue46784@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29553
pull_request: https://github.com/python/cpython/pull/31416

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46784>
_______________________________________

From report at bugs.python.org  Fri Feb 18 17:33:32 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Feb 2022 22:33:32 +0000
Subject: [issue46784] Duplicated symbols when linking embedded Python with
 libexpat
In-Reply-To: <1645140945.97.0.0561003008604.issue46784@roundup.psfhosted.org>
Message-ID: <1645223612.24.0.85155453422.issue46784@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29554
pull_request: https://github.com/python/cpython/pull/31417

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46784>
_______________________________________

From report at bugs.python.org  Fri Feb 18 18:07:51 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Feb 2022 23:07:51 +0000
Subject: [issue46784] Duplicated symbols when linking embedded Python with
 libexpat
In-Reply-To: <1645140945.97.0.0561003008604.issue46784@roundup.psfhosted.org>
Message-ID: <1645225671.34.0.373755985098.issue46784@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29555
pull_request: https://github.com/python/cpython/pull/31418

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46784>
_______________________________________

From report at bugs.python.org  Fri Feb 18 18:07:55 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Feb 2022 23:07:55 +0000
Subject: [issue46784] Duplicated symbols when linking embedded Python with
 libexpat
In-Reply-To: <1645140945.97.0.0561003008604.issue46784@roundup.psfhosted.org>
Message-ID: <1645225675.47.0.351645178702.issue46784@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29556
pull_request: https://github.com/python/cpython/pull/31419

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46784>
_______________________________________

From report at bugs.python.org  Fri Feb 18 18:13:20 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Feb 2022 23:13:20 +0000
Subject: [issue46784] Duplicated symbols when linking embedded Python with
 libexpat
In-Reply-To: <1645140945.97.0.0561003008604.issue46784@roundup.psfhosted.org>
Message-ID: <1645226000.01.0.181648464735.issue46784@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 9aca412db8343702d9199c31ba73519e6f8823b5 by Miss Islington (bot) in branch '3.9':
bpo-46784: Add newly exported expat symbols to the namespace. (GH-31397)
https://github.com/python/cpython/commit/9aca412db8343702d9199c31ba73519e6f8823b5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46784>
_______________________________________

From report at bugs.python.org  Fri Feb 18 18:33:51 2022
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 18 Feb 2022 23:33:51 +0000
Subject: [issue46784] Duplicated symbols when linking embedded Python with
 libexpat
In-Reply-To: <1645140945.97.0.0561003008604.issue46784@roundup.psfhosted.org>
Message-ID: <1645227231.05.0.418191746653.issue46784@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
pull_requests: +29557
pull_request: https://github.com/python/cpython/pull/31420

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46784>
_______________________________________

From report at bugs.python.org  Fri Feb 18 18:36:28 2022
From: report at bugs.python.org (sping)
Date: Fri, 18 Feb 2022 23:36:28 +0000
Subject: [issue46794] Please update bundled libexpat to 2.4.5 with security
 fixes (5 CVEs)
Message-ID: <1645227388.68.0.727345462152.issue46794@roundup.psfhosted.org>


New submission from sping <sebastian at pipping.org>:

Thank you!

https://github.com/libexpat/libexpat/blob/97a4840578693a346e79302909b67d97492e1880/expat/Changes#L6-L35

----------
components: XML
messages: 413517
nosy: sping
priority: normal
severity: normal
status: open
title: Please update bundled libexpat to 2.4.5 with security fixes (5 CVEs)
type: security
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46794>
_______________________________________

From report at bugs.python.org  Fri Feb 18 19:20:05 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 19 Feb 2022 00:20:05 +0000
Subject: [issue46782] Docs error for 3.10
In-Reply-To: <1645121541.07.0.568386298101.issue46782@roundup.psfhosted.org>
Message-ID: <1645230005.38.0.415257600307.issue46782@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The conversions from 0o777 to 511 in 3.10 and 3.11 but not in 3.9 are these:

https://docs.python.org/3/library/pathlib.html#pathlib.Path.mkdir
  Path.mkdir(mode=511, parents=False, exist_ok=False)

https://docs.python.org/3/library/os.html#os.mkdir
  os.mkdir(path, mode=511, *, dir_fd=None)

I don't know whether different sphinx versions are used for different versions of the docs.

----------
nosy: +eric.araujo, mdk, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46782>
_______________________________________

From report at bugs.python.org  Fri Feb 18 19:28:52 2022
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 19 Feb 2022 00:28:52 +0000
Subject: [issue46200] Discourage logging f-strings due to security
 considerations
In-Reply-To: <1640850255.25.0.496981368409.issue46200@roundup.psfhosted.org>
Message-ID: <1645230532.62.0.188315130964.issue46200@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

A new system of logging APIs has been on several of our (core dev and otherwise) minds ever since f-strings were introduced.  For this specific issue, agreed that documentation is key.

The old logging APIs cannot change.  And practically preventing passing non-literal constant values in as the first parameter within their implementation while there are theoretical ways to _maybe_ do that, I expect none would be maintainable or performant.

For https://www.python.org/dev/peps/pep-0675/#logging-format-string-injection, my gut feeling is you want logging functions annotated as is a duality using overload.

```
@overload
def info(str) -> None:
    ...

@overload
def info(msg: LiteralString, *args: object) -> None:
```

As that prevents the untrusted template in msg so you could use a lone f-str.

This larger conversation is better turned into a python-dev or discuss.python.org thread than done in our poor bug tracker as anything more than the doc update and musing around the annotations turns into an evolved logging system design discussion.  (a nice thread internally at work just restarted about this and linked here... people want f-logging!)

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46200>
_______________________________________

From report at bugs.python.org  Fri Feb 18 19:53:58 2022
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 19 Feb 2022 00:53:58 +0000
Subject: [issue46784] Duplicated symbols when linking embedded Python with
 libexpat
In-Reply-To: <1645140945.97.0.0561003008604.issue46784@roundup.psfhosted.org>
Message-ID: <1645232038.85.0.303232479381.issue46784@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:


New changeset e05e3d20d309603010f2c1194e612f894ad8a985 by Gregory P. Smith in branch '3.10':
[3.10] bpo-46784: Add newly exported expat symbols to the namespace. (GH-31397) (GH-31420)
https://github.com/python/cpython/commit/e05e3d20d309603010f2c1194e612f894ad8a985


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46784>
_______________________________________

From report at bugs.python.org  Fri Feb 18 20:26:06 2022
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 19 Feb 2022 01:26:06 +0000
Subject: [issue46784] Duplicated symbols when linking embedded Python with
 libexpat
In-Reply-To: <1645140945.97.0.0561003008604.issue46784@roundup.psfhosted.org>
Message-ID: <1645233966.44.0.918377621215.issue46784@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

PRs for 3.7 and 3.8 remain up to release blockers.

----------
components: +Build
resolution:  -> fixed
stage: patch review -> commit review
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46784>
_______________________________________

From report at bugs.python.org  Fri Feb 18 20:26:23 2022
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 19 Feb 2022 01:26:23 +0000
Subject: [issue46784] Duplicated symbols when linking embedded Python with
 libexpat
In-Reply-To: <1645140945.97.0.0561003008604.issue46784@roundup.psfhosted.org>
Message-ID: <1645233983.35.0.949213240528.issue46784@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

err "release managers" same thing right? ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46784>
_______________________________________

From report at bugs.python.org  Fri Feb 18 20:36:06 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 19 Feb 2022 01:36:06 +0000
Subject: [issue46793] expose expat XML billion laughs attack mitigation APIs
In-Reply-To: <1645219651.82.0.456438689192.issue46793@roundup.psfhosted.org>
Message-ID: <1645234566.6.0.117622411672.issue46793@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/issue46793>
_______________________________________

From report at bugs.python.org  Fri Feb 18 20:53:43 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Sat, 19 Feb 2022 01:53:43 +0000
Subject: [issue46571] Strange `@typing.no_type_check` behavior for class
 variables
In-Reply-To: <1643465522.51.0.205719891345.issue46571@roundup.psfhosted.org>
Message-ID: <1645235623.47.0.464165725659.issue46571@roundup.psfhosted.org>


Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:


New changeset 395029b0bd343648b4da8044c7509672ea768775 by Nikita Sobolev in branch 'main':
bpo-46571: improve `typing.no_type_check` to skip foreign objects (GH-31042)
https://github.com/python/cpython/commit/395029b0bd343648b4da8044c7509672ea768775


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46571>
_______________________________________

From report at bugs.python.org  Fri Feb 18 20:54:04 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Sat, 19 Feb 2022 01:54:04 +0000
Subject: [issue46603] `typing._strip_annotations` is not fully covered
In-Reply-To: <1643750261.29.0.798402203083.issue46603@roundup.psfhosted.org>
Message-ID: <1645235644.91.0.752331393613.issue46603@roundup.psfhosted.org>


Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:


New changeset 25c0b9d243b64ccd2eeab483089eaf7e4b4d5834 by Nikita Sobolev in branch 'main':
bpo-46603: improve coverage of `typing._strip_annotations` (GH-31063)
https://github.com/python/cpython/commit/25c0b9d243b64ccd2eeab483089eaf7e4b4d5834


----------
nosy: +Jelle Zijlstra

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46603>
_______________________________________

From report at bugs.python.org  Fri Feb 18 20:54:08 2022
From: report at bugs.python.org (miss-islington)
Date: Sat, 19 Feb 2022 01:54:08 +0000
Subject: [issue46603] `typing._strip_annotations` is not fully covered
In-Reply-To: <1643750261.29.0.798402203083.issue46603@roundup.psfhosted.org>
Message-ID: <1645235648.43.0.47817096135.issue46603@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: +29558
pull_request: https://github.com/python/cpython/pull/31423

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46603>
_______________________________________

From report at bugs.python.org  Fri Feb 18 20:54:11 2022
From: report at bugs.python.org (miss-islington)
Date: Sat, 19 Feb 2022 01:54:11 +0000
Subject: [issue46603] `typing._strip_annotations` is not fully covered
In-Reply-To: <1643750261.29.0.798402203083.issue46603@roundup.psfhosted.org>
Message-ID: <1645235651.89.0.202429537738.issue46603@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29559
pull_request: https://github.com/python/cpython/pull/31424

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46603>
_______________________________________

From report at bugs.python.org  Fri Feb 18 20:54:30 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Sat, 19 Feb 2022 01:54:30 +0000
Subject: [issue46603] `typing._strip_annotations` is not fully covered
In-Reply-To: <1643750261.29.0.798402203083.issue46603@roundup.psfhosted.org>
Message-ID: <1645235670.87.0.510939186891.issue46603@roundup.psfhosted.org>


Change by Jelle Zijlstra <jelle.zijlstra at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46603>
_______________________________________

From report at bugs.python.org  Fri Feb 18 20:54:58 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Sat, 19 Feb 2022 01:54:58 +0000
Subject: [issue46571] Strange `@typing.no_type_check` behavior for class
 variables
In-Reply-To: <1643465522.51.0.205719891345.issue46571@roundup.psfhosted.org>
Message-ID: <1645235698.05.0.0880868907205.issue46571@roundup.psfhosted.org>


Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:

Thanks for the fix Nikita!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46571>
_______________________________________

From report at bugs.python.org  Fri Feb 18 20:56:34 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Sat, 19 Feb 2022 01:56:34 +0000
Subject: [issue46685] Add additional tests for new features in `typing.py`
In-Reply-To: <1644350626.56.0.225939389842.issue46685@roundup.psfhosted.org>
Message-ID: <1645235794.64.0.00327828351963.issue46685@roundup.psfhosted.org>


Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:


New changeset 32e3e0bea613711a8f19003445eebcb05fb75acc by Nikita Sobolev in branch 'main':
bpo-46685: improve test coverage of `Self` and `Never` in `typing` (GH-31222)
https://github.com/python/cpython/commit/32e3e0bea613711a8f19003445eebcb05fb75acc


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46685>
_______________________________________

From report at bugs.python.org  Fri Feb 18 20:57:22 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Sat, 19 Feb 2022 01:57:22 +0000
Subject: [issue46685] Add additional tests for new features in `typing.py`
In-Reply-To: <1644350626.56.0.225939389842.issue46685@roundup.psfhosted.org>
Message-ID: <1645235842.82.0.19614079068.issue46685@roundup.psfhosted.org>


Change by Jelle Zijlstra <jelle.zijlstra at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46685>
_______________________________________

From report at bugs.python.org  Fri Feb 18 21:16:08 2022
From: report at bugs.python.org (miss-islington)
Date: Sat, 19 Feb 2022 02:16:08 +0000
Subject: [issue46603] `typing._strip_annotations` is not fully covered
In-Reply-To: <1643750261.29.0.798402203083.issue46603@roundup.psfhosted.org>
Message-ID: <1645236968.27.0.995257297455.issue46603@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 103f3ca80616958b4e608e9176b9c12cfc80f68b by Miss Islington (bot) in branch '3.10':
bpo-46603: improve coverage of `typing._strip_annotations` (GH-31063)
https://github.com/python/cpython/commit/103f3ca80616958b4e608e9176b9c12cfc80f68b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46603>
_______________________________________

From report at bugs.python.org  Fri Feb 18 21:21:14 2022
From: report at bugs.python.org (Alex Waygood)
Date: Sat, 19 Feb 2022 02:21:14 +0000
Subject: =?utf-8?q?=5Bissue46754=5D_Improve_Python_Language_Reference_based_on_=5B?=
 =?utf-8?b?S8O2aGwgMjAyMF0=?=
In-Reply-To: <1644887951.55.0.170879911355.issue46754@roundup.psfhosted.org>
Message-ID: <1645237274.53.0.0629416854131.issue46754@roundup.psfhosted.org>


Change by Alex Waygood <Alex.Waygood at Gmail.com>:


----------
keywords: +patch
nosy: +AlexWaygood
nosy_count: 1.0 -> 2.0
pull_requests: +29560
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/29479

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46754>
_______________________________________

From report at bugs.python.org  Fri Feb 18 21:24:19 2022
From: report at bugs.python.org (Alex Waygood)
Date: Sat, 19 Feb 2022 02:24:19 +0000
Subject: =?utf-8?q?=5Bissue46754=5D_Improve_Python_Language_Reference_based_on_=5B?=
 =?utf-8?b?S8O2aGwgMjAyMF0=?=
In-Reply-To: <1644887951.55.0.170879911355.issue46754@roundup.psfhosted.org>
Message-ID: <1645237459.5.0.258843909068.issue46754@roundup.psfhosted.org>


Change by Alex Waygood <Alex.Waygood at Gmail.com>:


----------
pull_requests:  -29560

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46754>
_______________________________________

From report at bugs.python.org  Fri Feb 18 21:24:40 2022
From: report at bugs.python.org (Alex Waygood)
Date: Sat, 19 Feb 2022 02:24:40 +0000
Subject: =?utf-8?q?=5Bissue46754=5D_Improve_Python_Language_Reference_based_on_=5B?=
 =?utf-8?b?S8O2aGwgMjAyMF0=?=
In-Reply-To: <1644887951.55.0.170879911355.issue46754@roundup.psfhosted.org>
Message-ID: <1645237480.74.0.62194564028.issue46754@roundup.psfhosted.org>


Change by Alex Waygood <Alex.Waygood at Gmail.com>:


----------
keywords:  -patch
nosy:  -AlexWaygood
stage: patch review -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46754>
_______________________________________

From report at bugs.python.org  Fri Feb 18 21:30:41 2022
From: report at bugs.python.org (Golubev Alexander)
Date: Sat, 19 Feb 2022 02:30:41 +0000
Subject: [issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys
In-Reply-To: <1429890469.94.0.27310602141.issue24053@psf.upfronthosting.co.za>
Message-ID: <1645237841.68.0.323574559906.issue24053@roundup.psfhosted.org>


Golubev Alexander <fatzer2 at gmail.com> added the comment:

Any reasons the PR still not merged?

----------
nosy: +Fat-Zer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24053>
_______________________________________

From report at bugs.python.org  Fri Feb 18 23:03:27 2022
From: report at bugs.python.org (=?utf-8?q?Tin_Tvrtkovi=C4=87?=)
Date: Sat, 19 Feb 2022 04:03:27 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645243407.03.0.428196530075.issue46771@roundup.psfhosted.org>


Change by Tin Tvrtkovi? <tinchester at gmail.com>:


----------
pull_requests: +29561
pull_request: https://github.com/python/cpython/pull/31415

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Fri Feb 18 23:07:31 2022
From: report at bugs.python.org (Ned Deily)
Date: Sat, 19 Feb 2022 04:07:31 +0000
Subject: [issue46400] Please update bundled libexpat to 2.4.4 with security
 fixes (CVE-2021-45960)
In-Reply-To: <1642350760.98.0.31451148779.issue46400@roundup.psfhosted.org>
Message-ID: <1645243651.33.0.666713109349.issue46400@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

expat 2.4.5 was released today (Issue46794).

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46400>
_______________________________________

From report at bugs.python.org  Fri Feb 18 23:39:29 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 19 Feb 2022 04:39:29 +0000
Subject: [issue45390] asyncio.Task doesn't propagate CancelledError()
 exception correctly.
In-Reply-To: <1633519842.27.0.396754460358.issue45390@roundup.psfhosted.org>
Message-ID: <1645245569.22.0.204523328566.issue45390@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/issue45390>
_______________________________________

From report at bugs.python.org  Sat Feb 19 00:24:06 2022
From: report at bugs.python.org (Dennis Sweeney)
Date: Sat, 19 Feb 2022 05:24:06 +0000
Subject: [issue46615] Use-after-free by mutating set during set operations
In-Reply-To: <1643824882.75.0.278611227582.issue46615@roundup.psfhosted.org>
Message-ID: <1645248246.15.0.784994031109.issue46615@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

It does look like there are some pickle situations that crash. Attached is a randomized crasher. I haven't done too much careful reasoning about it, but adding INCREFs everywhere seems to fix most of the issues.

----------
Added file: https://bugs.python.org/file50631/picklecrasher.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46615>
_______________________________________

From report at bugs.python.org  Sat Feb 19 00:25:14 2022
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 19 Feb 2022 05:25:14 +0000
Subject: [issue46066] Deprecate keyword args syntax for TypedDict definition
In-Reply-To: <1639409817.42.0.21314101687.issue46066@roundup.psfhosted.org>
Message-ID: <1645248314.03.0.997622750453.issue46066@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This change has introduced deprecation warning in tests

PYTHONWARNINGS=always ./python -Wall -X dev -m test.test_typing     
........................................................................................................................................................................................................................s................................................................................................................................................................................................./home/karthikeyan/stuff/python/cpython/Lib/test/test_typing.py:4589: DeprecationWarning: The kwargs-based syntax for TypedDict definitions is deprecated in Python 3.11, will be removed in Python 3.13, and may not be understood by third-party type checkers.
  TypedDict('Emp', _fields={'name': str, 'id': int})
./home/karthikeyan/stuff/python/cpython/Lib/test/test_typing.py:4602: DeprecationWarning: The kwargs-based syntax for TypedDict definitions is deprecated in Python 3.11, will be removed in Python 3.13, and may not be understood by third-party type checkers.
  TypedDict('Hi', x=1)
........................................
----------------------------------------------------------------------
Ran 451 tests in 0.105s

OK (skipped=1)

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46066>
_______________________________________

From report at bugs.python.org  Sat Feb 19 00:28:28 2022
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 19 Feb 2022 05:28:28 +0000
Subject: [issue46730] Please consider mentioning property without setter when
 an attribute can't be set
In-Reply-To: <1644664548.7.0.814482728123.issue46730@roundup.psfhosted.org>
Message-ID: <1645248508.57.0.451610731164.issue46730@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

The test introduces a deprecation warning. It might be fixed by using raw string like the msg_format used in other test.


./python -Wall -m py_compile Lib/test/test_property.py
Lib/test/test_property.py:345: DeprecationWarning: invalid escape sequence '\.'
  msg_format = "^property of 'PropertyUnreachableAttributeNoName\.cls' object {}$"

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46730>
_______________________________________

From report at bugs.python.org  Sat Feb 19 00:31:11 2022
From: report at bugs.python.org (sjndlnv brjkbn)
Date: Sat, 19 Feb 2022 05:31:11 +0000
Subject: [issue46782] Docs error for 3.10
In-Reply-To: <1645121541.07.0.568386298101.issue46782@roundup.psfhosted.org>
Message-ID: <1645248671.1.0.348373478763.issue46782@roundup.psfhosted.org>


sjndlnv brjkbn <usetohandletrush at gmail.com> added the comment:

I found out that this issue can be fixed by set ``autodoc_preserve_defaults`` to True [(From sphinx-doc)](https://www.sphinx-doc.org/en/master/usage/extensions/autodoc.html#confval-autodoc_preserve_defaults)

On the other hand. I test ``Path.mkdir(mode=511)`` on my mac. It's the same as ``Path.mkdir(mode=0o77)``

But it's not the same on my company's dev linux server.

I will double check this part on Monday.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46782>
_______________________________________

From report at bugs.python.org  Sat Feb 19 00:36:47 2022
From: report at bugs.python.org (Dennis Sweeney)
Date: Sat, 19 Feb 2022 05:36:47 +0000
Subject: [issue46730] Please consider mentioning property without setter when
 an attribute can't be set
In-Reply-To: <1644664548.7.0.814482728123.issue46730@roundup.psfhosted.org>
Message-ID: <1645249007.9.0.398567835017.issue46730@roundup.psfhosted.org>


Change by Dennis Sweeney <sweeney.dennis650 at gmail.com>:


----------
pull_requests: +29562
pull_request: https://github.com/python/cpython/pull/31427

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46730>
_______________________________________

From report at bugs.python.org  Sat Feb 19 00:48:03 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Sat, 19 Feb 2022 05:48:03 +0000
Subject: [issue44791] Substitution of ParamSpec in Concatenate
In-Reply-To: <1627727114.02.0.621938171006.issue44791@roundup.psfhosted.org>
Message-ID: <1645249683.94.0.613672747287.issue44791@roundup.psfhosted.org>


Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:

I'm looking at https://github.com/python/cpython/pull/30969 and I'm not sure what the motivation for the change is. PEP 612 is quite precise here (https://www.python.org/dev/peps/pep-0612/#id1) and allows only a ParamSpec as the last argument to Concatenate.

What is the use case for using ... as the last argument? What should it mean to a static type checker?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44791>
_______________________________________

From report at bugs.python.org  Sat Feb 19 00:57:51 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Sat, 19 Feb 2022 05:57:51 +0000
Subject: [issue46066] Deprecate keyword args syntax for TypedDict definition
In-Reply-To: <1639409817.42.0.21314101687.issue46066@roundup.psfhosted.org>
Message-ID: <1645250271.53.0.173319009703.issue46066@roundup.psfhosted.org>


Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:

Thanks, I'll send a PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46066>
_______________________________________

From report at bugs.python.org  Sat Feb 19 01:02:02 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Sat, 19 Feb 2022 06:02:02 +0000
Subject: [issue46066] Deprecate keyword args syntax for TypedDict definition
In-Reply-To: <1639409817.42.0.21314101687.issue46066@roundup.psfhosted.org>
Message-ID: <1645250522.09.0.631019967451.issue46066@roundup.psfhosted.org>


Change by Jelle Zijlstra <jelle.zijlstra at gmail.com>:


----------
pull_requests: +29563
pull_request: https://github.com/python/cpython/pull/31428

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46066>
_______________________________________

From report at bugs.python.org  Sat Feb 19 01:42:30 2022
From: report at bugs.python.org (Meer Suri)
Date: Sat, 19 Feb 2022 06:42:30 +0000
Subject: [issue46586] In documentation contents enum.property erroneously
 links to built-in property
In-Reply-To: <1643555525.86.0.209520180874.issue46586@roundup.psfhosted.org>
Message-ID: <1645252950.89.0.843935605353.issue46586@roundup.psfhosted.org>


Change by Meer Suri <meersuri at gmail.com>:


----------
pull_requests: +29564
pull_request: https://github.com/python/cpython/pull/31429

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46586>
_______________________________________

From report at bugs.python.org  Sat Feb 19 01:59:26 2022
From: report at bugs.python.org (zjmxq)
Date: Sat, 19 Feb 2022 06:59:26 +0000
Subject: [issue46795] Why does
 3rd/Python39/Lib/site-packages/psycopg2/_psycopg.cp39-win_amd64.pyd have the
 CVE-201-4160 vulnerability when I use Python 3.9.2
Message-ID: <1645253966.69.0.935118725759.issue46795@roundup.psfhosted.org>


Change by zjmxq <zjmxq180 at 163.com>:


----------
components: Library (Lib)
nosy: zjmxq
priority: normal
severity: normal
status: open
title: Why does 3rd/Python39/Lib/site-packages/psycopg2/_psycopg.cp39-win_amd64.pyd have the CVE-201-4160 vulnerability when I use Python 3.9.2
type: security
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46795>
_______________________________________

From report at bugs.python.org  Sat Feb 19 02:01:08 2022
From: report at bugs.python.org (zjmxq)
Date: Sat, 19 Feb 2022 07:01:08 +0000
Subject: [issue46795] Why Does
 3rd/Python39/Lib/site-packages/psycopg2/_psycopg.cp39-win_amd64.pyd Have the
 CVE-20211-4160 Vulnerability? I Use Python 3.9.2? Where Is OpenSSL Used?
Message-ID: <1645254068.76.0.969952477089.issue46795@roundup.psfhosted.org>


Change by zjmxq <zjmxq180 at 163.com>:


----------
title: Why does 3rd/Python39/Lib/site-packages/psycopg2/_psycopg.cp39-win_amd64.pyd have the CVE-201-4160 vulnerability when I use Python 3.9.2 -> Why Does 3rd/Python39/Lib/site-packages/psycopg2/_psycopg.cp39-win_amd64.pyd Have the CVE-20211-4160 Vulnerability? I Use Python 3.9.2? Where Is OpenSSL Used?

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46795>
_______________________________________

From report at bugs.python.org  Sat Feb 19 02:09:51 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Sat, 19 Feb 2022 07:09:51 +0000
Subject: [issue46757] dataclasses should define an empty __post_init__
In-Reply-To: <1644923607.6.0.495534870715.issue46757@roundup.psfhosted.org>
Message-ID: <1645254591.59.0.820107811012.issue46757@roundup.psfhosted.org>


Nikita Sobolev <mail at sobolevn.me> added the comment:

I like this idea.

`attrs` right now behave the same way (no default `__attrs_post_init__`:

```
>>> import attrs
>>> @attrs.define
... class Some:
...   x: int
... 
>>> @attrs.define
... class Other(Some):
...    def __attrs_post_init__(self):
...       super().__attrs_post_init__()
...       self.x += 1
... 
>>> Other(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<attrs generated init __main__.Other>", line 3, in __init__
  File "<stdin>", line 4, in __attrs_post_init__
AttributeError: 'super' object has no attribute '__attrs_post_init__'
```

I am attaching a simple patch.

Alternative solution is to not merge this patch and recommend this instead:

```
def __post_init__(self):
  try:
    super().__post_init__()
  except AttributeError:
    pass
```

----------
nosy: +sobolevn

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46757>
_______________________________________

From report at bugs.python.org  Sat Feb 19 02:12:06 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Sat, 19 Feb 2022 07:12:06 +0000
Subject: [issue46757] dataclasses should define an empty __post_init__
In-Reply-To: <1644923607.6.0.495534870715.issue46757@roundup.psfhosted.org>
Message-ID: <1645254726.55.0.674990693059.issue46757@roundup.psfhosted.org>


Change by Nikita Sobolev <mail at sobolevn.me>:


----------
keywords: +patch
pull_requests: +29565
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31430

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46757>
_______________________________________

From report at bugs.python.org  Sat Feb 19 02:18:26 2022
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 19 Feb 2022 07:18:26 +0000
Subject: [issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys
In-Reply-To: <1429890469.94.0.27310602141.issue24053@psf.upfronthosting.co.za>
Message-ID: <1645255106.23.0.438287687205.issue24053@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

> Any reasons the PR still not merged?

There was dissent about whether these constants should be added or not. It doesn't help to merge a PR that is not expected to provide a benefit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24053>
_______________________________________

From report at bugs.python.org  Sat Feb 19 02:42:14 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Sat, 19 Feb 2022 07:42:14 +0000
Subject: [issue46757] dataclasses should define an empty __post_init__
In-Reply-To: <1644923607.6.0.495534870715.issue46757@roundup.psfhosted.org>
Message-ID: <1645256534.02.0.533316611485.issue46757@roundup.psfhosted.org>


Change by Nikita Sobolev <mail at sobolevn.me>:


----------
type:  -> behavior
versions: +Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46757>
_______________________________________

From report at bugs.python.org  Sat Feb 19 02:51:27 2022
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Sat, 19 Feb 2022 07:51:27 +0000
Subject: [issue46757] dataclasses should define an empty __post_init__
In-Reply-To: <1644923607.6.0.495534870715.issue46757@roundup.psfhosted.org>
Message-ID: <1645257087.62.0.557266399264.issue46757@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

That "except AttributeError" approach is a powerful bug magnet, since it can very easily mask real attribute errors stemming from misspelled attribute names in the __post_init__ call itself. What you should _really_ do is

    def __post_init__(self):
        with contextlib.suppress(AttributeError):
            post_init = super().__post_init__
        post_init()

But of course, nobody will ever write that.

Raymond in his "super considered super" video (https://youtu.be/xKgELVmrqfs?t=2068) says the right thing to do is to make your own root which knows exactly what classes it manages, and drops the supercalls from them (after possibly verifying that all kwargs have actually been used and so on).

But in case of dataclasses, usually any class can serve as such a root, and the main reason people use dataclasses is to avoid boilerplate code. So I think it would be a nice compromise.

----------
nosy: +veky

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46757>
_______________________________________

From report at bugs.python.org  Sat Feb 19 02:56:05 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 19 Feb 2022 07:56:05 +0000
Subject: [issue46796] Simplify handling of removed parameter "loop" in asyncio
Message-ID: <1645257365.33.0.518204757476.issue46796@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Before 3.10 many asyncio classes did have an optional parameter "loop". It was deprecated in 3.8. To simplify the code, such classes inherited a constructor from _LoopBoundMixin which set the _loop attribute and (since 3.8) emitted a warning if the loop argument was passed. Since 3.10 the _LoopBoundMixin no longer sets the _loop attribute and always raises a TypeError if the loop argument is passed.

The same effect can be achieved if just remove the loop parameter (and the _LoopBoundMixin constructor as it will do nothing). The only difference in the error message: it will be standard "Lock.__init__() got an unexpected keyword argument 'loop'" instead of "As of 3.10, the *loop* parameter was removed from Lock() since it is no longer necessary". Usually we do not keep specialized error messages for removed parameters.

----------
components: asyncio
messages: 413539
nosy: asvetlov, serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: Simplify handling of removed parameter "loop" in asyncio
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46796>
_______________________________________

From report at bugs.python.org  Sat Feb 19 02:57:14 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 19 Feb 2022 07:57:14 +0000
Subject: [issue46796] Simplify handling of removed parameter "loop" in asyncio
In-Reply-To: <1645257365.33.0.518204757476.issue46796@roundup.psfhosted.org>
Message-ID: <1645257434.51.0.235259334504.issue46796@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +29566
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31431

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46796>
_______________________________________

From report at bugs.python.org  Sat Feb 19 03:03:29 2022
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 19 Feb 2022 08:03:29 +0000
Subject: [issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys
In-Reply-To: <1429890469.94.0.27310602141.issue24053@psf.upfronthosting.co.za>
Message-ID: <1645257809.46.0.881489269872.issue24053@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy:  -mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24053>
_______________________________________

From report at bugs.python.org  Sat Feb 19 03:07:03 2022
From: report at bugs.python.org (Neil Girdhar)
Date: Sat, 19 Feb 2022 08:07:03 +0000
Subject: [issue46757] dataclasses should define an empty __post_init__
In-Reply-To: <1645257087.62.0.557266399264.issue46757@roundup.psfhosted.org>
Message-ID: <CAA68w_mjWMnosBfU5EQEp4csM9waO8eon5Bh6ywZJ1-4YisQoQ@mail.gmail.com>


Neil Girdhar <mistersheik at gmail.com> added the comment:

On Sat, Feb 19, 2022 at 2:51 AM Vedran ?a?i? <report at bugs.python.org> wrote:

>
> Vedran ?a?i? <vedgar at gmail.com> added the comment:
>
> That "except AttributeError" approach is a powerful bug magnet, since it
> can very easily mask real attribute errors stemming from misspelled
> attribute names in the __post_init__ call itself. What you should _really_
> do is
>
>     def __post_init__(self):
>         with contextlib.suppress(AttributeError):
>             post_init = super().__post_init__
>         post_init()
>
> But of course, nobody will ever write that.
>
> Great point!

Raymond in his "super considered super" video (
> https://youtu.be/xKgELVmrqfs?t=2068) says the right thing to do is to
> make your own root which knows exactly what classes it manages, and drops
> the supercalls from them (after possibly verifying that all kwargs have
> actually been used and so on).
>
> But in case of dataclasses, usually any class can serve as such a root,
> and the main reason people use dataclasses is to avoid boilerplate code. So
> I think it would be a nice compromise.
>

I'm not sure I understand what you're saying here.  Anyone can inherit from
a class C with the special root and some other class D, and then your
introduced root won't catch D's super calls.

>
> ----------
> nosy: +veky
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue46757>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46757>
_______________________________________

From report at bugs.python.org  Sat Feb 19 03:09:43 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 19 Feb 2022 08:09:43 +0000
Subject: [issue46777] Fix incorrect use of directives in asyncio documentation
In-Reply-To: <1645102456.61.0.455925245808.issue46777@roundup.psfhosted.org>
Message-ID: <1645258183.05.0.444222809023.issue46777@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/issue46777>
_______________________________________

From report at bugs.python.org  Sat Feb 19 03:29:17 2022
From: report at bugs.python.org (Jakub Wilk)
Date: Sat, 19 Feb 2022 08:29:17 +0000
Subject: [issue46797] ast.Constant.n deprecated without warning
Message-ID: <1645259356.98.0.34127429103.issue46797@roundup.psfhosted.org>


New submission from Jakub Wilk <jwilk at jwilk.net>:

ast.Constant.n is documented to be deprecated, but you don't get any warning when you use it:

$ python3.11 -Wd
Python 3.11.0a5 (main, Feb 12 2022, 17:11:59) [GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ast
>>> help(ast.Constant.n)
Help on property:

    Deprecated. Use value instead.

>>> ast.Constant(value=42).n
42

----------
components: Library (Lib)
messages: 413541
nosy: jwilk, serhiy.storchaka
priority: normal
severity: normal
status: open
title: ast.Constant.n deprecated without warning
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46797>
_______________________________________

From report at bugs.python.org  Sat Feb 19 03:37:07 2022
From: report at bugs.python.org (zjmxq)
Date: Sat, 19 Feb 2022 08:37:07 +0000
Subject: [issue46795] Why Does
 3rd/Python39/Lib/site-packages/psycopg2/_psycopg.cp39-win_amd64.pyd Have the
 CVE-2021-3711 CVE-2021-23840 CVE-2021-3450 CVE-2021-3712 CVE-2021-23841
 CVE-2021-3449 CVE-2021-4160 Vulnerability? I Use Python 3.9.2? Where Is
 OpenSSL Used?
Message-ID: <1645259827.87.0.127351370598.issue46795@roundup.psfhosted.org>


Change by zjmxq <zjmxq180 at 163.com>:


----------
title: Why Does 3rd/Python39/Lib/site-packages/psycopg2/_psycopg.cp39-win_amd64.pyd Have the CVE-20211-4160 Vulnerability? I Use Python 3.9.2? Where Is OpenSSL Used? -> Why Does 3rd/Python39/Lib/site-packages/psycopg2/_psycopg.cp39-win_amd64.pyd Have the CVE-2021-3711 CVE-2021-23840 CVE-2021-3450 CVE-2021-3712 CVE-2021-23841 CVE-2021-3449 CVE-2021-4160 Vulnerability? I Use Python 3.9.2? Where Is OpenSSL Used?

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46795>
_______________________________________

From report at bugs.python.org  Sat Feb 19 05:49:50 2022
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 19 Feb 2022 10:49:50 +0000
Subject: [issue46782] Docs error for 3.10
In-Reply-To: <1645121541.07.0.568386298101.issue46782@roundup.psfhosted.org>
Message-ID: <1645267790.88.0.18214129638.issue46782@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> added the comment:

Octal 777 is really the same as decimal 511.
If you are calling mkdir and looking at the permissions on the created directory, you may think the mode is wrong because of umask (default permission bitmask that?s applied to the mode).  But the numbers are really equivalent, we are only talking about a doc presentation issue here, not any problem in code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46782>
_______________________________________

From report at bugs.python.org  Sat Feb 19 06:31:31 2022
From: report at bugs.python.org (padremayi)
Date: Sat, 19 Feb 2022 11:31:31 +0000
Subject: [issue46798] xml.etree.ElementTree: get() doesn't return default
 value, always ATTLIST value
Message-ID: <1645270291.57.0.995603390679.issue46798@roundup.psfhosted.org>


New submission from padremayi <francesco.other at gmail.com>:

XML test file:

<?xml version="1.0"?>
<!DOCTYPE main [
<!ELEMENT main (object+)>
    <!ELEMENT object (description, year, manufacturer)>
        <!ATTLIST object name CDATA #REQUIRED>
        <!ATTLIST object works (yes|no) "yes">
        <!ELEMENT description (#PCDATA)>
        <!ELEMENT year (#PCDATA)>
        <!ELEMENT manufacturer (#PCDATA)>
]>

<main>
    <object name="My object">
        <description>This is a simple object</description>
        <year>2022</year>
        <manufacturer>Myself</manufacturer>
    </object>
</main>


Python code:
import xml.etree.ElementTree


try:
    xml_data = xml.etree.ElementTree.iterparse("test.xml", events=("start", "end"))

    for event, xml_tag in xml_data:
        if event == "end" and xml_tag.tag == "object":
            object_name = xml_tag.get("name")
            object_description = xml_tag.find("description").text
            works = xml_tag.get("works", default="foo")

            print("works value: " + str(works))

            xml_tag.clear()

    print("Done!")

except (NameError, xml.etree.ElementTree.ParseError):
    print("XML error!")


Output:
works value: yes
Done!


Expected behaviour:
works value: foo
Done!

----------
components: XML
messages: 413543
nosy: padremayi
priority: normal
severity: normal
status: open
title: xml.etree.ElementTree: get() doesn't return default value, always ATTLIST value
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46798>
_______________________________________

From report at bugs.python.org  Sat Feb 19 07:02:30 2022
From: report at bugs.python.org (Ting-Che Lin)
Date: Sat, 19 Feb 2022 12:02:30 +0000
Subject: [issue46799] ShareableList memory bloat and performance improvement
Message-ID: <1645272150.7.0.530571625794.issue46799@roundup.psfhosted.org>


New submission from Ting-Che Lin <lintingche2012 at gmail.com>:

The current implementation of ShareableList keeps an unnecessary list of offsets in self._allocated_offsets. This list could have a large memory footprint if the number of items in the list is high. Additionally, this list will be copied in each process that needs access to the ShareableList, sometimes negating the benefit of the shared memory. Furthermore, in the current implementation, different metadata is kept at different sections of shared memory, requiring multiple struck.unpack_from calls for a __getitem__ call. I have attached a prototype that merged the allocated offsets and packing format into a single section in the shared memory. This allows us to use single struck.unpack_from operation to obtain both the allocated offset and the packing format. By removing the self._allocated_offset list and reducing the number of struck.unpack_from operations, we can drastically reduce the memory usage and increase the reading performance by 10%. In the case where there are only integers in the ShareableList, we can reduce the memory usage by half. The attached implementation also fixed the issue https://bugs.python.org/issue44170 that causes error when reading some Unicode characters. I am happy to adapt this implementation into a proper bugfix/patch if it is deemed reasonable.

----------
components: Library (Lib)
files: shareable_list.py
messages: 413544
nosy: davin, pitrou, tcl326
priority: normal
severity: normal
status: open
title: ShareableList memory bloat and performance improvement
type: performance
versions: Python 3.10, Python 3.11, Python 3.9
Added file: https://bugs.python.org/file50632/shareable_list.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46799>
_______________________________________

From report at bugs.python.org  Sat Feb 19 07:05:17 2022
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 19 Feb 2022 12:05:17 +0000
Subject: [issue46791] Allow os.remove to defer to rmdir
In-Reply-To: <1645206913.87.0.447648839641.issue46791@roundup.psfhosted.org>
Message-ID: <1645272317.95.0.416835249315.issue46791@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

In Windows, checking for a directory in order to defer to either os_rmdir_impl() or os_unlink_impl() would lead to a redundant directory check. os_unlink_impl() already has to check for a directory in order to delete a directory symlink or mountpoint. I suggest implementing a common _Py_remove() function in Windows. For example:

    typedef enum {
        REMOVE_FILE,
        REMOVE_DIR,
        REMOVE_BOTH,
    } _Py_remove_mode;

    int
    _Py_remove(path_t *path, _Py_remove_mode mode)
    {
        BOOL isDir = FALSE;
        BOOL isLnk = FALSE;
        BOOL success = FALSE;

        if (mode != REMOVE_DIR) {
            DWORD fileAttributes = GetFileAttributesW(path->wide);
            if (fileAttributes != INVALID_FILE_ATTRIBUTES) {
                isDir = fileAttributes & FILE_ATTRIBUTE_DIRECTORY;
            }

            if (isDir && (mode == REMOVE_FILE)) {
                WIN32_FIND_DATAW data;
                HANDLE hFind = FindFirstFileW(path->wide, &data);
                if (hFind != INVALID_HANDLE_VALUE) {
                    FindClose(hFind);
                    if (data.dwFileAttributes & FILE_ATTRIBUTE_REPARSE_POINT) {
                        isLnk = IsReparseTagNameSurrogate(data.dwReserved0);
                    }
                }
            }
        }

        if (mode == REMOVE_DIR || isDir && (mode == REMOVE_BOTH || isLnk)) {
            success = RemoveDirectoryW(path->wide);
        } else {
            success = DeleteFileW(path->wide);
        }
        
        return success ? 0 : -1;
    }

The multiple opens for GetFileAttributesW(), FindFirstFileW() and DeleteFileW() add up to make the delete more expensive and more race prone than it has to be. It would be nice to use a single open for all operations. But the Windows API just has CreateFileW(), which requires SYNCHRONIZE access. The latter can't be granted by the parent directory, unlike FILE_READ_ATTRIBUTES and DELETE access. We could implement a version that uses CreateFileW(), and fall back on the above version when access is denied, similar to what we do for os.stat(). Also, Python is limited to the Windows 8.1 SDK, which makes it awkward to use FileDispositionInfoEx (POSIX delete) like DeleteFileW() does in Windows 10, but it should still be possible.

----------
nosy: +eryksun
stage:  -> needs patch
versions: +Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46791>
_______________________________________

From report at bugs.python.org  Sat Feb 19 07:22:18 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 19 Feb 2022 12:22:18 +0000
Subject: [issue46797] ast.Constant.n deprecated without warning
In-Reply-To: <1645259356.98.0.34127429103.issue46797@roundup.psfhosted.org>
Message-ID: <1645273338.63.0.63171459796.issue46797@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +29567
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31432

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46797>
_______________________________________

From report at bugs.python.org  Sat Feb 19 07:24:07 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 19 Feb 2022 12:24:07 +0000
Subject: [issue46797] ast.Constant.n deprecated without warning
In-Reply-To: <1645259356.98.0.34127429103.issue46797@roundup.psfhosted.org>
Message-ID: <1645273447.92.0.121371213926.issue46797@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It is because we did not have a plan for removing deprecates features. Deprecation in documentation only helps third-party code. Instead of adding a complex code which switches between using old and new names depending on Python version, the third-party code can continue to use old names without worring about deprecation warnings, and switch completely to using new features only when support of old Python versions be dropped. 3.7 and 3.8 are not so old and may be still supported in third-party code.

I have created a PR which adds deprecation warnings, but I am not sure that it is worth to include it in 3.11.

----------
priority: normal -> low
resolution:  -> postponed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46797>
_______________________________________

From report at bugs.python.org  Sat Feb 19 07:27:19 2022
From: report at bugs.python.org (Arie Bovenberg)
Date: Sat, 19 Feb 2022 12:27:19 +0000
Subject: [issue46200] Discourage logging f-strings due to security
 considerations
In-Reply-To: <1640850255.25.0.496981368409.issue46200@roundup.psfhosted.org>
Message-ID: <1645273639.97.0.399958390107.issue46200@roundup.psfhosted.org>


Arie Bovenberg <a.c.bovenberg at gmail.com> added the comment:

Thanks @gregory.p.smith! I didn't know about discuss.python.org. I created a new topic there: https://discuss.python.org/t/safer-logging-methods-for-f-strings-and-new-style-formatting/13802

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46200>
_______________________________________

From report at bugs.python.org  Sat Feb 19 07:46:37 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 19 Feb 2022 12:46:37 +0000
Subject: [issue46757] dataclasses should define an empty __post_init__
In-Reply-To: <1644923607.6.0.495534870715.issue46757@roundup.psfhosted.org>
Message-ID: <1645274797.99.0.190939485706.issue46757@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I'm not crazy about adding a method to every dataclass just for the 0.1% of the times it's needed.

I think using hasattr or catching the exception is a better way to go.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46757>
_______________________________________

From report at bugs.python.org  Sat Feb 19 08:23:12 2022
From: report at bugs.python.org (Sam Bull)
Date: Sat, 19 Feb 2022 13:23:12 +0000
Subject: [issue45098] asyncio.CancelledError should contain more information
 on cancellations
In-Reply-To: <1630761463.35.0.712522138496.issue45098@roundup.psfhosted.org>
Message-ID: <1645276992.82.0.791456846231.issue45098@roundup.psfhosted.org>


Sam Bull <m6f6g7 at sambull.org> added the comment:

I think there's still a problem, in that the user still expects a task to be cancelled in the example previously: https://github.com/aio-libs/async-timeout/issues/229#issuecomment-908502523

If we encounter the race condition where the timeout cancels the task and then the user cancels the task, then we still have the case that async-timeout swallows the cancellation and the task will run forever. This would basically require the user to check everytime they want to cancel the task, with something awkward like:

```
while not task.cancel() and not task.cancelled():
    await asyncio.sleep(0)
```

I think this change is still necessary, but rather than adding multiple values to e.args, we can use the new ExceptionGroup to raise multiple CancelledErrors. So, each call of task.cancel() will create a new CancelledError, and then all of those CancelledErrors will get raised together.

For async-timeout, we can then just catch the CancelledError with our sentinel and raise a TimeoutError, while reraising any other CancelledErrors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45098>
_______________________________________

From report at bugs.python.org  Sat Feb 19 09:44:03 2022
From: report at bugs.python.org (sping)
Date: Sat, 19 Feb 2022 14:44:03 +0000
Subject: [issue46400] Please update bundled libexpat to 2.4.4 with security
 fixes (CVE-2021-45960)
In-Reply-To: <1642350760.98.0.31451148779.issue46400@roundup.psfhosted.org>
Message-ID: <1645281843.78.0.705965445135.issue46400@roundup.psfhosted.org>


sping <sebastian at pipping.org> added the comment:

Yes, I have already created bpo-46794 for 2.4.5.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46400>
_______________________________________

From report at bugs.python.org  Sat Feb 19 09:44:54 2022
From: report at bugs.python.org (sping)
Date: Sat, 19 Feb 2022 14:44:54 +0000
Subject: [issue46400] Please update bundled libexpat to 2.4.4 with security
 fixes (CVE-2021-45960)
In-Reply-To: <1642350760.98.0.31451148779.issue46400@roundup.psfhosted.org>
Message-ID: <1645281894.66.0.786741128973.issue46400@roundup.psfhosted.org>


sping <sebastian at pipping.org> added the comment:

Overlooked your reference, so you already know, my bad, nevermind.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46400>
_______________________________________

From report at bugs.python.org  Sat Feb 19 10:09:28 2022
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 19 Feb 2022 15:09:28 +0000
Subject: [issue46795] Why Does
 3rd/Python39/Lib/site-packages/psycopg2/_psycopg.cp39-win_amd64.pyd Have the
 CVE-2021-3711 CVE-2021-23840 CVE-2021-3450 CVE-2021-3712 CVE-2021-23841
 CVE-2021-3449 CVE-2021-4160 Vulnerability? I Use Python 3.9.2? Where Is
 OpenSSL Used?
Message-ID: <1645283368.47.0.23633171153.issue46795@roundup.psfhosted.org>


New submission from Zachary Ware <zachary.ware at gmail.com>:

Psycopg2 is a third-party package; questions about it should be directed to the Users category of discuss.python.org, the python-list mailing list, or a forum specific to psycopg2.

Also, note that Python 3.9.2 is well out of date; you should update to 3.9.10 or 3.10.2.  On Windows, OpenSSL is included with Python, and is most easily updated by updating Python.

And lastly, please use the comment field rather than cramming your comments into the title field.

----------
nosy: +zach.ware
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46795>
_______________________________________

From report at bugs.python.org  Sat Feb 19 12:13:14 2022
From: report at bugs.python.org (Neil Girdhar)
Date: Sat, 19 Feb 2022 17:13:14 +0000
Subject: [issue46757] dataclasses should define an empty __post_init__
In-Reply-To: <1644923607.6.0.495534870715.issue46757@roundup.psfhosted.org>
Message-ID: <1645290794.49.0.0234345786799.issue46757@roundup.psfhosted.org>


Neil Girdhar <mistersheik at gmail.com> added the comment:

> I'm not crazy about adding a method to every dataclass just for the 0.1% of the times it's needed.

I'm not sure I totally understand the cost here.  You can have a single shared global function that you set on each dataclass.  So the only cost would be an entry in each dataclass type's dict.  Even if a user creates a thousand dataclasses, that should only be tens of killobytes in pointers.

> I think using hasattr or catching the exception is a better way to go.

If you choose this, then I think this should be documented under the __post_init__ saying that any time you define __post_init__, you should either be a final class, or else call super.  If you call super, you musteither use hasattr(super().__post_init__) or catch the exception.

I have to admit, I find this quite ugly from a user perspective.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46757>
_______________________________________

From report at bugs.python.org  Sat Feb 19 12:24:27 2022
From: report at bugs.python.org (Philip Rowlands)
Date: Sat, 19 Feb 2022 17:24:27 +0000
Subject: [issue46800] Support for pause(2)
Message-ID: <1645291467.44.0.659055078048.issue46800@roundup.psfhosted.org>


New submission from Philip Rowlands <pythonbugs at dimebar.com>:

Went looking for os.pause() but found nothing in the docs, bpo, or Google.
https://man7.org/linux/man-pages/man2/pause.2.html

Obviously not a popular syscall, but I have a use case for it.

----------
components: Library (Lib)
messages: 413554
nosy: philiprowlands
priority: normal
severity: normal
status: open
title: Support for pause(2)
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46800>
_______________________________________

From report at bugs.python.org  Sat Feb 19 12:44:03 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 19 Feb 2022 17:44:03 +0000
Subject: [issue46757] dataclasses should define an empty __post_init__
In-Reply-To: <1644923607.6.0.495534870715.issue46757@roundup.psfhosted.org>
Message-ID: <1645292643.34.0.850638654611.issue46757@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

The fact that it's never been needed in the years that dataclasses and attrs have existed tell me it's kind of a niche requirement.

This does not seem like the ugliest code I've ever seen:

        if hasattr(super(), "__post_init__"):
            super().__post_init__()

or the probably more efficient, but more lines of code:

        try:
            post_init = super().__post_init__
        except AttributeError:
            pass
        else:
            post_init()

As always with calling super functions, the whole hierarchy needs to cooperate. Say you had a dataclass:

@dataclass
class Base:
    def __post_init__(self, some_arg):
        pass

How would an arbitrary derived class know how to call this? It can't. There has to be knowledge of the base class's requirements already. Surely knowing "__post_init__ must be called with some_arg" isn't too different from "I know __post_init__ doesn't exist". I don't think adding ways to make the "always call super" pattern easier is a good idea.

I'm still unconvinced, but I'll hold off on making a decision to see if there's more support. Maybe taking it to python-ideas would be worthwhile.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46757>
_______________________________________

From report at bugs.python.org  Sat Feb 19 13:01:07 2022
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 19 Feb 2022 18:01:07 +0000
Subject: [issue46800] Support for pause(2)
In-Reply-To: <1645291467.44.0.659055078048.issue46800@roundup.psfhosted.org>
Message-ID: <1645293667.75.0.163389783954.issue46800@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

See signal.pause: https://docs.python.org/3/library/signal.html#signal.pause

----------
nosy: +zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46800>
_______________________________________

From report at bugs.python.org  Sat Feb 19 13:34:32 2022
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 19 Feb 2022 18:34:32 +0000
Subject: [issue46761] functools.update_wrapper breaks the signature of
 functools.partial objects
In-Reply-To: <1644948374.87.0.765462873315.issue46761@roundup.psfhosted.org>
Message-ID: <1645295672.73.0.0365276976085.issue46761@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

Yury, Ka-Ping, can you guys shed any light on this?  Your names are still on inspect.py.

----------
nosy: +ping, yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46761>
_______________________________________

From report at bugs.python.org  Sat Feb 19 14:36:56 2022
From: report at bugs.python.org (Irit Katriel)
Date: Sat, 19 Feb 2022 19:36:56 +0000
Subject: [issue46801] test_typing emits deprecation warnings
Message-ID: <1645299416.66.0.862941946832.issue46801@roundup.psfhosted.org>


New submission from Irit Katriel <iritkatriel at gmail.com>:

======================================================================
ERROR: test_typeddict_create_errors (test.test_typing.TypedDictTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_typing.py", line 4589, in test_typeddict_create_errors
    TypedDict('Emp', _fields={'name': str, 'id': int})
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/typing.py", line 2609, in TypedDict
    warnings.warn(
    ^^^^^^^^^^^^^^
DeprecationWarning: The kwargs-based syntax for TypedDict definitions is deprecated in Python 3.11, will be removed in Python 3.13, and may not be understood by third-party type checkers.

======================================================================
ERROR: test_typeddict_errors (test.test_typing.TypedDictTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython-1/Lib/test/test_typing.py", line 4602, in test_typeddict_errors
    TypedDict('Hi', x=1)
    ^^^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-1/Lib/typing.py", line 2609, in TypedDict
    warnings.warn(
    ^^^^^^^^^^^^^^
DeprecationWarning: The kwargs-based syntax for TypedDict definitions is deprecated in Python 3.11, will be removed in Python 3.13, and may not be understood by third-party type checkers.

----------
components: Tests
messages: 413558
nosy: iritkatriel
priority: normal
severity: normal
status: open
title: test_typing emits deprecation warnings
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46801>
_______________________________________

From report at bugs.python.org  Sat Feb 19 14:38:47 2022
From: report at bugs.python.org (Irit Katriel)
Date: Sat, 19 Feb 2022 19:38:47 +0000
Subject: [issue46801] test_typing emits deprecation warnings
In-Reply-To: <1645299416.66.0.862941946832.issue46801@roundup.psfhosted.org>
Message-ID: <1645299527.72.0.682031927139.issue46801@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at gmail.com>:


----------
keywords: +patch
pull_requests: +29568
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31433

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46801>
_______________________________________

From report at bugs.python.org  Sat Feb 19 14:43:05 2022
From: report at bugs.python.org (Irit Katriel)
Date: Sat, 19 Feb 2022 19:43:05 +0000
Subject: [issue46801] test_typing emits deprecation warnings
In-Reply-To: <1645299416.66.0.862941946832.issue46801@roundup.psfhosted.org>
Message-ID: <1645299785.14.0.829648605222.issue46801@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at gmail.com>:


----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46801>
_______________________________________

From report at bugs.python.org  Sat Feb 19 18:06:15 2022
From: report at bugs.python.org (Jonathan)
Date: Sat, 19 Feb 2022 23:06:15 +0000
Subject: [issue46802] Wrong result unpacking binary data with ctypes bitfield.
Message-ID: <1645311975.58.0.202718468445.issue46802@roundup.psfhosted.org>


New submission from Jonathan <jon.hahn at posteo.de>:

I have issues unpacking binary data, produced by C++. The appended jupyter notebook shows the problem. It is also uploaded to github gist: https://gist.github.com/helo9/04125ae67b493e505d5dce4b254a2ccc

----------
components: ctypes
files: ctypes_bitfield_problem.ipynb
messages: 413559
nosy: helo9
priority: normal
severity: normal
status: open
title: Wrong result unpacking binary data with ctypes bitfield.
type: behavior
versions: Python 3.10
Added file: https://bugs.python.org/file50633/ctypes_bitfield_problem.ipynb

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46802>
_______________________________________

From report at bugs.python.org  Sat Feb 19 18:32:37 2022
From: report at bugs.python.org (Jonathan)
Date: Sat, 19 Feb 2022 23:32:37 +0000
Subject: [issue46802] Wrong result unpacking binary data with ctypes bitfield.
In-Reply-To: <1645311975.58.0.202718468445.issue46802@roundup.psfhosted.org>
Message-ID: <1645313557.34.0.117407660636.issue46802@roundup.psfhosted.org>


Change by Jonathan <jon.hahn at posteo.de>:


----------
nosy:  -helo9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46802>
_______________________________________

From report at bugs.python.org  Sat Feb 19 19:16:51 2022
From: report at bugs.python.org (Dennis Sweeney)
Date: Sun, 20 Feb 2022 00:16:51 +0000
Subject: [issue46802] Wrong result unpacking binary data with ctypes bitfield.
In-Reply-To: <1645311975.58.0.202718468445.issue46802@roundup.psfhosted.org>
Message-ID: <1645316211.72.0.550862281275.issue46802@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

Possible duplicate of https://bugs.python.org/issue29753

----------
nosy: +Dennis Sweeney

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46802>
_______________________________________

From report at bugs.python.org  Sat Feb 19 19:30:50 2022
From: report at bugs.python.org (Jonathan)
Date: Sun, 20 Feb 2022 00:30:50 +0000
Subject: [issue46802] Wrong result unpacking binary data with ctypes bitfield.
In-Reply-To: <1645311975.58.0.202718468445.issue46802@roundup.psfhosted.org>
Message-ID: <1645317050.69.0.129579741575.issue46802@roundup.psfhosted.org>


Jonathan <jon.hahn at posteo.de> added the comment:

True, have to admit, that I forgot to search first, that really looks like it is the same problem, especially when looking at https://bugs.python.org/msg289212. Would say this one can be closed.

----------
nosy: +helo9
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46802>
_______________________________________

From report at bugs.python.org  Sat Feb 19 20:44:58 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Sun, 20 Feb 2022 01:44:58 +0000
Subject: [issue46066] Deprecate keyword args syntax for TypedDict definition
In-Reply-To: <1639409817.42.0.21314101687.issue46066@roundup.psfhosted.org>
Message-ID: <1645321498.64.0.854475626137.issue46066@roundup.psfhosted.org>


Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:


New changeset 0a8a8e7454c6565cf1554d5f23314e4c70960bcd by Jelle Zijlstra in branch 'main':
bpo-46066: Check DeprecationWarning in test_typing (GH-31428)
https://github.com/python/cpython/commit/0a8a8e7454c6565cf1554d5f23314e4c70960bcd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46066>
_______________________________________

From report at bugs.python.org  Sat Feb 19 22:30:25 2022
From: report at bugs.python.org (neonene)
Date: Sun, 20 Feb 2022 03:30:25 +0000
Subject: [issue45116] Performance regression 3.10b1: inlining issue in the big
 _PyEval_EvalFrameDefault() function with Visual Studio (MSC)
In-Reply-To: <1630942038.24.0.156228540374.issue45116@roundup.psfhosted.org>
Message-ID: <1645327825.21.0.403529991725.issue45116@roundup.psfhosted.org>


Change by neonene <nicesalmon at gmail.com>:


----------
pull_requests: +29570
pull_request: https://github.com/python/cpython/pull/31436

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45116>
_______________________________________

From report at bugs.python.org  Sat Feb 19 23:10:06 2022
From: report at bugs.python.org (Jack O'Connor)
Date: Sun, 20 Feb 2022 04:10:06 +0000
Subject: [issue39298] add BLAKE3 to hashlib
In-Reply-To: <1578716860.16.0.194711020268.issue39298@roundup.psfhosted.org>
Message-ID: <1645330206.35.0.387462765849.issue39298@roundup.psfhosted.org>


Jack O'Connor <oconnor663 at gmail.com> added the comment:

Yes, everything in https://github.com/BLAKE3-team/BLAKE3 and https://github.com/oconnor663/blake3-py is public domain via CC0, and dual licensed under Apache for good measure. Hopefully that makes it easy to use it anywhere.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39298>
_______________________________________

From report at bugs.python.org  Sun Feb 20 01:30:30 2022
From: report at bugs.python.org (Jason Yang)
Date: Sun, 20 Feb 2022 06:30:30 +0000
Subject: [issue46803] Item not shown when using mouse wheel to scroll for
 Listbox/Combobox
Message-ID: <1645338630.05.0.344258150366.issue46803@roundup.psfhosted.org>


New submission from Jason Yang <jason990420 at outlook.com>:

When scrolled items by mouse wheel in tk.Listbox/ttk.Combobox, some items not shown.

Is it a bug ? or I did something wrong ?

In following case, 'Wednesday' will not shown when scroll mouse wheel at

- tk.Listbox or vertical scrollbar of tk.Listbox, or
- listbox of ttk.Combo

```python
from tkinter import *
from tkinter import ttk

font = ('Courier New', 24)
lst = ('Sunday', 'Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday', 'Saturday')

root = Tk()

frame1 = Frame(root)
frame1.pack(side=LEFT)
vsb1 = Scrollbar(frame1, orient='v')
vsb1.pack(side=RIGHT, fill='y')
var = StringVar()
var.set(lst)
listbox = Listbox(frame1, width=10, height=3, listvariable=var, font=font, yscrollcommand=vsb1.set)
listbox.pack(side=LEFT)
vsb1.configure(command=listbox.yview)

frame2 = Frame(root)
frame2.pack(side=LEFT, fill='y')
combobox = ttk.Combobox(frame2, values=lst, width=10, height=3, font=font)
combobox.pack()

root.mainloop()
```

Platform: WIN10

----------
components: Tkinter
files: PeS9r.png
messages: 413564
nosy: Jason990420
priority: normal
severity: normal
status: open
title: Item not shown when using mouse wheel to scroll for Listbox/Combobox
type: behavior
versions: Python 3.8, Python 3.9
Added file: https://bugs.python.org/file50634/PeS9r.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46803>
_______________________________________

From report at bugs.python.org  Sun Feb 20 02:33:42 2022
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 20 Feb 2022 07:33:42 +0000
Subject: [issue46803] Item not shown when using mouse wheel to scroll for
 Listbox/Combobox
In-Reply-To: <1645338630.05.0.344258150366.issue46803@roundup.psfhosted.org>
Message-ID: <1645342422.57.0.233034903356.issue46803@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Replicated on Linux, Python 3.10.

It looks like mousewheel scrolling jumps by the wrong amount as it pages down (or up), and consequently some lines never appear in the view area.

I ran a slightly modified version of the code that had 16 entries instead of just seven. By default, just three entries are visible at a time. If we number the lines 1-16, and start with lines 1-3 visible, then we get:

* Initial view: lines 1, 2, 3 visible, 4-16 below the view area.
* Scrollwheel down.
* Lines 6-8 visible, 1-5 above the view area, 9-16 below.
* Scrollwheel down.
* Lines 11-13 visible, 1-10 above the view area, 14-16 below.
* Scrollwheel down.
* Lines 14-16 visible, 1-13 above the view area.

So the scrollwheel scrolls down by: 5 lines, 5 lines, 3 lines.

Going back the otherway, the scrollwheel scrolls up by 5, 5, 3.

Why five lines? My guess is that it might have something to do with 16//3 = 5.

I don't know if this is something we can fix, or we're stuck with whatever tk/tcl does.

I don't know if this is related, or should be a separate issue, but I see that the keyboard PageUp and PageDown keys don't scroll up or down by a page, but by a single line -- and they don't correctly highlight the selected line either.

Paging should scroll up or down by N-1 lines, where N is the number of visible lines in the view area.

Likewise for clicking in the scrollbar's PageUp/PageDown region, which also scrolls by a single line.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46803>
_______________________________________

From report at bugs.python.org  Sun Feb 20 03:35:08 2022
From: report at bugs.python.org (=?utf-8?b?6IKW5bCP5bCP?=)
Date: Sun, 20 Feb 2022 08:35:08 +0000
Subject: [issue46803] Item not shown when using mouse wheel to scroll for
 Listbox/Combobox
In-Reply-To: <1645338630.05.0.344258150366.issue46803@roundup.psfhosted.org>
Message-ID: <1645346108.51.0.751109665486.issue46803@roundup.psfhosted.org>


??? <xiaox55066 at gmail.com> added the comment:

<a href="http://www.strong19.com/goods.php?id=56" target="_blank">????  </a>

----------
nosy: +xiaox55066
Added file: https://bugs.python.org/file50635/6.jpeg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46803>
_______________________________________

From report at bugs.python.org  Sun Feb 20 03:36:05 2022
From: report at bugs.python.org (=?utf-8?b?6IKW5bCP5bCP?=)
Date: Sun, 20 Feb 2022 08:36:05 +0000
Subject: [issue46803] Item not shown when using mouse wheel to scroll for
 Listbox/Combobox
In-Reply-To: <1645338630.05.0.344258150366.issue46803@roundup.psfhosted.org>
Message-ID: <1645346165.07.0.931730897292.issue46803@roundup.psfhosted.org>


??? <xiaox55066 at gmail.com> added the comment:

<a href="http://www.strong19.com/category.php?id=5" target="_blank">???????  </a>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46803>
_______________________________________

From report at bugs.python.org  Sun Feb 20 03:37:01 2022
From: report at bugs.python.org (=?utf-8?b?6IKW5bCP5bCP?=)
Date: Sun, 20 Feb 2022 08:37:01 +0000
Subject: [issue46803] Item not shown when using mouse wheel to scroll for
 Listbox/Combobox
In-Reply-To: <1645338630.05.0.344258150366.issue46803@roundup.psfhosted.org>
Message-ID: <1645346221.43.0.30478460974.issue46803@roundup.psfhosted.org>


??? <xiaox55066 at gmail.com> added the comment:

http://www.strong19.com/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46803>
_______________________________________

From report at bugs.python.org  Sun Feb 20 03:42:36 2022
From: report at bugs.python.org (=?utf-8?b?6IKW5bCP5bCP?=)
Date: Sun, 20 Feb 2022 08:42:36 +0000
Subject: [issue45620] A misleading url in 'Floating Point Arithmetic' page
In-Reply-To: <1635313160.15.0.740336077946.issue45620@roundup.psfhosted.org>
Message-ID: <1645346556.87.0.632849196614.issue45620@roundup.psfhosted.org>


??? <xiaox55066 at gmail.com> added the comment:

Thanks! Works for me in browser now.http://www.strong19.com/

----------
nosy: +xiaox55066

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45620>
_______________________________________

From report at bugs.python.org  Sun Feb 20 03:43:03 2022
From: report at bugs.python.org (=?utf-8?b?6IKW5bCP5bCP?=)
Date: Sun, 20 Feb 2022 08:43:03 +0000
Subject: [issue45620] A misleading url in 'Floating Point Arithmetic' page
In-Reply-To: <1635313160.15.0.740336077946.issue45620@roundup.psfhosted.org>
Message-ID: <1645346583.81.0.785831989793.issue45620@roundup.psfhosted.org>


??? <xiaox55066 at gmail.com> added the comment:

It shows the drug ad slogan even with the google search result.
I searched 'The Perils of Floating Point lahey'http://www.strong19.com/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45620>
_______________________________________

From report at bugs.python.org  Sun Feb 20 03:51:01 2022
From: report at bugs.python.org (=?utf-8?b?6IKW5bCP5bCP?=)
Date: Sun, 20 Feb 2022 08:51:01 +0000
Subject: [issue45620] A misleading url in 'Floating Point Arithmetic' page
In-Reply-To: <1635313160.15.0.740336077946.issue45620@roundup.psfhosted.org>
Message-ID: <1645347061.92.0.708063875472.issue45620@roundup.psfhosted.org>


??? <xiaox55066 at gmail.com> added the comment:

I was redirect to http://www.strong19.com/
so is this my internet problem?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45620>
_______________________________________

From report at bugs.python.org  Sun Feb 20 03:51:27 2022
From: report at bugs.python.org (=?utf-8?b?6IKW5bCP5bCP?=)
Date: Sun, 20 Feb 2022 08:51:27 +0000
Subject: [issue45620] A misleading url in 'Floating Point Arithmetic' page
In-Reply-To: <1635313160.15.0.740336077946.issue45620@roundup.psfhosted.org>
Message-ID: <1645347087.38.0.0364780197322.issue45620@roundup.psfhosted.org>


??? <xiaox55066 at gmail.com> added the comment:

It shows the drug ad slogan even with the google search result.
http://www.strong19.com/I searched 'The Perils of Floating Point lahey'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45620>
_______________________________________

From report at bugs.python.org  Sun Feb 20 03:57:09 2022
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 20 Feb 2022 08:57:09 +0000
Subject: [issue46803] Item not shown when using mouse wheel to scroll for
 Listbox/Combobox
In-Reply-To: <1645338630.05.0.344258150366.issue46803@roundup.psfhosted.org>
Message-ID: <1645347429.39.0.119716601135.issue46803@roundup.psfhosted.org>


Change by Steven D'Aprano <steve+python at pearwood.info>:


----------
Removed message: https://bugs.python.org/msg413566

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46803>
_______________________________________

From report at bugs.python.org  Sun Feb 20 03:57:30 2022
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 20 Feb 2022 08:57:30 +0000
Subject: [issue46803] Item not shown when using mouse wheel to scroll for
 Listbox/Combobox
In-Reply-To: <1645338630.05.0.344258150366.issue46803@roundup.psfhosted.org>
Message-ID: <1645347450.05.0.56027875739.issue46803@roundup.psfhosted.org>


Change by Steven D'Aprano <steve+python at pearwood.info>:


----------
Removed message: https://bugs.python.org/msg413567

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46803>
_______________________________________

From report at bugs.python.org  Sun Feb 20 03:57:47 2022
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 20 Feb 2022 08:57:47 +0000
Subject: [issue46803] Item not shown when using mouse wheel to scroll for
 Listbox/Combobox
In-Reply-To: <1645338630.05.0.344258150366.issue46803@roundup.psfhosted.org>
Message-ID: <1645347467.76.0.232374465737.issue46803@roundup.psfhosted.org>


Change by Steven D'Aprano <steve+python at pearwood.info>:


----------
Removed message: https://bugs.python.org/msg413568

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46803>
_______________________________________

From report at bugs.python.org  Sun Feb 20 03:58:03 2022
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 20 Feb 2022 08:58:03 +0000
Subject: [issue46803] Item not shown when using mouse wheel to scroll for
 Listbox/Combobox
In-Reply-To: <1645338630.05.0.344258150366.issue46803@roundup.psfhosted.org>
Message-ID: <1645347483.31.0.110555574113.issue46803@roundup.psfhosted.org>


Change by Steven D'Aprano <steve+python at pearwood.info>:


----------
nosy:  -xiaox55066

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46803>
_______________________________________

From report at bugs.python.org  Sun Feb 20 03:58:44 2022
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 20 Feb 2022 08:58:44 +0000
Subject: [issue46803] Item not shown when using mouse wheel to scroll for
 Listbox/Combobox
In-Reply-To: <1645338630.05.0.344258150366.issue46803@roundup.psfhosted.org>
Message-ID: <1645347524.57.0.424046894838.issue46803@roundup.psfhosted.org>


Change by Steven D'Aprano <steve+python at pearwood.info>:


Removed file: https://bugs.python.org/file50635/6.jpeg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46803>
_______________________________________

From report at bugs.python.org  Sun Feb 20 04:11:54 2022
From: report at bugs.python.org (Mehdi2277)
Date: Sun, 20 Feb 2022 09:11:54 +0000
Subject: [issue44791] Substitution of ParamSpec in Concatenate
In-Reply-To: <1627727114.02.0.621938171006.issue44791@roundup.psfhosted.org>
Message-ID: <1645348314.51.0.4527071759.issue44791@roundup.psfhosted.org>


Mehdi2277 <med2277 at gmail.com> added the comment:

Concatenate[int, ...] I would interpret as a function signature with first argument int, followed by arbitrary arguments afterwards. I haven't run into this case, but ... is allowed in other spots Paramspec is allowed currently.

P = Paramspec("P")

class Foo(Generic[P]):
  ...

Foo[...] # Allowed 
Callable[..., None] # Allowed

Are there any other places a paramspec is allowed? Generic type argument, first argument to callable, last to concatenate, anything else?

I'm unaware of any type checking use case for Concatenate[int, ...]. You can practically get same thing by using a paramspec variable without using it elsewhere so that it captures, but then effectively discards that information.

def use_func1(f: Callable[Concatenate[int, P], None]) -> None:
  ...

def use_func2(f: Callable[Concatenate[int, ...], None]) -> None:
  ...

feels like those two signatures should encode same information.

----------
nosy: +med2277

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44791>
_______________________________________

From report at bugs.python.org  Sun Feb 20 04:46:24 2022
From: report at bugs.python.org (Akuli)
Date: Sun, 20 Feb 2022 09:46:24 +0000
Subject: [issue45620] A misleading url in 'Floating Point Arithmetic' page
In-Reply-To: <1635313160.15.0.740336077946.issue45620@roundup.psfhosted.org>
Message-ID: <1645350384.63.0.403127894787.issue45620@roundup.psfhosted.org>


Akuli <akuviljanen17 at gmail.com> added the comment:

If you still have the problem, can you show us what headers your browser sends to websites? You can see that by running in Python:

    import socket
    print(socket.create_server(('127.0.0.1', 12345)).accept()[0].recv(1024).decode())

and then going to http://localhost:12345/ in your browser.

I'm especially interested in the line that starts with Accept-Language. For me, the site now works, and my Accept-Language header is:

    Accept-Language: en-US,en;q=0.9,fi;q=0.8,sv;q=0.7,pt;q=0.6,it;q=0.5,zh-CN;q=0.4,zh;q=0.3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45620>
_______________________________________

From report at bugs.python.org  Sun Feb 20 05:07:15 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 20 Feb 2022 10:07:15 +0000
Subject: [issue46752] Introduce task groups to asyncio and change task
 cancellation semantics
In-Reply-To: <1644871469.64.0.38816696304.issue46752@roundup.psfhosted.org>
Message-ID: <1645351635.61.0.382070750095.issue46752@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset e7130c2e8c6abfaf04b209bd5b239059eda024b9 by Andrew Svetlov in branch 'main':
bpo-46752: Uniform TaskGroup.__repr__ (GH-31409)
https://github.com/python/cpython/commit/e7130c2e8c6abfaf04b209bd5b239059eda024b9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46752>
_______________________________________

From report at bugs.python.org  Sun Feb 20 05:24:09 2022
From: report at bugs.python.org (miss-islington)
Date: Sun, 20 Feb 2022 10:24:09 +0000
Subject: [issue46672] NameError in asyncio.gather when passing a invalid type
 as an arg with multiple awaitables
In-Reply-To: <1644211485.82.0.488303396987.issue46672@roundup.psfhosted.org>
Message-ID: <1645352649.81.0.0387968371656.issue46672@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: +29571
pull_request: https://github.com/python/cpython/pull/31440

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46672>
_______________________________________

From report at bugs.python.org  Sun Feb 20 05:24:17 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 20 Feb 2022 10:24:17 +0000
Subject: [issue46672] NameError in asyncio.gather when passing a invalid type
 as an arg with multiple awaitables
In-Reply-To: <1644211485.82.0.488303396987.issue46672@roundup.psfhosted.org>
Message-ID: <1645352657.61.0.373475680773.issue46672@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset 4ab8167b9c60d1a04b2e3116d0c52db254b68cda by Nikita Sobolev in branch 'main':
bpo-46672: fix `NameError` in `asyncio.gather` if type check fails (GH-31187)
https://github.com/python/cpython/commit/4ab8167b9c60d1a04b2e3116d0c52db254b68cda


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46672>
_______________________________________

From report at bugs.python.org  Sun Feb 20 05:24:23 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 20 Feb 2022 10:24:23 +0000
Subject: =?utf-8?b?W2lzc3VlNDY4MDRdIFlheXRleHQubmV0IC0gVOG6oW8gdsSDbiBi4bqjbiBj?=
 =?utf-8?b?aOG7ryBraeG7g3UsIGvDrSB04buxIMSR4bq3YyBiaeG7h3QgxJHhu5ljIMSR?=
 =?utf-8?b?w6Fv?=
In-Reply-To: <1645349986.97.0.997454849977.issue46804@roundup.psfhosted.org>
Message-ID: <1645352663.67.0.255995190943.issue46804@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
Removed message: https://bugs.python.org/msg413575

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46804>
_______________________________________

From report at bugs.python.org  Sun Feb 20 05:24:27 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 20 Feb 2022 10:24:27 +0000
Subject: =?utf-8?b?W2lzc3VlNDY4MDRdIFlheXRleHQubmV0IC0gVOG6oW8gdsSDbiBi4bqjbiBj?=
 =?utf-8?b?aOG7ryBraeG7g3UsIGvDrSB04buxIMSR4bq3YyBiaeG7h3QgxJHhu5ljIMSR?=
 =?utf-8?b?w6Fv?=
Message-ID: <1645352667.89.0.316979154872.issue46804@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
Removed message: https://bugs.python.org/msg413574

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46804>
_______________________________________

From report at bugs.python.org  Sun Feb 20 05:25:15 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 20 Feb 2022 10:25:15 +0000
Subject: =?utf-8?b?W2lzc3VlNDY4MDRdIFlheXRleHQubmV0IC0gVOG6oW8gdsSDbiBi4bqjbiBj?=
 =?utf-8?b?aOG7ryBraeG7g3UsIGvDrSB04buxIMSR4bq3YyBiaeG7h3QgxJHhu5ljIMSR?=
 =?utf-8?b?w6Fv?=
Message-ID: <1645352715.53.0.764529061645.issue46804@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/issue46804>
_______________________________________

From report at bugs.python.org  Sun Feb 20 05:27:09 2022
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Sun, 20 Feb 2022 10:27:09 +0000
Subject: [issue46805] Add low level UDP socket functions to asyncio
Message-ID: <1645352829.56.0.926800544018.issue46805@roundup.psfhosted.org>


New submission from Alex Gr?nholm <alex.gronholm at nextday.fi>:

The asyncio module currently has a number of low-level functions for working asynchronously with raw socket objects. Such functions for working with UDP sockets are, however, notably absent, and there is no workaround for this. You can of course use sock_receive() with UDP sockets but that would discard the sender address which is a showstopper problem. Also, having a send function that applies back pressure to the sender if the kernel buffer is full would also be prudent.

I will provide a PR if you're okay with this.
It would include the following functions:

* sock_sendto()
* sock_recvfrom()
* sock_recvfrom_into()

----------
components: asyncio
messages: 413579
nosy: alex.gronholm, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Add low level UDP socket functions to asyncio
type: enhancement
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46805>
_______________________________________

From report at bugs.python.org  Sun Feb 20 05:37:15 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 20 Feb 2022 10:37:15 +0000
Subject: [issue46672] NameError in asyncio.gather when passing a invalid type
 as an arg with multiple awaitables
In-Reply-To: <1644211485.82.0.488303396987.issue46672@roundup.psfhosted.org>
Message-ID: <1645353435.05.0.733888162714.issue46672@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
pull_requests: +29572
pull_request: https://github.com/python/cpython/pull/31441

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46672>
_______________________________________

From report at bugs.python.org  Sun Feb 20 05:57:57 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 20 Feb 2022 10:57:57 +0000
Subject: [issue46252] Forbid passing SSLSocket into asyncio methods
Message-ID: <1645354677.24.0.468507584959.issue46252@roundup.psfhosted.org>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

SSLSocket is a blocking object by definition, it is not compatible with asyncio.

asyncio has a check for SSLSocket in sock_*() operations, it should be extended to transport-based API

----------
title: SSLWantReadError causes _SelectorSocketTransport to close -> Forbid passing SSLSocket into asyncio methods

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46252>
_______________________________________

From report at bugs.python.org  Sun Feb 20 06:06:58 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 20 Feb 2022 11:06:58 +0000
Subject: [issue46252] Forbid passing SSLSocket into asyncio methods
In-Reply-To: <1645354677.24.0.468507584959.issue46252@roundup.psfhosted.org>
Message-ID: <1645355218.44.0.570640505235.issue46252@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
pull_requests: +29573
pull_request: https://github.com/python/cpython/pull/31442

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46252>
_______________________________________

From report at bugs.python.org  Sun Feb 20 06:49:18 2022
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Sun, 20 Feb 2022 11:49:18 +0000
Subject: [issue46805] Add low level UDP socket functions to asyncio
In-Reply-To: <1645352829.56.0.926800544018.issue46805@roundup.psfhosted.org>
Message-ID: <1645357758.69.0.168204281763.issue46805@roundup.psfhosted.org>


Alex Gr?nholm <alex.gronholm at nextday.fi> added the comment:

One question: should I add the "flags" argument to the new functions? For some reason it's missing from the existing functions, so maybe I should add that in a separate PR?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46805>
_______________________________________

From report at bugs.python.org  Sun Feb 20 07:11:08 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 20 Feb 2022 12:11:08 +0000
Subject: [issue46805] Add low level UDP socket functions to asyncio
In-Reply-To: <1645352829.56.0.926800544018.issue46805@roundup.psfhosted.org>
Message-ID: <1645359068.12.0.0182753766277.issue46805@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

A separate issue for 'flags' adding looks better. The reason for missing is an oversight I think.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46805>
_______________________________________

From report at bugs.python.org  Sun Feb 20 07:15:41 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 20 Feb 2022 12:15:41 +0000
Subject: [issue46252] Forbid passing SSLSocket into asyncio methods
In-Reply-To: <1645354677.24.0.468507584959.issue46252@roundup.psfhosted.org>
Message-ID: <1645359341.86.0.168208194624.issue46252@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46252>
_______________________________________

From report at bugs.python.org  Sun Feb 20 07:16:43 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 20 Feb 2022 12:16:43 +0000
Subject: [issue46252] Forbid passing SSLSocket into asyncio methods
In-Reply-To: <1645354677.24.0.468507584959.issue46252@roundup.psfhosted.org>
Message-ID: <1645359403.31.0.327293173359.issue46252@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

The issue can be backported.
It doesn't change existing behavior but raises a better error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46252>
_______________________________________

From report at bugs.python.org  Sun Feb 20 07:19:52 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 20 Feb 2022 12:19:52 +0000
Subject: [issue46252] Forbid passing SSLSocket into asyncio methods
In-Reply-To: <1645354677.24.0.468507584959.issue46252@roundup.psfhosted.org>
Message-ID: <1645359592.54.0.995677117172.issue46252@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
pull_requests: +29574
pull_request: https://github.com/python/cpython/pull/31443

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46252>
_______________________________________

From report at bugs.python.org  Sun Feb 20 07:23:02 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 20 Feb 2022 12:23:02 +0000
Subject: [issue46252] Forbid passing SSLSocket into asyncio methods
In-Reply-To: <1645354677.24.0.468507584959.issue46252@roundup.psfhosted.org>
Message-ID: <1645359782.45.0.513975897259.issue46252@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
pull_requests: +29575
pull_request: https://github.com/python/cpython/pull/31444

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46252>
_______________________________________

From report at bugs.python.org  Sun Feb 20 07:34:47 2022
From: report at bugs.python.org (aklajnert)
Date: Sun, 20 Feb 2022 12:34:47 +0000
Subject: [issue46806] Overlapping PYTHONPATH may cause
Message-ID: <1645360487.42.0.278270431314.issue46806@roundup.psfhosted.org>


New submission from aklajnert <python at aklajnert.pl>:

I'm not 100% sure whether it is a bug or intentional behavior but looks like a bug to me. I couldn't find anything about it here or anywhere else.

Sample project structure:
```
.
??? main.py
??? src
    ??? __init__.py
    ??? common_object.py
    ??? user_1.py
    ??? user_2.py
    ??? user_3.py
```

`__init__.py` is an empty file.


```
# src/common_object.py
OBJECT = object()
```

```
# src/user_1.py
from .common_object import OBJECT
```

```
# src/user_2.py
from src.common_object import OBJECT
```

```
# src/user_3.py
from common_object import OBJECT
```

```
# main.py
import sys

sys.path.append("src")

from src import user_1, user_2, user_3


if __name__ == '__main__':
    print(user_1.OBJECT is user_2.OBJECT) # True
    print(user_1.OBJECT is user_3.OBJECT) # False
```

Since `src` package is added to `PYTHONPATH`, it is possible to import `common_object` by calling `from src.common_object` or `from common_object`.  
Both methods work, but using import without `src.` makes Python load the same module again instead of using the already loaded one.

If you extend `main.py` with the following code, you'll see a bit more:
```
modules = [
    module
    for name, module in sys.modules.items()
    if "common_object" in name
]
print(len(modules)) # 2
print(modules[0].__file__ == modules[1].__file__) # True
```

In the `sys.modules` dict there will be two separate modules - one called `common_object` and another named `src.common_object`. 
If you compare the `__file__` value for both modules you'll see that they are the same. It seems that python gets the module name wrong.

----------
messages: 413584
nosy: aklajnert
priority: normal
severity: normal
status: open
title: Overlapping PYTHONPATH may cause
type: behavior
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46806>
_______________________________________

From report at bugs.python.org  Sun Feb 20 07:39:35 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 20 Feb 2022 12:39:35 +0000
Subject: [issue46672] NameError in asyncio.gather when passing a invalid type
 as an arg with multiple awaitables
In-Reply-To: <1644211485.82.0.488303396987.issue46672@roundup.psfhosted.org>
Message-ID: <1645360775.99.0.316329894853.issue46672@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset a6116a980c9eae91c2f9af7cbd0a9727e9b887ba by Andrew Svetlov in branch '3.9':
[3.9] bpo-46672: fix `NameError` in `asyncio.gather` if type check fails (GH-31187) (GH-31441)
https://github.com/python/cpython/commit/a6116a980c9eae91c2f9af7cbd0a9727e9b887ba


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46672>
_______________________________________

From report at bugs.python.org  Sun Feb 20 07:49:51 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 20 Feb 2022 12:49:51 +0000
Subject: [issue46252] Forbid passing SSLSocket into asyncio methods
In-Reply-To: <1645354677.24.0.468507584959.issue46252@roundup.psfhosted.org>
Message-ID: <1645361391.26.0.906980079793.issue46252@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/issue46252>
_______________________________________

From report at bugs.python.org  Sun Feb 20 07:52:05 2022
From: report at bugs.python.org (aklajnert)
Date: Sun, 20 Feb 2022 12:52:05 +0000
Subject: [issue46806] Overlapping PYTHONPATH may cause import already imported
 module
In-Reply-To: <1645360487.42.0.278270431314.issue46806@roundup.psfhosted.org>
Message-ID: <1645361525.9.0.785683601983.issue46806@roundup.psfhosted.org>


Change by aklajnert <python at aklajnert.pl>:


----------
title: Overlapping PYTHONPATH may cause -> Overlapping PYTHONPATH may cause import already imported module

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46806>
_______________________________________

From report at bugs.python.org  Sun Feb 20 08:05:31 2022
From: report at bugs.python.org (Konstantin)
Date: Sun, 20 Feb 2022 13:05:31 +0000
Subject: [issue46807] Wrong class __annotations__ when field name and type are
 equal
Message-ID: <1645362331.92.0.497127869678.issue46807@roundup.psfhosted.org>


New submission from Konstantin <dev at kgubaev.org>:

In [18]: class Str(str):
    ...:     pass

In [19]: class Class:
    ...:     Str: str
    ...: 
    ...: 
    ...: Class.__annotations__
Out[19]: {'Str': str}

In [20]: class Class:
    ...:     Str: str = ""
    ...: 
    ...: 
    ...: Class.__annotations__
Out[20]: {'Str': str}

In [21]: class Class:
    ...:     Str: Str = ""
    ...: 
    ...: 
    ...: Class.__annotations__      # Wrong!
Out[21]: {'Str': ''}

In [22]: class Class:
    ...:     Str: Str
    ...: 
    ...: 
    ...: Class.__annotations__
Out[22]: {'Str': __main__.Str}

It reproduced all the version which support annotations as part of the core (I tested python 3.6..3.10.2)

----------
components: Parser
messages: 413586
nosy: kgubaev, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Wrong class __annotations__ when field name and type are equal
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46807>
_______________________________________

From report at bugs.python.org  Sun Feb 20 08:10:21 2022
From: report at bugs.python.org (Alex Waygood)
Date: Sun, 20 Feb 2022 13:10:21 +0000
Subject: [issue46807] Wrong class __annotations__ when field name and type are
 equal
In-Reply-To: <1645362331.92.0.497127869678.issue46807@roundup.psfhosted.org>
Message-ID: <1645362621.44.0.38973560321.issue46807@roundup.psfhosted.org>


Change by Alex Waygood <Alex.Waygood at Gmail.com>:


----------
nosy: +AlexWaygood, larry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46807>
_______________________________________

From report at bugs.python.org  Sun Feb 20 08:14:49 2022
From: report at bugs.python.org (Alex Waygood)
Date: Sun, 20 Feb 2022 13:14:49 +0000
Subject: [issue46807] Wrong class __annotations__ when field name and type are
 equal
In-Reply-To: <1645362331.92.0.497127869678.issue46807@roundup.psfhosted.org>
Message-ID: <1645362889.13.0.702565497257.issue46807@roundup.psfhosted.org>


Change by Alex Waygood <Alex.Waygood at Gmail.com>:


----------
nosy: +Jelle Zijlstra

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46807>
_______________________________________

From report at bugs.python.org  Sun Feb 20 08:57:50 2022
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=)
Date: Sun, 20 Feb 2022 13:57:50 +0000
Subject: [issue46794] Please update bundled libexpat to 2.4.5 with security
 fixes (5 CVEs)
In-Reply-To: <1645227388.68.0.727345462152.issue46794@roundup.psfhosted.org>
Message-ID: <1645365470.91.0.917840839574.issue46794@roundup.psfhosted.org>


Micha? G?rny <mgorny at gentoo.org> added the comment:

BTW there are test regressions with expat 2.4.5, apparently due to some test snippets now being rejected as invalid XML:

======================================================================
ERROR: test_issue3151 (test.test_xml_etree.BugsTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/mgorny/git/cpython/Lib/xml/etree/ElementTree.py", line 1718, in feed
    self.parser.Parse(data, False)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
xml.parsers.expat.ExpatError: syntax error: line 1, column 0

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/mgorny/git/cpython/Lib/test/test_xml_etree.py", line 2196, in test_issue3151
    e = ET.XML('<prefix:localname xmlns:prefix="${stuff}"/>')
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/mgorny/git/cpython/Lib/xml/etree/ElementTree.py", line 1347, in XML
    parser.feed(text)
    ^^^^^^^^^^^^^^^^^
  File "/home/mgorny/git/cpython/Lib/xml/etree/ElementTree.py", line 1720, in feed
    self._raiseerror(v)
    ^^^^^^^^^^^^^^^^^^^
  File "/home/mgorny/git/cpython/Lib/xml/etree/ElementTree.py", line 1627, in _raiseerror
    raise err
    ^^^^^^^^^
xml.etree.ElementTree.ParseError: syntax error: line 1, column 0


======================================================================
ERROR: testEncodings (test.test_minidom.MinidomTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/mgorny/git/cpython/Lib/test/test_minidom.py", line 1150, in testEncodings
    self.assertRaises(UnicodeDecodeError, parseString,
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/mgorny/git/cpython/Lib/unittest/case.py", line 734, in assertRaises
    return context.handle('assertRaises', args, kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/mgorny/git/cpython/Lib/unittest/case.py", line 218, in handle
    callable_obj(*args, **kwargs)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/mgorny/git/cpython/Lib/xml/dom/minidom.py", line 1998, in parseString
    return expatbuilder.parseString(string)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/mgorny/git/cpython/Lib/xml/dom/expatbuilder.py", line 925, in parseString
    return builder.parseString(string)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/mgorny/git/cpython/Lib/xml/dom/expatbuilder.py", line 223, in parseString
    parser.Parse(string, True)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^
xml.parsers.expat.ExpatError: not well-formed (invalid token): line 1, column 5

======================================================================
ERROR: testExceptionOnSpacesInXMLNSValue (test.test_minidom.MinidomTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/mgorny/git/cpython/Lib/test/test_minidom.py", line 1613, in testExceptionOnSpacesInXMLNSValue
    parseString('<element xmlns:abc="http:abc.com/de f g/hi/j k"><abc:foo /></element>')
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/mgorny/git/cpython/Lib/xml/dom/minidom.py", line 1998, in parseString
    return expatbuilder.parseString(string)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/mgorny/git/cpython/Lib/xml/dom/expatbuilder.py", line 925, in parseString
    return builder.parseString(string)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/mgorny/git/cpython/Lib/xml/dom/expatbuilder.py", line 223, in parseString
    parser.Parse(string, True)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^
xml.parsers.expat.ExpatError: syntax error: line 1, column 0

----------
nosy: +mgorny

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46794>
_______________________________________

From report at bugs.python.org  Sun Feb 20 09:48:08 2022
From: report at bugs.python.org (Neil Girdhar)
Date: Sun, 20 Feb 2022 14:48:08 +0000
Subject: [issue46757] dataclasses should define an empty __post_init__
In-Reply-To: <1644923607.6.0.495534870715.issue46757@roundup.psfhosted.org>
Message-ID: <1645368488.65.0.17304007841.issue46757@roundup.psfhosted.org>


Neil Girdhar <mistersheik at gmail.com> added the comment:

> How would an arbitrary derived class know how to call this? It can't. There has to be knowledge of the base class's requirements already. Surely knowing "__post_init__ must be called with some_arg" isn't too different from "I know __post_init__ doesn't exist".

This is exactly the same problem you have with all other "augmenting methods" that have arbitrary parameters (e.g., __init__).  When calling super on a non-final class you could simply forward keyword arguments.


@dataclass
class X:
    def __post_init__(self, **kwargs):
        super().__post_init__(**kwargs)
        ...

@dataclass
class Y(X):
    def __post_init__(self, **kwargs):
        super().__post_init__(**kwargs)
        ...

> I'm still unconvinced, but I'll hold off on making a decision to see if there's more support. Maybe taking it to python-ideas would be worthwhile.

Sounds good, done:  https://groups.google.com/g/python-ideas/c/-gctNaSqgew

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46757>
_______________________________________

From report at bugs.python.org  Sun Feb 20 09:48:48 2022
From: report at bugs.python.org (Irit Katriel)
Date: Sun, 20 Feb 2022 14:48:48 +0000
Subject: [issue46808] remove NEXT_BLOCK() from compile.c
Message-ID: <1645368528.16.0.363497063609.issue46808@roundup.psfhosted.org>


New submission from Irit Katriel <iritkatriel at gmail.com>:

The compiler currently requires the code-generation functions to explicitly specify where basic blocks end, with a NEXT_BLOCK().

If you get that wrong, you get an exception about "malformed control flow graph" later, in the cfg analysis stage. It is not obvious then where the error is, and it makes it difficult to make changes in the compiler. 

We can instead make the compiler implicitly create a new block when this is needed (which is after specific opcodes).

----------
assignee: iritkatriel
components: Interpreter Core
messages: 413589
nosy: iritkatriel
priority: normal
severity: normal
status: open
title: remove NEXT_BLOCK() from compile.c
type: enhancement
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46808>
_______________________________________

From report at bugs.python.org  Sun Feb 20 09:50:39 2022
From: report at bugs.python.org (Irit Katriel)
Date: Sun, 20 Feb 2022 14:50:39 +0000
Subject: [issue46808] remove NEXT_BLOCK() from compile.c
In-Reply-To: <1645368528.16.0.363497063609.issue46808@roundup.psfhosted.org>
Message-ID: <1645368639.02.0.164633633189.issue46808@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at gmail.com>:


----------
keywords: +patch
pull_requests: +29576
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31448

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46808>
_______________________________________

From report at bugs.python.org  Sun Feb 20 10:04:10 2022
From: report at bugs.python.org (Martin Kirchgessner)
Date: Sun, 20 Feb 2022 15:04:10 +0000
Subject: [issue46740] Improve Telnetlib's throughput
In-Reply-To: <1644783460.72.0.175033327075.issue46740@roundup.psfhosted.org>
Message-ID: <1645369450.58.0.327101144273.issue46740@roundup.psfhosted.org>


Change by Martin Kirchgessner <martin.kirch at gmail.com>:


----------
keywords: +patch
pull_requests: +29577
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31449

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46740>
_______________________________________

From report at bugs.python.org  Sun Feb 20 10:09:50 2022
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 20 Feb 2022 15:09:50 +0000
Subject: [issue46807] Wrong class __annotations__ when field name and type are
 equal
In-Reply-To: <1645362331.92.0.497127869678.issue46807@roundup.psfhosted.org>
Message-ID: <1645369790.81.0.0379410580732.issue46807@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This looks similar to https://bugs.python.org/issue36363

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46807>
_______________________________________

From report at bugs.python.org  Sun Feb 20 10:19:08 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 20 Feb 2022 15:19:08 +0000
Subject: [issue46807] Wrong class __annotations__ when field name and type are
 equal
In-Reply-To: <1645362331.92.0.497127869678.issue46807@roundup.psfhosted.org>
Message-ID: <1645370348.52.0.889461368313.issue46807@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Wrong type when missname dataclass attribute with existing variable name

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46807>
_______________________________________

From report at bugs.python.org  Sun Feb 20 10:22:30 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 20 Feb 2022 15:22:30 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645370550.11.0.522359208952.issue46771@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Suppose we have a case when two nested timeouts are reached at the same event loop iteration:

async def asyncio.timeout(1) as cm1:
   async with third_party_cm() as cm2:
       async def asyncio.timeout(1) as cm3:
           async with third_party_cm() as cm4:
               await asyncio.sleep(10)

What exception should be bubbled between outer and inner context manager 'exit' executions?

`sleep()` is interrupted with CancelledError, it is clear (and the only possible solution in asyncio world). `cm4.__aexit__` receives the CancelledError, does the cleanup if required, and re-raises the cancellation.

`cm3.__aexit__` receives the bubbled CancelledError and updates its own state and raises an exception.
The question is: what exception should be raised, CancelledError or TimeoutError?
What exception should see `cm2.__aexit__` code?

After careful thinking, I believe that CancelledError should be re-raised by *inner affected* timeout context managers, the only top-level *affected* context should convert CancelledError and raise TimeoutError.

My reasons for this behavior are:
  A generic asyncio code is usually *ready* for cancellation. If it wants to react to the cancellation event, it caught `asyncio.CancelledError` and reraised it. Also, the asyncio code is cancellation-ready by default because usually `BaseException` is now handled (asyncio.CancelledError is derived from BaseException). TimeoutError is caught by `except Exception` instead, it adds extra difficulty.
  Handling both CancelledError and TimeoutError by *any* asyncio code on async stack unwinding is tedious and error-prone. If we should choose one I bet on CancelledError.
  The inner code ignores timeouts usually (and executes resource cleanup only). That's what CancelledError handling exists for already. If the cleanup differs depending on timeout expiration, `cm3.expired` (name it) can be used as a flag. You can disagree with me here, my opinion is based on my experience of writing asyncio code only.
  The top-level affected timeout context manager should raise TimeoutError because it exists and is used for such things.

Long story short: all *internal affected* timeout context managers should not raise TimeoutError (or it should be configurable and 'off' by default) because `third_party_cm()` should have the same simple implementation whether is it used as `cm2` or `cm4`.

Happy to see your opinions regarding the question, folks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Sun Feb 20 10:29:03 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 20 Feb 2022 15:29:03 +0000
Subject: [issue46672] NameError in asyncio.gather when passing a invalid type
 as an arg with multiple awaitables
In-Reply-To: <1644211485.82.0.488303396987.issue46672@roundup.psfhosted.org>
Message-ID: <1645370943.08.0.0288645858528.issue46672@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.11, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46672>
_______________________________________

From report at bugs.python.org  Sun Feb 20 10:29:08 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 20 Feb 2022 15:29:08 +0000
Subject: [issue46672] NameError in asyncio.gather when passing a invalid type
 as an arg with multiple awaitables
In-Reply-To: <1644211485.82.0.488303396987.issue46672@roundup.psfhosted.org>
Message-ID: <1645370948.25.0.0284343791392.issue46672@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset f1916cde24053f4c8b6799730666d19474f8dd09 by Miss Islington (bot) in branch '3.10':
bpo-46672: fix `NameError` in `asyncio.gather` if type check fails (GH-31187) (GH-31440)
https://github.com/python/cpython/commit/f1916cde24053f4c8b6799730666d19474f8dd09


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46672>
_______________________________________

From report at bugs.python.org  Sun Feb 20 10:36:40 2022
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 20 Feb 2022 15:36:40 +0000
Subject: [issue46807] Wrong class __annotations__ when field name and type are
 equal
In-Reply-To: <1645362331.92.0.497127869678.issue46807@roundup.psfhosted.org>
Message-ID: <1645371400.53.0.920356348866.issue46807@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

Yeah, it's the same behavior.  In that class, you have defined Str to be "", then you reference Str in the annotation, and its value is "".  Whatever you set Str to in the example in [21], that's the value of the annotation.

GvR closed the previous report as "not a bug", so I'm gonna do that here too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46807>
_______________________________________

From report at bugs.python.org  Sun Feb 20 10:45:50 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 20 Feb 2022 15:45:50 +0000
Subject: [issue46757] dataclasses should define an empty __post_init__
In-Reply-To: <1644923607.6.0.495534870715.issue46757@roundup.psfhosted.org>
Message-ID: <1645371950.41.0.290909107848.issue46757@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
assignee:  -> eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46757>
_______________________________________

From report at bugs.python.org  Sun Feb 20 10:57:04 2022
From: report at bugs.python.org (Royce Mitchell)
Date: Sun, 20 Feb 2022 15:57:04 +0000
Subject: [issue46809] copy.deepcopy can fail with unhelpful diagnostics
Message-ID: <1645372624.51.0.480394370702.issue46809@roundup.psfhosted.org>


New submission from Royce Mitchell <royce3 at gmail.com>:

Dear devs,

I have a small change request to make to a built-in Python file.

I'm currently running python 3.9.5

The file is copy.py

I would like to propose changing line 264 (in _reconstruct) from this:

    y = func(*args)

to something like this:

    try:
        y = func(*args)
    except TypeError as e:
        raise TypeError(
            f'calling {func.__module__}.{func.__qualname__}: {e.args[0]}', *e.args[1:]
        ).with_traceback(e.__traceback__) from None

All the change does it inject the module and qualified-name of the function trying to be
created onto the front-end of the error.

It makes this:

TypeError: __init__() missing 1 required positional argument: 'delta'

into this:

TypeError: calling datetime.datetime: calling mytz.Tzoffset: __init__() missing 1 required positional argument: 'delta'

Here's a summary of the situation that led to this difficulty:

I have a project that is a couple years old and I'm no longer intimately aware of every single
thing the program is doing. I went to make some enhancements and noticed the unit tests
hadn't been touched since early in the project and decided I wanted to start using it.

I got stuck trying to prettyprint an object and getting a TypeError from the line above
because it was trying to call a function but was missing a required argument.

The traceback was unhelpful because I didn't know what object it was trying to copy,
which was very complicated with lots of data and sub-objects.

It turns out that a dataclass (named TransDetail) I was trying to prettyprint
had a list of another dataclass (named Billing) which had a datetime.datetime object
with a custom tzinfo object that I had never tried to deepcopy before.
(The custom tzinfo object was adapted from examples on StackOverflow)

Trying to google the issue, I found many others experiencing the same problem.

The fix was to define a default datetime.timedelta value for that custom tzinfo object,
but I had to make the changes to copy.py in order to efficiently figure out that this
was the problem.

----------
components: Library (Lib)
messages: 413594
nosy: remdragon
priority: normal
severity: normal
status: open
title: copy.deepcopy can fail with unhelpful diagnostics
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46809>
_______________________________________

From report at bugs.python.org  Sun Feb 20 11:02:24 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 20 Feb 2022 16:02:24 +0000
Subject: [issue39327] shutil.rmtree using vagrant synched folder fails
In-Reply-To: <1578995152.92.0.0617677010821.issue39327@roundup.psfhosted.org>
Message-ID: <1645372944.5.0.54041802751.issue39327@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset b77158b4da449ec5b8f682816a79d004fd65ed07 by Lital Natan in branch 'main':
bpo-39327: Close file descriptors as soon as possible in shutil.rmtree (GH-31384)
https://github.com/python/cpython/commit/b77158b4da449ec5b8f682816a79d004fd65ed07


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39327>
_______________________________________

From report at bugs.python.org  Sun Feb 20 11:02:51 2022
From: report at bugs.python.org (miss-islington)
Date: Sun, 20 Feb 2022 16:02:51 +0000
Subject: [issue39327] shutil.rmtree using vagrant synched folder fails
In-Reply-To: <1578995152.92.0.0617677010821.issue39327@roundup.psfhosted.org>
Message-ID: <1645372971.08.0.867309771634.issue39327@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: +29579
pull_request: https://github.com/python/cpython/pull/31450

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39327>
_______________________________________

From report at bugs.python.org  Sun Feb 20 11:02:54 2022
From: report at bugs.python.org (miss-islington)
Date: Sun, 20 Feb 2022 16:02:54 +0000
Subject: [issue39327] shutil.rmtree using vagrant synched folder fails
In-Reply-To: <1578995152.92.0.0617677010821.issue39327@roundup.psfhosted.org>
Message-ID: <1645372974.46.0.233835213752.issue39327@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29580
pull_request: https://github.com/python/cpython/pull/31451

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39327>
_______________________________________

From report at bugs.python.org  Sun Feb 20 11:20:27 2022
From: report at bugs.python.org (sping)
Date: Sun, 20 Feb 2022 16:20:27 +0000
Subject: [issue46794] Please update bundled libexpat to 2.4.6 with security
 fixes (5 CVEs)
In-Reply-To: <1645227388.68.0.727345462152.issue46794@roundup.psfhosted.org>
Message-ID: <1645374027.27.0.675577303528.issue46794@roundup.psfhosted.org>


sping <sebastian at pipping.org> added the comment:

Hi Michal,


TL;DR would be:

- There is a regression but none of these test fails are related.

- There will be a release Expat 2.4.6 with the regression fixed later today.

- The 3 failing tests need (small) adjustments to Expat 2.4.5
  and these fails are not considered bugs in Expat.

I will demo a fix to 2 of the 3 test fails below:


# git diff -U1 | cat
diff --git a/Lib/test/test_minidom.py b/Lib/test/test_minidom.py
index 1663b1f114..38cea97a97 100644
--- a/Lib/test/test_minidom.py
+++ b/Lib/test/test_minidom.py
@@ -12,2 +12,3 @@
 from xml.dom.minidom import getDOMImplementation
+from xml.parsers.expat import ExpatError
 
@@ -1149,4 +1150,6 @@ def testEncodings(self):
         # of crashing
-        self.assertRaises(UnicodeDecodeError, parseString,
-                b'<fran\xe7ais>Comment \xe7a va ? Tr\xe8s bien ?</fran\xe7ais>')
+        self.assertRaises(ExpatError, parseString,
+                b'<fran\xe7ais></fran\xe7ais>')
+        self.assertRaises(ExpatError, parseString,
+                b'<franais>Comment \xe7a va ? Tr\xe8s bien ?</franais>')
 
@@ -1611,3 +1614,3 @@ def testEmptyXMLNSValue(self):
     def testExceptionOnSpacesInXMLNSValue(self):
-        with self.assertRaisesRegex(ValueError, 'Unsupported syntax'):
+        with self.assertRaisesRegex(ExpatError, "syntax error"):
             parseString('<element xmlns:abc="http:abc.com/de f g/hi/j k"><abc:foo /></element>')
             

For the third test, the key is that the closing curly brace is used as the
namespace separator in line 3660?

  self->parser = EXPAT(ParserCreate_MM)(encoding, &ExpatMemoryHandler, "}");
  
?in file Modules/_elementtree.c (which is okay but part of the test fail).

Best



Sebastian

----------
title: Please update bundled libexpat to 2.4.5 with security fixes (5 CVEs) -> Please update bundled libexpat to 2.4.6 with security fixes (5 CVEs)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46794>
_______________________________________

From report at bugs.python.org  Sun Feb 20 11:34:15 2022
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=)
Date: Sun, 20 Feb 2022 16:34:15 +0000
Subject: [issue46794] Please update bundled libexpat to 2.4.6 with security
 fixes (5 CVEs)
In-Reply-To: <1645227388.68.0.727345462152.issue46794@roundup.psfhosted.org>
Message-ID: <1645374855.85.0.71869351515.issue46794@roundup.psfhosted.org>


Micha? G?rny <mgorny at gentoo.org> added the comment:

Could you make a PR to fix the test failures?  I suppose that could speed things up and if not, I'd at least have something to pull into Gentoo.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46794>
_______________________________________

From report at bugs.python.org  Sun Feb 20 11:41:57 2022
From: report at bugs.python.org (sping)
Date: Sun, 20 Feb 2022 16:41:57 +0000
Subject: [issue46794] Please update bundled libexpat to 2.4.6 with security
 fixes (5 CVEs)
In-Reply-To: <1645227388.68.0.727345462152.issue46794@roundup.psfhosted.org>
Message-ID: <1645375317.93.0.0851720654565.issue46794@roundup.psfhosted.org>


sping <sebastian at pipping.org> added the comment:

I'm busy with the release upstream at the moment.  I'll see what I can do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46794>
_______________________________________

From report at bugs.python.org  Sun Feb 20 12:36:46 2022
From: report at bugs.python.org (Michael Hupfer)
Date: Sun, 20 Feb 2022 17:36:46 +0000
Subject: [issue46810] multiprocessing.connection.Client doesn't support ipv6
Message-ID: <1645378606.64.0.848284398217.issue46810@roundup.psfhosted.org>


New submission from Michael Hupfer <michael.hupfer at web.de>:

Hi there,

connecting a multiprocessing.connection.Client to an ipv6 address is not possible, since the address family is not passed into the constructor of class SocketClient. The constructor determines the family by calling address_type(address), which never returns AF_INET6.

The class SocketListener already implemented ipv6 support.

kind regards

----------
messages: 413599
nosy: mhupfer
priority: normal
severity: normal
status: open
title: multiprocessing.connection.Client doesn't support ipv6
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46810>
_______________________________________

From report at bugs.python.org  Sun Feb 20 13:05:57 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 20 Feb 2022 18:05:57 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645380357.77.0.497700390339.issue46771@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

The 3rd party context managers are somewhat of a red herring.
These are just try/except or try/finally blocks.

The inner cm (cm4) is irrelevant, it will see CancelledError and presumably that bubbles out. If it does any resource cleanup we can replace it with try/finally for purposes of simplifying the example.

But here's an even simpler example that poses the same question:

async with asyncio.timeout(1) as cm1:
  try:
    async with asyncio.timeout(1) as cm3:
      await asyncio.sleep(10)  # Raises CancelledError
  except TimeoutError:
    print("timed out")

Does this see CancelledError or catch TimeoutError? I had naively expected that it would catch TimeoutError, but then there's no place for the outer cancel scope to have any effect, so I agree that it should indeed see CancelledError, and "timed out" is never printed. The outer cancel scope sees CancelledError and turns it into TimeoutError.

Note that if the outer cancel scope has a longer timeout (which isn't expired yet), the try/except will catch TimeoutError. If it then enters another `await asyncio.sleep(10)` it will be cancelled and the outer cancel scope will raise TimeoutError.

How to implement this behavior? It can be done with the "cancel counter" that I proposed and Tin implemented in https://github.com/python/cpython/pull/31434.

Can it be done with the simpler version (just a cancel-requested bit), without using a nonce? I don't think so -- we don't know in which order the cancel call from the inner and outer cancel scope happen, and if the inner goes first, it cannot be aware of the outer.

So I think the cancel counter is the minimal change needed.

I have one final question, to which I don't have a firm answer yet. In Task.cancel(), if the cancel counter is already nonzero, should it still go ahead and set the must-cancel flag (or pass the cancellation on to `self._fut_waiter` -- I am still not sure what that's for :-( ). I think it only makes a difference if the task being cancelled has already caught a CancelledError (from the first cancel()) and is handling it. If we set must-cancel, then if it uses `await` it will be cancelled again. If we don't set must-cancel, its cleanup is "shielded". **Opinions?**




(PS. There's a typo in Andrew's example -- it should be "async with", not "async def".)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Sun Feb 20 13:38:30 2022
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Sun, 20 Feb 2022 18:38:30 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645382310.02.0.825577244997.issue46771@roundup.psfhosted.org>


Alex Gr?nholm <alex.gronholm at nextday.fi> added the comment:

Can I also get comments on my proposal for the "scope" parameter? Is there a use case it would not solve?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Sun Feb 20 13:45:13 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 20 Feb 2022 18:45:13 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645382713.0.0.184911687541.issue46771@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

In docs we can explain the behavior as "the outer expired timeout cancels the inner waiter, waits for CancelError bubbling up, and raising TimeoutError instead".

I agree that a counter is required for this behavior.
An alternative implementation can use the global `dict[Task, int]` for keeping counters. It can be either WeakKeyDictionary or a regular dict that deletes entries on `task.add_done_callback()` call.  We have a similar structure for `asyncio.all_tasks()` support already.

The global dict has a benefit: it doesn't overlap with the user's `.cancel()` calls but counts timeouts only.

A few words regarding task internals: _must_cancel boolean flag is set when a task doesn't wait for something, it was just created or `await sleep(0)` context switch was executed on the previous step.
Otherwise, a task always waits for a future completion, the future is stored as _fut_waiter.

If we use the global counting dict, timeout could call `.cancel()` only if the cancellation was not initiated previously. The current behavior works fine with this as the second `.cancel()` call is ignored.  Technically the ignorance could be reverted, `task.cancelling()` check is enough.

> If we don't set must-cancel, its cleanup is "shielded"

If I understand it correctly, I want this feature. Cleanup can perform async operations for a graceful resources shutdown, cancelling these cleaups look dangerous. With the current asyncio state, you can do it by calling `task.uncancel(); task.cancel()` in a line though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Sun Feb 20 14:19:45 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 20 Feb 2022 19:19:45 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645384785.9.0.201155932198.issue46771@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Updated https://github.com/python/cpython/pull/31394 demonstrated the approach with global dict for counters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Sun Feb 20 14:25:47 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 20 Feb 2022 19:25:47 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645385147.27.0.12184337928.issue46771@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Alex, the 'scope' argument can be added if it is really required. 
I'm not sure if the nonce is unavoidable still.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Sun Feb 20 14:54:05 2022
From: report at bugs.python.org (sping)
Date: Sun, 20 Feb 2022 19:54:05 +0000
Subject: [issue46811] Test suite needs adjustments for Expat >=2.4.5
Message-ID: <1645386845.86.0.727249777809.issue46811@roundup.psfhosted.org>


New submission from sping <sebastian at pipping.org>:

It has been reported at https://bugs.python.org/issue46794#msg413587 that the current CPython test suite needs some adjustments for Expat >=2.4.5. Since that is somewhat separate from updating the bundled copy of Expat to >=2.4.6, I am creating this dedicated ticket.  I pull request for discussion will follow shortly.

----------
components: XML
messages: 413605
nosy: mgorny, sping
priority: normal
severity: normal
status: open
title: Test suite needs adjustments for Expat >=2.4.5
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46811>
_______________________________________

From report at bugs.python.org  Sun Feb 20 14:55:27 2022
From: report at bugs.python.org (sping)
Date: Sun, 20 Feb 2022 19:55:27 +0000
Subject: [issue46794] Please update bundled libexpat to 2.4.6 with security
 fixes (5 CVEs)
In-Reply-To: <1645227388.68.0.727345462152.issue46794@roundup.psfhosted.org>
Message-ID: <1645386927.19.0.0384031264324.issue46794@roundup.psfhosted.org>


sping <sebastian at pipping.org> added the comment:

I have created a dedicated ticket bpo-46811 now, test suite pull request upcoming.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46794>
_______________________________________

From report at bugs.python.org  Sun Feb 20 15:05:58 2022
From: report at bugs.python.org (sping)
Date: Sun, 20 Feb 2022 20:05:58 +0000
Subject: [issue46811] Test suite needs adjustments for Expat >=2.4.5
In-Reply-To: <1645386845.86.0.727249777809.issue46811@roundup.psfhosted.org>
Message-ID: <1645387558.09.0.641406877224.issue46811@roundup.psfhosted.org>


Change by sping <sebastian at pipping.org>:


----------
keywords: +patch
pull_requests: +29581
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31453

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46811>
_______________________________________

From report at bugs.python.org  Sun Feb 20 15:09:30 2022
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Sun, 20 Feb 2022 20:09:30 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645387770.49.0.555862382259.issue46771@roundup.psfhosted.org>


Alex Gr?nholm <alex.gronholm at nextday.fi> added the comment:

> Alex, the 'scope' argument can be added if it is really required. 
> I'm not sure if the nonce is unavoidable still.

What other generic solution is there? I've read your last few messages but didn't find an answer. There needs to be some way to avoid a whole-task cancellation being ignored when it happens after a cancel scope triggers a cancellation for itself. My proposal solves that problem, and I think it eliminates the need for un-cancellation or other backwards incompatible changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Sun Feb 20 15:33:35 2022
From: report at bugs.python.org (Sam Bull)
Date: Sun, 20 Feb 2022 20:33:35 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645389215.79.0.771426533408.issue46771@roundup.psfhosted.org>


Sam Bull <m6f6g7 at sambull.org> added the comment:

> If the task is already pending a cancellation targeted at a cancel scope, the task itself cannot be cancelled anymore since calling cancel() again on the task is a no-op. This would be solved by updating the cancel message on the second call.

> I think Andrew missed one case: in his second diagram, what if the explicit cancel() happened *after* the timeout (but still in the same iteration)? That's the case that makes me want to delete those two lines from Task.cancel() (see my earlier message).

To expand on this point, I've been looking at solving the race conditions in async-timeout. To see how such a race condition can end up with a task never exiting, take a look at this example: https://github.com/aio-libs/async-timeout/issues/229#issuecomment-908502523

In the condition Guido describes, the user's cancellation is suppressed and the code runs forever.

I also wrote tests that seem to reliably reproduce the race condition (the 2nd one still seems unfixable with the current solutions, the 1st was fixed with the nonce/sentinel trick): https://github.com/aio-libs/async-timeout/commit/ab04eb53dcf49388b6e6eacf0a50bafe19c5c74b#diff-60a009a48129ae41018d588c32a6d94c54d1d2948cbc3b831fc27a9c8fdbac68L364-L421

You can see the flow of execution from the call_order assert at the end.

I think most of the solutions proposed here will still not solve this race condition. I initially proposed a solution at: https://bugs.python.org/issue45098

In short, I think that every time we call .cancel(), we need to raise another CancelledError. So, in this race condition you would get 2 CancelledErrors (via an ExceptionGroup). Then our code can catch the error with our nonce/sentinel and handle that, but also reraise any other errors which are unrelated.

----------
nosy: +dreamsorcerer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Sun Feb 20 15:42:42 2022
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 20 Feb 2022 20:42:42 +0000
Subject: [issue46232] Client certificates with UniqueIdentifier in the subject
 break ssl.peer_certificate()
In-Reply-To: <1641160999.16.0.149653140984.issue46232@roundup.psfhosted.org>
Message-ID: <1645389762.56.0.774408755954.issue46232@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset be095f6c32188bba02079d086ac8639ea37cec3c by Christian Heimes in branch 'main':
bpo-46232: Fix parsing of certs with bit string in DN (GH-30351)
https://github.com/python/cpython/commit/be095f6c32188bba02079d086ac8639ea37cec3c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46232>
_______________________________________

From report at bugs.python.org  Sun Feb 20 15:42:47 2022
From: report at bugs.python.org (miss-islington)
Date: Sun, 20 Feb 2022 20:42:47 +0000
Subject: [issue46232] Client certificates with UniqueIdentifier in the subject
 break ssl.peer_certificate()
In-Reply-To: <1641160999.16.0.149653140984.issue46232@roundup.psfhosted.org>
Message-ID: <1645389767.9.0.111247603711.issue46232@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: +29582
pull_request: https://github.com/python/cpython/pull/31454

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46232>
_______________________________________

From report at bugs.python.org  Sun Feb 20 15:46:19 2022
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Sun, 20 Feb 2022 20:46:19 +0000
Subject: [issue46805] Add low level UDP socket functions to asyncio
In-Reply-To: <1645352829.56.0.926800544018.issue46805@roundup.psfhosted.org>
Message-ID: <1645389979.81.0.217372344683.issue46805@roundup.psfhosted.org>


Change by Alex Gr?nholm <alex.gronholm at nextday.fi>:


----------
keywords: +patch
pull_requests: +29583
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31455

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46805>
_______________________________________

From report at bugs.python.org  Sun Feb 20 16:26:40 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 20 Feb 2022 21:26:40 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645392400.58.0.193359895158.issue46771@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

> Can I also get comments on my proposal for the "scope" parameter? Is there a use case it would not solve?

It looks more complicated -- the extra parameter needs to be passed around via the task and then into the CancelledError exception.

What use case do you have that cannot be solved by some variation of the "cancel count" proposal?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Sun Feb 20 16:31:35 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 20 Feb 2022 21:31:35 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645392695.86.0.444421320132.issue46771@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

(Sam Bull)
> To expand on this point, I've been looking at solving the race conditions in async-timeout. To see how such a race condition can end up with a task never exiting, take a look at this example: https://github.com/aio-libs/async-timeout/issues/229#issuecomment-908502523

This should be solved when using the cancel count -- the explicit cancel bumps the cancel count so the cancel scope (i.e. timeout()) will not raise TimeoutError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Sun Feb 20 16:46:35 2022
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Sun, 20 Feb 2022 21:46:35 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645393595.95.0.142602267361.issue46771@roundup.psfhosted.org>


Alex Gr?nholm <alex.gronholm at nextday.fi> added the comment:

> It looks more complicated -- the extra parameter needs to be passed around via the task and then into the CancelledError exception.

It reduces overall complexity by making uncancellation unnecessary and restoring backwards compatibility.

> What use case do you have that cannot be solved by some variation of the "cancel count" proposal?

I'm not sure I'm keeping proper track of the variations, but it seems it still relies on task uncancellation. But worse than that, (correct me if I'm wrong) it makes the innermost context manager handle the cancellation, even if it was requested by an outer one. If you have 3 nested "cancel scopes" and the task is cancelled once, how do you know which one of those context managers should handle the cancellation?

I'm not sure my proposal is a fix-all either, in its current form. Sure, it fixes the case where a full task cancellation would go unnoticed, but if two unrelated context managers trigger cancellation at the same time, only the first one would actually receive it. Perhaps then we need to raise a CancelledError separately for each scope? I'm not sure yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Sun Feb 20 16:58:45 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 20 Feb 2022 21:58:45 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645394325.21.0.0210852055722.issue46771@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

> This should be solved when using the cancel count -- the explicit cancel bumps the cancel count so the cancel scope (i.e. timeout()) will not raise TimeoutError.

Hmmm. Interesting!

Timeouts are not the single primitive that should care about the cancellation source.

Suppose, async code reconnects on network problem but should be terminated on explicit task cancelling.
Could cancel count be used here? Is the approach generic enough? My first answer is "why not?"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Sun Feb 20 17:00:37 2022
From: report at bugs.python.org (=?utf-8?q?Tin_Tvrtkovi=C4=87?=)
Date: Sun, 20 Feb 2022 22:00:37 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645394437.15.0.830452592311.issue46771@roundup.psfhosted.org>


Tin Tvrtkovi? <tinchester at gmail.com> added the comment:

@Alex you can follow along here: https://github.com/python/cpython/pull/31394

With the cancel_counter approach, a context manager knows whether to handle or propagate the exception by examining its own local state and the remaining counter on the task. If after uncancelling the counter is still non-zero, it propagates.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Sun Feb 20 17:54:13 2022
From: report at bugs.python.org (=?utf-8?q?Tin_Tvrtkovi=C4=87?=)
Date: Sun, 20 Feb 2022 22:54:13 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645397653.02.0.0394249039667.issue46771@roundup.psfhosted.org>


Change by Tin Tvrtkovi? <tinchester at gmail.com>:


----------
pull_requests: +29584
pull_request: https://github.com/python/cpython/pull/31434

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Sun Feb 20 18:06:31 2022
From: report at bugs.python.org (Irit Katriel)
Date: Sun, 20 Feb 2022 23:06:31 +0000
Subject: [issue46808] remove NEXT_BLOCK() from compile.c
In-Reply-To: <1645368528.16.0.363497063609.issue46808@roundup.psfhosted.org>
Message-ID: <1645398391.66.0.675925829253.issue46808@roundup.psfhosted.org>


Irit Katriel <iritkatriel at gmail.com> added the comment:

The patch in PR31448 delays the creation of an implicit block to when it is needed (do if we begin using another block before a new instruction is added, the implicit block is never created). 

I counted how many empty blocks are being detected by the optimizer during "python -m test" and this number went down from 41798 (for main) to 35405 (for my PR), which shows that it is not only a theoretical possibility but actually happens. It would be things like:

NEXT_BLOCK()
VISIT_SEQ(c, stmt, s->v.Try.orelse);
compiler_use_next_block(c, end);

where the orelse block is empty.


In summary, the patch simplifies the code as well as making it more efficient.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46808>
_______________________________________

From report at bugs.python.org  Sun Feb 20 18:17:01 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 20 Feb 2022 23:17:01 +0000
Subject: [issue46805] Add low level UDP socket functions to asyncio
In-Reply-To: <1645352829.56.0.926800544018.issue46805@roundup.psfhosted.org>
Message-ID: <1645399021.07.0.637867844469.issue46805@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Sorry, I was not clear maybe.
Newly added methods can have a `flag` argument from the very beginning.
Adding a flag to already existing methods requires a separate issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46805>
_______________________________________

From report at bugs.python.org  Sun Feb 20 18:22:28 2022
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Sun, 20 Feb 2022 23:22:28 +0000
Subject: [issue46805] Add low level UDP socket functions to asyncio
In-Reply-To: <1645352829.56.0.926800544018.issue46805@roundup.psfhosted.org>
Message-ID: <1645399348.57.0.654384428306.issue46805@roundup.psfhosted.org>


Alex Gr?nholm <alex.gronholm at nextday.fi> added the comment:

Yeah, my question was specific about the new functions, so I understood that a separate PR should add that to the all the relevant functions.

I have a different problem now however: the test suite is failing in CI but not locally. It's giving me NameError about a function used by existing tests but for some reason, it's not defined in the scope of the new test functions?!?

The proactor version of sock_recvfrom_into() is giving me quite a bit of trouble, as it seems to require heavy handed changes in _overlapped.c. 

I'm also not very successful in testing cases where sendto() would fill the kernel buffer and raise BlockingIOError. With TCP this is easy but with UDP near impossible to do in a controlled fashion in the test suite.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46805>
_______________________________________

From report at bugs.python.org  Sun Feb 20 19:00:29 2022
From: report at bugs.python.org (Sam Bull)
Date: Mon, 21 Feb 2022 00:00:29 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645401629.54.0.793383386212.issue46771@roundup.psfhosted.org>


Sam Bull <m6f6g7 at sambull.org> added the comment:

> This should be solved when using the cancel count -- the explicit cancel bumps the cancel count so the cancel scope (i.e. timeout()) will not raise TimeoutError.

It will probably work in this case. But, what about more complex cases? If there are 2 different timeouts and the possibility of a user cancellation, and we have a count of 2 cancellations, then what happened? 2 timeouts, or 1 timeout and user cancellation? Without being able to check the nonces of each cancellation, I don't see how this would work. Or if the user calls .cancel() twice explicitly, then you cancel both timeouts, even though it had nothing to do with the timeout.

Propagating an ExceptionGroup where every exception can be inspected to see if it was caused by this code or not still seems like the safe option to me (and obviously still has the cancel count implicitly).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Sun Feb 20 19:05:23 2022
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Mon, 21 Feb 2022 00:05:23 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645401923.59.0.890374370257.issue46771@roundup.psfhosted.org>


Alex Gr?nholm <alex.gronholm at nextday.fi> added the comment:

> Propagating an ExceptionGroup where every exception can be inspected to see if it was caused by this code or not still seems like the safe option to me (and obviously still has the cancel count implicitly).

Note that this, too, causes backwards incompatible changes in cancellation behavior. Previously, when the task was cancelled twice, only one CancelledError was raised. Now it would raise a BaseExceptionGroup instead.

The current backward incompatible changes in cancellation behavior are already causing 10 tests to fail in the AnyIO test suite. I'm trying to find an alternate solution that does not break anything.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Sun Feb 20 19:13:13 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Mon, 21 Feb 2022 00:13:13 +0000
Subject: [issue43853] [sqlite3] Improve sqlite3_value_text() error handling
In-Reply-To: <1618480809.83.0.17163581819.issue43853@roundup.psfhosted.org>
Message-ID: <1645402393.46.0.597610739025.issue43853@roundup.psfhosted.org>


Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:


New changeset ba457fe6f8e50ad3ef3ceffb75dee96629a42ad7 by Erlend Egeberg Aasland in branch '3.10':
[3.10] bpo-43853: Expand test suite for SQLite UDF's (GH-27642) (GH-31030)
https://github.com/python/cpython/commit/ba457fe6f8e50ad3ef3ceffb75dee96629a42ad7


----------
nosy: +Jelle Zijlstra

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43853>
_______________________________________

From report at bugs.python.org  Sun Feb 20 19:19:10 2022
From: report at bugs.python.org (Sam Bull)
Date: Mon, 21 Feb 2022 00:19:10 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645402750.88.0.664265853878.issue46771@roundup.psfhosted.org>


Sam Bull <m6f6g7 at sambull.org> added the comment:

Actually, in your counter proposal, you say:

> Such context managers should still keep track of whether they cancelled the task themselves or not, and if they did, they should always call t.uncancel().

But, if we are using nonces on the CancelledError to keep track, then only 1 context manager will know if it was themselves or not. This is exactly why I'm proposing to use multiple CancelledErrors, so that every nonce is passed to the handling code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Sun Feb 20 19:20:49 2022
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Mon, 21 Feb 2022 00:20:49 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645402849.47.0.271946853243.issue46771@roundup.psfhosted.org>


Alex Gr?nholm <alex.gronholm at nextday.fi> added the comment:

> But, if we are using nonces on the CancelledError to keep track, then only 1 context manager will know if it was themselves or not. This is exactly why I'm proposing to use multiple CancelledErrors, so that every nonce is passed to the handling code.

Raising multiple CancelledErrors is not the only way to accomplish this. We could store the nonces in a single CancelledError instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Sun Feb 20 19:22:51 2022
From: report at bugs.python.org (Sam Bull)
Date: Mon, 21 Feb 2022 00:22:51 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645402971.07.0.67533515352.issue46771@roundup.psfhosted.org>


Sam Bull <m6f6g7 at sambull.org> added the comment:

> Previously, when the task was cancelled twice, only one CancelledError was raised. Now it would raise a BaseExceptionGroup instead.

I was under the impression that ExceptionGroup was somewhat backwards compatible, in that you could still use `except CancelledError:` and it would catch all the errors in the group. But, maybe I'm wrong, I've not seen the documentation for the final feature yet, but that's the impression I got from the PEP.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Sun Feb 20 19:24:07 2022
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Mon, 21 Feb 2022 00:24:07 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645403047.48.0.487802941159.issue46771@roundup.psfhosted.org>


Alex Gr?nholm <alex.gronholm at nextday.fi> added the comment:

> I was under the impression that ExceptionGroup was somewhat backwards compatible, in that you could still use `except CancelledError:` and it would catch all the errors in the group. But, maybe I'm wrong, I've not seen the documentation for the final feature yet, but that's the impression I got from the PEP.

No, you need the new except* syntax for that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Sun Feb 20 19:24:15 2022
From: report at bugs.python.org (Sam Bull)
Date: Mon, 21 Feb 2022 00:24:15 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645403055.33.0.0153569060197.issue46771@roundup.psfhosted.org>


Sam Bull <m6f6g7 at sambull.org> added the comment:

> We could store the nonces in a single CancelledError instead.

Indeed, my initial proposal was exactly that, but after learning about ExceptionGroup, I thought that was a cleaner approach.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Sun Feb 20 19:47:24 2022
From: report at bugs.python.org (Stanley)
Date: Mon, 21 Feb 2022 00:47:24 +0000
Subject: [issue45492] stdlib inspect documentation on code.co_names is
 incorrect
In-Reply-To: <1634381128.63.0.689395571563.issue45492@roundup.psfhosted.org>
Message-ID: <1645404444.08.0.574303026545.issue45492@roundup.psfhosted.org>


Change by Stanley <ostanley.lee at gmail.com>:


----------
keywords: +patch
nosy: +slateny
nosy_count: 2.0 -> 3.0
pull_requests: +29585
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31456

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45492>
_______________________________________

From report at bugs.python.org  Sun Feb 20 20:06:37 2022
From: report at bugs.python.org (Stanley)
Date: Mon, 21 Feb 2022 01:06:37 +0000
Subject: [issue36557] [doc] Clarify the meaning of /uninstall in windows cli
In-Reply-To: <1554726023.31.0.350138244198.issue36557@roundup.psfhosted.org>
Message-ID: <1645405597.39.0.315451063653.issue36557@roundup.psfhosted.org>


Change by Stanley <ostanley.lee at gmail.com>:


----------
keywords: +patch
nosy: +slateny
nosy_count: 7.0 -> 8.0
pull_requests: +29586
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31457

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36557>
_______________________________________

From report at bugs.python.org  Sun Feb 20 20:48:37 2022
From: report at bugs.python.org (Barney Gale)
Date: Mon, 21 Feb 2022 01:48:37 +0000
Subject: [issue42777] WindowsPath does not implement is_mount but ntpath
 implements and offers a ismount method
In-Reply-To: <1609215479.73.0.163162738943.issue42777@roundup.psfhosted.org>
Message-ID: <1645408117.5.0.967173186512.issue42777@roundup.psfhosted.org>


Change by Barney Gale <barney.gale at gmail.com>:


----------
keywords: +patch
nosy: +barneygale
nosy_count: 1.0 -> 2.0
pull_requests: +29587
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31458

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42777>
_______________________________________

From report at bugs.python.org  Sun Feb 20 21:00:28 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 21 Feb 2022 02:00:28 +0000
Subject: [issue46757] dataclasses should define an empty __post_init__
In-Reply-To: <1644923607.6.0.495534870715.issue46757@roundup.psfhosted.org>
Message-ID: <1645408828.86.0.577782451349.issue46757@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

-1

* I concur with Eric that this is mostly not needed.  Probably 99.95% of dataclass use case don't need this.  When it is needed, it is trivial to implement and probably should be explicit rather that implicit.

* Vedran is also correct in noting that it would sometimes mask errors.

* There is a runtime cost for all dataclasses that do not use __post_init__.  Calling an empty method takes time.  We shouldn't make all users pay for a feature that almost no one needs.

* With respect to use of super(), it might help a little bit, but only because __post_init__() takes no arguments.  For the other methods in cooperative multiple inheritance, a user would need to either incorporate a straight forward hasattr() check or add a terminal root class as described in super-considered-super.  I see no reason to make __post_init__ a special case that would differ from other methods (for example, object() doesn't provide an empty __call__ or __getitem__).

* Adding a default __post_init__ will create a new problem.  Currently, it is possible to easily introspect and determine whether a __post_init__ has been provided, but if there is an empty default, it becomes a much more tricky test.  We had this problem with functools.total_ordering.  When that tool was first created, we could easily use hasattr() to test for a user defined rich comparison method.  But after default methods were added to object(), the test because much more delicate:  ``getattr(cls, op, None) is not getattr(object, op, None)``.  Likewise the Hashable ABC cannot just use hasattr() because __hash__() is always present and has to be set to None to turn it off.  A default __post_init__ is worse than both cases.  You can't test for it, so you just have to call it, not knowing in advance whether it would do anything.

* Anyone supporting multiple versions of Python will still need to write the hasattr() check or provide a terminal/root class.  They won't be able to rely on the default being present.

I recommend leaving dataclasses as is.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46757>
_______________________________________

From report at bugs.python.org  Sun Feb 20 21:08:14 2022
From: report at bugs.python.org (Barney Gale)
Date: Mon, 21 Feb 2022 02:08:14 +0000
Subject: [issue46733] pathlib.Path methods can raise NotImplementedError
In-Reply-To: <1644694513.05.0.985214969865.issue46733@roundup.psfhosted.org>
Message-ID: <1645409294.22.0.230672638525.issue46733@roundup.psfhosted.org>


Barney Gale <barney.gale at gmail.com> added the comment:

Thanks both. I've adjusted PR 31338 to leave is_mount() unchanged. I've opened a new pull request that implements is_mount() on Windows using ntpath.ismount(): PR 31458

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46733>
_______________________________________

From report at bugs.python.org  Sun Feb 20 21:36:33 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 21 Feb 2022 02:36:33 +0000
Subject: [issue46732] Builtin __bool__ docstrings are wrong
In-Reply-To: <1644693001.93.0.383788579819.issue46732@roundup.psfhosted.org>
Message-ID: <1645410993.28.0.613371860137.issue46732@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

For whatever reason, all builtins with a __bool__ method appear to share the same docstring.  For example,

>>> range.__bool__.__doc__
'self != 0'
>>> bool(range(0))
False
>>> bool(range(1))
True

The concrete collection classes have their lengths stored internally so bool use that via len(self).  But len(range) != 0 iff stop != start.

----------
title: None.__bool__ docstring is wrong -> Builtin __bool__ docstrings are wrong

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46732>
_______________________________________

From report at bugs.python.org  Sun Feb 20 21:47:19 2022
From: report at bugs.python.org (Mark Gordon)
Date: Mon, 21 Feb 2022 02:47:19 +0000
Subject: [issue46812] Thread starvation with threading.Condition
Message-ID: <1645411639.57.0.97137643572.issue46812@roundup.psfhosted.org>


New submission from Mark Gordon <msg555 at gmail.com>:

When using Condition variables to manage access to shared resources you can run into starvation issues due to the thread that just gave up a resource (making a call to notify/notify_all) having priority on immediately reacquiring that resource before any of the waiting threads get a chance. The issue appears to arise because unlike the Lock implementation Condition variables are implemented partly in Python and a thread must hold the GIL when it reacquires its underlying condition variable lock.

Coupled with Python's predictable switch interval this means that if a thread notifies others of a resource being available and then shortly after attempts to reacquire that resource it will be able to do so since it will have held the GIL the entire time.

This can lead to some threads being entirely starved (forever) for access to a shared resource. This came up in a real world situation for me when I had multiple threads trying to access a shared database connection repeatedly without blocking between accesses. Some threads were never getting a connection leading to unexpected timeouts. See https://github.com/sqlalchemy/sqlalchemy/issues/7679


Here's a simple example of this issue using the queue.Queue implementation: https://gist.github.com/msg555/36a10bb5a0c0fe8c89c89d8c05d00e21

Similar example just using Condition variables directly: https://gist.github.com/msg555/dd491078cf10dbabbe7b1cd142644910

Analagous C++ implementation. On Linux 5.13 this is still not _that_ fair but does not completely starve threads: https://gist.github.com/msg555/14d8029b910704a42d372004d3afa465

Thoughts:
- Is this something that's worth fixing? The behavior at the very least is surprising and I was unable to find discussion or documentation of it.
- Can Condition variables be implemented using standard C libraries? (e.g. pthreads) Maybe at least this can happen when using the standard threading.Lock as the Condition variables lock?
- I mocked up a fair Condition variable implementation at https://github.com/msg555/fairsync/blob/main/fairsync/condition.py. However fairness comes at its own overhead of additional context switching.


Tested on Python 3.7-3.10

----------
components: Library (Lib)
messages: 413629
nosy: msg555
priority: normal
severity: normal
status: open
title: Thread starvation with threading.Condition
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46812>
_______________________________________

From report at bugs.python.org  Sun Feb 20 22:12:22 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 21 Feb 2022 03:12:22 +0000
Subject: [issue46812] Thread starvation with threading.Condition
In-Reply-To: <1645411639.57.0.97137643572.issue46812@roundup.psfhosted.org>
Message-ID: <1645413142.77.0.976162254994.issue46812@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/issue46812>
_______________________________________

From report at bugs.python.org  Sun Feb 20 22:24:41 2022
From: report at bugs.python.org (Tim Peters)
Date: Mon, 21 Feb 2022 03:24:41 +0000
Subject: [issue46812] Thread starvation with threading.Condition
In-Reply-To: <1645411639.57.0.97137643572.issue46812@roundup.psfhosted.org>
Message-ID: <1645413881.51.0.931887390075.issue46812@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Unassigning myself - I have no insight into this.

I suspect the eternally contentious issue 7946 is related.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46812>
_______________________________________

From report at bugs.python.org  Sun Feb 20 22:35:26 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 21 Feb 2022 03:35:26 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645414526.93.0.652170686947.issue46771@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

[Alex]
> The current backward incompatible changes in cancellation behavior are already causing 10 tests to fail in the AnyIO test suite. I'm trying to find an alternate solution that does not break anything.

Are you sure that the tests aren't over-specified? Maybe you could link to the failing test run? (Though I worry that understanding your test infrastructure might be a bit much.)

That said, when I landed this change I wasn't at all sure that it wouldn't break things (there just weren't any asyncio tests that it broke), and I am totally willing to roll that part back or change it if it breaks a valid use case.

So basically I am saying please chill, feature freeze isn't until late May.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Sun Feb 20 22:46:12 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 21 Feb 2022 03:46:12 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645415172.66.0.320356756751.issue46771@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

[Sam]
> It will probably work in this case. But, what about more complex cases? If there are 2 different timeouts and the possibility of a user cancellation, and we have a count of 2 cancellations, then what happened? 2 timeouts, or 1 timeout and user cancellation? Without being able to check the nonces of each cancellation, I don't see how this would work. Or if the user calls .cancel() twice explicitly, then you cancel both timeouts, even though it had nothing to do with the timeout.

The cancel scope must record whether it called cancel() or not. (This is what TaskGroup does.) Suppose the inner timeout cancels and sees two cancellations. It knows one of those is its own, so it calls uncancel() and raises CancelledError. Now the outer cancel scope sees one cancellation. If it did not call cancel(), it knows it was a user cancellation (or another, even more outer, cancel scope -- it really doesn't matter), and it raises CancelledError. If the outer cancel scope also called cancel(), it knows that this is so, and it in turn calls uncancel() -- and it knows (by the count returned from uncancel()) that there are no more cancellations, so it raises TimeoutError.

QED

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Sun Feb 20 22:53:04 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 21 Feb 2022 03:53:04 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645415584.85.0.192200658816.issue46771@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

PS. The cancel count can work whether or not cancel() returns without setting must-cancel (or cancelling the underlying future/task) when there's already a cancellation in progress. Other things may be different though. We have to look into this separately.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Sun Feb 20 22:58:40 2022
From: report at bugs.python.org (John)
Date: Mon, 21 Feb 2022 03:58:40 +0000
Subject: [issue32514] 0x80070002 - The system cannot find the file specified
In-Reply-To: <1515358496.6.0.467229070634.issue32514@psf.upfronthosting.co.za>
Message-ID: <1645415920.99.0.986429805866.issue32514@roundup.psfhosted.org>


Change by John <TylorBeatty1 at gmail.com>:


Removed file: https://bugs.python.org/file47373/Python 3.6.4 (32-bit)_20180107153053_000_core_JustForMe[3206].log

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32514>
_______________________________________

From report at bugs.python.org  Sun Feb 20 22:59:00 2022
From: report at bugs.python.org (John)
Date: Mon, 21 Feb 2022 03:59:00 +0000
Subject: [issue32514] 0x80070002 - The system cannot find the file specified
In-Reply-To: <1515358496.6.0.467229070634.issue32514@psf.upfronthosting.co.za>
Message-ID: <1645415940.06.0.307804703488.issue32514@roundup.psfhosted.org>


Change by John <TylorBeatty1 at gmail.com>:


Removed file: https://bugs.python.org/file47370/Python 3.6.4 (32-bit)_20180107153053[3191].log

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32514>
_______________________________________

From report at bugs.python.org  Sun Feb 20 23:16:47 2022
From: report at bugs.python.org (neonene)
Date: Mon, 21 Feb 2022 04:16:47 +0000
Subject: [issue45116] Performance regression 3.10b1: inlining issue in the big
 _PyEval_EvalFrameDefault() function with Visual Studio (MSC)
In-Reply-To: <1630942038.24.0.156228540374.issue45116@roundup.psfhosted.org>
Message-ID: <1645417007.09.0.123555165506.issue45116@roundup.psfhosted.org>


Change by neonene <nicesalmon at gmail.com>:


----------
pull_requests: +29588
pull_request: https://github.com/python/cpython/pull/31459

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45116>
_______________________________________

From report at bugs.python.org  Sun Feb 20 23:37:05 2022
From: report at bugs.python.org (Stanley)
Date: Mon, 21 Feb 2022 04:37:05 +0000
Subject: [issue31327] [doc] Add example of platform-specific support for
 negative timestamps to the time doc
In-Reply-To: <1504286649.82.0.482783873664.issue31327@psf.upfronthosting.co.za>
Message-ID: <1645418225.02.0.753305033568.issue31327@roundup.psfhosted.org>


Change by Stanley <ostanley.lee at gmail.com>:


----------
keywords: +patch
nosy: +slateny
nosy_count: 8.0 -> 9.0
pull_requests: +29589
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31460

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31327>
_______________________________________

From report at bugs.python.org  Mon Feb 21 02:32:59 2022
From: report at bugs.python.org (penguin_wwy)
Date: Mon, 21 Feb 2022 07:32:59 +0000
Subject: [issue46813] Allow developer to resize the dictionary
Message-ID: <1645428779.91.0.472362648196.issue46813@roundup.psfhosted.org>


New submission from penguin_wwy <940375606 at qq.com>:

https://github.com/faster-cpython/ideas/discussions/288

----------
components: Interpreter Core
messages: 413634
nosy: penguin_wwy
priority: normal
severity: normal
status: open
title: Allow developer to resize the dictionary
type: enhancement
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46813>
_______________________________________

From report at bugs.python.org  Mon Feb 21 02:37:35 2022
From: report at bugs.python.org (penguin_wwy)
Date: Mon, 21 Feb 2022 07:37:35 +0000
Subject: [issue46813] Allow developer to resize the dictionary
In-Reply-To: <1645428779.91.0.472362648196.issue46813@roundup.psfhosted.org>
Message-ID: <1645429055.44.0.233272447527.issue46813@roundup.psfhosted.org>


Change by penguin_wwy <940375606 at qq.com>:


----------
keywords: +patch
pull_requests: +29590
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31461

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46813>
_______________________________________

From report at bugs.python.org  Mon Feb 21 02:41:47 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 21 Feb 2022 07:41:47 +0000
Subject: [issue46813] Allow developer to resize the dictionary
In-Reply-To: <1645428779.91.0.472362648196.issue46813@roundup.psfhosted.org>
Message-ID: <1645429307.65.0.696620860512.issue46813@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

This idea surfaced once before and Guido shot it down.  IIRC the rationale was the exposed implementation details, that would challenging for users to consistently set the size correctly, and that it may not make sense for other implementations.

This was a good while ago so it may be worth scanning the tracker or python-dev archives to find where he opined.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46813>
_______________________________________

From report at bugs.python.org  Mon Feb 21 03:08:00 2022
From: report at bugs.python.org (miss-islington)
Date: Mon, 21 Feb 2022 08:08:00 +0000
Subject: [issue39327] shutil.rmtree using vagrant synched folder fails
In-Reply-To: <1578995152.92.0.0617677010821.issue39327@roundup.psfhosted.org>
Message-ID: <1645430880.17.0.689694491187.issue39327@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 959846be52b03da57f50ebc07f99ec262a86e860 by Miss Islington (bot) in branch '3.9':
bpo-39327: Close file descriptors as soon as possible in shutil.rmtree (GH-31384)
https://github.com/python/cpython/commit/959846be52b03da57f50ebc07f99ec262a86e860


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39327>
_______________________________________

From report at bugs.python.org  Mon Feb 21 03:08:00 2022
From: report at bugs.python.org (miss-islington)
Date: Mon, 21 Feb 2022 08:08:00 +0000
Subject: [issue39327] shutil.rmtree using vagrant synched folder fails
In-Reply-To: <1578995152.92.0.0617677010821.issue39327@roundup.psfhosted.org>
Message-ID: <1645430880.28.0.305510097235.issue39327@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 95d6271f1997580f8cb8a2985d0cd48af912763f by Miss Islington (bot) in branch '3.10':
bpo-39327: Close file descriptors as soon as possible in shutil.rmtree (GH-31384)
https://github.com/python/cpython/commit/95d6271f1997580f8cb8a2985d0cd48af912763f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39327>
_______________________________________

From report at bugs.python.org  Mon Feb 21 03:08:00 2022
From: report at bugs.python.org (miss-islington)
Date: Mon, 21 Feb 2022 08:08:00 +0000
Subject: [issue39327] shutil.rmtree using vagrant synched folder fails
In-Reply-To: <1578995152.92.0.0617677010821.issue39327@roundup.psfhosted.org>
Message-ID: <1645430880.17.0.689694491187.issue39327@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 959846be52b03da57f50ebc07f99ec262a86e860 by Miss Islington (bot) in branch '3.9':
bpo-39327: Close file descriptors as soon as possible in shutil.rmtree (GH-31384)
https://github.com/python/cpython/commit/959846be52b03da57f50ebc07f99ec262a86e860


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39327>
_______________________________________

From report at bugs.python.org  Mon Feb 21 03:09:37 2022
From: report at bugs.python.org (penguin_wwy)
Date: Mon, 21 Feb 2022 08:09:37 +0000
Subject: [issue46813] Allow developer to resize the dictionary
In-Reply-To: <1645428779.91.0.472362648196.issue46813@roundup.psfhosted.org>
Message-ID: <1645430977.28.0.463521473332.issue46813@roundup.psfhosted.org>


penguin_wwy <940375606 at qq.com> added the comment:

I tried to look for it in issue list two days ago but couldn't find it. Maybe I should have been more careful :(.

However, I think it is a useful modification. Just need to return a dict that satisfies the user's requirements, and the developers themselves should be responsible for their code (if they can't use it exactly, they should choose to use the default, and python needs to do is provide that optional ability)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46813>
_______________________________________

From report at bugs.python.org  Mon Feb 21 03:25:45 2022
From: report at bugs.python.org (Josh A. Mitchell)
Date: Mon, 21 Feb 2022 08:25:45 +0000
Subject: [issue46814] Documentation for constructin abstract base classes is
 misleading
Message-ID: <1645431945.33.0.392126816255.issue46814@roundup.psfhosted.org>


New submission from Josh A. Mitchell <yoshanuikabundi at gmail.com>:

The docs for the abc[0] module states "With this class, an abstract base class can be created by simply deriving from ABC", and then gives an example of a class with no contents. This is not sufficient to construct an ABC; an ABC in Python additionally requires at least one abstract method. This can be demonstrated by executing the example code and instantiating it (ABCs cannot be instantiated) or calling the inspect.isabstract() function on it (returns False). The requirement is also (cryptically) explicated in the Implementation paragraph of the "The abc Module: an ABC Support Framework" section of PEP 3119[1]. This requirement of implementing an abstract method is not mentioned in the docs for the abc module or in the module's docstrings. An ABC with no abstract methods is sometimes used to mark a parent class that is not intended to be instantiated on its own, so this limitation of the Python implementation should be documented.

[0] https://docs.python.org/3.11/library/abc.html

[1] https://www.python.org/dev/peps/pep-3119/#the-abc-module-an-abc-support-framework

----------
assignee: docs at python
components: Documentation
messages: 413639
nosy: Yoshanuikabundi, docs at python
priority: normal
severity: normal
status: open
title: Documentation for constructin abstract base classes is misleading
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46814>
_______________________________________

From report at bugs.python.org  Mon Feb 21 03:28:52 2022
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 21 Feb 2022 08:28:52 +0000
Subject: [issue46813] Allow developer to resize the dictionary
In-Reply-To: <1645428779.91.0.472362648196.issue46813@roundup.psfhosted.org>
Message-ID: <1645432132.82.0.488941661464.issue46813@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

As I commented in https://github.com/faster-cpython/ideas/discussions/288, your benchmark is not fair.

Include `{}` and `{}.resize(len(cases))` into the measured function.

----------
nosy: +methane

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46813>
_______________________________________

From report at bugs.python.org  Mon Feb 21 03:30:09 2022
From: report at bugs.python.org (Stanley)
Date: Mon, 21 Feb 2022 08:30:09 +0000
Subject: [issue23747] [doc] platform module exposes win32_ver function on
 posix systems
In-Reply-To: <1427103016.81.0.503768282249.issue23747@psf.upfronthosting.co.za>
Message-ID: <1645432209.93.0.887970335112.issue23747@roundup.psfhosted.org>


Change by Stanley <ostanley.lee at gmail.com>:


----------
keywords: +patch
nosy: +slateny
nosy_count: 4.0 -> 5.0
pull_requests: +29591
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31462

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23747>
_______________________________________

From report at bugs.python.org  Mon Feb 21 04:15:43 2022
From: report at bugs.python.org (Josh A. Mitchell)
Date: Mon, 21 Feb 2022 09:15:43 +0000
Subject: [issue46814] Documentation for constructin abstract base classes is
 misleading
In-Reply-To: <1645431945.33.0.392126816255.issue46814@roundup.psfhosted.org>
Message-ID: <1645434943.1.0.71474156406.issue46814@roundup.psfhosted.org>


Change by Josh A. Mitchell <yoshanuikabundi at gmail.com>:


----------
keywords: +patch
pull_requests: +29592
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31463

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46814>
_______________________________________

From report at bugs.python.org  Mon Feb 21 04:19:35 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 21 Feb 2022 09:19:35 +0000
Subject: [issue39327] shutil.rmtree using vagrant synched folder fails
In-Reply-To: <1578995152.92.0.0617677010821.issue39327@roundup.psfhosted.org>
Message-ID: <1645435175.89.0.479704810584.issue39327@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.11, Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39327>
_______________________________________

From report at bugs.python.org  Mon Feb 21 04:37:46 2022
From: report at bugs.python.org (miss-islington)
Date: Mon, 21 Feb 2022 09:37:46 +0000
Subject: [issue46232] Client certificates with UniqueIdentifier in the subject
 break ssl.peer_certificate()
In-Reply-To: <1641160999.16.0.149653140984.issue46232@roundup.psfhosted.org>
Message-ID: <1645436266.7.0.468591111652.issue46232@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 633d0f90f933515a9fca21a38cf87a8baf8ddc7d by Miss Islington (bot) in branch '3.10':
bpo-46232: Fix parsing of certs with bit string in DN (GH-30351)
https://github.com/python/cpython/commit/633d0f90f933515a9fca21a38cf87a8baf8ddc7d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46232>
_______________________________________

From report at bugs.python.org  Mon Feb 21 04:59:19 2022
From: report at bugs.python.org (=?utf-8?b?6IKW5bCP5bCP?=)
Date: Mon, 21 Feb 2022 09:59:19 +0000
Subject: [issue46232] Client certificates with UniqueIdentifier in the subject
 break ssl.peer_certificate()
In-Reply-To: <1641160999.16.0.149653140984.issue46232@roundup.psfhosted.org>
Message-ID: <1645437559.92.0.136489456153.issue46232@roundup.psfhosted.org>


??? <xiaox55066 at gmail.com> added the comment:

http://www.strong19.com/

----------
nosy: +xiaox55066

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46232>
_______________________________________

From report at bugs.python.org  Mon Feb 21 05:22:11 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Mon, 21 Feb 2022 10:22:11 +0000
Subject: [issue46815] Extra `DeprecationWarning` when running `lib2to3` tests
Message-ID: <1645438931.34.0.27153420052.issue46815@roundup.psfhosted.org>


New submission from Nikita Sobolev <mail at sobolevn.me>:

I first noticed it in the buildbot logs:

```
0:24:42 load avg: 3.87 [430/431/1] test_lib2to3 passed (1 min 38 sec)
<string>:2: DeprecationWarning: lib2to3 package is deprecated and may not be able to parse Python 3.10+
```

But, it also happens locally:

```
? ./python.exe Lib/test/test_lib2to3.py
/Users/sobolev/Desktop/cpython/Lib/unittest/loader.py:350: DeprecationWarning: lib2to3 package is deprecated and may not be able to parse Python 3.10+
  __import__(name)
Refactor file: /Users/sobolev/Desktop/cpython/Lib/lib2to3/refactor.py
```

After my patch it is gone:

```
? ./python.exe Lib/test/test_lib2to3.py
Refactor file: /Users/sobolev/Desktop/cpython/Lib/lib2to3/refactor.py
```

----------
components: Tests
messages: 413643
nosy: Jelle Zijlstra, benjamin.peterson, lukasz.langa, sobolevn
priority: normal
severity: normal
status: open
title: Extra `DeprecationWarning` when running `lib2to3` tests
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46815>
_______________________________________

From report at bugs.python.org  Mon Feb 21 05:23:36 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Mon, 21 Feb 2022 10:23:36 +0000
Subject: [issue46815] Extra `DeprecationWarning` when running `lib2to3` tests
In-Reply-To: <1645438931.34.0.27153420052.issue46815@roundup.psfhosted.org>
Message-ID: <1645439016.14.0.708095903763.issue46815@roundup.psfhosted.org>


Change by Nikita Sobolev <mail at sobolevn.me>:


----------
keywords: +patch
pull_requests: +29594
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31464

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46815>
_______________________________________

From report at bugs.python.org  Mon Feb 21 05:33:08 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 21 Feb 2022 10:33:08 +0000
Subject: [issue46733] pathlib.Path methods can raise NotImplementedError
In-Reply-To: <1644694513.05.0.985214969865.issue46733@roundup.psfhosted.org>
Message-ID: <1645439588.18.0.575714214415.issue46733@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

> In the long run, it would be better to migrate the implementations in the other direction. Rewrite genericpath, ntpath, posixpath, and parts of shutil to use PurePath and Path objects.

pathlib does not allow to distinguish "path" from "path/".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46733>
_______________________________________

From report at bugs.python.org  Mon Feb 21 05:45:57 2022
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 21 Feb 2022 10:45:57 +0000
Subject: [issue46329] Split up the CALL_NO_KW and CALL_KW instructions.
In-Reply-To: <1641819285.76.0.605357810946.issue46329@roundup.psfhosted.org>
Message-ID: <1645440357.94.0.451015558678.issue46329@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
pull_requests: +29595
pull_request: https://github.com/python/cpython/pull/31465

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46329>
_______________________________________

From report at bugs.python.org  Mon Feb 21 05:48:39 2022
From: report at bugs.python.org (Oleg Iarygin)
Date: Mon, 21 Feb 2022 10:48:39 +0000
Subject: [issue46816] Remove declarations for non-__STDC__ compilers
Message-ID: <1645440519.15.0.480736088206.issue46816@roundup.psfhosted.org>


New submission from Oleg Iarygin <oleg at arhadthedev.net>:

Currently, Python code contains two places where presence of __STDC__ is checked:

- Include/internal/pycore_pymath.h:12
- Python/errors.c:13

These checks are used to add extern functions missing in non-standard versions of math.h.

However, after Python switched to C99, there is a guarantee that every compiler conforms to ISO C so checks of __STDC__ have no sense anymore.

Note, that:

- errors.c check was added by 53e8d44 on 9 Mar 1995
- pycore_pymath.h check was initially added into Objects/floatobject.c by eddc144 on 20 Nov 2003 then moved to pycore_pymath by 53876d9.

----------
components: Interpreter Core
messages: 413645
nosy: arhadthedev
priority: normal
severity: normal
status: open
title: Remove declarations for non-__STDC__ compilers
type: enhancement
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46816>
_______________________________________

From report at bugs.python.org  Mon Feb 21 05:49:06 2022
From: report at bugs.python.org (Oleg Iarygin)
Date: Mon, 21 Feb 2022 10:49:06 +0000
Subject: [issue46816] Remove declarations for non-__STDC__ compilers
In-Reply-To: <1645440519.15.0.480736088206.issue46816@roundup.psfhosted.org>
Message-ID: <1645440546.18.0.51077141754.issue46816@roundup.psfhosted.org>


Change by Oleg Iarygin <oleg at arhadthedev.net>:


----------
keywords: +patch
pull_requests: +29596
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31466

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46816>
_______________________________________

From report at bugs.python.org  Mon Feb 21 06:26:02 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 21 Feb 2022 11:26:02 +0000
Subject: [issue46796] Simplify handling of removed parameter "loop" in asyncio
In-Reply-To: <1645257365.33.0.518204757476.issue46796@roundup.psfhosted.org>
Message-ID: <1645442762.45.0.94766871729.issue46796@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset 195a46d6ffd4cec6c5fb69c5890f8b1758ac91ca by Serhiy Storchaka in branch 'main':
bpo-46796: Simplify handling of removed parameter "loop" in asyncio (GH-31431)
https://github.com/python/cpython/commit/195a46d6ffd4cec6c5fb69c5890f8b1758ac91ca


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46796>
_______________________________________

From report at bugs.python.org  Mon Feb 21 06:26:34 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 21 Feb 2022 11:26:34 +0000
Subject: [issue46796] Simplify handling of removed parameter "loop" in asyncio
In-Reply-To: <1645257365.33.0.518204757476.issue46796@roundup.psfhosted.org>
Message-ID: <1645442794.67.0.709973778271.issue46796@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/issue46796>
_______________________________________

From report at bugs.python.org  Mon Feb 21 06:42:45 2022
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 21 Feb 2022 11:42:45 +0000
Subject: [issue46733] pathlib.Path methods can raise NotImplementedError
In-Reply-To: <1644694513.05.0.985214969865.issue46733@roundup.psfhosted.org>
Message-ID: <1645443765.4.0.715292042354.issue46733@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> pathlib does not allow to distinguish "path" from "path/".

os.path.normpath() and os.path.abspath() don't retain a trailing slash -- or a leading dot component for that matter. Are you referring to os.path.join()? For example:

    >>> os.path.join('./spam', 'eggs/')
    './spam/eggs/'
    >>> os.path.normpath('./spam/eggs/')
    'spam/eggs'
    >>> PurePath('./spam') / PurePath('eggs/')
    PurePosixPath('spam/eggs')

A leading dot component is significant in a context that searches a set of paths -- usually PATH. A trailing slash is significant in a context that has to distinguish a device or file path from a directory path, of which there are several cases in Windows.

I think it's a deficiency in pathlib that it lacks a way to require conservative normalization in these cases. Path and PurePath objects could gain a keyword-only parameter, and internal attribute if needed, that enables a more conservative normalization.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46733>
_______________________________________

From report at bugs.python.org  Mon Feb 21 06:45:54 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Feb 2022 11:45:54 +0000
Subject: [issue33601] [doc] Py_UTF8Mode is not documented
In-Reply-To: <1526996981.47.0.682650639539.issue33601@psf.upfronthosting.co.za>
Message-ID: <1645443954.22.0.80816919737.issue33601@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> [Entry level contributor seeking guidance]The PR on this issue looks closed. I worked on this and attaching the updated html file.

Hi. You should update Doc/c-api/init.rst. Not the generated HTML page.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33601>
_______________________________________

From report at bugs.python.org  Mon Feb 21 06:46:17 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Feb 2022 11:46:17 +0000
Subject: [issue34990] year 2038 problem in compileall.py
In-Reply-To: <1539602536.3.0.788709270274.issue34990@psf.upfronthosting.co.za>
Message-ID: <1645443977.67.0.893444003561.issue34990@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34990>
_______________________________________

From report at bugs.python.org  Mon Feb 21 06:46:32 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Feb 2022 11:46:32 +0000
Subject: [issue43974] Define Py_BUILD_CORE_MODULE in extensions instead of
 setup.py and Modules/Setup
In-Reply-To: <1619686946.42.0.670507836309.issue43974@roundup.psfhosted.org>
Message-ID: <1645443992.07.0.298369722942.issue43974@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43974>
_______________________________________

From report at bugs.python.org  Mon Feb 21 06:49:24 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Feb 2022 11:49:24 +0000
Subject: [issue46716] regrtest didn't respect the timeout when running
 test_subprocess on AMD64 Windows11 3.x
In-Reply-To: <1644534557.28.0.000333882929265.issue46716@roundup.psfhosted.org>
Message-ID: <1645444164.14.0.358891885771.issue46716@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> It does seem that only the Windows Popen._wait() cannot handle negative timeout values, so the fix should be as simple as coercing the timeout values to >= 0.

Oh. This function should maybe raise an exception if the timeout is negative, and ther caller must replace negative timeout with zero.

> A judicious use of prints in subprocess.py, reveals that the timeout passed to wait() ends up being negative.  That value, once cast to a DWORD, ultimately causes a very long wait (0xfffffff2, in my testing).

This sounds dangerous and must be fixed. Python must not convert negative values to very large positive values.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46716>
_______________________________________

From report at bugs.python.org  Mon Feb 21 06:50:18 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Feb 2022 11:50:18 +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: <1645444218.41.0.985671801494.issue42752@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42752>
_______________________________________

From report at bugs.python.org  Mon Feb 21 07:34:07 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Feb 2022 12:34:07 +0000
Subject: [issue46789] Restore caching of externals on Windows buildbots
In-Reply-To: <1645203625.57.0.7602685108.issue46789@roundup.psfhosted.org>
Message-ID: <1645446847.86.0.703455640244.issue46789@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Would it be possible to create a download cache somewhere outside the Python source tree, so "git clean -fdx" would not remove this cache?

Some CIs implement such cache. Does buildbot have helpers for that?

buildbot provides for example:

* LRUCache: https://docs.buildbot.net/2.4.0/full.html#module-buildbot.util.lru
* State: https://docs.buildbot.net/2.4.0/full.html#keeping-state
* Server cache: https://docs.buildbot.net/2.4.0/full.html#caches

In this case, one option would be to enhance PCbuild/get_external.py to add support for a cache directory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46789>
_______________________________________

From report at bugs.python.org  Mon Feb 21 07:59:12 2022
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 21 Feb 2022 12:59:12 +0000
Subject: [issue46817] Add a line-start table to the code object.
Message-ID: <1645448352.85.0.240103559175.issue46817@roundup.psfhosted.org>


New submission from Mark Shannon <mark at hotpy.org>:

Computing whether an instruction is the first on a line (for tracing) in the interpreter is complicated and slow. Doing it in the compiler should be simpler and has no runtime cost.

Currently we decide if the current instruction is the first on a line, by using the `co_lines` table, but if the previous instruction executed was a jump from the same line over a block of instructions with different line number(s) then we can get this wrong.

This doesn't seem to a problem now, but could be with either: 
Specialization of FOR_ITER inlining generators, or
Compiler improvements leading to different code layout.


The table is only one bit per instruction, so shouldn't be a problem in terms of space.

----------
components: Interpreter Core
messages: 413651
nosy: Mark.Shannon, iritkatriel
priority: normal
severity: normal
status: open
title: Add a line-start table to the code object.
type: behavior
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46817>
_______________________________________

From report at bugs.python.org  Mon Feb 21 08:03:49 2022
From: report at bugs.python.org (Kristiyan)
Date: Mon, 21 Feb 2022 13:03:49 +0000
Subject: [issue46818] Proper way to inherit from collections.abc.Coroutine
Message-ID: <1645448629.24.0.443450493338.issue46818@roundup.psfhosted.org>


New submission from Kristiyan <skrechy at gmail.com>:

Hello,

Last several days I'm trying to implement an async "opener" object that can be used as Coroutine as well as an AsyncContextManager (eg. work with `await obj.open()` and `async with obj.open()`). I've researched several implementations from various python packages such as:
1. aiofiles: https://github.com/Tinche/aiofiles/blob/master/src/aiofiles/base.py#L28
2. aiohttp: https://github.com/aio-libs/aiohttp/blob/master/aiohttp/client.py#L1082

Unlike these libs though, I want my implementation to return a custom object that is a wrapper around the object returned from the underlying module I'm hiding. 

Example:
I want to implement a DataFeeder interface that has a single method `open()`. Sub-classes of this interface will support, for example, opening an file using aiofiles package. So,
AsyncFileDataFeeder.open() will call `aiofiles.open()`, but instead of returning "file-handle" from aiofiles, I want to return a custom Feed class that implements some more methods for reading -- for example:

async with async_data_feeder.open() as feed:
  async for chunk in feed.iter_chunked():
    ...

To support that I'm returning an instance of the following class from DataFeeder.open():

class ContextOpener(
    Coroutine[Any, Any, Feed],
    AbstractAsyncContextManager[Feed],
):
    __slots__ = ("_wrapped_coro", "_feed_cls", "_feed")

    def __init__(self, opener_coro: Coroutine, feed_cls: Type[Feed]):
        self._wrapped_coro = opener_coro
        self._feed_cls = feed_cls

        self._feed: Any = None

    def __await__(self) -> Generator[Any, Any, Feed]:
        print("in await", locals())
        handle = yield from self._wrapped_coro.__await__()
        return self._feed_cls(handle)

    def send(self, value: Any) -> Any:
        print("in send", locals())
        return self._wrapped_coro.send(value)

    def throw(self, *args, **kwargs) -> Any:
        print("in throw", locals())
        return self._wrapped_coro.throw(*args, **kwargs)

    def close(self) -> None:
        print("in close", locals())
        self._wrapped_coro.close()

    async def __aenter__(self) -> feeds.Feed:
        handle = await self._wrapped_coro
        self._feed = self._feed_cls(handle)
        return self._feed

    async def __aexit__(
        self,
        exc_type: Optional[Type[BaseException]],
        exc: Optional[BaseException],
        tb: Optional[TracebackType],
    ) -> None:
        await self._feed.close()
        self._feed = None


This code actually works! But I've noticed that when calling `await DataFeeder.open()` the event loop never calls my `send()` method.

if __name__ == "__main__":
    async def open_test():
        await asyncio.sleep(1)
        return 1

    async def main():
        c = ContextOpener(open_test(), feeds.AsyncFileFeed)
        ret = await c
        print("Finish:", ret, ret._handle)

The output:
in await {'self': <__main__.ContextOpener object at 0x11099cd10>}
Finish: <feeds.AsyncFileFeed object at 0x1109a9a80> 1

>From then on a great thinking and reading on the Internet happened, trying to explain to myself how exactly coroutines are working. I suspect that the ContextOpener.__await__ is returning a generator instance and from then on, outer coroutines (eg. main in this case) are calling send()/throw()/close() on THAT generator, not on the ContextOpener "coroutine".
The only way to make Python call ContextOpener send() method (and friends) is when ContextOpener is the outermost coroutine that is communicating directly with the event loop:

ret = asyncio.run(ContextOpener(open_test(), feeds.AsyncFileFeed))
print("Finish:", ret)

Output:
in send {'self': <__main__.ContextOpener object at 0x10dcf47c0>, 'value': None}
in send {'self': <__main__.ContextOpener object at 0x10dcf47c0>, 'value': None}
Finish: 1

However, now I see that I have an error in my implementation that was hidden before: my send() method implementation is not complete because StopIteration case is not handled and returns 1, instead of Feed object.

Since __await__() should return iterator (by PEP492) I can't figure out a way to implement what I want unless making my coroutine class an iterator itself (actually generator) by returning `self` from __await__ and add __iter__ and __next__ methods:

    def __await__(self):
        return self

    def __iter__(self):
        return self

    def __next__(self):
        return self.send(None)

Is this the proper way to make a Coroutine out of a collections.abc.Coroutine? Why is then the documentation not explicitly saying that a Coroutine should inherit from collections.abc.Generator?

I see this as very common misconception since every such "ContextManager" similar to ContextOpener from 3rd party packages (like the aforementioned two, aiofiles and aiohttp, but there are others as well) is subclassing collections.abc.Coroutine and implements send(), throw() and close() methods that are not actually being called. I suspect, the authors of these libraries haven't noticed that because the returned value from the __await__() and send() methods is the same in their case.

----------
components: asyncio
messages: 413652
nosy: asvetlov, skrech, yselivanov
priority: normal
severity: normal
status: open
title: Proper way to inherit from collections.abc.Coroutine
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46818>
_______________________________________

From report at bugs.python.org  Mon Feb 21 09:06:13 2022
From: report at bugs.python.org (Ting-Che Lin)
Date: Mon, 21 Feb 2022 14:06:13 +0000
Subject: [issue46799] ShareableList memory bloat and performance improvement
In-Reply-To: <1645272150.7.0.530571625794.issue46799@roundup.psfhosted.org>
Message-ID: <1645452373.41.0.607562912848.issue46799@roundup.psfhosted.org>


Change by Ting-Che Lin <lintingche2012 at gmail.com>:


----------
keywords: +patch
pull_requests: +29597
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31467

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46799>
_______________________________________

From report at bugs.python.org  Mon Feb 21 09:11:35 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 21 Feb 2022 14:11:35 +0000
Subject: [issue46541] Replace _Py_IDENTIFIER() with statically initialized
 objects.
In-Reply-To: <1643234464.46.0.949364478641.issue46541@roundup.psfhosted.org>
Message-ID: <1645452695.41.0.73284232178.issue46541@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
pull_requests: +29598
pull_request: https://github.com/python/cpython/pull/31468

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46541>
_______________________________________

From report at bugs.python.org  Mon Feb 21 09:47:07 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 21 Feb 2022 14:47:07 +0000
Subject: [issue46541] Replace _Py_IDENTIFIER() with statically initialized
 objects.
In-Reply-To: <1643234464.46.0.949364478641.issue46541@roundup.psfhosted.org>
Message-ID: <1645454827.4.0.277780212449.issue46541@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:


New changeset 2b86616456629e11de33629da1bb732f033c436e by Dong-hee Na in branch 'main':
bpo-46541: Remove usage of _Py_IDENTIFIER from pyexpat (GH-31468)
https://github.com/python/cpython/commit/2b86616456629e11de33629da1bb732f033c436e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46541>
_______________________________________

From report at bugs.python.org  Mon Feb 21 09:48:49 2022
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 21 Feb 2022 14:48:49 +0000
Subject: [issue46811] Test suite needs adjustments for Expat >=2.4.5
In-Reply-To: <1645386845.86.0.727249777809.issue46811@roundup.psfhosted.org>
Message-ID: <1645454929.07.0.58616726145.issue46811@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:


New changeset 2cae93832f46b245847bdc252456ddf7742ef45e by Sebastian Pipping in branch 'main':
bpo-46811: Make test suite support Expat >=2.4.5 (GH-31453)
https://github.com/python/cpython/commit/2cae93832f46b245847bdc252456ddf7742ef45e


----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46811>
_______________________________________

From report at bugs.python.org  Mon Feb 21 09:48:54 2022
From: report at bugs.python.org (miss-islington)
Date: Mon, 21 Feb 2022 14:48:54 +0000
Subject: [issue46811] Test suite needs adjustments for Expat >=2.4.5
In-Reply-To: <1645386845.86.0.727249777809.issue46811@roundup.psfhosted.org>
Message-ID: <1645454934.43.0.087003618491.issue46811@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: +29599
pull_request: https://github.com/python/cpython/pull/31469

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46811>
_______________________________________

From report at bugs.python.org  Mon Feb 21 09:49:06 2022
From: report at bugs.python.org (miss-islington)
Date: Mon, 21 Feb 2022 14:49:06 +0000
Subject: [issue46811] Test suite needs adjustments for Expat >=2.4.5
In-Reply-To: <1645386845.86.0.727249777809.issue46811@roundup.psfhosted.org>
Message-ID: <1645454946.61.0.977524162016.issue46811@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29601
pull_request: https://github.com/python/cpython/pull/31471

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46811>
_______________________________________

From report at bugs.python.org  Mon Feb 21 09:49:00 2022
From: report at bugs.python.org (miss-islington)
Date: Mon, 21 Feb 2022 14:49:00 +0000
Subject: [issue46811] Test suite needs adjustments for Expat >=2.4.5
In-Reply-To: <1645386845.86.0.727249777809.issue46811@roundup.psfhosted.org>
Message-ID: <1645454940.71.0.618152548712.issue46811@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29600
pull_request: https://github.com/python/cpython/pull/31470

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46811>
_______________________________________

From report at bugs.python.org  Mon Feb 21 10:00:07 2022
From: report at bugs.python.org (Jeremy Kloth)
Date: Mon, 21 Feb 2022 15:00:07 +0000
Subject: [issue46789] Restore caching of externals on Windows buildbots
In-Reply-To: <1645446847.86.0.703455640244.issue46789@roundup.psfhosted.org>
Message-ID: <CAGvrs3+MRqo4twKNYww9UFUshtVEEcVepvsKB71wymVgSjbPJA@mail.gmail.com>


Jeremy Kloth <jeremy.kloth at gmail.com> added the comment:

> Would it be possible to create a download cache somewhere outside the Python source tree, so "git clean -fdx" would not remove this cache?

I was thinking of locating it next to the checkout directory.  The
current structure is:

[worker root]
-- [builder root]
---- [checkout]

I propose to add the externals directory within the builder root, so
each branch would still have a unique copy.

----------
nosy: +jeremy.kloth

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46789>
_______________________________________

From report at bugs.python.org  Mon Feb 21 10:02:42 2022
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 21 Feb 2022 15:02:42 +0000
Subject: [issue46400] Please update bundled libexpat to 2.4.4 with security
 fixes (CVE-2021-45960)
In-Reply-To: <1642350760.98.0.31451148779.issue46400@roundup.psfhosted.org>
Message-ID: <1645455762.4.0.535320776973.issue46400@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:


New changeset c60414de7cefd092643ba200c2c045da1569c391 by Dong-hee Na in branch '3.8':
bpo-46400: Update libexpat from 2.4.1 to 2.4.4 (GH-31022) (GH-31297)
https://github.com/python/cpython/commit/c60414de7cefd092643ba200c2c045da1569c391


----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46400>
_______________________________________

From report at bugs.python.org  Mon Feb 21 10:03:38 2022
From: report at bugs.python.org (miss-islington)
Date: Mon, 21 Feb 2022 15:03:38 +0000
Subject: [issue46811] Test suite needs adjustments for Expat >=2.4.5
In-Reply-To: <1645386845.86.0.727249777809.issue46811@roundup.psfhosted.org>
Message-ID: <1645455818.46.0.481880559037.issue46811@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29602
pull_request: https://github.com/python/cpython/pull/31472

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46811>
_______________________________________

From report at bugs.python.org  Mon Feb 21 10:42:55 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 21 Feb 2022 15:42:55 +0000
Subject: [issue45641] Error In opening a file through tkinter on macOS Monterey
In-Reply-To: <1635403092.77.0.425701800447.issue45641@roundup.psfhosted.org>
Message-ID: <1645458175.22.0.664791216191.issue45641@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
nosy: +corona10
nosy_count: 7.0 -> 8.0
pull_requests: +29603
pull_request: https://github.com/python/cpython/pull/31475

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45641>
_______________________________________

From report at bugs.python.org  Mon Feb 21 10:46:15 2022
From: report at bugs.python.org (miss-islington)
Date: Mon, 21 Feb 2022 15:46:15 +0000
Subject: [issue46732] Builtin __bool__ docstrings are wrong
In-Reply-To: <1644693001.93.0.383788579819.issue46732@roundup.psfhosted.org>
Message-ID: <1645458375.38.0.957699324803.issue46732@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: +29604
pull_request: https://github.com/python/cpython/pull/31473

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46732>
_______________________________________

From report at bugs.python.org  Mon Feb 21 10:46:55 2022
From: report at bugs.python.org (miss-islington)
Date: Mon, 21 Feb 2022 15:46:55 +0000
Subject: [issue46732] Builtin __bool__ docstrings are wrong
In-Reply-To: <1644693001.93.0.383788579819.issue46732@roundup.psfhosted.org>
Message-ID: <1645458415.02.0.184394665002.issue46732@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29605
pull_request: https://github.com/python/cpython/pull/31474

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46732>
_______________________________________

From report at bugs.python.org  Mon Feb 21 10:46:56 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 21 Feb 2022 15:46:56 +0000
Subject: [issue46818] Proper way to inherit from collections.abc.Coroutine
In-Reply-To: <1645448629.24.0.443450493338.issue46818@roundup.psfhosted.org>
Message-ID: <1645458416.44.0.841651409553.issue46818@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

You don't need send()/throw()/close() methods.
aiohttp had them to work with Python 3.5

P.S. Please don't use the bug tracker as Q&A site.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46818>
_______________________________________

From report at bugs.python.org  Mon Feb 21 11:16:26 2022
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 21 Feb 2022 16:16:26 +0000
Subject: [issue46811] Test suite needs adjustments for Expat >=2.4.5
In-Reply-To: <1645386845.86.0.727249777809.issue46811@roundup.psfhosted.org>
Message-ID: <1645460186.75.0.139299102958.issue46811@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:


New changeset 7da97f61816f3cadaa6788804b22a2434b40e8c5 by Miss Islington (bot) in branch '3.10':
bpo-46811: Make test suite support Expat >=2.4.5 (GH-31453) (GH-31472)
https://github.com/python/cpython/commit/7da97f61816f3cadaa6788804b22a2434b40e8c5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46811>
_______________________________________

From report at bugs.python.org  Mon Feb 21 11:16:27 2022
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 21 Feb 2022 16:16:27 +0000
Subject: [issue46811] Test suite needs adjustments for Expat >=2.4.5
In-Reply-To: <1645386845.86.0.727249777809.issue46811@roundup.psfhosted.org>
Message-ID: <1645460187.11.0.355904153785.issue46811@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:


New changeset 336a916f75642dfe2d87e237981686051d5d51f8 by Miss Islington (bot) in branch '3.9':
bpo-46811: Make test suite support Expat >=2.4.5 (GH-31453) (GH-31469)
https://github.com/python/cpython/commit/336a916f75642dfe2d87e237981686051d5d51f8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46811>
_______________________________________

From report at bugs.python.org  Mon Feb 21 11:42:51 2022
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 21 Feb 2022 16:42:51 +0000
Subject: [issue46804] spam
Message-ID: <1645461771.95.0.682018718775.issue46804@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
title: Yaytext.net - T?o v?n b?n ch? ki?u, k? t? ??c bi?t ??c ??o -> spam

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46804>
_______________________________________

From report at bugs.python.org  Mon Feb 21 12:18:56 2022
From: report at bugs.python.org (miss-islington)
Date: Mon, 21 Feb 2022 17:18:56 +0000
Subject: [issue46732] Builtin __bool__ docstrings are wrong
In-Reply-To: <1644693001.93.0.383788579819.issue46732@roundup.psfhosted.org>
Message-ID: <1645463936.41.0.418949352791.issue46732@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c596ecbf821843de0e044f0d4da34c6b49a06907 by Miss Islington (bot) in branch '3.10':
[3.10] bpo-46732: fix __bool__ docstring (GH-31301) (GH-31473)
https://github.com/python/cpython/commit/c596ecbf821843de0e044f0d4da34c6b49a06907


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46732>
_______________________________________

From report at bugs.python.org  Mon Feb 21 12:18:59 2022
From: report at bugs.python.org (miss-islington)
Date: Mon, 21 Feb 2022 17:18:59 +0000
Subject: [issue46732] Builtin __bool__ docstrings are wrong
In-Reply-To: <1644693001.93.0.383788579819.issue46732@roundup.psfhosted.org>
Message-ID: <1645463939.01.0.32851972719.issue46732@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 8eb18d842c37c37c1f9316c7e171aad36e875b9a by Miss Islington (bot) in branch '3.9':
[3.9] bpo-46732: fix __bool__ docstring (GH-31301) (GH-31474)
https://github.com/python/cpython/commit/8eb18d842c37c37c1f9316c7e171aad36e875b9a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46732>
_______________________________________

From report at bugs.python.org  Mon Feb 21 12:19:35 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Mon, 21 Feb 2022 17:19:35 +0000
Subject: [issue46732] Builtin __bool__ docstrings are wrong
In-Reply-To: <1644693001.93.0.383788579819.issue46732@roundup.psfhosted.org>
Message-ID: <1645463975.18.0.759403634993.issue46732@roundup.psfhosted.org>


Change by Jelle Zijlstra <jelle.zijlstra at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46732>
_______________________________________

From report at bugs.python.org  Mon Feb 21 12:22:12 2022
From: report at bugs.python.org (Ned Deily)
Date: Mon, 21 Feb 2022 17:22:12 +0000
Subject: [issue45641] Error In opening a file through tkinter on macOS Monterey
In-Reply-To: <1635403092.77.0.425701800447.issue45641@roundup.psfhosted.org>
Message-ID: <1645464132.07.0.0913530310245.issue45641@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
pull_requests:  -29603

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45641>
_______________________________________

From report at bugs.python.org  Mon Feb 21 12:23:06 2022
From: report at bugs.python.org (Kristiyan Kanchev)
Date: Mon, 21 Feb 2022 17:23:06 +0000
Subject: [issue46818] Proper way to inherit from collections.abc.Coroutine
In-Reply-To: <1645448629.24.0.443450493338.issue46818@roundup.psfhosted.org>
Message-ID: <1645464186.16.0.0687451065828.issue46818@roundup.psfhosted.org>


Kristiyan Kanchev <skrechy at tutanota.com> added the comment:

Hello Andrew, 

I'm sorry for using the bug tracker, but I wasn't sure whether posting on StackOverflow (is this the appropriate Q&A site?) will attract the attention of the right people.

Although I see you marked this as Closed, I'll be very pleased if you'd elaborate on why I don't need send/throw/close methods since they are "mandatory" from collections.abc.Coroutine. Are you suggesting that I need to just inherit from Awaitable? 

As a matter of fact, I'm writing in the bug tracker because I think that there is a potential for a change -- maybe just in the documentation. I struggle to find an example on how to implement a Coroutine class, and I believe this will be valuable to others, too. While reading the documentation of collections.abc.Coroutine one have an impression that he/she would have to return an Iterator from __await__() and then outer coroutines will call send/throw/close methods of the derived collections.abc.Coroutine class, but this is not the case. One have to dive deep into Python internals to grasp why Iterator should be returned and how outer coroutines interact with it.

Moreover, there are several cross-referencing PEPs that explain yield, yield from, await but none of them has an example of how to construct a Coroutine from a class. Explanation and examples are always concerned with `yield` and its suspension property is presented as implementation detail.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46818>
_______________________________________

From report at bugs.python.org  Mon Feb 21 12:26:24 2022
From: report at bugs.python.org (Cooper Lees)
Date: Mon, 21 Feb 2022 17:26:24 +0000
Subject: [issue46819] Add an Error / Exception / Warning when
 contextlib.suppress() is entered with no specified exception(s) to suppress
Message-ID: <1645464384.79.0.401778534641.issue46819@roundup.psfhosted.org>


New submission from Cooper Lees <me at cooperlees.com>:

Today if you enter a `contextlib.suppress()` context and specify no exceptions there is no error or warning (I didn't check pywarnings to be fair). Isn't this a useless context then? If not, please explain why and close.

If it is, I'd love to discuss possibly raising a new NoSupressionError or at least a warning to let people know they executing an unneeded context.

Example code that 3.11 does not error on:

```python
cooper at home1:~$ python3.11
Python 3.11.0a5+ (main, Feb 21 2022, 08:52:10) [GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import contextlib
>>> with contextlib.suppress():
...   print("Foo")
...
Foo
```

This was reported to `flake8-bugbear` and if this is not accepted I may accept adding this to the linter. But feel this could be fixable in cpython itself.

----------
components: Library (Lib)
messages: 413663
nosy: cooperlees
priority: normal
severity: normal
status: open
title: Add an Error / Exception / Warning when contextlib.suppress() is entered with no specified exception(s) to suppress
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46819>
_______________________________________

From report at bugs.python.org  Mon Feb 21 12:48:05 2022
From: report at bugs.python.org (Ned Deily)
Date: Mon, 21 Feb 2022 17:48:05 +0000
Subject: [issue45618] Documentation builds fail with Sphinx 3.2.1
In-Reply-To: <1635287699.66.0.0951441516371.issue45618@roundup.psfhosted.org>
Message-ID: <1645465685.2.0.871083299749.issue45618@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
pull_requests: +29606
pull_request: https://github.com/python/cpython/pull/31476

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45618>
_______________________________________

From report at bugs.python.org  Mon Feb 21 12:50:04 2022
From: report at bugs.python.org (Patrick Reader)
Date: Mon, 21 Feb 2022 17:50:04 +0000
Subject: [issue46820] SyntaxError on `1not in...`
Message-ID: <1645465803.96.0.142928933167.issue46820@roundup.psfhosted.org>


New submission from Patrick Reader <pxeger at protonmail.com>:

The following code gives a SyntaxError in 3.10, but used to work fine before (I have tested it in 2.7, 3.8, 3.9):

    1not in [2, 3]

It seems to be only the `not in` syntax which is affected; all other keywords still work correctly:

    1in [2, 3]
    1or 2
    1and 2
    1if 1else 1
    1is 1

I know this syntax is deprecated in 3.10 (bpo43833), but it still needs to work for now, so that old code written like this can keep working.

----------
components: Parser
messages: 413664
nosy: lys.nikolaou, pablogsal, pxeger
priority: normal
severity: normal
status: open
title: SyntaxError on `1not in...`
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46820>
_______________________________________

From report at bugs.python.org  Mon Feb 21 12:52:33 2022
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 21 Feb 2022 17:52:33 +0000
Subject: [issue46820] SyntaxError on `1not in...`
In-Reply-To: <1645465803.96.0.142928933167.issue46820@roundup.psfhosted.org>
Message-ID: <1645465953.99.0.873797307298.issue46820@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46820>
_______________________________________

From report at bugs.python.org  Mon Feb 21 12:58:59 2022
From: report at bugs.python.org (Ned Deily)
Date: Mon, 21 Feb 2022 17:58:59 +0000
Subject: [issue45618] Documentation builds fail with Sphinx 3.2.1
In-Reply-To: <1635287699.66.0.0951441516371.issue45618@roundup.psfhosted.org>
Message-ID: <1645466339.61.0.806966941525.issue45618@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 7a5850987010ca5cb0f1e2844cfe183935916e7e by Ned Deily in branch '3.7':
bpo-45618: Fix documentation build by pinning Docutils version to 0.17.1 (GH-31476)
https://github.com/python/cpython/commit/7a5850987010ca5cb0f1e2844cfe183935916e7e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45618>
_______________________________________

From report at bugs.python.org  Mon Feb 21 13:26:56 2022
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 21 Feb 2022 18:26:56 +0000
Subject: [issue46329] Split up the CALL_NO_KW and CALL_KW instructions.
In-Reply-To: <1641819285.76.0.605357810946.issue46329@roundup.psfhosted.org>
Message-ID: <1645468016.42.0.591858017184.issue46329@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset 59585d6b2ea50d7bc3a9b336da5bde61367f527c by Mark Shannon in branch 'main':
bpo-46329: Streamline calling sequence a bit. (GH-31465)
https://github.com/python/cpython/commit/59585d6b2ea50d7bc3a9b336da5bde61367f527c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46329>
_______________________________________

From report at bugs.python.org  Mon Feb 21 13:32:56 2022
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 21 Feb 2022 18:32:56 +0000
Subject: [issue46819] Add an Error / Exception / Warning when
 contextlib.suppress() is entered with no specified exception(s) to suppress
In-Reply-To: <1645464384.79.0.401778534641.issue46819@roundup.psfhosted.org>
Message-ID: <1645468376.09.0.680955960013.issue46819@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

I'm -1 on this suggestion; consider the following:

```
exceptions_to_suppress = []
if some_condition:
    exceptions_to_suppress.append(ValueError)

with contextlib.suppress(*exceptions_to_suppress):
    do_a_thing()
```

This seems a reasonable case to support and would require quite some gymnastics to continue supporting while also warning on an empty set.

----------
nosy: +ncoghlan, yselivanov, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46819>
_______________________________________

From report at bugs.python.org  Mon Feb 21 14:18:36 2022
From: report at bugs.python.org (Ned Deily)
Date: Mon, 21 Feb 2022 19:18:36 +0000
Subject: [issue46784] Duplicated symbols when linking embedded Python with
 libexpat
In-Reply-To: <1645140945.97.0.0561003008604.issue46784@roundup.psfhosted.org>
Message-ID: <1645471116.1.0.688927650959.issue46784@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 61f3c308e435c5294e674ef59fed1d51f47e0089 by Miss Islington (bot) in branch '3.7':
bpo-46784: Add newly exported expat symbols to the namespace. (GH-31397) (GH-31418)
https://github.com/python/cpython/commit/61f3c308e435c5294e674ef59fed1d51f47e0089


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46784>
_______________________________________

From report at bugs.python.org  Mon Feb 21 13:47:10 2022
From: report at bugs.python.org (Ned Deily)
Date: Mon, 21 Feb 2022 18:47:10 +0000
Subject: [issue46400] Please update bundled libexpat to 2.4.4 with security
 fixes (CVE-2021-45960)
In-Reply-To: <1642350760.98.0.31451148779.issue46400@roundup.psfhosted.org>
Message-ID: <1645469230.92.0.00518905010776.issue46400@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46400>
_______________________________________

From report at bugs.python.org  Mon Feb 21 13:46:10 2022
From: report at bugs.python.org (Ned Deily)
Date: Mon, 21 Feb 2022 18:46:10 +0000
Subject: [issue46400] Please update bundled libexpat to 2.4.4 with security
 fixes (CVE-2021-45960)
In-Reply-To: <1642350760.98.0.31451148779.issue46400@roundup.psfhosted.org>
Message-ID: <1645469170.2.0.608787539017.issue46400@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 5fdacac8cecb123ae12669ceb3504b2f41075c20 by Dong-hee Na in branch '3.7':
bpo-46400: Update libexpat from 2.4.1 to 2.4.4 (GH-31022) (GH-31298)
https://github.com/python/cpython/commit/5fdacac8cecb123ae12669ceb3504b2f41075c20


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46400>
_______________________________________

From report at bugs.python.org  Mon Feb 21 14:38:34 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 21 Feb 2022 19:38:34 +0000
Subject: [issue45641] Error In opening a file through tkinter on macOS Monterey
In-Reply-To: <1635403092.77.0.425701800447.issue45641@roundup.psfhosted.org>
Message-ID: <1645472314.54.0.374954728656.issue45641@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
pull_requests: +29607
pull_request: https://github.com/python/cpython/pull/31475

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45641>
_______________________________________

From report at bugs.python.org  Mon Feb 21 14:58:17 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Mon, 21 Feb 2022 19:58:17 +0000
Subject: [issue46821] Introspection support for typing.overload
Message-ID: <1645473497.26.0.919718721464.issue46821@roundup.psfhosted.org>


New submission from Jelle Zijlstra <jelle.zijlstra at gmail.com>:

Currently, the implementation of @overload (https://github.com/python/cpython/blob/59585d6b2ea50d7bc3a9b336da5bde61367f527c/Lib/typing.py#L2211) simply returns a dummy function and throws away the decorated function. This makes it virtually impossible for type checkers using the runtime function object to find overloads specified at runtime.

In pyanalyze, I worked around this by providing a custom @overload decorator, working something like this:

_overloads: dict[str, list[Callable]] = {}

def _get_key(func: Callable) -> str:
    return f"{func.__module__}.{func.__qualname__}"

def overload(func):
    key = _get_key(func)
    _overloads.setdefault(key, []).append(func)
    return _overload_dummy

def get_overloads_for(func):
    key = _get_key(func)
    return _overloads.get(key, [])

A full implementation will need more error handling.

I'd like to add something like this to typing.py so that other tools can also use this information.

----------
assignee: Jelle Zijlstra
components: Library (Lib)
messages: 413671
nosy: AlexWaygood, Jelle Zijlstra, gvanrossum, kj, sobolevn
priority: normal
severity: normal
status: open
title: Introspection support for typing.overload
type: enhancement
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46821>
_______________________________________

From report at bugs.python.org  Mon Feb 21 14:58:37 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 21 Feb 2022 19:58:37 +0000
Subject: [issue46820] SyntaxError on `1not in...`
In-Reply-To: <1645465803.96.0.142928933167.issue46820@roundup.psfhosted.org>
Message-ID: <1645473517.14.0.970568526943.issue46820@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Good catch. Thank you for your report Patrick.

----------
stage: patch review -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46820>
_______________________________________

From report at bugs.python.org  Mon Feb 21 14:03:16 2022
From: report at bugs.python.org (Ned Deily)
Date: Mon, 21 Feb 2022 19:03:16 +0000
Subject: [issue46811] Test suite needs adjustments for Expat >=2.4.5
In-Reply-To: <1645386845.86.0.727249777809.issue46811@roundup.psfhosted.org>
Message-ID: <1645470196.43.0.706622250644.issue46811@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset d4f5bb912e67299b59b814b89a5afd9a8821a14e by Miss Islington (bot) in branch '3.7':
bpo-46811: Make test suite support Expat >=2.4.5 (GH-31453) (GH-31471)
https://github.com/python/cpython/commit/d4f5bb912e67299b59b814b89a5afd9a8821a14e


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46811>
_______________________________________

From report at bugs.python.org  Mon Feb 21 15:09:18 2022
From: report at bugs.python.org (Vidhya)
Date: Mon, 21 Feb 2022 20:09:18 +0000
Subject: [issue33601] [doc] Py_UTF8Mode is not documented
In-Reply-To: <1526996981.47.0.682650639539.issue33601@psf.upfronthosting.co.za>
Message-ID: <1645474158.62.0.631878558133.issue33601@roundup.psfhosted.org>


Change by Vidhya <vidhya.friend at gmail.com>:


----------
keywords: +patch
pull_requests: +29609
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31480

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33601>
_______________________________________

From report at bugs.python.org  Mon Feb 21 15:15:37 2022
From: report at bugs.python.org (Vidhya)
Date: Mon, 21 Feb 2022 20:15:37 +0000
Subject: [issue33601] [doc] Py_UTF8Mode is not documented
In-Reply-To: <1526996981.47.0.682650639539.issue33601@psf.upfronthosting.co.za>
Message-ID: <1645474537.38.0.38145347526.issue33601@roundup.psfhosted.org>


Vidhya <vidhya.friend at gmail.com> added the comment:

[Entry level contributor seeking guidance]The rst file is updated in this pull request:
 https://github.com/python/cpython/pull/31480

Unable to update GitHub PR in the issue. Getting the following error "Edit Error: GitHub PR already added to issue"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33601>
_______________________________________

From report at bugs.python.org  Mon Feb 21 14:57:25 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 21 Feb 2022 19:57:25 +0000
Subject: [issue46820] SyntaxError on `1not in...`
In-Reply-To: <1645465803.96.0.142928933167.issue46820@roundup.psfhosted.org>
Message-ID: <1645473445.76.0.433225161726.issue46820@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +29608
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31479

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46820>
_______________________________________

From report at bugs.python.org  Mon Feb 21 15:20:02 2022
From: report at bugs.python.org (Alex Waygood)
Date: Mon, 21 Feb 2022 20:20:02 +0000
Subject: [issue46821] Introspection support for typing.overload
In-Reply-To: <1645473497.26.0.919718721464.issue46821@roundup.psfhosted.org>
Message-ID: <1645474802.03.0.99210956765.issue46821@roundup.psfhosted.org>


Alex Waygood <Alex.Waygood at Gmail.com> added the comment:

Discussion of similar ideas in Issue45100

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46821>
_______________________________________

From report at bugs.python.org  Mon Feb 21 15:23:36 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Mon, 21 Feb 2022 20:23:36 +0000
Subject: [issue46821] Introspection support for typing.overload
In-Reply-To: <1645473497.26.0.919718721464.issue46821@roundup.psfhosted.org>
Message-ID: <1645475016.42.0.586984853092.issue46821@roundup.psfhosted.org>


Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:

Thanks! Closing this as a duplicate.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Improve help() by making typing.overload() information accessible at runtime

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46821>
_______________________________________

From report at bugs.python.org  Mon Feb 21 15:27:20 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Mon, 21 Feb 2022 20:27:20 +0000
Subject: [issue45100] Improve help() by making typing.overload() information
 accessible at runtime
In-Reply-To: <1630778608.65.0.813637953031.issue45100@roundup.psfhosted.org>
Message-ID: <1645475240.41.0.518216890478.issue45100@roundup.psfhosted.org>


Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:

I made a similar suggestion in issue46821 (thanks Alex for pointing me to this older issue):

Currently, the implementation of @overload (https://github.com/python/cpython/blob/59585d6b2ea50d7bc3a9b336da5bde61367f527c/Lib/typing.py#L2211) simply returns a dummy function and throws away the decorated function. This makes it virtually impossible for type checkers using the runtime function object to find overloads specified at runtime.

In pyanalyze, I worked around this by providing a custom @overload decorator, working something like this:

_overloads: dict[str, list[Callable]] = {}

def _get_key(func: Callable) -> str:
    return f"{func.__module__}.{func.__qualname__}"

def overload(func):
    key = _get_key(func)
    _overloads.setdefault(key, []).append(func)
    return _overload_dummy

def get_overloads_for(func):
    key = _get_key(func)
    return _overloads.get(key, [])

A full implementation will need more error handling.

I'd like to add something like this to typing.py so that other tools can also use this information.

---

With my suggested solution, help() would need to call typing.get_overloads_for() to get any overloads for the function. Unlike Raymond's suggestion, we would not need to change the function creation machinery.

----------
nosy: +Jelle Zijlstra

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45100>
_______________________________________

From report at bugs.python.org  Mon Feb 21 15:52:59 2022
From: report at bugs.python.org (Ned Deily)
Date: Mon, 21 Feb 2022 20:52:59 +0000
Subject: [issue41028] Move docs.python.org language and version switcher out
 of cpython
In-Reply-To: <1592516133.76.0.0424010515361.issue41028@roundup.psfhosted.org>
Message-ID: <1645476779.32.0.980111010938.issue41028@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41028>
_______________________________________

From report at bugs.python.org  Mon Feb 21 15:53:06 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 21 Feb 2022 20:53:06 +0000
Subject: [issue45100] Improve help() by making typing.overload() information
 accessible at runtime
In-Reply-To: <1645475240.41.0.518216890478.issue45100@roundup.psfhosted.org>
Message-ID: <CAP7+vJ+GzBKFWs-f9uF8ywKn8Va4aQOVdXW3_HGNGCFg9eyM1w@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

Sounds good to me. (I don?t care what happens at runtime but I want to
support the folks who do.)--
--Guido (mobile)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45100>
_______________________________________

From report at bugs.python.org  Mon Feb 21 15:55:10 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 21 Feb 2022 20:55:10 +0000
Subject: [issue46541] Replace _Py_IDENTIFIER() with statically initialized
 objects.
In-Reply-To: <1643234464.46.0.949364478641.issue46541@roundup.psfhosted.org>
Message-ID: <1645476910.4.0.329677990044.issue46541@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
pull_requests: +29611
pull_request: https://github.com/python/cpython/pull/31475

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46541>
_______________________________________

From report at bugs.python.org  Mon Feb 21 15:57:12 2022
From: report at bugs.python.org (Ned Deily)
Date: Mon, 21 Feb 2022 20:57:12 +0000
Subject: [issue46786] embed, source, track,
 wbr HTML elements not considered empty
In-Reply-To: <1645179799.58.0.92424391054.issue46786@roundup.psfhosted.org>
Message-ID: <1645477032.17.0.867333676678.issue46786@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
nosy: +eli.bendersky, scoder

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46786>
_______________________________________

From report at bugs.python.org  Mon Feb 21 15:57:22 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 21 Feb 2022 20:57:22 +0000
Subject: [issue45641] Error In opening a file through tkinter on macOS Monterey
In-Reply-To: <1635403092.77.0.425701800447.issue45641@roundup.psfhosted.org>
Message-ID: <1645477042.52.0.688865047284.issue45641@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests:  -29607

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45641>
_______________________________________

From report at bugs.python.org  Mon Feb 21 15:59:10 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 21 Feb 2022 20:59:10 +0000
Subject: [issue45390] asyncio.Task doesn't propagate CancelledError()
 exception correctly.
In-Reply-To: <1633519842.27.0.396754460358.issue45390@roundup.psfhosted.org>
Message-ID: <1645477150.94.0.0612747547591.issue45390@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset 4140bcb1cd76dec5cf8d398f4d0e86c438c987d0 by Andrew Svetlov in branch 'main':
bpo-45390: Propagate CancelledError's message from cancelled task to its awaiter (GH-31383)
https://github.com/python/cpython/commit/4140bcb1cd76dec5cf8d398f4d0e86c438c987d0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45390>
_______________________________________

From report at bugs.python.org  Mon Feb 21 16:00:00 2022
From: report at bugs.python.org (Steve Dower)
Date: Mon, 21 Feb 2022 21:00:00 +0000
Subject: [issue46789] Restore caching of externals on Windows buildbots
In-Reply-To: <1645446847.86.0.703455640244.issue46789@roundup.psfhosted.org>
Message-ID: <1f3e91a0-b0ca-ac2f-0908-bc60e80c44df@python.org>


Steve Dower <steve.dower at python.org> added the comment:

> one option would be to enhance PCbuild/get_external.py to add support 
for a cache directory.

It should already have this support - set the EXTERNALS_DIR environment 
variable before building. I use this in my own builds.

Though if there are specific platforms worth integrating with, this 
could no doubt be further improved.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46789>
_______________________________________

From report at bugs.python.org  Mon Feb 21 16:06:24 2022
From: report at bugs.python.org (Ned Deily)
Date: Mon, 21 Feb 2022 21:06:24 +0000
Subject: [issue46798] xml.etree.ElementTree: get() doesn't return default
 value, always ATTLIST value
In-Reply-To: <1645270291.57.0.995603390679.issue46798@roundup.psfhosted.org>
Message-ID: <1645477584.03.0.110337276745.issue46798@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
nosy: +eli.bendersky, scoder

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46798>
_______________________________________

From report at bugs.python.org  Mon Feb 21 16:18:39 2022
From: report at bugs.python.org (Cooper Lees)
Date: Mon, 21 Feb 2022 21:18:39 +0000
Subject: [issue46819] Add an Error / Exception / Warning when
 contextlib.suppress() is entered with no specified exception(s) to suppress
In-Reply-To: <1645464384.79.0.401778534641.issue46819@roundup.psfhosted.org>
Message-ID: <1645478319.09.0.915208748763.issue46819@roundup.psfhosted.org>


Cooper Lees <me at cooperlees.com> added the comment:

Totally agree with your example use case. There you have a chance for it being useful under certain conditions. In that example there is a passed argument.  In my example there is no passed argument. Thus, I believe that this will generally always be developer error, again, unless I'm missing something here.

My main suggestion here is to just error/warn when no argument at all is passed to `contextlib.suppress` and this this context is *never* a chance of it being useful. If someone passes None or an empty `Sequence` (or anything non truthy) I propose we stay behaving the same as today.

Please feel free to edit the title if that's not clear enough etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46819>
_______________________________________

From report at bugs.python.org  Mon Feb 21 16:18:45 2022
From: report at bugs.python.org (Ned Deily)
Date: Mon, 21 Feb 2022 21:18:45 +0000
Subject: [issue46232] Client certificates with UniqueIdentifier in the subject
 break ssl.peer_certificate()
In-Reply-To: <1641160999.16.0.149653140984.issue46232@roundup.psfhosted.org>
Message-ID: <1645478325.55.0.15355394914.issue46232@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
Removed message: https://bugs.python.org/msg413642

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46232>
_______________________________________

From report at bugs.python.org  Mon Feb 21 16:37:43 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 21 Feb 2022 21:37:43 +0000
Subject: [issue46814] Documentation for constructin abstract base classes is
 misleading
In-Reply-To: <1645431945.33.0.392126816255.issue46814@roundup.psfhosted.org>
Message-ID: <1645479463.48.0.115064511159.issue46814@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

To me, this looks like a way too extensive edit jsut to emphasize a corner case that rarely arises in practice.   It bends over backwards to force an awkward definition regarding what an ABC really is.

A more minimal edit is to just note that inspect.isabstract() returns true if a class inherits from ABC and has at least one remaining abstractmethod.  

That tells the truth without having to redefine an ABC.  And it matches the spirit of the ABC mechanism.  At no point does ABCMeta ever require that any class in the chain must have ever defined an abstractmethod.  Instead, its only rule is that if there is least one remaining abstractmethod, it will refuse to instantiate.  Roughly:

  if any(getattr(meth, '__isabstractmethod__', False) for meth in meths):
     raise TypeError("Can't instantiate")
  instantiate(cls)

Note, any() defaults to False if there are no inputs and that the actual C code works the same way.  Even if a class never defines any abstractmethods, this test still occurs.  For an empty ABC, it just happens to always succeed in instantiating because there is no work left to be done.

Worldviews aside, I don't think it helpful to users to everywhere rewrite what it means to be an ABC just to make it match the output of inspect.isabstract() which is just short for inspect.has_abstract_methods_remaining().

Guido, any thoughts?

----------
nosy: +gvanrossum, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46814>
_______________________________________

From report at bugs.python.org  Mon Feb 21 16:47:14 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 21 Feb 2022 21:47:14 +0000
Subject: [issue46814] Documentation for constructin abstract base classes is
 misleading
In-Reply-To: <1645431945.33.0.392126816255.issue46814@roundup.psfhosted.org>
Message-ID: <1645480034.6.0.856088614439.issue46814@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

An analogy may help.  Release managers must check the list of release blockers and stop if the list is non-empty.  If no release blockers were ever filed, the release blockers list is empty, but it still exists and its definition hasn't changed.

The test is_blocked(blockers) tells us whether the list is non-empty.  It doesn't redefine what it means to be a blockers list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46814>
_______________________________________

From report at bugs.python.org  Mon Feb 21 17:01:40 2022
From: report at bugs.python.org (Alex Waygood)
Date: Mon, 21 Feb 2022 22:01:40 +0000
Subject: [issue46814] Documentation for constructing abstract base classes is
 misleading
In-Reply-To: <1645431945.33.0.392126816255.issue46814@roundup.psfhosted.org>
Message-ID: <1645480900.56.0.661145647852.issue46814@roundup.psfhosted.org>


Change by Alex Waygood <Alex.Waygood at Gmail.com>:


----------
title: Documentation for constructin abstract base classes is misleading -> Documentation for constructing abstract base classes is misleading

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46814>
_______________________________________

From report at bugs.python.org  Mon Feb 21 17:02:00 2022
From: report at bugs.python.org (Spencer Brown)
Date: Mon, 21 Feb 2022 22:02:00 +0000
Subject: [issue45100] Improve help() by making typing.overload() information
 accessible at runtime
In-Reply-To: <1630778608.65.0.813637953031.issue45100@roundup.psfhosted.org>
Message-ID: <1645480920.02.0.502134853166.issue45100@roundup.psfhosted.org>


Spencer Brown <spencerb21 at live.com> added the comment:

I'm not sure a get_overloads() function potentially called after the fact would fully work - there's the tricky case of nested functions, where the overload list would need to be somehow cleared to ensure every instantiation doesn't endlessly append to the same list. It's probably also desirable to weakref it (or make it an attribute) so they can be decrefed if the function isn't being used.

----------
nosy: +Spencer Brown

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45100>
_______________________________________

From report at bugs.python.org  Mon Feb 21 17:56:22 2022
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 21 Feb 2022 22:56:22 +0000
Subject: [issue46725] Unpacking without parentheses is allowed since 3.9
In-Reply-To: <1644603030.68.0.559962279778.issue46725@roundup.psfhosted.org>
Message-ID: <1645484182.85.0.265806749262.issue46725@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +29612
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31481

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46725>
_______________________________________

From report at bugs.python.org  Mon Feb 21 18:03:43 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Mon, 21 Feb 2022 23:03:43 +0000
Subject: [issue45100] Improve help() by making typing.overload() information
 accessible at runtime
In-Reply-To: <1630778608.65.0.813637953031.issue45100@roundup.psfhosted.org>
Message-ID: <1645484623.67.0.114392288821.issue45100@roundup.psfhosted.org>


Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:

I'm OK with not fully supporting overloads created in nested functions; that's a pretty marginal use case. But it's true that my proposed implementation would create a memory leak if someone does do that. I don't immediately see a way to fix that with weakrefs. Maybe we need to put something in the defining namespace, as Raymond suggested.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45100>
_______________________________________

From report at bugs.python.org  Mon Feb 21 18:35:53 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 21 Feb 2022 23:35:53 +0000
Subject: [issue46814] Documentation for constructing abstract base classes is
 misleading
In-Reply-To: <1645431945.33.0.392126816255.issue46814@roundup.psfhosted.org>
Message-ID: <1645486553.97.0.825080507724.issue46814@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

FWIW, I?m only -0 on this.   It is also perfectly reasonable to say that a class is abstract if and only if there is at least one remaining abstract method.  After 15 years though, I?m inclined to say that the status quo wins.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46814>
_______________________________________

From report at bugs.python.org  Mon Feb 21 19:02:06 2022
From: report at bugs.python.org (Steve Dower)
Date: Tue, 22 Feb 2022 00:02:06 +0000
Subject: [issue46822] test_create_server_ssl_over_ssl attempts to listen on
 0.0.0.0
Message-ID: <1645488125.93.0.760341419573.issue46822@roundup.psfhosted.org>


New submission from Steve Dower <steve.dower at python.org>:

This causes a failure on one of my test machines where the firewall settings forbid it.

However, the test itself seems designed to only listen on localhost. Even tracing all call through socket, I don't see when or where it is attempting to listen on 0.0.0.0, and yet TCP Monitor (and my firewall) claim that it is.

This seems to be fairly recent, though I haven't done a bisect yet. Anyone have any ideas?

----------
components: Tests, Windows, asyncio
messages: 413687
nosy: asvetlov, paul.moore, steve.dower, tim.golden, yselivanov, zach.ware
priority: normal
severity: normal
stage: test needed
status: open
title: test_create_server_ssl_over_ssl attempts to listen on 0.0.0.0
type: behavior
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46822>
_______________________________________

From report at bugs.python.org  Mon Feb 21 20:05:52 2022
From: report at bugs.python.org (Ka-Ping Yee)
Date: Tue, 22 Feb 2022 01:05:52 +0000
Subject: [issue46761] functools.update_wrapper breaks the signature of
 functools.partial objects
In-Reply-To: <1644948374.87.0.765462873315.issue46761@roundup.psfhosted.org>
Message-ID: <1645491952.78.0.921448898233.issue46761@roundup.psfhosted.org>


Ka-Ping Yee <zestyping at gmail.com> added the comment:

Hmm, interesting.  I wasn't involved in writing the `follow_wrapper_chains` feature, so I don't know why it's there.  I wonder if some digging through the revision history of `functools.py` and `inspect.py` would yield insight.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46761>
_______________________________________

From report at bugs.python.org  Mon Feb 21 20:13:13 2022
From: report at bugs.python.org (=?utf-8?q?Tin_Tvrtkovi=C4=87?=)
Date: Tue, 22 Feb 2022 01:13:13 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645492393.9.0.799338626977.issue46771@roundup.psfhosted.org>


Change by Tin Tvrtkovi? <tinchester at gmail.com>:


----------
pull_requests: +29613
pull_request: https://github.com/python/cpython/pull/31483

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Mon Feb 21 21:31:16 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 22 Feb 2022 02:31:16 +0000
Subject: [issue46794] Please update bundled libexpat to 2.4.6 with security
 fixes (5 CVEs)
In-Reply-To: <1645227388.68.0.727345462152.issue46794@roundup.psfhosted.org>
Message-ID: <1645497076.62.0.663305137265.issue46794@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
assignee:  -> corona10
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46794>
_______________________________________

From report at bugs.python.org  Mon Feb 21 21:59:35 2022
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 22 Feb 2022 02:59:35 +0000
Subject: [issue46606] Large C stack usage of os.getgroups() and os.setgroups()
In-Reply-To: <1643771204.31.0.0513908090604.issue46606@roundup.psfhosted.org>
Message-ID: <1645498775.84.0.820745074108.issue46606@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset 74127b89a8224d021fc76f679422b76510844ff9 by Inada Naoki in branch 'main':
bpo-46606: Reduce stack usage of getgroups and setgroups (GH-31073)
https://github.com/python/cpython/commit/74127b89a8224d021fc76f679422b76510844ff9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46606>
_______________________________________

From report at bugs.python.org  Mon Feb 21 21:59:43 2022
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 22 Feb 2022 02:59:43 +0000
Subject: [issue46606] Large C stack usage of os.getgroups() and os.setgroups()
In-Reply-To: <1643771204.31.0.0513908090604.issue46606@roundup.psfhosted.org>
Message-ID: <1645498783.25.0.72274570608.issue46606@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46606>
_______________________________________

From report at bugs.python.org  Mon Feb 21 22:08:52 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 22 Feb 2022 03:08:52 +0000
Subject: [issue46794] Please update bundled libexpat to 2.4.6 with security
 fixes (5 CVEs)
In-Reply-To: <1645227388.68.0.727345462152.issue46794@roundup.psfhosted.org>
Message-ID: <1645499332.79.0.0227796115257.issue46794@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
keywords: +patch
pull_requests: +29614
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31486

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46794>
_______________________________________

From report at bugs.python.org  Mon Feb 21 22:09:25 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 22 Feb 2022 03:09:25 +0000
Subject: [issue46794] Please update bundled libexpat to 2.4.6 with security
 fixes (5 CVEs)
In-Reply-To: <1645227388.68.0.727345462152.issue46794@roundup.psfhosted.org>
Message-ID: <1645499365.28.0.28909963861.issue46794@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
pull_requests:  -29614

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46794>
_______________________________________

From report at bugs.python.org  Mon Feb 21 22:15:59 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 22 Feb 2022 03:15:59 +0000
Subject: [issue46794] Please update bundled libexpat to 2.4.6 with security
 fixes (5 CVEs)
In-Reply-To: <1645227388.68.0.727345462152.issue46794@roundup.psfhosted.org>
Message-ID: <1645499759.7.0.541145515488.issue46794@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
pull_requests: +29615
pull_request: https://github.com/python/cpython/pull/31487

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46794>
_______________________________________

From report at bugs.python.org  Mon Feb 21 22:16:00 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 22 Feb 2022 03:16:00 +0000
Subject: [issue46794] Please update bundled libexpat to 2.4.6 with security
 fixes (5 CVEs)
In-Reply-To: <1645227388.68.0.727345462152.issue46794@roundup.psfhosted.org>
Message-ID: <1645499760.04.0.469453711025.issue46794@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
pull_requests: +29615, 29616
pull_request: https://github.com/python/cpython/pull/31487

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46794>
_______________________________________

From report at bugs.python.org  Mon Feb 21 22:50:24 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 22 Feb 2022 03:50:24 +0000
Subject: [issue46757] dataclasses should define an empty __post_init__
In-Reply-To: <1644923607.6.0.495534870715.issue46757@roundup.psfhosted.org>
Message-ID: <1645501824.42.0.0538275311151.issue46757@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Note that adding an empty __post_init__ method would be a breaking change.  The following prints out 'B' then 'C'.  But if class A adds an empty __post_init__, then 'B' never gets printed.  The arrangement relies on class A being a passthrough to class B.

    from dataclasses import dataclass

    @dataclass
    class A:
        pass

    @dataclass
    class B:
        def __post_init__(self):
            print('B')

    @dataclass
    class C(A, B):
        def __post_init__(self):
            super().__post_init__()
            print('C')

    c = C()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46757>
_______________________________________

From report at bugs.python.org  Mon Feb 21 23:32:24 2022
From: report at bugs.python.org (Neil Girdhar)
Date: Tue, 22 Feb 2022 04:32:24 +0000
Subject: [issue46757] dataclasses should define an empty __post_init__
In-Reply-To: <1644923607.6.0.495534870715.issue46757@roundup.psfhosted.org>
Message-ID: <1645504344.12.0.589170633605.issue46757@roundup.psfhosted.org>


Neil Girdhar <mistersheik at gmail.com> added the comment:

@Raymond yeah I've been thinking about this some more, and there's no way to have a "top level" method with the dataclass decorator.

I think I will make a case to have a class version of dataclasses that works with inheritance.  Class versions of dataclasses are used in some places like here: https://github.com/google/flax/blob/main/flax/struct.py#L184
They just call dataclass on the class in __init_subclass__.

If we had something like this in the standard library, then you could put your empty __post_init__ in that class.  You could also make __init__ call super so that mixins would be initialized (right now the collider pattern you showed also breaks if B is not a dataclass, and has a non-trivial __init__).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46757>
_______________________________________

From report at bugs.python.org  Tue Feb 22 00:11:54 2022
From: report at bugs.python.org (Dennis Sweeney)
Date: Tue, 22 Feb 2022 05:11:54 +0000
Subject: [issue46823] Add LOAD_FAST__LOAD_ATTR_INSTACE_VALUE combined opcode
Message-ID: <1645506714.72.0.112858305238.issue46823@roundup.psfhosted.org>


New submission from Dennis Sweeney <sweeney.dennis650 at gmail.com>:

See https://github.com/faster-cpython/ideas/discussions/291

----------
messages: 413692
nosy: Dennis Sweeney
priority: normal
severity: normal
status: open
title: Add LOAD_FAST__LOAD_ATTR_INSTACE_VALUE combined opcode

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46823>
_______________________________________

From report at bugs.python.org  Tue Feb 22 00:12:21 2022
From: report at bugs.python.org (Dennis Sweeney)
Date: Tue, 22 Feb 2022 05:12:21 +0000
Subject: [issue46823] Add LOAD_FAST__LOAD_ATTR_INSTACE_VALUE combined opcode
In-Reply-To: <1645506714.72.0.112858305238.issue46823@roundup.psfhosted.org>
Message-ID: <1645506741.92.0.236952585583.issue46823@roundup.psfhosted.org>


Change by Dennis Sweeney <sweeney.dennis650 at gmail.com>:


----------
keywords: +patch
pull_requests: +29617
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31484

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46823>
_______________________________________

From report at bugs.python.org  Tue Feb 22 00:13:22 2022
From: report at bugs.python.org (Eddie Elizondo)
Date: Tue, 22 Feb 2022 05:13:22 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting and
 immortal objects
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1645506802.38.0.272493467152.issue40255@roundup.psfhosted.org>


Change by Eddie Elizondo <eduardo.elizondorueda at gmail.com>:


----------
pull_requests: +29618
pull_request: https://github.com/python/cpython/pull/31488

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Tue Feb 22 00:24:28 2022
From: report at bugs.python.org (Eddie Elizondo)
Date: Tue, 22 Feb 2022 05:24:28 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting and
 immortal objects
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1645507468.2.0.407829127867.issue40255@roundup.psfhosted.org>


Change by Eddie Elizondo <eduardo.elizondorueda at gmail.com>:


----------
pull_requests: +29619
pull_request: https://github.com/python/cpython/pull/31489

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Tue Feb 22 00:28:25 2022
From: report at bugs.python.org (Eddie Elizondo)
Date: Tue, 22 Feb 2022 05:28:25 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting and
 immortal objects
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1645507705.6.0.191294668336.issue40255@roundup.psfhosted.org>


Change by Eddie Elizondo <eduardo.elizondorueda at gmail.com>:


----------
pull_requests: +29620
pull_request: https://github.com/python/cpython/pull/31490

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Tue Feb 22 00:36:34 2022
From: report at bugs.python.org (Eddie Elizondo)
Date: Tue, 22 Feb 2022 05:36:34 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting and
 immortal objects
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1645508194.61.0.718455243355.issue40255@roundup.psfhosted.org>


Change by Eddie Elizondo <eduardo.elizondorueda at gmail.com>:


----------
pull_requests: +29621
pull_request: https://github.com/python/cpython/pull/31491

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Tue Feb 22 00:42:28 2022
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 22 Feb 2022 05:42:28 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting and
 immortal objects
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1645508548.5.0.300483755285.issue40255@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

All of these optimizations should be disabled by default.

* It will cause leak when Python is embedded.
* Even for python command, it will break __del__ and weakref callbacks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Tue Feb 22 00:59:39 2022
From: report at bugs.python.org (Eddie Elizondo)
Date: Tue, 22 Feb 2022 05:59:39 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting and
 immortal objects
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1645509579.66.0.655094811958.issue40255@roundup.psfhosted.org>


Eddie Elizondo <eduardo.elizondorueda at gmail.com> added the comment:

It seems that we are back on track with perf being back to neutral!

I've created 4 new PRs. Each with an optimization applied on top of the baseline introduction of instance immortalization.

The main PR 19474 currently stands at around 4%, after rebasing past Eric's PR 30928 it went down to 3%.

This is the list of optimizations that I used to get some performance back:
* Immortalizing Interned Strings (PR 31488): 1% regression
* Immortalizing Runtime Heap After Startup (PR 31489): 0% regression
* Immortalizing Modules After Import (PR 31490): 1% regression
* Combined Optimizations (PR 31491): 0% improvement

All the PRs contain the results of the pyperformance benchmarks and they should each stand on their own in case we want to go for a subset of these optimizations rather than all of them. Make sure to look at each PR to read the implementation details.

For testing, in every PR I made sure all the tests were passing on my local environment. Though I do expect some failures happening in non-linux environments. I'll be fixing these over the next couple of days.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Tue Feb 22 01:51:20 2022
From: report at bugs.python.org (Spencer Brown)
Date: Tue, 22 Feb 2022 06:51:20 +0000
Subject: [issue45100] Improve help() by making typing.overload() information
 accessible at runtime
In-Reply-To: <1630778608.65.0.813637953031.issue45100@roundup.psfhosted.org>
Message-ID: <1645512680.87.0.61171562289.issue45100@roundup.psfhosted.org>


Spencer Brown <spencerb21 at live.com> added the comment:

Had a potential thought. Since the only situation we care about is overload being used on function definitions in lexical order, valid calls are only that on definitions with ascending co_firstlineno counts. Expanding on Jelle's solution, the overload() decorator could compare the current function's line number to the first in the list, and if it's <= clear out the list (we're re-defining). Then repeated re-definitions wouldn't duplicate overloads. 

The other change I'd suggest is to make get_overloads_for() first check __overloads__, then only if not present pop from the _overloads dict and assign to that attribute. That way if code calls get_overloads_for() at least once, the function will be referring to the actual overloads created at the same time. It'd also get garbage collected then when the function dies. It also means you could manually assign to add overloads to any callable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45100>
_______________________________________

From report at bugs.python.org  Tue Feb 22 02:31:19 2022
From: report at bugs.python.org (Safihre)
Date: Tue, 22 Feb 2022 07:31:19 +0000
Subject: [issue37355] SSLSocket.read does a GIL round-trip for every 16KB TLS
 record
In-Reply-To: <1561056169.29.0.814417679233.issue37355@roundup.psfhosted.org>
Message-ID: <1645515079.72.0.0343550281317.issue37355@roundup.psfhosted.org>


Change by Safihre <safihre at sabnzbd.org>:


----------
pull_requests: +29622
pull_request: https://github.com/python/cpython/pull/31492

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37355>
_______________________________________

From report at bugs.python.org  Tue Feb 22 02:52:01 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 22 Feb 2022 07:52:01 +0000
Subject: [issue46820] SyntaxError on `1not in...`
In-Reply-To: <1645465803.96.0.142928933167.issue46820@roundup.psfhosted.org>
Message-ID: <1645516321.09.0.890035931046.issue46820@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 090e5c4b946b28f50fce445916c5d3ec45c8f45f by Serhiy Storchaka in branch 'main':
bpo-46820: Fix a SyntaxError in a numeric literal followed by "not in" (GH-31479)
https://github.com/python/cpython/commit/090e5c4b946b28f50fce445916c5d3ec45c8f45f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46820>
_______________________________________

From report at bugs.python.org  Tue Feb 22 02:52:09 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 22 Feb 2022 07:52:09 +0000
Subject: [issue46820] SyntaxError on `1not in...`
In-Reply-To: <1645465803.96.0.142928933167.issue46820@roundup.psfhosted.org>
Message-ID: <1645516329.33.0.671036636325.issue46820@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: +29623
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31493

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46820>
_______________________________________

From report at bugs.python.org  Tue Feb 22 03:05:32 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 22 Feb 2022 08:05:32 +0000
Subject: [issue46820] SyntaxError on `1not in...`
In-Reply-To: <1645465803.96.0.142928933167.issue46820@roundup.psfhosted.org>
Message-ID: <1645517132.27.0.134068533897.issue46820@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +29624
pull_request: https://github.com/python/cpython/pull/31494

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46820>
_______________________________________

From report at bugs.python.org  Tue Feb 22 03:55:05 2022
From: report at bugs.python.org (Tzu-ping Chung)
Date: Tue, 22 Feb 2022 08:55:05 +0000
Subject: [issue46622] Support decorating a coroutine with
 functools.cached_property
In-Reply-To: <1643873308.65.0.92890586202.issue46622@roundup.psfhosted.org>
Message-ID: <1645520105.6.0.923333182951.issue46622@roundup.psfhosted.org>


Change by Tzu-ping Chung <uranusjr at gmail.com>:


----------
pull_requests: +29625
pull_request: https://github.com/python/cpython/pull/31495

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46622>
_______________________________________

From report at bugs.python.org  Tue Feb 22 04:46:40 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 22 Feb 2022 09:46:40 +0000
Subject: [issue45390] asyncio.Task doesn't propagate CancelledError()
 exception correctly.
In-Reply-To: <1633519842.27.0.396754460358.issue45390@roundup.psfhosted.org>
Message-ID: <1645523200.92.0.609138967419.issue45390@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/issue45390>
_______________________________________

From report at bugs.python.org  Tue Feb 22 05:00:54 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 22 Feb 2022 10:00:54 +0000
Subject: [issue46820] SyntaxError on `1not in...`
In-Reply-To: <1645465803.96.0.142928933167.issue46820@roundup.psfhosted.org>
Message-ID: <1645524054.91.0.987328112637.issue46820@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset f20ac2ed076df63a77f65ff2660148af9f1a9b3c by Miss Islington (bot) in branch '3.10':
bpo-46820: Fix a SyntaxError in a numeric literal followed by "not in" (GH-31479) (GH-31493)
https://github.com/python/cpython/commit/f20ac2ed076df63a77f65ff2660148af9f1a9b3c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46820>
_______________________________________

From report at bugs.python.org  Tue Feb 22 05:10:41 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 22 Feb 2022 10:10:41 +0000
Subject: [issue46725] Unpacking without parentheses is allowed since 3.9
In-Reply-To: <1644603030.68.0.559962279778.issue46725@roundup.psfhosted.org>
Message-ID: <1645524641.8.0.961414894396.issue46725@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

What exactly was happened? What rule was changed? Can it cause other changes which allow ambiguous code or change semantic?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46725>
_______________________________________

From report at bugs.python.org  Tue Feb 22 05:15:29 2022
From: report at bugs.python.org (Thomas Grainger)
Date: Tue, 22 Feb 2022 10:15:29 +0000
Subject: [issue46824] use AI_NUMERICHOST | AI_NUMERICSERV to skip getaddrinfo
 thread in asyncio
Message-ID: <1645524928.96.0.755041008121.issue46824@roundup.psfhosted.org>


New submission from Thomas Grainger <tagrain at gmail.com>:

now that the getaddrinfo lock has been removed on all platforms the numeric only host resolve in asyncio could be moved back into BaseEventLoop.getaddrinfo

----------
components: asyncio
messages: 413699
nosy: asvetlov, graingert, yselivanov
priority: normal
severity: normal
status: open
title: use AI_NUMERICHOST | AI_NUMERICSERV to skip getaddrinfo thread in asyncio
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46824>
_______________________________________

From report at bugs.python.org  Tue Feb 22 05:21:34 2022
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 22 Feb 2022 10:21:34 +0000
Subject: [issue46329] Split up the CALL_NO_KW and CALL_KW instructions.
In-Reply-To: <1641819285.76.0.605357810946.issue46329@roundup.psfhosted.org>
Message-ID: <1645525294.58.0.790360484033.issue46329@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
pull_requests: +29626
pull_request: https://github.com/python/cpython/pull/31496

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46329>
_______________________________________

From report at bugs.python.org  Tue Feb 22 05:23:16 2022
From: report at bugs.python.org (Thomas Grainger)
Date: Tue, 22 Feb 2022 10:23:16 +0000
Subject: [issue46824] use AI_NUMERICHOST | AI_NUMERICSERV to skip getaddrinfo
 thread in asyncio
In-Reply-To: <1645524928.96.0.755041008121.issue46824@roundup.psfhosted.org>
Message-ID: <1645525396.7.0.229112772012.issue46824@roundup.psfhosted.org>


Change by Thomas Grainger <tagrain at gmail.com>:


----------
keywords: +patch
pull_requests: +29627
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31497

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46824>
_______________________________________

From report at bugs.python.org  Tue Feb 22 05:23:02 2022
From: report at bugs.python.org (Heran Yang)
Date: Tue, 22 Feb 2022 10:23:02 +0000
Subject: [issue46825] slow matching on regular expression
Message-ID: <1645525382.1.0.0821682540319.issue46825@roundup.psfhosted.org>


New submission from Heran Yang <heran55 at 126.com>:

I'm using `re.fullmatch` to match a string that only contains 0 and 1. The regular expression is: (0+|1(01*0)*1)+

It runs rather slow with Python 3.7, but when I try using regex in C++, with std::regex_constants::__polynomial, it works well.

Would someone take a look at it? Thx.

----------
components: Regular Expressions
files: match.py
messages: 413700
nosy: HeRaNO, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: slow matching on regular expression
type: performance
versions: Python 3.7
Added file: https://bugs.python.org/file50636/match.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46825>
_______________________________________

From report at bugs.python.org  Tue Feb 22 05:35:44 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 22 Feb 2022 10:35:44 +0000
Subject: [issue46824] use AI_NUMERICHOST | AI_NUMERICSERV to skip getaddrinfo
 thread in asyncio
In-Reply-To: <1645524928.96.0.755041008121.issue46824@roundup.psfhosted.org>
Message-ID: <1645526144.18.0.769478114386.issue46824@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Could you provide more context for the proposed change?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46824>
_______________________________________

From report at bugs.python.org  Tue Feb 22 05:53:58 2022
From: report at bugs.python.org (Thomas Grainger)
Date: Tue, 22 Feb 2022 10:53:58 +0000
Subject: [issue46824] use AI_NUMERICHOST | AI_NUMERICSERV to skip getaddrinfo
 thread in asyncio
In-Reply-To: <1645524928.96.0.755041008121.issue46824@roundup.psfhosted.org>
Message-ID: <1645527238.24.0.0557235128509.issue46824@roundup.psfhosted.org>


Thomas Grainger <tagrain at gmail.com> added the comment:

hello, it's actually a bit of a round about context, but it was brought up on a tornado issue where I was attempting to port the asyncio optimization to tornado: https://github.com/tornadoweb/tornado/issues/3113#issuecomment-1041019287

I think it would be better to use this AI_NUMERICHOST | AI_NUMERICSERV optimization from trio everywhere instead

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46824>
_______________________________________

From report at bugs.python.org  Tue Feb 22 05:56:34 2022
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 22 Feb 2022 10:56:34 +0000
Subject: [issue46725] Unpacking without parentheses is allowed since 3.9
In-Reply-To: <1644603030.68.0.559962279778.issue46725@roundup.psfhosted.org>
Message-ID: <1645527394.66.0.316005287652.issue46725@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

What happened is that the new grammar using the PEG parser used the equivalent of starred_testlist instead of testlist for the iterable list of for statements.

The only extra thing allowed is starred elements, that are interpreted as if you are building a tuple without parentheses.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46725>
_______________________________________

From report at bugs.python.org  Tue Feb 22 06:27:13 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 22 Feb 2022 11:27:13 +0000
Subject: [issue46818] Proper way to inherit from collections.abc.Coroutine
In-Reply-To: <1645448629.24.0.443450493338.issue46818@roundup.psfhosted.org>
Message-ID: <1645529233.62.0.16015060017.issue46818@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

> Are you suggesting that I need to just inherit from Awaitable? 

Yes. Awaitable is a very base protocol, Coroutine is an implementation.

`__await__` returns a generator that is used by Python internals as if `yield from awaitable.__await__()` was called.  asyncio never sends data back to the generator but other async frameworks can do it.

`send()`/`close()`/`throw()` coroutine methods are never used now IFAIK.  The current implementation calls these methods at the C level without using Python-exposed names. Performance matters.
These methods can be still used in very rare cases, e.g. when explicit Python `yield from custom_coro.__await__()` is used.

----------
components: +Interpreter Core -asyncio

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46818>
_______________________________________

From report at bugs.python.org  Tue Feb 22 06:33:44 2022
From: report at bugs.python.org (Addison Snelling)
Date: Tue, 22 Feb 2022 11:33:44 +0000
Subject: [issue46826] prefixes argument to site.getsitepackages() missing
 documentation
Message-ID: <1645529624.68.0.789981983481.issue46826@roundup.psfhosted.org>


New submission from Addison Snelling <addison at asnell.io>:

The documentation for site.getsitepackages() makes no mention of the "prefixes" argument, introduced in v3.3.

I'll put together a pull request in the next day or so to add this to the docs.

----------
assignee: docs at python
components: Documentation
messages: 413705
nosy: asnell, docs at python
priority: normal
severity: normal
status: open
title: prefixes argument to site.getsitepackages() missing documentation
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46826>
_______________________________________

From report at bugs.python.org  Tue Feb 22 06:37:58 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 22 Feb 2022 11:37:58 +0000
Subject: [issue46622] Support decorating a coroutine with functools.lru_cache
In-Reply-To: <1643873308.65.0.92890586202.issue46622@roundup.psfhosted.org>
Message-ID: <1645529878.81.0.0811972393568.issue46622@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
title: Support  decorating a coroutine with functools.cached_property -> Support  decorating a coroutine with functools.lru_cache

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46622>
_______________________________________

From report at bugs.python.org  Tue Feb 22 08:24:42 2022
From: report at bugs.python.org (Taneli Hukkinen)
Date: Tue, 22 Feb 2022 13:24:42 +0000
Subject: [issue40059] Provide a toml module in the standard library
In-Reply-To: <1585119261.47.0.818238682424.issue40059@roundup.psfhosted.org>
Message-ID: <1645536282.97.0.51560456723.issue40059@roundup.psfhosted.org>


Change by Taneli Hukkinen <taneli.hukkinen+python at gmail.com>:


----------
keywords: +patch
nosy: +hukkinj1
nosy_count: 15.0 -> 16.0
pull_requests: +29628
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31498

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40059>
_______________________________________

From report at bugs.python.org  Tue Feb 22 08:26:21 2022
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 22 Feb 2022 13:26:21 +0000
Subject: [issue46798] xml.etree.ElementTree: get() doesn't return default
 value, always ATTLIST value
In-Reply-To: <1645270291.57.0.995603390679.issue46798@roundup.psfhosted.org>
Message-ID: <1645536381.39.0.5891009302.issue46798@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

The question here is simply, which is considered more important: the default provided by the document, or the default provided by Python. I don't think it's a clear choice, but the way it is now does not seem unreasonable. Changing it would mean deliberate breakage of existing code that relies on the existing behaviour, and I do not see a reason to do that.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46798>
_______________________________________

From report at bugs.python.org  Tue Feb 22 08:38:34 2022
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 22 Feb 2022 13:38:34 +0000
Subject: [issue46786] embed, source, track,
 wbr HTML elements not considered empty
In-Reply-To: <1645179799.58.0.92424391054.issue46786@roundup.psfhosted.org>
Message-ID: <1645537114.89.0.177041554122.issue46786@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

Makes sense. That list hasn't been updated in 10 years.

----------
versions:  -Python 3.10, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46786>
_______________________________________

From report at bugs.python.org  Tue Feb 22 08:47:50 2022
From: report at bugs.python.org (Alex Waygood)
Date: Tue, 22 Feb 2022 13:47:50 +0000
Subject: [issue45100] Improve help() by making typing.overload() information
 accessible at runtime
In-Reply-To: <1630778608.65.0.813637953031.issue45100@roundup.psfhosted.org>
Message-ID: <1645537670.43.0.760815581661.issue45100@roundup.psfhosted.org>


Change by Alex Waygood <Alex.Waygood at Gmail.com>:


----------
nosy: +sobolevn

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45100>
_______________________________________

From report at bugs.python.org  Tue Feb 22 09:36:28 2022
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 22 Feb 2022 14:36:28 +0000
Subject: [issue46825] slow matching on regular expression
In-Reply-To: <1645525382.1.0.0821682540319.issue46825@roundup.psfhosted.org>
Message-ID: <1645540588.86.0.0803214692894.issue46825@roundup.psfhosted.org>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

The expression is a repeated alternative where the first alternative is a repeat. Repeated repeats can result in a lot of attempts and backtracking and should be avoided.

Try this instead:

    (0|1(01*0)*1)+

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46825>
_______________________________________

From report at bugs.python.org  Tue Feb 22 10:05:31 2022
From: report at bugs.python.org (Thomas Grainger)
Date: Tue, 22 Feb 2022 15:05:31 +0000
Subject: [issue46827] asyncio SelectorEventLoop.sock_connect fails with a UDP
 socket
Message-ID: <1645542331.15.0.0460526883326.issue46827@roundup.psfhosted.org>


New submission from Thomas Grainger <tagrain at gmail.com>:

the following code:

import socket
import asyncio

async def amain():
    with socket.socket(family=socket.AF_INET, proto=socket.IPPROTO_UDP, type=socket.SOCK_DGRAM) as sock:
        sock.setblocking(False)
        await asyncio.get_running_loop().sock_connect(sock, ("google.com", "443"))

asyncio.run(amain())


fails with:

Traceback (most recent call last):
  File "/home/graingert/projects/test_foo.py", line 9, in <module>
    asyncio.run(amain())
  File "/usr/lib/python3.10/asyncio/runners.py", line 44, in run
    return loop.run_until_complete(main)
  File "/usr/lib/python3.10/asyncio/base_events.py", line 641, in run_until_complete
    return future.result()
  File "/home/graingert/projects/test_foo.py", line 7, in amain
    await asyncio.get_running_loop().sock_connect(sock, ("google.com", "443"))
  File "/usr/lib/python3.10/asyncio/selector_events.py", line 496, in sock_connect
    resolved = await self._ensure_resolved(
  File "/usr/lib/python3.10/asyncio/base_events.py", line 1395, in _ensure_resolved
    return await loop.getaddrinfo(host, port, family=family, type=type,
  File "/usr/lib/python3.10/asyncio/base_events.py", line 855, in getaddrinfo
    return await self.run_in_executor(
  File "/usr/lib/python3.10/concurrent/futures/thread.py", line 58, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/lib/python3.10/socket.py", line 955, in getaddrinfo
    for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno -7] ai_socktype not supported

----------
components: asyncio
messages: 413709
nosy: asvetlov, graingert, yselivanov
priority: normal
severity: normal
status: open
title: asyncio SelectorEventLoop.sock_connect fails with a UDP socket
versions: Python 3.10, Python 3.11, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46827>
_______________________________________

From report at bugs.python.org  Tue Feb 22 10:07:13 2022
From: report at bugs.python.org (Thomas Grainger)
Date: Tue, 22 Feb 2022 15:07:13 +0000
Subject: [issue46827] asyncio SelectorEventLoop.sock_connect fails with a UDP
 socket
In-Reply-To: <1645542331.15.0.0460526883326.issue46827@roundup.psfhosted.org>
Message-ID: <1645542433.6.0.1279167993.issue46827@roundup.psfhosted.org>


Change by Thomas Grainger <tagrain at gmail.com>:


----------
keywords: +patch
pull_requests: +29629
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31499

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46827>
_______________________________________

From report at bugs.python.org  Tue Feb 22 10:45:31 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 22 Feb 2022 15:45:31 +0000
Subject: [issue46757] dataclasses should define an empty __post_init__
In-Reply-To: <1644923607.6.0.495534870715.issue46757@roundup.psfhosted.org>
Message-ID: <1645544731.69.0.778173706405.issue46757@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I'm going to close this issue. As Raymond says, it's a breaking change, and the workaround is easy enough.

----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46757>
_______________________________________

From report at bugs.python.org  Tue Feb 22 10:54:45 2022
From: report at bugs.python.org (Steve Dower)
Date: Tue, 22 Feb 2022 15:54:45 +0000
Subject: [issue46822] test_create_server_ssl_over_ssl times out on some systems
In-Reply-To: <1645488125.93.0.760341419573.issue46822@roundup.psfhosted.org>
Message-ID: <1645545285.54.0.15890867337.issue46822@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Looks like my issue is actually related to the timeouts added in issue44011.

I'm guessing it's an SSL shutdown timeout, because those are notoriously weird on Windows/OpenSSL.

The timeout is now 30s, but the test aborts after 10s. If I increase the test timeout to 50s, it passes reliably.

However, if I pass ssl_shutdown_timeout to the protocol created in the test (which I think is the right place?), it fails with a timeout somewhere else.

So my guess is that my system (VM in a somewhat protected network) is legitimately taking that long to shut down the connection? And so the test timeout ought to be increased?

----------
title: test_create_server_ssl_over_ssl attempts to listen on 0.0.0.0 -> test_create_server_ssl_over_ssl times out on some systems

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46822>
_______________________________________

From report at bugs.python.org  Tue Feb 22 10:58:54 2022
From: report at bugs.python.org (Steve Dower)
Date: Tue, 22 Feb 2022 15:58:54 +0000
Subject: [issue46822] test_create_server_ssl_over_ssl times out on some systems
In-Reply-To: <1645488125.93.0.760341419573.issue46822@roundup.psfhosted.org>
Message-ID: <1645545534.56.0.495236393155.issue46822@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

In fact, I only have to increase the test timeout to 15s to get it to pass reliably.

I don't see any reason the test should time out quicker than the operations it's testing though, right? So set it to 30s?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46822>
_______________________________________

From report at bugs.python.org  Tue Feb 22 11:02:26 2022
From: report at bugs.python.org (Steve Dower)
Date: Tue, 22 Feb 2022 16:02:26 +0000
Subject: [issue46822] test_create_server_ssl_over_ssl times out on some systems
In-Reply-To: <1645488125.93.0.760341419573.issue46822@roundup.psfhosted.org>
Message-ID: <1645545746.18.0.129722301355.issue46822@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch
pull_requests: +29630
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/31502

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46822>
_______________________________________

From report at bugs.python.org  Tue Feb 22 11:23:46 2022
From: report at bugs.python.org (Eric Snow)
Date: Tue, 22 Feb 2022 16:23:46 +0000
Subject: [issue46806] Overlapping PYTHONPATH may cause import already imported
 module
In-Reply-To: <1645360487.42.0.278270431314.issue46806@roundup.psfhosted.org>
Message-ID: <1645547026.05.0.638948020019.issue46806@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

When you run a Python script, the directory the script is in is automatically added to the beginning of sys.path.  This is the fundamental issue you've run into.

Basically, "src.common_object" is imported relative to the "src" that was imported relative to that automatically added sys.path entry.  However, "common_object" is a distinct module imported relative to the sys.path entry you explicitly added.

In general, adding a package's directory to sys.path is a bad idea.

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46806>
_______________________________________

From report at bugs.python.org  Tue Feb 22 11:23:54 2022
From: report at bugs.python.org (Eric Snow)
Date: Tue, 22 Feb 2022 16:23:54 +0000
Subject: [issue46806] Overlapping PYTHONPATH may cause import already imported
 module
In-Reply-To: <1645360487.42.0.278270431314.issue46806@roundup.psfhosted.org>
Message-ID: <1645547034.57.0.274108907923.issue46806@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Here is more detail on what happens when "from src import user_1, user_2, user_3" is executed in main.py:

1. the "src" module is imported
   a. not found in sys.modules
   b. file found on a sys.path entry (the directory main.py is in)
   c. the "src" module is created with __path__ set to the src directory
   d. the module is added to sys.modules
   e. src/__init__.py is executed
2. the "src.user_1" module is imported
   a. not found in sys.modules
   b. file found relative to src.__path__
   c. module created
   d. added to sys.modules
   e. executed
3. "from .common_object import OBJECT" is resolved to "from src.common_object import OBJECT"
4. "src.common_object" is imported (see 2)
5. src.common_object.OBJECT is created
6. "src.user_2" is imported (see 2)
7. "src.common_object" is already found in sys.modules and used
8. "src.user_3" is imported (see 2)
9. "common_object" is imported
   a. not found in sys.modules
   b. file found on a sys.path entry (the one you added in main.py)
   c. module created
   d. added to sys.modules
   e. executed
10. common_object.OBJECT is created

So the module created at (4) is different than the one at (9), even though they are imported from the same file.  Consequently, the OBJECT in each is likewise distinct.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46806>
_______________________________________

From report at bugs.python.org  Tue Feb 22 11:25:15 2022
From: report at bugs.python.org (Steve Dower)
Date: Tue, 22 Feb 2022 16:25:15 +0000
Subject: [issue46822] test_create_server_ssl_over_ssl times out on some systems
In-Reply-To: <1645488125.93.0.760341419573.issue46822@roundup.psfhosted.org>
Message-ID: <1645547115.19.0.00426875567634.issue46822@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 77f31a91d55df2df79ac767690738081f27ad476 by Steve Dower in branch 'main':
bpo-46822: Increase timeout for test_create_server_ssl_over_ssl to match underlying timeouts (GH-31502)
https://github.com/python/cpython/commit/77f31a91d55df2df79ac767690738081f27ad476


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46822>
_______________________________________

From report at bugs.python.org  Tue Feb 22 11:25:44 2022
From: report at bugs.python.org (Eric Snow)
Date: Tue, 22 Feb 2022 16:25:44 +0000
Subject: [issue46806] Overlapping PYTHONPATH may cause import already imported
 module
In-Reply-To: <1645360487.42.0.278270431314.issue46806@roundup.psfhosted.org>
Message-ID: <1645547144.52.0.546548067267.issue46806@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

I'm leaving this "pending" in case there may be some improvement we can make to the documentation to address this.

----------
components: +Interpreter Core
nosy: +docs at python
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46806>
_______________________________________

From report at bugs.python.org  Tue Feb 22 11:42:58 2022
From: report at bugs.python.org (Eric Snow)
Date: Tue, 22 Feb 2022 16:42:58 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting and
 immortal objects
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1645548178.43.0.584148206807.issue40255@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Thanks for the updates, Eddie.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Tue Feb 22 11:44:59 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 22 Feb 2022 16:44:59 +0000
Subject: [issue45100] Improve help() by making typing.overload() information
 accessible at runtime
In-Reply-To: <1630778608.65.0.813637953031.issue45100@roundup.psfhosted.org>
Message-ID: <1645548299.39.0.335725352867.issue45100@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/issue45100>
_______________________________________

From report at bugs.python.org  Tue Feb 22 12:26:57 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 22 Feb 2022 17:26:57 +0000
Subject: [issue46725] Unpacking without parentheses is allowed since 3.9
In-Reply-To: <1644603030.68.0.559962279778.issue46725@roundup.psfhosted.org>
Message-ID: <1645550817.3.0.116383833984.issue46725@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 7fb94fd7a88f14096a509dddd4d8a979a3912672 by Pablo Galindo Salgado in branch 'main':
bpo-46725: Document starred expressions in for statements (GH-31481)
https://github.com/python/cpython/commit/7fb94fd7a88f14096a509dddd4d8a979a3912672


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46725>
_______________________________________

From report at bugs.python.org  Tue Feb 22 12:27:25 2022
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 22 Feb 2022 17:27:25 +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: <1645550845.82.0.72503508124.issue40421@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The gevent project is not compatible with Python 3.11: it gets and sets directly PyFrameObject.f_code member which has been removed in Python 3.11 (moved to PyFrameObject.f_frame.f_code internal C API).

gevent issue: https://github.com/gevent/gevent/issues/1867

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40421>
_______________________________________

From report at bugs.python.org  Tue Feb 22 12:32:00 2022
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 22 Feb 2022 17:32:00 +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: <1645551120.48.0.461572589149.issue40421@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The f_code member has been removed by in bpo-44032 by the commit b11a951f16f0603d98de24fee5c023df83ea552c.

The f_frame member has been added in bpo-44590 by the commit ae0a2b756255629140efcbe57fc2e714f0267aa3.

See also bpo-46355 [C API] Document PyFrameObject and PyThreadState changes and explain how to port code to Python 3.11.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40421>
_______________________________________

From report at bugs.python.org  Tue Feb 22 12:33:39 2022
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 22 Feb 2022 17:33:39 +0000
Subject: [issue44032] Function locals and evaluation stack should be stored in
 a contiguous, per-thread stack
In-Reply-To: <1620140071.36.0.488434643792.issue44032@roundup.psfhosted.org>
Message-ID: <1645551219.15.0.943863699525.issue44032@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Removing the PyFrameObject.f_code member (commit b11a951f16f0603d98de24fee5c023df83ea552c) broke by gevent project:

* https://github.com/gevent/gevent/issues/1867
* https://bugs.python.org/issue40421#msg413719

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44032>
_______________________________________

From report at bugs.python.org  Tue Feb 22 12:36:18 2022
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 22 Feb 2022 17:36:18 +0000
Subject: [issue36557] [doc] Clarify the meaning of /uninstall in windows cli
In-Reply-To: <1554726023.31.0.350138244198.issue36557@roundup.psfhosted.org>
Message-ID: <1645551378.82.0.889989087565.issue36557@roundup.psfhosted.org>


Irit Katriel <iritkatriel at gmail.com> added the comment:


New changeset 9a0d941df4c3e1efb8b3017cd2c2de17e582fd5c by slateny in branch 'main':
bpo-36557: Updated wording for using/windows (GH-31457)
https://github.com/python/cpython/commit/9a0d941df4c3e1efb8b3017cd2c2de17e582fd5c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36557>
_______________________________________

From report at bugs.python.org  Tue Feb 22 12:36:26 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 22 Feb 2022 17:36:26 +0000
Subject: [issue36557] [doc] Clarify the meaning of /uninstall in windows cli
In-Reply-To: <1554726023.31.0.350138244198.issue36557@roundup.psfhosted.org>
Message-ID: <1645551386.07.0.0949514368773.issue36557@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 8.0 -> 9.0
pull_requests: +29631
pull_request: https://github.com/python/cpython/pull/31504

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36557>
_______________________________________

From report at bugs.python.org  Tue Feb 22 12:36:31 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 22 Feb 2022 17:36:31 +0000
Subject: [issue36557] [doc] Clarify the meaning of /uninstall in windows cli
In-Reply-To: <1554726023.31.0.350138244198.issue36557@roundup.psfhosted.org>
Message-ID: <1645551391.77.0.905103995533.issue36557@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29632
pull_request: https://github.com/python/cpython/pull/31505

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36557>
_______________________________________

From report at bugs.python.org  Tue Feb 22 12:42:58 2022
From: report at bugs.python.org (Steve Dower)
Date: Tue, 22 Feb 2022 17:42:58 +0000
Subject: [issue46822] test_create_server_ssl_over_ssl times out on some systems
In-Reply-To: <1645488125.93.0.760341419573.issue46822@roundup.psfhosted.org>
Message-ID: <1645551778.35.0.660753916999.issue46822@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/issue46822>
_______________________________________

From report at bugs.python.org  Tue Feb 22 12:57:10 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 22 Feb 2022 17:57:10 +0000
Subject: [issue36557] [doc] Clarify the meaning of /uninstall in windows cli
In-Reply-To: <1554726023.31.0.350138244198.issue36557@roundup.psfhosted.org>
Message-ID: <1645552630.92.0.215244071387.issue36557@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset d04fb9213a547def5604fbc60b0554c176d4c998 by Miss Islington (bot) in branch '3.10':
[3.10] bpo-36557: Updated wording for using/windows (GH-31457) (GH-31504)
https://github.com/python/cpython/commit/d04fb9213a547def5604fbc60b0554c176d4c998


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36557>
_______________________________________

From report at bugs.python.org  Tue Feb 22 12:57:24 2022
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 22 Feb 2022 17:57:24 +0000
Subject: [issue46800] Support for pause(2)
In-Reply-To: <1645291467.44.0.659055078048.issue46800@roundup.psfhosted.org>
Message-ID: <1645552644.64.0.291883987996.issue46800@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
resolution:  -> works for me
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46800>
_______________________________________

From report at bugs.python.org  Tue Feb 22 13:02:51 2022
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 22 Feb 2022 18:02:51 +0000
Subject: [issue46819] Add an Error / Exception / Warning when
 contextlib.suppress() is entered with no specified exception(s) to suppress
In-Reply-To: <1645464384.79.0.401778534641.issue46819@roundup.psfhosted.org>
Message-ID: <1645552971.43.0.92687494069.issue46819@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

But `suppress` takes varargs; from `suppress`'s perspective, there is no difference between `suppress()` and `l=[];suppress(*l)`.  There would be a difference at the AST level, but trying to find it within `suppress` to issue a warning seems unfeasible.  Certainly possible for a linter, though :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46819>
_______________________________________

From report at bugs.python.org  Tue Feb 22 13:03:46 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 22 Feb 2022 18:03:46 +0000
Subject: [issue36557] [doc] Clarify the meaning of /uninstall in windows cli
In-Reply-To: <1554726023.31.0.350138244198.issue36557@roundup.psfhosted.org>
Message-ID: <1645553026.68.0.300343502338.issue36557@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset aa9a5c4d72e083f8b4c635d79f7450dbe8319469 by Miss Islington (bot) in branch '3.9':
bpo-36557: Updated wording for using/windows (GH-31457)
https://github.com/python/cpython/commit/aa9a5c4d72e083f8b4c635d79f7450dbe8319469


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36557>
_______________________________________

From report at bugs.python.org  Tue Feb 22 13:05:38 2022
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 22 Feb 2022 18:05:38 +0000
Subject: [issue36557] [doc] Clarify the meaning of /uninstall in windows cli
In-Reply-To: <1554726023.31.0.350138244198.issue36557@roundup.psfhosted.org>
Message-ID: <1645553138.93.0.279897308159.issue36557@roundup.psfhosted.org>


Irit Katriel <iritkatriel at gmail.com> added the comment:

Thank you @slateny.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36557>
_______________________________________

From report at bugs.python.org  Tue Feb 22 13:06:49 2022
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 22 Feb 2022 18:06:49 +0000
Subject: [issue20923] [doc] Explain ConfigParser 'valid section name' and
 .SECTCRE
In-Reply-To: <1394806905.89.0.637343755468.issue20923@psf.upfronthosting.co.za>
Message-ID: <1645553209.58.0.254290783923.issue20923@roundup.psfhosted.org>


Irit Katriel <iritkatriel at gmail.com> added the comment:


New changeset bba8008f99d615a02984422a3825082bb5621f5a by vidhya in branch 'main':
bpo-20923 : [doc] Explain ConfigParser 'valid section name'  and .SECTCRE (GH-31413)
https://github.com/python/cpython/commit/bba8008f99d615a02984422a3825082bb5621f5a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20923>
_______________________________________

From report at bugs.python.org  Tue Feb 22 13:07:00 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 22 Feb 2022 18:07:00 +0000
Subject: [issue20923] [doc] Explain ConfigParser 'valid section name' and
 .SECTCRE
In-Reply-To: <1394806905.89.0.637343755468.issue20923@psf.upfronthosting.co.za>
Message-ID: <1645553220.31.0.719915482361.issue20923@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 11.0 -> 12.0
pull_requests: +29633
pull_request: https://github.com/python/cpython/pull/31506

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20923>
_______________________________________

From report at bugs.python.org  Tue Feb 22 13:07:04 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 22 Feb 2022 18:07:04 +0000
Subject: [issue20923] [doc] Explain ConfigParser 'valid section name' and
 .SECTCRE
In-Reply-To: <1394806905.89.0.637343755468.issue20923@psf.upfronthosting.co.za>
Message-ID: <1645553224.65.0.905832636274.issue20923@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29634
pull_request: https://github.com/python/cpython/pull/31507

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20923>
_______________________________________

From report at bugs.python.org  Tue Feb 22 13:11:19 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 22 Feb 2022 18:11:19 +0000
Subject: [issue46819] Add an Error / Exception / Warning when
 contextlib.suppress() is entered with no specified exception(s) to suppress
In-Reply-To: <1645464384.79.0.401778534641.issue46819@roundup.psfhosted.org>
Message-ID: <1645553479.72.0.837072730116.issue46819@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I concur with Zachary.

Note that suppress without arguments corresponds to "except" and isinstance() with empty tuple.

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46819>
_______________________________________

From report at bugs.python.org  Tue Feb 22 13:12:51 2022
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 22 Feb 2022 18:12:51 +0000
Subject: [issue46717] Raising exception multiple times leaks memory
In-Reply-To: <1644548391.27.0.391231331567.issue46717@roundup.psfhosted.org>
Message-ID: <1645553571.66.0.177201334474.issue46717@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at gmail.com>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46717>
_______________________________________

From report at bugs.python.org  Tue Feb 22 13:14:48 2022
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 22 Feb 2022 18:14:48 +0000
Subject: [issue43545] Use LOAD_GLOBAL to set __module__ in class def
In-Reply-To: <1616083438.62.0.932778825065.issue43545@roundup.psfhosted.org>
Message-ID: <1645553688.81.0.394369041008.issue43545@roundup.psfhosted.org>


Irit Katriel <iritkatriel at gmail.com> added the comment:

Please reopen or create and new issue if this is still relevant and you can provide more information.

----------
stage:  -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43545>
_______________________________________

From report at bugs.python.org  Tue Feb 22 13:17:22 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 22 Feb 2022 18:17:22 +0000
Subject: [issue46825] slow matching on regular expression
In-Reply-To: <1645525382.1.0.0821682540319.issue46825@roundup.psfhosted.org>
Message-ID: <1645553842.11.0.231536669227.issue46825@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The re module does not support features corresponding to std::regex_constants::__polynomial in C++. Rewrite your regular expression or try to use alternative regex implementations (for example wrappers around the re2 library or C++ regex library).

----------
nosy: +serhiy.storchaka
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46825>
_______________________________________

From report at bugs.python.org  Tue Feb 22 13:19:47 2022
From: report at bugs.python.org (Cooper Lees)
Date: Tue, 22 Feb 2022 18:19:47 +0000
Subject: [issue46819] Add an Error / Exception / Warning when
 contextlib.suppress() is entered with no specified exception(s) to suppress
In-Reply-To: <1645464384.79.0.401778534641.issue46819@roundup.psfhosted.org>
Message-ID: <1645553987.4.0.991357920297.issue46819@roundup.psfhosted.org>


Cooper Lees <me at cooperlees.com> added the comment:

Ok thanks. Looks like the warning in flake8-bugbear is the right place then, unfortunately.

And just to be sure:

> Note that suppress without arguments corresponds to "except" and isinstance() with empty tuple.

Are you saying that `contextlib.suppress()` should effectively `except BaseException` (cause this is not the behavior from my tests) and suppress all or suppress nothing? I believe the empty tuple makes it except nothing?

```python
cooper at home1:~$ python3.11
Python 3.11.0a5+ (main, Feb 22 2022, 08:51:50) [GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import contextlib
>>> with contextlib.suppress():
...   raise ValueError("I raise ...")
...
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
ValueError: I raise ...
>>>
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46819>
_______________________________________

From report at bugs.python.org  Tue Feb 22 13:24:02 2022
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 22 Feb 2022 18:24:02 +0000
Subject: [issue46819] Add an Error / Exception / Warning when
 contextlib.suppress() is entered with no specified exception(s) to suppress
In-Reply-To: <1645464384.79.0.401778534641.issue46819@roundup.psfhosted.org>
Message-ID: <1645554242.14.0.0793344792312.issue46819@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

>>> try:
...     raise ValueError("I raise...")
... except ():
...     pass
... 
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
ValueError: I raise...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46819>
_______________________________________

From report at bugs.python.org  Tue Feb 22 13:27:02 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 22 Feb 2022 18:27:02 +0000
Subject: [issue46819] Add an Error / Exception / Warning when
 contextlib.suppress() is entered with no specified exception(s) to suppress
In-Reply-To: <1645464384.79.0.401778534641.issue46819@roundup.psfhosted.org>
Message-ID: <1645554422.15.0.244823839595.issue46819@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

No, I say that

    with suppress():
        ...

is equivalent to

    try:
        ...
    except ():
        pass

or

    try:
        ...
    except BaseException as err:
        if not isinstance(err, ()):
            raise

If you want to suppress all exceptions (it is not very clever idea), use suppress(BaseException).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46819>
_______________________________________

From report at bugs.python.org  Tue Feb 22 13:28:55 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 22 Feb 2022 18:28:55 +0000
Subject: [issue20923] [doc] Explain ConfigParser 'valid section name' and
 .SECTCRE
In-Reply-To: <1394806905.89.0.637343755468.issue20923@psf.upfronthosting.co.za>
Message-ID: <1645554535.3.0.304991917537.issue20923@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a7af34d407b344de7f138c002854a3e16ecb9db5 by Miss Islington (bot) in branch '3.10':
[3.10] bpo-20923 : [doc] Explain ConfigParser 'valid section name'  and .SECTCRE (GH-31413) (GH-31506)
https://github.com/python/cpython/commit/a7af34d407b344de7f138c002854a3e16ecb9db5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20923>
_______________________________________

From report at bugs.python.org  Tue Feb 22 13:29:02 2022
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 22 Feb 2022 18:29:02 +0000
Subject: [issue46729] Better str() for BaseExceptionGroup
In-Reply-To: <1644663721.5.0.89729285647.issue46729@roundup.psfhosted.org>
Message-ID: <1645554542.32.0.686568634049.issue46729@roundup.psfhosted.org>


Irit Katriel <iritkatriel at gmail.com> added the comment:


New changeset 38b5acf8673ce42a401263a2528202e44d6ae60a by Irit Katriel in branch 'main':
bpo-46729: add number of sub-exceptions in str() of BaseExceptionGroup (GH-31294)
https://github.com/python/cpython/commit/38b5acf8673ce42a401263a2528202e44d6ae60a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46729>
_______________________________________

From report at bugs.python.org  Tue Feb 22 13:29:26 2022
From: report at bugs.python.org (Cooper Lees)
Date: Tue, 22 Feb 2022 18:29:26 +0000
Subject: [issue46819] Add an Error / Exception / Warning when
 contextlib.suppress() is entered with no specified exception(s) to suppress
In-Reply-To: <1645464384.79.0.401778534641.issue46819@roundup.psfhosted.org>
Message-ID: <1645554566.93.0.92990342584.issue46819@roundup.psfhosted.org>


Cooper Lees <me at cooperlees.com> added the comment:

I would never want to do that ... I understand it's bad. Just questioning things before adding lints so we put things in the right places and more importantly making sure I understand.

Thanks for the discussion all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46819>
_______________________________________

From report at bugs.python.org  Tue Feb 22 13:30:01 2022
From: report at bugs.python.org (Cooper Lees)
Date: Tue, 22 Feb 2022 18:30:01 +0000
Subject: [issue46819] Add an Error / Exception / Warning when
 contextlib.suppress() is entered with no specified exception(s) to suppress
In-Reply-To: <1645464384.79.0.401778534641.issue46819@roundup.psfhosted.org>
Message-ID: <1645554601.76.0.922119343621.issue46819@roundup.psfhosted.org>


Cooper Lees <me at cooperlees.com> added the comment:

FWIW - Will be looking to add to flake8-bugbear here: https://github.com/PyCQA/flake8-bugbear/issues/222

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46819>
_______________________________________

From report at bugs.python.org  Tue Feb 22 13:30:58 2022
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 22 Feb 2022 18:30:58 +0000
Subject: [issue46729] Better str() for BaseExceptionGroup
In-Reply-To: <1644663721.5.0.89729285647.issue46729@roundup.psfhosted.org>
Message-ID: <1645554658.48.0.217884474028.issue46729@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46729>
_______________________________________

From report at bugs.python.org  Tue Feb 22 13:31:20 2022
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 22 Feb 2022 18:31:20 +0000
Subject: [issue46725] Unpacking without parentheses is allowed since 3.9
In-Reply-To: <1644603030.68.0.559962279778.issue46725@roundup.psfhosted.org>
Message-ID: <1645554680.42.0.574681260408.issue46725@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/issue46725>
_______________________________________

From report at bugs.python.org  Tue Feb 22 13:44:09 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 22 Feb 2022 18:44:09 +0000
Subject: [issue20923] [doc] Explain ConfigParser 'valid section name' and
 .SECTCRE
In-Reply-To: <1394806905.89.0.637343755468.issue20923@psf.upfronthosting.co.za>
Message-ID: <1645555449.33.0.517167939124.issue20923@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 2387aeacc78bfd9d314428b79590b2b47511bf33 by Miss Islington (bot) in branch '3.9':
[3.9] bpo-20923 : [doc] Explain ConfigParser 'valid section name'  and .SECTCRE (GH-31413) (GH-31507)
https://github.com/python/cpython/commit/2387aeacc78bfd9d314428b79590b2b47511bf33


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20923>
_______________________________________

From report at bugs.python.org  Tue Feb 22 13:46:35 2022
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 22 Feb 2022 18:46:35 +0000
Subject: [issue20923] [doc] Explain ConfigParser 'valid section name' and
 .SECTCRE
In-Reply-To: <1394806905.89.0.637343755468.issue20923@psf.upfronthosting.co.za>
Message-ID: <1645555595.44.0.229941762708.issue20923@roundup.psfhosted.org>


Irit Katriel <iritkatriel at gmail.com> added the comment:

Thank you @vidhya!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20923>
_______________________________________

From report at bugs.python.org  Tue Feb 22 13:58:00 2022
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 22 Feb 2022 18:58:00 +0000
Subject: [issue46632] test_ssl: 2 tests fail on cstratak-CentOS9-fips-x86_64
In-Reply-To: <1643968485.02.0.29316293905.issue46632@roundup.psfhosted.org>
Message-ID: <1645556280.89.0.0351335697629.issue46632@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Same on AMD64 CentOS9 FIPS Only Blake2 Builtin Hash 3.x:
https://buildbot.python.org/all/#/builders/828/builds/196

test.pythoninfo:

fips.linux_crypto_fips_enabled: 1
fips.openssl_fips_mode: 1
ssl.OPENSSL_VERSION: OpenSSL 3.0.1 14 Dec 2021
ssl.OPENSSL_VERSION_INFO: (3, 0, 0, 1, 0)

======================================================================
ERROR: test_load_verify_cadata (test.test_ssl.ContextTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-CentOS9-fips-x86_64.no-builtin-hashes-except-blake2/build/Lib/test/test_ssl.py", line 1494, in test_load_verify_cadata
    ctx.load_verify_locations(cadata=cacert_der)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ssl.SSLError: [EVP] unsupported (_ssl.c:4009)

======================================================================
ERROR: test_connect_cadata (test.test_ssl.SimpleBackgroundTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-CentOS9-fips-x86_64.no-builtin-hashes-except-blake2/build/Lib/test/test_ssl.py", line 2138, in test_connect_cadata
    ctx.load_verify_locations(cadata=der)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ssl.SSLError: [EVP] unsupported (_ssl.c:4009)

Stdout:
 server:  new connection from ('127.0.0.1', 38484)
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46632>
_______________________________________

From report at bugs.python.org  Tue Feb 22 14:04:33 2022
From: report at bugs.python.org (Neil Webber)
Date: Tue, 22 Feb 2022 19:04:33 +0000
Subject: [issue46828] math.prod can return integers (contradicts doc)
Message-ID: <1645556673.97.0.708040802519.issue46828@roundup.psfhosted.org>


New submission from Neil Webber <nw at neilwebber.com>:

The math module documentation says:

   Except when explicitly noted otherwise, all return values are floats.

But this code returns an integer:

   from math import prod; prod((1,2,3))

Doc should "explicitly note otherwise" here, I imagine. The issue being wanting to know that the result on all-integer input will be an exact (integer) value not a floating value.

----------
assignee: docs at python
components: Documentation
messages: 413741
nosy: docs at python, neilwebber
priority: normal
severity: normal
status: open
title: math.prod can return integers (contradicts doc)
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46828>
_______________________________________

From report at bugs.python.org  Tue Feb 22 14:11:13 2022
From: report at bugs.python.org (=?utf-8?q?Tin_Tvrtkovi=C4=87?=)
Date: Tue, 22 Feb 2022 19:11:13 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645557073.85.0.240097974425.issue46771@roundup.psfhosted.org>


Change by Tin Tvrtkovi? <tinchester at gmail.com>:


----------
pull_requests: +29635
pull_request: https://github.com/python/cpython/pull/31508

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Tue Feb 22 15:36:20 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 22 Feb 2022 20:36:20 +0000
Subject: [issue46827] asyncio SelectorEventLoop.sock_connect fails with a UDP
 socket
In-Reply-To: <1645542331.15.0.0460526883326.issue46827@roundup.psfhosted.org>
Message-ID: <1645562180.9.0.531133149286.issue46827@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: +29636
pull_request: https://github.com/python/cpython/pull/31509

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46827>
_______________________________________

From report at bugs.python.org  Tue Feb 22 15:36:25 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 22 Feb 2022 20:36:25 +0000
Subject: [issue46827] asyncio SelectorEventLoop.sock_connect fails with a UDP
 socket
In-Reply-To: <1645542331.15.0.0460526883326.issue46827@roundup.psfhosted.org>
Message-ID: <1645562185.91.0.198563162649.issue46827@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29637
pull_request: https://github.com/python/cpython/pull/31510

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46827>
_______________________________________

From report at bugs.python.org  Tue Feb 22 15:36:25 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 22 Feb 2022 20:36:25 +0000
Subject: [issue46827] asyncio SelectorEventLoop.sock_connect fails with a UDP
 socket
In-Reply-To: <1645542331.15.0.0460526883326.issue46827@roundup.psfhosted.org>
Message-ID: <1645562185.56.0.893189149417.issue46827@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset 8fb94893e4a870ed3533e80c4bc2f1ebf1cfa9e7 by Thomas Grainger in branch 'main':
bpo-46827: pass sock.type to getaddrinfo in sock_connect (GH-31499)
https://github.com/python/cpython/commit/8fb94893e4a870ed3533e80c4bc2f1ebf1cfa9e7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46827>
_______________________________________

From report at bugs.python.org  Tue Feb 22 15:58:09 2022
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 22 Feb 2022 20:58:09 +0000
Subject: [issue46811] Test suite needs adjustments for Expat >=2.4.5
In-Reply-To: <1645386845.86.0.727249777809.issue46811@roundup.psfhosted.org>
Message-ID: <1645563489.02.0.962582024313.issue46811@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:


New changeset fdfd7a93540b0866ba42264ecb9b0a3c2286f654 by ?ukasz Langa (Sebastian Pipping) in branch '3.8':
bpo-46811: Make test suite support Expat >=2.4.5 (GH-31453)
https://github.com/python/cpython/commit/fdfd7a93540b0866ba42264ecb9b0a3c2286f654


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46811>
_______________________________________

From report at bugs.python.org  Tue Feb 22 16:04:20 2022
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 22 Feb 2022 21:04:20 +0000
Subject: [issue46659] Deprecate locale.getdefaultlocale() function
In-Reply-To: <1644168794.44.0.0658923518102.issue46659@roundup.psfhosted.org>
Message-ID: <1645563860.04.0.83752139949.issue46659@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset ccbe8045faf6e63d36229ea4e1b9298572cda126 by Victor Stinner in branch 'main':
bpo-46659: Fix the MBCS codec alias on Windows (GH-31218)
https://github.com/python/cpython/commit/ccbe8045faf6e63d36229ea4e1b9298572cda126


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46659>
_______________________________________

From report at bugs.python.org  Tue Feb 22 16:06:49 2022
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 22 Feb 2022 21:06:49 +0000
Subject: [issue46659] Deprecate locale.getdefaultlocale() function
In-Reply-To: <1644168794.44.0.0658923518102.issue46659@roundup.psfhosted.org>
Message-ID: <1645564009.43.0.34203777692.issue46659@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset b899126094731bc49fecb61f2c1b7557d74ca839 by Victor Stinner in branch 'main':
bpo-46659: Deprecate locale.getdefaultlocale() (GH-31206)
https://github.com/python/cpython/commit/b899126094731bc49fecb61f2c1b7557d74ca839


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46659>
_______________________________________

From report at bugs.python.org  Tue Feb 22 16:09:42 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 22 Feb 2022 21:09:42 +0000
Subject: [issue46827] asyncio SelectorEventLoop.sock_connect fails with a UDP
 socket
In-Reply-To: <1645542331.15.0.0460526883326.issue46827@roundup.psfhosted.org>
Message-ID: <1645564182.24.0.857951528933.issue46827@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset d327517b54c148eba499c777b99760356102cbe0 by Miss Islington (bot) in branch '3.10':
bpo-46827: pass sock.type to getaddrinfo in sock_connect (GH-31499)
https://github.com/python/cpython/commit/d327517b54c148eba499c777b99760356102cbe0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46827>
_______________________________________

From report at bugs.python.org  Tue Feb 22 16:10:08 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 22 Feb 2022 21:10:08 +0000
Subject: [issue46827] asyncio SelectorEventLoop.sock_connect fails with a UDP
 socket
In-Reply-To: <1645542331.15.0.0460526883326.issue46827@roundup.psfhosted.org>
Message-ID: <1645564208.02.0.0237338631773.issue46827@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 29e8c43b32d6f1ec2e8b4fd8c4903d30830f280f by Miss Islington (bot) in branch '3.9':
bpo-46827: pass sock.type to getaddrinfo in sock_connect (GH-31499)
https://github.com/python/cpython/commit/29e8c43b32d6f1ec2e8b4fd8c4903d30830f280f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46827>
_______________________________________

From report at bugs.python.org  Tue Feb 22 16:10:49 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 22 Feb 2022 21:10:49 +0000
Subject: [issue46827] asyncio SelectorEventLoop.sock_connect fails with a UDP
 socket
In-Reply-To: <1645542331.15.0.0460526883326.issue46827@roundup.psfhosted.org>
Message-ID: <1645564249.77.0.921718144366.issue46827@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/issue46827>
_______________________________________

From report at bugs.python.org  Tue Feb 22 16:12:45 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 22 Feb 2022 21:12:45 +0000
Subject: [issue44011] Borrow asyncio ssl implementation from uvloop
In-Reply-To: <1619987620.01.0.201978044819.issue44011@roundup.psfhosted.org>
Message-ID: <1645564365.99.0.259530206598.issue44011@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/issue44011>
_______________________________________

From report at bugs.python.org  Tue Feb 22 16:34:56 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 22 Feb 2022 21:34:56 +0000
Subject: [issue45146] Add a possibility for asyncio.Condition to determine the
 count of currently waiting consumers
In-Reply-To: <1631162776.4.0.536124821312.issue45146@roundup.psfhosted.org>
Message-ID: <1645565696.48.0.0722926811326.issue45146@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Sorry, your use-case looks not convincing but overcomplicated.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45146>
_______________________________________

From report at bugs.python.org  Tue Feb 22 17:02:51 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 22 Feb 2022 22:02:51 +0000
Subject: [issue46829] Confusing CancelError message if multiple cancellations
 are scheduled
Message-ID: <1645567371.24.0.086924022035.issue46829@roundup.psfhosted.org>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

Suppose multiple `task.cancel(msg)` with different messages are called on the same event loop iteration.

What message (`cancel_exc.args[0]`) should be sent on the next loop iteration?

As of Python 3.10 it is the message from the *last* `task.cancel(msg)` call. 
The main branch changed it to the *first* message (it is a subject for discussion still).
Both choices are equally bad. The order of tasks execution at the same loop iteration is weak and depends on very many circumstances. Effectively, first-cancelled-message and last-cancelled-message are equal to random-message.

This makes use of cancellation message not robust: a task can be cancelled by many sources, task-groups adds even more mess.

Guido van Rossum suggested that messages should be collected in a list and raised altogether. There is a possibility to do it in a backward-compatible way: construct the exception as `CancelledError(last_msg, tuple(msg_list))`. args[0] is args[1][-1]. Weird but works.

`.cancel()` should add `None` to the list of cancelled messages.
The message list should be cleared when a new CancelledError is constructed and thrown into cancelling task.

Working with exc.args[0] / exc.args[1] is tedious and error-prone. I propose adding `exc.msgs` property. Not sure if the last added message is worth a separate attribute, a robust code should not rely on messages order as I described above.

The single message is not very useful but a list of messages can be used in timeouts implementation as cancellation count alternative.

I don't have a strong preference now but want to carefully discuss possible opportunities before making the final decision.

----------
components: asyncio
messages: 413749
nosy: ajoino, alex.gronholm, asvetlov, chris.jerdonek, dreamsorcerer, gvanrossum, iritkatriel, jab, njs, tinchester, yselivanov
priority: normal
severity: normal
status: open
title: Confusing CancelError message if multiple cancellations are scheduled
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46829>
_______________________________________

From report at bugs.python.org  Tue Feb 22 17:06:33 2022
From: report at bugs.python.org (Brandt Bucher)
Date: Tue, 22 Feb 2022 22:06:33 +0000
Subject: [issue46329] Split up the CALL_NO_KW and CALL_KW instructions.
In-Reply-To: <1641819285.76.0.605357810946.issue46329@roundup.psfhosted.org>
Message-ID: <1645567593.73.0.483427366934.issue46329@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
pull_requests: +29638
pull_request: https://github.com/python/cpython/pull/31511

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46329>
_______________________________________

From report at bugs.python.org  Tue Feb 22 17:11:58 2022
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 22 Feb 2022 22:11:58 +0000
Subject: [issue45459] Limited API support for Py_buffer
In-Reply-To: <1634118913.79.0.141868262007.issue45459@roundup.psfhosted.org>
Message-ID: <1645567918.36.0.246820628499.issue45459@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 66b3cd7063322a9f5c922a97bbd06fdb98309999 by Victor Stinner in branch 'main':
bpo-45459: Rename buffer.h to pybuffer.h (#31201)
https://github.com/python/cpython/commit/66b3cd7063322a9f5c922a97bbd06fdb98309999


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45459>
_______________________________________

From report at bugs.python.org  Tue Feb 22 17:13:23 2022
From: report at bugs.python.org (Alex Waygood)
Date: Tue, 22 Feb 2022 22:13:23 +0000
Subject: [issue45100] Improve help() by making typing.overload() information
 accessible at runtime
In-Reply-To: <1630778608.65.0.813637953031.issue45100@roundup.psfhosted.org>
Message-ID: <1645568003.21.0.52016765866.issue45100@roundup.psfhosted.org>


Alex Waygood <Alex.Waygood at Gmail.com> added the comment:

I'd dearly like better introspection tools for functions decorated with @overload, but I'd rather have a solution where:

- inspect.signature doesn't have to import typing. That doesn't feel worth it for users who aren't using typing.overload, but inspect.signature would have to import typing whether or not @overload was being used, in order to *check* whether @overload was being used.
- The solution could be reused by, and generalised to, other kinds of functions that have multiple signatures.

If we create an __overloads__ dunder that stored the signatures of multi-signature functions, as Raymond suggests, inspect.signature could check that dunder to examine whether the function is a multi-dispatch signature, and change its representation of the function accordingly. This kind of solution could be easily reused by other parts of the stdlib, like @functools.singledispatch, and by third-party packages such as plum-dispatch, multipledispatch, and Nikita's dry-python/classes library.

So, while it would undoubtedly be more complex to implement, I much prefer Raymond's suggested solution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45100>
_______________________________________

From report at bugs.python.org  Tue Feb 22 17:34:23 2022
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 22 Feb 2022 22:34:23 +0000
Subject: [issue45459] Limited API support for Py_buffer
In-Reply-To: <1634118913.79.0.141868262007.issue45459@roundup.psfhosted.org>
Message-ID: <1645569263.17.0.317317353427.issue45459@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

pmp-p:
> There's some side effects with "buffer.h" inclusion in Panda3D when building againt 3.11a5, project manager concerns are here https://github.com/python/cpython/pull/29991#issuecomment-1031731100

Thanks for the report. It has been fixed. I close again the issue.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45459>
_______________________________________

From report at bugs.python.org  Tue Feb 22 17:49:41 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 22 Feb 2022 22:49:41 +0000
Subject: [issue46829] Confusing CancelError message if multiple cancellations
 are scheduled
In-Reply-To: <1645567371.24.0.086924022035.issue46829@roundup.psfhosted.org>
Message-ID: <1645570181.97.0.513986009384.issue46829@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

What about `CancelledError(*msg_list)` or `CancelledError(*reversed(msg_list))`? It is backward compatible and all messages are uniformely represented.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46829>
_______________________________________

From report at bugs.python.org  Tue Feb 22 17:58:10 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 22 Feb 2022 22:58:10 +0000
Subject: [issue44886] asyncio: create_datagram_endpoint() does not return a
 DatagramTransport
In-Reply-To: <1628671129.22.0.924495128156.issue44886@roundup.psfhosted.org>
Message-ID: <1645570690.52.0.811564645374.issue44886@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
keywords: +patch
pull_requests: +29639
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31512

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44886>
_______________________________________

From report at bugs.python.org  Tue Feb 22 17:58:40 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 22 Feb 2022 22:58:40 +0000
Subject: [issue44886] asyncio: create_datagram_endpoint() does not return a
 DatagramTransport
In-Reply-To: <1628671129.22.0.924495128156.issue44886@roundup.psfhosted.org>
Message-ID: <1645570720.93.0.738355919414.issue44886@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
versions: +Python 3.10, Python 3.11 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44886>
_______________________________________

From report at bugs.python.org  Tue Feb 22 17:59:31 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 22 Feb 2022 22:59:31 +0000
Subject: [issue44886] asyncio: create_datagram_endpoint() does not return a
 DatagramTransport
In-Reply-To: <1628671129.22.0.924495128156.issue44886@roundup.psfhosted.org>
Message-ID: <1645570771.83.0.869023502942.issue44886@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
assignee:  -> asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44886>
_______________________________________

From report at bugs.python.org  Tue Feb 22 18:00:18 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 22 Feb 2022 23:00:18 +0000
Subject: [issue45883] reuse_address mistakenly removed from loop.create_server
In-Reply-To: <1637694476.84.0.389312565282.issue45883@roundup.psfhosted.org>
Message-ID: <1645570818.97.0.609728007923.issue45883@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/issue45883>
_______________________________________

From report at bugs.python.org  Tue Feb 22 18:03:59 2022
From: report at bugs.python.org (Vidhya)
Date: Tue, 22 Feb 2022 23:03:59 +0000
Subject: [issue31327] [doc] Add example of platform-specific support for
 negative timestamps to the time doc
In-Reply-To: <1504286649.82.0.482783873664.issue31327@psf.upfronthosting.co.za>
Message-ID: <1645571039.85.0.623484016002.issue31327@roundup.psfhosted.org>


Vidhya <vidhya.friend at gmail.com> added the comment:

[Entry level contributor seeking guidance]If this is not yet fixed, I can work on this. Please let me know.

----------
nosy: +vidhya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31327>
_______________________________________

From report at bugs.python.org  Tue Feb 22 18:05:27 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 22 Feb 2022 23:05:27 +0000
Subject: [issue46829] Confusing CancelError message if multiple cancellations
 are scheduled
In-Reply-To: <1645567371.24.0.086924022035.issue46829@roundup.psfhosted.org>
Message-ID: <1645571127.67.0.322667535888.issue46829@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

I would like to go on record (again) as preferring to get rid of the cancel-message parameter altogether. Let's deprecate it. When we initially designed things without a cancel message we did it on purpose -- "cancellation" is a single flag, not a collection of data.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46829>
_______________________________________

From report at bugs.python.org  Tue Feb 22 18:07:28 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 22 Feb 2022 23:07:28 +0000
Subject: [issue43119] asyncio.Queue.put never yields if the queue is unbounded
In-Reply-To: <1612381282.49.0.371079618361.issue43119@roundup.psfhosted.org>
Message-ID: <1645571248.16.0.995047013748.issue43119@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Sorry, that's how asyncio works: it never switches to another task if `await ...` doesn't need to wait for something actually.

Adding `await asyncio.sleep(0)` to every call decreases performance.

----------
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43119>
_______________________________________

From report at bugs.python.org  Tue Feb 22 18:29:24 2022
From: report at bugs.python.org (=?utf-8?q?Tin_Tvrtkovi=C4=87?=)
Date: Tue, 22 Feb 2022 23:29:24 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645572564.35.0.685732169413.issue46771@roundup.psfhosted.org>


Change by Tin Tvrtkovi? <tinchester at gmail.com>:


----------
pull_requests: +29640
pull_request: https://github.com/python/cpython/pull/31513

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Tue Feb 22 18:38:05 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 22 Feb 2022 23:38:05 +0000
Subject: [issue46829] Confusing CancelError message if multiple cancellations
 are scheduled
In-Reply-To: <1645567371.24.0.086924022035.issue46829@roundup.psfhosted.org>
Message-ID: <1645573085.25.0.271733210578.issue46829@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Deprecation is a good answer. 
Let's not forget to apply it to 3.11 then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46829>
_______________________________________

From report at bugs.python.org  Tue Feb 22 18:40:33 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 22 Feb 2022 23:40:33 +0000
Subject: [issue44886] asyncio: create_datagram_endpoint() does not return a
 DatagramTransport
In-Reply-To: <1628671129.22.0.924495128156.issue44886@roundup.psfhosted.org>
Message-ID: <1645573233.45.0.166258311061.issue44886@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: +29641
pull_request: https://github.com/python/cpython/pull/31514

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44886>
_______________________________________

From report at bugs.python.org  Tue Feb 22 18:41:11 2022
From: report at bugs.python.org (miss-islington)
Date: Tue, 22 Feb 2022 23:41:11 +0000
Subject: [issue44886] asyncio: create_datagram_endpoint() does not return a
 DatagramTransport
In-Reply-To: <1628671129.22.0.924495128156.issue44886@roundup.psfhosted.org>
Message-ID: <1645573271.48.0.927823033887.issue44886@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29642
pull_request: https://github.com/python/cpython/pull/31515

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44886>
_______________________________________

From report at bugs.python.org  Tue Feb 22 18:50:06 2022
From: report at bugs.python.org (Socob)
Date: Tue, 22 Feb 2022 23:50:06 +0000
Subject: [issue40358] pathlib's relative_to should behave like os.path.relpath
In-Reply-To: <1587513783.17.0.6950267733.issue40358@roundup.psfhosted.org>
Message-ID: <1645573806.36.0.416145284046.issue40358@roundup.psfhosted.org>


Change by Socob <206a8535 at opayq.com>:


----------
nosy: +Socob

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40358>
_______________________________________

From report at bugs.python.org  Tue Feb 22 18:52:02 2022
From: report at bugs.python.org (Socob)
Date: Tue, 22 Feb 2022 23:52:02 +0000
Subject: [issue42234] pathlib relative_to behaviour change
In-Reply-To: <1604245703.4.0.361207259352.issue42234@roundup.psfhosted.org>
Message-ID: <1645573922.78.0.278730712255.issue42234@roundup.psfhosted.org>


Change by Socob <206a8535 at opayq.com>:


----------
nosy: +Socob

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42234>
_______________________________________

From report at bugs.python.org  Tue Feb 22 18:52:20 2022
From: report at bugs.python.org (Socob)
Date: Tue, 22 Feb 2022 23:52:20 +0000
Subject: [issue44078] Output relative path when using PurePath.relative_to
In-Reply-To: <1620488591.33.0.62171873486.issue44078@roundup.psfhosted.org>
Message-ID: <1645573940.22.0.149838808218.issue44078@roundup.psfhosted.org>


Change by Socob <206a8535 at opayq.com>:


----------
nosy: +Socob

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44078>
_______________________________________

From report at bugs.python.org  Tue Feb 22 18:57:02 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 22 Feb 2022 23:57:02 +0000
Subject: [issue40358] pathlib's relative_to should behave like os.path.relpath
In-Reply-To: <1587513783.17.0.6950267733.issue40358@roundup.psfhosted.org>
Message-ID: <1645574222.78.0.452494569862.issue40358@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy:  -terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40358>
_______________________________________

From report at bugs.python.org  Tue Feb 22 18:57:25 2022
From: report at bugs.python.org (Brandt Bucher)
Date: Tue, 22 Feb 2022 23:57:25 +0000
Subject: [issue45885] Specialize COMPARE_OP
In-Reply-To: <1637701224.16.0.881347004039.issue45885@roundup.psfhosted.org>
Message-ID: <1645574245.99.0.861614922362.issue45885@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
nosy: +brandtbucher
nosy_count: 2.0 -> 3.0
pull_requests: +29643
pull_request: https://github.com/python/cpython/pull/31516

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45885>
_______________________________________

From report at bugs.python.org  Tue Feb 22 19:24:19 2022
From: report at bugs.python.org (Eric Snow)
Date: Wed, 23 Feb 2022 00:24:19 +0000
Subject: [issue46765] Replace Locally Cached Strings with Statically
 Initialized Objects
In-Reply-To: <1644981402.43.0.406024734296.issue46765@roundup.psfhosted.org>
Message-ID: <1645575859.4.0.306415317306.issue46765@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:


New changeset 1f455361ecfb1892e375bdbee813cdf095b6cfb8 by Eric Snow in branch 'main':
bpo-46765: Replace Locally Cached Strings with Statically Initialized Objects (gh-31366)
https://github.com/python/cpython/commit/1f455361ecfb1892e375bdbee813cdf095b6cfb8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46765>
_______________________________________

From report at bugs.python.org  Tue Feb 22 19:25:04 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 23 Feb 2022 00:25:04 +0000
Subject: [issue46522] concurrent.futures.__getattr__ raises the wrong
 AttributeError message
In-Reply-To: <1643123783.64.0.215214582085.issue46522@roundup.psfhosted.org>
Message-ID: <1645575904.81.0.495941824005.issue46522@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset 9b12b1b803d7b73640ab637a74a6f35f3fe9db21 by Thomas Grainger in branch 'main':
bpo-46522: fix concurrent.futures and io AttributeError messages (GH-30887)
https://github.com/python/cpython/commit/9b12b1b803d7b73640ab637a74a6f35f3fe9db21


----------
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46522>
_______________________________________

From report at bugs.python.org  Tue Feb 22 19:25:23 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 23 Feb 2022 00:25:23 +0000
Subject: [issue46522] concurrent.futures.__getattr__ raises the wrong
 AttributeError message
In-Reply-To: <1643123783.64.0.215214582085.issue46522@roundup.psfhosted.org>
Message-ID: <1645575923.29.0.257385713969.issue46522@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
versions:  -Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46522>
_______________________________________

From report at bugs.python.org  Tue Feb 22 19:25:32 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 23 Feb 2022 00:25:32 +0000
Subject: [issue46522] concurrent.futures.__getattr__ raises the wrong
 AttributeError message
In-Reply-To: <1643123783.64.0.215214582085.issue46522@roundup.psfhosted.org>
Message-ID: <1645575932.65.0.476381300227.issue46522@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46522>
_______________________________________

From report at bugs.python.org  Tue Feb 22 19:32:01 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 23 Feb 2022 00:32:01 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645576321.61.0.0171637898842.issue46771@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

If some code is used together with timeout() and this code calls `.cancel()` but forgot about `.uncancel()` in try/except/finally -- timeout() never raises TimeoutError.

Should we care? The missing `.uncancel()` call is hard to detect by the runtime and static checkers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Tue Feb 22 19:55:59 2022
From: report at bugs.python.org (Jeff Cagle)
Date: Wed, 23 Feb 2022 00:55:59 +0000
Subject: [issue46830] Add Find functionality to Squeezed Text viewer
Message-ID: <1645577759.96.0.0764946040694.issue46830@roundup.psfhosted.org>


New submission from Jeff Cagle <jeffreyrcagle at gmail.com>:

Squeezed text output currently opens in a viewer whose only functionality is scrolling.  Adding the Find widget a la IDLE would make the viewer much more useful.

----------
assignee: terry.reedy
components: IDLE
messages: 413761
nosy: Jeff.Cagle, terry.reedy
priority: normal
severity: normal
status: open
title: Add Find functionality to Squeezed Text viewer
type: enhancement
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46830>
_______________________________________

From report at bugs.python.org  Tue Feb 22 20:23:06 2022
From: report at bugs.python.org (Brandt Bucher)
Date: Wed, 23 Feb 2022 01:23:06 +0000
Subject: [issue44337] Port LOAD_ATTR to adaptive interpreter
In-Reply-To: <1623089020.4.0.120322851148.issue44337@roundup.psfhosted.org>
Message-ID: <1645579386.07.0.627851493225.issue44337@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
nosy: +brandtbucher
nosy_count: 3.0 -> 4.0
pull_requests: +29644
pull_request: https://github.com/python/cpython/pull/31517

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44337>
_______________________________________

From report at bugs.python.org  Tue Feb 22 20:40:37 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 23 Feb 2022 01:40:37 +0000
Subject: [issue46794] Please update bundled libexpat to 2.4.6 with security
 fixes (5 CVEs)
In-Reply-To: <1645227388.68.0.727345462152.issue46794@roundup.psfhosted.org>
Message-ID: <1645580437.84.0.694704325576.issue46794@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: +29645
pull_request: https://github.com/python/cpython/pull/31518

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46794>
_______________________________________

From report at bugs.python.org  Tue Feb 22 20:40:41 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 23 Feb 2022 01:40:41 +0000
Subject: [issue46794] Please update bundled libexpat to 2.4.6 with security
 fixes (5 CVEs)
In-Reply-To: <1645227388.68.0.727345462152.issue46794@roundup.psfhosted.org>
Message-ID: <1645580441.96.0.89319521301.issue46794@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29646
pull_request: https://github.com/python/cpython/pull/31519

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46794>
_______________________________________

From report at bugs.python.org  Tue Feb 22 20:40:45 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 23 Feb 2022 01:40:45 +0000
Subject: [issue46794] Please update bundled libexpat to 2.4.6 with security
 fixes (5 CVEs)
In-Reply-To: <1645227388.68.0.727345462152.issue46794@roundup.psfhosted.org>
Message-ID: <1645580445.91.0.0299351378098.issue46794@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:


New changeset 1935e1cc284942bec8006287c939e295e1a7bf13 by Dong-hee Na in branch 'main':
bpo-46794: Bump up the libexpat version into 2.4.6 (GH-31487)
https://github.com/python/cpython/commit/1935e1cc284942bec8006287c939e295e1a7bf13


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46794>
_______________________________________

From report at bugs.python.org  Tue Feb 22 20:40:46 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 23 Feb 2022 01:40:46 +0000
Subject: [issue46794] Please update bundled libexpat to 2.4.6 with security
 fixes (5 CVEs)
In-Reply-To: <1645227388.68.0.727345462152.issue46794@roundup.psfhosted.org>
Message-ID: <1645580446.48.0.563932768279.issue46794@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29647
pull_request: https://github.com/python/cpython/pull/31520

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46794>
_______________________________________

From report at bugs.python.org  Tue Feb 22 20:40:50 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 23 Feb 2022 01:40:50 +0000
Subject: [issue46794] Please update bundled libexpat to 2.4.6 with security
 fixes (5 CVEs)
In-Reply-To: <1645227388.68.0.727345462152.issue46794@roundup.psfhosted.org>
Message-ID: <1645580450.36.0.340874756599.issue46794@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29648
pull_request: https://github.com/python/cpython/pull/31521

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46794>
_______________________________________

From report at bugs.python.org  Tue Feb 22 20:41:08 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 23 Feb 2022 01:41:08 +0000
Subject: [issue46828] math.prod can return integers (contradicts doc)
In-Reply-To: <1645556673.97.0.708040802519.issue46828@roundup.psfhosted.org>
Message-ID: <1645580468.49.0.834302744406.issue46828@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I'll add a note that the output type is determined by the input type.

----------
assignee: docs at python -> rhettinger
nosy: +rhettinger
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46828>
_______________________________________

From report at bugs.python.org  Tue Feb 22 20:54:42 2022
From: report at bugs.python.org (Eric Snow)
Date: Wed, 23 Feb 2022 01:54:42 +0000
Subject: [issue46765] Replace Locally Cached Strings with Statically
 Initialized Objects
In-Reply-To: <1644981402.43.0.406024734296.issue46765@roundup.psfhosted.org>
Message-ID: <1645581282.57.0.134279196606.issue46765@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46765>
_______________________________________

From report at bugs.python.org  Tue Feb 22 21:43:26 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 23 Feb 2022 02:43:26 +0000
Subject: [issue46622] Add a async variant of lru_cache for coroutines.
In-Reply-To: <1643873308.65.0.92890586202.issue46622@roundup.psfhosted.org>
Message-ID: <1645584206.95.0.603702014713.issue46622@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

If this goes forward, my strong preference is to have a separate async_lru() function  just like the referenced external project.

For non-async uses, overloading the current lru_cache makes it confusing to reason about. It becomes harder to describe clearly what the caches do or to show a pure python equivalent.  People are already challenged to digest the current capabilities and are already finding it difficult to reason about when references are held.  I don't want to add complexity, expand the docs to be more voluminous, cover the new corner cases, and add examples that don't make sense to non-async users (i.e. the vast majority of python users).  Nor do I want to update the recipes for lru_cache variants to all be async aware.  So, please keep this separate (it is okay to share some of the underlying implementation, but the APIs should be distinct).

Also as a matter of fair and equitable policy, I am concerned about taking the core of a popular external project and putting in the standard library.  That would tend to kill the external project, either stealing all its users or leaving it as something that only offers a few incremental features above those in the standard library.  That is profoundly unfair to the people who created, maintained, and promoted the project.

Various SC members periodically voice a desire to move functionality *out* of the standard library and into PyPI rather than the reverse.  If a popular external package is meeting needs, perhaps it should be left alone.

As noted by the other respondants, caching sync and async iterators/generators is venturing out on thin ice.  Even if it could be done reliably (which is dubious), it is likely to be bug bait for users.  Remember, we already get people who try to cache time(), random() or other impure functions.  They cache methods and cannot understand why references is held for the instance.  Assuredly, coroutines and futures will encounter even more misunderstandings. 

Also, automatic reiterability is can of worms and would likely require a PEP. Every time subject has come up before, we've decided not to go there.  Let's not make a tool that makes user's lives worse.  Not everything should be cached.  Even if we can, it doesn't mean we should.

----------
title: Support  decorating a coroutine with functools.lru_cache -> Add a async variant of lru_cache for coroutines.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46622>
_______________________________________

From report at bugs.python.org  Tue Feb 22 21:50:44 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 23 Feb 2022 02:50:44 +0000
Subject: [issue46794] Please update bundled libexpat to 2.4.6 with security
 fixes (5 CVEs)
In-Reply-To: <1645227388.68.0.727345462152.issue46794@roundup.psfhosted.org>
Message-ID: <1645584644.65.0.406805868454.issue46794@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 4955a9ed14c681ed835bc8902a9db0bcc728bdee by Miss Islington (bot) in branch '3.10':
bpo-46794: Bump up the libexpat version into 2.4.6 (GH-31487)
https://github.com/python/cpython/commit/4955a9ed14c681ed835bc8902a9db0bcc728bdee


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46794>
_______________________________________

From report at bugs.python.org  Tue Feb 22 21:51:08 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 23 Feb 2022 02:51:08 +0000
Subject: [issue46794] Please update bundled libexpat to 2.4.6 with security
 fixes (5 CVEs)
In-Reply-To: <1645227388.68.0.727345462152.issue46794@roundup.psfhosted.org>
Message-ID: <1645584668.12.0.997063302052.issue46794@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 87cebb1e69758aa8b79f8e15187b976d62cba36a by Miss Islington (bot) in branch '3.9':
bpo-46794: Bump up the libexpat version into 2.4.6 (GH-31487)
https://github.com/python/cpython/commit/87cebb1e69758aa8b79f8e15187b976d62cba36a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46794>
_______________________________________

From report at bugs.python.org  Tue Feb 22 21:52:33 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 23 Feb 2022 02:52:33 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645584753.27.0.706374088427.issue46771@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

> If some code is used together with timeout() and this code calls
> `.cancel()` but forgot about `.uncancel()` in try/except/finally --
> timeout() never raises TimeoutError.

Could you show an example? I'm not sure from this description who cancels whom and where the try/except/finally is in relation to the rest.

If you have something that catches CancelledError and then ignores it, e.g.

while True:
    try:
        await <something>
    except CancelledError:
        pass

then that's an immortal task and it shouldn't be run inside a timeout.

If you have something that catches CancelledError once, e.g.

try:
    await <big action>
finally:
    await <cleanup>

there should be no need to call .uncancel() *unless* the <cleanup> may hang -- in that case you could write

try:
    await <big action>
finally:
    async with timeout(5):
        await <cleanup>

I'm not sure that we should recommend using .uncancel() except in very special cases (e.g. when writing a timeout() context manager :-) and those cases should just be tested.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Tue Feb 22 22:11:28 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 23 Feb 2022 03:11:28 +0000
Subject: [issue46622] Add an async variant of lru_cache for coroutines.
In-Reply-To: <1643873308.65.0.92890586202.issue46622@roundup.psfhosted.org>
Message-ID: <1645585888.92.0.773533091264.issue46622@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
title: Add a async variant of lru_cache for coroutines. -> Add an async variant of lru_cache for coroutines.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46622>
_______________________________________

From report at bugs.python.org  Tue Feb 22 22:31:57 2022
From: report at bugs.python.org (Shantanu)
Date: Wed, 23 Feb 2022 03:31:57 +0000
Subject: [issue46831] Outdated comment for __build_class__ in compile.c
Message-ID: <1645587117.9.0.320928426769.issue46831@roundup.psfhosted.org>


New submission from Shantanu <hauntsaninja at gmail.com>:

https://github.com/python/cpython/blob/cf345e945f48f54785799390c2e92c5310847bd4/Python/compile.c#L2537
```
    /* ultimately generate code for:
         <name> = __build_class__(<func>, <name>, *<bases>, **<keywords>)
       where:
         <func> is a function/closure created from the class body;
            it has a single argument (__locals__) where the dict
            (or MutableSequence) representing the locals is passed
```

`func` currently takes zero arguments. This was changed in https://github.com/python/cpython/commit/e8e14591ebb729b4fa19626ce245fa0811cf6f32 in Python 3.4

----------
assignee: docs at python
components: Documentation
messages: 413768
nosy: docs at python, hauntsaninja
priority: normal
severity: normal
status: open
title: Outdated comment for __build_class__ in compile.c

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46831>
_______________________________________

From report at bugs.python.org  Tue Feb 22 22:32:46 2022
From: report at bugs.python.org (Shantanu)
Date: Wed, 23 Feb 2022 03:32:46 +0000
Subject: [issue46831] Outdated comment for __build_class__ in compile.c
In-Reply-To: <1645587117.9.0.320928426769.issue46831@roundup.psfhosted.org>
Message-ID: <1645587166.57.0.882758678097.issue46831@roundup.psfhosted.org>


Change by Shantanu <hauntsaninja at gmail.com>:


----------
keywords: +patch
pull_requests: +29649
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31522

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46831>
_______________________________________

From report at bugs.python.org  Tue Feb 22 23:08:28 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 23 Feb 2022 04:08:28 +0000
Subject: [issue46830] Add Find functionality to Squeezed Text viewer
In-Reply-To: <1645577759.96.0.0764946040694.issue46830@roundup.psfhosted.org>
Message-ID: <1645589308.21.0.334144089549.issue46830@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> IDLE: Add search to textview.ViewWindow

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46830>
_______________________________________

From report at bugs.python.org  Tue Feb 22 23:09:44 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 23 Feb 2022 04:09:44 +0000
Subject: [issue36595] IDLE: Add search to textview.ViewWindow
In-Reply-To: <1554941521.08.0.779423976753.issue36595@roundup.psfhosted.org>
Message-ID: <1645589384.05.0.611119594675.issue36595@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

#46830 is a duplicate request.

----------
versions: +Python 3.11 -Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36595>
_______________________________________

From report at bugs.python.org  Tue Feb 22 23:33:21 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 23 Feb 2022 04:33:21 +0000
Subject: [issue46757] dataclasses should define an empty __post_init__
In-Reply-To: <1644923607.6.0.495534870715.issue46757@roundup.psfhosted.org>
Message-ID: <1645590801.89.0.758660353765.issue46757@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
pull_requests: +29650
pull_request: https://github.com/python/cpython/pull/31523

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46757>
_______________________________________

From report at bugs.python.org  Tue Feb 22 23:36:11 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 23 Feb 2022 04:36:11 +0000
Subject: [issue46757] dataclasses should define an empty __post_init__
In-Reply-To: <1644923607.6.0.495534870715.issue46757@roundup.psfhosted.org>
Message-ID: <1645590971.58.0.586956437613.issue46757@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I'm adding a test that mimic's Raymond's example of the proposed addition being a breaking change. This way, if we ever decide to actually add this feature, we'll break this test. If we do decide to continue and make the change anyway, at least we'll do so with the knowledge that it's a breaking change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46757>
_______________________________________

From report at bugs.python.org  Wed Feb 23 00:14:43 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 23 Feb 2022 05:14:43 +0000
Subject: [issue46757] dataclasses should define an empty __post_init__
In-Reply-To: <1644923607.6.0.495534870715.issue46757@roundup.psfhosted.org>
Message-ID: <1645593283.03.0.0383216052458.issue46757@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:


New changeset 288af845a32fd2a92e3b49738faf8f2de6a7bf7c by Eric V. Smith in branch 'main':
bpo-46757: Add a test to verify dataclass's __post_init__ isn't being automatically added. (GH-31523)
https://github.com/python/cpython/commit/288af845a32fd2a92e3b49738faf8f2de6a7bf7c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46757>
_______________________________________

From report at bugs.python.org  Wed Feb 23 00:30:12 2022
From: report at bugs.python.org (aklajnert)
Date: Wed, 23 Feb 2022 05:30:12 +0000
Subject: [issue46806] Overlapping PYTHONPATH may cause import already imported
 module
In-Reply-To: <1645360487.42.0.278270431314.issue46806@roundup.psfhosted.org>
Message-ID: <1645594212.16.0.811498094789.issue46806@roundup.psfhosted.org>


aklajnert <python at aklajnert.pl> added the comment:

I agree that adding a package directory to PYTHONPATH is not a good idea, however, I've stumbled on it in two completely independent companies' codebases. So it makes me suspect that this is may not be that rare case.

In the previous company we got bitten by this problem, and debugging took quite some time as this issue usually doesn't reveal immediately.

If the relative path is resolved to the same module as not relative, then the behavior when the same file's path but referenced in a slightly different way isn't seems at least inconsistent. Note that the absolute path to the module is exactly the same, the only thing that is different is how you reference it.

I'm happy to make an attempt to fix it if it gets acknowledged as a bug (a little guidance would be also helpful).

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46806>
_______________________________________

From report at bugs.python.org  Wed Feb 23 00:45:43 2022
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 23 Feb 2022 05:45:43 +0000
Subject: [issue45459] Limited API support for Py_buffer
In-Reply-To: <1634118913.79.0.141868262007.issue45459@roundup.psfhosted.org>
Message-ID: <1645595143.3.0.534033510922.issue45459@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:

clang doesn't like the typedef forward-decl:

In file included from ../cpython/Modules/_ctypes/_ctypes.c:108:
In file included from ../cpython/Include/Python.h:43:
../cpython/Include/object.h:109:3: warning: redefinition of typedef 'PyObject' is a C11 feature [-Wtypedef-redefinition]
} PyObject;
  ^
../cpython/Include/pybuffer.h:23:24: note: previous definition is here
typedef struct _object PyObject;
                       ^
1 warning generated.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45459>
_______________________________________

From report at bugs.python.org  Wed Feb 23 01:12:09 2022
From: report at bugs.python.org (Artyom Polkovnikov)
Date: Wed, 23 Feb 2022 06:12:09 +0000
Subject: [issue46832] unicodeobject.c doesn't compile when defined
 EXPERIMENTAL_ISOLATED_SUBINTERPRETERS, variable "interned" not found
Message-ID: <1645596729.1.0.194216196654.issue46832@roundup.psfhosted.org>


New submission from Artyom Polkovnikov <artyom.polkovnikov at gmail.com>:

1) Downloaded https://www.python.org/ftp/python/3.10.2/Python-3.10.2.tar.xz

2) Compiled under MSVC 2019 with define EXPERIMENTAL_ISOLATED_SUBINTERPRETERS

3) Got compilation error of file Objects/unicodeobject.c at line 15931, about undefined variable "interned", it is function _PyUnicode_ClearInterned(), uncompilable code is "if (interned == NULL) {".


This happens because when EXPERIMENTAL_ISOLATED_SUBINTERPRETERS is defined then INTERNED_STRINGS is undefined hence global variable "static PyObject *interned = NULL;" is not created, and _PyUnicode_ClearInterned() uses this global variable "interned".

For reference attaching my version of "unicodeobject.c" which has compilation error at line 15931.

----------
components: Subinterpreters
files: unicodeobject.c
messages: 413774
nosy: artyom.polkovnikov
priority: normal
severity: normal
status: open
title: unicodeobject.c doesn't compile when defined EXPERIMENTAL_ISOLATED_SUBINTERPRETERS, variable "interned" not found
type: compile error
versions: Python 3.10
Added file: https://bugs.python.org/file50637/unicodeobject.c

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46832>
_______________________________________

From report at bugs.python.org  Wed Feb 23 01:24:18 2022
From: report at bugs.python.org (Neil Girdhar)
Date: Wed, 23 Feb 2022 06:24:18 +0000
Subject: [issue46757] dataclasses should define an empty __post_init__
In-Reply-To: <1644923607.6.0.495534870715.issue46757@roundup.psfhosted.org>
Message-ID: <1645597458.71.0.998538798784.issue46757@roundup.psfhosted.org>


Neil Girdhar <mistersheik at gmail.com> added the comment:

@eric

Good thinking.  Would it make sense to add to the documentation as well that the __post_init__ methods aren't collected, and you should call super's __post_init__ if there is one using something like

        if hasattr(super(), "__post_init__"):
            super().__post_init__()

Noting this will make it easier to point to the docs if someone wonders when they see code like this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46757>
_______________________________________

From report at bugs.python.org  Wed Feb 23 02:16:05 2022
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 23 Feb 2022 07:16:05 +0000
Subject: [issue46829] Confusing CancelError message if multiple cancellations
 are scheduled
In-Reply-To: <1645567371.24.0.086924022035.issue46829@roundup.psfhosted.org>
Message-ID: <1645600565.88.0.329412621576.issue46829@roundup.psfhosted.org>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

I don't really understand all the hate around the idea of a cancel message. One reason it's useful is that it provides a simple way to say *why* something is being cancelled or *what* is cancelling it. It provides additional context to the exception, in the same way that a normal exception's message can provide additional helpful context.

Take for example this chunk of code:

import asyncio
import random

async def job():
    await asyncio.sleep(5)

async def main():
    task = asyncio.create_task(job())
    await asyncio.sleep(1)
    r = random.random()
    if r < 0.5:
        task.cancel()
    else:
        task.cancel()
    await task

if __name__=="__main__":
    asyncio.run(main())

Without passing a message, there's no way to tell which of the two lines called cancel, or why. The tracebacks are identical in both cases. This is even in the simplest case where only one cancellation is occurring. Passing a message lets one disambiguate the two call sites. And if there is truly a race condition where it's up in the air between two things cancelling it, I think it would be okay for the chosen message to be indeterminate, as either would have instigated the cancel in the absence of the other.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46829>
_______________________________________

From report at bugs.python.org  Wed Feb 23 03:22:08 2022
From: report at bugs.python.org (Christian Buhtz)
Date: Wed, 23 Feb 2022 08:22:08 +0000
Subject: [issue46833] Installer Wizard is unclear and has redundant settings
Message-ID: <1645604528.5.0.846357801282.issue46833@roundup.psfhosted.org>


New submission from Christian Buhtz <c.buhtz at posteo.jp>:

Hello together,
this is is about the installer of Python 3.9.10 on Windows 10 64bit.

I have problems to interpret the installer wizard/dialog. And my argument is that no matter if there are good reasons for the current options some of the users are confused by it.

The goal should be to make the installer more clear about what this options do.

Lets see the "Install for all users" option:
 This appears on all three pages.
 I am not sure but would say that the first two options are related to the py-launcher not the the python interpreter itself. OK, but why two options?
 The third option is for the interpreter?
 And I do not see an advantage in making a difference between launcher and interpreter for that option.

Lets see about PATH/environment variables:
 This appears on the first page ("Add Python 3.9 to PATH") and on the third page ("Add Python to environment variables").
 I do not understand why.

And all this options are not synchronized. It means when I Enable "Add Python 3.9 to Path" on the first page the "Add Python to environment variables" on the third page is not updated (enabled) also.

Again:
I am sure there are very good reasons for this separated options. But the wizard should make this reason clear to the user (or her/his admins) so that she/he can make an well informed decision.

----------
components: Installation, Windows
files: python3_9_10_install_wizard_page1-3.png
messages: 413777
nosy: buhtz, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Installer Wizard is unclear and has redundant settings
versions: Python 3.9
Added file: https://bugs.python.org/file50638/python3_9_10_install_wizard_page1-3.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46833>
_______________________________________

From report at bugs.python.org  Wed Feb 23 03:53:26 2022
From: report at bugs.python.org (Ofey Chan)
Date: Wed, 23 Feb 2022 08:53:26 +0000
Subject: [issue46761] functools.update_wrapper breaks the signature of
 functools.partial objects
In-Reply-To: <1644948374.87.0.765462873315.issue46761@roundup.psfhosted.org>
Message-ID: <1645606406.53.0.110614326369.issue46761@roundup.psfhosted.org>


Ofey Chan <ofey206 at gmail.com> added the comment:

Hello, I am new to cpython project and want to help.

I dig into `follow_wrapper_chains` feature and found it really interesting.

In `inspect.signature()`, the conversion of `functools.partial` object's signature is made when going down the unwrap chain.

Relevant code: https://github.com/python/cpython/blob/288af845a32fd2a92e3b49738faf8f2de6a7bf7c/Lib/inspect.py#L2467

So, there is an inconsistent assumption which cause the problem:

- `inspect.signature()` handle `functools.partial` object it met specially.
- `functools.update_wrapper()` just treat `functools.partial` object as a normal decorator and ignore it.
  
After calling `functools.update_wrapper()`, a new (wrong) signature is constructed, and it covers the original (right) process.

That's why `inspect.signature()` returns the *original* function's signature, not the *wrapped* function's signature.

In my humble opinion, A sane solution might be that: let the `functools.update_wrapper` respect the `functools.partial` object in the similar way of `inspect.signature()`.

I'm working on a pull request to express my idea more clearly, any help is welcome!

----------
nosy: +ofey404

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46761>
_______________________________________

From report at bugs.python.org  Wed Feb 23 04:20:59 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 23 Feb 2022 09:20:59 +0000
Subject: [issue45390] asyncio.Task doesn't propagate CancelledError()
 exception correctly.
In-Reply-To: <1633519842.27.0.396754460358.issue45390@roundup.psfhosted.org>
Message-ID: <1645608059.58.0.646848313473.issue45390@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Seems a CancelledError message can be lost also in Condition.wait().

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45390>
_______________________________________

From report at bugs.python.org  Wed Feb 23 04:51:57 2022
From: report at bugs.python.org (padremayi)
Date: Wed, 23 Feb 2022 09:51:57 +0000
Subject: [issue46798] xml.etree.ElementTree: get() doesn't return default
 value, always ATTLIST value
In-Reply-To: <1645270291.57.0.995603390679.issue46798@roundup.psfhosted.org>
Message-ID: <1645609917.55.0.510442917836.issue46798@roundup.psfhosted.org>


padremayi <francesco.other at gmail.com> added the comment:

IMHO if the developer doesn't manage the XML itself it is VERY unreasonable to use the document value and not the developer one. At the moment the developer must predict the future changes on XML structure.

For my point of view if an attribute is not present get() must return None (or the default value passed by developer) AND the document default adding an optional parameter to get() call: if True return 2 values, otherwise return the document one (current behaviour).

In this way the old code continue to work

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46798>
_______________________________________

From report at bugs.python.org  Wed Feb 23 04:53:43 2022
From: report at bugs.python.org (padremayi)
Date: Wed, 23 Feb 2022 09:53:43 +0000
Subject: [issue46798] xml.etree.ElementTree: get() doesn't return default
 value, always ATTLIST value
In-Reply-To: <1645270291.57.0.995603390679.issue46798@roundup.psfhosted.org>
Message-ID: <1645610023.78.0.916817495583.issue46798@roundup.psfhosted.org>


Change by padremayi <francesco.other at gmail.com>:


----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46798>
_______________________________________

From report at bugs.python.org  Wed Feb 23 05:03:17 2022
From: report at bugs.python.org (Min RK)
Date: Wed, 23 Feb 2022 10:03:17 +0000
Subject: [issue26832] ProactorEventLoop doesn't support stdin/stdout nor files
 with connect_read_pipe/connect_write_pipe
In-Reply-To: <1461383150.45.0.258316694453.issue26832@psf.upfronthosting.co.za>
Message-ID: <1645610597.2.0.667849546302.issue26832@roundup.psfhosted.org>


Min RK <benjaminrk at gmail.com> added the comment:

It appears that connect_read_pipe also doesn't accept pipes returned by `os.pipe`. If that's the case, what _does_ ProactorEventLoop.connect_read_pipe accept? I haven't been able to find any examples of `connect_read_pipe` that work on Windows, and every connect_read_pipe call in the cpython test suite appears to be skipped on win32. Should it still be raising NotImplementedError on ProactorEventLoop?

I think the error handling could be better (I only get logged errors, nothing I can catch/handle). It seems like `connect_read_pipe` itself should raise when it fails to register the pipe with IOCP. If that's not feasible, connection_lost/transport.close should probably be triggered, but it isn't with Python 3.9, at least.

Example that works on posix, but seems to fail with non-catchable errors with ProactorEventLoop:

```
import asyncio
import os
import sys

class PipeProtocol(asyncio.Protocol):
    def __init__(self):
        self.finished = asyncio.Future()

    def connection_made(self, transport):
        print("connection made", file=sys.stderr)
        self.transport = transport

    def connection_lost(self, exc):
        print("connection lost", exc, file=sys.stderr)
        self.finished.set_result(None)

    def data_received(self, data):
        print("data received", data, file=sys.stderr)
        self.handler(data)

    def eof_received(self):
        print("eof received", file=sys.stderr)
        self.finished.set_result(None)

async def test():
    r, w = os.pipe()
    rf = os.fdopen(r, 'r')
    x, p = await asyncio.get_running_loop().connect_read_pipe(PipeProtocol, rf)
    await asyncio.sleep(1)
    print("writing")
    os.write(w, b'asdf')
    await asyncio.sleep(2)
    print("closing")
    os.close(w)
    await asyncio.wait([p.finished], timeout=3)
    x.close()

if __name__ == "__main__":
    asyncio.run(test())
```

----------
nosy: +minrk
versions: +Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26832>
_______________________________________

From report at bugs.python.org  Wed Feb 23 05:34:17 2022
From: report at bugs.python.org (padremayi)
Date: Wed, 23 Feb 2022 10:34:17 +0000
Subject: [issue46798] xml.etree.ElementTree: get() doesn't return default
 value, always ATTLIST value
In-Reply-To: <1645270291.57.0.995603390679.issue46798@roundup.psfhosted.org>
Message-ID: <1645612457.14.0.651695497672.issue46798@roundup.psfhosted.org>


padremayi <francesco.other at gmail.com> added the comment:

Now:
def get(self, key, default=None)

Future:
def get(self, key, default=None, double_value=False)

No code break

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46798>
_______________________________________

From report at bugs.python.org  Wed Feb 23 06:01:07 2022
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 23 Feb 2022 11:01:07 +0000
Subject: [issue46329] Split up the CALL_NO_KW and CALL_KW instructions.
In-Reply-To: <1641819285.76.0.605357810946.issue46329@roundup.psfhosted.org>
Message-ID: <1645614067.59.0.981078180361.issue46329@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset 424023efee5b21567b4725015ef143b627112e3c by Brandt Bucher in branch 'main':
bpo-46329: Fix test failure when `Py_STATS` is enabled (GH-31511)
https://github.com/python/cpython/commit/424023efee5b21567b4725015ef143b627112e3c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46329>
_______________________________________

From report at bugs.python.org  Wed Feb 23 06:06:35 2022
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 23 Feb 2022 11:06:35 +0000
Subject: [issue45885] Specialize COMPARE_OP
In-Reply-To: <1637701224.16.0.881347004039.issue45885@roundup.psfhosted.org>
Message-ID: <1645614395.69.0.892399692906.issue45885@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset 375a56bd4015596c0cf44129c8842a1fe7199785 by Brandt Bucher in branch 'main':
bpo-45885: Don't un-adapt `COMPARE_OP` when collecting stats (GH-31516)
https://github.com/python/cpython/commit/375a56bd4015596c0cf44129c8842a1fe7199785


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45885>
_______________________________________

From report at bugs.python.org  Wed Feb 23 06:49:25 2022
From: report at bugs.python.org (Stefan Behnel)
Date: Wed, 23 Feb 2022 11:49:25 +0000
Subject: [issue46798] xml.etree.ElementTree: get() doesn't return default
 value, always ATTLIST value
In-Reply-To: <1645270291.57.0.995603390679.issue46798@roundup.psfhosted.org>
Message-ID: <1645616965.57.0.447820375852.issue46798@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

> IMHO if the developer doesn't manage the XML itself it is VERY unreasonable to use the document value and not the developer one.

I disagree. If the document says "this is the default if no explicit value if given", then I consider that just as good as providing a value each time. Meaning, the attribute *is* in fact present, just not explicitly spelled out on the element.

I would specifically like to avoid adding a new option just to override the way the document distributes its attribute value spelling across DTD and document structure. In particular, the .get() method is the wrong place to deal with this.

You can probably configure the parser to ignore the internal DTD subset, if that's what you want.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46798>
_______________________________________

From report at bugs.python.org  Wed Feb 23 07:09:45 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Wed, 23 Feb 2022 12:09:45 +0000
Subject: [issue46834] test_gdb started to fail on buildbot/s390x RHEL7
Message-ID: <1645618185.12.0.728684681117.issue46834@roundup.psfhosted.org>


New submission from Nikita Sobolev <mail at sobolevn.me>:

Log sample:

```
======================================================================
FAIL: test_up_then_down (test.test_gdb.StackNavigationTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z/build/Lib/test/test_gdb.py", line 782, in test_up_then_down
    self.assertMultilineMatches(bt,
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z/build/Lib/test/test_gdb.py", line 297, in assertMultilineMatches
    self.fail(msg='%r did not match %r' % (actual, pattern))
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: 'Breakpoint 1 at 0x801ff160: file Python/bltinmodule.c, line 1168.\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library "/lib64/libthread_db.so.1".\n\nBreakpoint 1, builtin_id (self=, v=<_PyRuntime+2184>) at Python/bltinmodule.c:1168\n1168\t{\n#16 Frame 0x3fffdfb1118, for file <string>, line 9, in bar (a=1, b=2, c=3)\n#16 Frame 0x3fffdfb1090, for file <string>, line 6, in foo (a=1, b=2, c=3)\n#16 Frame 0x3fffdfb1020, for file <string>, line 14, in <module> ()\nUnable to find an older python frame\n#4 Frame 0x3fffdfb11a8, for file <string>, line 12, in baz (args=(1, 2, 3))\n' did not match '^.*\n#[0-9]+ Frame 0x-?[0-9a-f]+, for file <string>, line 12, in baz \\(args=\\(1, 2, 3\\)\\)\n#[0-9]+ <built-in method pyobject_fastcall of module object at remote 0x[0-9a-f]+>\n#[0-9]+ Frame 0x-?[0-9a-f]+, for file <string>, line 12, in baz \\(args=\\(1, 2, 3\\)\\)\n$'
----------------------------------------------------------------------
Ran 32 tests in 15.312s
FAILED (failures=53)
test test_gdb failed
1 test failed again:
    test_gdb
```

Full log (too long): https://buildbot.python.org/all/#/builders/179/builds/1769/steps/5/logs/stdio

It started to happen (at least more often - however, I cannot find any older failures at the moment) after this commit: https://github.com/python/cpython/commit/b899126094731bc49fecb61f2c1b7557d74ca839

Build link: https://buildbot.python.org/all/#/builders/402/builds/1744

Latest commits (at this moment):
- Fails: https://github.com/python/cpython/commit/375a56bd4015596c0cf44129c8842a1fe7199785
- Passes: https://github.com/python/cpython/commit/424023efee5b21567b4725015ef143b627112e3c
- Fails: https://github.com/python/cpython/commit/288af845a32fd2a92e3b49738faf8f2de6a7bf7c

----------
components: Tests
messages: 413786
nosy: sobolevn, vstinner
priority: normal
severity: normal
status: open
title: test_gdb started to fail on buildbot/s390x RHEL7
type: behavior
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46834>
_______________________________________

From report at bugs.python.org  Wed Feb 23 07:11:59 2022
From: report at bugs.python.org (Nikita Sobolev)
Date: Wed, 23 Feb 2022 12:11:59 +0000
Subject: [issue46834] test_gdb started to fail on buildbot/s390x RHEL7
In-Reply-To: <1645618185.12.0.728684681117.issue46834@roundup.psfhosted.org>
Message-ID: <1645618319.69.0.55464668702.issue46834@roundup.psfhosted.org>


Nikita Sobolev <mail at sobolevn.me> added the comment:

Sorry, wrong link. It started to fail after this commit: https://github.com/python/cpython/commit/66b3cd7063322a9f5c922a97bbd06fdb98309999

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46834>
_______________________________________

From report at bugs.python.org  Wed Feb 23 07:43:36 2022
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Wed, 23 Feb 2022 12:43:36 +0000
Subject: [issue46835] ImportError: bad magic number in ... does not indicate
 where is that file located
Message-ID: <1645620216.31.0.535281755903.issue46835@roundup.psfhosted.org>


New submission from Miro Hron?ok <miro at hroncok.cz>:

Recently I've been debugging a very nasty bug report that looked like this:

    Traceback (most recent call last):
      File "/usr/bin/jupyter-notebook", line 5, in <module>
        from notebook.notebookapp import main
      File "/usr/lib/python3.10/site-packages/notebook/notebookapp.py", line 78, in <module>
        from .services.kernels.kernelmanager import MappingKernelManager, AsyncMappingKernelManager
      File "/usr/lib/python3.10/site-packages/notebook/services/kernels/kernelmanager.py", line 18, in <module>
        from jupyter_client.session import Session
      File "/usr/lib/python3.10/site-packages/jupyter_client/session.py", line 41, in <module>
        from jupyter_client.jsonutil import extract_dates, squash_dates, date_default
      File "/usr/lib/python3.10/site-packages/jupyter_client/jsonutil.py", line 10, in <module>
        from dateutil.parser import parse as _dateutil_parse
      File "/usr/lib/python3.10/site-packages/dateutil/parser/__init__.py", line 2, in <module>
        from ._parser import parse, parser, parserinfo, ParserError
      File "/usr/lib/python3.10/site-packages/dateutil/parser/_parser.py", line 42, in <module>
        import six
    ImportError: bad magic number in 'six': b'\x03\xf3\r\n'

For details, see https://bugzilla.redhat.com/2057340 and https://github.com/benjaminp/six/issues/359


What would really make things much easier to understand would be if the exception mentioned what is the path of 'six'.


Consider this example:

A rogue .py file in /usr/bin:

    $ sudo touch /usr/bin/copy.py

Programs fail with:

    Traceback (most recent call last):
      File "/usr/bin/...", line ..., in <module>
        ...
    ImportError: cannot import name 'deepcopy' from 'copy' (/usr/bin/copy.py)

Immediately I can see there is /usr/bin/copy.py which is probably not supposed to be there.

However, when it is a pyc instead:

    $ sudo touch /usr/bin/copy.pyc

Programs fail with:

    Traceback (most recent call last):
      File "/usr/bin/...", line ..., in <module>
        ...
    ImportError: bad magic number in 'copy': b''

Now I have no idea where "copy" is.


The is a request for that exception to give that infomartion.

----------
components: Interpreter Core
messages: 413788
nosy: hroncok, petr.viktorin
priority: normal
severity: normal
status: open
title: ImportError: bad magic number in ... does not indicate where is that file located
type: enhancement
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46835>
_______________________________________

From report at bugs.python.org  Wed Feb 23 07:49:33 2022
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Wed, 23 Feb 2022 12:49:33 +0000
Subject: [issue46835] ImportError: bad magic number in ... does not indicate
 where is that file located
In-Reply-To: <1645620216.31.0.535281755903.issue46835@roundup.psfhosted.org>
Message-ID: <1645620573.42.0.982221289777.issue46835@roundup.psfhosted.org>


Miro Hron?ok <miro at hroncok.cz> added the comment:

Apparently, the exception already contains a path attribute with exactly the kind of information I'd like to see.

What if the message was:

ImportError: bad magic number in '/usr/bin/six.pyc': b'\x03\xf3\r\n'

Would that be accepted as a PR? Should I discuss this on the mailing list?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46835>
_______________________________________

From report at bugs.python.org  Wed Feb 23 08:00:49 2022
From: report at bugs.python.org (burrito)
Date: Wed, 23 Feb 2022 13:00:49 +0000
Subject: [issue45326] Unexpected TypeError with type alias+issubclass+ABC
In-Reply-To: <1632950049.79.0.711339156878.issue45326@roundup.psfhosted.org>
Message-ID: <1645621249.91.0.359242424502.issue45326@roundup.psfhosted.org>


Change by burrito <rburczynski at spoton.com>:


----------
nosy: +burrito

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45326>
_______________________________________

From report at bugs.python.org  Wed Feb 23 08:38:46 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 23 Feb 2022 13:38:46 +0000
Subject: [issue46622] Add an async variant of lru_cache for coroutines.
In-Reply-To: <1643873308.65.0.92890586202.issue46622@roundup.psfhosted.org>
Message-ID: <1645623526.93.0.0314956730582.issue46622@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Thanks, Raymond.

I agree that caching of iterators and generators is out of the issue scope.

Also, I agree that a separate async cache decorator should be added. I prefer the `async_lru_cache` (and maybe `async_cache` for the API symmetry). We have `contextmanager` and `asynccontextmanager` in contextlib already along with `closing` / `aclosing`, `ExitStack` / `AsyncExitStack` etc.

`async_lru_cache` should have the same arguments as accepted by `lru_cache` but work with async functions.

I think this function should be a part of stdlib because the implementation shares *internal* `_lru_cache_wrapper` that does all dirty jobs (and has C accelerator). A third-party library should either copy all these implementation details or import a private function from stdlib and keep fingers crossed in hope that the private API will keep backward compatibility in future Python versions.

Similar reasons were applied to contextlib async APIs.

Third parties can have different features (time-to-live, expiration events, etc., etc.) and can be async-framework specific (work with asyncio or trio only) -- I don't care about these extensions here.

My point is: stdlib has built-in lru cache support, I love it. Let's add exactly the as we have already for sync functions but for async ones.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46622>
_______________________________________

From report at bugs.python.org  Wed Feb 23 08:47:58 2022
From: report at bugs.python.org (Tzu-ping Chung)
Date: Wed, 23 Feb 2022 13:47:58 +0000
Subject: [issue46622] Add an async variant of lru_cache for coroutines.
In-Reply-To: <1643873308.65.0.92890586202.issue46622@roundup.psfhosted.org>
Message-ID: <1645624078.94.0.110982969124.issue46622@roundup.psfhosted.org>


Tzu-ping Chung <uranusjr at gmail.com> added the comment:

Another thing to point out is that existing third-party solutions (both alru_cache and cached_property) only work for asyncio, and the stdlib version (as implemented now) will be an improvement. And if the position is that the improvements should only be submitted to third-party solutions---I would need to disagree since both lru_cache and cached_property have third-party solutions predating their stdlib implementations, and it is double-standard IMO if an async solution is kept out while the sync version is kept in.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46622>
_______________________________________

From report at bugs.python.org  Wed Feb 23 09:12:40 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 14:12:40 +0000
Subject: [issue45459] Limited API support for Py_buffer
In-Reply-To: <1634118913.79.0.141868262007.issue45459@roundup.psfhosted.org>
Message-ID: <1645625560.07.0.311252396852.issue45459@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29651
pull_request: https://github.com/python/cpython/pull/31527

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45459>
_______________________________________

From report at bugs.python.org  Wed Feb 23 09:14:39 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 14:14:39 +0000
Subject: [issue45459] Limited API support for Py_buffer
In-Reply-To: <1634118913.79.0.141868262007.issue45459@roundup.psfhosted.org>
Message-ID: <1645625679.3.0.76174254014.issue45459@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Include/object.h:109:3: warning: redefinition of typedef 'PyObject' is a C11 feature [-Wtypedef-redefinition]

Oh. I already met this error :-(

That's why I proposed in GH-31201 to move all forward declarations at the top of Python.h to solve such issue.

I wrote GH-31527 to do exactly that: add a new pytypedefs.h header files to move all forward declarations at the top of Python.h.

I didn't move *all* "typedef struct xxx yyy;" there: only the ones which cause interdependencies issues.

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45459>
_______________________________________

From report at bugs.python.org  Wed Feb 23 09:32:58 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 14:32:58 +0000
Subject: [issue45459] Limited API support for Py_buffer
In-Reply-To: <1634118913.79.0.141868262007.issue45459@roundup.psfhosted.org>
Message-ID: <1645626778.57.0.771463435911.issue45459@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29652
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/31528

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45459>
_______________________________________

From report at bugs.python.org  Wed Feb 23 09:41:35 2022
From: report at bugs.python.org (Steve Dower)
Date: Wed, 23 Feb 2022 14:41:35 +0000
Subject: [issue46833] Installer Wizard is unclear and has redundant settings
In-Reply-To: <1645604528.5.0.846357801282.issue46833@roundup.psfhosted.org>
Message-ID: <1645627295.06.0.185703384824.issue46833@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> I am not sure but would say that the first two options are related to the py-launcher not the the python interpreter itself.

You correctly read the options, so we'll need a suggestion on how to make it more clear without becoming impenetrable. Maybe changing the third one to say "Install Python for all users" would suffice?

Possibly we should link to the install docs from the front page for people who want more help.

> OK, but why two options?

The py.exe launcher is totally separate from the version of Python you're installing, and if you previously installed it for all users (including if you previously installed Python 3.4 or earlier), you have to install it for all users again or it won't work.

The option is on the front page so that non-admins can easily disable it and still install everything.

> This appears on the first page ("Add Python 3.9 to PATH") and on the third page ("Add Python to environment variables").

So that users can change it without having to go through the advanced install. This is the most common option to enable, even though we recommend against it unless you know what you're doing, so putting it on the front page saves _many_ users from having to go through all the other pages.

> all this options are not synchronized

That sound like a bug. And I can't reproduce it, so we might need more info.

If you go through setup a few times (without ever actually installing) and fiddle with the options, it will still produce a log file in %TEMP% that should explain which settings were modified, so we can see why they may not be updating in the UI for you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46833>
_______________________________________

From report at bugs.python.org  Wed Feb 23 09:56:27 2022
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 23 Feb 2022 14:56:27 +0000
Subject: [issue45390] asyncio.Task doesn't propagate CancelledError()
 exception correctly.
In-Reply-To: <1633519842.27.0.396754460358.issue45390@roundup.psfhosted.org>
Message-ID: <1645628187.76.0.255518188516.issue45390@roundup.psfhosted.org>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

For future reference, with Andrew's change merged above, the traceback for the example snippet in my message above:
https://bugs.python.org/issue45390#msg403570
is now the following. Observe that (1) the call to sleep() continues to be present, but (2) without introducing two new intermediate CancelledErrors, which increase the verbosity of the traceback:

Traceback (most recent call last):
  File "/home/andrew/projects/cpython/exc_traceback.py", line 14, in <module>
    asyncio.run(main())
    ^^^^^^^^^^^^^^^^^^^
  File "/home/andrew/projects/cpython/Lib/asyncio/runners.py", line 44, in run
    return loop.run_until_complete(main)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/andrew/projects/cpython/Lib/asyncio/base_events.py", line 640, in run_until_complete
    return future.result()
           ^^^^^^^^^^^^^^^
  File "/home/andrew/projects/cpython/exc_traceback.py", line 11, in main
    await task
    ^^^^^^^^^^
  File "/home/andrew/projects/cpython/exc_traceback.py", line 5, in job
    await asyncio.sleep(5)
    ^^^^^^^^^^^^^^^^^^^^^^
  File "/home/andrew/projects/cpython/Lib/asyncio/tasks.py", line 619, in sleep
    return await future
           ^^^^^^^^^^^^
asyncio.exceptions.CancelledError: cancel job

(This is copied from Andrew's comment in the PR here:
https://github.com/python/cpython/pull/31383#issuecomment-1046822899 )

Serhiy, can you provide a sample snippet for your case with output, like I did in my message linked above?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45390>
_______________________________________

From report at bugs.python.org  Wed Feb 23 10:02:28 2022
From: report at bugs.python.org (Ofey Chan)
Date: Wed, 23 Feb 2022 15:02:28 +0000
Subject: [issue46761] functools.update_wrapper breaks the signature of
 functools.partial objects
In-Reply-To: <1644948374.87.0.765462873315.issue46761@roundup.psfhosted.org>
Message-ID: <1645628548.16.0.685595443615.issue46761@roundup.psfhosted.org>


Change by Ofey Chan <ofey206 at gmail.com>:


----------
keywords: +patch
pull_requests: +29653
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/31529

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46761>
_______________________________________

From report at bugs.python.org  Wed Feb 23 10:04:12 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 15:04:12 +0000
Subject: [issue46836] [C API] Move PyFrameObject to the internal C API
Message-ID: <1645628652.12.0.0785803095185.issue46836@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

I propose to move the PyFrameObject structure to the internal C API.


--


Between Python 3.10 and Python 3.11, the work on optimizing ceval.c modified deeply the PyFrameObject structure. Examples:

* The f_code member has been removed by in bpo-44032 by the commit b11a951f16f0603d98de24fee5c023df83ea552c.
* The f_frame member has been added in bpo-44590 by the commit ae0a2b756255629140efcbe57fc2e714f0267aa3.

Most members have been moved to a new PyFrameObject.f_frame member which has the type "struct _interpreter_frame*". Problem: this type is only part of the *internal* C API.

Moreover, accessing the few remaining members which "didn't change" became dangerous. For example, f_back can be NULL even if the frame has a previous frame: the PyFrame_GetBack() function *must* now be called. See bpo-46356 "[C API] Enforce usage of PyFrame_GetBack()".

Reading directly f_lineno was already dangerous since Python 2.3: the value is only valid if the value is greater than 0. It's way safer to use the clean PyFrame_GetLineNumber() API instead.

PyFrame_GetBack() was added to Python 3.9. You can use the pythoncapi_compat project to get this function on Python 3.8 and older:

=> https://pythoncapi-compat.readthedocs.io/

PyFrame_GetLineNumber() was added to the limited API in Python 3.10.

=> Documentation: https://docs.python.org/dev/c-api/reflection.html#c.PyFrame_GetBack


--


There *are* projects accessing directly PyFrameObject like the gevent project which sets the f_code member (moved to f_frame.f_code in Python 3.11). It's broken on Python 3.11:
https://bugs.python.org/issue40421#msg413719

Debuggers and profilers also want to read PyFrameObject directly. IMO for these *specific* use cases, using the *internal* C API is a legit use case and it's fine.

Moving PyFrameObject to the internal C API would clarify the situation. Currently, What's New in Python 3.11 documents the change this with warning:

"While the documentation notes that the fields of PyFrameObject are subject to change at any time, they have been stable for a long time and were used in several popular extensions. "


--


I'm mostly worried about Cython which still get and set many PyFrameObject members directly (ex: f_lasti, f_lineno, f_localsplus, f_trace), since there are no public functions for that.

=> https://bugs.python.org/issue40421#msg367550

Right now, I would suggest Cython to use the internal C API, and *later* consider adding new getter and setter functions. I don't think that we can solve all problems at once: it takes take to design clean API and use them in Cython.

Python 3.11 already broke Cython since most PyFrameObject members moved into the new "internal" PyFrameObject.f_frame API which requires using the internal C API to get "struct _interpreter_frame".

=> https://github.com/cython/cython/issues/4500


--


Using a frame using the *public* C API was and remains supported. Short example:
--
PyThreadState *tstate = PyThreadState_Get();
PyFrameObject* frame = PyThreadState_GetFrame(tstate);
int lineno = PyFrame_GetLineNumber(frame);
---

The PyFrameObject structure is opaque and members are not accessed directly: it's fine.

----------
components: C API
messages: 413795
nosy: vstinner
priority: normal
severity: normal
status: open
title: [C API] Move PyFrameObject to the internal C API
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46836>
_______________________________________

From report at bugs.python.org  Wed Feb 23 10:05:22 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 15:05:22 +0000
Subject: [issue46836] [C API] Move PyFrameObject to the internal C API
In-Reply-To: <1645628652.12.0.0785803095185.issue46836@roundup.psfhosted.org>
Message-ID: <1645628722.72.0.954928381193.issue46836@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

By the way, Include/cpython/ceval.h uses the "struct _interpreter_frame*" type whereas this type is part of the internal C API:

PyAPI_FUNC(PyObject *) _PyEval_EvalFrameDefault(PyThreadState *tstate, struct _interpreter_frame *f, int exc);

Maybe we should move this defintion to the internal C API pycore_ceval.h.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46836>
_______________________________________

From report at bugs.python.org  Wed Feb 23 10:13:39 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 15:13:39 +0000
Subject: [issue46836] [C API] Move PyFrameObject to the internal C API
In-Reply-To: <1645628652.12.0.0785803095185.issue46836@roundup.psfhosted.org>
Message-ID: <1645629219.63.0.878027558218.issue46836@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +29654
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31530

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46836>
_______________________________________

From report at bugs.python.org  Wed Feb 23 10:14:04 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 15:14:04 +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: <1645629244.74.0.704938468433.issue40421@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I created bpo-46836: "[C API] Move PyFrameObject to the internal C API".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40421>
_______________________________________

From report at bugs.python.org  Wed Feb 23 10:14:23 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 15:14:23 +0000
Subject: [issue44590] Create frame objects lazily when needed
In-Reply-To: <1625828020.36.0.429011373838.issue44590@roundup.psfhosted.org>
Message-ID: <1645629263.16.0.899339162772.issue44590@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I created bpo-46836: "[C API] Move PyFrameObject to the internal C API".

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44590>
_______________________________________

From report at bugs.python.org  Wed Feb 23 10:14:32 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 15:14:32 +0000
Subject: [issue46355] [C API] Document PyFrameObject and PyThreadState changes
 and explain how to port code to Python 3.11
In-Reply-To: <1641996684.93.0.427230565464.issue46355@roundup.psfhosted.org>
Message-ID: <1645629272.79.0.52246406819.issue46355@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I created bpo-46836: "[C API] Move PyFrameObject to the internal C API".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46355>
_______________________________________

From report at bugs.python.org  Wed Feb 23 10:14:24 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 15:14:24 +0000
Subject: [issue44032] Function locals and evaluation stack should be stored in
 a contiguous, per-thread stack
In-Reply-To: <1620140071.36.0.488434643792.issue44032@roundup.psfhosted.org>
Message-ID: <1645629264.57.0.731816231519.issue44032@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I created bpo-46836: "[C API] Move PyFrameObject to the internal C API".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44032>
_______________________________________

From report at bugs.python.org  Wed Feb 23 10:17:31 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 15:17:31 +0000
Subject: [issue46836] [C API] Move PyFrameObject to the internal C API
In-Reply-To: <1645628652.12.0.0785803095185.issue46836@roundup.psfhosted.org>
Message-ID: <1645629451.94.0.256625594411.issue46836@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

See also bpo-40421 "[C API] Add getter functions for PyFrameObject and maybe move PyFrameObject to the internal C API". I added getter functions in recent Python versions:

* PyFrame_GetBack(): Python 3.9
* PyFrame_GetCode(): Python 3.9
* PyFrame_GetLineNumber() added to the limited C API version 3.10

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46836>
_______________________________________

From report at bugs.python.org  Wed Feb 23 10:19:54 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 15:19:54 +0000
Subject: [issue46836] [C API] Move PyFrameObject to the internal C API
In-Reply-To: <1645628652.12.0.0785803095185.issue46836@roundup.psfhosted.org>
Message-ID: <1645629594.99.0.0668356842601.issue46836@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

See also bpo-44800 "Code readability: rename InterpreterFrame to _Py_framedata".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46836>
_______________________________________

From report at bugs.python.org  Wed Feb 23 10:21:21 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 15:21:21 +0000
Subject: [issue46836] [C API] Move PyFrameObject to the internal C API
In-Reply-To: <1645628652.12.0.0785803095185.issue46836@roundup.psfhosted.org>
Message-ID: <1645629681.76.0.598117041518.issue46836@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

See also bpo-45247: [C API] Add explicit support for Cython to the C API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46836>
_______________________________________

From report at bugs.python.org  Wed Feb 23 10:21:36 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 15:21:36 +0000
Subject: [issue45247] [C API] Add explicit support for Cython to the C API
In-Reply-To: <1632135587.14.0.29634943523.issue45247@roundup.psfhosted.org>
Message-ID: <1645629696.83.0.483674726835.issue45247@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I created bpo-46836: "[C API] Move PyFrameObject to the internal C API".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45247>
_______________________________________

From report at bugs.python.org  Wed Feb 23 10:23:22 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 15:23:22 +0000
Subject: [issue46836] [C API] Move PyFrameObject to the internal C API
In-Reply-To: <1645628652.12.0.0785803095185.issue46836@roundup.psfhosted.org>
Message-ID: <1645629802.0.0.691262549286.issue46836@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I marked my PR as a draft since this change is an incompatible change. Even if PyFrameObject structure is excluded from the limited C API and not documented, it's used by a few projects. I plan to check how this change impacts these projects before merging the change.

For example, test this change on:

* Cython: https://github.com/cython/cython/issues/4500
* gevent: https://github.com/gevent/gevent/issues/1867
* coverage uses f_lasti: https://bugs.python.org/issue40421#msg403814

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46836>
_______________________________________

From report at bugs.python.org  Wed Feb 23 10:24:06 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 15:24:06 +0000
Subject: [issue46836] [C API] Move PyFrameObject to the internal C API
In-Reply-To: <1645628652.12.0.0785803095185.issue46836@roundup.psfhosted.org>
Message-ID: <1645629846.52.0.975216289274.issue46836@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +Mark.Shannon, corona10, erlendaasland, petr.viktorin, scoder

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46836>
_______________________________________

From report at bugs.python.org  Wed Feb 23 10:24:26 2022
From: report at bugs.python.org (Andreas H.)
Date: Wed, 23 Feb 2022 15:24:26 +0000
Subject: [issue45184] Add `pop` function to remove context manager from
 (Async)ExitStack
In-Reply-To: <1631544002.04.0.855227455654.issue45184@roundup.psfhosted.org>
Message-ID: <1645629866.64.0.765265450506.issue45184@roundup.psfhosted.org>


Andreas H. <ahangauer at gmx.net> added the comment:

Inside the discussion an ExitPool class is sketched (https://mail.python.org/archives/list/python-ideas at python.org/message/66W55FRCYMYF73TVMDMWDLVIZK4ZDHPD/), which provides this removal of context managers.

What I learned is that this would have different cleanup mode (atexit style), as compared to present ExitStack cleanup (nested style). 

So contrary to what I was originally thinking ExitPool functionality would be close to, but not a strict superset of ExitStack functionality. Still such an ExitPool functionality would be extremely useful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45184>
_______________________________________

From report at bugs.python.org  Wed Feb 23 10:29:18 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 15:29:18 +0000
Subject: [issue46836] [C API] Move PyFrameObject to the internal C API
In-Reply-To: <1645628652.12.0.0785803095185.issue46836@roundup.psfhosted.org>
Message-ID: <1645630158.89.0.093353065909.issue46836@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

See also the bpo-39947: "[C API] Make the PyThreadState structure opaque (move it to the internal C API)". Recently, I also added helper functions:

* PyThreadState_GetFrame(): Python 3.9 and limited C API version 3.10
* PyThreadState_GetID(): Python 3.9 and limited C API version 3.10
* PyThreadState_GetInterpreter(): Python 3.9 and limited C API version 3.10
* PyThreadState_EnterTracing(), PyThreadState_LeaveTracing(): Python 3.11

See also pending GH-29121 of bpo-39947: "Add PyThreadState_SetTrace() function".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46836>
_______________________________________

From report at bugs.python.org  Wed Feb 23 10:29:45 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 23 Feb 2022 15:29:45 +0000
Subject: [issue45390] asyncio.Task doesn't propagate CancelledError()
 exception correctly.
In-Reply-To: <1633519842.27.0.396754460358.issue45390@roundup.psfhosted.org>
Message-ID: <1645630185.94.0.177390360502.issue45390@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Serhiy is right, Condition.wait() has the following code:

        finally:
            # Must reacquire lock even if wait is cancelled
            cancelled = False
            while True:
                try:
                    await self.acquire()
                    break
                except exceptions.CancelledError:
                    cancelled = True

            if cancelled:
                raise exceptions.CancelledError

It swallows CancelledError exceptions from waiters and re-raises CancelledError without the cancellation message.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45390>
_______________________________________

From report at bugs.python.org  Wed Feb 23 10:30:11 2022
From: report at bugs.python.org (Christian Buhtz)
Date: Wed, 23 Feb 2022 15:30:11 +0000
Subject: [issue46833] Installer Wizard is unclear and has redundant settings
In-Reply-To: <1645604528.5.0.846357801282.issue46833@roundup.psfhosted.org>
Message-ID: <1645630211.91.0.0443966187492.issue46833@roundup.psfhosted.org>


Christian Buhtz <c.buhtz at posteo.jp> added the comment:

Thank you very much for your quick replay and for taking my problems and thoughts into account.

I have to dive deeper into the topic but still have some ideas how to re-design the wizard.

IMHO the primary problem is that on the first page the decision between "normal" and "advanced" is mixed with the settings for "normal".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46833>
_______________________________________

From report at bugs.python.org  Wed Feb 23 10:30:51 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 15:30:51 +0000
Subject: [issue46356] [C API] Enforce usage of PyFrame_GetBack()
In-Reply-To: <1642001581.89.0.653777729997.issue46356@roundup.psfhosted.org>
Message-ID: <1645630251.52.0.182479014374.issue46356@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I created bpo-46836: "[C API] Move PyFrameObject to the internal C API".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46356>
_______________________________________

From report at bugs.python.org  Wed Feb 23 10:31:36 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 23 Feb 2022 15:31:36 +0000
Subject: [issue46813] Allow developer to resize the dictionary
In-Reply-To: <1645428779.91.0.472362648196.issue46813@roundup.psfhosted.org>
Message-ID: <1645630296.04.0.845142295987.issue46813@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I'm going to close this one.  Making a new and previously rejected extension to one of Python's most import APIs requires broad discussion and buy-in.  If you really want to push for this, please take it to the python-ideas list.

----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46813>
_______________________________________

From report at bugs.python.org  Wed Feb 23 10:34:41 2022
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 23 Feb 2022 15:34:41 +0000
Subject: [issue45107] Improve LOAD_METHOD specialization
In-Reply-To: <1630859956.74.0.360849757822.issue45107@roundup.psfhosted.org>
Message-ID: <1645630481.7.0.665880988308.issue45107@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
nosy: +Mark.Shannon
nosy_count: 1.0 -> 2.0
pull_requests: +29655
pull_request: https://github.com/python/cpython/pull/31531

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45107>
_______________________________________

From report at bugs.python.org  Wed Feb 23 10:37:54 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 23 Feb 2022 15:37:54 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645630674.24.0.238926841367.issue46771@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

I have no good simple real-case scenario, sorry. 

There is a demonstration of my thoughts.

Suppose we have a custom context manager that behaves similar to timeout() but is controlled not by timer but external event source (it could be an invalidation message sent by a distributed broker or something else).


class EventRaised(Exception):
    pass

class CancelOnEvent:
    async def __init__(self, event):
        self.event = event

    async def __aenter__(self):
        self.waiter = asyncio.task(self._cancel_on_event, asyncio.current_task())

    async def __aexit__(self, exc_typ, ecx_val, exc_tb):
        if exc_typ is asyncio.CancelledError:
            if CASE1:  # <<< cleanup strategy selector
                if asyncio.current_task().uncancel() == 0:
                    raise EventRaised
            else:
                if self.event.is_set():
                    raise EventRaised

    async def _cancel_on_event(self, task):
        await self.event.wait()
        task.cancel()

###########
event = asyncio.Event()

async with asyncio.timeout(1):  # what exception should bubble-up here?
    async with CancelOnEvent(event):
        await asyncio.sleep(10)  # event.set() is called here after 1 sec timeout

If this CancelOnEvent context manager is used together with timeout() CM, is the behavior clear? Should `.uncancel()` be used by CancelOnEvent? Why? How should it interact with timeout()?
I have no clear and obvious answer on these questions, this worries me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Wed Feb 23 10:42:48 2022
From: report at bugs.python.org (Eric Snow)
Date: Wed, 23 Feb 2022 15:42:48 +0000
Subject: [issue46806] Overlapping PYTHONPATH may cause import already imported
 module
In-Reply-To: <1645360487.42.0.278270431314.issue46806@roundup.psfhosted.org>
Message-ID: <1645630968.1.0.856275694241.issue46806@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

FYI, a technical solution has been discussed before: bpo-13475 and PEP 395.  However, that does not help so much if the default behavior isn't changed.  That would require a PEP but I expect it would be rejected because so many scripts already rely on the current behavior and the current behavior is useful in some cases.

PEP 395 also has a good discussion of the various pitfalls related to sys.path[0] initialization.  Furthermore, the topic is discussed in quite a few issues, such as bpo-44132 and bpo-29929.

Probably the best use of your time on this would be to improve the documentation so people will more easily avoid the problem, or at least more easily diagnose the situation when they stumble on it.  Again, PEP 395 is a good guide for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46806>
_______________________________________

From report at bugs.python.org  Wed Feb 23 10:57:53 2022
From: report at bugs.python.org (Ofey Chan)
Date: Wed, 23 Feb 2022 15:57:53 +0000
Subject: [issue46761] functools.update_wrapper breaks the signature of
 functools.partial objects
In-Reply-To: <1644948374.87.0.765462873315.issue46761@roundup.psfhosted.org>
Message-ID: <1645631873.56.0.42650753417.issue46761@roundup.psfhosted.org>


Ofey Chan <ofey206 at gmail.com> added the comment:

I fix the problem.

But sorry for my last message, because it totally miss the point ;)

In `inspect.signature()`, the order of handle `follow_wrapper_chains` and `functools.partial` cause the problem.

Relevant code: https://github.com/python/cpython/blob/288af845a32fd2a92e3b49738faf8f2de6a7bf7c/Lib/inspect.py#L2408

The original order is:

1. `follow_wrapper_chains` unwrap decorators.
   - It would check `__wrapped__` attribute in `unwrap()`.
   - `functools.update_wrapper()` would set `__wrapped__`.
2. Then handle `functools.partial`, construct new signature with `_signature_get_partial()`

So the original `functools.partial` object would skip (1), goto (2) and would be correctly processed.

But after calling `functools.update_wrapper()`, the `functools.partial` object has a `__wrapped__` attribute, so it directly handled by (1) and will never reach (2). That's why `inspect.signature()` return the original function's signature.

`update_wrapper.breaks.partial.signature.check.__wrapped__.py` shows the `__wrapped__` attribute.

My solution is simple: swap the order of (1) and (2).

`functools.partial` is a special type of wrapper, handle it before going down the wrapper chain is sane.

And I have written test case to ensure it's correct, hope it works.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46761>
_______________________________________

From report at bugs.python.org  Wed Feb 23 10:58:08 2022
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 23 Feb 2022 15:58:08 +0000
Subject: [issue46835] ImportError: bad magic number in ... does not indicate
 where is that file located
In-Reply-To: <1645620216.31.0.535281755903.issue46835@roundup.psfhosted.org>
Message-ID: <1645631888.82.0.613544645111.issue46835@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

I assume a PR review should be enough.

----------
components: +Library (Lib) -Interpreter Core

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46835>
_______________________________________

From report at bugs.python.org  Wed Feb 23 10:58:22 2022
From: report at bugs.python.org (Ofey Chan)
Date: Wed, 23 Feb 2022 15:58:22 +0000
Subject: [issue46761] functools.update_wrapper breaks the signature of
 functools.partial objects
In-Reply-To: <1644948374.87.0.765462873315.issue46761@roundup.psfhosted.org>
Message-ID: <1645631902.18.0.180844911483.issue46761@roundup.psfhosted.org>


Change by Ofey Chan <ofey206 at gmail.com>:


Added file: https://bugs.python.org/file50639/update_wrapper.breaks.partial.signature.check.__wrapped__.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46761>
_______________________________________

From report at bugs.python.org  Wed Feb 23 11:04:09 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 16:04:09 +0000
Subject: [issue46836] [C API] Move PyFrameObject to the internal C API
In-Reply-To: <1645628652.12.0.0785803095185.issue46836@roundup.psfhosted.org>
Message-ID: <1645632249.19.0.544735586321.issue46836@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29656
pull_request: https://github.com/python/cpython/pull/31532

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46836>
_______________________________________

From report at bugs.python.org  Wed Feb 23 11:13:28 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 23 Feb 2022 16:13:28 +0000
Subject: [issue46356] [C API] Enforce usage of PyFrame_GetBack()
In-Reply-To: <1642001581.89.0.653777729997.issue46356@roundup.psfhosted.org>
Message-ID: <1645632808.67.0.805315401225.issue46356@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/issue46356>
_______________________________________

From report at bugs.python.org  Wed Feb 23 11:16:21 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 23 Feb 2022 16:16:21 +0000
Subject: =?utf-8?q?=5Bissue46754=5D_Improve_Python_Language_Reference_based_on_=5B?=
 =?utf-8?b?S8O2aGwgMjAyMF0=?=
In-Reply-To: <1644887951.55.0.170879911355.issue46754@roundup.psfhosted.org>
Message-ID: <1645632981.55.0.399450753299.issue46754@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/issue46754>
_______________________________________

From report at bugs.python.org  Wed Feb 23 11:17:23 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 23 Feb 2022 16:17:23 +0000
Subject: [issue46736] Generate HTML 5 with
 SimpleHTTPRequestHandler.list_directory
In-Reply-To: <1644741188.03.0.745095490398.issue46736@roundup.psfhosted.org>
Message-ID: <1645633043.95.0.367170941575.issue46736@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/issue46736>
_______________________________________

From report at bugs.python.org  Wed Feb 23 11:39:43 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 23 Feb 2022 16:39:43 +0000
Subject: [issue46622] Add an async variant of lru_cache for coroutines.
In-Reply-To: <1643873308.65.0.92890586202.issue46622@roundup.psfhosted.org>
Message-ID: <1645634383.03.0.813789420751.issue46622@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I think that it would be simpler to add a decorator which wraps the result of an asynchronous function into an object which can be awaited more than once:

def reawaitable(func):
    @wraps(func)
    def wrapper(*args, **kwargs):
        return CachedAwaitable(func(*args, **kwargs))
    return wrapper

It can be combined with lru_cache and cached_property any third-party caching decorator. No access to internals of the cache is needed.

@lru_cache()
@reawaitable
async def coro(...):
    ...

@cached_property
@reawaitable
async def prop(self):
    ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46622>
_______________________________________

From report at bugs.python.org  Wed Feb 23 11:41:14 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 16:41:14 +0000
Subject: [issue43311] bpo-43311: PyInterpreterState_New use thread-specific
 data tstate before key create .
In-Reply-To: <1614155405.65.0.593028600281.issue43311@roundup.psfhosted.org>
Message-ID: <1645634474.59.0.572686925812.issue43311@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/issue43311>
_______________________________________

From report at bugs.python.org  Wed Feb 23 11:46:25 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 23 Feb 2022 16:46:25 +0000
Subject: [issue46829] Confusing CancelError message if multiple cancellations
 are scheduled
In-Reply-To: <1645567371.24.0.086924022035.issue46829@roundup.psfhosted.org>
Message-ID: <1645634785.21.0.49189060105.issue46829@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

But that example is made-up. Is there a real-world situation where you need to know the call site, and it wouldn't be obvious from other log messages?

Directly cancelling a task without also somehow catching the cancellation (like in the timeout or task group cases) feels like an odd practice to me.

And passing the cancel message through is complex (as we've seen in recent PRs).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46829>
_______________________________________

From report at bugs.python.org  Wed Feb 23 11:49:01 2022
From: report at bugs.python.org (Christian Buhtz)
Date: Wed, 23 Feb 2022 16:49:01 +0000
Subject: [issue46833] Installer Wizard is unclear and has redundant settings
In-Reply-To: <1645604528.5.0.846357801282.issue46833@roundup.psfhosted.org>
Message-ID: <1645634941.03.0.389141568486.issue46833@roundup.psfhosted.org>


Christian Buhtz <c.buhtz at posteo.jp> added the comment:

In the attachment you will find a PDF with variants A to D on each side.

I tried to think into the design decisions made by the team who created the current installer. I am not sure of course but I tried to take this (assumed) decisions into account.

Variant A:
This is nearest to the current release version.
 - The settings on page 1 are moved onto that page directly to the bottom of "Install Now" and before(!) "Customize installation".
 - The "all users" option is now available for the interpreter and launcher.
Modifying the position of the two checkboxes make?s it more clear to which decision way (simple or customized/advanced installation) they belong.

Variant B:
The same as A but Page 2 and 3 (from A) are joined together. If there is enough room on the wizard dialog this would be OK. But very important is to visually separate the two sections "Interpreter" and "Launcher" on that one dialog. You could do that with bigger bold text like headings or you could use a horizontal bar.

Variant C (would be my second favourite):
Page 1 is more minimal. The user only have to make a decision between simple installation and advanced/customize installation.

Variant D (my favourite):
Page one offers the simple options about "PATH" and "all users" for interpreter and launcher. This should be separated in a visual way of course.
btw: From a technical point of view I do not see an advantage of separating the decision about "PATH" and "all users" between python and py. I would assume if py should goes to PATH and installed for "all users" the interpreter should treated the same.
More important on D is that the way to the "advanced" (currently named "customize") installation way is "hidden" behind a simple GUI button. A lot of other installers doing it the same way. It is just a simple button. Not big, no special colours or something like that. The page 1 of the current release version of the installer is to much bling-bling. ;)

Some more Notes and Thoughts

?Customize? is not a good term, because it is still possible to ?customize? the installation on that first page (the two check boxes on the bottom) without clicking ?Customize installation? and
When clicking on ?Customize installation? the next (2nd) page is named ?Optional Features? which is different from ?Customization?. I would suggest "Advanced" or "Expert".
It is similar with ?Advanced? on page 3. What is the difference between ?Advanced? and ?Customize??

Add a ?What is the py launcher for? link to the wizard.

Add a ?What is pip launcher for? link to the wizard.

In the What-for-pages: Do not describe what py/pip can do but describe what the user can do with it. Modify the perspectives/view points! I would help you to review this texts.

Use horizontal bars in the GUI to better visualise the separate ways/topics. E.g. in Variant B on page 2.

I have some more detailed suggestions about modified wording. But I think at this point it is enough. :)

----------
Added file: https://bugs.python.org/file50640/py_installer.pdf

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46833>
_______________________________________

From report at bugs.python.org  Wed Feb 23 11:52:45 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 23 Feb 2022 16:52:45 +0000
Subject: [issue46736] Generate HTML 5 with
 SimpleHTTPRequestHandler.list_directory
In-Reply-To: <1644741188.03.0.745095490398.issue46736@roundup.psfhosted.org>
Message-ID: <1645635165.41.0.122088043334.issue46736@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
keywords: +patch
pull_requests: +29657
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31533

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46736>
_______________________________________

From report at bugs.python.org  Wed Feb 23 11:55:07 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 23 Feb 2022 16:55:07 +0000
Subject: [issue46622] Add an async variant of lru_cache for coroutines.
In-Reply-To: <1643873308.65.0.92890586202.issue46622@roundup.psfhosted.org>
Message-ID: <1645635307.48.0.136453653253.issue46622@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

async_lru_cache() and async_cached_property() can be written using that decorator. The implementation of async_lru_cache() is complicated because the interface of lru_cache() is complicated. But it is simpler than using _lru_cache_wrapper().

def async_lru_cache(maxsize=128, typed=False):
    if callable(maxsize) and isinstance(typed, bool):
        user_function, maxsize = maxsize, 128
        return lru_cache(maxsize, typed)(reawaitable(user_function))

    def decorating_function(user_function):
        return lru_cache(maxsize, typed)(reawaitable(user_function))

    return decorating_function

def async_cached_property(user_function):
    return cached_property(reawaitable(user_function))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46622>
_______________________________________

From report at bugs.python.org  Wed Feb 23 12:03:19 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 23 Feb 2022 17:03:19 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645635799.54.0.742459391532.issue46771@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

To make this cleanly interact with timeout, TaskGroup etc., the CancelOnEvent class should have a "did-I-cancel" flag which is set in the _cancel_on_event() callback. Then if that flag is set it should call .uncancel(), and if that returns a value > 0, it should bubble the CancelledError out; otherwise it can raise EventRaised (if the condition is set).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Wed Feb 23 12:03:30 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 23 Feb 2022 17:03:30 +0000
Subject: [issue46829] Confusing CancelError message if multiple cancellations
 are scheduled
In-Reply-To: <1645567371.24.0.086924022035.issue46829@roundup.psfhosted.org>
Message-ID: <1645635810.78.0.685037384352.issue46829@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

For reference, the msg parameter of Task.cancel() was added in issue31033.

It seems that the initial use case was for debugging. I do not see how it differs from the following example:

    r = random.random()
    if r < 0.5:
        x = 0
    else:
        x = 0
    1/x

In the traceback we see the line where an error occurred but we do not see a line which lead to this error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46829>
_______________________________________

From report at bugs.python.org  Wed Feb 23 12:07:41 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 17:07:41 +0000
Subject: [issue46430] intern strings in deepfrozen modules
In-Reply-To: <1642590983.92.0.896257318647.issue46430@roundup.psfhosted.org>
Message-ID: <1645636061.0.0.862078924789.issue46430@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> New changeset c0a5ebeb1239020f2ecc199053bb1a70d78841a1 by Kumar Aditya in branch 'main':
> bpo-46430: Intern strings in deep-frozen modules  (GH-30683)

This change introduced a memory leak at Python exit.

Before:

$ ./python -X showrefcount -c pass
[0 refs, 0 blocks]

After:

$ ./python -X showrefcount -c pass
[0 refs, 344 blocks]

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46430>
_______________________________________

From report at bugs.python.org  Wed Feb 23 12:09:20 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 17:09:20 +0000
Subject: [issue46430] intern strings in deepfrozen modules
In-Reply-To: <1642590983.92.0.896257318647.issue46430@roundup.psfhosted.org>
Message-ID: <1645636160.03.0.897987068396.issue46430@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> This change introduced a memory leak at Python exit.

It's regression related to bpo-1635741 which I fixed recently:
https://mail.python.org/archives/list/python-dev at python.org/thread/E4C6TDNVDPDNNP73HTGHN5W42LGAE22F/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46430>
_______________________________________

From report at bugs.python.org  Wed Feb 23 12:10:54 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 17:10:54 +0000
Subject: [issue46430] intern strings in deepfrozen modules
In-Reply-To: <1642590983.92.0.896257318647.issue46430@roundup.psfhosted.org>
Message-ID: <1645636254.6.0.791216065325.issue46430@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

_PyStaticCode_InternStrings() error handling is based on assert(): that's really bad. It can crash Python (exit with abort()) at the first memory allocation failure. Why not returning -1 on error?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46430>
_______________________________________

From report at bugs.python.org  Wed Feb 23 12:14:28 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 17:14:28 +0000
Subject: [issue46668] encodings: the "mbcs" alias doesn't work
In-Reply-To: <1644188809.05.0.861398707442.issue46668@roundup.psfhosted.org>
Message-ID: <1645636468.42.0.753207832121.issue46668@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

commit ccbe8045faf6e63d36229ea4e1b9298572cda126
Author: Victor Stinner <vstinner at python.org>
Date:   Tue Feb 22 22:04:07 2022 +0100

    bpo-46659: Fix the MBCS codec alias on Windows (GH-31218)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46668>
_______________________________________

From report at bugs.python.org  Wed Feb 23 12:16:40 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 17:16:40 +0000
Subject: [issue45412] [C API] Remove Py_OVERFLOWED(),
 Py_SET_ERRNO_ON_MATH_ERROR(), Py_ADJUST_ERANGE1()
In-Reply-To: <1633700351.81.0.101355063932.issue45412@roundup.psfhosted.org>
Message-ID: <1645636600.95.0.837682624787.issue45412@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 9bbdde218005f552304d9954bb97e3f9185edded by Victor Stinner in branch 'main':
bpo-45412: Add _PY_SHORT_FLOAT_REPR macro (GH-31171)
https://github.com/python/cpython/commit/9bbdde218005f552304d9954bb97e3f9185edded


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45412>
_______________________________________

From report at bugs.python.org  Wed Feb 23 12:18:00 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 17:18:00 +0000
Subject: [issue45412] [C API] Remove Py_OVERFLOWED(),
 Py_SET_ERRNO_ON_MATH_ERROR(), Py_ADJUST_ERANGE1()
In-Reply-To: <1633700351.81.0.101355063932.issue45412@roundup.psfhosted.org>
Message-ID: <1645636680.04.0.754988249517.issue45412@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

See also bpo-46670: "Build Python with -Wundef: don't use undefined macros".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45412>
_______________________________________

From report at bugs.python.org  Wed Feb 23 12:20:03 2022
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 23 Feb 2022 17:20:03 +0000
Subject: [issue46836] [C API] Move PyFrameObject to the internal C API
In-Reply-To: <1645628652.12.0.0785803095185.issue46836@roundup.psfhosted.org>
Message-ID: <1645636803.67.0.383592754309.issue46836@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

So, this will break Cython and gevent, but (unlike the optimization work that broke f_code/f_frame) it won't provide any value to users?

I don't see how that's a good idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46836>
_______________________________________

From report at bugs.python.org  Wed Feb 23 12:27:01 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 17:27:01 +0000
Subject: [issue46836] [C API] Move PyFrameObject to the internal C API
In-Reply-To: <1645628652.12.0.0785803095185.issue46836@roundup.psfhosted.org>
Message-ID: <1645637221.09.0.421435269296.issue46836@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Petr Viktorin:
> So, this will break Cython and gevent,

This change doesn't break Cython and gevent: they are already broken.


> but (unlike the optimization work that broke f_code/f_frame) it won't provide any value to users?

The problem is that the C API changed silently: existing code which gets directly PyFrameObject.f_back still compiles successfully, but it will no longer work in some cases.

See bpo-46356 "[C API] Enforce usage of PyFrame_GetBack()" for more details.

The intent of moving the structure to the internal C API is to clarify its status: we provide no backward compatibility warranty, you are on our own if you use it.

It's also a way to promote the usage of the new clean public C API: it is now reliable, whereas accessing directly PyFrameObject members break at each Python version.

The internal C API cannot be used easily on purpose: you have to opt-in for this API by defining the Py_BUILD_CORE_MODULE macro and you need to use different #include. It's a way to enforce the usage of the clean public C API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46836>
_______________________________________

From report at bugs.python.org  Wed Feb 23 12:27:45 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 23 Feb 2022 17:27:45 +0000
Subject: [issue45390] asyncio.Task doesn't propagate CancelledError()
 exception correctly.
In-Reply-To: <1633519842.27.0.396754460358.issue45390@roundup.psfhosted.org>
Message-ID: <1645637265.64.0.953578636346.issue45390@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Also Future.result() and Future.exception() can raise a CancelledError. So a CancelledError raised in a task may not contain a message passed to Task.cancel().

import asyncio
import random

async def main():
    fut = asyncio.Future()
    fut.cancel()
    async def job():
        if random.random() < 0.5:
            await asyncio.sleep(2)
        fut.result()
        await asyncio.sleep(5)
    task = asyncio.create_task(job())
    await asyncio.sleep(1)
    task.cancel("cancel task")
    await task

asyncio.run(main())

You need to catch a CancelledError raised in a coroutine and re-raise a new CancelledError with the specified cancel message if the task was cancelled.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45390>
_______________________________________

From report at bugs.python.org  Wed Feb 23 12:38:54 2022
From: report at bugs.python.org (Jigar Gajjar)
Date: Wed, 23 Feb 2022 17:38:54 +0000
Subject: [issue46837] lstrip and strip not working as expected
Message-ID: <1645637934.57.0.221676088435.issue46837@roundup.psfhosted.org>


New submission from Jigar Gajjar <jigar030 at gmail.com>:

Code:

my_string = 'Auth:AWS'
print(my_string.lstrip('Auth:'))


Actual Output:

WS

Excepted Output:

AWS

----------
messages: 413831
nosy: jigar030
priority: normal
severity: normal
status: open
title: lstrip and strip not working as expected
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46837>
_______________________________________

From report at bugs.python.org  Wed Feb 23 12:41:32 2022
From: report at bugs.python.org (Jigar Gajjar)
Date: Wed, 23 Feb 2022 17:41:32 +0000
Subject: [issue46837] lstrip and strip not working as expected
In-Reply-To: <1645637934.57.0.221676088435.issue46837@roundup.psfhosted.org>
Message-ID: <1645638092.63.0.0120319029663.issue46837@roundup.psfhosted.org>


Change by Jigar Gajjar <jigar030 at gmail.com>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46837>
_______________________________________

From report at bugs.python.org  Wed Feb 23 12:45:34 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 23 Feb 2022 17:45:34 +0000
Subject: [issue46430] intern strings in deepfrozen modules
In-Reply-To: <1642590983.92.0.896257318647.issue46430@roundup.psfhosted.org>
Message-ID: <1645638334.9.0.773603047763.issue46430@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Okay, let's change the error handling. @Kumar, can you handle that?

@Victor, the refleak is unrelated to the error handling right? Presumably the leak is imaginary -- the deep-frozen interned strings should be accounted for somehow. @Kumar do you need help investigating this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46430>
_______________________________________

From report at bugs.python.org  Wed Feb 23 12:48:42 2022
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Wed, 23 Feb 2022 17:48:42 +0000
Subject: [issue46835] ImportError: bad magic number in ... does not indicate
 where is that file located
In-Reply-To: <1645620216.31.0.535281755903.issue46835@roundup.psfhosted.org>
Message-ID: <1645638522.6.0.284167081745.issue46835@roundup.psfhosted.org>


Change by Miro Hron?ok <miro at hroncok.cz>:


----------
keywords: +patch
pull_requests: +29658
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31534

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46835>
_______________________________________

From report at bugs.python.org  Wed Feb 23 12:49:02 2022
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 23 Feb 2022 17:49:02 +0000
Subject: [issue46761] functools.update_wrapper breaks the signature of
 functools.partial objects
In-Reply-To: <1644948374.87.0.765462873315.issue46761@roundup.psfhosted.org>
Message-ID: <1645638542.27.0.533334963222.issue46761@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

Ofey, I appreciate your enthusiasm, but you should probably slow down.  Fixing the bug is probably going to be the easy part here.  But we're not to that stage quite yet.  First, we need to determine

* why the code behaves like this--is this behavior a genuine bug, or is it actually a bugfix for some worse behavior?
* will fixing the bug cause problems for Python users? and if so, can we still fix the bug while mitigating the damage to people who are unfortunately depending on the bug?

The next step is not to write a bugfix for this exact behavior, it's to determine why the code is the way it is.  If it was genuinely just a mistake, and we can simply fix it and people will thank us, then we may have a use for your patch.  But, generally, people who work on Python are smart, and they don't tend to commit dumb mistakes, so we can't simply assume it's a simple bug and fix it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46761>
_______________________________________

From report at bugs.python.org  Wed Feb 23 12:53:26 2022
From: report at bugs.python.org (Yves Duprat)
Date: Wed, 23 Feb 2022 17:53:26 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645638806.38.0.240962157494.issue46771@roundup.psfhosted.org>


Change by Yves Duprat <yduprat at gmail.com>:


----------
nosy: +yduprat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Wed Feb 23 12:59:36 2022
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 23 Feb 2022 17:59:36 +0000
Subject: [issue46736] Generate HTML 5 with
 SimpleHTTPRequestHandler.list_directory
In-Reply-To: <1644741188.03.0.745095490398.issue46736@roundup.psfhosted.org>
Message-ID: <1645639176.38.0.175960015691.issue46736@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 0bb40a42d71873ea267aace8c92a02d66fe36dc2 by Dong-hee Na in branch 'main':
closes bpo-46736: SimpleHTTPRequestHandler now uses HTML5. (GH-31533)
https://github.com/python/cpython/commit/0bb40a42d71873ea267aace8c92a02d66fe36dc2


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46736>
_______________________________________

From report at bugs.python.org  Wed Feb 23 12:59:44 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 17:59:44 +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: <1645639184.77.0.741281495791.issue40421@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29659
pull_request: https://github.com/python/cpython/pull/31535

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40421>
_______________________________________

From report at bugs.python.org  Wed Feb 23 13:00:46 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 18:00:46 +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: <1645639246.36.0.49113015064.issue40421@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> The docs for PyFrame_GetCode say it's returning an "int". 

Oh. I  missed your comment. I created GH-31535 to fix the return type in the documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40421>
_______________________________________

From report at bugs.python.org  Wed Feb 23 13:02:00 2022
From: report at bugs.python.org (Thomas Grainger)
Date: Wed, 23 Feb 2022 18:02:00 +0000
Subject: [issue45390] asyncio.Task doesn't propagate CancelledError()
 exception correctly.
In-Reply-To: <1633519842.27.0.396754460358.issue45390@roundup.psfhosted.org>
Message-ID: <1645639320.73.0.643679860491.issue45390@roundup.psfhosted.org>


Thomas Grainger <tagrain at gmail.com> added the comment:

there could be multiple messages here

perhaps it could be:

```
        finally:
            # Must reacquire lock even if wait is cancelled
            cancelled = []
            while True:
                try:
                    await self.acquire()
                    break
                except exceptions.CancelledError as e:
                    cancelled.append(e)

            if len(cancelled) > 1:
                raise ExceptionGroup("Cancelled", cancelled)
            if cancelled:
                raise cancelled[0]
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45390>
_______________________________________

From report at bugs.python.org  Wed Feb 23 13:02:44 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 18:02:44 +0000
Subject: [issue46430] intern strings in deepfrozen modules
In-Reply-To: <1642590983.92.0.896257318647.issue46430@roundup.psfhosted.org>
Message-ID: <1645639364.1.0.587735064281.issue46430@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Presumably the leak is imaginary

Well, you can check with your favorite memory debugger like Valgrind if you don't trust Python internal memory debugger :-)

Not leaking memory at exit matters when Python is embedded in an application.

I don't think that it's related to the error handling which is stripped in release mode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46430>
_______________________________________

From report at bugs.python.org  Wed Feb 23 13:04:42 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 23 Feb 2022 18:04:42 +0000
Subject: [issue45390] asyncio.Task doesn't propagate CancelledError()
 exception correctly.
In-Reply-To: <1633519842.27.0.396754460358.issue45390@roundup.psfhosted.org>
Message-ID: <1645639482.66.0.732306366794.issue45390@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

We should really stop appending to a closed issue.

Anyway, raising ExceptionGroup is backwards incompatible, since "except CancelledError" wouldn't cancel the group.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45390>
_______________________________________

From report at bugs.python.org  Wed Feb 23 13:07:16 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 23 Feb 2022 18:07:16 +0000
Subject: [issue46430] intern strings in deepfrozen modules
In-Reply-To: <1642590983.92.0.896257318647.issue46430@roundup.psfhosted.org>
Message-ID: <1645639636.62.0.898021422046.issue46430@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

> Not leaking memory at exit matters when Python is embedded
> in an application.

Sure, but "leaks" caused by deep-freezing cannot be solved by freeing up the deep-frozen memory -- the solution must be to update the accounting somewhere.

Where is the existence of Py_None accounted for (since it's statically allocated, or at least used to be)? That's likely where we'd have to do something about the deep-frozen objects.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46430>
_______________________________________

From report at bugs.python.org  Wed Feb 23 13:21:11 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 23 Feb 2022 18:21:11 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645640471.65.0.527290264583.issue46771@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Clear, thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Wed Feb 23 13:26:20 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 23 Feb 2022 18:26:20 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645640780.2.0.508023122391.issue46771@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

I will now merge GH-31513 (cancel counts). Once that's in you can merge main into your timeout PR (GH-31394) and then that can land soon (I'd like to review it once more).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Wed Feb 23 13:33:46 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 18:33:46 +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: <1645641226.97.0.807189251613.issue40421@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Ned Batchelder:
> I went ahead and changed the coverage.py code to this: (...)

I proposed a coverage PR using PyObject_GetAttrString(frame, "f_lasti") which should works on all Python versions:
https://github.com/nedbat/coveragepy/pull/1331

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40421>
_______________________________________

From report at bugs.python.org  Wed Feb 23 13:36:48 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 18:36:48 +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: <1645641408.58.0.358301345122.issue40421@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29660
pull_request: https://github.com/python/cpython/pull/31536

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40421>
_______________________________________

From report at bugs.python.org  Wed Feb 23 13:39:38 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 18:39:38 +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: <1645641578.64.0.887854301429.issue40421@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Mark Shannon:
> The only purpose of `f_lasti` is to get the line number and that can be done directly via `PyFrame_GetLineNumber(PyFrameObject *frame)`

I found the uwsgi project on PyPI which uses f_lasti with PyCode_Addr2Line(). I wrote GH-31536 to suggest using PyFrame_GetLineNumber() in What's New in Python 3.11.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40421>
_______________________________________

From report at bugs.python.org  Wed Feb 23 13:48:51 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 18:48:51 +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: <1645642131.81.0.455624891269.issue40421@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> I found the uwsgi project on PyPI which uses f_lasti with PyCode_Addr2Line().

Oh, plugins/python/profiler.c uses that to define PyFrame_GetLineNumber() on Python older than 2.7, Python 3.0 and Python 3.1. In 2022, it's no longer relevant.

But well, there might be other code in the wild using PyCode_Addr2Line() with f_lasti, so IMO it's worth it to document the suggestion ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40421>
_______________________________________

From report at bugs.python.org  Wed Feb 23 13:49:34 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 23 Feb 2022 18:49:34 +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: <1645642174.63.0.502945205602.issue40421@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: +29661
pull_request: https://github.com/python/cpython/pull/31537

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40421>
_______________________________________

From report at bugs.python.org  Wed Feb 23 13:49:31 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 18:49:31 +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: <1645642171.42.0.110312524338.issue40421@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 78859e58e4e016286e648d1dc155e0f6cebfa6ff by Victor Stinner in branch 'main':
bpo-40421: Fix PyFrame_GetCode() documentation (GH-31535)
https://github.com/python/cpython/commit/78859e58e4e016286e648d1dc155e0f6cebfa6ff


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40421>
_______________________________________

From report at bugs.python.org  Wed Feb 23 13:50:36 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 23 Feb 2022 18:50:36 +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: <1645642236.64.0.022181234006.issue40421@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29662
pull_request: https://github.com/python/cpython/pull/31538

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40421>
_______________________________________

From report at bugs.python.org  Wed Feb 23 13:53:33 2022
From: report at bugs.python.org (Brandt Bucher)
Date: Wed, 23 Feb 2022 18:53:33 +0000
Subject: [issue44337] Port LOAD_ATTR to adaptive interpreter
In-Reply-To: <1623089020.4.0.120322851148.issue44337@roundup.psfhosted.org>
Message-ID: <1645642413.4.0.267683812993.issue44337@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:


New changeset 281ea9c39146a00cdf3fa2b3d0be60e2a39278ce by Brandt Bucher in branch 'main':
bpo-44337: Shrink the LOAD_ATTR/STORE_ATTR caches (GH-31517)
https://github.com/python/cpython/commit/281ea9c39146a00cdf3fa2b3d0be60e2a39278ce


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44337>
_______________________________________

From report at bugs.python.org  Wed Feb 23 13:58:10 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 18:58:10 +0000
Subject: [issue46430] intern strings in deepfrozen modules
In-Reply-To: <1642590983.92.0.896257318647.issue46430@roundup.psfhosted.org>
Message-ID: <1645642690.26.0.12125581293.issue46430@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Sure, but "leaks" caused by deep-freezing cannot be solved by freeing up the deep-frozen memory -- the solution must be to update the accounting somewhere.

Python allocates memory (ex: with PyObject_Malloc()) which is not released at exit. Two examples from Valgrind:

==196803== 50 bytes in 1 blocks are still reachable in loss record 1 of 87
==196803==    at 0x484486F: malloc (vg_replace_malloc.c:381)
==196803==    by 0x544E29: _PyMem_RawMalloc (obmalloc.c:101)
==196803==    by 0x545E0E: PyObject_Malloc (obmalloc.c:700)
==196803==    by 0x587159: PyUnicode_New (unicodeobject.c:1448)
==196803==    by 0x58C4CF: get_latin1_char (unicodeobject.c:2148)
==196803==    by 0x58D7F7: _PyUnicode_FromUCS1 (unicodeobject.c:2450)
==196803==    by 0x58E374: PyUnicode_FromKindAndData (unicodeobject.c:2525)
==196803==    by 0x69402B: r_object (marshal.c:1150)
==196803==    by 0x694295: r_object (marshal.c:1212)
==196803==    by 0x694AE0: r_object (marshal.c:1393)
==196803==    by 0x694295: r_object (marshal.c:1212)
==196803==    by 0x694AA4: r_object (marshal.c:1387)
==196803==    by 0x6950F3: read_object (marshal.c:1524)
==196803==    by 0x6953E7: PyMarshal_ReadObjectFromString (marshal.c:1641)
==196803==    by 0x763223: _Py_Get_Getpath_CodeObject (getpath.c:792)
==196803==    by 0x76337F: _PyConfig_InitPathConfig (getpath.c:847)
==196803==    by 0x68CD04: config_init_import (initconfig.c:1967)
==196803==    by 0x68CE4E: _PyConfig_InitImportConfig (initconfig.c:2000)
==196803==    by 0x69E594: init_interp_main (pylifecycle.c:1103)
==196803==    by 0x69EBF8: pyinit_main (pylifecycle.c:1216)
==196803==    by 0x69EDCE: Py_InitializeFromConfig (pylifecycle.c:1247)
==196803==    by 0x6D5346: pymain_init (main.c:67)
==196803==    by 0x6D64F8: pymain_main (main.c:692)
==196803==    by 0x6D65A1: Py_BytesMain (main.c:725)
==196803==    by 0x41D7B5: main (python.c:15)

and

==196803== 3,336 bytes in 60 blocks are still reachable in loss record 87 of 87
==196803==    at 0x484486F: malloc (vg_replace_malloc.c:381)
==196803==    by 0x544E29: _PyMem_RawMalloc (obmalloc.c:101)
==196803==    by 0x545E0E: PyObject_Malloc (obmalloc.c:700)
==196803==    by 0x587159: PyUnicode_New (unicodeobject.c:1448)
==196803==    by 0x59AEB9: unicode_decode_utf8 (unicodeobject.c:5162)
==196803==    by 0x59B5B0: PyUnicode_DecodeUTF8Stateful (unicodeobject.c:5292)
==196803==    by 0x58D296: PyUnicode_FromString (unicodeobject.c:2322)
==196803==    by 0x5CFFAE: PyUnicode_InternFromString (unicodeobject.c:15650)
==196803==    by 0x4E8B61: descr_new (descrobject.c:885)
==196803==    by 0x4E8C9B: PyDescr_NewMethod (descrobject.c:934)
==196803==    by 0x56694C: type_add_method (typeobject.c:5643)
==196803==    by 0x566A92: type_add_methods (typeobject.c:5689)
==196803==    by 0x569166: type_ready_fill_dict (typeobject.c:6165)
==196803==    by 0x569A02: type_ready (typeobject.c:6421)
==196803==    by 0x569B59: PyType_Ready (typeobject.c:6457)
==196803==    by 0x544363: _PyTypes_InitTypes (object.c:1952)
==196803==    by 0x69D12D: pycore_init_types (pylifecycle.c:704)
==196803==    by 0x69D8FC: pycore_interp_init (pylifecycle.c:831)
==196803==    by 0x69DC31: pyinit_config (pylifecycle.c:887)
==196803==    by 0x69E355: pyinit_core (pylifecycle.c:1050)
==196803==    by 0x69ED32: Py_InitializeFromConfig (pylifecycle.c:1240)
==196803==    by 0x6D5346: pymain_init (main.c:67)
==196803==    by 0x6D64F8: pymain_main (main.c:692)
==196803==    by 0x6D65A1: Py_BytesMain (main.c:725)
==196803==    by 0x41D7B5: main (python.c:15)

Before the commit c0a5ebeb1239020f2ecc199053bb1a70d78841a1, Python didn't leak this memory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46430>
_______________________________________

From report at bugs.python.org  Wed Feb 23 13:58:31 2022
From: report at bugs.python.org (Brandt Bucher)
Date: Wed, 23 Feb 2022 18:58:31 +0000
Subject: =?utf-8?q?=5Bissue46754=5D_Improve_Python_Language_Reference_based_on_=5B?=
 =?utf-8?b?S8O2aGwgMjAyMF0=?=
In-Reply-To: <1644887951.55.0.170879911355.issue46754@roundup.psfhosted.org>
Message-ID: <1645642711.35.0.428516286974.issue46754@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
nosy: +brandtbucher

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46754>
_______________________________________

From report at bugs.python.org  Wed Feb 23 13:58:59 2022
From: report at bugs.python.org (Brandt Bucher)
Date: Wed, 23 Feb 2022 18:58:59 +0000
Subject: [issue45107] Improve LOAD_METHOD specialization
In-Reply-To: <1630859956.74.0.360849757822.issue45107@roundup.psfhosted.org>
Message-ID: <1645642739.51.0.330636489371.issue45107@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
nosy: +brandtbucher

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45107>
_______________________________________

From report at bugs.python.org  Wed Feb 23 13:59:35 2022
From: report at bugs.python.org (Brandt Bucher)
Date: Wed, 23 Feb 2022 18:59:35 +0000
Subject: [issue46823] Add LOAD_FAST__LOAD_ATTR_INSTACE_VALUE combined opcode
In-Reply-To: <1645506714.72.0.112858305238.issue46823@roundup.psfhosted.org>
Message-ID: <1645642775.05.0.951593481463.issue46823@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
nosy: +brandtbucher

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46823>
_______________________________________

From report at bugs.python.org  Wed Feb 23 14:13:03 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 23 Feb 2022 19:13:03 +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: <1645643583.01.0.883774680498.issue40421@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b0de6299a840a397d4fe3e6c98159d9f258d3295 by Miss Islington (bot) in branch '3.10':
bpo-40421: Fix PyFrame_GetCode() documentation (GH-31535)
https://github.com/python/cpython/commit/b0de6299a840a397d4fe3e6c98159d9f258d3295


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40421>
_______________________________________

From report at bugs.python.org  Wed Feb 23 14:16:14 2022
From: report at bugs.python.org (miss-islington)
Date: Wed, 23 Feb 2022 19:16:14 +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: <1645643774.66.0.850273474797.issue40421@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 763e23e11e785162f9d68f83539404af8e863748 by Miss Islington (bot) in branch '3.9':
bpo-40421: Fix PyFrame_GetCode() documentation (GH-31535)
https://github.com/python/cpython/commit/763e23e11e785162f9d68f83539404af8e863748


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40421>
_______________________________________

From report at bugs.python.org  Wed Feb 23 14:20:07 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 19:20:07 +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: <1645644007.76.0.769045282444.issue40421@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 8a716bc62c8205bb9deeda17422b7e69204b6897 by Victor Stinner in branch 'main':
bpo-40421: What's New in Python 3.11: PyFrameObject.f_lasti (GH-31536)
https://github.com/python/cpython/commit/8a716bc62c8205bb9deeda17422b7e69204b6897


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40421>
_______________________________________

From report at bugs.python.org  Wed Feb 23 14:23:33 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 19:23:33 +0000
Subject: [issue45459] Limited API support for Py_buffer
In-Reply-To: <1634118913.79.0.141868262007.issue45459@roundup.psfhosted.org>
Message-ID: <1645644213.96.0.151853837165.issue45459@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29663
pull_request: https://github.com/python/cpython/pull/31539

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45459>
_______________________________________

From report at bugs.python.org  Wed Feb 23 14:28:19 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 23 Feb 2022 19:28:19 +0000
Subject: [issue46430] intern strings in deepfrozen modules
In-Reply-To: <1642590983.92.0.896257318647.issue46430@roundup.psfhosted.org>
Message-ID: <1645644499.19.0.942028147892.issue46430@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

That's pretty mysterious. The deep-freeze code isn't on the stack for either of those, but allocation of new unicode string objects is. I'm guessing these are somehow leaked by the interning, but I don't follow yet how.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46430>
_______________________________________

From report at bugs.python.org  Wed Feb 23 14:44:47 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 19:44:47 +0000
Subject: [issue46430] intern strings in deepfrozen modules
In-Reply-To: <1642590983.92.0.896257318647.issue46430@roundup.psfhosted.org>
Message-ID: <1645645487.79.0.973481081191.issue46430@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

PyUnicode_InternInPlace() in intern_strings() can convert an immortal string to a regular Python strong reference, whereas _PyStaticCode_Dealloc() doesn't bother with clearing co_names, co_consts and co_localsplusnames.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46430>
_______________________________________

From report at bugs.python.org  Wed Feb 23 14:45:04 2022
From: report at bugs.python.org (Stefan Behnel)
Date: Wed, 23 Feb 2022 19:45:04 +0000
Subject: [issue46836] [C API] Move PyFrameObject to the internal C API
In-Reply-To: <1645628652.12.0.0785803095185.issue46836@roundup.psfhosted.org>
Message-ID: <1645645504.1.0.593995196349.issue46836@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

I haven't looked fully into this yet, but I *think* that Cython can get rid of most of the direct usages of PyFrameObject by switching to the new InterpreterFrame struct instead. It looks like the important fields have now been moved over to that.

That won't improve the situation regarding the usage of CPython internals, but it's probably worth keeping in mind before we start adding new API functions that work on frame objects.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46836>
_______________________________________

From report at bugs.python.org  Wed Feb 23 14:48:12 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 19:48:12 +0000
Subject: [issue46836] [C API] Move PyFrameObject to the internal C API
In-Reply-To: <1645628652.12.0.0785803095185.issue46836@roundup.psfhosted.org>
Message-ID: <1645645692.76.0.120824838071.issue46836@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Stefan Behnel:
> I haven't looked fully into this yet, but I *think* that Cython can get rid of most of the direct usages of PyFrameObject by switching to the new InterpreterFrame struct instead. It looks like the important fields have now been moved over to that.

InterpreterFrame is part of the internal C API. As I wrote, IMO it's fine for now that Cython uses the internal C API.

> That won't improve the situation regarding the usage of CPython internals, but it's probably worth keeping in mind before we start adding new API functions that work on frame objects.

Right.

My hope is also that making the structure internal should help to identify which members should be exposed with getter functions, or even setter functions (Mark would prefer to no add setter functions).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46836>
_______________________________________

From report at bugs.python.org  Wed Feb 23 15:33:02 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 20:33:02 +0000
Subject: [issue46430] intern strings in deepfrozen modules
In-Reply-To: <1642590983.92.0.896257318647.issue46430@roundup.psfhosted.org>
Message-ID: <1645648382.61.0.882189137185.issue46430@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I tried to hack _PyStaticCode_Dealloc() to free strings, but since immortal objects are half-baken today, calling Py_DECREF() does crash.

Py_SETREF() should increase _Py_RefTotal if the old object is immortal and he new object is not.

Maybe this change should be reverted until Eric's PEP 683 "Immortal Objects, Using a Fixed Refcount" is implemented.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46430>
_______________________________________

From report at bugs.python.org  Wed Feb 23 16:23:21 2022
From: report at bugs.python.org (Andrej Klychin)
Date: Wed, 23 Feb 2022 21:23:21 +0000
Subject: [issue46838] Parameters and arguments parser syntax error improvments
Message-ID: <1645651401.14.0.658565183507.issue46838@roundup.psfhosted.org>


New submission from Andrej Klychin <andy_kl at bk.ru>:

I saw that pablogsal welcomed improvments to the parser's suggestions, so here are the messages for parameters and arguments lists I think should be written instead of the current generic "invalid syntax".

>>> def foo(*arg, *arg): pass
SyntaxError: * argument may appear only once

>>> def foo(**arg, **arg): pass
SyntaxError: ** argument may appear only once

>>> def foo(arg1, /, arg2, /, arg3): pass
SyntaxError: / may appear only once

>>> def foo(*args, /, arg): pass
SyntaxError: / must be ahead of *

>>> def foo(/, arg): pass
SyntaxError: at least one argument must precede /

>>> def foo(arg=): pass
SyntaxError: expected default value expression

>>> def foo(*args=None): pass
SyntaxError: * argument cannot have default value

>>> def foo(**kwargs=None): pass
SyntaxError: ** argument cannot have default value

>>> foo(*args=[0])
SyntaxError: cannot assign to iterable argument unpacking

>>> foo(**args={"a": None})
SyntaxError: cannot assign to keyword argument unpacking

>>> foo(arg=)
SyntaxError: expected argument value expression

----------
components: Parser
messages: 413856
nosy: Andy_kl, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Parameters and arguments parser syntax error improvments
type: enhancement
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46838>
_______________________________________

From report at bugs.python.org  Wed Feb 23 16:27:45 2022
From: report at bugs.python.org (Barney Gale)
Date: Wed, 23 Feb 2022 21:27:45 +0000
Subject: [issue44136] Remove pathlib flavours
In-Reply-To: <1621016938.4.0.46024543706.issue44136@roundup.psfhosted.org>
Message-ID: <1645651665.67.0.225829353407.issue44136@roundup.psfhosted.org>


Barney Gale <barney.gale at gmail.com> added the comment:

^ just to bring my previous comment up-to-date:

I'm no longer pursuing adding `os.path.isreserved()` and `os.path.fileuri()` functions, or modifying `normpath()`. At least, not for now!

Instead, my plan is to move flavour functionality as follows (as classmethods with underscore prefixes):

  _Flavour        --> PurePath
  _PosixFlavour   --> PurePath
  _WindowsFlavour --> PureWindowsPath

As a result, PurePath will use POSIX syntax by default. This is fully backwards-compatible, as users can't create PurePath objects! PurePath.__new__() instantiates PurePosixPath or PureWindowsPath. But it will matter for future user subclasses of PurePath/Path, where we usually want POSIX syntax.

I think there will be three PRs involved. PR 30320 and PR 30321 move _Flavour.make_uri() and _Flavour.is_reserved() respectively; these are reasonably standalone. If/when they land, I'll make a larger PR that moves the remaining methods into PurePath and PureWindowsPath.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44136>
_______________________________________

From report at bugs.python.org  Wed Feb 23 16:31:02 2022
From: report at bugs.python.org (Andrej Klychin)
Date: Wed, 23 Feb 2022 21:31:02 +0000
Subject: [issue46838] Parameters and arguments parser syntax error improvments
In-Reply-To: <1645651401.14.0.658565183507.issue46838@roundup.psfhosted.org>
Message-ID: <1645651862.79.0.271060729107.issue46838@roundup.psfhosted.org>


Andrej Klychin <andy_kl at bk.ru> added the comment:

I also sometimes write def foo(pos_only, /*, kwarg): pass. Perhaps this can be special cased with 
SyntaxError: expected comma between / and *

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46838>
_______________________________________

From report at bugs.python.org  Wed Feb 23 16:31:32 2022
From: report at bugs.python.org (=?utf-8?q?Tin_Tvrtkovi=C4=87?=)
Date: Wed, 23 Feb 2022 21:31:32 +0000
Subject: [issue46752] Introduce task groups to asyncio and change task
 cancellation semantics
In-Reply-To: <1644871469.64.0.38816696304.issue46752@roundup.psfhosted.org>
Message-ID: <1645651892.23.0.100215767385.issue46752@roundup.psfhosted.org>


Change by Tin Tvrtkovi? <tinchester at gmail.com>:


----------
nosy: +tinchester
nosy_count: 6.0 -> 7.0
pull_requests: +29664
pull_request: https://github.com/python/cpython/pull/31513

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46752>
_______________________________________

From report at bugs.python.org  Wed Feb 23 16:36:16 2022
From: report at bugs.python.org (sami)
Date: Wed, 23 Feb 2022 21:36:16 +0000
Subject: [issue46839] Process finished with exit code -1073741819 (0xC0000005)
Message-ID: <1645652176.24.0.399924224142.issue46839@roundup.psfhosted.org>


New submission from sami <fazel.samira at gmail.com>:

Hi, 
I am running my python code for large data set and currently, I received this exit code: "Process finished with exit code -1073741819 (0xC0000005)"

I monitored via Event Viewer and found the following error. I wonder how I can solve this issue? Thanks

Faulting application name: python.exe, version: 0.0.0.0, time stamp: 0x56abcaee
Faulting module name: python27.dll, version: 2.7.11150.1013, time stamp: 0x56abcaed
Exception code: 0xc0000005
Fault offset: 0x00000000000a4f81
Faulting process id: 0x29d0
Faulting application start time: 0x01d8287ff03c7476
Faulting application path: C:\Users\sami\Anaconda2\python.exe
Faulting module path: C:\Users\sami\Anaconda2\python27.dll

----------
messages: 413859
nosy: fa.sami
priority: normal
severity: normal
status: open
title: Process finished with exit code -1073741819 (0xC0000005)
type: crash

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46839>
_______________________________________

From report at bugs.python.org  Wed Feb 23 16:46:37 2022
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 23 Feb 2022 21:46:37 +0000
Subject: [issue46838] Parameters and arguments parser syntax error improvments
In-Reply-To: <1645651401.14.0.658565183507.issue46838@roundup.psfhosted.org>
Message-ID: <1645652797.07.0.882753944159.issue46838@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Thanks a lot for the suggestions! I will try to give these a go to see if we can get them implemented. Parameter parsing is a bit hairy so not sure how lucky we will be but all of them make sense!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46838>
_______________________________________

From report at bugs.python.org  Wed Feb 23 16:49:25 2022
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 23 Feb 2022 21:49:25 +0000
Subject: [issue46839] Process finished with exit code -1073741819 (0xC0000005)
In-Reply-To: <1645652176.24.0.399924224142.issue46839@roundup.psfhosted.org>
Message-ID: <1645652965.44.0.927335706706.issue46839@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

0xc0000005 appears to be an access violation, but beyond that there's not much we can help with here.

For a start, Python 2.7 has been out of support for over 2 years now, and as far as I can easily tell Anaconda2 is no longer supported either.  It is highly recommended to update to Python 3.9 or later if at all possible.

Also, it seems likely that the problem is actually in a third-party extension module rather than Python itself, though it's impossible to tell for sure from what information is here.

For further assistance, you can try the Users category of discuss.python.org, the python-list at python.org mailing list, or a forum specific to Anaconda (though I'm not familiar with one myself).

----------
nosy: +zach.ware
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46839>
_______________________________________

From report at bugs.python.org  Wed Feb 23 16:51:16 2022
From: report at bugs.python.org (Ned Deily)
Date: Wed, 23 Feb 2022 21:51:16 +0000
Subject: [issue46794] Please update bundled libexpat to 2.4.6 with security
 fixes (5 CVEs)
In-Reply-To: <1645227388.68.0.727345462152.issue46794@roundup.psfhosted.org>
Message-ID: <1645653076.93.0.517830422183.issue46794@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 15d7594d9974cfef10e65cbb01161168c42abe9d by Miss Islington (bot) in branch '3.7':
bpo-46794: Bump up the libexpat version into 2.4.6 (GH-31487) (GH-31521)
https://github.com/python/cpython/commit/15d7594d9974cfef10e65cbb01161168c42abe9d


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46794>
_______________________________________

From report at bugs.python.org  Wed Feb 23 16:53:16 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 23 Feb 2022 21:53:16 +0000
Subject: =?utf-8?q?=5Bissue46754=5D_Improve_Python_Language_Reference_based_on_=5B?=
 =?utf-8?b?S8O2aGwgMjAyMF0=?=
In-Reply-To: <1644887951.55.0.170879911355.issue46754@roundup.psfhosted.org>
Message-ID: <1645653196.87.0.185058554979.issue46754@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

A few examples of issues brought up by Kohl:

- While the PLR explicitly states that ?x < y calls x.__lt__(y)?
  [20, ?3.3.1.] this is actually false.
  There are cases where x < y does not call x.__lt__(y)
  and there are other cases where x.__lt__(y) is called
  but more than that happens.

- If no expression is provided, the PLR states that
  ?the last exception that was active in the current scope?
  should be re-raised. Unfortunately, the PLR stays
  unspecific on what it means for an exception to be
  ?the last exception that was active in the current scope.
  [...]
  Instead, raise re-raises the exception that *is active*
  in the respective execution context

(Perhaps unrelated, but indicative of how out of date the PLR is: in executionmodel.rst there's still a mention of and even an index entry for restricted execution, a feature that was removed in some early Python 2 release.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46754>
_______________________________________

From report at bugs.python.org  Wed Feb 23 17:53:16 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 22:53:16 +0000
Subject: [issue46606] Large C stack usage of os.getgroups() and os.setgroups()
In-Reply-To: <1643771204.31.0.0513908090604.issue46606@roundup.psfhosted.org>
Message-ID: <1645656796.57.0.173905095625.issue46606@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

>  n++; // Avoid malloc(0)
> grouplist = PyMem_New(gid_t, n+1);

FYI PyMem_New(0) is well specified and doesn't return NULL:
https://docs.python.org/dev/c-api/memory.html#c.PyMem_Malloc

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46606>
_______________________________________

From report at bugs.python.org  Wed Feb 23 18:07:02 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 23 Feb 2022 23:07:02 +0000
Subject: =?utf-8?q?=5Bissue46754=5D_Improve_Python_Language_Reference_based_on_=5B?=
 =?utf-8?b?S8O2aGwgMjAyMF0=?=
In-Reply-To: <1644887951.55.0.170879911355.issue46754@roundup.psfhosted.org>
Message-ID: <1645657622.74.0.704642697361.issue46754@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Another:

- The description of this name binding and resolution process
  in the PLR [20, ?4.2.] is unfortunately not particularly clear.

(I found this to be the case too, and wrote up what I found:
https://gvanrossum.github.io/formal/scopesblog.html
Hopefully it matches what Kohl derived.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46754>
_______________________________________

From report at bugs.python.org  Wed Feb 23 18:25:06 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2022 23:25:06 +0000
Subject: [issue46623] test_zlib: test_pair() and test_speech128() fail with
 s390x hardware accelerator
In-Reply-To: <1643877280.17.0.469977325894.issue46623@roundup.psfhosted.org>
Message-ID: <1645658706.97.0.916435241901.issue46623@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I checked os.uname() value on two buildbots, by looking at their test.pythoninfo:

os.uname: posix.uname_result(sysname='Linux', nodename='ztcpip3.pok.ibm.com', release='3.10.0-1160.53.1.el7.s390x', version='#1 SMP Thu Dec 16 04:33:52 EST 2021', machine='s390x')

os.uname: posix.uname_result(sysname='Linux', nodename='dje', release='5.10.0-11-s390x', version='#1 SMP Debian 5.10.92-1 (2022-01-18)', machine='s390x')

So the machine is 's390x'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46623>
_______________________________________

From report at bugs.python.org  Wed Feb 23 19:07:17 2022
From: report at bugs.python.org (Samwyse)
Date: Thu, 24 Feb 2022 00:07:17 +0000
Subject: [issue23041] csv needs more quoting rules
In-Reply-To: <1418402205.61.0.685044268577.issue23041@psf.upfronthosting.co.za>
Message-ID: <1645661237.59.0.111126521556.issue23041@roundup.psfhosted.org>


Samwyse <samwyse at gmail.com> added the comment:

I just signed the contributor agreement. (Thought I had done that last year but I don?t see any emails. Is there any place to check?)

I agree that round-tripping should Bebe possible for any value of quoting.

Hopefully this will finally get done before its eighth birthday.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23041>
_______________________________________

From report at bugs.python.org  Wed Feb 23 19:32:02 2022
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Feb 2022 00:32:02 +0000
Subject: [issue13475] Add '--mainpath'/'--nomainpath' command line options to
 override sys.path[0] initialisation
In-Reply-To: <1322181994.22.0.955887054946.issue13475@psf.upfronthosting.co.za>
Message-ID: <1645662722.48.0.17966617612.issue13475@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

See also "Python flag/envvar not to put current directory to sys.path (but don?t ignore PYTHONPATH)" discussion:
https://discuss.python.org/t/python-flag-envvar-not-to-put-current-directory-to-sys-path-but-dont-ignore-pythonpath/4235/2

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13475>
_______________________________________

From report at bugs.python.org  Wed Feb 23 19:38:48 2022
From: report at bugs.python.org (Nikolay Markov)
Date: Thu, 24 Feb 2022 00:38:48 +0000
Subject: [issue24313] json fails to serialise numpy.int64
In-Reply-To: <1432801951.51.0.0124262456045.issue24313@psf.upfronthosting.co.za>
Message-ID: <1645663128.27.0.956391376339.issue24313@roundup.psfhosted.org>


Nikolay Markov <nikolai.markov at icloud.com> added the comment:

Just ran into this. Are there any updates? Is there any task to contribute to regarding this?

----------
nosy: +mxposed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24313>
_______________________________________

From report at bugs.python.org  Wed Feb 23 20:40:39 2022
From: report at bugs.python.org (Jerome Perrin)
Date: Thu, 24 Feb 2022 01:40:39 +0000
Subject: [issue46840] xmlrpc.client.ServerProxy shows password in __repr__
 when using basic authentication
Message-ID: <1645666839.94.0.152253377842.issue46840@roundup.psfhosted.org>


New submission from Jerome Perrin <jerome at nexedi.com>:

>>> import xmlrpc.client
>>> xmlrpc.client.ServerProxy('https://login:password at example.com')
<ServerProxy for login:password at example.com/RPC2>

Because this repr is included in error messages, this can lead to leaking the password:

>>> xmlrpc.client.ServerProxy('https://login:password at example.com').method()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.7/xmlrpc/client.py", line 1112, in __call__
    return self.__send(self.__name, args)
  File "/usr/lib/python3.7/xmlrpc/client.py", line 1452, in __request
    verbose=self.__verbose
  File "/usr/lib/python3.7/xmlrpc/client.py", line 1154, in request
    return self.single_request(host, handler, request_body, verbose)
  File "/usr/lib/python3.7/xmlrpc/client.py", line 1187, in single_request
    dict(resp.getheaders())
xmlrpc.client.ProtocolError: <ProtocolError for login:password at example.com/RPC2: 404 Not Found>

----------
components: Library (Lib)
messages: 413870
nosy: perrinjerome
priority: normal
severity: normal
status: open
title: xmlrpc.client.ServerProxy shows password in __repr__ when using basic authentication

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46840>
_______________________________________

From report at bugs.python.org  Wed Feb 23 20:54:09 2022
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Feb 2022 01:54:09 +0000
Subject: [issue13475] Add '--mainpath'/'--nomainpath' command line options to
 override sys.path[0] initialisation
In-Reply-To: <1322181994.22.0.955887054946.issue13475@psf.upfronthosting.co.za>
Message-ID: <1645667649.42.0.793583972753.issue13475@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29665
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31542

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13475>
_______________________________________

From report at bugs.python.org  Wed Feb 23 20:55:08 2022
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Feb 2022 01:55:08 +0000
Subject: [issue13475] Add '--mainpath'/'--nomainpath' command line options to
 override sys.path[0] initialisation
In-Reply-To: <1322181994.22.0.955887054946.issue13475@psf.upfronthosting.co.za>
Message-ID: <1645667708.39.0.588618564573.issue13475@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The problem of long option names is that they cannot be used in a Unix shebang: "#!/usr/bin/python3 --long-option".

I propose to add the -P option to not add sys.path[0]: I wrote GH-31542.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13475>
_______________________________________

From report at bugs.python.org  Wed Feb 23 20:57:52 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 24 Feb 2022 01:57:52 +0000
Subject: [issue46430] intern strings in deepfrozen modules
In-Reply-To: <1642590983.92.0.896257318647.issue46430@roundup.psfhosted.org>
Message-ID: <1645667872.93.0.903968684333.issue46430@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/issue46430>
_______________________________________

From report at bugs.python.org  Wed Feb 23 21:16:35 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Thu, 24 Feb 2022 02:16:35 +0000
Subject: =?utf-8?q?=5Bissue46754=5D_Improve_Python_Language_Reference_based_on_=5B?=
 =?utf-8?b?S8O2aGwgMjAyMF0=?=
In-Reply-To: <1644887951.55.0.170879911355.issue46754@roundup.psfhosted.org>
Message-ID: <1645668995.89.0.595679903294.issue46754@roundup.psfhosted.org>


Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:

Some specific points from the document:

"While the PLR explicitly states that ?x < y calls x.__lt__(y)? [20, 3.3.1.] this is actually false." They had to read the implementation to actually figure out how this works.

"If no expression is provided, the PLR states that ?the last exception that was active in the current scope? should be re-raised. Unfortunately, the PLR stays unspecific on what it means for an exception to be ?the last exception that was active in the current scope.?"

"The description of this name binding and resolution process in the PLR [20, 4.2.] is unfortunately not particularly clear"

"While generator objects seem not to be specified as part of the PLR, the documentation of the inspect module5 describes them."

(I didn't read the whole thing, but searched for "PLR".)

Here's a few similar things I noticed while reading through the reference recently:

- https://docs.python.org/3.10/reference/datamodel.html#the-standard-type-hierarchy is supposed to be a list of primitive types but has a few problems:
  - Lists "numbers.Number" as a standard type, when it's an ABC that's really not part of the core language
  - Lists "I/O objects" as a kind of standard object, but there are many kinds of file-like objects, and I'd argue they're not part of the core language, but of the standard library.
  - On the other hand, some builtin types (range, map, filter, zip) are not listed.
- https://docs.python.org/3.10/reference/expressions.html#subscriptions doesn't actually give the rules about when __class_getitem__ is called vs. __getitem__. That's in https://docs.python.org/3.10/reference/datamodel.html#class-getitem-versus-getitem.
- The text at https://docs.python.org/3.10/reference/expressions.html#calls doesn't cover positional-only parameters.

----------
nosy: +Jelle Zijlstra

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46754>
_______________________________________

From report at bugs.python.org  Wed Feb 23 21:17:13 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 24 Feb 2022 02:17:13 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1645669033.79.0.279221812343.issue46771@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset 7fce1063b6e5a366f8504e039a8ccdd6944625cd by Tin Tvrtkovi? in branch 'main':
bpo-46771: Implement task cancel requests counter (GH-31513)
https://github.com/python/cpython/commit/7fce1063b6e5a366f8504e039a8ccdd6944625cd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Wed Feb 23 21:17:14 2022
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 24 Feb 2022 02:17:14 +0000
Subject: [issue46841] Inline bytecode caches
Message-ID: <1645669034.5.0.77775951626.issue46841@roundup.psfhosted.org>


New submission from Brandt Bucher <brandtbucher at gmail.com>:

...as discussed in https://github.com/faster-cpython/ideas/discussions/263.

My plan is for this initial PR to lay the groundwork, then to work on porting over the existing opcode caches one-by-one. Once that's done, we can clean up lots of the "old" machinery.

----------
assignee: brandtbucher
components: Interpreter Core
messages: 413875
nosy: Mark.Shannon, brandtbucher
priority: normal
severity: normal
stage: patch review
status: open
title: Inline bytecode caches
type: performance
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46841>
_______________________________________

From report at bugs.python.org  Wed Feb 23 21:18:54 2022
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 24 Feb 2022 02:18:54 +0000
Subject: [issue46841] Inline bytecode caches
In-Reply-To: <1645669034.5.0.77775951626.issue46841@roundup.psfhosted.org>
Message-ID: <1645669134.0.0.536232154689.issue46841@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
keywords: +patch
pull_requests: +29666
pull_request: https://github.com/python/cpython/pull/31543

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46841>
_______________________________________

From report at bugs.python.org  Wed Feb 23 21:50:47 2022
From: report at bugs.python.org (Ofey Chan)
Date: Thu, 24 Feb 2022 02:50:47 +0000
Subject: [issue46761] functools.update_wrapper breaks the signature of
 functools.partial objects
In-Reply-To: <1644948374.87.0.765462873315.issue46761@roundup.psfhosted.org>
Message-ID: <1645671047.31.0.101542336684.issue46761@roundup.psfhosted.org>


Ofey Chan <ofey206 at gmail.com> added the comment:

Thank you Larry.  It can never be too careful to deal with language issues!

> why the code behaves like this--is this behavior a genuine bug, or is it actually a bugfix for some worse behavior?

In my view, there's rather an concept needing clarify, than a genuine bug.  I look into the file blame, and it shows the processing order around `follow_wrapper_chains` might be carefully arranged...

- The `follow_wrapper_chains` functionality is added in issue 13266: https://bugs.python.org/issue13266
- When `signature()` first implemented, `__wrapped__` is handled then `partial`, this order never changed.
   - Issue #15008: Implement PEP 362 "Signature Objects": https://github.com/python/cpython/commit/7c7cbfc00fc8d655fc267ff57f8084357858b1db

> will fixing the bug cause problems for Python users? and if so, can we still fix the bug while mitigating the damage to people who are unfortunately depending on the bug?

It's really a heavy responsibility!  Slow down is right... A clear explaination and plan should be constructed before any action is taken.

So I may study PEP 362 to get some context, about why the code is this way.  And I'm wondering what else can I do?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46761>
_______________________________________

From report at bugs.python.org  Wed Feb 23 21:55:12 2022
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Feb 2022 02:55:12 +0000
Subject: [issue13475] Add '--mainpath'/'--nomainpath' command line options to
 override sys.path[0] initialisation
In-Reply-To: <1322181994.22.0.955887054946.issue13475@psf.upfronthosting.co.za>
Message-ID: <1645671312.92.0.402703156202.issue13475@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

See also bpo-16202 "sys.path[0] security issues".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13475>
_______________________________________

From report at bugs.python.org  Wed Feb 23 22:00:47 2022
From: report at bugs.python.org (Addison Snelling)
Date: Thu, 24 Feb 2022 03:00:47 +0000
Subject: [issue46826] prefixes argument to site.getsitepackages() missing
 documentation
In-Reply-To: <1645529624.68.0.789981983481.issue46826@roundup.psfhosted.org>
Message-ID: <1645671647.77.0.852215410372.issue46826@roundup.psfhosted.org>


Change by Addison Snelling <addison at asnell.io>:


----------
keywords: +patch
pull_requests: +29667
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31546

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46826>
_______________________________________

From report at bugs.python.org  Wed Feb 23 22:41:44 2022
From: report at bugs.python.org (benrg)
Date: Thu, 24 Feb 2022 03:41:44 +0000
Subject: [issue46842] py to pyc location mapping with sys.pycache_prefix isn't
 1-to-1 on Windows
Message-ID: <1645674104.76.0.96131746117.issue46842@roundup.psfhosted.org>


New submission from benrg <benrudiak at gmail.com>:

`importlib._bootstrap_external` contains this comment:

    # We need an absolute path to the py file to avoid the possibility of
    # collisions within sys.pycache_prefix [...]
    # [...] the idea here is that if we get `Foo\Bar`, we first
    # make it absolute (`C:\Somewhere\Foo\Bar`), then make it root-relative
    # (`Somewhere\Foo\Bar`), so we end up placing the bytecode file in an
    # unambiguous `C:\Bytecode\Somewhere\Foo\Bar\`.

The code follows the comment, but doesn't achieve the goal: `C:\Somewhere\Foo\Bar` and `D:\Somewhere\Foo\Bar` collide. There is also no explicit handling of UNC paths, with the result that `\\Somewhere\Foo\Bar` maps to the same location.

I think that on Windows the code should use a mapping like

    C:\Somewhere\Foo\Bar  ==>  C:\Bytecode\C\Somewhere\Foo\Bar
    D:\Somewhere\Foo\Bar  ==>  C:\Bytecode\D\Somewhere\Foo\Bar
    \\Somewhere\Foo\Bar   ==>  C:\Bytecode\UNC\Somewhere\Foo\Bar

The lack of double-slash prefix handling also matters on Unixy platforms that give it a special meaning. Cygwin is probably affected by this. I don't know whether there are any others.

----------
components: Library (Lib), Windows
messages: 413878
nosy: benrg, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: py to pyc location mapping with sys.pycache_prefix isn't 1-to-1 on Windows
type: behavior
versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46842>
_______________________________________

From report at bugs.python.org  Wed Feb 23 23:16:14 2022
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 24 Feb 2022 04:16:14 +0000
Subject: [issue46839] Process finished with exit code -1073741819 (0xC0000005)
In-Reply-To: <1645652176.24.0.399924224142.issue46839@roundup.psfhosted.org>
Message-ID: <1645676174.09.0.254661470952.issue46839@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

I tried to get more information for you by installing 2.7.11 (64-bit because of the given fault) and unassembling python27.dll at the fault offset. But it doesn't help. Whatever the bug is, it ended up jumping to an address that's in the middle of an instruction. This final bit of nonsense is what killed the process with an access violation, but it's not directly related to the problem.

Here's the address that triggered the access violation:

    0:000> ? python27 + a4f81
    Evaluate expression: 1368149889 = 00000000`518c4f81

The nearest function is rawiobase_readall():

    0:000> ln python27 + a4f81
    (00000000`518c4f10)   python27!rawiobase_readall+0x71   |
    (00000000`518c51a0)   python27!resize_buffer

But 0x518c4f81 isn't the address of an instruction in this function:

    0:000> u python27!rawiobase_readall python27!rawiobase_readall+80
    python27!rawiobase_readall:
    [...]
    00000000`518c4f7f 48894318        mov     qword ptr [rbx+18h],rax
    00000000`518c4f83 48894310        mov     qword ptr [rbx+10h],rax
    00000000`518c4f87 48894320        mov     qword ptr [rbx+20h],rax
    00000000`518c4f8b 48837f10fe      cmp     qword ptr [rdi+10h],0FFFFFFFFFFFFFFFEh
    00000000`518c4f90 4c89642440      mov     qword ptr [rsp+40h],r12

It's inside of the first MOV instruction.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46839>
_______________________________________

From report at bugs.python.org  Thu Feb 24 00:34:25 2022
From: report at bugs.python.org (Joongi Kim)
Date: Thu, 24 Feb 2022 05:34:25 +0000
Subject: [issue46843] PersistentTaskGroup API
Message-ID: <1645680865.21.0.230450894933.issue46843@roundup.psfhosted.org>


New submission from Joongi Kim <me at daybreaker.info>:

I'm now tracking the recent addition and discussion of TaskGroup and cancellation scopes. It's interesting! :)

I would like to suggest to have a different mode of operation in asyncio.TaskGroup, which I named "PersistentTaskGroup".

AFAIK, TaskGroup targets to replace asyncio.gather, ensuring completion or cancellation of all tasks within the context manager scope.

I believe that a "safe" asyncio application should consist of a nested tree of task groups, which allow us to explicitly state when tasks of different purposes and contexts terminate.  For example, a task group for database transactions should be shutdown before a task group for HTTP handlers is shutdown.

To this end, in server applications with many sporadically spawned tasks throughout the whole process lifetime, there are different requirements for a task group that manages such task sets.  The tasks should *not* be cancelled upon the unhandled exceptions of sibling tasks in the task group, while we need an explicit "fallback" exception handler for those (just like "return_exceptions=True" in asyncio.gather).  The tasks belong to the task group but their references should not be kept forever to prevent memory leak (I'd suggest using weakref.WeakSet).  When terminating the task group itself, the ongoing tasks should be cancelled.  The cancellation process upon termination may happend in two phases: cancel request with initial timeout + additional limited waiting of cancellations.  (This is what Guido has mentioned in the discussion in bpo-46771.)

An initial sketch of PersistentTaskGroup is on aiotools:
https://github.com/achimnol/aiotools/blob/main/src/aiotools/ptaskgroup.py
Currently has no two-phase cancellation because it would require Python 3.11 with asyncio.Task.uncancel().

As Andrew has left a comment (https://github.com/achimnol/aiotools/issues/29#issuecomment-997437030), I think it is the time to revisit the concrete API design and whether to include PersistentTaskGroup in the stdlib or not.

----------
components: asyncio
messages: 413880
nosy: achimnol, asvetlov, gvanrossum, yselivanov
priority: normal
severity: normal
status: open
title: PersistentTaskGroup API
type: enhancement
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46843>
_______________________________________

From report at bugs.python.org  Thu Feb 24 00:38:49 2022
From: report at bugs.python.org (Stanley)
Date: Thu, 24 Feb 2022 05:38:49 +0000
Subject: [issue34429] [doc] On Windows tempfile.TemporaryFile behaves like
 NamedTemporaryFile
In-Reply-To: <1534590017.91.0.56676864532.issue34429@psf.upfronthosting.co.za>
Message-ID: <1645681129.38.0.710985802307.issue34429@roundup.psfhosted.org>


Change by Stanley <ostanley.lee at gmail.com>:


----------
keywords: +patch
nosy: +slateny
nosy_count: 4.0 -> 5.0
pull_requests: +29668
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31547

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34429>
_______________________________________

From report at bugs.python.org  Thu Feb 24 00:45:56 2022
From: report at bugs.python.org (Joongi Kim)
Date: Thu, 24 Feb 2022 05:45:56 +0000
Subject: [issue46844] Context-based TaskGroup for legacy libraries
Message-ID: <1645681556.47.0.510927748304.issue46844@roundup.psfhosted.org>


New submission from Joongi Kim <me at daybreaker.info>:

Along with bpo-46843 and the new asyncio.TaskGroup API, I would like to suggest addition of context-based TaskGroup feature.

Currently asyncio.create_task() just creates a new task directly attached to the event loop, while asyncio.TaskGroup.create_task() creates a new task managed by the TaskGroup instance.

It would be ideal to all existing asyncio codes to migrate to use TaskGroup, but this is impractical.

An alternative approach is to implicitly bind asyncio.create_task() under a specific context to a specific task group, probably using contextvars.

I believe that this approach would allow more control over tasks implicitly spawned by 3rd-party libraries that cannot control.

How about your thoughts?

----------
components: asyncio
messages: 413881
nosy: achimnol, asvetlov, gvanrossum, yselivanov
priority: normal
severity: normal
status: open
title: Context-based TaskGroup for legacy libraries
type: enhancement
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46844>
_______________________________________

From report at bugs.python.org  Thu Feb 24 00:48:09 2022
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 24 Feb 2022 05:48:09 +0000
Subject: [issue46844] Context-based TaskGroup for legacy libraries
In-Reply-To: <1645681556.47.0.510927748304.issue46844@roundup.psfhosted.org>
Message-ID: <1645681689.85.0.977318875141.issue46844@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> I believe that this approach would allow more control over tasks implicitly spawned by 3rd-party libraries that cannot control.

Please elaborate. I'm not sure what are the benefits of this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46844>
_______________________________________

From report at bugs.python.org  Thu Feb 24 01:46:30 2022
From: report at bugs.python.org (Stanley)
Date: Thu, 24 Feb 2022 06:46:30 +0000
Subject: [issue45991] Improve ambiguous docstrings in pkgutil
In-Reply-To: <1638730607.25.0.754715317111.issue45991@roundup.psfhosted.org>
Message-ID: <1645685190.45.0.795286831159.issue45991@roundup.psfhosted.org>


Stanley <ostanley.lee at gmail.com> added the comment:

Could you expand a bit on why 'list of paths' in pkgutil is understood by default to be 'list of PosixPath paths'? I would interpret it by default to be string paths if I saw it somewhere without context

----------
nosy: +slateny

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45991>
_______________________________________

From report at bugs.python.org  Thu Feb 24 01:47:10 2022
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 24 Feb 2022 06:47:10 +0000
Subject: [issue40116] Regression in memory use of shared key dictionaries for
 "compact dicts"
In-Reply-To: <1585581236.94.0.571794171265.issue40116@roundup.psfhosted.org>
Message-ID: <1645685230.23.0.920185143566.issue40116@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

I found regression caused by GH-28520.

```
class C:
    def __init__(self, n):
        if n:
            self.a = 1
            self.b = 2
            self.c = 3
        else:
            self.c = 1
            self.b = 2
            self.a = 3


o1 = C(True)
o2 = C(False)
print(o2.__dict__)  # {'c': 1, 'b': 2, 'a': 3}

d1 = {}
d1.update(o2.__dict__)  # {'a': 3, 'b': 2, 'c': 1}
print(d1)
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40116>
_______________________________________

From report at bugs.python.org  Thu Feb 24 01:54:03 2022
From: report at bugs.python.org (Joongi Kim)
Date: Thu, 24 Feb 2022 06:54:03 +0000
Subject: [issue46844] Context-based TaskGroup for legacy libraries
In-Reply-To: <1645681556.47.0.510927748304.issue46844@roundup.psfhosted.org>
Message-ID: <1645685643.58.0.0674662017083.issue46844@roundup.psfhosted.org>


Joongi Kim <me at daybreaker.info> added the comment:

The main benefit is that any legacy code that I cannot modify can be upgraded to TaskGroup-based codes, which offers a better machinary for exception handling and propagation.

There may be different ways to visit this issue: allow replacing the task factory in asyncio at runtime.  Then I could just implement my own snippet to transfer the "ownership" of the task to a specific task group.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46844>
_______________________________________

From report at bugs.python.org  Thu Feb 24 01:58:54 2022
From: report at bugs.python.org (Joongi Kim)
Date: Thu, 24 Feb 2022 06:58:54 +0000
Subject: [issue46844] Context-based TaskGroup for legacy libraries
In-Reply-To: <1645681556.47.0.510927748304.issue46844@roundup.psfhosted.org>
Message-ID: <1645685934.77.0.867748464868.issue46844@roundup.psfhosted.org>


Joongi Kim <me at daybreaker.info> added the comment:

Conceptually it is similar to replace malloc using LD_PRELOAD or LD_LIBRARY_PATH manipulation.  When I cannot modify the executable/library binaries, this allows replacing the functionality of specific functions.

If we could assign a specific (persistent) task group to all asyncio tasks spawned by a black-box code (when the black-box itself does not use task groups), we could achieve the full application-level transparency on the timing of task cancellation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46844>
_______________________________________

From report at bugs.python.org  Thu Feb 24 02:01:20 2022
From: report at bugs.python.org (Joongi Kim)
Date: Thu, 24 Feb 2022 07:01:20 +0000
Subject: [issue46844] Context-based TaskGroup for legacy libraries
In-Reply-To: <1645681556.47.0.510927748304.issue46844@roundup.psfhosted.org>
Message-ID: <1645686080.17.0.871502304564.issue46844@roundup.psfhosted.org>


Joongi Kim <me at daybreaker.info> added the comment:

It is also useful to write debugging/monitoring codes for asyncio applications.  For instance, we could "group" tasks from different libraries and count them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46844>
_______________________________________

From report at bugs.python.org  Thu Feb 24 02:08:32 2022
From: report at bugs.python.org (Stanley)
Date: Thu, 24 Feb 2022 07:08:32 +0000
Subject: [issue30677] [doc] mention that os.mkdir() raises FileNotFound if
 path does not exist
In-Reply-To: <1497535738.66.0.994856278172.issue30677@psf.upfronthosting.co.za>
Message-ID: <1645686512.31.0.195745691907.issue30677@roundup.psfhosted.org>


Change by Stanley <ostanley.lee at gmail.com>:


----------
keywords: +patch
nosy: +slateny
nosy_count: 3.0 -> 4.0
pull_requests: +29669
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31548

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30677>
_______________________________________

From report at bugs.python.org  Thu Feb 24 02:14:13 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 24 Feb 2022 07:14:13 +0000
Subject: [issue46844] Context-based TaskGroup for legacy libraries
In-Reply-To: <1645681556.47.0.510927748304.issue46844@roundup.psfhosted.org>
Message-ID: <1645686853.57.0.854081828911.issue46844@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

-1

Now bare `create_task()` does fire-and-forget action.
After the proposed change it will fail loudly.
Even if this behavior is better it is not backward compatible.
People start blaming and asking "how to return everything back?"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46844>
_______________________________________

From report at bugs.python.org  Thu Feb 24 02:15:25 2022
From: report at bugs.python.org (Joongi Kim)
Date: Thu, 24 Feb 2022 07:15:25 +0000
Subject: [issue46844] Context-based TaskGroup for legacy libraries
In-Reply-To: <1645681556.47.0.510927748304.issue46844@roundup.psfhosted.org>
Message-ID: <1645686925.84.0.0450670749761.issue46844@roundup.psfhosted.org>


Joongi Kim <me at daybreaker.info> added the comment:

My propsal is to opt-in the taskgroup binding for asyncio.create_task() under a specific context, not changing the defautl behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46844>
_______________________________________

From report at bugs.python.org  Thu Feb 24 02:27:33 2022
From: report at bugs.python.org (Joongi Kim)
Date: Thu, 24 Feb 2022 07:27:33 +0000
Subject: [issue46844] Context-based TaskGroup for legacy libraries
In-Reply-To: <1645681556.47.0.510927748304.issue46844@roundup.psfhosted.org>
Message-ID: <1645687653.86.0.836954881.issue46844@roundup.psfhosted.org>


Joongi Kim <me at daybreaker.info> added the comment:

An example would be like:

tg = asyncio.TaskGroup()
...
async with tg:
  with asyncio.TaskGroupBinder(tg):  # just a hypothetical API
    asyncio.create_task(...)         # equivalent to tg.create_task(...)
    await some_library.some_work()   # all tasks are bound to tg
  asyncio.create_task(...)           # fire-and-forget (not bound to tg)

If TaskGroup supports enumeration/counting of its own tasks and asyncio allows enumeration of TaskGroups just like asyncio.Task.all_tasks(), we could extend aiomonitor to provide per-taskgroup statistics.

In my projects, we have multiple cases to find and fix bugs in customer sites using aiomonitor and I'm willing to improve aiomonitor to support task groups as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46844>
_______________________________________

From report at bugs.python.org  Thu Feb 24 02:29:56 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Thu, 24 Feb 2022 07:29:56 +0000
Subject: [issue46430] intern strings in deepfrozen modules
In-Reply-To: <1642590983.92.0.896257318647.issue46430@roundup.psfhosted.org>
Message-ID: <1645687796.66.0.294288216326.issue46430@roundup.psfhosted.org>


Change by Kumar Aditya <rahuladitya303 at gmail.com>:


----------
pull_requests: +29670
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31549

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46430>
_______________________________________

From report at bugs.python.org  Thu Feb 24 02:34:49 2022
From: report at bugs.python.org (Joongi Kim)
Date: Thu, 24 Feb 2022 07:34:49 +0000
Subject: [issue46844] Context-based TaskGroup for legacy libraries
In-Reply-To: <1645681556.47.0.510927748304.issue46844@roundup.psfhosted.org>
Message-ID: <1645688089.8.0.616658480076.issue46844@roundup.psfhosted.org>


Joongi Kim <me at daybreaker.info> added the comment:

Ah, and this use case also requires that TaskGroup should have an option like `return_exceptions=True` which makes it not to cancel sibling tasks upon unhandled exceptions, as I suggested in PersistentTaskGroup (bpo-46843).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46844>
_______________________________________

From report at bugs.python.org  Thu Feb 24 02:36:21 2022
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 24 Feb 2022 07:36:21 +0000
Subject: [issue40116] Regression in memory use of shared key dictionaries for
 "compact dicts"
In-Reply-To: <1585581236.94.0.571794171265.issue40116@roundup.psfhosted.org>
Message-ID: <1645688181.89.0.190829626277.issue40116@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +29671
pull_request: https://github.com/python/cpython/pull/31550

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40116>
_______________________________________

From report at bugs.python.org  Thu Feb 24 02:40:55 2022
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 24 Feb 2022 07:40:55 +0000
Subject: [issue46845] dict: Use smaller entry for Unicode-key only dict.
Message-ID: <1645688455.61.0.00785191075466.issue46845@roundup.psfhosted.org>


New submission from Inada Naoki <songofacandy at gmail.com>:

Currently, PyDictKeyEntry is 24bytes (hash, key, and value).

We can drop the hash from entry when all keys are unicode, because unicode objects caches hash already.

This will cause some performance regression on microbenchmark because dict need one more indirect access to compare hash value.

On the other hand, this will reduce some RAM usage. Additionally, unlike docstrings and annotations, this includes much **hot** RAM. It will make Python more cache efficient.

This is work in progress code: https://github.com/methane/cpython/pull/43
pypeformance result is in the PR too.

----------
components: Interpreter Core
messages: 413892
nosy: Mark.Shannon, methane, rhettinger
priority: normal
severity: normal
status: open
title: dict: Use smaller entry for Unicode-key only dict.
type: performance
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46845>
_______________________________________

From report at bugs.python.org  Thu Feb 24 02:53:27 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Thu, 24 Feb 2022 07:53:27 +0000
Subject: [issue46430] intern strings in deepfrozen modules
In-Reply-To: <1642590983.92.0.896257318647.issue46430@roundup.psfhosted.org>
Message-ID: <1645689207.2.0.253457719463.issue46430@roundup.psfhosted.org>


Kumar Aditya <rahuladitya303 at gmail.com> added the comment:

I have created a PR to fix the memory leak, See https://github.com/python/cpython/pull/31549

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46430>
_______________________________________

From report at bugs.python.org  Thu Feb 24 02:54:38 2022
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 24 Feb 2022 07:54:38 +0000
Subject: [issue40116] Regression in memory use of shared key dictionaries for
 "compact dicts"
In-Reply-To: <1585581236.94.0.571794171265.issue40116@roundup.psfhosted.org>
Message-ID: <1645689278.74.0.100391219503.issue40116@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

PyDict_Keys(), PyDict_Values(), and PyDict_Items() don't respect insertion order too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40116>
_______________________________________

From report at bugs.python.org  Thu Feb 24 03:36:05 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 24 Feb 2022 08:36:05 +0000
Subject: [issue34429] [doc] On Windows tempfile.TemporaryFile behaves like
 NamedTemporaryFile
In-Reply-To: <1534590017.91.0.56676864532.issue34429@psf.upfronthosting.co.za>
Message-ID: <1645691765.6.0.0394195939345.issue34429@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy:  -terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34429>
_______________________________________

From report at bugs.python.org  Thu Feb 24 03:49:47 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Thu, 24 Feb 2022 08:49:47 +0000
Subject: [issue46430] intern strings in deepfrozen modules
In-Reply-To: <1642590983.92.0.896257318647.issue46430@roundup.psfhosted.org>
Message-ID: <1645692587.63.0.0297280001338.issue46430@roundup.psfhosted.org>


Kumar Aditya <rahuladitya303 at gmail.com> added the comment:

> Okay, let's change the error handling. @Kumar, can you handle that?

How it should be handled? Currently PyUnicode_InternInPlace ignores any errors and does not return it. It would be backwards-incompatible to change that, moreover as I explained in https://github.com/python/cpython/pull/30683#discussion_r800648477 intern_strings only check if all the items are strings which will be always true in case of deep-freeze so I don't think anything needs to be changed here. I would be interested to know if I am missing something though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46430>
_______________________________________

From report at bugs.python.org  Thu Feb 24 03:58:14 2022
From: report at bugs.python.org (Stanley)
Date: Thu, 24 Feb 2022 08:58:14 +0000
Subject: [issue12165] [doc] clarify documentation of nonlocal
In-Reply-To: <1306216657.18.0.255448168009.issue12165@psf.upfronthosting.co.za>
Message-ID: <1645693094.53.0.97447746024.issue12165@roundup.psfhosted.org>


Change by Stanley <ostanley.lee at gmail.com>:


----------
keywords: +patch
nosy: +slateny
nosy_count: 6.0 -> 7.0
pull_requests: +29672
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31551

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12165>
_______________________________________

From report at bugs.python.org  Thu Feb 24 04:21:14 2022
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 24 Feb 2022 09:21:14 +0000
Subject: [issue46761] functools.update_wrapper breaks the signature of
 functools.partial objects
In-Reply-To: <1644948374.87.0.765462873315.issue46761@roundup.psfhosted.org>
Message-ID: <1645694474.35.0.126770746044.issue46761@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

Okay, so, I considered the problem for a while, and I have a reasonable theory about what follow_wrapper_chains was for in the first place.

If you have a generic decorator, like functools.cache(), it usually looks like this:

  def my_decorator(fn):
    def generic_version(*args, **kwargs):
      args, kwargs = do_something(args, kwargs)
      return fn(*args, **kwargs)
    return generic_version

  @my_decorator
  def add_five(i):
    return i+5

If you take the signature of add_five, you'd get (*args, **kwargs), because that's the signature of the wrapper function returned by the decorator.  The decorator doesn't change the parameters of the function, but because of how decorators work it can occlude the proper function signature.  In that instance, follow_wrapper_chains does the right thing, and as a result you get a precise function signature.

(Of course, it would do the wrong thing if your hand-written decorator *also* behaved like a partial application, adding in its own hard-coded arguments, so that the resulting function signature changed.)

Still, obviously it's doing the wrong thing when it comes to functools.partial() functions.

My suspicion is that I'm the rare individual who actually uses update_wrapper on a functools.partial object.  So maybe we have the situation here where, yeah, it's a bug, and we can fix it without causing further breakage.

Maybe we can loop in someone who works on a popular runtime function introspection library (FastAPI, Pydantic) to see if they have any take on it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46761>
_______________________________________

From report at bugs.python.org  Thu Feb 24 04:39:21 2022
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 24 Feb 2022 09:39:21 +0000
Subject: [issue46846] functools.partial objects should set __signature__ and
 _annotations__
Message-ID: <1645695561.69.0.398852174273.issue46846@roundup.psfhosted.org>


New submission from Larry Hastings <larry at hastings.org>:

I ran across an interesting bug in issue #46761.  If you call functools.update_wrapper on a functools.partial object, inspect.signature will return the wrong (original) signature for the partial object.

We're still figuring that one out.  And, of course, it's telling that the bug has been there for a long time.  I suspect this isn't something that has inconvenienced a lot of people.

But: I suggest that it's time functools.partial participated in signature stuff.  Specifically, I think functools.partial should generate a new and correct __signature__ for the partial object.  And I propose it should also generate a new and correct __annotations__ for the partial, by removing all entries for parameters that are filled in by the partial object.

Right now inspect.signature has special support for functools.partial objects.  It finds the underlying function, and .  Which means there's code in both modules that has to understand the internals of partial objects.  Just from a code hygiene perspective, it'd be better if all that logic lived under functools.

I wonder if functools.partial objects should generally do a better job of impersonating the original function.  Should they adopt the same __name__?  __file__?  __qualname__?  My intuition is, it'd be nice if it did.  But I might be forgetting something important.

(I suspect everything I said about functools.partial also applies to functools.partialmethod.)

----------
components: Library (Lib)
messages: 413897
nosy: larry, rhettinger
priority: normal
severity: normal
stage: test needed
status: open
title: functools.partial objects should set __signature__ and _annotations__
type: enhancement
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46846>
_______________________________________

From report at bugs.python.org  Thu Feb 24 04:47:13 2022
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 24 Feb 2022 09:47:13 +0000
Subject: [issue46847] functools.update_wrapper doesn't understand partial
 objects and annotations
Message-ID: <1645696033.77.0.27320800273.issue46847@roundup.psfhosted.org>


New submission from Larry Hastings <larry at hastings.org>:

functools.update_wrapper currently copies over every attribute listed in the "assigned" parameter, which defaults to WRAPPER_ASSIGNMENTS, which means it copies the wrapped function's __annotations__ to the wrapper.  This is slightly wrong if the wrapper occludes an annotated parameter:

    def foo(a: int, b: str, c: float):
        print(a, b, c)

    import functools

    foo_a = functools.partial(foo, 3)
    functools.update_wrapper(foo_a, foo)

    print(foo_a.__annotations__)

In this case, foo_a.__annotations__ contains an annotation for a parameter named "a", even though foo_a doesn't have a parameter named "a".

This problem occurred to me just after I filed #46846; the two issues are definitely related.

----------
components: Library (Lib)
messages: 413898
nosy: larry, rhettinger
priority: normal
severity: normal
stage: test needed
status: open
title: functools.update_wrapper doesn't understand partial objects and annotations
type: behavior
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46847>
_______________________________________

From report at bugs.python.org  Thu Feb 24 04:56:19 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 24 Feb 2022 09:56:19 +0000
Subject: [issue46844] Context-based TaskGroup for legacy libraries
In-Reply-To: <1645681556.47.0.510927748304.issue46844@roundup.psfhosted.org>
Message-ID: <1645696579.33.0.166207374162.issue46844@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

I personally don't think that the described opt-in trick should be a part of asyncio.
A third-party library that patches asyncio.create_task() can be a useful thing though during the transition period.
We even cannot deprecate asyncio.create_task() right now: the minimal supported Python 3.7 thas now alternative, writing cross-version code is overcomplicated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46844>
_______________________________________

From report at bugs.python.org  Thu Feb 24 05:00:31 2022
From: report at bugs.python.org (Safihre)
Date: Thu, 24 Feb 2022 10:00:31 +0000
Subject: [issue37355] SSLSocket.read does a GIL round-trip for every 16KB TLS
 record
In-Reply-To: <1561056169.29.0.814417679233.issue37355@roundup.psfhosted.org>
Message-ID: <1645696831.2.0.636152757228.issue37355@roundup.psfhosted.org>


Safihre <safihre at sabnzbd.org> added the comment:

Could the new PR be reviewed? Thank you!
https://github.com/python/cpython/pull/31492
Documentation still needs updating, but would like feedback.

PS: Why not enable the setting the GitHub Actions workflow only need to be approved for new GitHub accounts instead of for *all* new contributors?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37355>
_______________________________________

From report at bugs.python.org  Thu Feb 24 05:09:09 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 24 Feb 2022 10:09:09 +0000
Subject: [issue44886] asyncio: create_datagram_endpoint() does not return a
 DatagramTransport
In-Reply-To: <1628671129.22.0.924495128156.issue44886@roundup.psfhosted.org>
Message-ID: <1645697349.09.0.875257753374.issue44886@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/issue44886>
_______________________________________

From report at bugs.python.org  Thu Feb 24 05:15:08 2022
From: report at bugs.python.org (Alex Waygood)
Date: Thu, 24 Feb 2022 10:15:08 +0000
Subject: [issue46847] functools.update_wrapper doesn't understand partial
 objects and annotations
In-Reply-To: <1645696033.77.0.27320800273.issue46847@roundup.psfhosted.org>
Message-ID: <1645697708.96.0.423972038957.issue46847@roundup.psfhosted.org>


Change by Alex Waygood <Alex.Waygood at Gmail.com>:


----------
nosy: +AlexWaygood, Jelle Zijlstra, sobolevn

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46847>
_______________________________________

From report at bugs.python.org  Thu Feb 24 05:16:21 2022
From: report at bugs.python.org (Alex Waygood)
Date: Thu, 24 Feb 2022 10:16:21 +0000
Subject: [issue46846] functools.partial objects should set __signature__ and
 _annotations__
In-Reply-To: <1645695561.69.0.398852174273.issue46846@roundup.psfhosted.org>
Message-ID: <1645697781.15.0.97729228908.issue46846@roundup.psfhosted.org>


Change by Alex Waygood <Alex.Waygood at Gmail.com>:


----------
nosy: +AlexWaygood

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46846>
_______________________________________

From report at bugs.python.org  Thu Feb 24 05:55:27 2022
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 24 Feb 2022 10:55:27 +0000
Subject: [issue46841] Inline bytecode caches
In-Reply-To: <1645669034.5.0.77775951626.issue46841@roundup.psfhosted.org>
Message-ID: <1645700127.97.0.29019154295.issue46841@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

We need to decide what to do about dis.

I don't think we should have a `show_cache` option, as the caches are meaningless junk without quickening (maybe we should drop the CACHE opcode, and just use zeroes).

Instead we should have a `show_quickened` option, to show the quickened form, which we need to make clear is very much implementation defined.
E.g. Cinder might show the machine code as well.

That way, we can present the cache information as extra data on the quickened form, rather than junk instructions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46841>
_______________________________________

From report at bugs.python.org  Thu Feb 24 06:21:27 2022
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 24 Feb 2022 11:21:27 +0000
Subject: [issue46841] Inline bytecode caches
In-Reply-To: <1645669034.5.0.77775951626.issue46841@roundup.psfhosted.org>
Message-ID: <1645701687.84.0.196503417183.issue46841@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
pull_requests: +29673
pull_request: https://github.com/python/cpython/pull/31552

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46841>
_______________________________________

From report at bugs.python.org  Thu Feb 24 07:16:58 2022
From: report at bugs.python.org (Petr Viktorin)
Date: Thu, 24 Feb 2022 12:16:58 +0000
Subject: [issue46748] Python.h includes stdbool.h
In-Reply-To: <1644830899.62.0.590844926135.issue46748@roundup.psfhosted.org>
Message-ID: <1645705018.04.0.309780254375.issue46748@roundup.psfhosted.org>


Change by Petr Viktorin <encukou at gmail.com>:


----------
keywords: +patch
pull_requests: +29674
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31553

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46748>
_______________________________________

From report at bugs.python.org  Thu Feb 24 07:43:50 2022
From: report at bugs.python.org (Stefan Tatschner)
Date: Thu, 24 Feb 2022 12:43:50 +0000
Subject: [issue46848] Use optimized string search function in mmap.find()
Message-ID: <1645706630.43.0.574969248824.issue46848@roundup.psfhosted.org>


New submission from Stefan Tatschner <stefan at rumpelsepp.org>:

The mmap.find() in  function uses a naive loop to search string matches. This can be optimized ?for free? by using libc's memmap(3) function instead.

The relevant file is Modules/mmapmodule.c, the relevant function is mmap_gfind().

----------
messages: 413902
nosy: rumpelsepp
priority: normal
severity: normal
status: open
title: Use optimized string search function in mmap.find()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46848>
_______________________________________

From report at bugs.python.org  Thu Feb 24 07:45:31 2022
From: report at bugs.python.org (Stefan Tatschner)
Date: Thu, 24 Feb 2022 12:45:31 +0000
Subject: [issue46848] Use optimized string search function in mmap.find()
In-Reply-To: <1645706630.43.0.574969248824.issue46848@roundup.psfhosted.org>
Message-ID: <1645706731.49.0.941782843387.issue46848@roundup.psfhosted.org>


Stefan Tatschner <stefan at rumpelsepp.org> added the comment:

Sorry, I mean memmem(3). :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46848>
_______________________________________

From report at bugs.python.org  Thu Feb 24 07:52:28 2022
From: report at bugs.python.org (Stefan Tatschner)
Date: Thu, 24 Feb 2022 12:52:28 +0000
Subject: [issue46848] Use optimized string search function in mmap.find()
In-Reply-To: <1645706630.43.0.574969248824.issue46848@roundup.psfhosted.org>
Message-ID: <1645707148.67.0.539615723822.issue46848@roundup.psfhosted.org>


Change by Stefan Tatschner <stefan at rumpelsepp.org>:


----------
keywords: +patch
pull_requests: +29675
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31554

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46848>
_______________________________________

From report at bugs.python.org  Thu Feb 24 08:08:05 2022
From: report at bugs.python.org (Joongi Kim)
Date: Thu, 24 Feb 2022 13:08:05 +0000
Subject: [issue46844] Context-based TaskGroup for legacy libraries
In-Reply-To: <1645681556.47.0.510927748304.issue46844@roundup.psfhosted.org>
Message-ID: <1645708085.72.0.776329808545.issue46844@roundup.psfhosted.org>


Joongi Kim <me at daybreaker.info> added the comment:

Ok, let me be clear: Patching asyncio.create_task() to support this opt-in contextual task group binding is not an ultimate goal of this issue.  If it becomes possible to override/extend the task factory at runtime with any event loop implementation, then it's ok to implement this feature request as a 3rd-party library.  I also don't want to bloat the stdlib with version-specific branches, if there are alternative ways to achieve the same goal.  I just wanted to check out your opinons and potential alternative approaches to implement it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46844>
_______________________________________

From report at bugs.python.org  Thu Feb 24 08:17:54 2022
From: report at bugs.python.org (Joongi Kim)
Date: Thu, 24 Feb 2022 13:17:54 +0000
Subject: [issue46843] PersistentTaskGroup API
In-Reply-To: <1645680865.21.0.230450894933.issue46843@roundup.psfhosted.org>
Message-ID: <1645708674.1.0.251435744218.issue46843@roundup.psfhosted.org>


Joongi Kim <me at daybreaker.info> added the comment:

So I have more things in mind.

Basically PersistentTaskGroup resemble TaskGroup in that:
 - It has the same "create_task()" method.
 - It has an explicit "cancel()" or "shutdown()" method.
 - Exiting of the context manager means that all tasks of it have either completed or cancelled.

TaskGroup is intended to be used for a short-lived set of tasks, while PersistentTaskGroup is intended for a long-running set of tasks though individual tasks may be short-lived.  Thus, adding globally accessible monitoring facility for plain TaskGroup would not be that useful.  In contrast, it is super-useful to have a monitoring feature in PersistentTaskGroup!

In aiomonitor, we can enumerate the currently running asyncio tasks by reading asyncio.Task.all_tasks().  This has saved my life several times when debugging real-world server applications.  I think we can go further by having asyncio.PersistentTaskGroup.all_task_groups() which works in the same way.  If we make different modules and libraries to use different persistent task groups, then we could keep track of their task statistics separately.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46843>
_______________________________________

From report at bugs.python.org  Thu Feb 24 08:20:32 2022
From: report at bugs.python.org (Chris)
Date: Thu, 24 Feb 2022 13:20:32 +0000
Subject: [issue43333] utf8 in BytesGenerator
In-Reply-To: <1614376213.69.0.504043333554.issue43333@roundup.psfhosted.org>
Message-ID: <1645708832.71.0.0270867176308.issue43333@roundup.psfhosted.org>


Chris <chrisstaunton1990 at gmail.com> added the comment:

found this issue while googling the error. Also having the same problem with as_bytes() breaking on non-ascii characters. 

I've tried policy=policy.default.clone(utf8=True) but it gives the same error. 

My sample.py file attached contains a string sample email - which has a character \u200d (https://unicode-table.com/en/200D/) - Zero Width Joiner in the body. 

UnicodeEncodeError: 'ascii' codec can't encode character '\u200d' in position 70: ordinal not in range(128)

Any assistance on what I can do to solve it would be great. It seems I can parse 99% of the emails I've tried but this one has me confused.

----------
nosy: +chrisstaunton1990
Added file: https://bugs.python.org/file50641/sample.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43333>
_______________________________________

From report at bugs.python.org  Thu Feb 24 08:29:36 2022
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Feb 2022 13:29:36 +0000
Subject: [issue46659] Deprecate locale.getdefaultlocale() function
In-Reply-To: <1644168794.44.0.0658923518102.issue46659@roundup.psfhosted.org>
Message-ID: <1645709376.05.0.302813440837.issue46659@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 4fccf910738d1442852cb900747e6dccb8fe03ef by Victor Stinner in branch 'main':
bpo-46659: Enhance LocaleTextCalendar for C locale (GH-31214)
https://github.com/python/cpython/commit/4fccf910738d1442852cb900747e6dccb8fe03ef


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46659>
_______________________________________

From report at bugs.python.org  Thu Feb 24 08:33:16 2022
From: report at bugs.python.org (Joongi Kim)
Date: Thu, 24 Feb 2022 13:33:16 +0000
Subject: [issue46843] PersistentTaskGroup API
In-Reply-To: <1645680865.21.0.230450894933.issue46843@roundup.psfhosted.org>
Message-ID: <1645709596.75.0.207334976218.issue46843@roundup.psfhosted.org>


Joongi Kim <me at daybreaker.info> added the comment:

I think people may ask "why in stdlib?".

My reasons are:
 - We are adding new asyncio APIs in 3.11 such as TaskGroup, so I think it is a good time to add another one, as long as it does not break existing stuffs.
 - I believe that long-running task sets are equally representative use-case for real-world asyncio applications, particularly for servers.  Why not to have intrinsic support for them?
 - PersistentTaskGroup is going to be universally adopted throughout my 70+K LoC asyncio codebase, for instance, in every aiohttp.Application context, plugin contexts and modules, etc.

Of course, the name "PersistentTaskGroup" may look quite long, and I'm completely open with alternative suggestions.  I also welcome suggestions on changes to its functional semantics based on your experience and knowledge.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46843>
_______________________________________

From report at bugs.python.org  Thu Feb 24 08:39:30 2022
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Feb 2022 13:39:30 +0000
Subject: [issue28533] Remove asyncore, asynchat and smtpd modules
In-Reply-To: <1477420324.44.0.338895938894.issue28533@psf.upfronthosting.co.za>
Message-ID: <1645709970.1.0.837050507726.issue28533@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Follow-up: PEP 594 schedules the removal of these 4 modules in Python 3.12, but the PEP remains a draft.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28533>
_______________________________________

From report at bugs.python.org  Thu Feb 24 08:41:35 2022
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Feb 2022 13:41:35 +0000
Subject: [issue46659] Deprecate locale.getdefaultlocale() function
In-Reply-To: <1644168794.44.0.0658923518102.issue46659@roundup.psfhosted.org>
Message-ID: <1645710095.59.0.232261409255.issue46659@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

locale.getdefaultlocale() is now deprecated.

calendar now uses locale.setlocale() instead of locale.getdefaultlocale().

The ANSI code page alias to MBCS now has better tests and better comments.

Thanks Eryk Sun for your very useful feedback!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46659>
_______________________________________

From report at bugs.python.org  Thu Feb 24 08:42:05 2022
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Feb 2022 13:42:05 +0000
Subject: [issue43557] Deprecate getdefaultlocale(),
 getlocale() and normalize() functions
In-Reply-To: <1616160447.56.0.84902377628.issue43557@roundup.psfhosted.org>
Message-ID: <1645710125.4.0.682866111824.issue43557@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Deprecating these functions is complex. I prefer to start with the least controversial part: bpo-46659.

locale.getdefaultlocale() is now deprecated in Python 3.11.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43557>
_______________________________________

From report at bugs.python.org  Thu Feb 24 09:11:26 2022
From: report at bugs.python.org (tongxiaoge)
Date: Thu, 24 Feb 2022 14:11:26 +0000
Subject: [issue46849] Memory problems detected using Valgrind
Message-ID: <1645711886.58.0.922948546021.issue46849@roundup.psfhosted.org>


New submission from tongxiaoge <shixuantong at huawei.com>:

Reproduction steps:
1. Execute command: iotop -b -n 10 &
2. Execute the command in another session: valgrind /usr/sbin/iotop -b -n 5 > iotop_test

The output information is as follows:
[root at openEuler ~]# valgrind /usr/sbin/iotop -b -n 5 > iotop_test
==13750== Memcheck, a memory error detector
==13750== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==13750== Using Valgrind-3.16.0 and LibVEX; rerun with -h for copyright info
==13750== Command: /usr/sbin/iotop -b -n 5
==13750==
==13750== Conditional jump or move depends on uninitialised value(s)
==13750== at 0x49B2C40: PyUnicode_Decode (unicodeobject.c:3488)
==13750== by 0x49B335B: unicode_new (unicodeobject.c:15465)
==13750== by 0x4982C07: type_call (typeobject.c:1014)
==13750== by 0x492CA17: _PyObject_MakeTpCall (call.c:191)
==13750== by 0x48F1863: _PyObject_VectorcallTstate (abstract.h:116)
==13750== by 0x48F1863: _PyObject_VectorcallTstate (abstract.h:103)
==13750== by 0x48F1863: PyObject_Vectorcall (abstract.h:127)
==13750== by 0x48F1863: call_function (ceval.c:5075)
==13750== by 0x48F1863: _PyEval_EvalFrameDefault (ceval.c:3518)
==13750== by 0x48EAEE7: _PyEval_EvalFrame (pycore_ceval.h:40)
==13750== by 0x48EAEE7: function_code_fastcall (call.c:330)
==13750== by 0x492CBE7: _PyObject_FastCallDictTstate (call.c:118)
==13750== by 0x492CEEB: _PyObject_Call_Prepend (call.c:489)
==13750== by 0x498A007: slot_tp_init (typeobject.c:6964)
==13750== by 0x4982C4F: type_call (typeobject.c:1026)
==13750== by 0x492CA17: _PyObject_MakeTpCall (call.c:191)
==13750== by 0x48F1863: _PyObject_VectorcallTstate (abstract.h:116)
==13750== by 0x48F1863: _PyObject_VectorcallTstate (abstract.h:103)
==13750== by 0x48F1863: PyObject_Vectorcall (abstract.h:127)
==13750== by 0x48F1863: call_function (ceval.c:5075)
==13750== by 0x48F1863: _PyEval_EvalFrameDefault (ceval.c:3518)
==13750==
==13751== Warning: invalid file descriptor 1024 in syscall close()
==13751== Warning: invalid file descriptor 1025 in syscall close()
==13751== Warning: invalid file descriptor 1026 in syscall close()
==13751== Warning: invalid file descriptor 1027 in syscall close()
==13751== Use --log-fd= to select an alternative log fd.
==13751== Warning: invalid file descriptor 1028 in syscall close()
==13751== Warning: invalid file descriptor 1029 in syscall close()
==13752== Warning: invalid file descriptor 1024 in syscall close()
==13752== Warning: invalid file descriptor 1025 in syscall close()
==13752== Warning: invalid file descriptor 1026 in syscall close()
==13752== Warning: invalid file descriptor 1027 in syscall close()
==13752== Use --log-fd= to select an alternative log fd.
==13752== Warning: invalid file descriptor 1028 in syscall close()
==13752== Warning: invalid file descriptor 1029 in syscall close()
==13750==
==13750== HEAP SUMMARY:
==13750== in use at exit: 1,069,715 bytes in 10,017 blocks
==13750== total heap usage: 589,638 allocs, 579,621 frees, 128,672,782 bytes allocated
==13750==
==13750== LEAK SUMMARY:
==13750== definitely lost: 0 bytes in 0 blocks
==13750== indirectly lost: 0 bytes in 0 blocks
==13750== possibly lost: 1,042,483 bytes in 9,894 blocks
==13750== still reachable: 27,232 bytes in 123 blocks
==13750== suppressed: 0 bytes in 0 blocks
==13750== Rerun with --leak-check=full to see details of leaked memory
==13750==
==13750== Use --track-origins=yes to see where uninitialised values come from
==13750== For lists of detected and suppressed errors, rerun with: -s
==13750== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

Software version: python3-3.9.9 & python3.9.10  iotop-6.0

The above stack information is in Python 3.9.10 and this problem cannot be reproduced in Python 3.7.


So is it a python3  problem or an iotop problem?  How to fix it.

----------
messages: 413912
nosy: sxt1001
priority: normal
severity: normal
status: open
title: Memory problems detected using Valgrind
type: resource usage
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46849>
_______________________________________

From report at bugs.python.org  Thu Feb 24 09:18:45 2022
From: report at bugs.python.org (Joongi Kim)
Date: Thu, 24 Feb 2022 14:18:45 +0000
Subject: [issue46843] PersistentTaskGroup API
In-Reply-To: <1645680865.21.0.230450894933.issue46843@roundup.psfhosted.org>
Message-ID: <1645712325.01.0.358043845712.issue46843@roundup.psfhosted.org>


Joongi Kim <me at daybreaker.info> added the comment:

Example use cases:

* Implement an event iteration loop to fetch events and dispatch the handlers depending on the event type (e.g., WebSocket connections, message queues, etc.)
  - https://github.com/aio-libs/aiohttp/pull/2885
  - https://github.com/lablup/backend.ai-manager/pull/533
  - https://github.com/lablup/backend.ai-agent/pull/341
  - https://github.com/lablup/backend.ai-agent/pull/331
* Separate monitoring of event handler tasks by the event sources.
  - aiomonitor extension to count currently ongoing tasks and extract the most frequent task stack frames
* Separate the fallback exception handlers by each persistent task group, instead of using the single "global" event loop exception handler.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46843>
_______________________________________

From report at bugs.python.org  Thu Feb 24 09:29:02 2022
From: report at bugs.python.org (Joongi Kim)
Date: Thu, 24 Feb 2022 14:29:02 +0000
Subject: [issue46843] PersistentTaskGroup API
In-Reply-To: <1645680865.21.0.230450894933.issue46843@roundup.psfhosted.org>
Message-ID: <1645712942.8.0.986537859228.issue46843@roundup.psfhosted.org>


Joongi Kim <me at daybreaker.info> added the comment:

Some search results from cs.github.com with the input "asyncio task weakset", which may be replaced/simplified with PersistentTaskGroup:

- https://github.com/Textualize/textual/blob/38efc821737e3158a8c4c7ef8ecfa953dc7c0ba8/src/textual/message_pump.py#L43
- https://github.com/aiokitchen/aiomisc/blob/59abd4434e6d134537490db699f89a51df1e6bbc/aiomisc/entrypoint.py#L132
- https://github.com/anki/cozmo-python-sdk/blob/dd29edef18748fcd816550469195323842a7872e/src/cozmo/event.py#L102
- https://github.com/aio-libs/aiohttp-sse/blob/db7d49bfc8a4907d9a8e7696a85b9772e1c550eb/examples/graceful_shutdown.py#L50
- https://github.com/mosquito/aiormq/blob/9c6c0dfc771ea8f6e79b7532177640c2692c640f/aiormq/base.py#L18
https://github.com/mars-project/mars/blob/d1a14cc4a1cb96e40e1d81eef38113b0c9221a84/mars/lib/aio/_runners.py#L57

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46843>
_______________________________________

From report at bugs.python.org  Thu Feb 24 09:53:20 2022
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 24 Feb 2022 14:53:20 +0000
Subject: [issue46659] Deprecate locale.getdefaultlocale() function
In-Reply-To: <1645710095.59.0.232261409255.issue46659@roundup.psfhosted.org>
Message-ID: <2d1752c4-b297-3f14-93ab-f0865dda5f54@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Thanks, Victor.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46659>
_______________________________________

From report at bugs.python.org  Thu Feb 24 09:56:04 2022
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 24 Feb 2022 14:56:04 +0000
Subject: [issue46823] Add LOAD_FAST__LOAD_ATTR_INSTACE_VALUE combined opcode
In-Reply-To: <1645506714.72.0.112858305238.issue46823@roundup.psfhosted.org>
Message-ID: <1645714564.81.0.384002784453.issue46823@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset a52d2528a405c1e2bfeb6470cb3313a5338dc45f by Dennis Sweeney in branch 'main':
bpo-46823: Implement LOAD_FAST__LOAD_ATTR_INSTANCE_VALUE superinstruction (GH-31484)
https://github.com/python/cpython/commit/a52d2528a405c1e2bfeb6470cb3313a5338dc45f


----------
nosy: +Mark.Shannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46823>
_______________________________________

From report at bugs.python.org  Thu Feb 24 10:00:01 2022
From: report at bugs.python.org (Petr Viktorin)
Date: Thu, 24 Feb 2022 15:00:01 +0000
Subject: [issue46836] [C API] Move PyFrameObject to the internal C API
In-Reply-To: <1645628652.12.0.0785803095185.issue46836@roundup.psfhosted.org>
Message-ID: <1645714801.49.0.569131778573.issue46836@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

OK, looking at it more carefully, it makes sense to do the change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46836>
_______________________________________

From report at bugs.python.org  Thu Feb 24 10:36:24 2022
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Feb 2022 15:36:24 +0000
Subject: [issue46850] [C API] Move _PyEval_EvalFrameDefault() to the internal
 C API
Message-ID: <1645716984.87.0.22272006941.issue46850@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

In Python 3.10, _PyEval_EvalFrameDefault() has the API:

PyObject* _PyEval_EvalFrameDefault(PyThreadState *tstate, PyFrameObject *f, int throwflag);

In Python 3.11, bpo-44590 (commit ae0a2b756255629140efcbe57fc2e714f0267aa3 "Lazily allocate frame objects (GH-27077)") changed it to:

PyObject* _PyEval_EvalFrameDefault(PyThreadState *tstate, InterpreterFrame *frame, int throwflag);

Problem: InterpreterFrame is part of the internal C API.

By the way, PyInterpreterState.eval_frame type (_PyFrameEvalFunction) also changed. This field type already changed in Python 3.9:

* ``PyInterpreterState.eval_frame`` (:pep:`523`) now requires a new mandatory
  *tstate* parameter (``PyThreadState*``).
  (Contributed by Victor Stinner in :issue:`38500`.)

Maybe the Python 3.11 change should be documented in What's New in Python 3.11, as it was in What's New in Python 3.9.


I propose to move most _PyEval private functions to the internal C API to clarify that they must be used.

----------
components: C API
messages: 413918
nosy: vstinner
priority: normal
severity: normal
status: open
title: [C API] Move _PyEval_EvalFrameDefault() to the internal C API
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46850>
_______________________________________

From report at bugs.python.org  Thu Feb 24 10:42:28 2022
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Feb 2022 15:42:28 +0000
Subject: [issue46850] [C API] Move _PyEval_EvalFrameDefault() to the internal
 C API
In-Reply-To: <1645716984.87.0.22272006941.issue46850@roundup.psfhosted.org>
Message-ID: <1645717348.02.0.414486024027.issue46850@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

typo: "I propose to move most _PyEval private functions to the internal C API to clarify that they must *NOT* be used." :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46850>
_______________________________________

From report at bugs.python.org  Thu Feb 24 10:42:46 2022
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Feb 2022 15:42:46 +0000
Subject: [issue46850] [C API] Move _PyEval_EvalFrameDefault() to the internal
 C API
In-Reply-To: <1645716984.87.0.22272006941.issue46850@roundup.psfhosted.org>
Message-ID: <1645717366.03.0.10628171213.issue46850@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +29676
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31532

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46850>
_______________________________________

From report at bugs.python.org  Thu Feb 24 10:43:28 2022
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Feb 2022 15:43:28 +0000
Subject: [issue46850] [C API] Move _PyEval_EvalFrameDefault() to the internal
 C API
In-Reply-To: <1645716984.87.0.22272006941.issue46850@roundup.psfhosted.org>
Message-ID: <1645717408.73.0.641417015117.issue46850@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

See also bpo-46836: "[C API] Move PyFrameObject to the internal C API".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46850>
_______________________________________

From report at bugs.python.org  Thu Feb 24 10:43:54 2022
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Feb 2022 15:43:54 +0000
Subject: [issue46836] [C API] Move PyFrameObject to the internal C API
In-Reply-To: <1645628652.12.0.0785803095185.issue46836@roundup.psfhosted.org>
Message-ID: <1645717434.13.0.161803534054.issue46836@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> PyAPI_FUNC(PyObject *) _PyEval_EvalFrameDefault(PyThreadState *tstate, struct _interpreter_frame *f, int exc);

I created bpo-46850 "[C API] Move _PyEval_EvalFrameDefault() to the internal C API" for this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46836>
_______________________________________

From report at bugs.python.org  Thu Feb 24 10:44:07 2022
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Feb 2022 15:44:07 +0000
Subject: [issue46836] [C API] Move PyFrameObject to the internal C API
In-Reply-To: <1645628652.12.0.0785803095185.issue46836@roundup.psfhosted.org>
Message-ID: <1645717447.83.0.680444543897.issue46836@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests:  -29656

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46836>
_______________________________________

From report at bugs.python.org  Thu Feb 24 10:50:11 2022
From: report at bugs.python.org (Joongi Kim)
Date: Thu, 24 Feb 2022 15:50:11 +0000
Subject: [issue46843] PersistentTaskGroup API
In-Reply-To: <1645680865.21.0.230450894933.issue46843@roundup.psfhosted.org>
Message-ID: <1645717811.11.0.901103560311.issue46843@roundup.psfhosted.org>


Joongi Kim <me at daybreaker.info> added the comment:

@yselivanov @asvetlov
I think this API suggestion would require more refining and discussion in depths, and probably it may be better to undergo the PEP writing and review process.  Or I might need to have a separate discussion thread somewhere else (maybe discuss.python.org?).

Since I'm just a newbie in terms of Python core/stdlib development, could one of you guide me with what you think as the right way?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46843>
_______________________________________

From report at bugs.python.org  Thu Feb 24 10:56:56 2022
From: report at bugs.python.org (Joongi Kim)
Date: Thu, 24 Feb 2022 15:56:56 +0000
Subject: [issue46622] Add an async variant of lru_cache for coroutines.
In-Reply-To: <1643873308.65.0.92890586202.issue46622@roundup.psfhosted.org>
Message-ID: <1645718216.79.0.305973421708.issue46622@roundup.psfhosted.org>


Change by Joongi Kim <me at daybreaker.info>:


----------
nosy: +achimnol

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46622>
_______________________________________

From report at bugs.python.org  Thu Feb 24 11:03:50 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 24 Feb 2022 16:03:50 +0000
Subject: [issue46622] Add an async variant of lru_cache for coroutines.
In-Reply-To: <1643873308.65.0.92890586202.issue46622@roundup.psfhosted.org>
Message-ID: <1645718630.48.0.579466948362.issue46622@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

[Andrew Svetlov]
> A third-party library should either copy all these 
> implementation details or import a private function from stdlib 

OrderedDict provides just about everything needed to roll lru cache variants.  It simply isn't true this can only be done efficiently in the standard library.


[Serhiy]
> it would be simpler to add a decorator which wraps the result 
> of an asynchronous function into an object which can be awaited
> more than once:

This is much more sensible.

> It can be combined with lru_cache and cached_property any third-party
> caching decorator. No access to internals of the cache is needed.

Right.  The premise that this can only be done in the standard library was false.

> async_lru_cache() and async_cached_property() can be written 
> using that decorator. 

The task becomes trivially easy :-)  


[Andrew Svetlov]
> Pull Request is welcome!

ISTM it was premature to ask for a PR before an idea has been thought through.  We risk wasting a user's time or committing too early before simpler, better designed alternatives emerge.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46622>
_______________________________________

From report at bugs.python.org  Thu Feb 24 11:07:28 2022
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Feb 2022 16:07:28 +0000
Subject: [issue45459] Limited API support for Py_buffer
In-Reply-To: <1634118913.79.0.141868262007.issue45459@roundup.psfhosted.org>
Message-ID: <1645718848.5.0.825438950149.issue45459@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset ec091bd47e2f968b0d1631b9a8104283a7beeb1b by Victor Stinner in branch 'main':
bpo-45459: Add pytypedefs.h header file (GH-31527)
https://github.com/python/cpython/commit/ec091bd47e2f968b0d1631b9a8104283a7beeb1b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45459>
_______________________________________

From report at bugs.python.org  Thu Feb 24 11:13:35 2022
From: report at bugs.python.org (Irit Katriel)
Date: Thu, 24 Feb 2022 16:13:35 +0000
Subject: [issue3539] Problem with testembed make dependencies in certain
 circumstances
In-Reply-To: <1218416155.29.0.722740811463.issue3539@psf.upfronthosting.co.za>
Message-ID: <1645719215.79.0.311284994226.issue3539@roundup.psfhosted.org>


Irit Katriel <iritkatriel at gmail.com> added the comment:

Closing as suggested by Martin.

----------
nosy: +iritkatriel
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3539>
_______________________________________

From report at bugs.python.org  Thu Feb 24 11:45:33 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 24 Feb 2022 16:45:33 +0000
Subject: [issue46843] PersistentTaskGroup API
In-Reply-To: <1645680865.21.0.230450894933.issue46843@roundup.psfhosted.org>
Message-ID: <1645721133.11.0.0866445868528.issue46843@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Could you just have a global task group that owns these long-running tasks? It could be embedded in a "toplevel" task that is created using asyncio.create_task() (which won't be deprecated). To shut down all long-running tasks at the end, just cancel that toplevel task.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46843>
_______________________________________

From report at bugs.python.org  Thu Feb 24 11:52:28 2022
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Feb 2022 16:52:28 +0000
Subject: [issue45459] Limited API support for Py_buffer
In-Reply-To: <1634118913.79.0.141868262007.issue45459@roundup.psfhosted.org>
Message-ID: <1645721548.04.0.513975952607.issue45459@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 042f31da552c19054acd3ef7bb6cfd857bce172b by Victor Stinner in branch 'main':
bpo-45459: C API uses type names rather than structure names (GH-31528)
https://github.com/python/cpython/commit/042f31da552c19054acd3ef7bb6cfd857bce172b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45459>
_______________________________________

From report at bugs.python.org  Thu Feb 24 11:54:14 2022
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Feb 2022 16:54:14 +0000
Subject: [issue46430] intern strings in deepfrozen modules
In-Reply-To: <1642590983.92.0.896257318647.issue46430@roundup.psfhosted.org>
Message-ID: <1645721654.7.0.0301875256908.issue46430@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 4dc746310bd37ad6b381f9176acd167d445f4385 by Kumar Aditya in branch 'main':
bpo-46430: Fix memory leak in interned strings of deep-frozen modules (GH-31549)
https://github.com/python/cpython/commit/4dc746310bd37ad6b381f9176acd167d445f4385


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46430>
_______________________________________

From report at bugs.python.org  Thu Feb 24 12:02:17 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 24 Feb 2022 17:02:17 +0000
Subject: [issue46844] Context-based TaskGroup for legacy libraries
In-Reply-To: <1645681556.47.0.510927748304.issue46844@roundup.psfhosted.org>
Message-ID: <1645722137.2.0.439986473587.issue46844@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

-1. Libraries that manage their own tasks should continue to do so, until they are ready to adopt TaskGroup. Trying to "own" (and wait for) tasks created by a library sounds like a recipe for disaster if the library wasn't expecting that.

Do you have a specific use case or scenario that has bitten you in the past? If you want to continue to argue for this feature we would need specifics (not a link to reams of code but a clear story telling of a problem you've encountered in real life in the past that your proposal might solve).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46844>
_______________________________________

From report at bugs.python.org  Thu Feb 24 12:02:37 2022
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Feb 2022 17:02:37 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1645722157.98.0.365790215581.issue1635741@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29677
pull_request: https://github.com/python/cpython/pull/31555

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Thu Feb 24 12:02:41 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 24 Feb 2022 17:02:41 +0000
Subject: [issue46430] intern strings in deepfrozen modules
In-Reply-To: <1642590983.92.0.896257318647.issue46430@roundup.psfhosted.org>
Message-ID: <1645722161.19.0.420182425751.issue46430@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
pull_requests: +29678
pull_request: https://github.com/python/cpython/pull/31556

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46430>
_______________________________________

From report at bugs.python.org  Thu Feb 24 12:02:57 2022
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Feb 2022 17:02:57 +0000
Subject: [issue46430] intern strings in deepfrozen modules
In-Reply-To: <1642590983.92.0.896257318647.issue46430@roundup.psfhosted.org>
Message-ID: <1645722177.89.0.465860945018.issue46430@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I wrote https://github.com/python/cpython/pull/31555 to make sure that Python doesn't leak at Python exit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46430>
_______________________________________

From report at bugs.python.org  Thu Feb 24 12:04:41 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 24 Feb 2022 17:04:41 +0000
Subject: [issue46430] intern strings in deepfrozen modules
In-Reply-To: <1642590983.92.0.896257318647.issue46430@roundup.psfhosted.org>
Message-ID: <1645722281.54.0.12131083909.issue46430@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

> How it should be handled? Currently PyUnicode_InternInPlace ignores any errors and does not return it. It would be backwards-incompatible to change that, moreover as I explained in https://github.com/python/cpython/pull/30683#discussion_r800648477 intern_strings only check if all the items are strings which will be always true in case of deep-freeze so I don't think anything needs to be changed here. I would be interested to know if I am missing something though.

The other functions you are calling *do* return errors. You should not ignore those. If any errors are reported the caller can decide what to do (e.g. call Py_FatalError().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46430>
_______________________________________

From report at bugs.python.org  Thu Feb 24 12:49:09 2022
From: report at bugs.python.org (Steve Dower)
Date: Thu, 24 Feb 2022 17:49:09 +0000
Subject: [issue46833] Installer Wizard is unclear and has redundant settings
In-Reply-To: <1645604528.5.0.846357801282.issue46833@roundup.psfhosted.org>
Message-ID: <1645724949.78.0.723152227966.issue46833@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

So I'm the "team" that designed it the first time (with input from others, of course, but it wasn't designed by a committee or anything), and the primary goal was to enable a single-click install for the majority of users, biased towards simplicity for users who are less-experienced at administering a Windows PC. This was balanced with the fact that many users would already have 2.7 or 3.4 installed, and those installers had some poor, and irreversible, design flaws.

These flaws forced us to install py.exe for all users by default, otherwise the majority of people would end up installing it lower on PATH and would never get the updates. As a result, it would break, because the launcher included with 3.4 wouldn't reliably detect 3.5, and we didn't have any option to detect or upgrade it.

However, this meant that admin permissions would be required for a default install, which is not acceptable. So the front page option to switch that setting was added so that non-admin users could easily disable the admin requirement.

The PATH option was added under protest, because too many users/teachers rely on it for their coursework and wanted it to be easier to find. If we could safely enable it by default we would, but it's fundamentally an unsafe operation. But it's popular, so that's why it's on the front page.

So unsurprisingly, I like your variant A the best, which is really just tweaking the Tools/msi/bundle/Default.thm file a bit. It maintains the short path for those who want it (which we believe is the majority of users), and hopefully makes it clearer for advanced users.

I dislike variant C because of the second page for simple installs. And for variant D we wouldn't offer per-machine installs for the runtime, and we wouldn't offer PATH options for the launcher, so it basically boils down to making the advanced button harder to find with less explanation.

So if you'd like to propose a PR with changes to the files in Tools/msi/bundle to match your actual UIs, feel free. It _should_ automatically build the installer if you've modified those files, and you _should_ be able to download it for testing, though if not it isn't hard to build locally with Tools/msi/build.bat.

(And of course, this would only apply to 3.11, so I've updated the version field.)

----------
versions: +Python 3.11 -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46833>
_______________________________________

From report at bugs.python.org  Thu Feb 24 12:54:19 2022
From: report at bugs.python.org (Kevin Hock)
Date: Thu, 24 Feb 2022 17:54:19 +0000
Subject: [issue45991] Improve ambiguous docstrings in pkgutil
In-Reply-To: <1638730607.25.0.754715317111.issue45991@roundup.psfhosted.org>
Message-ID: <1645725259.55.0.254880531934.issue45991@roundup.psfhosted.org>


Kevin Hock <khock at pinterest.com> added the comment:

At best it is ambiguous, with the class being confused with Str being called Path. Looking up "AttributeError: 'PosixPath' object has no attribute 'startswith'" gives a lot of results for similar issues, so I think the wording could be improved.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45991>
_______________________________________

From report at bugs.python.org  Thu Feb 24 14:12:34 2022
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Thu, 24 Feb 2022 19:12:34 +0000
Subject: [issue46851] Document multiprocessing.set_forkserver_preload
Message-ID: <1645729954.43.0.679876278884.issue46851@roundup.psfhosted.org>


New submission from G?ry <gery.ogam at gmail.com>:

I have just notice that the multiprocessing.set_forkserver_preload (which originates from multiprocessing.forkserver.set_forkserver_preload) is not documented:
https://github.com/python/cpython/blob/v3.10.2/Lib/multiprocessing/context.py#L180-L185

----------
messages: 413934
nosy: docs at python, maggyero
priority: normal
severity: normal
status: open
title: Document multiprocessing.set_forkserver_preload
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46851>
_______________________________________

From report at bugs.python.org  Thu Feb 24 14:35:01 2022
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 24 Feb 2022 19:35:01 +0000
Subject: [issue45107] Improve LOAD_METHOD specialization
In-Reply-To: <1630859956.74.0.360849757822.issue45107@roundup.psfhosted.org>
Message-ID: <1645731301.87.0.426579815843.issue45107@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset 2a6ece572ca38f989fca66f4c053cb16550bccd4 by Mark Shannon in branch 'main':
bpo-45107: Specialize `LOAD_METHOD` for instances with dict. (GH-31531)
https://github.com/python/cpython/commit/2a6ece572ca38f989fca66f4c053cb16550bccd4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45107>
_______________________________________

From report at bugs.python.org  Thu Feb 24 14:52:08 2022
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 24 Feb 2022 19:52:08 +0000
Subject: [issue45898] ctypes cfield.c defines duplicate ffi_type_* symbols
In-Reply-To: <1637841460.9.0.780352638967.issue45898@roundup.psfhosted.org>
Message-ID: <1645732328.57.0.14264851948.issue45898@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset 38f331d4656394ae0f425568e26790ace778e076 by Christian Heimes in branch 'main':
bpo-45898: Remove duplicate symbols from _ctypes/cfield.c (GH-29791)
https://github.com/python/cpython/commit/38f331d4656394ae0f425568e26790ace778e076


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45898>
_______________________________________

From report at bugs.python.org  Thu Feb 24 15:00:27 2022
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 24 Feb 2022 20:00:27 +0000
Subject: [issue45898] ctypes cfield.c defines duplicate ffi_type_* symbols
In-Reply-To: <1637841460.9.0.780352638967.issue45898@roundup.psfhosted.org>
Message-ID: <1645732827.05.0.998557897587.issue45898@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

I have applied the patch to main branch (3.11). The workaround for Windows turned out to be more elaborate than initially anticipated. I'm not going to backport the fix to 3.10 and 3.9.

----------
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/issue45898>
_______________________________________

From report at bugs.python.org  Thu Feb 24 15:09:00 2022
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 24 Feb 2022 20:09:00 +0000
Subject: [issue46835] ImportError: bad magic number in ... does not indicate
 where is that file located
In-Reply-To: <1645620216.31.0.535281755903.issue46835@roundup.psfhosted.org>
Message-ID: <1645733340.82.0.405419904903.issue46835@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/issue46835>
_______________________________________

From report at bugs.python.org  Thu Feb 24 17:07:07 2022
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Thu, 24 Feb 2022 22:07:07 +0000
Subject: [issue46851] Document multiprocessing.set_forkserver_preload
In-Reply-To: <1645729954.43.0.679876278884.issue46851@roundup.psfhosted.org>
Message-ID: <1645740427.8.0.683368456691.issue46851@roundup.psfhosted.org>


Change by G?ry <gery.ogam at gmail.com>:


----------
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46851>
_______________________________________

From report at bugs.python.org  Thu Feb 24 18:03:24 2022
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Feb 2022 23:03:24 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1645743804.13.0.330037900497.issue1635741@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset c9c178fdb1af01e441a6c83f3a21a67e5dd9f17d by Victor Stinner in branch 'main':
bpo-1635741: test_embed cheks that Python does not leak (GH-31555)
https://github.com/python/cpython/commit/c9c178fdb1af01e441a6c83f3a21a67e5dd9f17d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Thu Feb 24 18:32:13 2022
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Feb 2022 23:32:13 +0000
Subject: [issue46623] test_zlib: test_pair() and test_speech128() fail with
 s390x hardware accelerator
In-Reply-To: <1643877280.17.0.469977325894.issue46623@roundup.psfhosted.org>
Message-ID: <1645745533.32.0.30969707909.issue46623@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 9475dc0b8d2a0db40278bbcb88a89b1265a77ec9 by Victor Stinner in branch 'main':
bpo-46623: Skip two test_zlib tests on s390x (GH-31096)
https://github.com/python/cpython/commit/9475dc0b8d2a0db40278bbcb88a89b1265a77ec9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46623>
_______________________________________

From report at bugs.python.org  Thu Feb 24 18:32:50 2022
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Feb 2022 23:32:50 +0000
Subject: [issue46623] test_zlib: test_pair() and test_speech128() fail with
 s390x hardware accelerator
In-Reply-To: <1643877280.17.0.469977325894.issue46623@roundup.psfhosted.org>
Message-ID: <1645745570.97.0.0375957584737.issue46623@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Even if Python 3.9 and 3.10 are also affected, I prefer to not backport the change since it's not ideal.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46623>
_______________________________________

From report at bugs.python.org  Thu Feb 24 18:34:55 2022
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Feb 2022 23:34:55 +0000
Subject: [issue46623] test_zlib: test_pair() and test_speech128() fail with
 s390x hardware accelerator
In-Reply-To: <1643877280.17.0.469977325894.issue46623@roundup.psfhosted.org>
Message-ID: <1645745695.02.0.631321249272.issue46623@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The Python 3.7 package on Fedora also skips these two tests using --ignore option of regrtest:
	
    %ifarch s390x
    --ignore test_speech128 \
    --ignore test_pair \
    %endif

* https://src.fedoraproject.org/rpms/python3.7/pull-request/38#request_diff
* https://src.fedoraproject.org/rpms/python3.7/blob/rawhide/f/python3.7.spec#_1168

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46623>
_______________________________________

From report at bugs.python.org  Thu Feb 24 18:44:50 2022
From: report at bugs.python.org (Alex Waygood)
Date: Thu, 24 Feb 2022 23:44:50 +0000
Subject: [issue46851] Document multiprocessing.set_forkserver_preload
In-Reply-To: <1645729954.43.0.679876278884.issue46851@roundup.psfhosted.org>
Message-ID: <1645746290.61.0.577397070303.issue46851@roundup.psfhosted.org>


Alex Waygood <Alex.Waygood at Gmail.com> added the comment:

(3.7 and 3.8 are not accepting patches unless they relate to security issues, so I am removing them from the "versions" field.)

----------
nosy: +AlexWaygood
versions:  -Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46851>
_______________________________________

From report at bugs.python.org  Thu Feb 24 18:44:54 2022
From: report at bugs.python.org (Alex Waygood)
Date: Thu, 24 Feb 2022 23:44:54 +0000
Subject: [issue46851] Document multiprocessing.set_forkserver_preload
In-Reply-To: <1645729954.43.0.679876278884.issue46851@roundup.psfhosted.org>
Message-ID: <1645746294.31.0.502335611568.issue46851@roundup.psfhosted.org>


Change by Alex Waygood <Alex.Waygood at Gmail.com>:


----------
nosy:  -AlexWaygood

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46851>
_______________________________________

From report at bugs.python.org  Thu Feb 24 18:51:32 2022
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Feb 2022 23:51:32 +0000
Subject: [issue46656] Compile fails if Py_NO_NAN is defined
In-Reply-To: <1644141275.01.0.967715714071.issue46656@roundup.psfhosted.org>
Message-ID: <1645746692.08.0.339029648846.issue46656@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29679
pull_request: https://github.com/python/cpython/pull/31557

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46656>
_______________________________________

From report at bugs.python.org  Thu Feb 24 19:07:57 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 00:07:57 +0000
Subject: [issue46852] Remove float.__get_format__() and float.__set_format__()
Message-ID: <1645747677.37.0.919337626983.issue46852@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

It has been decided to require IEEE 754 to build Python 3.11:
https://mail.python.org/archives/list/python-dev at python.org/thread/J5FSP6J4EITPY5C2UJI7HSL2GQCTCUWN/

At Python startup, _PyFloat_InitState() checks the IEEE 754 format at runtime. It can be changed using float.__get_format__() and  float.__set_format__() methods.

These methods docstrings say that they only exist to test Python itself:

"You probably don't want to use this function. It exists mainly to be used in Python's test suite."

These methods are private and not documented.

I propose to remove them.

Once they will be removed, it will become possible to move the detection of the IEEE 754 format in the build step (./configure script) rather than doing the detection at runtime (slower). It would remove an "if" in _PyFloat_Pack4() and _PyFloat_Pack8(), and allow to specialize these functions for the detected format at build time. These functions are used by serialization formats: marshal, pickle and struct.

----------
components: Interpreter Core
messages: 413943
nosy: vstinner
priority: normal
severity: normal
status: open
title: Remove float.__get_format__() and  float.__set_format__()
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46852>
_______________________________________

From report at bugs.python.org  Thu Feb 24 19:31:35 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 00:31:35 +0000
Subject: [issue46656] Compile fails if Py_NO_NAN is defined
In-Reply-To: <1644141275.01.0.967715714071.issue46656@roundup.psfhosted.org>
Message-ID: <1645749095.76.0.496003362423.issue46656@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 5f8b5e2f2150d2223ff9e286bd146de92ff16865 by Victor Stinner in branch 'main':
bpo-46656: Building Python now requires a C11 compiler (GH-31557)
https://github.com/python/cpython/commit/5f8b5e2f2150d2223ff9e286bd146de92ff16865


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46656>
_______________________________________

From report at bugs.python.org  Thu Feb 24 19:33:01 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 00:33:01 +0000
Subject: [issue46656] Compile fails if Py_NO_NAN is defined
In-Reply-To: <1644141275.01.0.967715714071.issue46656@roundup.psfhosted.org>
Message-ID: <1645749181.23.0.18616745772.issue46656@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 1b2611eb0283055835e5df632a7a735db8c894b8 by Victor Stinner in branch 'main':
bpo-46656: Remove Py_NO_NAN macro (GH-31160)
https://github.com/python/cpython/commit/1b2611eb0283055835e5df632a7a735db8c894b8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46656>
_______________________________________

From report at bugs.python.org  Thu Feb 24 19:40:46 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 25 Feb 2022 00:40:46 +0000
Subject: [issue46852] Remove float.__get_format__() and float.__set_format__()
In-Reply-To: <1645747677.37.0.919337626983.issue46852@roundup.psfhosted.org>
Message-ID: <1645749646.16.0.472972215433.issue46852@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I would not miss these methods.  Unless Mark says they are needed, +1 for removal.

----------
nosy: +mark.dickinson, rhettinger, tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46852>
_______________________________________

From report at bugs.python.org  Thu Feb 24 19:45:52 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 00:45:52 +0000
Subject: [issue46656] Remove the Py_NO_NAN macro: require NAN to build Python
 3.11
In-Reply-To: <1644141275.01.0.967715714071.issue46656@roundup.psfhosted.org>
Message-ID: <1645749952.2.0.320819609888.issue46656@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
components: +Build, Interpreter Core
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
title: Compile fails if Py_NO_NAN is defined -> Remove the Py_NO_NAN macro: require NAN to build Python 3.11
versions:  -Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46656>
_______________________________________

From report at bugs.python.org  Thu Feb 24 19:48:34 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 00:48:34 +0000
Subject: [issue46852] Remove float.__get_format__() and float.__set_format__()
In-Reply-To: <1645747677.37.0.919337626983.issue46852@roundup.psfhosted.org>
Message-ID: <1645750114.21.0.0768052834951.issue46852@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

See also bpo-46656: "Remove the Py_NO_NAN macro: require NAN to build Python 3.11".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46852>
_______________________________________

From report at bugs.python.org  Thu Feb 24 19:54:40 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 00:54:40 +0000
Subject: [issue46852] Remove float.__get_format__() and float.__set_format__()
In-Reply-To: <1645747677.37.0.919337626983.issue46852@roundup.psfhosted.org>
Message-ID: <1645750480.8.0.44647546371.issue46852@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Oh wait, I'm now confused by the method names. In Python 3.10, the correct names at:

* float.__getformat__() <= 4 underscores
* float.__set_format__() <= 5 underscores

It's even more confusing because the "set format" is only used in one place: test_float, and test_float uses... __setformat__() (4 underscores).

A typo a was introduced in Python 3.7 by:

commit b5c51d3dd95bbfde533655fb86ac0f96f771ba7b
Author: Serhiy Storchaka <storchaka at gmail.com>
Date:   Sat Mar 11 09:21:05 2017 +0200

    bpo-20185: Convert float object implementation to Argument Clinic. (#543)
    
    Based on patch by Vajrasky Kok.

Since Python 3.7, the 4 "set format" tests are simply skipped!

$ ./python -m test -v test_float
(...)
test_getformat (test.test_float.FormatFunctionsTestCase) ... skipped 'requires __setformat__'
test_setformat (test.test_float.FormatFunctionsTestCase) ... skipped 'requires __setformat__'
(...)
test_double_specials_dont_unpack (test.test_float.UnknownFormatTestCase) ... skipped 'requires __setformat__'
test_float_specials_dont_unpack (test.test_float.UnknownFormatTestCase) ... skipped 'requires __setformat__'
(...)


Moreover, unittest.mock supports mocking __setformat__() (4 underscores).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46852>
_______________________________________

From report at bugs.python.org  Thu Feb 24 20:06:10 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 01:06:10 +0000
Subject: [issue46852] Remove float.__get_format__() and float.__set_format__()
In-Reply-To: <1645747677.37.0.919337626983.issue46852@roundup.psfhosted.org>
Message-ID: <1645751170.12.0.902122285176.issue46852@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +29680
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31558

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46852>
_______________________________________

From report at bugs.python.org  Thu Feb 24 20:06:11 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 01:06:11 +0000
Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13
 files
In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za>
Message-ID: <1645751171.43.0.248843978632.issue20185@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +vstinner
nosy_count: 10.0 -> 11.0
pull_requests: +29681
pull_request: https://github.com/python/cpython/pull/31558

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20185>
_______________________________________

From report at bugs.python.org  Thu Feb 24 20:06:53 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 01:06:53 +0000
Subject: [issue46852] Remove float.__get_format__() and float.__set_format__()
In-Reply-To: <1645747677.37.0.919337626983.issue46852@roundup.psfhosted.org>
Message-ID: <1645751213.0.0.753897708966.issue46852@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I wrote GH-31558 to fix the typo in the method name.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46852>
_______________________________________

From report at bugs.python.org  Thu Feb 24 20:10:59 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 01:10:59 +0000
Subject: [issue46852] Remove the float.__setformat__() method
In-Reply-To: <1645747677.37.0.919337626983.issue46852@roundup.psfhosted.org>
Message-ID: <1645751459.44.0.0336417050235.issue46852@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

We can keep the float.__getformat__() method, it doesn't harm. I change the issue title to only propose to remove the float.__setformat__() method.

----------
title: Remove float.__get_format__() and  float.__set_format__() -> Remove the float.__setformat__() method

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46852>
_______________________________________

From report at bugs.python.org  Thu Feb 24 20:17:45 2022
From: report at bugs.python.org (=?utf-8?q?Tin_Tvrtkovi=C4=87?=)
Date: Fri, 25 Feb 2022 01:17:45 +0000
Subject: [issue46752] Introduce task groups to asyncio and change task
 cancellation semantics
In-Reply-To: <1644871469.64.0.38816696304.issue46752@roundup.psfhosted.org>
Message-ID: <1645751865.46.0.71924828984.issue46752@roundup.psfhosted.org>


Change by Tin Tvrtkovi? <tinchester at gmail.com>:


----------
pull_requests: +29682
pull_request: https://github.com/python/cpython/pull/31559

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46752>
_______________________________________

From report at bugs.python.org  Thu Feb 24 20:19:53 2022
From: report at bugs.python.org (Steve Dower)
Date: Fri, 25 Feb 2022 01:19:53 +0000
Subject: [issue46567] Add Tcl/Tk builds for ARM64
In-Reply-To: <1643388941.84.0.746346851464.issue46567@roundup.psfhosted.org>
Message-ID: <1645751993.63.0.859178820155.issue46567@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Getting this done with some help from colleagues. Tcl and Tk have been updated to support it, and I've pulled down their patches into our source repo.

Hopefully I find time to get the build and setup updates done before the next alpha... adding Pablo just to say that if you feel like deferring by a day or two, I will fully support you :)

----------
assignee:  -> steve.dower
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46567>
_______________________________________

From report at bugs.python.org  Thu Feb 24 20:57:53 2022
From: report at bugs.python.org (i5-7200u)
Date: Fri, 25 Feb 2022 01:57:53 +0000
Subject: [issue46853] Python interpreter can get code from memory,
 it is not secure.
Message-ID: <1645754273.34.0.366451994283.issue46853@roundup.psfhosted.org>


New submission from i5-7200u <aemre7478 at gmail.com>:

Hi, Python Interpreter have a big security bug/error.

My friend and l am. We can give virus code to Python Interpreter.

we were looking for run a binary application from memory (byte array)

Later we find python, but we got it is security bug/error

example from my friend:
https://www.virustotal.com/gui/file/6fc3ad98c40e6962f3c29e07735f7ae25e50092c3d7595201740a954ad5f3cf4?nocache=1

https://github.com/ArdaKC/run-python-in-java

if we encrypt python virus code and give to java codes as byte array and we decrypt python virus code and give to python interpreter from memory then antiviruses never detect it (not comodo, comodo have a strong hips and auto conmaintent) but we dont it.

we just want to fix this bug. for more peoples security. Please.


This bug is reported by KCS Team.

----------
components: Interpreter Core
files: afterexample.png
messages: 413952
nosy: i5-7200u
priority: normal
severity: normal
status: open
title: Python interpreter can get code from memory, it is not secure.
type: security
versions: Python 3.11
Added file: https://bugs.python.org/file50642/afterexample.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46853>
_______________________________________

From report at bugs.python.org  Thu Feb 24 21:02:59 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 02:02:59 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1645754579.94.0.14687872944.issue1635741@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29683
pull_request: https://github.com/python/cpython/pull/31560

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Thu Feb 24 21:05:45 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 02:05:45 +0000
Subject: [issue46852] Remove the float.__setformat__() method
In-Reply-To: <1645747677.37.0.919337626983.issue46852@roundup.psfhosted.org>
Message-ID: <1645754745.4.0.451664370293.issue46852@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 7d03c8be5af2f1559dbc35b775b3116dfd63cfb6 by Victor Stinner in branch 'main':
bpo-46852: Rename float.__set_format__() to float.__setformat__() (GH-31558)
https://github.com/python/cpython/commit/7d03c8be5af2f1559dbc35b775b3116dfd63cfb6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46852>
_______________________________________

From report at bugs.python.org  Thu Feb 24 21:05:45 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 02:05:45 +0000
Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13
 files
In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za>
Message-ID: <1645754745.51.0.258073320409.issue20185@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 7d03c8be5af2f1559dbc35b775b3116dfd63cfb6 by Victor Stinner in branch 'main':
bpo-46852: Rename float.__set_format__() to float.__setformat__() (GH-31558)
https://github.com/python/cpython/commit/7d03c8be5af2f1559dbc35b775b3116dfd63cfb6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20185>
_______________________________________

From report at bugs.python.org  Thu Feb 24 21:16:52 2022
From: report at bugs.python.org (sping)
Date: Fri, 25 Feb 2022 02:16:52 +0000
Subject: [issue46793] expose expat XML billion laughs attack mitigation APIs
In-Reply-To: <1645219651.82.0.456438689192.issue46793@roundup.psfhosted.org>
Message-ID: <1645755412.66.0.494128607865.issue46793@roundup.psfhosted.org>


sping <sebastian at pipping.org> added the comment:

First mention at https://bugs.python.org/issue44394#msg395642

----------
nosy: +sping

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46793>
_______________________________________

From report at bugs.python.org  Thu Feb 24 21:37:26 2022
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 25 Feb 2022 02:37:26 +0000
Subject: [issue12165] [doc] clarify documentation of nonlocal
In-Reply-To: <1306216657.18.0.255448168009.issue12165@psf.upfronthosting.co.za>
Message-ID: <1645756646.95.0.142533674709.issue12165@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> I think this is more confusing then helpful.

I concur.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12165>
_______________________________________

From report at bugs.python.org  Thu Feb 24 22:15:31 2022
From: report at bugs.python.org (Stanley)
Date: Fri, 25 Feb 2022 03:15:31 +0000
Subject: [issue45991] Improve ambiguous docstrings in pkgutil
In-Reply-To: <1638730607.25.0.754715317111.issue45991@roundup.psfhosted.org>
Message-ID: <1645758931.26.0.24824301871.issue45991@roundup.psfhosted.org>


Stanley <ostanley.lee at gmail.com> added the comment:

While it is ambiguous, when there's a path parameter I would default it to string unless otherwise specified. Maybe instead a note could be put in the Pathlib doc noting functions that accept path arguments might not accept Path objects?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45991>
_______________________________________

From report at bugs.python.org  Thu Feb 24 22:46:49 2022
From: report at bugs.python.org (aprpp)
Date: Fri, 25 Feb 2022 03:46:49 +0000
Subject: [issue46854] Failed to compile static python3.7.12
Message-ID: <1645760809.24.0.711406085286.issue46854@roundup.psfhosted.org>


New submission from aprpp <916495294 at qq.com>:

I compile static version of python3.7.12, I added the static standard library that I want to compile in Modules/Setup, reference Modules/Setup.dist in python source, like this:

static

Modules that should always be present (non UNIX dependent):
array arraymodule.c # array objects
cmath cmathmodule.c _math.c # -lm # complex math library functions
math mathmodule.c _math.c # -lm # math library functions, e.g. sin()
_contextvars _contextvarsmodule.c # Context Variables
_struct _struct.c # binary structure packing/unpacking

But there are still many modules that fail to compile, these modules with no commented out build definitions in the Modules/Setup.dist file. How do I add these modules build definitions to the Modules/Setup, yes they compile successfully ?

Failed to build these modules:
_bz2                  _ctypes               _ctypes_test
_decimal              _hashlib              _json
_lsprof               _lzma                 _multiprocessing
_opcode               _ssl                  _testbuffer
_testimportmultiple   _testmultiphase       _uuid
_xxtestfuzz           ossaudiodev           xxlimited

----------
components: Build
files: ??.PNG
messages: 413958
nosy: aprpp
priority: normal
severity: normal
status: open
title: Failed to compile static python3.7.12
type: compile error
versions: Python 3.7
Added file: https://bugs.python.org/file50643/??.PNG

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46854>
_______________________________________

From report at bugs.python.org  Thu Feb 24 23:05:18 2022
From: report at bugs.python.org (Joongi Kim)
Date: Fri, 25 Feb 2022 04:05:18 +0000
Subject: [issue46843] PersistentTaskGroup API
In-Reply-To: <1645680865.21.0.230450894933.issue46843@roundup.psfhosted.org>
Message-ID: <1645761918.07.0.0118762835065.issue46843@roundup.psfhosted.org>


Joongi Kim <me at daybreaker.info> added the comment:

@gvanrossum As you mentioned, the event loop currently plays the role of the top-level task group already, even without introducing yet another top-level task.  For instance, asyncio.run() includes necessary shutdown procedures to cancel all belonging unfinished tasks and async generators.

However, I think we should provide an abstraction to organize the shutdown procedures in a *hierarchical* manner.  For example, we could cancel all event handler tasks before cancelling all HTTP handler tasks upon a web server shutdown.  This prevents any potential races between theses two different task sets.  I think you could agree with the necessity of orderly release of underlying resources during shutdown in general.  Currently asyncio.Task.all_tasks() is just a list created from WeakSet and we cannot guarantee which tasks will be cancelled first.

Yes, this can be done by manually writing codes to declare multiple WeakSets and a for-loop to cancel the contained tasks by enumerating over them, just like asyncio.run() does.  With the new addition of TaskGroup and ExceptionGroup, this code does not require core changes of Python.

But I believe that this hierarchical persistent task group abstraction should be an essential part of the API and asyncio tutorials when writing server applications.  asyncio.run() could be written by users, but I think the core devs have agreed with that it is an essential abstraction to be included in the stdlib.  I'd like argue that hierarchical persistent task groups is the same case.

Though I named it "PersistentTaskGroup" because it looks similar to TaskGroup, but this name may be misleading.  In PersistentTaskGroup, even when all tasks finish successfully, it does NOT terminate but keeps waiting for new tasks to be spawned.  It terminates only when the outer task is cancelled or its shutdown() method is called.  Note that belonging tasks may be either short-running or long-running, and this does not matter.  The point is to shutdown any remaining tasks in an orderly manner.  If you don't like the naming, please suggest alternatives.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46843>
_______________________________________

From report at bugs.python.org  Thu Feb 24 23:07:51 2022
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 25 Feb 2022 04:07:51 +0000
Subject: [issue46606] Large C stack usage of os.getgroups() and os.setgroups()
In-Reply-To: <1643771204.31.0.0513908090604.issue46606@roundup.psfhosted.org>
Message-ID: <1645762071.89.0.312357830792.issue46606@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +29684
pull_request: https://github.com/python/cpython/pull/31561

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46606>
_______________________________________

From report at bugs.python.org  Thu Feb 24 23:20:29 2022
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 25 Feb 2022 04:20:29 +0000
Subject: [issue43364] Windows: Make UTF-8 mode more accessible
In-Reply-To: <1614675827.66.0.411790166938.issue43364@roundup.psfhosted.org>
Message-ID: <1645762829.32.0.124155474328.issue43364@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43364>
_______________________________________

From report at bugs.python.org  Thu Feb 24 23:45:01 2022
From: report at bugs.python.org (Joongi Kim)
Date: Fri, 25 Feb 2022 04:45:01 +0000
Subject: [issue46843] PersistentTaskGroup API
In-Reply-To: <1645680865.21.0.230450894933.issue46843@roundup.psfhosted.org>
Message-ID: <1645764301.0.0.265718415405.issue46843@roundup.psfhosted.org>


Joongi Kim <me at daybreaker.info> added the comment:

This particular experience, https://github.com/lablup/backend.ai-agent/pull/331, has actually motivated me to suggest PersistentTaskGroup.

The program subscribes the event stream of Docker daemon using aiohttp as an asyncio task, and this should be kept running throughout the whole application lifetime.  I first applied aiotools.TaskGroup to ensure shutdown of spawned event handler tasks, but I missed that it cancels all sibling tasks if one of the spawned tasks bubbles up an unhandled exception.  This has caused silent termination of the subscriber task and led to a bug.  We could debug this issue by inspecting aiomonitor and checking the existence of this task.  After this issue, I began to think we need a proper abstraction of a long-running task group (NOTE: the task group is long-running.  The lifetime of internal tasks does not matter).

Another case is that https://github.com/lablup/backend.ai/issues/330.

One of our customer site has suffered from excessive CPU usage by our program.  We could identify the issue by aiomonitor, and the root cause was the indefinite accumulation of peridoically created asyncio tasks to measure the disk usage of user directories, when there are too many files in them.  Since the number of tasks have exceeded 10K, it was very difficult to group and distinguish individual asyncio tasks in aiomonitor.  I thought that it would be nice if we could group such tasks into long-running groups and view task statistics separately.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46843>
_______________________________________

From report at bugs.python.org  Thu Feb 24 23:50:50 2022
From: report at bugs.python.org (Stanley)
Date: Fri, 25 Feb 2022 04:50:50 +0000
Subject: [issue27583] [doc ] configparser: modifying default_section at runtime
In-Reply-To: <1469105653.63.0.572086425799.issue27583@psf.upfronthosting.co.za>
Message-ID: <1645764650.81.0.744269606835.issue27583@roundup.psfhosted.org>


Change by Stanley <ostanley.lee at gmail.com>:


----------
keywords: +patch
nosy: +slateny
nosy_count: 5.0 -> 6.0
pull_requests: +29685
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31562

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27583>
_______________________________________

From report at bugs.python.org  Thu Feb 24 23:58:36 2022
From: report at bugs.python.org (Joongi Kim)
Date: Fri, 25 Feb 2022 04:58:36 +0000
Subject: [issue46843] PersistentTaskGroup API
In-Reply-To: <1645680865.21.0.230450894933.issue46843@roundup.psfhosted.org>
Message-ID: <1645765116.66.0.384556133567.issue46843@roundup.psfhosted.org>


Joongi Kim <me at daybreaker.info> added the comment:

I ended up with the following conclusion:
- The new abstraction should not cancel sibling tasks and itself upon unhandled execption but loudly report such errors (and the fallback error handler should be customizable).
- Nesting task groups will give additional benefits such as orderly shutdown of different task groups.  Empty up message queues before shutting down netweork connections, etc.

You may take my suggestion as "let's have a hierarchical nested virtual event loops to group tasks".  PersistentTaskGroup actually shares many characteristics with the event loop while itself is not an event loop.

So I came up with WeakSet with task decorators to handle exceptions by my own, and this is the current rudimentary implementation of PersistentTaskGroup in aiotools.

And I discovered from the additional search results that the same pattern ---managing sporadic tasks using WeakSet and writing a proper cancellation loop of them---appear quite commonly in many different asyncio applications and libraries.

So that's why I think this should be an intrinsic/essential abstraction.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46843>
_______________________________________

From report at bugs.python.org  Fri Feb 25 00:04:59 2022
From: report at bugs.python.org (Joongi Kim)
Date: Fri, 25 Feb 2022 05:04:59 +0000
Subject: [issue46843] PersistentTaskGroup API
In-Reply-To: <1645680865.21.0.230450894933.issue46843@roundup.psfhosted.org>
Message-ID: <1645765499.3.0.500657684064.issue46843@roundup.psfhosted.org>


Joongi Kim <me at daybreaker.info> added the comment:

Here is one another story.

When handling message queues in distributed applications, I use the following pattern frequently for graceful shutdown:
* Use a sentinel object to signal the end of queue.
* Enqueue the sentinel object when:
  - The server is shutting down. (i.e., cancelled explicitly)
  - The connection peer has sent an explicit termination message. (e.g., EOF)
* Wait until all enqueued messages before the sentinal object to be processed.
  - I'd like to impose a shutdown timeout on here using a persistent task group, by spawning all handler tasks of this queue into it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46843>
_______________________________________

From report at bugs.python.org  Fri Feb 25 00:13:48 2022
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 25 Feb 2022 05:13:48 +0000
Subject: [issue46606] Large C stack usage of os.getgroups() and os.setgroups()
In-Reply-To: <1643771204.31.0.0513908090604.issue46606@roundup.psfhosted.org>
Message-ID: <1645766028.27.0.489218212818.issue46606@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset ad6c7003e38a9f8bdf8d865fb5fa0f3c03690315 by Inada Naoki in branch 'main':
bpo-46606: Remove redundant +1. (GH-31561)
https://github.com/python/cpython/commit/ad6c7003e38a9f8bdf8d865fb5fa0f3c03690315


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46606>
_______________________________________

From report at bugs.python.org  Fri Feb 25 00:23:27 2022
From: report at bugs.python.org (Joongi Kim)
Date: Fri, 25 Feb 2022 05:23:27 +0000
Subject: [issue46844] Context-based TaskGroup for legacy libraries
In-Reply-To: <1645681556.47.0.510927748304.issue46844@roundup.psfhosted.org>
Message-ID: <1645766607.05.0.16586507729.issue46844@roundup.psfhosted.org>


Joongi Kim <me at daybreaker.info> added the comment:

I have added more about my stories in bpo-46843.

I think the suggestion of implicit taskgroup binding with the current asyncio.TaskGroup has no point but it would have more meaning with PersistentTaskGroup.

So, if we treat PersistentTaskGroup as a "nested, hierarchical virtual event loop" to repeat and group shutdown procedures for different task sets separately, the point may look a little bit clearer.

It is more like assigning a virtual event loop to different modules and libraries, while keeping the behavior of asyncio.create_task() same.  The difference is that the caller controls when these virtual loops are terminated and in what order.

Does this make sense better?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46844>
_______________________________________

From report at bugs.python.org  Fri Feb 25 00:41:15 2022
From: report at bugs.python.org (Joongi Kim)
Date: Fri, 25 Feb 2022 05:41:15 +0000
Subject: [issue46844] Implicit binding of PersistentTaskGroup (or virtual
 event loops)
In-Reply-To: <1645681556.47.0.510927748304.issue46844@roundup.psfhosted.org>
Message-ID: <1645767675.0.0.931672435548.issue46844@roundup.psfhosted.org>


Joongi Kim <me at daybreaker.info> added the comment:

Updated the title to reduce confusion.

----------
title: Context-based TaskGroup for legacy libraries -> Implicit binding of PersistentTaskGroup (or virtual event loops)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46844>
_______________________________________

From report at bugs.python.org  Fri Feb 25 00:58:52 2022
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 25 Feb 2022 05:58:52 +0000
Subject: [issue46845] dict: Use smaller entry for Unicode-key only dict.
In-Reply-To: <1645688455.61.0.00785191075466.issue46845@roundup.psfhosted.org>
Message-ID: <1645768732.24.0.904295437408.issue46845@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
keywords: +patch
pull_requests: +29686
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31564

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46845>
_______________________________________

From report at bugs.python.org  Fri Feb 25 01:22:06 2022
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 25 Feb 2022 06:22:06 +0000
Subject: [issue12165] [doc] clarify documentation of nonlocal
In-Reply-To: <1306216657.18.0.255448168009.issue12165@psf.upfronthosting.co.za>
Message-ID: <1645770126.48.0.441148254768.issue12165@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> Another problem with the current text is that it fails to exclude 
> enclosing class scopes

The nonlocal statement is only disallowed in module code (i.e. "exec" compilation mode) because it can never be nested. It's allowed in a class definition that has an outer function scope. A class body itself is never a nonlocal scope; it just has access to them. Here's a slightly modified version that includes class definitions:

"When the definition of a function or class is nested (enclosed) within the definitions of other functions, its nonlocal scopes are the local scopes of the enclosing functions. The nonlocal statement causes the listed identifiers to refer to names previously bound in nonlocal scopes. If a name is bound in more than one nonlocal scope, the nearest binding is used. If a name is not bound in any nonlocal scope, or if there is no nonlocal scope, a SyntaxError is raised.

The nonlocal statement applies to the entire scope of a function or class body. A SyntaxError is raised if a variable is used or assigned to prior to its nonlocal declaration in the scope."

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12165>
_______________________________________

From report at bugs.python.org  Fri Feb 25 01:39:03 2022
From: report at bugs.python.org (Stanley)
Date: Fri, 25 Feb 2022 06:39:03 +0000
Subject: [issue21761] [doc] language reference describes the role of
 module.__file__ inaccurately
In-Reply-To: <1402778004.82.0.418404996295.issue21761@psf.upfronthosting.co.za>
Message-ID: <1645771143.04.0.446713033623.issue21761@roundup.psfhosted.org>


Change by Stanley <ostanley.lee at gmail.com>:


----------
keywords: +patch
nosy: +slateny
nosy_count: 6.0 -> 7.0
pull_requests: +29687
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31565

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21761>
_______________________________________

From report at bugs.python.org  Fri Feb 25 02:03:06 2022
From: report at bugs.python.org (Joongi Kim)
Date: Fri, 25 Feb 2022 07:03:06 +0000
Subject: [issue46843] PersistentTaskGroup API
In-Reply-To: <1645680865.21.0.230450894933.issue46843@roundup.psfhosted.org>
Message-ID: <1645772586.38.0.654475017437.issue46843@roundup.psfhosted.org>


Joongi Kim <me at daybreaker.info> added the comment:

Anoter case:

https://github.com/lablup/backend.ai-manager/pull/533
https://github.com/lablup/backend.ai-agent/pull/341

When shutting down the application, I'd like to explicitly cancel the shielded tasks, while keep them shielded before shutdown.

So I inserted `ptaskgroup.create_task()` inside `asyncio.shield()`, so that the tasks are not cancelled upon the cancellation of their callers but they get cancelled when the server shuts down.

This pattern is conveniently implemented with PersistentTaskGroup.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46843>
_______________________________________

From report at bugs.python.org  Fri Feb 25 02:14:36 2022
From: report at bugs.python.org (benrg)
Date: Fri, 25 Feb 2022 07:14:36 +0000
Subject: [issue46848] Use optimized string search function in mmap.find()
In-Reply-To: <1645706630.43.0.574969248824.issue46848@roundup.psfhosted.org>
Message-ID: <1645773276.29.0.449132290476.issue46848@roundup.psfhosted.org>


benrg <benrudiak at gmail.com> added the comment:

memmem isn't a standard C function, and some libraries don't have it, notably Microsoft's.

newlib's memmem seems to be the same as glibc's, but is under a BSD 3-clause license instead of LGPL. An older version of newlib's memmem (prior to 2019-01-01) has the license "Permission to use, copy, modify, and distribute this software is freely granted, provided that this notice is preserved", and is still highly optimized and much better than a naive implementation.

Of course, bundling it would no longer be quite so "free".

Old newlib memmem: https://sourceware.org/git/?p=newlib-cygwin.git;a=blob_plain;f=newlib/libc/string/memmem.c;h=25704e467decff5971b34f4189ddfff04ac5fa8e

New newlib memmem: https://sourceware.org/git/?p=newlib-cygwin.git;a=blob_plain;f=newlib/libc/string/memmem.c

Helper file for both: https://sourceware.org/git/?p=newlib-cygwin.git;a=blob_plain;f=newlib/libc/string/str-two-way.h

----------
nosy: +benrg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46848>
_______________________________________

From report at bugs.python.org  Fri Feb 25 03:25:22 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Feb 2022 08:25:22 +0000
Subject: [issue46820] SyntaxError on `1not in...`
In-Reply-To: <1645465803.96.0.142928933167.issue46820@roundup.psfhosted.org>
Message-ID: <1645777522.65.0.300029947352.issue46820@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29688
pull_request: https://github.com/python/cpython/pull/31566

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46820>
_______________________________________

From report at bugs.python.org  Fri Feb 25 03:25:26 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 25 Feb 2022 08:25:26 +0000
Subject: [issue46820] SyntaxError on `1not in...`
In-Reply-To: <1645465803.96.0.142928933167.issue46820@roundup.psfhosted.org>
Message-ID: <1645777526.66.0.674494611532.issue46820@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 98c3bea4d1c7335135e60946d0ec8cd5031fb6c0 by Serhiy Storchaka in branch 'main':
bpo-46820: Refactor tests for ambiguous end of numerical literal (GH-31494)
https://github.com/python/cpython/commit/98c3bea4d1c7335135e60946d0ec8cd5031fb6c0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46820>
_______________________________________

From report at bugs.python.org  Fri Feb 25 03:26:08 2022
From: report at bugs.python.org (Petr Viktorin)
Date: Fri, 25 Feb 2022 08:26:08 +0000
Subject: [issue46748] Python.h includes stdbool.h
In-Reply-To: <1644830899.62.0.590844926135.issue46748@roundup.psfhosted.org>
Message-ID: <1645777568.3.0.689173853648.issue46748@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:


New changeset 2c228a7b8f89e9ed8d390370abd771d4993b79d8 by Petr Viktorin in branch 'main':
bpo-46748: Don't import <stdbool.h> in public headers (GH-31553)
https://github.com/python/cpython/commit/2c228a7b8f89e9ed8d390370abd771d4993b79d8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46748>
_______________________________________

From report at bugs.python.org  Fri Feb 25 03:50:18 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Feb 2022 08:50:18 +0000
Subject: [issue46820] SyntaxError on `1not in...`
In-Reply-To: <1645465803.96.0.142928933167.issue46820@roundup.psfhosted.org>
Message-ID: <1645779018.31.0.507864264776.issue46820@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c7a0fd2d3fa178c83c269f2b39ebf64a0c5babcd by Miss Islington (bot) in branch '3.10':
bpo-46820: Refactor tests for ambiguous end of numerical literal (GH-31494)
https://github.com/python/cpython/commit/c7a0fd2d3fa178c83c269f2b39ebf64a0c5babcd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46820>
_______________________________________

From report at bugs.python.org  Fri Feb 25 04:09:16 2022
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 25 Feb 2022 09:09:16 +0000
Subject: [issue46389] 3.11: unused generator comprehensions cause
 f_lineno==None
In-Reply-To: <1642249582.51.0.604668369809.issue46389@roundup.psfhosted.org>
Message-ID: <1645780156.83.0.425398755876.issue46389@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

Possibly also related, so I though I'd mention it here (sorry if this is hijacking the ticket, seems difficult to tell). We're also seeing None values in f_lineno in Cython's test suite with 3.11a5:

      File "<doctest line_trace.run_trace[2]>", line 1, in <module>
        run_trace(py_add, 1, 2)
        ^^^^^^^^^^^^^^^^^^^^^^^
      File "tests/run/line_trace.pyx", line 231, in line_trace.run_trace (line_trace.c:7000)
        func(*args)
      File "tests/run/line_trace.pyx", line 60, in line_trace.trace_trampoline (line_trace.c:3460)
        raise
      File "tests/run/line_trace.pyx", line 54, in line_trace.trace_trampoline (line_trace.c:3359)
        result = callback(frame, what, arg)
      File "tests/run/line_trace.pyx", line 81, in line_trace._create_trace_func._trace_func (line_trace.c:3927)
        trace.append((map_trace_types(event, event), frame.f_lineno - frame.f_code.co_firstlineno))
    TypeError: unsupported operand type(s) for -: 'NoneType' and 'int'

https://github.com/cython/cython/blob/7ab11ec473a604792bae454305adece55cd8ab37/tests/run/line_trace.pyx

No generator expressions involved, though. (Much of that test was written while trying to get the debugger in PyCharm to work with Cython compiled modules.)

There is a chance that Cython is doing something wrong in its own line tracing code, obviously.
(I also remember seeing other tracing issues before, where the line reported was actually in the trace function itself rather than the code to be traced. We haven't caught up with the frame-internal changes yet.)

----------
nosy: +scoder

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46389>
_______________________________________

From report at bugs.python.org  Fri Feb 25 06:01:51 2022
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 25 Feb 2022 11:01:51 +0000
Subject: [issue26175] Fully implement IOBase abstract on SpooledTemporaryFile
In-Reply-To: <1453413274.25.0.536987988375.issue26175@psf.upfronthosting.co.za>
Message-ID: <1645786911.52.0.781354660098.issue26175@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> added the comment:

I believe the PR is in good shape.
Can someone with expertise in tempfile review it?

It would also be useful if the people who had a bug could test the new code.

----------
nosy: +eric.araujo, giampaolo.rodola
versions: +Python 3.11 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26175>
_______________________________________

From report at bugs.python.org  Fri Feb 25 06:08:01 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Feb 2022 11:08:01 +0000
Subject: [issue34429] [doc] On Windows tempfile.TemporaryFile behaves like
 NamedTemporaryFile
In-Reply-To: <1534590017.91.0.56676864532.issue34429@psf.upfronthosting.co.za>
Message-ID: <1645787281.13.0.510040077735.issue34429@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: +29689
pull_request: https://github.com/python/cpython/pull/31567

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34429>
_______________________________________

From report at bugs.python.org  Fri Feb 25 06:08:05 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Feb 2022 11:08:05 +0000
Subject: [issue34429] [doc] On Windows tempfile.TemporaryFile behaves like
 NamedTemporaryFile
In-Reply-To: <1534590017.91.0.56676864532.issue34429@psf.upfronthosting.co.za>
Message-ID: <1645787285.15.0.406425555493.issue34429@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29690
pull_request: https://github.com/python/cpython/pull/31568

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34429>
_______________________________________

From report at bugs.python.org  Fri Feb 25 06:08:28 2022
From: report at bugs.python.org (Irit Katriel)
Date: Fri, 25 Feb 2022 11:08:28 +0000
Subject: [issue34429] [doc] On Windows tempfile.TemporaryFile behaves like
 NamedTemporaryFile
In-Reply-To: <1534590017.91.0.56676864532.issue34429@psf.upfronthosting.co.za>
Message-ID: <1645787308.42.0.971507078704.issue34429@roundup.psfhosted.org>


Irit Katriel <iritkatriel at gmail.com> added the comment:


New changeset 53ecf9e08d35801807daf74492c090a325f995b7 by slateny in branch 'main':
bpo-34429: Noted TemporaryFile behavior on non-Posix/non-Cygwin systems (GH-31547)
https://github.com/python/cpython/commit/53ecf9e08d35801807daf74492c090a325f995b7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34429>
_______________________________________

From report at bugs.python.org  Fri Feb 25 06:14:56 2022
From: report at bugs.python.org (Norman Fung)
Date: Fri, 25 Feb 2022 11:14:56 +0000
Subject: [issue46672] NameError in asyncio.gather when passing a invalid type
 as an arg with multiple awaitables
In-Reply-To: <1644211485.82.0.488303396987.issue46672@roundup.psfhosted.org>
Message-ID: <1645787696.39.0.0133639871435.issue46672@roundup.psfhosted.org>


Norman Fung <norman.lm.fung at gmail.com> added the comment:

hi there, on this issue : https://bugs.python.org/issue46672

I encountered this problem on 
a) Python 3.8.5
b) asyncio 3.4.3

This fix https://github.com/python/cpython/commit/f1916cde24053f4c8b6799730666d19474f8dd09 is only available python 3.9 or above?
Thanks

----------
nosy: +norman.lm.fung

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46672>
_______________________________________

From report at bugs.python.org  Fri Feb 25 06:20:12 2022
From: report at bugs.python.org (John Mellor)
Date: Fri, 25 Feb 2022 11:20:12 +0000
Subject: [issue39529] Deprecate get_event_loop()
In-Reply-To: <1580641897.21.0.210075972969.issue39529@roundup.psfhosted.org>
Message-ID: <1645788012.96.0.558309545309.issue39529@roundup.psfhosted.org>


Change by John Mellor <mellor at gmail.com>:


----------
nosy: +johnmellor

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39529>
_______________________________________

From report at bugs.python.org  Fri Feb 25 06:30:18 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 11:30:18 +0000
Subject: [issue46606] Large C stack usage of os.getgroups() and os.setgroups()
In-Reply-To: <1643771204.31.0.0513908090604.issue46606@roundup.psfhosted.org>
Message-ID: <1645788618.07.0.132108578765.issue46606@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29691
pull_request: https://github.com/python/cpython/pull/31569

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46606>
_______________________________________

From report at bugs.python.org  Fri Feb 25 06:30:32 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 25 Feb 2022 11:30:32 +0000
Subject: [issue46756] Incorrect authorization check in urllib.request
In-Reply-To: <1644918487.72.0.244898503691.issue46756@roundup.psfhosted.org>
Message-ID: <1645788632.05.0.887353962885.issue46756@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Yes, it is the same. I should search before writing a patch.

But for some reasons I prefer my solution over the one proposed in issue42766: The code is clearer and more strict, tests use public API instead of a private method.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46756>
_______________________________________

From report at bugs.python.org  Fri Feb 25 06:30:35 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Feb 2022 11:30:35 +0000
Subject: [issue34429] [doc] On Windows tempfile.TemporaryFile behaves like
 NamedTemporaryFile
In-Reply-To: <1534590017.91.0.56676864532.issue34429@psf.upfronthosting.co.za>
Message-ID: <1645788635.21.0.0192425407001.issue34429@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 632a8121d4d577541c3fddffc986bcb8d8d545b6 by Miss Islington (bot) in branch '3.10':
bpo-34429: Noted TemporaryFile behavior on non-Posix/non-Cygwin systems (GH-31547)
https://github.com/python/cpython/commit/632a8121d4d577541c3fddffc986bcb8d8d545b6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34429>
_______________________________________

From report at bugs.python.org  Fri Feb 25 06:31:09 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 25 Feb 2022 11:31:09 +0000
Subject: [issue46756] Incorrect authorization check in urllib.request
In-Reply-To: <1644918487.72.0.244898503691.issue46756@roundup.psfhosted.org>
Message-ID: <1645788669.7.0.226506045466.issue46756@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset e2e72567a1c94c548868f6ee5329363e6036057a by Serhiy Storchaka in branch 'main':
bpo-46756: Fix authorization check in urllib.request (GH-31353)
https://github.com/python/cpython/commit/e2e72567a1c94c548868f6ee5329363e6036057a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46756>
_______________________________________

From report at bugs.python.org  Fri Feb 25 06:31:12 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Feb 2022 11:31:12 +0000
Subject: [issue46756] Incorrect authorization check in urllib.request
In-Reply-To: <1644918487.72.0.244898503691.issue46756@roundup.psfhosted.org>
Message-ID: <1645788672.44.0.756742489846.issue46756@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: +29692
pull_request: https://github.com/python/cpython/pull/31570

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46756>
_______________________________________

From report at bugs.python.org  Fri Feb 25 06:31:15 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Feb 2022 11:31:15 +0000
Subject: [issue46756] Incorrect authorization check in urllib.request
In-Reply-To: <1644918487.72.0.244898503691.issue46756@roundup.psfhosted.org>
Message-ID: <1645788675.18.0.0718545289926.issue46756@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29693
pull_request: https://github.com/python/cpython/pull/31571

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46756>
_______________________________________

From report at bugs.python.org  Fri Feb 25 06:31:19 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Feb 2022 11:31:19 +0000
Subject: [issue46756] Incorrect authorization check in urllib.request
In-Reply-To: <1644918487.72.0.244898503691.issue46756@roundup.psfhosted.org>
Message-ID: <1645788679.64.0.783919804626.issue46756@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29694
pull_request: https://github.com/python/cpython/pull/31572

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46756>
_______________________________________

From report at bugs.python.org  Fri Feb 25 06:31:24 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Feb 2022 11:31:24 +0000
Subject: [issue46756] Incorrect authorization check in urllib.request
In-Reply-To: <1644918487.72.0.244898503691.issue46756@roundup.psfhosted.org>
Message-ID: <1645788684.31.0.856572248036.issue46756@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29695
pull_request: https://github.com/python/cpython/pull/31573

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46756>
_______________________________________

From report at bugs.python.org  Fri Feb 25 06:34:03 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 25 Feb 2022 11:34:03 +0000
Subject: [issue46756] Incorrect authorization check in urllib.request
In-Reply-To: <1644918487.72.0.244898503691.issue46756@roundup.psfhosted.org>
Message-ID: <1645788843.29.0.133014225008.issue46756@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +lukasz.langa, ned.deily, pablogsal
priority: high -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46756>
_______________________________________

From report at bugs.python.org  Fri Feb 25 06:34:18 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 11:34:18 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1645788858.24.0.252749830584.issue1635741@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 4657bf701670215ce69b89401b2307022a3b0a7d by Victor Stinner in branch 'main':
bpo-1635741: Fix winreg reference leaks (GH-31560)
https://github.com/python/cpython/commit/4657bf701670215ce69b89401b2307022a3b0a7d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Fri Feb 25 06:34:19 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Feb 2022 11:34:19 +0000
Subject: [issue34429] [doc] On Windows tempfile.TemporaryFile behaves like
 NamedTemporaryFile
In-Reply-To: <1534590017.91.0.56676864532.issue34429@psf.upfronthosting.co.za>
Message-ID: <1645788859.48.0.390647179096.issue34429@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b7f6e8e13574aaa69d132ea67d7a515bf257a0cb by Miss Islington (bot) in branch '3.9':
bpo-34429: Noted TemporaryFile behavior on non-Posix/non-Cygwin systems (GH-31547)
https://github.com/python/cpython/commit/b7f6e8e13574aaa69d132ea67d7a515bf257a0cb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34429>
_______________________________________

From report at bugs.python.org  Fri Feb 25 06:34:58 2022
From: report at bugs.python.org (Irit Katriel)
Date: Fri, 25 Feb 2022 11:34:58 +0000
Subject: [issue34429] [doc] On Windows tempfile.TemporaryFile behaves like
 NamedTemporaryFile
In-Reply-To: <1534590017.91.0.56676864532.issue34429@psf.upfronthosting.co.za>
Message-ID: <1645788898.91.0.714122941343.issue34429@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34429>
_______________________________________

From report at bugs.python.org  Fri Feb 25 06:53:29 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 11:53:29 +0000
Subject: [issue46836] [C API] Move PyFrameObject to the internal C API
In-Reply-To: <1645628652.12.0.0785803095185.issue46836@roundup.psfhosted.org>
Message-ID: <1645790009.39.0.7140938515.issue46836@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 18b5dd68c6b616257ae243c0b6bb965ffc885a23 by Victor Stinner in branch 'main':
bpo-46836: Move PyFrameObject to pycore_frame.h (GH-31530)
https://github.com/python/cpython/commit/18b5dd68c6b616257ae243c0b6bb965ffc885a23


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46836>
_______________________________________

From report at bugs.python.org  Fri Feb 25 06:54:05 2022
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 25 Feb 2022 11:54:05 +0000
Subject: [issue46567] Add Tcl/Tk builds for ARM64
In-Reply-To: <1643388941.84.0.746346851464.issue46567@roundup.psfhosted.org>
Message-ID: <1645790045.14.0.97851760239.issue46567@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I don't mind waiting a couple of days. We have also at least one release blocker as well, so is not even sure that we will be ready in time :S

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46567>
_______________________________________

From report at bugs.python.org  Fri Feb 25 06:56:23 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Feb 2022 11:56:23 +0000
Subject: [issue46756] Incorrect authorization check in urllib.request
In-Reply-To: <1644918487.72.0.244898503691.issue46756@roundup.psfhosted.org>
Message-ID: <1645790183.16.0.94993068779.issue46756@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 4560c7e605887fda3af63f8ce157abf94954d4d2 by Miss Islington (bot) in branch '3.9':
bpo-46756: Fix authorization check in urllib.request (GH-31353)
https://github.com/python/cpython/commit/4560c7e605887fda3af63f8ce157abf94954d4d2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46756>
_______________________________________

From report at bugs.python.org  Fri Feb 25 06:56:59 2022
From: report at bugs.python.org (Mark Shannon)
Date: Fri, 25 Feb 2022 11:56:59 +0000
Subject: [issue46389] 3.11: unused generator comprehensions cause
 f_lineno==None
In-Reply-To: <1642249582.51.0.604668369809.issue46389@roundup.psfhosted.org>
Message-ID: <1645790219.18.0.781031936942.issue46389@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

Stefan,

f_lineno can be None for some opcodes, but there shouldn't be trace events if it is.

E.g.
>>> def f():
...     try:
...          1/0
...     finally:
...          pass
...

>>> list(f.__code__.co_lines())
[(0, 2, 1), (2, 4, 2), (4, 12, 3), (12, 16, 5), (16, 18, None), (18, 26, 5)]

Note that the bytecode at offset 16 has no line number, but there should be no events for it.


BUT, before you try and fix your tracing emulation, I repeat my plea.

Please stop trying to mimic CPython internals, and ask for the APIs that you need.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46389>
_______________________________________

From report at bugs.python.org  Fri Feb 25 06:57:34 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Feb 2022 11:57:34 +0000
Subject: [issue46756] Incorrect authorization check in urllib.request
In-Reply-To: <1644918487.72.0.244898503691.issue46756@roundup.psfhosted.org>
Message-ID: <1645790254.09.0.848003652515.issue46756@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 2b7e04d61274af03426975fe824ed83eca35b035 by Miss Islington (bot) in branch '3.10':
bpo-46756: Fix authorization check in urllib.request (GH-31353)
https://github.com/python/cpython/commit/2b7e04d61274af03426975fe824ed83eca35b035


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46756>
_______________________________________

From report at bugs.python.org  Fri Feb 25 07:00:31 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 25 Feb 2022 12:00:31 +0000
Subject: [issue42766] urllib.request.HTTPPasswordMgr uses commonprefix instead
 of commonpath
In-Reply-To: <1609170153.96.0.504551551924.issue42766@roundup.psfhosted.org>
Message-ID: <1645790431.03.0.874097068251.issue42766@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Sorry I did not notice this issue. It is now solved in issue46756.

In any case thank you for the report and the PR.

----------
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> Incorrect authorization check in urllib.request

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42766>
_______________________________________

From report at bugs.python.org  Fri Feb 25 07:11:41 2022
From: report at bugs.python.org (Mark Shannon)
Date: Fri, 25 Feb 2022 12:11:41 +0000
Subject: [issue46841] Inline bytecode caches
In-Reply-To: <1645669034.5.0.77775951626.issue46841@roundup.psfhosted.org>
Message-ID: <1645791101.42.0.732772834991.issue46841@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset 0f41aac109c45aa468c432f798947c54d4178b3d by Brandt Bucher in branch 'main':
bpo-46841: Use *inline* caching for `BINARY_OP` (GH-31543)
https://github.com/python/cpython/commit/0f41aac109c45aa468c432f798947c54d4178b3d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46841>
_______________________________________

From report at bugs.python.org  Fri Feb 25 07:13:57 2022
From: report at bugs.python.org (Mark Shannon)
Date: Fri, 25 Feb 2022 12:13:57 +0000
Subject: [issue46841] Inline bytecode caches
In-Reply-To: <1645669034.5.0.77775951626.issue46841@roundup.psfhosted.org>
Message-ID: <1645791237.11.0.785541245796.issue46841@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

Making this a release blocker, as we really cannot leave this half finished for the release.

Shouldn't be a problem, as we'll have it done in a week or so.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46841>
_______________________________________

From report at bugs.python.org  Fri Feb 25 07:14:10 2022
From: report at bugs.python.org (Mark Shannon)
Date: Fri, 25 Feb 2022 12:14:10 +0000
Subject: [issue46841] Inline bytecode caches
In-Reply-To: <1645669034.5.0.77775951626.issue46841@roundup.psfhosted.org>
Message-ID: <1645791250.54.0.179296810412.issue46841@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46841>
_______________________________________

From report at bugs.python.org  Fri Feb 25 07:17:54 2022
From: report at bugs.python.org (Mark Shannon)
Date: Fri, 25 Feb 2022 12:17:54 +0000
Subject: [issue46808] remove NEXT_BLOCK() from compile.c
In-Reply-To: <1645368528.16.0.363497063609.issue46808@roundup.psfhosted.org>
Message-ID: <1645791474.11.0.7965515102.issue46808@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset c579243eb62d3182c84004cd72dcf6ef59100643 by Irit Katriel in branch 'main':
bpo-46808: remove NEXT_BLOCK() from compile.c (GH-31448)
https://github.com/python/cpython/commit/c579243eb62d3182c84004cd72dcf6ef59100643


----------
nosy: +Mark.Shannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46808>
_______________________________________

From report at bugs.python.org  Fri Feb 25 07:18:29 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 12:18:29 +0000
Subject: [issue46836] [C API] Move PyFrameObject to the internal C API
In-Reply-To: <1645628652.12.0.0785803095185.issue46836@roundup.psfhosted.org>
Message-ID: <1645791509.64.0.299191588749.issue46836@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I announced the change on the capi-sig mailing list:
https://mail.python.org/archives/list/capi-sig at python.org/thread/RCT4SB5LY5UPRRRALEOHWEQHIXFNTHYF/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46836>
_______________________________________

From report at bugs.python.org  Fri Feb 25 07:25:33 2022
From: report at bugs.python.org (Aivar Annamaa)
Date: Fri, 25 Feb 2022 12:25:33 +0000
Subject: [issue46666] IDLE Add indent guide
In-Reply-To: <1644184367.6.0.417629376487.issue46666@roundup.psfhosted.org>
Message-ID: <1645791933.48.0.565274220353.issue46666@roundup.psfhosted.org>


Aivar Annamaa <aivar.annamaa at gmail.com> added the comment:

The guides could be implemented by tagging the indentation characters in the Text widget with tags configured with suitable bgstipple (https://www.tcl.tk/man/tcl/TkCmd/text.html#M45) bitmaps.

I had some success with this in Thonny IDE, but abandoned the plan because bstipple is not supported on macOS (for some reason).

----------
nosy: +aivarannamaa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46666>
_______________________________________

From report at bugs.python.org  Fri Feb 25 08:05:45 2022
From: report at bugs.python.org (Steve Dower)
Date: Fri, 25 Feb 2022 13:05:45 +0000
Subject: [issue46567] Add Tcl/Tk builds for ARM64
In-Reply-To: <1643388941.84.0.746346851464.issue46567@roundup.psfhosted.org>
Message-ID: <1645794345.09.0.373968786445.issue46567@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch
pull_requests: +29696
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31574

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46567>
_______________________________________

From report at bugs.python.org  Fri Feb 25 08:09:25 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 25 Feb 2022 13:09:25 +0000
Subject: [issue46820] SyntaxError on `1not in...`
In-Reply-To: <1645465803.96.0.142928933167.issue46820@roundup.psfhosted.org>
Message-ID: <1645794565.8.0.139604201832.issue46820@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46820>
_______________________________________

From report at bugs.python.org  Fri Feb 25 08:32:13 2022
From: report at bugs.python.org (Mark Shannon)
Date: Fri, 25 Feb 2022 13:32:13 +0000
Subject: [issue46841] Inline bytecode caches
In-Reply-To: <1645669034.5.0.77775951626.issue46841@roundup.psfhosted.org>
Message-ID: <1645795933.79.0.433569993669.issue46841@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
pull_requests: +29697
pull_request: https://github.com/python/cpython/pull/31575

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46841>
_______________________________________

From report at bugs.python.org  Fri Feb 25 08:46:47 2022
From: report at bugs.python.org (Steve Dower)
Date: Fri, 25 Feb 2022 13:46:47 +0000
Subject: [issue46567] Add Tcl/Tk builds for ARM64
In-Reply-To: <1643388941.84.0.746346851464.issue46567@roundup.psfhosted.org>
Message-ID: <1645796807.85.0.599777593935.issue46567@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

This is blocked on the IDLE issue in https://github.com/python/cpython/runs/5334087871?check_suite_focus=true

======================================================================
ERROR: test_mousewheel (idlelib.idle_test.test_sidebar.ShellSidebarTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\a\cpython\cpython\Lib\idlelib\idle_test\tkinter_testing_utils.py", line 58, in new_test_method
    raise exception
    ^^^^^^^^^^^^^^^
  File "D:\a\cpython\cpython\Lib\idlelib\idle_test\tkinter_testing_utils.py", line 42, in after_callback
    next(test_generator)
    ^^^^^^^^^^^^^^^^^^^^
  File "D:\a\cpython\cpython\Lib\idlelib\idle_test\test_sidebar.py", line 694, in test_mousewheel
    sidebar.canvas.event_generate('<MouseWheel>', x=0, y=0, delta=delta)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\a\cpython\cpython\Lib\tkinter\__init__.py", line 1886, in event_generate
    self.tk.call(args)
    ^^^^^^^^^^^^^^^^^^
_tkinter.TclError: <MouseWheel> event doesn't accept "-delta" option

I don't have time to look into it right now, but it seems to be reliable on 64-bit builds but works on 32-bit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46567>
_______________________________________

From report at bugs.python.org  Fri Feb 25 09:04:29 2022
From: report at bugs.python.org (=?utf-8?b?6ZKf5pet5bCn?=)
Date: Fri, 25 Feb 2022 14:04:29 +0000
Subject: [issue37426] getpass.getpass not working with on windows when ctrl+v
 is used to enter the string
In-Reply-To: <1561628977.4.0.232389584594.issue37426@roundup.psfhosted.org>
Message-ID: <1645797869.99.0.925598829168.issue37426@roundup.psfhosted.org>


??? <python_zhong at qq.com> added the comment:

I have an idea to solve it. But I don't know how to get the clipboard data.

The code like this (Windows):

def win_getpass(prompt='Password: ', stream=None, echoChar='*'):
    """Prompt for password with echo off, using Windows getwch()."""
    if not isinstance(echoChar, str) or len(echoChar) < 1 or len(echoChar) > 1:
        raise ValueError("Argument 'echoChar' is incorrect. It should be a character.")
    if sys.stdin is not sys.__stdin__:
        return fallback_getpass(prompt, stream)
    for c in prompt:
        msvcrt.putwch(c)
    pw = ""
    while 1:
        c = msvcrt.getwch()
        if ord(c) == 22: # User pressed Ctrl-V
            k = <Clipboard Info>
            pw += k
            for _ in range(len(k)):
                msvcrt.putwch(echoChar)
        if c == '\r' or c == '\n' or c == '\r\n':
            break
        if c == '\003':
            raise KeyboardInterrupt
        if c == '\b':
            if pw != '':
                pw = pw[:-1]
                count = len(pw)
                for _ in range(count+1):
                    msvcrt.putwch('\b')
                for _ in range(count):
                    msvcrt.putwch(echoChar)
                msvcrt.putwch(' ')
                msvcrt.putwch('\b')
        else:
            pw = pw + c
            msvcrt.putwch(echoChar)
            
    msvcrt.putwch('\r')
    msvcrt.putwch('\n')
    return pw

----------
nosy: +W_M
versions:  -Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37426>
_______________________________________

From report at bugs.python.org  Fri Feb 25 09:13:13 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 14:13:13 +0000
Subject: [issue45316] [C API] Functions not exported with PyAPI_FUNC()
In-Reply-To: <1632903484.87.0.875373224779.issue45316@roundup.psfhosted.org>
Message-ID: <1645798393.18.0.0991453765186.issue45316@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +29698
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31576

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45316>
_______________________________________

From report at bugs.python.org  Fri Feb 25 09:16:46 2022
From: report at bugs.python.org (Steve Dower)
Date: Fri, 25 Feb 2022 14:16:46 +0000
Subject: [issue46567] Add Tcl/Tk builds for ARM64
In-Reply-To: <1643388941.84.0.746346851464.issue46567@roundup.psfhosted.org>
Message-ID: <1645798606.7.0.81261581014.issue46567@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Despite the IDLE issue, I made a test release. Again, I don't have time to dig into it before Monday, but if anyone does and would like to help out, here are the installer files (for all platforms):

https://artprodcus3.artifacts.visualstudio.com/Ac0fc90aa-a903-4cf7-8191-b925daa75b5c/8e426817-76c0-4b99-ba9e-a48a1e4bd5db/_apis/artifact/cGlwZWxpbmVhcnRpZmFjdDovL3B5dGhvbi9wcm9qZWN0SWQvOGU0MjY4MTctNzZjMC00Yjk5LWJhOWUtYTQ4YTFlNGJkNWRiL2J1aWxkSWQvOTc1MzEvYXJ0aWZhY3ROYW1lL21zaQ2/content?format=zip

Note that they're signed with a test certificate, so you'll probably get errors about it being invalid. These are fine, and shouldn't affect anything if you skip the warnings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46567>
_______________________________________

From report at bugs.python.org  Fri Feb 25 09:22:12 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 14:22:12 +0000
Subject: [issue45316] [C API] Functions not exported with PyAPI_FUNC()
In-Reply-To: <1632903484.87.0.875373224779.issue45316@roundup.psfhosted.org>
Message-ID: <1645798932.47.0.364008383083.issue45316@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29699
pull_request: https://github.com/python/cpython/pull/31577

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45316>
_______________________________________

From report at bugs.python.org  Fri Feb 25 09:26:29 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 14:26:29 +0000
Subject: [issue46852] Remove the float.__setformat__() method
In-Reply-To: <1645747677.37.0.919337626983.issue46852@roundup.psfhosted.org>
Message-ID: <1645799189.62.0.0458147796571.issue46852@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29700
pull_request: https://github.com/python/cpython/pull/31578

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46852>
_______________________________________

From report at bugs.python.org  Fri Feb 25 09:26:29 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 14:26:29 +0000
Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13
 files
In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za>
Message-ID: <1645799189.77.0.981592763273.issue20185@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29701
pull_request: https://github.com/python/cpython/pull/31578

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20185>
_______________________________________

From report at bugs.python.org  Fri Feb 25 09:41:40 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 14:41:40 +0000
Subject: [issue45316] [C API] Functions not exported with PyAPI_FUNC()
In-Reply-To: <1632903484.87.0.875373224779.issue45316@roundup.psfhosted.org>
Message-ID: <1645800100.92.0.103722297805.issue45316@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 4a0c7a1aacd08cead7717479620e62359c828e88 by Victor Stinner in branch 'main':
bpo-45316: Move private PyCode C API to internal C API (GH-31576)
https://github.com/python/cpython/commit/4a0c7a1aacd08cead7717479620e62359c828e88


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45316>
_______________________________________

From report at bugs.python.org  Fri Feb 25 09:41:59 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 14:41:59 +0000
Subject: [issue45316] [C API] Functions not exported with PyAPI_FUNC()
In-Reply-To: <1632903484.87.0.875373224779.issue45316@roundup.psfhosted.org>
Message-ID: <1645800119.48.0.0286534013629.issue45316@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 8ddbdd9e96e64b42c87dcfe4e38383cf0694988a by Victor Stinner in branch 'main':
bpo-45316: Move private PyDict functions to internal C API (GH-31577)
https://github.com/python/cpython/commit/8ddbdd9e96e64b42c87dcfe4e38383cf0694988a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45316>
_______________________________________

From report at bugs.python.org  Fri Feb 25 09:43:25 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 14:43:25 +0000
Subject: [issue45316] [C API] Functions not exported with PyAPI_FUNC()
In-Reply-To: <1632903484.87.0.875373224779.issue45316@roundup.psfhosted.org>
Message-ID: <1645800205.78.0.574548472653.issue45316@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29702
pull_request: https://github.com/python/cpython/pull/31579

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45316>
_______________________________________

From report at bugs.python.org  Fri Feb 25 09:47:15 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 14:47:15 +0000
Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13
 files
In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za>
Message-ID: <1645800435.08.0.497221364002.issue20185@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 0848da19ce8ea037ab1cfc569778e94bf8e3b24a by Victor Stinner in branch '3.10':
bpo-46852: Rename float.__set_format__() to float.__setformat__() (GH-31558) (GH-31578)
https://github.com/python/cpython/commit/0848da19ce8ea037ab1cfc569778e94bf8e3b24a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20185>
_______________________________________

From report at bugs.python.org  Fri Feb 25 09:47:14 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 14:47:14 +0000
Subject: [issue46852] Remove the float.__setformat__() method
In-Reply-To: <1645747677.37.0.919337626983.issue46852@roundup.psfhosted.org>
Message-ID: <1645800434.99.0.449536851913.issue46852@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 0848da19ce8ea037ab1cfc569778e94bf8e3b24a by Victor Stinner in branch '3.10':
bpo-46852: Rename float.__set_format__() to float.__setformat__() (GH-31558) (GH-31578)
https://github.com/python/cpython/commit/0848da19ce8ea037ab1cfc569778e94bf8e3b24a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46852>
_______________________________________

From report at bugs.python.org  Fri Feb 25 09:49:45 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 14:49:45 +0000
Subject: [issue45316] [C API] Functions not exported with PyAPI_FUNC()
In-Reply-To: <1632903484.87.0.875373224779.issue45316@roundup.psfhosted.org>
Message-ID: <1645800585.72.0.223896240788.issue45316@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29703
pull_request: https://github.com/python/cpython/pull/31580

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45316>
_______________________________________

From report at bugs.python.org  Fri Feb 25 09:51:09 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 14:51:09 +0000
Subject: [issue46852] Remove the float.__setformat__() method
In-Reply-To: <1645747677.37.0.919337626983.issue46852@roundup.psfhosted.org>
Message-ID: <1645800669.46.0.440880739219.issue46852@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29704
pull_request: https://github.com/python/cpython/pull/31581

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46852>
_______________________________________

From report at bugs.python.org  Fri Feb 25 09:51:09 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 14:51:09 +0000
Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13
 files
In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za>
Message-ID: <1645800669.55.0.306366563826.issue20185@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29705
pull_request: https://github.com/python/cpython/pull/31581

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20185>
_______________________________________

From report at bugs.python.org  Fri Feb 25 09:57:06 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 14:57:06 +0000
Subject: [issue46836] [C API] Move PyFrameObject to the internal C API
In-Reply-To: <1645628652.12.0.0785803095185.issue46836@roundup.psfhosted.org>
Message-ID: <1645801026.76.0.806755618634.issue46836@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29706
pull_request: https://github.com/python/cpython/pull/31583

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46836>
_______________________________________

From report at bugs.python.org  Fri Feb 25 10:00:16 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 15:00:16 +0000
Subject: [issue46356] [C API] Enforce usage of PyFrame_GetBack()
In-Reply-To: <1642001581.89.0.653777729997.issue46356@roundup.psfhosted.org>
Message-ID: <1645801216.69.0.284828162523.issue46356@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

This issue has been fixed by bpo-46836:

New changeset 18b5dd68c6b616257ae243c0b6bb965ffc885a23 by Victor Stinner in branch 'main':
bpo-46836: Move PyFrameObject to pycore_frame.h (GH-31530)

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46356>
_______________________________________

From report at bugs.python.org  Fri Feb 25 10:04:59 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 15:04:59 +0000
Subject: [issue45431] [C API] Rename CFrame or hide it to only export names
 starting with Py
In-Reply-To: <1633945803.57.0.940910379519.issue45431@roundup.psfhosted.org>
Message-ID: <1645801499.68.0.420240190808.issue45431@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +29707
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31584

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45431>
_______________________________________

From report at bugs.python.org  Fri Feb 25 10:06:29 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 15:06:29 +0000
Subject: [issue45431] [C API] Rename CFrame or hide it to only export names
 starting with Py
In-Reply-To: <1633945803.57.0.940910379519.issue45431@roundup.psfhosted.org>
Message-ID: <1645801589.34.0.897054697528.issue45431@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> We should either make the whole PyThreadState structure private (move it to the internal C API), or rename CFrame (to PyCFrame?).

Well, moving PyThreadState to the internal C API is complicate. I prefer to start by renaming CFrame to PyCFrame: see GH-31584.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45431>
_______________________________________

From report at bugs.python.org  Fri Feb 25 10:07:18 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 15:07:18 +0000
Subject: [issue45316] [C API] Functions not exported with PyAPI_FUNC()
In-Reply-To: <1632903484.87.0.875373224779.issue45316@roundup.psfhosted.org>
Message-ID: <1645801638.33.0.896048437963.issue45316@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 8f2a337a80a283c66e1a4252839792fa229d2763 by Victor Stinner in branch 'main':
bpo-45316: Move private functions to internal C API (GH-31579)
https://github.com/python/cpython/commit/8f2a337a80a283c66e1a4252839792fa229d2763


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45316>
_______________________________________

From report at bugs.python.org  Fri Feb 25 10:09:43 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 15:09:43 +0000
Subject: [issue46640] Python can now use the C99 NAN constant or
 __builtin_nan()
In-Reply-To: <1644006249.4.0.292742084923.issue46640@roundup.psfhosted.org>
Message-ID: <1645801783.95.0.32648435622.issue46640@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

PEP 7 has been updated, I close the issue.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46640>
_______________________________________

From report at bugs.python.org  Fri Feb 25 10:11:33 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 15:11:33 +0000
Subject: [issue46663] test_math test_cmath test_complex fails on Fedora
 Rawhide buildbots
In-Reply-To: <1644179485.62.0.212038403809.issue46663@roundup.psfhosted.org>
Message-ID: <1645801893.06.0.363231234911.issue46663@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Rawhide buildbots are back to green: GCC has been fixed, I close the issue.

Moreover, Python 3.11 now uses NAN constant or __builtin_nan("").

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46663>
_______________________________________

From report at bugs.python.org  Fri Feb 25 10:12:29 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 15:12:29 +0000
Subject: [issue46432] AMD64 FreeBSD Shared 3.x buildbot fails to build: error:
 error reading 'LASTCFLAGS'
In-Reply-To: <1642606471.52.0.164766781716.issue46432@roundup.psfhosted.org>
Message-ID: <1645801949.73.0.388268669067.issue46432@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

AMD64 FreeBSD Shared 3.x is back to green, I close the issue.

> Please leave this issue open

Sorry but I prefer to use the Python bug tracker for things which must change in Python.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46432>
_______________________________________

From report at bugs.python.org  Fri Feb 25 10:13:53 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 15:13:53 +0000
Subject: [issue46852] Remove the float.__setformat__() method
In-Reply-To: <1645747677.37.0.919337626983.issue46852@roundup.psfhosted.org>
Message-ID: <1645802033.83.0.374296178841.issue46852@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset a549cd1fc55888e2e287714b25e2cb2251913909 by Victor Stinner in branch '3.9':
bpo-46852: Rename float.__set_format__() to float.__setformat__() (GH-31558) (GH-31581)
https://github.com/python/cpython/commit/a549cd1fc55888e2e287714b25e2cb2251913909


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46852>
_______________________________________

From report at bugs.python.org  Fri Feb 25 10:13:53 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 15:13:53 +0000
Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13
 files
In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za>
Message-ID: <1645802033.93.0.84520520645.issue20185@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset a549cd1fc55888e2e287714b25e2cb2251913909 by Victor Stinner in branch '3.9':
bpo-46852: Rename float.__set_format__() to float.__setformat__() (GH-31558) (GH-31581)
https://github.com/python/cpython/commit/a549cd1fc55888e2e287714b25e2cb2251913909


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20185>
_______________________________________

From report at bugs.python.org  Fri Feb 25 10:18:24 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 15:18:24 +0000
Subject: [issue46852] Remove the float.__setformat__() method
In-Reply-To: <1645747677.37.0.919337626983.issue46852@roundup.psfhosted.org>
Message-ID: <1645802304.76.0.215176014484.issue46852@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29708
pull_request: https://github.com/python/cpython/pull/31585

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46852>
_______________________________________

From report at bugs.python.org  Fri Feb 25 10:19:34 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 15:19:34 +0000
Subject: [issue45316] [C API] Functions not exported with PyAPI_FUNC()
In-Reply-To: <1632903484.87.0.875373224779.issue45316@roundup.psfhosted.org>
Message-ID: <1645802374.57.0.580299629235.issue45316@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset f780d9690f1a009a56ac0c653ec9608e6b2aeff4 by Victor Stinner in branch 'main':
bpo-45316: Move _PyArg_Fini() to internal C API (GH-31580)
https://github.com/python/cpython/commit/f780d9690f1a009a56ac0c653ec9608e6b2aeff4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45316>
_______________________________________

From report at bugs.python.org  Fri Feb 25 10:21:28 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 15:21:28 +0000
Subject: [issue45316] [C API] Functions not exported with PyAPI_FUNC()
In-Reply-To: <1632903484.87.0.875373224779.issue45316@roundup.psfhosted.org>
Message-ID: <1645802488.45.0.450675220801.issue45316@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Update: only two remaining functions are not exported by the public C API:

int PySignal_SetWakeupFd(int fd);
int _Py_CheckPython3(void);

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45316>
_______________________________________

From report at bugs.python.org  Fri Feb 25 10:22:05 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 15:22:05 +0000
Subject: [issue46836] [C API] Move PyFrameObject to the internal C API
In-Reply-To: <1645628652.12.0.0785803095185.issue46836@roundup.psfhosted.org>
Message-ID: <1645802525.03.0.771812850544.issue46836@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 87af12bff33b3e7546fa26158b7d8680ecb6ecec by Victor Stinner in branch 'main':
bpo-46836: Rename InterpreterFrame to _PyInterpreterFrame (GH-31583)
https://github.com/python/cpython/commit/87af12bff33b3e7546fa26158b7d8680ecb6ecec


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46836>
_______________________________________

From report at bugs.python.org  Fri Feb 25 10:33:21 2022
From: report at bugs.python.org (Yves Duprat)
Date: Fri, 25 Feb 2022 15:33:21 +0000
Subject: [issue46752] Introduce task groups to asyncio and change task
 cancellation semantics
In-Reply-To: <1644871469.64.0.38816696304.issue46752@roundup.psfhosted.org>
Message-ID: <1645803201.08.0.916291617313.issue46752@roundup.psfhosted.org>


Change by Yves Duprat <yduprat at gmail.com>:


----------
nosy: +yduprat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46752>
_______________________________________

From report at bugs.python.org  Fri Feb 25 10:34:45 2022
From: report at bugs.python.org (Erlend E. Aasland)
Date: Fri, 25 Feb 2022 15:34:45 +0000
Subject: [issue43853] [sqlite3] Improve sqlite3_value_text() error handling
In-Reply-To: <1618480809.83.0.17163581819.issue43853@roundup.psfhosted.org>
Message-ID: <1645803285.94.0.712639830871.issue43853@roundup.psfhosted.org>


Change by Erlend E. Aasland <erlend.aasland at innova.no>:


----------
pull_requests: +29709
pull_request: https://github.com/python/cpython/pull/31586

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43853>
_______________________________________

From report at bugs.python.org  Fri Feb 25 10:49:37 2022
From: report at bugs.python.org (svilen dobrev)
Date: Fri, 25 Feb 2022 15:49:37 +0000
Subject: [issue46855] printing a string with strange characters loops forever
Message-ID: <1645804177.22.0.124909459168.issue46855@roundup.psfhosted.org>


New submission from svilen dobrev <az at svilendobrev.com>:

$ python
Python 3.10.2 (main, Jan 15 2022, 19:56:27) [GCC 11.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> a= "Betrag gr\xc3\xb6\xc3\x9fer als Betrag der Original-Transaktion"
>>> a
'Betrag gr???\x9fer als Betrag der Original-Transaktion'
>>> print(a)
Betrag gr???~ 

---------------

And above waits forever. Does not consume resources, but does not hear Ctrl-C. Ctrl-\ kills it.

The string above is just a byte string of the utf-8 representation, with forgotten "b" infront of it.

----------
components: Interpreter Core
messages: 414010
nosy: svild
priority: normal
severity: normal
status: open
title: printing a string with strange characters loops forever
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46855>
_______________________________________

From report at bugs.python.org  Fri Feb 25 10:58:46 2022
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 25 Feb 2022 15:58:46 +0000
Subject: [issue46852] Remove the float.__setformat__() method
In-Reply-To: <1645747677.37.0.919337626983.issue46852@roundup.psfhosted.org>
Message-ID: <1645804726.32.0.443904185901.issue46852@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'd be happy to see `float.__setformat__` go, if it's not still needed for Python's test suite (which was its entire raison d'?tre). If no-one noticed the accidental misnaming, then it's pretty clear no-one's been using it.

I'd like to bet that there are at least a few people out there using float.__getformat__, despite that its docstring says "You probably don't want to use this function".

Maybe we could consider moving the information contained in __getformat__ to somewhere more accessible (e.g., a new field in sys.float_info)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46852>
_______________________________________

From report at bugs.python.org  Fri Feb 25 11:02:26 2022
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 25 Feb 2022 16:02:26 +0000
Subject: [issue37426] getpass.getpass not working with on windows when ctrl+v
 is used to enter the string
In-Reply-To: <1561628977.4.0.232389584594.issue37426@roundup.psfhosted.org>
Message-ID: <1645804946.82.0.836685190991.issue37426@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> Clicking `Edit > Paste` from the window menu
> Use right-click to paste

In particular, if the console has quick-edit mode enabled, then you can paste text by right-clicking. Also, if text is selected in quick-edit mode, right-clicking copies to the clipboard.

> Enabling `Properties > Options > Use Ctrl+Shift+C/V as Copy/Paste` from the menu

I prefer this setting because it matches the behavior of terminals on other platforms. I suggest setting it in the "Defaults" dialog instead of "Properties". Otherwise, you'll have to configure it individually for each shell link (.LNK file) or session title. (The console session title defaults to the executable path, unless set in STARTUPINFO.)

> Using the new Windows Terminal

Terminal allows configuring the actions for keyboard shortcuts. By default it grabs Ctrl+C (copy) and Ctrl+V (paste). I disable these mappings. I leave the default mappings in place for Ctrl+Shift+C (copy), Ctrl+Shift+V (paste), Ctrl+Insert (copy), and Shift+Insert (paste).  

> This behavior is the same Command Prompt and PowerShell

The behavior has to be the same when the parent process is a normal console shell such as CMD or PowerShell. Python inherits its console session from the shell, and that's the extent of the shell's involvement. 

A console session is hosted by an instance of conhost.exe or openconsole.exe. If the host is running in pseudoconsole (headless) mode, then the user interface for the session is hosted by another application (e.g. Windows Terminal). Even in pseudoconsole mode, however, the console host a lot to do in order to manage the session state for the console API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37426>
_______________________________________

From report at bugs.python.org  Fri Feb 25 11:10:01 2022
From: report at bugs.python.org (Joris Geysens)
Date: Fri, 25 Feb 2022 16:10:01 +0000
Subject: [issue46856] datetime.max conversion
Message-ID: <1645805401.57.0.267496020204.issue46856@roundup.psfhosted.org>


New submission from Joris Geysens <joris.geysens at enervalis.com>:

Reading the documentation, I don't understand how this is not possible : 

# get the max utc timestamp
ts = datetime.max.replace(tzinfo=timezone.utc).timestamp()

# similarly 
ts2 = datetime(9999, 12, 31, 23, 59, 59, 999999, tzinfo=timezone.utc).timestamp()

# timestamp value 253402300800 seems correct
# converting back to timestamp is impossible, these all fail : 

dt = datetime.fromtimestamp(ts, tz=timezone.utc)
dt = datetime.utcfromtimestamp(ts)

It should be possible to get a datetime back from the initially converted timestamp, no?

----------
messages: 414013
nosy: joris.geysens
priority: normal
severity: normal
status: open
title: datetime.max conversion
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46856>
_______________________________________

From report at bugs.python.org  Fri Feb 25 11:34:17 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 25 Feb 2022 16:34:17 +0000
Subject: [issue46843] PersistentTaskGroup API
In-Reply-To: <1645680865.21.0.230450894933.issue46843@roundup.psfhosted.org>
Message-ID: <1645806857.6.0.699327105242.issue46843@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

The implementation of asyncio.TaskGroup isn't all that complicated (and the new "cancel count" API helps). I recommend that you build one that satisfies your requirements yourself, or convince the authors of some other package like Quattro or aiotools to provide variations.

----------
nosy: +tinchester

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46843>
_______________________________________

From report at bugs.python.org  Fri Feb 25 11:34:53 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 25 Feb 2022 16:34:53 +0000
Subject: [issue46843] PersistentTaskGroup API
In-Reply-To: <1645680865.21.0.230450894933.issue46843@roundup.psfhosted.org>
Message-ID: <1645806893.76.0.336549807807.issue46843@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

(FWIW I would close this issue but I'll wait to see if @asvetlov has something to add.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46843>
_______________________________________

From report at bugs.python.org  Fri Feb 25 11:39:13 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 25 Feb 2022 16:39:13 +0000
Subject: [issue46844] Implicit binding of PersistentTaskGroup (or virtual
 event loops)
In-Reply-To: <1645681556.47.0.510927748304.issue46844@roundup.psfhosted.org>
Message-ID: <1645807153.37.0.662581283152.issue46844@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Let's concentrate the discussion in the other issue.

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46844>
_______________________________________

From report at bugs.python.org  Fri Feb 25 11:41:28 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Feb 2022 16:41:28 +0000
Subject: [issue26897] [doc] Clarify Popen stdin, stdout, stderr
In-Reply-To: <1462077137.11.0.0338937138998.issue26897@psf.upfronthosting.co.za>
Message-ID: <1645807288.12.0.0718547870893.issue26897@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: +29710
pull_request: https://github.com/python/cpython/pull/31587

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26897>
_______________________________________

From report at bugs.python.org  Fri Feb 25 11:41:29 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Fri, 25 Feb 2022 16:41:29 +0000
Subject: [issue26897] [doc] Clarify Popen stdin, stdout, stderr
In-Reply-To: <1462077137.11.0.0338937138998.issue26897@psf.upfronthosting.co.za>
Message-ID: <1645807289.89.0.44798606849.issue26897@roundup.psfhosted.org>


Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:


New changeset dd69f734218ac5d3a551227069ac53ee09b0cd3e by Kumar Aditya in branch 'main':
bpo-26897: Clarify Popen stdin, stdout, stderr file object docs (GH-30231)
https://github.com/python/cpython/commit/dd69f734218ac5d3a551227069ac53ee09b0cd3e


----------
nosy: +Jelle Zijlstra

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26897>
_______________________________________

From report at bugs.python.org  Fri Feb 25 11:43:01 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Fri, 25 Feb 2022 16:43:01 +0000
Subject: [issue26897] [doc] Clarify Popen stdin, stdout, stderr
In-Reply-To: <1462077137.11.0.0338937138998.issue26897@psf.upfronthosting.co.za>
Message-ID: <1645807381.87.0.626377604373.issue26897@roundup.psfhosted.org>


Change by Jelle Zijlstra <jelle.zijlstra at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26897>
_______________________________________

From report at bugs.python.org  Fri Feb 25 11:41:32 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Feb 2022 16:41:32 +0000
Subject: [issue26897] [doc] Clarify Popen stdin, stdout, stderr
In-Reply-To: <1462077137.11.0.0338937138998.issue26897@psf.upfronthosting.co.za>
Message-ID: <1645807292.87.0.551766240153.issue26897@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +29711
pull_request: https://github.com/python/cpython/pull/31588

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26897>
_______________________________________

From report at bugs.python.org  Fri Feb 25 11:49:11 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 16:49:11 +0000
Subject: [issue46852] Remove the float.__setformat__() method
In-Reply-To: <1645747677.37.0.919337626983.issue46852@roundup.psfhosted.org>
Message-ID: <1645807751.55.0.511052072916.issue46852@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Mark Dickinson:
> I'd be happy to see `float.__setformat__` go, if it's not still needed for Python's test suite (which was its entire raison d'?tre). If no-one noticed the accidental misnaming, then it's pretty clear no-one's been using it.

Nobody noticed the since Python 3.7 (released in June 2018). Well, even test_float didn't use it :-D (I just fixed the typo yesterday.) So I expect that no one uses it.

> I'd like to bet that there are at least a few people out there using float.__getformat__, despite that its docstring says "You probably don't want to use this function".

Yeah, I changed my mind and I prefer to leave it unchanged for now. It doesn't prevent me to optimize _PyFloat_Pack8().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46852>
_______________________________________

From report at bugs.python.org  Fri Feb 25 11:49:14 2022
From: report at bugs.python.org (Eric Snow)
Date: Fri, 25 Feb 2022 16:49:14 +0000
Subject: [issue45316] [C API] Functions not exported with PyAPI_FUNC()
In-Reply-To: <1632903484.87.0.875373224779.issue45316@roundup.psfhosted.org>
Message-ID: <1645807754.77.0.316738872188.issue45316@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Thanks for working on this, Victor.

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45316>
_______________________________________

From report at bugs.python.org  Fri Feb 25 11:57:11 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 16:57:11 +0000
Subject: [issue46857] Python leaks one reference at exit on Windows
Message-ID: <1645808231.81.0.426207041717.issue46857@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

"./python -X showrefcount -I -c pass" returns "[0 refs, 0 blocks]" as expected on Linux: Python doesn't leak any reference nor memory block.

But on Windows, it still leaks 1 reference (and 1 memory block)!

vstinner at DESKTOP-DK7VBIL C:\vstinner\python\main>python -X showrefcount -I -c pass
[1 refs, 1 blocks]

I recently added a test in test_embed which now fails on Windows.

See bpo-1635741 "Py_Finalize() doesn't clear all Python objects at exit" for the context.

----------
components: Interpreter Core
messages: 414020
nosy: vstinner
priority: normal
severity: normal
status: open
title: Python leaks one reference at exit on Windows
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46857>
_______________________________________

From report at bugs.python.org  Fri Feb 25 12:02:49 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 17:02:49 +0000
Subject: [issue46857] Python leaks one reference at exit on Windows
In-Reply-To: <1645808231.81.0.426207041717.issue46857@roundup.psfhosted.org>
Message-ID: <1645808569.38.0.450992303672.issue46857@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +29712
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31589

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46857>
_______________________________________

From report at bugs.python.org  Fri Feb 25 12:03:46 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Feb 2022 17:03:46 +0000
Subject: [issue26897] [doc] Clarify Popen stdin, stdout, stderr
In-Reply-To: <1462077137.11.0.0338937138998.issue26897@psf.upfronthosting.co.za>
Message-ID: <1645808626.49.0.516990724114.issue26897@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1f956d11dbd952fed9b214a0c6e5fd9f91a1f4ca by Miss Islington (bot) in branch '3.10':
bpo-26897: Clarify Popen stdin, stdout, stderr file object docs (GH-30231)
https://github.com/python/cpython/commit/1f956d11dbd952fed9b214a0c6e5fd9f91a1f4ca


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26897>
_______________________________________

From report at bugs.python.org  Fri Feb 25 12:07:16 2022
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Feb 2022 17:07:16 +0000
Subject: [issue26897] [doc] Clarify Popen stdin, stdout, stderr
In-Reply-To: <1462077137.11.0.0338937138998.issue26897@psf.upfronthosting.co.za>
Message-ID: <1645808836.66.0.392132260053.issue26897@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset de2c91a89aa0e89d5d01d71697d0f27a9f60c11d by Miss Islington (bot) in branch '3.9':
bpo-26897: Clarify Popen stdin, stdout, stderr file object docs (GH-30231)
https://github.com/python/cpython/commit/de2c91a89aa0e89d5d01d71697d0f27a9f60c11d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26897>
_______________________________________

From report at bugs.python.org  Fri Feb 25 12:17:22 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 25 Feb 2022 17:17:22 +0000
Subject: [issue46856] datetime.max conversion
In-Reply-To: <1645805401.57.0.267496020204.issue46856@roundup.psfhosted.org>
Message-ID: <1645809442.1.0.0956295908866.issue46856@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Please show us how they fail.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46856>
_______________________________________

From report at bugs.python.org  Fri Feb 25 12:19:21 2022
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 25 Feb 2022 17:19:21 +0000
Subject: [issue37426] getpass.getpass not working with on windows when ctrl+v
 is used to enter the string
In-Reply-To: <1561628977.4.0.232389584594.issue37426@roundup.psfhosted.org>
Message-ID: <1645809561.05.0.938331503575.issue37426@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> I have an idea to solve it. But I don't know how to get the 
> clipboard data.

In Windows, using the window manager entails extending the process and the current thread with GUI-related structures in the kernel and then connecting the process to a window station (usually "WinSta0", which contains the clipboard) and connecting the thread to a desktop (usually "Default"). This permanently changes how the OS sees the process. I think whether or not the process should be a GUI process is something for the application to decide, not the standard library. Thus getpass should not read text from the clipboard.

The docs could note that terminals may need to be configured to support Ctrl+Shift+C (copy) and Ctrl+Shift+V (paste) shortcuts, and that some terminals provide alternate ways to paste text, such as a right-click action or context menu. I don't think the docs should provide detailed explanations and configuration details for particular terminals.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37426>
_______________________________________

From report at bugs.python.org  Fri Feb 25 12:24:41 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 17:24:41 +0000
Subject: [issue46857] Python leaks one reference at exit on Windows
In-Reply-To: <1645808231.81.0.426207041717.issue46857@roundup.psfhosted.org>
Message-ID: <1645809881.15.0.392017982197.issue46857@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset ea9612a17bc60d44e0058f525d3c02a91c439cef by Victor Stinner in branch 'main':
bpo-46857: Fix test_embed.test_no_memleak() on Windows (GH-31589)
https://github.com/python/cpython/commit/ea9612a17bc60d44e0058f525d3c02a91c439cef


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46857>
_______________________________________

From report at bugs.python.org  Fri Feb 25 12:46:29 2022
From: report at bugs.python.org (=?utf-8?q?Tin_Tvrtkovi=C4=87?=)
Date: Fri, 25 Feb 2022 17:46:29 +0000
Subject: [issue46843] PersistentTaskGroup API
In-Reply-To: <1645680865.21.0.230450894933.issue46843@roundup.psfhosted.org>
Message-ID: <1645811189.64.0.330252225741.issue46843@roundup.psfhosted.org>


Tin Tvrtkovi? <tinchester at gmail.com> added the comment:

The asyncio TaskGroup already uses a WeakSet for its children, so it's suitable for long-lived use.

As for errors in siblings aborting the TaskGroup, could you apply a wrapper to the scheduled coroutines to swallow and log any errors yourself?

Apart from the timeouts, that should get you a long way towards what you're describing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46843>
_______________________________________

From report at bugs.python.org  Fri Feb 25 12:49:59 2022
From: report at bugs.python.org (Ned Deily)
Date: Fri, 25 Feb 2022 17:49:59 +0000
Subject: [issue46756] Incorrect authorization check in urllib.request
In-Reply-To: <1644918487.72.0.244898503691.issue46756@roundup.psfhosted.org>
Message-ID: <1645811399.13.0.384229860823.issue46756@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 31fef7edf951fb759004c58ae64df18bc32ea376 by Miss Islington (bot) in branch '3.7':
bpo-46756: Fix authorization check in urllib.request (GH-31353) (GH-31573)
https://github.com/python/cpython/commit/31fef7edf951fb759004c58ae64df18bc32ea376


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46756>
_______________________________________

From report at bugs.python.org  Fri Feb 25 13:05:39 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 25 Feb 2022 18:05:39 +0000
Subject: [issue46712] Share global string identifiers in deepfreeze
In-Reply-To: <1644502683.1.0.673362326219.issue46712@roundup.psfhosted.org>
Message-ID: <1645812339.61.0.730896186272.issue46712@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset eb002dbe0da9622245a355db5f0cd5aa2fc70b40 by Kumar Aditya in branch 'main':
bpo-46712: Share global string identifiers in deepfreeze (GH-31261)
https://github.com/python/cpython/commit/eb002dbe0da9622245a355db5f0cd5aa2fc70b40


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46712>
_______________________________________

From report at bugs.python.org  Fri Feb 25 13:08:29 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 25 Feb 2022 18:08:29 +0000
Subject: [issue46712] Share global string identifiers in deepfreeze
In-Reply-To: <1644502683.1.0.673362326219.issue46712@roundup.psfhosted.org>
Message-ID: <1645812509.45.0.332479810934.issue46712@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> resource usage

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46712>
_______________________________________

From report at bugs.python.org  Fri Feb 25 13:14:14 2022
From: report at bugs.python.org (Joongi Kim)
Date: Fri, 25 Feb 2022 18:14:14 +0000
Subject: [issue46843] PersistentTaskGroup API
In-Reply-To: <1645680865.21.0.230450894933.issue46843@roundup.psfhosted.org>
Message-ID: <1645812854.59.0.855130255267.issue46843@roundup.psfhosted.org>


Joongi Kim <me at daybreaker.info> added the comment:

Good to hear that TaskGroup already uses WeakSet.

When all tasks finish, PersistentTaskGroup should not finish and wait for future tasks, unless explicitly cancelled or shutdown.  Could this be also configured with asyncio.TaskGroup?

I'm also ok with adding a simple option for such behavior to asyncio.TaskGroup instead of adding a whole new API/class.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46843>
_______________________________________

From report at bugs.python.org  Fri Feb 25 13:28:25 2022
From: report at bugs.python.org (Joongi Kim)
Date: Fri, 25 Feb 2022 18:28:25 +0000
Subject: [issue46843] PersistentTaskGroup API
In-Reply-To: <1645680865.21.0.230450894933.issue46843@roundup.psfhosted.org>
Message-ID: <1645813705.22.0.669095692808.issue46843@roundup.psfhosted.org>


Joongi Kim <me at daybreaker.info> added the comment:

> As for errors in siblings aborting the TaskGroup, could you apply a wrapper to the scheduled coroutines to swallow and log any errors yourself?

Yes, this could be a simplest way to implement PersistentTaskGroup if TaskGroup supports "persistent" option to keep it running.

And just a question: I'm just curious about what happens if belonging tasks see the cancellation raised from their inner tasks.  Sibling tasks should not be cancelled, and the outer task group should not be cancelled, unless the task group itself has requested cancellation.  Could the new cancellation counter help this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46843>
_______________________________________

From report at bugs.python.org  Fri Feb 25 13:34:15 2022
From: report at bugs.python.org (Brandt Bucher)
Date: Fri, 25 Feb 2022 18:34:15 +0000
Subject: [issue45431] [C API] Rename CFrame or hide it to only export names
 starting with Py
In-Reply-To: <1633945803.57.0.940910379519.issue45431@roundup.psfhosted.org>
Message-ID: <1645814055.15.0.0899185590044.issue45431@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
nosy: +brandtbucher

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45431>
_______________________________________

From report at bugs.python.org  Fri Feb 25 13:34:34 2022
From: report at bugs.python.org (Brandt Bucher)
Date: Fri, 25 Feb 2022 18:34:34 +0000
Subject: [issue46808] remove NEXT_BLOCK() from compile.c
In-Reply-To: <1645368528.16.0.363497063609.issue46808@roundup.psfhosted.org>
Message-ID: <1645814074.1.0.412163445012.issue46808@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
nosy: +brandtbucher

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46808>
_______________________________________

From report at bugs.python.org  Fri Feb 25 13:35:25 2022
From: report at bugs.python.org (Brandt Bucher)
Date: Fri, 25 Feb 2022 18:35:25 +0000
Subject: [issue46850] [C API] Move _PyEval_EvalFrameDefault() to the internal
 C API
In-Reply-To: <1645716984.87.0.22272006941.issue46850@roundup.psfhosted.org>
Message-ID: <1645814125.21.0.140615748359.issue46850@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
nosy: +brandtbucher

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46850>
_______________________________________

From report at bugs.python.org  Fri Feb 25 13:36:57 2022
From: report at bugs.python.org (Brandt Bucher)
Date: Fri, 25 Feb 2022 18:36:57 +0000
Subject: [issue46836] [C API] Move PyFrameObject to the internal C API
In-Reply-To: <1645628652.12.0.0785803095185.issue46836@roundup.psfhosted.org>
Message-ID: <1645814217.03.0.309181387419.issue46836@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
nosy: +brandtbucher

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46836>
_______________________________________

From report at bugs.python.org  Fri Feb 25 13:40:38 2022
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 25 Feb 2022 18:40:38 +0000
Subject: [issue46855] printing a string with strange characters loops forever
In-Reply-To: <1645804177.22.0.124909459168.issue46855@roundup.psfhosted.org>
Message-ID: <1645814438.51.0.0676942331801.issue46855@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

The ordinal range 0x80-0x9F is the C1 control code set [1]. Ordinal 0x9F is "Application Program Command" (APC). The command must be terminated by ordinal 0x9C, "String Terminator" (ST). For example, "\x9f Some Command \x9c". 

In Gnome Terminal, after executing print('\x9f'), an APC command without a terminator, typing Ctrl+L still works to clear the screen and get back to a prompt.

[1] https://en.wikipedia.org/wiki/C0_and_C1_control_codes#C1_controls

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46855>
_______________________________________

From report at bugs.python.org  Fri Feb 25 13:41:13 2022
From: report at bugs.python.org (Joris Geysens)
Date: Fri, 25 Feb 2022 18:41:13 +0000
Subject: [issue46856] datetime.max conversion
In-Reply-To: <1645805401.57.0.267496020204.issue46856@roundup.psfhosted.org>
Message-ID: <1645814473.37.0.863174381767.issue46856@roundup.psfhosted.org>


Joris Geysens <joris.geysens at enervalis.com> added the comment:

a ValueError is raised : 

ValueError: year 10000 is out of range 

on 

dt = datetime.fromtimestamp(ts, tz=timezone.utc)

or 

dt = datetime.utcfromtimestamp(ts)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46856>
_______________________________________

From report at bugs.python.org  Fri Feb 25 14:05:17 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Feb 2022 19:05:17 +0000
Subject: [issue26175] Fully implement IOBase abstract on SpooledTemporaryFile
In-Reply-To: <1453413274.25.0.536987988375.issue26175@psf.upfronthosting.co.za>
Message-ID: <1645815917.05.0.164791505381.issue26175@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

?ric, you might use git log or git blame to see who that is active has patched the relevant file in the last few years.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26175>
_______________________________________

From report at bugs.python.org  Fri Feb 25 14:08:02 2022
From: report at bugs.python.org (Joongi Kim)
Date: Fri, 25 Feb 2022 19:08:02 +0000
Subject: [issue46843] PersistentTaskGroup API
In-Reply-To: <1645680865.21.0.230450894933.issue46843@roundup.psfhosted.org>
Message-ID: <1645816082.04.0.928702722883.issue46843@roundup.psfhosted.org>


Joongi Kim <me at daybreaker.info> added the comment:

> And just a question: I'm just curious about what happens if belonging tasks see the cancellation raised from their inner tasks.  Sibling tasks should not be cancelled, and the outer task group should not be cancelled, unless the task group itself has requested cancellation.  Could the new cancellation counter help this?

To achieve this by distinguishing cancellation from inner/outer tasks, TaskGroup._on_task_done() should be modified to skip setting _on_completed_fut because it should keep running.  Swallowing exceptions in child tasks can be done without modifying TaskGroup, but this part requires changes of TaskGroup.

Another difference is the usage.  Instead of relying on the async context manager interface, we would call "TaskGroup.shutdown()" separately from either directly in signal handlers or from cleanup methods of long-lived objects that have task groups as attributes.

And I also want to perform two-phase cancellation: instead of cancelling all tasks immediately as in current _abort(), have a configurable grace period until they have chances to complete and then cancel with additional timeout on cancellation itself to prevent hangs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46843>
_______________________________________

From report at bugs.python.org  Fri Feb 25 14:08:36 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Feb 2022 19:08:36 +0000
Subject: [issue26175] Fully implement IOBase abstract on SpooledTemporaryFile
In-Reply-To: <1453413274.25.0.536987988375.issue26175@psf.upfronthosting.co.za>
Message-ID: <1645816116.91.0.728014765693.issue26175@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Also, which of the two patches.

Irit, you just patched Temp file doc, can you look at the PR code?

----------
nosy: +iritkatriel

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26175>
_______________________________________

From report at bugs.python.org  Fri Feb 25 14:26:34 2022
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 25 Feb 2022 19:26:34 +0000
Subject: [issue46853] Python interpreter can get code from memory,
 it is not secure.
In-Reply-To: <1645754273.34.0.366451994283.issue46853@roundup.psfhosted.org>
Message-ID: <1645817194.42.0.390568516388.issue46853@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

This is by design and thus not a security hole or bug.

Also, for any future security issues, please disclose them responsibly by following the instructions at https://www.python.org/dev/security/ .

----------
nosy: +brett.cannon
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46853>
_______________________________________

From report at bugs.python.org  Fri Feb 25 14:38:24 2022
From: report at bugs.python.org (Joongi Kim)
Date: Fri, 25 Feb 2022 19:38:24 +0000
Subject: [issue46843] PersistentTaskGroup API
In-Reply-To: <1645680865.21.0.230450894933.issue46843@roundup.psfhosted.org>
Message-ID: <1645817904.39.0.00920523542065.issue46843@roundup.psfhosted.org>


Joongi Kim <me at daybreaker.info> added the comment:

Short summary:

PersistentTaskGroup shares the followings from TaskGroup:
- It uses WeakSet to keep track of child tasks.
- After exiting the async context manager scope (or the shutdown procedure), it ensures that all tasks are complete or cancelled.

PersistentTaskGroup differs in that:
- It keeps running after all tasks successfully finish unless it is explicitly shutdown or the parent task is cancelled.
- It is one of the main use cases that shutdown() method is called separately.  The shutdown procedure may be triggered from different task contexts.
- It provides two-phase cancellation with a configurable grace period.
- It does not propagate unhandled exceptions and cancellations from child tasks to the outside of the task group and sibling tasks but calls a customizable fallback exception handler. -> This could be done without modifying TaskGroup.

The API looks similar to TaskGroup with minor modification.
The semantics of a PersistentTaskGroup more resembles a nested event loop, in that it has its own set of tasks, it keeps running until closed, and it has its own fallback exception handler.

Note that current aiotools implementation lacks many details, such as two-phase cancellation.  I'm going to implement more soon.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46843>
_______________________________________

From report at bugs.python.org  Fri Feb 25 15:01:48 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Feb 2022 20:01:48 +0000
Subject: [issue37426] getpass.getpass not working with on windows when ctrl+v
 is used to enter the string
In-Reply-To: <1561628977.4.0.232389584594.issue37426@roundup.psfhosted.org>
Message-ID: <1645819308.69.0.0922451158055.issue37426@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy:  -terry.reedy
versions: +Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37426>
_______________________________________

From report at bugs.python.org  Fri Feb 25 15:29:58 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Feb 2022 20:29:58 +0000
Subject: [issue46810] Make multiprocessing.connection.Client support ipv6
In-Reply-To: <1645378606.64.0.848284398217.issue46810@roundup.psfhosted.org>
Message-ID: <1645820998.93.0.502965299155.issue46810@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +davin, pitrou
title: multiprocessing.connection.Client doesn't support ipv6 -> Make multiprocessing.connection.Client support ipv6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46810>
_______________________________________

From report at bugs.python.org  Fri Feb 25 15:31:50 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Feb 2022 20:31:50 +0000
Subject: [issue46816] Remove declarations for non-__STDC__ compilers
In-Reply-To: <1645440519.15.0.480736088206.issue46816@roundup.psfhosted.org>
Message-ID: <1645821110.08.0.290603892594.issue46816@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46816>
_______________________________________

From report at bugs.python.org  Fri Feb 25 15:35:19 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Feb 2022 20:35:19 +0000
Subject: [issue46833] Windows installer is unclear and has redundant settings
In-Reply-To: <1645604528.5.0.846357801282.issue46833@roundup.psfhosted.org>
Message-ID: <1645821319.42.0.93898623705.issue46833@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: Installer Wizard is unclear and has redundant settings -> Windows installer is unclear and has redundant settings

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46833>
_______________________________________

From report at bugs.python.org  Fri Feb 25 15:45:07 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Feb 2022 20:45:07 +0000
Subject: [issue46838] Parameters and arguments parser syntax error improvments
In-Reply-To: <1645651401.14.0.658565183507.issue46838@roundup.psfhosted.org>
Message-ID: <1645821907.9.0.822217656433.issue46838@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

With two exceptions, nice suggestions if feasible.

>>> def foo(*args=None): pass
SyntaxError: * argument cannot have default value

>>> def foo(**kwargs=None): pass
SyntaxError: ** argument cannot have default value

Good.

>>> foo(*args=[0])
SyntaxError: cannot assign to iterable argument unpacking

>>> foo(**args={"a": None})
SyntaxError: cannot assign to keyword argument unpacking

Incomprehensible.  It seems to me that these should have same message as first two; message should not depend on proposed default.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46838>
_______________________________________

From report at bugs.python.org  Fri Feb 25 15:47:49 2022
From: report at bugs.python.org (benrg)
Date: Fri, 25 Feb 2022 20:47:49 +0000
Subject: [issue46858] mmap constructor resets the file pointer on Windows
Message-ID: <1645822069.83.0.570318294839.issue46858@roundup.psfhosted.org>


New submission from benrg <benrudiak at gmail.com>:

On Windows, `mmap.mmap(f.fileno(), ...)` has the undocumented side effect of setting f's file pointer to 0.

The responsible code in mmapmodule is this:

    /* Win9x appears to need us seeked to zero */
    lseek(fileno, 0, SEEK_SET);

Win9x is no longer supported, and I'm quite sure that NT doesn't have whatever problem they were trying to fix. I think this code should be deleted, and a regression test added to verify that mmap leaves the file pointer alone on all platforms.

(mmap also maintains its own file pointer, the `pos` field of `mmap_object`, which is initially set to zero. This issue is about the kernel file pointer, not mmap's pointer.)

----------
components: IO, Library (Lib), Windows
messages: 414039
nosy: benrg, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: mmap constructor resets the file pointer on Windows
type: behavior
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46858>
_______________________________________

From report at bugs.python.org  Fri Feb 25 16:09:26 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Feb 2022 21:09:26 +0000
Subject: [issue46845] dict: Use smaller entry for Unicode-key only dict.
In-Reply-To: <1645688455.61.0.00785191075466.issue46845@roundup.psfhosted.org>
Message-ID: <1645823366.53.0.282544941794.issue46845@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

CPython, at least, allows users to insert non-string keys in namespace dicts that are conceptually string-key only.

>>> globals()[0] = 'zero'
>>> globals()[0]
'zero'
>>> vars()
{'__name__': '__main__', ..., 0: 'zero'}

[This is for consenting adults only, as it prevents sorting keys and string-only operations on keys.
>>> dir()
...
TypeError: '<' not supported between instances of 'int' and 'str']
 
Do you propose to
1. Only use StringKeyDicts when non-string keys are not possible?  (Where would this be?)
2. Switch to a normal dict when a non-string key is added?  (But likely not switch back when the last non-string key is removed.)
3. Deprecate and remove the option to add non-string keys to namespace dicts?  (Proposed and rejected at least once as not gaining much.)

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46845>
_______________________________________

From report at bugs.python.org  Fri Feb 25 16:15:29 2022
From: report at bugs.python.org (svilen dobrev)
Date: Fri, 25 Feb 2022 21:15:29 +0000
Subject: [issue46855] printing a string with strange characters loops forever
In-Reply-To: <1645804177.22.0.124909459168.issue46855@roundup.psfhosted.org>
Message-ID: <1645823729.59.0.439059235669.issue46855@roundup.psfhosted.org>


svilen dobrev <az at svilendobrev.com> added the comment:

aha. ctrl-s also closes it.
seems kind-of ( ctrl-q - ctrl-s )
 https://en.wikipedia.org/wiki/Software_flow_control

thanks, closing this.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46855>
_______________________________________

From report at bugs.python.org  Fri Feb 25 16:21:23 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Feb 2022 21:21:23 +0000
Subject: [issue46849] Memory problems detected using Valgrind
In-Reply-To: <1645711886.58.0.922948546021.issue46849@roundup.psfhosted.org>
Message-ID: <1645824083.12.0.305319648877.issue46849@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

It is possible that some core developer may get regular valgrind reports, but I would not know who.  I am pretty sure that you should run it at least on the latest release of the 'main' branch, 3.11.0a5, and perhaps even better, the current tip.  There might be a performance patch that was not backported.  (I have no idea what iotop is.)

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46849>
_______________________________________

From report at bugs.python.org  Fri Feb 25 16:22:41 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Feb 2022 21:22:41 +0000
Subject: [issue46854] Failed to compile static python3.7.12
In-Reply-To: <1645760809.24.0.711406085286.issue46854@roundup.psfhosted.org>
Message-ID: <1645824161.97.0.613614538118.issue46854@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46854>
_______________________________________

From report at bugs.python.org  Fri Feb 25 16:38:57 2022
From: report at bugs.python.org (Joris Geysens)
Date: Fri, 25 Feb 2022 21:38:57 +0000
Subject: [issue46856] datetime.max conversion
In-Reply-To: <1645805401.57.0.267496020204.issue46856@roundup.psfhosted.org>
Message-ID: <1645825137.61.0.154118200722.issue46856@roundup.psfhosted.org>


Joris Geysens <joris.geysens at enervalis.com> added the comment:

I see this in the python source code being tested (datetimetester.py), so I guess it is a rounding problem : 

# maximum timestamp: set seconds to zero to avoid rounding issues
        max_dt = self.theclass.max.replace(tzinfo=timezone.utc,
                                           second=0, microsecond=0)
        max_ts = max_dt.timestamp()
        # date 9999-12-31 23:59:00+00:00: timestamp 253402300740
        self.assertEqual(self.theclass.fromtimestamp(max_ts, tz=timezone.utc),
                         max_dt)

----------
components: +Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46856>
_______________________________________

From report at bugs.python.org  Fri Feb 25 16:58:48 2022
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 25 Feb 2022 21:58:48 +0000
Subject: [issue46856] datetime.max conversion
In-Reply-To: <1645805401.57.0.267496020204.issue46856@roundup.psfhosted.org>
Message-ID: <1645826328.38.0.973314244339.issue46856@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Probably so. You could step through the code to make sure that's what's going on.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46856>
_______________________________________

From report at bugs.python.org  Fri Feb 25 17:42:54 2022
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 25 Feb 2022 22:42:54 +0000
Subject: [issue46838] Parameters and arguments parser syntax error improvments
In-Reply-To: <1645651401.14.0.658565183507.issue46838@roundup.psfhosted.org>
Message-ID: <1645828974.17.0.941162455957.issue46838@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +29713
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31590

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46838>
_______________________________________

From report at bugs.python.org  Fri Feb 25 17:44:39 2022
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 25 Feb 2022 22:44:39 +0000
Subject: [issue46845] dict: Use smaller entry for Unicode-key only dict.
In-Reply-To: <1645823366.53.0.282544941794.issue46845@roundup.psfhosted.org>
Message-ID: <CAEfz+TwN+uzcMMN+SbAyF00PsEYU95V-zi2VBWSH-g3cy_mZ6A@mail.gmail.com>


Inada Naoki <songofacandy at gmail.com> added the comment:

>
>
> Do you propose to
> 1. Only use StringKeyDicts when non-string keys are not possible?  (Where
> would this be?)
> 2. Switch to a normal dict when a non-string key is added?  (But likely
> not switch back when the last non-string key is removed.)
> 3. Deprecate and remove the option to add non-string keys to namespace
> dicts?  (Proposed and rejected at least once as not gaining much.)
>
>
>

2. We already do such hack for key sharing dict.
And yes, deleting non string key doesn't switch back. d[0]=0; del d[0];
loop must be amortized O(1).
Only dict.clear() switches back.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46845>
_______________________________________

From report at bugs.python.org  Fri Feb 25 18:17:10 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 23:17:10 +0000
Subject: [issue46816] Remove declarations for non-__STDC__ compilers
In-Reply-To: <1645440519.15.0.480736088206.issue46816@roundup.psfhosted.org>
Message-ID: <1645831030.44.0.893222381006.issue46816@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 4060111f9dc44682f9d7bdafb4e7dacb96706ad3 by Oleg Iarygin in branch 'main':
bpo-46816: Remove declarations for non-__STDC__ compilers (GH-31466)
https://github.com/python/cpython/commit/4060111f9dc44682f9d7bdafb4e7dacb96706ad3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46816>
_______________________________________

From report at bugs.python.org  Fri Feb 25 18:17:32 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 23:17:32 +0000
Subject: [issue46816] Remove declarations for non-__STDC__ compilers
In-Reply-To: <1645440519.15.0.480736088206.issue46816@roundup.psfhosted.org>
Message-ID: <1645831052.35.0.870784923914.issue46816@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

It should be fine :-D Thanks.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46816>
_______________________________________

From report at bugs.python.org  Fri Feb 25 18:20:43 2022
From: report at bugs.python.org (Norman Fung)
Date: Fri, 25 Feb 2022 23:20:43 +0000
Subject: [issue46859] NameError: free variable 'outer' referenced before
 assignment in enclosing scope
Message-ID: <1645831243.13.0.138384399313.issue46859@roundup.psfhosted.org>


New submission from Norman Fung <norman.lm.fung at gmail.com>:

In reference to ticket (which was fix for Python 3.9 or above) https://bugs.python.org/issue46672?@ok_message=msg%20413975%20created%0Aissue%2046672%20nosy_count%2C%20nosy%2C%20messages%2C%20message_count%20edited%20ok&@template=item

I encountered this problem on:
a) Python 3.8.5
b) asyncio 3.4.3

Stack
Exception in callback gather.<locals>._done_callback(<Future finis...events.py:422>) at C:\ProgramData\Anaconda3\lib\asyncio\tasks.py:758
handle: <Handle gather.<locals>._done_callback(<Future finis...events.py:422>) at C:\ProgramData\Anaconda3\lib\asyncio\tasks.py:758 created at C:\ProgramData\Anaconda3\lib\asyncio\futures.py:149>
source_traceback: Object created at (most recent call last):
  File "src\xxxxx.py", line 37, in _invoke_runners
    one_loop.run_until_complete(runner.xxxxx)
  File "C:\ProgramData\Anaconda3\lib\site-packages\nest_asyncio.py", line 90, in run_until_complete
    self._run_once()
  File "C:\ProgramData\Anaconda3\lib\site-packages\nest_asyncio.py", line 127, in _run_once
    handle._run()
  File "C:\ProgramData\Anaconda3\lib\site-packages\nest_asyncio.py", line 196, in run
    ctx.run(self._callback, *self._args)
  File "C:\ProgramData\Anaconda3\lib\asyncio\futures.py", line 356, in _set_state
    _copy_future_state(other, future)
  File "C:\ProgramData\Anaconda3\lib\asyncio\futures.py", line 335, in _copy_future_state
    dest.set_result(result)
  File "C:\ProgramData\Anaconda3\lib\asyncio\futures.py", line 237, in set_result
    self.__schedule_callbacks()
  File "C:\ProgramData\Anaconda3\lib\asyncio\futures.py", line 149, in __schedule_callbacks
    self._loop.call_soon(callback, self, context=ctx)
Traceback (most recent call last):
  File "C:\ProgramData\Anaconda3\lib\site-packages\nest_asyncio.py", line 196, in run
    ctx.run(self._callback, *self._args)
  File "C:\ProgramData\Anaconda3\lib\asyncio\tasks.py", line 762, in _done_callback
    if outer.done():
NameError: free variable 'outer' referenced before assignment in enclosing scope

----------
components: asyncio
messages: 414048
nosy: asvetlov, miss-islington, norman.lm.fung, onerandomusername, sobolevn, yselivanov
priority: normal
severity: normal
status: open
title: NameError: free variable 'outer' referenced before assignment in enclosing scope
type: crash
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46859>
_______________________________________

From report at bugs.python.org  Fri Feb 25 18:20:49 2022
From: report at bugs.python.org (Brandt Bucher)
Date: Fri, 25 Feb 2022 23:20:49 +0000
Subject: [issue46841] Inline bytecode caches
In-Reply-To: <1645669034.5.0.77775951626.issue46841@roundup.psfhosted.org>
Message-ID: <1645831249.42.0.885287738476.issue46841@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
pull_requests: +29714
pull_request: https://github.com/python/cpython/pull/31591

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46841>
_______________________________________

From report at bugs.python.org  Fri Feb 25 18:25:59 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 23:25:59 +0000
Subject: [issue45459] Limited API support for Py_buffer
In-Reply-To: <1634118913.79.0.141868262007.issue45459@roundup.psfhosted.org>
Message-ID: <1645831559.66.0.904191602961.issue45459@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I close again the issue, the C API should now be fine :-)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45459>
_______________________________________

From report at bugs.python.org  Fri Feb 25 18:53:38 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2022 23:53:38 +0000
Subject: [issue46852] Remove the float.__setformat__() method
In-Reply-To: <1645747677.37.0.919337626983.issue46852@roundup.psfhosted.org>
Message-ID: <1645833218.21.0.985476835175.issue46852@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 5ab745fc51e159ead28b523414e52f0bcc1ef353 by Victor Stinner in branch 'main':
bpo-46852: Remove the float.__set_format__() method (GH-31585)
https://github.com/python/cpython/commit/5ab745fc51e159ead28b523414e52f0bcc1ef353


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46852>
_______________________________________

From report at bugs.python.org  Fri Feb 25 19:15:14 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Feb 2022 00:15:14 +0000
Subject: [issue46852] Remove the float.__setformat__() method
In-Reply-To: <1645747677.37.0.919337626983.issue46852@roundup.psfhosted.org>
Message-ID: <1645834514.23.0.490508003313.issue46852@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29715
pull_request: https://github.com/python/cpython/pull/31592

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46852>
_______________________________________

From report at bugs.python.org  Fri Feb 25 19:18:02 2022
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 26 Feb 2022 00:18:02 +0000
Subject: [issue46860] `--with-suffix` not respected on case-insensitive file
 systems
Message-ID: <1645834682.9.0.270645499588.issue46860@roundup.psfhosted.org>


New submission from Brett Cannon <brett at python.org>:

If you use `--with-suffix` on a case-insensitive file system it is ultimately ignored and forced to `.exe`.

PR incoming.

----------
assignee: brett.cannon
components: Build
messages: 414051
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: `--with-suffix` not respected on case-insensitive file systems
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46860>
_______________________________________

From report at bugs.python.org  Fri Feb 25 19:20:46 2022
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 26 Feb 2022 00:20:46 +0000
Subject: [issue46860] `--with-suffix` not respected on case-insensitive file
 systems
In-Reply-To: <1645834682.9.0.270645499588.issue46860@roundup.psfhosted.org>
Message-ID: <1645834846.31.0.311506238415.issue46860@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
keywords: +patch
pull_requests: +29716
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31593

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46860>
_______________________________________

From report at bugs.python.org  Fri Feb 25 19:26:19 2022
From: report at bugs.python.org (Andre Roberge)
Date: Sat, 26 Feb 2022 00:26:19 +0000
Subject: [issue46838] Parameters and arguments parser syntax error improvments
In-Reply-To: <1645651401.14.0.658565183507.issue46838@roundup.psfhosted.org>
Message-ID: <1645835179.03.0.569512185149.issue46838@roundup.psfhosted.org>


Change by Andre Roberge <andre.roberge at gmail.com>:


----------
nosy: +aroberge

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46838>
_______________________________________

From report at bugs.python.org  Fri Feb 25 19:30:09 2022
From: report at bugs.python.org (Andrej Klychin)
Date: Sat, 26 Feb 2022 00:30:09 +0000
Subject: [issue46838] Parameters and arguments parser syntax error improvments
In-Reply-To: <1645651401.14.0.658565183507.issue46838@roundup.psfhosted.org>
Message-ID: <1645835409.03.0.164935983267.issue46838@roundup.psfhosted.org>


Andrej Klychin <andy_kl at bk.ru> added the comment:

@terry.reedy, I based that error message on current >>> foo(**{}, *())
SyntaxError: iterable argument unpacking follows keyword argument unpacking

and >>> foo(__debug__=True)
SyntaxError: cannot assign to __debug__

but the final error message could be anything if it explicitly says "what's wrong".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46838>
_______________________________________

From report at bugs.python.org  Fri Feb 25 20:11:01 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Feb 2022 01:11:01 +0000
Subject: [issue46748] Python.h includes stdbool.h
In-Reply-To: <1644830899.62.0.590844926135.issue46748@roundup.psfhosted.org>
Message-ID: <1645837861.18.0.987525580458.issue46748@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> New changeset 2c228a7b8f89e9ed8d390370abd771d4993b79d8 by Petr Viktorin in branch 'main':
> bpo-46748: Don't import <stdbool.h> in public headers (GH-31553)

It seems like this change broke ctypes on some architectures like s390x:

https://buildbot.python.org/all/#/builders/3/builds/1573

======================================================================
FAIL: test_frozentable (ctypes.test.test_values.PythonValuesTestCase) [__phello_alias__]
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.clang/build/Lib/ctypes/test/test_values.py", line 86, in test_frozentable
    self.assertIsNone(spec.submodule_search_locations)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: [] is not None
======================================================================
FAIL: test_frozentable (ctypes.test.test_values.PythonValuesTestCase) [__phello__]
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.clang/build/Lib/ctypes/test/test_values.py", line 86, in test_frozentable
    self.assertIsNone(spec.submodule_search_locations)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: ['/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.clang/build/Lib/__phello__'] is not None
======================================================================
FAIL: test_frozentable (ctypes.test.test_values.PythonValuesTestCase) [__phello__.ham]
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.clang/build/Lib/ctypes/test/test_values.py", line 86, in test_frozentable
    self.assertIsNone(spec.submodule_search_locations)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: ['/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.clang/build/Lib/__phello__/ham'] is not None

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46748>
_______________________________________

From report at bugs.python.org  Fri Feb 25 20:21:59 2022
From: report at bugs.python.org (aprpp)
Date: Sat, 26 Feb 2022 01:21:59 +0000
Subject: [issue46854] Failed to compile static python3.7.12
In-Reply-To: <1645760809.24.0.711406085286.issue46854@roundup.psfhosted.org>
Message-ID: <1645838519.33.0.834015134982.issue46854@roundup.psfhosted.org>


aprpp <916495294 at qq.com> added the comment:

I  have signed the contributor agreement

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46854>
_______________________________________

From report at bugs.python.org  Fri Feb 25 20:27:48 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Sat, 26 Feb 2022 01:27:48 +0000
Subject: [issue46859] NameError: free variable 'outer' referenced before
 assignment in enclosing scope
In-Reply-To: <1645831243.13.0.138384399313.issue46859@roundup.psfhosted.org>
Message-ID: <1645838868.85.0.879373197068.issue46859@roundup.psfhosted.org>


Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:

3.8 is only receiving security fixes now. Please upgrade. If you cannot upgrade, I suggest manually applying the patch from https://github.com/python/cpython/pull/31441/files to your installation of Python.

----------
nosy: +Jelle Zijlstra
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46859>
_______________________________________

From report at bugs.python.org  Fri Feb 25 20:29:38 2022
From: report at bugs.python.org (Jeremy Kloth)
Date: Sat, 26 Feb 2022 01:29:38 +0000
Subject: [issue46857] Python leaks one reference at exit on Windows
In-Reply-To: <1645808231.81.0.426207041717.issue46857@roundup.psfhosted.org>
Message-ID: <1645838978.31.0.114008331345.issue46857@roundup.psfhosted.org>


Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com> added the comment:

Good news, the difference on Windows was easy enough to find, bad news total refs are now negative!

--- a/Objects/exceptions.c
+++ b/Objects/exceptions.c
@@ -3647,8 +3647,7 @@ _PyBuiltins_AddExceptions(PyObject *bltinmod)

 #define INIT_ALIAS(NAME, TYPE) \
     do { \
-        Py_INCREF(PyExc_ ## TYPE); \
-        Py_XDECREF(PyExc_ ## NAME); \
+        Py_XSETREF(PyExc_ ## NAME, PyExc_ ## TYPE); \
         PyExc_ ## NAME = PyExc_ ## TYPE; \
         if (PyDict_SetItemString(mod_dict, # NAME, PyExc_ ## NAME)) { \
             return -1; \

As the PyExc_* aliases just deprecated names for PyExc_OSError, there is no need to increment their refcounts.  Or they could be decremented in Fini().  Or they could finally be removed entirely.

----------
nosy: +jkloth

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46857>
_______________________________________

From report at bugs.python.org  Fri Feb 25 20:38:00 2022
From: report at bugs.python.org (Jeremy Kloth)
Date: Sat, 26 Feb 2022 01:38:00 +0000
Subject: [issue46857] Python leaks one reference at exit on Windows
In-Reply-To: <1645808231.81.0.426207041717.issue46857@roundup.psfhosted.org>
Message-ID: <1645839480.22.0.516778996869.issue46857@roundup.psfhosted.org>


Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com> added the comment:

Note that an allocated block is still leaking.

Strange as well, when using dump_refs, the total refs are much more negative (-12 linux, -13 Windows)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46857>
_______________________________________

From report at bugs.python.org  Fri Feb 25 20:41:34 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Feb 2022 01:41:34 +0000
Subject: [issue46857] Python leaks one reference at exit on Windows
In-Reply-To: <1645808231.81.0.426207041717.issue46857@roundup.psfhosted.org>
Message-ID: <1645839694.47.0.480159145468.issue46857@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29717
pull_request: https://github.com/python/cpython/pull/31594

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46857>
_______________________________________

From report at bugs.python.org  Fri Feb 25 20:50:52 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Feb 2022 01:50:52 +0000
Subject: [issue46857] Python leaks one reference at exit on Windows
In-Reply-To: <1645808231.81.0.426207041717.issue46857@roundup.psfhosted.org>
Message-ID: <1645840252.45.0.915416762124.issue46857@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Good news, the difference on Windows was easy enough to find, bad news total refs are now negative!

Oh wow. How did you find this leak? Did you read all C files and check for code specific to Windows? How did you proceed? Well spotted!


>  #define INIT_ALIAS(NAME, TYPE)

I proposed GH-31594 to fix this macro.


> Strange as well, when using dump_refs, the total refs are much more negative (-12 linux, -13 Windows)

Which command do you type? Do you pass -I option to Python?

With my PR, I get exactly 0 on Linux:

$ ./python -I -X showrefcount -c pass
[0 refs, 0 blocks]


> Note that an allocated block is still leaking.

Right, with my PR, I now get 1 leaked memory block on Windows:

> python -I -X showrefcount -c pass               
[0 refs, 1 blocks]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46857>
_______________________________________

From report at bugs.python.org  Fri Feb 25 21:21:18 2022
From: report at bugs.python.org (Ned Deily)
Date: Sat, 26 Feb 2022 02:21:18 +0000
Subject: [issue46854] Failed to compile static python3.7.12
In-Reply-To: <1645760809.24.0.711406085286.issue46854@roundup.psfhosted.org>
Message-ID: <1645842078.38.0.850297546459.issue46854@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Successfully building a statically-linked version of Python depends greatly on the environment in which you are trying to build it and is really beyond the scope of this bug tracker. You don't say on which OS platform and version you are attempting this so it is hard to give any meaningful suggestions other than to make sure you have installed development versions (those including header files) of the various third-party libraries Python builds depend on (like libssl and libcrypto from OpenSSL), if your platform has a package manager, or build the required third-party libraries yourself. In any case, you will probably need to further edit the Setup file to reflect the location of the various third-party headers and libraries. As a rule, we don't do a lot of testing of static builds using Setup directly but some of the downstream distributors of Python do. Also note that Python 3.7 is now in the security-fix-only phase of its lifecycle prior to end-of-life in 2023, so further changes to the build process in 3.7 at this point would be out-of-scope. For what it's worth, there has been a significant amount of work in this area that is going into the next Python feature release, 3.11.0, planned for later this year so it should be significantly easier to do static builds and the like in 3.11. If you still run into problems with 3.7, suggest you ask in help forums like StackOverflow.  Good luck!

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46854>
_______________________________________

From report at bugs.python.org  Fri Feb 25 22:12:34 2022
From: report at bugs.python.org (aprpp)
Date: Sat, 26 Feb 2022 03:12:34 +0000
Subject: [issue46854] Failed to compile static python3.7.12
In-Reply-To: <1645760809.24.0.711406085286.issue46854@roundup.psfhosted.org>
Message-ID: <1645845154.64.0.189845487352.issue46854@roundup.psfhosted.org>


Change by aprpp <916495294 at qq.com>:


----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46854>
_______________________________________

From report at bugs.python.org  Fri Feb 25 22:18:28 2022
From: report at bugs.python.org (Jeremy Kloth)
Date: Sat, 26 Feb 2022 03:18:28 +0000
Subject: [issue46857] Python leaks one reference at exit on Windows
In-Reply-To: <1645840252.45.0.915416762124.issue46857@roundup.psfhosted.org>
Message-ID: <CAGvrs3KzZU5Nr7jvxrt=uNU4UJN9zU8+iOKHhhbCTF5sKG7wRQ@mail.gmail.com>


Jeremy Kloth <jeremy.kloth at gmail.com> added the comment:

> Oh wow. How did you find this leak? Did you read all C files and check for code specific to Windows? How did you proceed? Well spotted!

Initially, I modified Py_INCREF to dump the object (addr & tp_name) on
initial inc (ob_refcnt == 1) and Py_DECREF to dump on final dec
(ob_refcnt == 0).
Then filter that list (~65K) to find objects not dealloc'ed.  Given
those names (~200), cross-check with source files containing 'ifdef
MS_WINDOWS' (and related spellings).

> Which command do you type? Do you pass -I option to Python?

For both as -I disables environment lookup:
--- a/Python/initconfig.c
+++ b/Python/initconfig.c
@@ -757,6 +757,7 @@ config_init_defaults(PyConfig *config)
    config->user_site_directory = 1;
    config->buffered_stdio = 1;
    config->pathconfig_warnings = 1;
+   config->dump_refs = 1;
#ifdef MS_WINDOWS
    config->legacy_windows_stdio = 0;
#endif

For linux:
./configure --enabled-shared --with-py-debug --with-trace-refs
make build_all
LD_LIBRARY_PATH=$PWD ./python -X showrefcount -I -c pass

For Windows:
Add "#define Py_TRACE_REFS 1" to PC\pyconfig.h
build.bat -d -e
amd64\python_d.exe -X showrefcount -I -c pass

> I proposed GH-31594 to fix this macro.

Even using that change, I still have negative refs (but I still have
Py_TRACE_REFS defined)

----------
nosy: +jeremy.kloth

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46857>
_______________________________________

From report at bugs.python.org  Fri Feb 25 22:30:45 2022
From: report at bugs.python.org (aprpp)
Date: Sat, 26 Feb 2022 03:30:45 +0000
Subject: [issue46854] Failed to compile static python3.7.12
In-Reply-To: <1645760809.24.0.711406085286.issue46854@roundup.psfhosted.org>
Message-ID: <1645846245.77.0.957053047742.issue46854@roundup.psfhosted.org>


aprpp <916495294 at qq.com> added the comment:

The platform i build python3.7.12 on is Ubuntu18.04, I would like to know how the modules I fail to build, like _ctypes, should be added in Modules/Setup.
The steps for my build are?
1.tar -zxvf Python-3.7.12.tgz && cd Python-3.7.12 
2.edit Modules/Setup, add modules build definitions in the Modules/Setup
3../configure LDFLAGS="-static" --disable-shared --prefix=/home/python3
4.make LDFLAGS="-static" LINKFORSHARED=" "

How to build python3.7 statically without relying on editing Modules/Setup?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46854>
_______________________________________

From report at bugs.python.org  Fri Feb 25 22:33:09 2022
From: report at bugs.python.org (Jeremy Kloth)
Date: Sat, 26 Feb 2022 03:33:09 +0000
Subject: [issue46857] Python leaks one reference at exit on Windows
In-Reply-To: <CAGvrs3KzZU5Nr7jvxrt=uNU4UJN9zU8+iOKHhhbCTF5sKG7wRQ@mail.gmail.com>
Message-ID: <CAGvrs3Jqgotk2PnkmiCFWjrmSvfRGY74WEqsB=xqLhGZY7_9Og@mail.gmail.com>


Jeremy Kloth <jeremy.kloth at gmail.com> added the comment:

> ./configure --enabled-shared --with-py-debug --with-trace-refs

(that's what I get for typing from memory):
./configure --enable-shared --with-pydebug --with-trace-refs

> > I proposed GH-31594 to fix this macro.
>
> Even using that change, I still have negative refs (but I still have
> Py_TRACE_REFS defined)

I initially missed the _PySet_Dummy change, with that total refs (w/o
dump_refs) is now 0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46857>
_______________________________________

From report at bugs.python.org  Fri Feb 25 22:35:47 2022
From: report at bugs.python.org (aprpp)
Date: Sat, 26 Feb 2022 03:35:47 +0000
Subject: [issue46854] Failed to compile static python3.7.12
In-Reply-To: <1645760809.24.0.711406085286.issue46854@roundup.psfhosted.org>
Message-ID: <1645846547.35.0.617817739933.issue46854@roundup.psfhosted.org>


aprpp <916495294 at qq.com> added the comment:

As shown in the attachment, how should I add the definition of module _ctypes to Modules/Setup? Modules like _ctypes are not given in Modules/Setup.dist, I really don't know what they depend on

----------
Added file: https://bugs.python.org/file50644/Setup.PNG

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46854>
_______________________________________

From report at bugs.python.org  Fri Feb 25 22:44:08 2022
From: report at bugs.python.org (benrg)
Date: Sat, 26 Feb 2022 03:44:08 +0000
Subject: [issue46861] os.environ forces variable names to upper case on Windows
Message-ID: <1645847048.14.0.626717468993.issue46861@roundup.psfhosted.org>


New submission from benrg <benrudiak at gmail.com>:

The Windows functions that deal with environment variables are case-insensitive and case-preserving, like most Windows file systems. Many environment variables are conventionally written in all caps, but others aren't, such as `ProgramData`, `PSModulePath`, and `windows_tracing_logfile`.

os.environ forces all environment variable names to upper case when it's constructed. One consequence is that if you pass a modified environment to subprocess.Popen, you end up with variables named `PROGRAMDATA`, etc., even if you didn't modify their values.

While this is unlikely to break things since other software normally ignores the case, it's nonstandard behavior, and disconcerting when the affected variable names are shown to human beings.

Here's an example of someone being confused by this: https://stackoverflow.com/questions/19023238/why-python-uppercases-all-environment-variables-in-windows

----------
components: Library (Lib), Windows
messages: 414064
nosy: benrg, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: os.environ forces variable names to upper case on Windows
type: behavior
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46861>
_______________________________________

From report at bugs.python.org  Fri Feb 25 23:08:58 2022
From: report at bugs.python.org (Ned Deily)
Date: Sat, 26 Feb 2022 04:08:58 +0000
Subject: [issue46854] Failed to compile static python3.7.12
In-Reply-To: <1645760809.24.0.711406085286.issue46854@roundup.psfhosted.org>
Message-ID: <1645848538.06.0.28873721775.issue46854@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Sorry, I'll repeat: "Successfully building a statically-linked version of Python depends greatly on the environment in which you are trying to build it and is really beyond the scope of this bug tracker." Note, a quick web search found this page which should give you some suggestions on what dev packages need to be installed in an Ubuntu 18.04 environment. But also note that the directions there are for a normal, non-static Python build using setup.py and not Modules/Setup which, again, we don't normally test for 3.7. Good luck!

https://linuxize.com/post/how-to-install-python-3-7-on-ubuntu-18-04/

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46854>
_______________________________________

From report at bugs.python.org  Fri Feb 25 23:15:04 2022
From: report at bugs.python.org (Ned Deily)
Date: Sat, 26 Feb 2022 04:15:04 +0000
Subject: [issue46854] Failed to compile static python3.7.12
In-Reply-To: <1645760809.24.0.711406085286.issue46854@roundup.psfhosted.org>
Message-ID: <1645848904.18.0.022850778278.issue46854@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

P.S. One other suggestion: try building a non-static version of Python 3.7 first, i.e. without modifying Modules/Setup, and, once you get that working, it should be easier to examine the output from the build and copy those paths that setup.py found into your Modules/Setup.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46854>
_______________________________________

From report at bugs.python.org  Fri Feb 25 23:17:24 2022
From: report at bugs.python.org (Tim Peters)
Date: Sat, 26 Feb 2022 04:17:24 +0000
Subject: [issue45735] Promise the long-time truth that `args=list` works
In-Reply-To: <1636171321.93.0.670075505099.issue45735@roundup.psfhosted.org>
Message-ID: <1645849044.03.0.111889818342.issue45735@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:


New changeset e466faa9df9a1bd377d9725de5484471bc4af8d0 by Charlie Zhao in branch 'main':
bpo-45735: Promise the long-time truth that `args=list` works (GH-30982)
https://github.com/python/cpython/commit/e466faa9df9a1bd377d9725de5484471bc4af8d0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45735>
_______________________________________

From report at bugs.python.org  Fri Feb 25 23:19:39 2022
From: report at bugs.python.org (benrg)
Date: Sat, 26 Feb 2022 04:19:39 +0000
Subject: [issue46862] subprocess makes environment blocks with duplicate keys
 on Windows
Message-ID: <1645849179.34.0.588618338218.issue46862@roundup.psfhosted.org>


New submission from benrg <benrudiak at gmail.com>:

On Windows, if one writes

    env = os.environ.copy()
    env['http_proxy'] = 'whatever'

or either of the documented equivalents ({**os.environ, ...} or (os.environ | {...})), and passes the resulting environment to subprocess.run or subprocess.Popen, the spawned process may get an environment containing both `HTTP_PROXY` and `http_proxy`. Most Win32 software will see only the first one, which contains the unmodified value from os.environ.

Because os.environ forces all keys to upper case, it's possible to work around this by using only upper case keys in the update, but that behavior of os.environ is nonstandard (issue 46861), and subprocess shouldn't depend on it always being true, nor should end users have to.

Since dicts preserve order, the user's (presumable) intent is preserved in the env argument. I think subprocess should do something like

    env = {k.upper(): (k, v) for k, v in env.items()}
    env = dict(env.values())

to discard duplicate keys, keeping only the rightmost one.

----------
components: Library (Lib), Windows
messages: 414068
nosy: benrg, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: subprocess makes environment blocks with duplicate keys on Windows
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46862>
_______________________________________

From report at bugs.python.org  Fri Feb 25 23:55:50 2022
From: report at bugs.python.org (aprpp)
Date: Sat, 26 Feb 2022 04:55:50 +0000
Subject: [issue46854] Failed to compile static python3.7.12
In-Reply-To: <1645760809.24.0.711406085286.issue46854@roundup.psfhosted.org>
Message-ID: <1645851350.08.0.675904931271.issue46854@roundup.psfhosted.org>


aprpp <916495294 at qq.com> added the comment:

I'm really sorry, I would like to know what environment is the official recommendation for static python3.7 compilation? What are the steps and commands for compilation officially required? Because the static python3.7 is very important to me, it has been a week and it has not been compiled successfully.Hope to get official help.Thanks

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46854>
_______________________________________

From report at bugs.python.org  Fri Feb 25 23:58:52 2022
From: report at bugs.python.org (Norman Fung)
Date: Sat, 26 Feb 2022 04:58:52 +0000
Subject: [issue46859] NameError: free variable 'outer' referenced before
 assignment in enclosing scope
In-Reply-To: <1645838868.85.0.879373197068.issue46859@roundup.psfhosted.org>
Message-ID: <CAJxNEcu=+y6fB_hV5wL_h+3Gv=e3Yh4SQ3TjrzdtrxeuWDTaqA@mail.gmail.com>


Norman Fung <norman.lm.fung at gmail.com> added the comment:

Thanks Jelle, let me try upgrade first.

Norman

On Sat, Feb 26, 2022 at 9:27 AM Jelle Zijlstra <report at bugs.python.org>
wrote:

>
> Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:
>
> 3.8 is only receiving security fixes now. Please upgrade. If you cannot
> upgrade, I suggest manually applying the patch from
> https://github.com/python/cpython/pull/31441/files to your installation
> of Python.
>
> ----------
> nosy: +Jelle Zijlstra
> resolution:  -> out of date
> stage:  -> resolved
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue46859>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46859>
_______________________________________

From report at bugs.python.org  Sat Feb 26 00:08:48 2022
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 26 Feb 2022 05:08:48 +0000
Subject: [issue46858] mmap constructor resets the file pointer on Windows
In-Reply-To: <1645822069.83.0.570318294839.issue46858@roundup.psfhosted.org>
Message-ID: <1645852128.15.0.694486960128.issue46858@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

The resize() method also modifies the file pointer. Instead of fixing that oversight, I think it should directly set the file's FileEndOfFileInfo and FileAllocationInfo. For example:

            // resize the file
            if (!SetFileInformationByHandle(
                    self->file_handle, FileEndOfFileInfo,
                    &max_size, sizeof(max_size)) ||
                  !SetFileInformationByHandle(
                        self->file_handle, FileAllocationInfo,
                        &max_size, sizeof(max_size)))
            {
                // resizing failed. try to remap the file
                file_resize_error = GetLastError();
                max_size.QuadPart = self->size;
                new_size = self->size;
            }

This is cheaper in terms of system calls. The existing implementation makes four system calls: one to set the file pointer in SetFilePointerEx() and three in SetEndOfFile(), which queries the file pointer, sets the end-of-file info, and sets the allocation info. 

Note that this approach doesn't modify the file pointer in any case. This may be surprising if the file size shrinks to less than the existing file pointer. But os.ftruncate() behaves the same way, as does the resize() method in Linux.

----------
nosy: +eryksun
versions:  -Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46858>
_______________________________________

From report at bugs.python.org  Sat Feb 26 00:12:46 2022
From: report at bugs.python.org (Adam Pinckard)
Date: Sat, 26 Feb 2022 05:12:46 +0000
Subject: [issue46863] Python 3.10 OpenSSL Configuration Issues
Message-ID: <1645852366.6.0.130545163871.issue46863@roundup.psfhosted.org>


New submission from Adam Pinckard <apinckard85 at gmail.com>:

Python 3.10 does not appear to respecting the OpenSSL configuration within linux. Testing completed using Pyenv on both Ubuntu 20.04.4 and Centos-8. Note PEP 644 which requires OpenSSL >= 1.1.1 is released in Python 3.10.

We operate behind a corporate proxy / firewall which causes an SSL error where the Diffie-Hellman key size is too small. In previous Python versions this is resolved by updating the OpenSSL configuration, e.g. downgrading the linux crypto policies `sudo update-crypto-policies --set LEGACY`. 

The issue is reproducible in both Ubuntu 20.04.4 and Centos-8. In both linux distributions the SSL error is resolvable in earlier Python version, using the OpenSSL configurations, but the configuration is not respected with Python 3.10.2.

See the details below on the kernel versions, linux distributions, and Openssl versions, many thanks in advance.

1. Python 3.10.2 Error:
(py_3_10_2) ?  py_3_10_2 pip install --upgrade pip
WARNING: Retrying (Retry(total=4, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLError(1, '[SSL: DH_KEY_TOO_SMALL] dh key too small (_ssl.c:997)'))': /simple/pip/

2. Ubuntu details
uname -a
Linux Horatio 5.13.0-30-generic #33~20.04.1-Ubuntu SMP Mon Feb 7 14:25:10 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

lsb_release  -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 20.04.4 LTS
Release:	20.04
Codename:	focal

openssl version -a
OpenSSL 1.1.1f  31 Mar 2020
built on: Wed Nov 24 13:20:48 2021 UTC
platform: debian-amd64
options:  bn(64,64) rc4(16x,int) des(int) blowfish(ptr) 
compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -fdebug-prefix-map=/build/openssl-dnfdFp/openssl-1.1.1f=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_TLS_SECURITY_LEVEL=2 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2
OPENSSLDIR: "/usr/lib/ssl"
ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-1.1"
Seeding source: os-specific

2. Centos-8 details
uname -a
Linux localhost.localdomain 5.4.181-1.el8.elrepo.x86_64 #1 SMP Tue Feb 22 10:00:15 EST 2022 x86_64 x86_64 x86_64 GNU/Linux

cat /etc/centos-release
CentOS Stream release 8

openssl version -a
OpenSSL 1.1.1k  FIPS 25 Mar 2021
built on: Thu Dec  2 16:40:48 2021 UTC
platform: linux-x86_64
options:  bn(64,64) md2(char) rc4(16x,int) des(int) idea(int) blowfish(ptr) 
compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -Wa,--noexecstack -Wa,--generate-missing-build-notes=yes -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DZLIB -DNDEBUG -DPURIFY -DDEVRANDOM="\"/dev/urandom\"" -DSYSTEM_CIPHERS_FILE="/etc/crypto-policies/back-ends/openssl.config"
OPENSSLDIR: "/etc/pki/tls"
ENGINESDIR: "/usr/lib64/engines-1.1"
Seeding source: os-specific
engines:  rdrand dynamic

----------
assignee: christian.heimes
components: SSL
messages: 414072
nosy: adam, christian.heimes
priority: normal
severity: normal
status: open
title: Python 3.10 OpenSSL Configuration Issues
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46863>
_______________________________________

From report at bugs.python.org  Sat Feb 26 00:30:36 2022
From: report at bugs.python.org (Ned Deily)
Date: Sat, 26 Feb 2022 05:30:36 +0000
Subject: [issue46854] Failed to compile static python3.7.12
In-Reply-To: <1645760809.24.0.711406085286.issue46854@roundup.psfhosted.org>
Message-ID: <1645853436.37.0.399506546951.issue46854@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

?I would like to know what environment is the official recommendation for static python3.7 compilation.?

There is no official recommendation. As I?ve mentioned, we normally do not build with modified Modules/Setup configurations when developing and releasing Python. It?s complicated. That?s why setup.py and using Distutils to build the standard library modules was introduced years ago. Most users don?t need a statically linked Python. Please accept that you need to look elsewhere for assistance.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46854>
_______________________________________

From report at bugs.python.org  Sat Feb 26 01:00:31 2022
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 26 Feb 2022 06:00:31 +0000
Subject: [issue46862] subprocess makes environment blocks with duplicate keys
 on Windows
In-Reply-To: <1645849179.34.0.588618338218.issue46862@roundup.psfhosted.org>
Message-ID: <1645855231.38.0.441824773566.issue46862@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

This should be handled in _winapi.CreateProcess(). An environment block is technically required to be sorted. (Ages ago this was a MUST requirement for getting and setting variables to work correctly, since the implementation depended on the sort order, but I think nowadays it's a SHOULD requirement.) For example, see the documentation of CreateProcessW() [1]:

    If an application provides an environment block, ... explicitly create
    these environment variable strings, sort them alphabetically (because
    the system uses a sorted environment)

"Changing Environment Variables" is more specific [2]:

    All strings in the environment block must be sorted alphabetically by name.
    The sort is case-insensitive, Unicode order, without regard to locale.

CompareStringOrdinal() [3] implements a case-insensitive ordinal comparison. When a key compares as equal, either keep the current one in the sorted list, or replace it with the new key.

---

[1] https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessw
[2] https://docs.microsoft.com/en-us/windows/win32/procthread/changing-environment-variables
[3] https://docs.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-comparestringordinal

----------
nosy: +eryksun
versions: +Python 3.11, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46862>
_______________________________________

From report at bugs.python.org  Sat Feb 26 01:06:11 2022
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 26 Feb 2022 06:06:11 +0000
Subject: [issue43702] [Windows] correctly sort and remove duplicates in
 _winapi getenvironment()
In-Reply-To: <1617336974.49.0.41114511179.issue43702@roundup.psfhosted.org>
Message-ID: <1645855571.1.0.883597446018.issue43702@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
versions: +Python 3.11 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43702>
_______________________________________

From report at bugs.python.org  Sat Feb 26 01:07:22 2022
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 26 Feb 2022 06:07:22 +0000
Subject: [issue46862] subprocess makes environment blocks with duplicate keys
 on Windows
In-Reply-To: <1645849179.34.0.588618338218.issue46862@roundup.psfhosted.org>
Message-ID: <1645855642.21.0.904220861503.issue46862@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

I suggest closing this issue as a duplicate of bpo-43702.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46862>
_______________________________________

From report at bugs.python.org  Sat Feb 26 01:21:53 2022
From: report at bugs.python.org (Barney Gale)
Date: Sat, 26 Feb 2022 06:21:53 +0000
Subject: [issue45991] Improve ambiguous docstrings in pkgutil
In-Reply-To: <1638730607.25.0.754715317111.issue45991@roundup.psfhosted.org>
Message-ID: <1645856513.04.0.836551252671.issue45991@roundup.psfhosted.org>


Barney Gale <barney.gale at gmail.com> added the comment:

Should pkgutil call os.fspath() in this case?

----------
nosy: +barneygale

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45991>
_______________________________________

From report at bugs.python.org  Sat Feb 26 01:36:56 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 26 Feb 2022 06:36:56 +0000
Subject: [issue46859] NameError: free variable 'outer' referenced before
 assignment in enclosing scope
In-Reply-To: <CAJxNEcu=+y6fB_hV5wL_h+3Gv=e3Yh4SQ3TjrzdtrxeuWDTaqA@mail.gmail.com>
Message-ID: <CAL3CFcW6e1CRY3ruqkzXCHq0JcJFbn7jfLchaasLubg7o+80cA@mail.gmail.com>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Also, fix is 1 week old. There are no python releases with the fix
included yet.

On Sat, Feb 26, 2022, 06:58 Norman Fung <report at bugs.python.org> wrote:

>
> Norman Fung <norman.lm.fung at gmail.com> added the comment:
>
> Thanks Jelle, let me try upgrade first.
>
> Norman
>
> On Sat, Feb 26, 2022 at 9:27 AM Jelle Zijlstra <report at bugs.python.org>
> wrote:
>
> >
> > Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:
> >
> > 3.8 is only receiving security fixes now. Please upgrade. If you cannot
> > upgrade, I suggest manually applying the patch from
> > https://github.com/python/cpython/pull/31441/files to your installation
> > of Python.
> >
> > ----------
> > nosy: +Jelle Zijlstra
> > resolution:  -> out of date
> > stage:  -> resolved
> > status: open -> closed
> >
> > _______________________________________
> > Python tracker <report at bugs.python.org>
> > <https://bugs.python.org/issue46859>
> > _______________________________________
> >
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue46859>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46859>
_______________________________________

From report at bugs.python.org  Sat Feb 26 02:16:13 2022
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 26 Feb 2022 07:16:13 +0000
Subject: [issue28824] os.environ should preserve the case of the OS keys ?
In-Reply-To: <1480359346.4.0.287394822331.issue28824@psf.upfronthosting.co.za>
Message-ID: <1645859773.98.0.0580664393536.issue28824@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
versions: +Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28824>
_______________________________________

From report at bugs.python.org  Sat Feb 26 02:16:55 2022
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 26 Feb 2022 07:16:55 +0000
Subject: [issue46861] os.environ forces variable names to upper case on Windows
In-Reply-To: <1645847048.14.0.626717468993.issue46861@roundup.psfhosted.org>
Message-ID: <1645859815.95.0.341623803676.issue46861@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> os.environ should preserve the case of the OS keys ?

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46861>
_______________________________________

From report at bugs.python.org  Sat Feb 26 02:20:11 2022
From: report at bugs.python.org (Norman Fung)
Date: Sat, 26 Feb 2022 07:20:11 +0000
Subject: [issue46859] NameError: free variable 'outer' referenced before
 assignment in enclosing scope
In-Reply-To: <CAL3CFcW6e1CRY3ruqkzXCHq0JcJFbn7jfLchaasLubg7o+80cA@mail.gmail.com>
Message-ID: <CAJxNEcv7O311RjtcF5g3kAUsTE2ynCVSc5y_Ahx2kLW8PKB7Pg@mail.gmail.com>


Norman Fung <norman.lm.fung at gmail.com> added the comment:

Thanks Andrew for heads up.

*1. My laptop (Windows 10) *with no changes runs happily with no error from
here.
    python 3.8.5
    asyncio 3.4.3

2. *My Windows VM (AWS EC2)* is where the whole mess is happening. I *upgraded
*from Python 3.8.5 to 3.9.7. Asynio stayed 3.4.3, no change.

I manually overwrite C:\ProgramData\Anaconda3\Lib\asyncio\task.py with
what's here https://github.com/python/cpython/pull/31441/files
(Only
https://github.com/asvetlov/cpython/blob/150ef068c77abc6a5e7ba97397ac65113dba355a/Lib/asyncio/tasks.py
)

Before I made this change, the error was:
  File "src\xxx\xxx.py", line 37, in _invoke_runners
    one_loop.run_until_complete(runner.xxx(xxx, xxx))
  File "C:\ProgramData\Anaconda3\lib\site-packages\nest_asyncio.py", line
90, in run_until_complete
    self._run_once()
  File "C:\ProgramData\Anaconda3\lib\site-packages\nest_asyncio.py", line
127, in _run_once
    handle._run()
  File "C:\ProgramData\Anaconda3\lib\site-packages\nest_asyncio.py", line
196, in run
    ctx.run(self._callback, *self._args)
  File "C:\ProgramData\Anaconda3\lib\asyncio\futures.py", line 356, in
_set_state
    _copy_future_state(other, future)
  File "C:\ProgramData\Anaconda3\lib\asyncio\futures.py", line 335, in
_copy_future_state
    dest.set_result(result)
  File "C:\ProgramData\Anaconda3\lib\asyncio\futures.py", line 237, in
set_result
    self.__schedule_callbacks()
  File "C:\ProgramData\Anaconda3\lib\asyncio\futures.py", line 149, in
__schedule_callbacks
    self._loop.call_soon(callback, self, context=ctx)
Traceback (most recent call last):
  File "C:\ProgramData\Anaconda3\lib\site-packages\nest_asyncio.py", line
196, in run
    ctx.run(self._callback, *self._args)
  File "C:\ProgramData\Anaconda3\lib\asyncio\tasks.py", line 762, in
_done_callback
    if outer.done():
NameError: free variable 'outer' referenced before assignment in enclosing
scope

After I upgraded python to 3.9.7 and overwrite task.py, a different error
(but also in asyncio stack):

2022-02-26 06:48:27,047 casin0: @slack algo_order.id: 13 #8 Algo tick level
error casin0 uat <class 'RuntimeError'> Non-thread-safe operation invoked
on an event loop other than the current one Traceback (most recent call
last):
  File "C:\dev\xxx.py", line 547, in xxx
    await asyncio.sleep(algo.param.interval_ms / 1000)
  File "C:\ProgramData\Anaconda3\lib\asyncio\tasks.py", line 651, in sleep
    h = loop.call_later(delay,
  File "C:\ProgramData\Anaconda3\lib\asyncio\base_events.py", line 714, in
call_later
    timer = self.call_at(self.time() + delay, callback, *args,
  File "C:\ProgramData\Anaconda3\lib\asyncio\base_events.py", line 727, in
call_at
    self._check_thread()
  File "C:\ProgramData\Anaconda3\lib\asyncio\base_events.py", line 785, in
_check_thread
    raise RuntimeError(
RuntimeError: Non-thread-safe operation invoked on an event loop other than
the current one

On Sat, Feb 26, 2022 at 2:36 PM Andrew Svetlov <report at bugs.python.org>
wrote:

>
> Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:
>
> Also, fix is 1 week old. There are no python releases with the fix
> included yet.
>
> On Sat, Feb 26, 2022, 06:58 Norman Fung <report at bugs.python.org> wrote:
>
> >
> > Norman Fung <norman.lm.fung at gmail.com> added the comment:
> >
> > Thanks Jelle, let me try upgrade first.
> >
> > Norman
> >
> > On Sat, Feb 26, 2022 at 9:27 AM Jelle Zijlstra <report at bugs.python.org>
> > wrote:
> >
> > >
> > > Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:
> > >
> > > 3.8 is only receiving security fixes now. Please upgrade. If you cannot
> > > upgrade, I suggest manually applying the patch from
> > > https://github.com/python/cpython/pull/31441/files to your
> installation
> > > of Python.
> > >
> > > ----------
> > > nosy: +Jelle Zijlstra
> > > resolution:  -> out of date
> > > stage:  -> resolved
> > > status: open -> closed
> > >
> > > _______________________________________
> > > Python tracker <report at bugs.python.org>
> > > <https://bugs.python.org/issue46859>
> > > _______________________________________
> > >
> >
> > ----------
> >
> > _______________________________________
> > Python tracker <report at bugs.python.org>
> > <https://bugs.python.org/issue46859>
> > _______________________________________
> >
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue46859>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46859>
_______________________________________

From report at bugs.python.org  Sat Feb 26 02:22:28 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Sat, 26 Feb 2022 07:22:28 +0000
Subject: [issue46712] Share global string identifiers in deepfreeze
In-Reply-To: <1644502683.1.0.673362326219.issue46712@roundup.psfhosted.org>
Message-ID: <1645860148.25.0.724051640247.issue46712@roundup.psfhosted.org>


Change by Kumar Aditya <rahuladitya303 at gmail.com>:


----------
pull_requests: +29718
pull_request: https://github.com/python/cpython/pull/31596

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46712>
_______________________________________

From report at bugs.python.org  Sat Feb 26 02:23:43 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Sat, 26 Feb 2022 07:23:43 +0000
Subject: [issue46430] intern strings in deepfrozen modules
In-Reply-To: <1642590983.92.0.896257318647.issue46430@roundup.psfhosted.org>
Message-ID: <1645860223.66.0.522215971754.issue46430@roundup.psfhosted.org>


Change by Kumar Aditya <rahuladitya303 at gmail.com>:


----------
pull_requests: +29719
pull_request: https://github.com/python/cpython/pull/31596

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46430>
_______________________________________

From report at bugs.python.org  Sat Feb 26 02:44:14 2022
From: report at bugs.python.org (Norman Fung)
Date: Sat, 26 Feb 2022 07:44:14 +0000
Subject: [issue46859] NameError: free variable 'outer' referenced before
 assignment in enclosing scope
In-Reply-To: <CAJxNEcv7O311RjtcF5g3kAUsTE2ynCVSc5y_Ahx2kLW8PKB7Pg@mail.gmail.com>
Message-ID: <CAJxNEcueS+EFC9HaVxGFAmOa2R_Rxrrw06pWQr4dFSENPDHH3A@mail.gmail.com>


Norman Fung <norman.lm.fung at gmail.com> added the comment:

Also, i reverted back to python 3.8.5 and overwrote task.py as recommended.
I think that version we dont already have "GenericAlias".

    import asyncio
  File "C:\ProgramData\Anaconda3\lib\asyncio\__init__.py", line 8, in
<module>
    from .base_events import *
  File "C:\ProgramData\Anaconda3\lib\asyncio\base_events.py", line 45, in
<module>
    from . import staggered
  File "C:\ProgramData\Anaconda3\lib\asyncio\staggered.py", line 11, in
<module>
    from . import tasks
  File "C:\ProgramData\Anaconda3\lib\asyncio\tasks.py", line 20, in <module>
    from types import GenericAlias
ImportError: cannot import name 'GenericAlias' from 'types'
(C:\ProgramData\Anaconda3\lib\types.py)

On Sat, Feb 26, 2022 at 3:20 PM Norman Fung <report at bugs.python.org> wrote:

>
> Norman Fung <norman.lm.fung at gmail.com> added the comment:
>
> Thanks Andrew for heads up.
>
> *1. My laptop (Windows 10) *with no changes runs happily with no error from
> here.
>     python 3.8.5
>     asyncio 3.4.3
>
> 2. *My Windows VM (AWS EC2)* is where the whole mess is happening. I
> *upgraded
> *from Python 3.8.5 to 3.9.7. Asynio stayed 3.4.3, no change.
>
> I manually overwrite C:\ProgramData\Anaconda3\Lib\asyncio\task.py with
> what's here https://github.com/python/cpython/pull/31441/files
> (Only
>
> https://github.com/asvetlov/cpython/blob/150ef068c77abc6a5e7ba97397ac65113dba355a/Lib/asyncio/tasks.py
> )
>
> Before I made this change, the error was:
>   File "src\xxx\xxx.py", line 37, in _invoke_runners
>     one_loop.run_until_complete(runner.xxx(xxx, xxx))
>   File "C:\ProgramData\Anaconda3\lib\site-packages\nest_asyncio.py", line
> 90, in run_until_complete
>     self._run_once()
>   File "C:\ProgramData\Anaconda3\lib\site-packages\nest_asyncio.py", line
> 127, in _run_once
>     handle._run()
>   File "C:\ProgramData\Anaconda3\lib\site-packages\nest_asyncio.py", line
> 196, in run
>     ctx.run(self._callback, *self._args)
>   File "C:\ProgramData\Anaconda3\lib\asyncio\futures.py", line 356, in
> _set_state
>     _copy_future_state(other, future)
>   File "C:\ProgramData\Anaconda3\lib\asyncio\futures.py", line 335, in
> _copy_future_state
>     dest.set_result(result)
>   File "C:\ProgramData\Anaconda3\lib\asyncio\futures.py", line 237, in
> set_result
>     self.__schedule_callbacks()
>   File "C:\ProgramData\Anaconda3\lib\asyncio\futures.py", line 149, in
> __schedule_callbacks
>     self._loop.call_soon(callback, self, context=ctx)
> Traceback (most recent call last):
>   File "C:\ProgramData\Anaconda3\lib\site-packages\nest_asyncio.py", line
> 196, in run
>     ctx.run(self._callback, *self._args)
>   File "C:\ProgramData\Anaconda3\lib\asyncio\tasks.py", line 762, in
> _done_callback
>     if outer.done():
> NameError: free variable 'outer' referenced before assignment in enclosing
> scope
>
> After I upgraded python to 3.9.7 and overwrite task.py, a different error
> (but also in asyncio stack):
>
> 2022-02-26 06:48:27,047 casin0: @slack algo_order.id: 13 #8 Algo tick
> level
> error casin0 uat <class 'RuntimeError'> Non-thread-safe operation invoked
> on an event loop other than the current one Traceback (most recent call
> last):
>   File "C:\dev\xxx.py", line 547, in xxx
>     await asyncio.sleep(algo.param.interval_ms / 1000)
>   File "C:\ProgramData\Anaconda3\lib\asyncio\tasks.py", line 651, in sleep
>     h = loop.call_later(delay,
>   File "C:\ProgramData\Anaconda3\lib\asyncio\base_events.py", line 714, in
> call_later
>     timer = self.call_at(self.time() + delay, callback, *args,
>   File "C:\ProgramData\Anaconda3\lib\asyncio\base_events.py", line 727, in
> call_at
>     self._check_thread()
>   File "C:\ProgramData\Anaconda3\lib\asyncio\base_events.py", line 785, in
> _check_thread
>     raise RuntimeError(
> RuntimeError: Non-thread-safe operation invoked on an event loop other than
> the current one
>
> On Sat, Feb 26, 2022 at 2:36 PM Andrew Svetlov <report at bugs.python.org>
> wrote:
>
> >
> > Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:
> >
> > Also, fix is 1 week old. There are no python releases with the fix
> > included yet.
> >
> > On Sat, Feb 26, 2022, 06:58 Norman Fung <report at bugs.python.org> wrote:
> >
> > >
> > > Norman Fung <norman.lm.fung at gmail.com> added the comment:
> > >
> > > Thanks Jelle, let me try upgrade first.
> > >
> > > Norman
> > >
> > > On Sat, Feb 26, 2022 at 9:27 AM Jelle Zijlstra <report at bugs.python.org
> >
> > > wrote:
> > >
> > > >
> > > > Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:
> > > >
> > > > 3.8 is only receiving security fixes now. Please upgrade. If you
> cannot
> > > > upgrade, I suggest manually applying the patch from
> > > > https://github.com/python/cpython/pull/31441/files to your
> > installation
> > > > of Python.
> > > >
> > > > ----------
> > > > nosy: +Jelle Zijlstra
> > > > resolution:  -> out of date
> > > > stage:  -> resolved
> > > > status: open -> closed
> > > >
> > > > _______________________________________
> > > > Python tracker <report at bugs.python.org>
> > > > <https://bugs.python.org/issue46859>
> > > > _______________________________________
> > > >
> > >
> > > ----------
> > >
> > > _______________________________________
> > > Python tracker <report at bugs.python.org>
> > > <https://bugs.python.org/issue46859>
> > > _______________________________________
> > >
> >
> > ----------
> >
> > _______________________________________
> > Python tracker <report at bugs.python.org>
> > <https://bugs.python.org/issue46859>
> > _______________________________________
> >
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue46859>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46859>
_______________________________________

From report at bugs.python.org  Sat Feb 26 02:46:36 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Sat, 26 Feb 2022 07:46:36 +0000
Subject: [issue44011] Borrow asyncio ssl implementation from uvloop
In-Reply-To: <1619987620.01.0.201978044819.issue44011@roundup.psfhosted.org>
Message-ID: <1645861596.2.0.494452651511.issue44011@roundup.psfhosted.org>


Change by Kumar Aditya <rahuladitya303 at gmail.com>:


----------
pull_requests: +29720
pull_request: https://github.com/python/cpython/pull/31597

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44011>
_______________________________________

From report at bugs.python.org  Sat Feb 26 03:13:25 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Sat, 26 Feb 2022 08:13:25 +0000
Subject: [issue37179] asyncio loop.start_tls() provide support for TLS in TLS
In-Reply-To: <1559843713.76.0.0171515478407.issue37179@roundup.psfhosted.org>
Message-ID: <1645863205.63.0.488001405467.issue37179@roundup.psfhosted.org>


Kumar Aditya <rahuladitya303 at gmail.com> added the comment:

This has been fixed in the main branch since https://github.com/python/cpython/pull/31275, this can be closed now.

----------
nosy: +kumaraditya303

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37179>
_______________________________________

From report at bugs.python.org  Sat Feb 26 03:15:37 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Sat, 26 Feb 2022 08:15:37 +0000
Subject: [issue37179] asyncio loop.start_tls() provide support for TLS in TLS
In-Reply-To: <1559843713.76.0.0171515478407.issue37179@roundup.psfhosted.org>
Message-ID: <1645863337.91.0.282859861707.issue37179@roundup.psfhosted.org>


Change by Kumar Aditya <rahuladitya303 at gmail.com>:


----------
type:  -> enhancement
versions: +Python 3.11 -Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37179>
_______________________________________

From report at bugs.python.org  Sat Feb 26 03:33:24 2022
From: report at bugs.python.org (Christian Buhtz)
Date: Sat, 26 Feb 2022 08:33:24 +0000
Subject: [issue46833] Windows installer is unclear and has redundant settings
In-Reply-To: <1645604528.5.0.846357801282.issue46833@roundup.psfhosted.org>
Message-ID: <1645864404.71.0.354404975696.issue46833@roundup.psfhosted.org>


Christian Buhtz <c.buhtz at posteo.jp> added the comment:

Dear Steve,
thanks for your feedback. I did not understand all details of your design decisions but I am OK with that.

Variant A is fine for me, too. The important to points of A for me are 1) that the checkboxes on page 1 are moved up directly under the "Install Now" to make clear where they belong to and 2) the (easier to understand) separation between interpreter- (page2) and launcher-settings (page3).

My apologize but I am not able to create PRs/patches. I am not familiar with your development environment and not able to invest time to learn it because in the feature it does not seems like I will create more patches for something because I do not have the expertise for a python interpreter.

But I understand that is a question of resources. If there are currently now resources I would recommend to keep this ticket open.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46833>
_______________________________________

From report at bugs.python.org  Sat Feb 26 03:36:30 2022
From: report at bugs.python.org (=?utf-8?b?5ZCE5YuZ5YSq5rGw?=)
Date: Sat, 26 Feb 2022 08:36:30 +0000
Subject: [issue46833] Windows installer is unclear and has redundant settings
In-Reply-To: <1645604528.5.0.846357801282.issue46833@roundup.psfhosted.org>
Message-ID: <1645864590.09.0.201747820327.issue46833@roundup.psfhosted.org>


???? <h30-04213 at koto.ed.jp> added the comment:

?????????????

----------
nosy: +h30-04213
Added file: https://bugs.python.org/file50645/??????? (????)?Benesse?????????????????????.pdf

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46833>
_______________________________________

From report at bugs.python.org  Sat Feb 26 03:49:05 2022
From: report at bugs.python.org (Inada Naoki)
Date: Sat, 26 Feb 2022 08:49:05 +0000
Subject: [issue46864] Deprecate ob_shash in BytesObject
Message-ID: <1645865345.09.0.509753942233.issue46864@roundup.psfhosted.org>


New submission from Inada Naoki <songofacandy at gmail.com>:

Code objects have more and more bytes attributes for now.
To reduce the RAM by code, I want to remove ob_shash (cached hash value) from bytes object.

Sets and dicts have own hash cache.
Unless checking same bytes object against dicts/sets many times, this don't cause big performance loss.

----------
components: Interpreter Core
messages: 414083
nosy: methane
priority: normal
severity: normal
status: open
title: Deprecate ob_shash in BytesObject
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46864>
_______________________________________

From report at bugs.python.org  Sat Feb 26 03:49:46 2022
From: report at bugs.python.org (Inada Naoki)
Date: Sat, 26 Feb 2022 08:49:46 +0000
Subject: [issue46864] Deprecate ob_shash in BytesObject
In-Reply-To: <1645865345.09.0.509753942233.issue46864@roundup.psfhosted.org>
Message-ID: <1645865386.29.0.782580026467.issue46864@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
keywords: +patch
pull_requests: +29721
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31598

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46864>
_______________________________________

From report at bugs.python.org  Sat Feb 26 03:56:42 2022
From: report at bugs.python.org (Norman Fung)
Date: Sat, 26 Feb 2022 08:56:42 +0000
Subject: [issue46859] NameError: free variable 'outer' referenced before
 assignment in enclosing scope
In-Reply-To: <CAJxNEcueS+EFC9HaVxGFAmOa2R_Rxrrw06pWQr4dFSENPDHH3A@mail.gmail.com>
Message-ID: <CAJxNEcs_aX3WadA4AgHKw-cf190DYaUD-rsWgXh1os3kWg6O0A@mail.gmail.com>


Norman Fung <norman.lm.fung at gmail.com> added the comment:

I tried hacking tasks.py (After revert back to Python 3.8.5), it
didn't work: Error disappeared, but essentially the program execution
freezed.

def _done_callback(fut):
        ... more ...

        try: outer
        except NameError: outer = None
        if outer is None or outer.done():
            if not fut.cancelled():
                # Mark exception retrieved.
                fut.exception()
            return
    ... more code here ...

    arg_to_fut = {}
    children = []
    nfuts = 0
    nfinished = 0
    outer = None    =============> added
    for arg in coros_or_futures:
        if arg not in arg_to_fut:
            fut = ensure_future(arg, loop=loop)

Reference: https://github.com/python/cpython/pull/31441/files

On Sat, Feb 26, 2022 at 3:44 PM Norman Fung <report at bugs.python.org> wrote:

>
> Norman Fung <norman.lm.fung at gmail.com> added the comment:
>
> Also, i reverted back to python 3.8.5 and overwrote task.py as recommended.
> I think that version we dont already have "GenericAlias".
>
>     import asyncio
>   File "C:\ProgramData\Anaconda3\lib\asyncio\__init__.py", line 8, in
> <module>
>     from .base_events import *
>   File "C:\ProgramData\Anaconda3\lib\asyncio\base_events.py", line 45, in
> <module>
>     from . import staggered
>   File "C:\ProgramData\Anaconda3\lib\asyncio\staggered.py", line 11, in
> <module>
>     from . import tasks
>   File "C:\ProgramData\Anaconda3\lib\asyncio\tasks.py", line 20, in
> <module>
>     from types import GenericAlias
> ImportError: cannot import name 'GenericAlias' from 'types'
> (C:\ProgramData\Anaconda3\lib\types.py)
>
> On Sat, Feb 26, 2022 at 3:20 PM Norman Fung <report at bugs.python.org>
> wrote:
>
> >
> > Norman Fung <norman.lm.fung at gmail.com> added the comment:
> >
> > Thanks Andrew for heads up.
> >
> > *1. My laptop (Windows 10) *with no changes runs happily with no error
> from
> > here.
> >     python 3.8.5
> >     asyncio 3.4.3
> >
> > 2. *My Windows VM (AWS EC2)* is where the whole mess is happening. I
> > *upgraded
> > *from Python 3.8.5 to 3.9.7. Asynio stayed 3.4.3, no change.
> >
> > I manually overwrite C:\ProgramData\Anaconda3\Lib\asyncio\task.py with
> > what's here https://github.com/python/cpython/pull/31441/files
> > (Only
> >
> >
> https://github.com/asvetlov/cpython/blob/150ef068c77abc6a5e7ba97397ac65113dba355a/Lib/asyncio/tasks.py
> > )
> >
> > Before I made this change, the error was:
> >   File "src\xxx\xxx.py", line 37, in _invoke_runners
> >     one_loop.run_until_complete(runner.xxx(xxx, xxx))
> >   File "C:\ProgramData\Anaconda3\lib\site-packages\nest_asyncio.py", line
> > 90, in run_until_complete
> >     self._run_once()
> >   File "C:\ProgramData\Anaconda3\lib\site-packages\nest_asyncio.py", line
> > 127, in _run_once
> >     handle._run()
> >   File "C:\ProgramData\Anaconda3\lib\site-packages\nest_asyncio.py", line
> > 196, in run
> >     ctx.run(self._callback, *self._args)
> >   File "C:\ProgramData\Anaconda3\lib\asyncio\futures.py", line 356, in
> > _set_state
> >     _copy_future_state(other, future)
> >   File "C:\ProgramData\Anaconda3\lib\asyncio\futures.py", line 335, in
> > _copy_future_state
> >     dest.set_result(result)
> >   File "C:\ProgramData\Anaconda3\lib\asyncio\futures.py", line 237, in
> > set_result
> >     self.__schedule_callbacks()
> >   File "C:\ProgramData\Anaconda3\lib\asyncio\futures.py", line 149, in
> > __schedule_callbacks
> >     self._loop.call_soon(callback, self, context=ctx)
> > Traceback (most recent call last):
> >   File "C:\ProgramData\Anaconda3\lib\site-packages\nest_asyncio.py", line
> > 196, in run
> >     ctx.run(self._callback, *self._args)
> >   File "C:\ProgramData\Anaconda3\lib\asyncio\tasks.py", line 762, in
> > _done_callback
> >     if outer.done():
> > NameError: free variable 'outer' referenced before assignment in
> enclosing
> > scope
> >
> > After I upgraded python to 3.9.7 and overwrite task.py, a different error
> > (but also in asyncio stack):
> >
> > 2022-02-26 06:48:27,047 casin0: @slack algo_order.id: 13 #8 Algo tick
> > level
> > error casin0 uat <class 'RuntimeError'> Non-thread-safe operation invoked
> > on an event loop other than the current one Traceback (most recent call
> > last):
> >   File "C:\dev\xxx.py", line 547, in xxx
> >     await asyncio.sleep(algo.param.interval_ms / 1000)
> >   File "C:\ProgramData\Anaconda3\lib\asyncio\tasks.py", line 651, in
> sleep
> >     h = loop.call_later(delay,
> >   File "C:\ProgramData\Anaconda3\lib\asyncio\base_events.py", line 714,
> in
> > call_later
> >     timer = self.call_at(self.time() + delay, callback, *args,
> >   File "C:\ProgramData\Anaconda3\lib\asyncio\base_events.py", line 727,
> in
> > call_at
> >     self._check_thread()
> >   File "C:\ProgramData\Anaconda3\lib\asyncio\base_events.py", line 785,
> in
> > _check_thread
> >     raise RuntimeError(
> > RuntimeError: Non-thread-safe operation invoked on an event loop other
> than
> > the current one
> >
> > On Sat, Feb 26, 2022 at 2:36 PM Andrew Svetlov <report at bugs.python.org>
> > wrote:
> >
> > >
> > > Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:
> > >
> > > Also, fix is 1 week old. There are no python releases with the fix
> > > included yet.
> > >
> > > On Sat, Feb 26, 2022, 06:58 Norman Fung <report at bugs.python.org>
> wrote:
> > >
> > > >
> > > > Norman Fung <norman.lm.fung at gmail.com> added the comment:
> > > >
> > > > Thanks Jelle, let me try upgrade first.
> > > >
> > > > Norman
> > > >
> > > > On Sat, Feb 26, 2022 at 9:27 AM Jelle Zijlstra <
> report at bugs.python.org
> > >
> > > > wrote:
> > > >
> > > > >
> > > > > Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:
> > > > >
> > > > > 3.8 is only receiving security fixes now. Please upgrade. If you
> > cannot
> > > > > upgrade, I suggest manually applying the patch from
> > > > > https://github.com/python/cpython/pull/31441/files to your
> > > installation
> > > > > of Python.
> > > > >
> > > > > ----------
> > > > > nosy: +Jelle Zijlstra
> > > > > resolution:  -> out of date
> > > > > stage:  -> resolved
> > > > > status: open -> closed
> > > > >
> > > > > _______________________________________
> > > > > Python tracker <report at bugs.python.org>
> > > > > <https://bugs.python.org/issue46859>
> > > > > _______________________________________
> > > > >
> > > >
> > > > ----------
> > > >
> > > > _______________________________________
> > > > Python tracker <report at bugs.python.org>
> > > > <https://bugs.python.org/issue46859>
> > > > _______________________________________
> > > >
> > >
> > > ----------
> > >
> > > _______________________________________
> > > Python tracker <report at bugs.python.org>
> > > <https://bugs.python.org/issue46859>
> > > _______________________________________
> > >
> >
> > ----------
> >
> > _______________________________________
> > Python tracker <report at bugs.python.org>
> > <https://bugs.python.org/issue46859>
> > _______________________________________
> >
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue46859>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46859>
_______________________________________

From report at bugs.python.org  Sat Feb 26 03:58:09 2022
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 26 Feb 2022 08:58:09 +0000
Subject: [issue28824] os.environ should preserve the case of the OS keys ?
In-Reply-To: <1480359346.4.0.287394822331.issue28824@psf.upfronthosting.co.za>
Message-ID: <1645865889.28.0.907625741847.issue28824@roundup.psfhosted.org>


Change by Larry Hastings <larry at hastings.org>:


----------
nosy:  -larry, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28824>
_______________________________________

From report at bugs.python.org  Sat Feb 26 04:01:49 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Sat, 26 Feb 2022 09:01:49 +0000
Subject: [issue46541] Replace _Py_IDENTIFIER() with statically initialized
 objects.
In-Reply-To: <1643234464.46.0.949364478641.issue46541@roundup.psfhosted.org>
Message-ID: <1645866109.53.0.539353847723.issue46541@roundup.psfhosted.org>


Change by Kumar Aditya <rahuladitya303 at gmail.com>:


----------
pull_requests: +29722
pull_request: https://github.com/python/cpython/pull/31599

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46541>
_______________________________________

From report at bugs.python.org  Sat Feb 26 04:04:32 2022
From: report at bugs.python.org (Robert Spralja)
Date: Sat, 26 Feb 2022 09:04:32 +0000
Subject: [issue46865] *() Invalid Syntax: iterable unpacking of empty tuple
Message-ID: <1645866272.11.0.779642676261.issue46865@roundup.psfhosted.org>


New submission from Robert Spralja <robert.spralja at gmail.com>:

`
>>> def foo(num=1):
...     return num
...
>>> foo(*(bool,) is bool else *())
  File "<stdin>", line 1
    foo(*(bool,) is bool else *())
                         ^
SyntaxError: invalid syntax
>>> foo(*(bool,) if bool else *())
  File "<stdin>", line 1
    foo(*(bool,) if bool else *())
                              ^
SyntaxError: invalid syntax
>>> def foo(num=1):
...     return num
...
>>> stri = ''
>>> foo(*(stri,) if stri else *())
  File "<stdin>", line 1
    foo(*(stri,) if stri else *())
                              ^
SyntaxError: invalid syntax
>>> foo(*((stri,) if stri else ()))
1
>>>
`

Iterable unpacking of empty tuple seems to not work in one example but does in another.

----------
messages: 414085
nosy: spralja
priority: normal
severity: normal
status: open
title: *() Invalid Syntax: iterable unpacking of empty tuple
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46865>
_______________________________________

From report at bugs.python.org  Sat Feb 26 04:07:18 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 26 Feb 2022 09:07:18 +0000
Subject: [issue46865] *() Invalid Syntax: iterable unpacking of empty tuple
In-Reply-To: <1645866272.11.0.779642676261.issue46865@roundup.psfhosted.org>
Message-ID: <1645866438.37.0.762793560375.issue46865@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It is an invalid syntax. Write foo(*((stri,) if stri else ())).

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46865>
_______________________________________

From report at bugs.python.org  Sat Feb 26 04:09:46 2022
From: report at bugs.python.org (Robert Spralja)
Date: Sat, 26 Feb 2022 09:09:46 +0000
Subject: [issue46865] *() Invalid Syntax: iterable unpacking of empty tuple
In-Reply-To: <1645866438.37.0.762793560375.issue46865@roundup.psfhosted.org>
Message-ID: <CABenZofvAJUsHHhe74+n+uX4dbSSWEaA0vU1HiekmdN8tpVuFg@mail.gmail.com>


Robert Spralja <robert.spralja at gmail.com> added the comment:

I understand that it's invalid synatax, but not why.

On Sat, 26 Feb 2022 at 10:07, Serhiy Storchaka <report at bugs.python.org>
wrote:

>
> Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:
>
> It is an invalid syntax. Write foo(*((stri,) if stri else ())).
>
> ----------
> nosy: +serhiy.storchaka
> resolution:  -> not a bug
> stage:  -> resolved
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue46865>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46865>
_______________________________________

From report at bugs.python.org  Sat Feb 26 05:09:17 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 26 Feb 2022 10:09:17 +0000
Subject: [issue46865] *() Invalid Syntax: iterable unpacking of empty tuple
In-Reply-To: <1645866272.11.0.779642676261.issue46865@roundup.psfhosted.org>
Message-ID: <1645870157.31.0.0895280967494.issue46865@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

See the grammar. https://docs.python.org/3/reference/expressions.html#conditional-expressions


conditional_expression ::=  or_test ["if" or_test "else" expression]
expression             ::=  conditional_expression | lambda_expr

`*()` is not an expression. It is either a starred_item (which can be a part of starred_list or a starred_expression), or a positional_item or a starred_and_keywords which are parts of an argument_list. None of them are expressions.

`foo(*(stri,) if stri else x)` is interpreted as `foo(*((stri,) if stri else x))` if x is an expression. But `*()` is not an expression, thus a syntax error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46865>
_______________________________________

From report at bugs.python.org  Sat Feb 26 05:23:59 2022
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 26 Feb 2022 10:23:59 +0000
Subject: [issue46863] Python 3.10 OpenSSL Configuration Issues
In-Reply-To: <1645852366.6.0.130545163871.issue46863@roundup.psfhosted.org>
Message-ID: <1645871039.02.0.120752658412.issue46863@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

How did you build Python 3.10? Neither CentOS 8 nor Ubuntu 20.04 come with Python 3.10. Does your build of Python use system's OpenSSL build?

----------
assignee: christian.heimes -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46863>
_______________________________________

From report at bugs.python.org  Sat Feb 26 05:36:44 2022
From: report at bugs.python.org (Norman Fung)
Date: Sat, 26 Feb 2022 10:36:44 +0000
Subject: [issue46859] NameError: free variable 'outer' referenced before
 assignment in enclosing scope
In-Reply-To: <CAJxNEcs_aX3WadA4AgHKw-cf190DYaUD-rsWgXh1os3kWg6O0A@mail.gmail.com>
Message-ID: <CAJxNEcvYt2_N=es1x4-OCD1pRA3kbG1yivJJ94fw1YmTqJ0ngg@mail.gmail.com>


Norman Fung <norman.lm.fung at gmail.com> added the comment:

I think this will work, i need to test further but it seems to work on
python 3.8.5. I think the prev fix didnt really fix it. And the core of the
problem was " _done_callback" fired before "outer" was defined by "
_GatheringFuture" .  Have a look at "Look here" below.
Let me know if you agree, or otherwise. Thanks

def gather(*coros_or_futures, loop=None, return_exceptions=False):
    if not coros_or_futures:
        if loop is None:
            loop = events.get_event_loop()
        else:
            warnings.warn("The loop argument is deprecated since Python
3.8, "
                          "and scheduled for removal in Python 3.10.",
                          DeprecationWarning, stacklevel=2)
        outer = loop.create_future()
        outer.set_result([])
        return outer

    def _done_callback(fut):
        while not outer: <==== Look here
            print(f"scream ... you can't just return")

        nonlocal nfinished
        nfinished += 1

        if outer.done():
            if not fut.cancelled():
                # Mark exception retrieved.
                fut.exception()
            return

        if not return_exceptions:
            if fut.cancelled():
                # Check if 'fut' is cancelled first, as
                # 'fut.exception()' will *raise* a CancelledError
                # instead of returning it.
                exc = exceptions.CancelledError()
                outer.set_exception(exc)
                return
            else:
                exc = fut.exception()
                if exc is not None:
                    outer.set_exception(exc)
                    return

        if nfinished == nfuts:
            # All futures are done; create a list of results
            # and set it to the 'outer' future.
            results = []

            for fut in children:
                if fut.cancelled():
                    # Check if 'fut' is cancelled first, as
                    # 'fut.exception()' will *raise* a CancelledError
                    # instead of returning it.
                    res = exceptions.CancelledError()
                else:
                    res = fut.exception()
                    if res is None:
                        res = fut.result()
                results.append(res)

            if outer._cancel_requested:
                # If gather is being cancelled we must propagate the
                # cancellation regardless of *return_exceptions* argument.
                # See issue 32684.
                outer.set_exception(exceptions.CancelledError())
            else:
                outer.set_result(results)

    arg_to_fut = {}
    children = []
    nfuts = 0
    nfinished = 0
    outer = None <==== Look here, need at least define the variable
    for arg in coros_or_futures:
        if arg not in arg_to_fut:
            fut = ensure_future(arg, loop=loop)
            if loop is None:
                loop = futures._get_loop(fut)
            if fut is not arg:
                # 'arg' was not a Future, therefore, 'fut' is a new
                # Future created specifically for 'arg'.  Since the caller
                # can't control it, disable the "destroy pending task"
                # warning.
                fut._log_destroy_pending = False

            nfuts += 1
            arg_to_fut[arg] = fut
            fut.add_done_callback(_done_callback) <==== Look here,
_done_callback fired before _GatheringFuture got a chance to return
"outer"!?

        else:
            # There's a duplicate Future object in coros_or_futures.
            fut = arg_to_fut[arg]

        children.append(fut)

    outer = _GatheringFuture(children, loop=loop)   <==== Look here,
"outer" defined only here.
    return outer

On Sat, Feb 26, 2022 at 4:56 PM Norman Fung <report at bugs.python.org> wrote:

>
> Norman Fung <norman.lm.fung at gmail.com> added the comment:
>
> I tried hacking tasks.py (After revert back to Python 3.8.5), it
> didn't work: Error disappeared, but essentially the program execution
> freezed.
>
> def _done_callback(fut):
>         ... more ...
>
>         try: outer
>         except NameError: outer = None
>         if outer is None or outer.done():
>             if not fut.cancelled():
>                 # Mark exception retrieved.
>                 fut.exception()
>             return
>     ... more code here ...
>
>     arg_to_fut = {}
>     children = []
>     nfuts = 0
>     nfinished = 0
>     outer = None    =============> added
>     for arg in coros_or_futures:
>         if arg not in arg_to_fut:
>             fut = ensure_future(arg, loop=loop)
>
> Reference: https://github.com/python/cpython/pull/31441/files
>
> On Sat, Feb 26, 2022 at 3:44 PM Norman Fung <report at bugs.python.org>
> wrote:
>
> >
> > Norman Fung <norman.lm.fung at gmail.com> added the comment:
> >
> > Also, i reverted back to python 3.8.5 and overwrote task.py as
> recommended.
> > I think that version we dont already have "GenericAlias".
> >
> >     import asyncio
> >   File "C:\ProgramData\Anaconda3\lib\asyncio\__init__.py", line 8, in
> > <module>
> >     from .base_events import *
> >   File "C:\ProgramData\Anaconda3\lib\asyncio\base_events.py", line 45, in
> > <module>
> >     from . import staggered
> >   File "C:\ProgramData\Anaconda3\lib\asyncio\staggered.py", line 11, in
> > <module>
> >     from . import tasks
> >   File "C:\ProgramData\Anaconda3\lib\asyncio\tasks.py", line 20, in
> > <module>
> >     from types import GenericAlias
> > ImportError: cannot import name 'GenericAlias' from 'types'
> > (C:\ProgramData\Anaconda3\lib\types.py)
> >
> > On Sat, Feb 26, 2022 at 3:20 PM Norman Fung <report at bugs.python.org>
> > wrote:
> >
> > >
> > > Norman Fung <norman.lm.fung at gmail.com> added the comment:
> > >
> > > Thanks Andrew for heads up.
> > >
> > > *1. My laptop (Windows 10) *with no changes runs happily with no error
> > from
> > > here.
> > >     python 3.8.5
> > >     asyncio 3.4.3
> > >
> > > 2. *My Windows VM (AWS EC2)* is where the whole mess is happening. I
> > > *upgraded
> > > *from Python 3.8.5 to 3.9.7. Asynio stayed 3.4.3, no change.
> > >
> > > I manually overwrite C:\ProgramData\Anaconda3\Lib\asyncio\task.py with
> > > what's here https://github.com/python/cpython/pull/31441/files
> > > (Only
> > >
> > >
> >
> https://github.com/asvetlov/cpython/blob/150ef068c77abc6a5e7ba97397ac65113dba355a/Lib/asyncio/tasks.py
> > > )
> > >
> > > Before I made this change, the error was:
> > >   File "src\xxx\xxx.py", line 37, in _invoke_runners
> > >     one_loop.run_until_complete(runner.xxx(xxx, xxx))
> > >   File "C:\ProgramData\Anaconda3\lib\site-packages\nest_asyncio.py",
> line
> > > 90, in run_until_complete
> > >     self._run_once()
> > >   File "C:\ProgramData\Anaconda3\lib\site-packages\nest_asyncio.py",
> line
> > > 127, in _run_once
> > >     handle._run()
> > >   File "C:\ProgramData\Anaconda3\lib\site-packages\nest_asyncio.py",
> line
> > > 196, in run
> > >     ctx.run(self._callback, *self._args)
> > >   File "C:\ProgramData\Anaconda3\lib\asyncio\futures.py", line 356, in
> > > _set_state
> > >     _copy_future_state(other, future)
> > >   File "C:\ProgramData\Anaconda3\lib\asyncio\futures.py", line 335, in
> > > _copy_future_state
> > >     dest.set_result(result)
> > >   File "C:\ProgramData\Anaconda3\lib\asyncio\futures.py", line 237, in
> > > set_result
> > >     self.__schedule_callbacks()
> > >   File "C:\ProgramData\Anaconda3\lib\asyncio\futures.py", line 149, in
> > > __schedule_callbacks
> > >     self._loop.call_soon(callback, self, context=ctx)
> > > Traceback (most recent call last):
> > >   File "C:\ProgramData\Anaconda3\lib\site-packages\nest_asyncio.py",
> line
> > > 196, in run
> > >     ctx.run(self._callback, *self._args)
> > >   File "C:\ProgramData\Anaconda3\lib\asyncio\tasks.py", line 762, in
> > > _done_callback
> > >     if outer.done():
> > > NameError: free variable 'outer' referenced before assignment in
> > enclosing
> > > scope
> > >
> > > After I upgraded python to 3.9.7 and overwrite task.py, a different
> error
> > > (but also in asyncio stack):
> > >
> > > 2022-02-26 06:48:27,047 casin0: @slack algo_order.id: 13 #8 Algo tick
> > > level
> > > error casin0 uat <class 'RuntimeError'> Non-thread-safe operation
> invoked
> > > on an event loop other than the current one Traceback (most recent call
> > > last):
> > >   File "C:\dev\xxx.py", line 547, in xxx
> > >     await asyncio.sleep(algo.param.interval_ms / 1000)
> > >   File "C:\ProgramData\Anaconda3\lib\asyncio\tasks.py", line 651, in
> > sleep
> > >     h = loop.call_later(delay,
> > >   File "C:\ProgramData\Anaconda3\lib\asyncio\base_events.py", line 714,
> > in
> > > call_later
> > >     timer = self.call_at(self.time() + delay, callback, *args,
> > >   File "C:\ProgramData\Anaconda3\lib\asyncio\base_events.py", line 727,
> > in
> > > call_at
> > >     self._check_thread()
> > >   File "C:\ProgramData\Anaconda3\lib\asyncio\base_events.py", line 785,
> > in
> > > _check_thread
> > >     raise RuntimeError(
> > > RuntimeError: Non-thread-safe operation invoked on an event loop other
> > than
> > > the current one
> > >
> > > On Sat, Feb 26, 2022 at 2:36 PM Andrew Svetlov <report at bugs.python.org
> >
> > > wrote:
> > >
> > > >
> > > > Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:
> > > >
> > > > Also, fix is 1 week old. There are no python releases with the fix
> > > > included yet.
> > > >
> > > > On Sat, Feb 26, 2022, 06:58 Norman Fung <report at bugs.python.org>
> > wrote:
> > > >
> > > > >
> > > > > Norman Fung <norman.lm.fung at gmail.com> added the comment:
> > > > >
> > > > > Thanks Jelle, let me try upgrade first.
> > > > >
> > > > > Norman
> > > > >
> > > > > On Sat, Feb 26, 2022 at 9:27 AM Jelle Zijlstra <
> > report at bugs.python.org
> > > >
> > > > > wrote:
> > > > >
> > > > > >
> > > > > > Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:
> > > > > >
> > > > > > 3.8 is only receiving security fixes now. Please upgrade. If you
> > > cannot
> > > > > > upgrade, I suggest manually applying the patch from
> > > > > > https://github.com/python/cpython/pull/31441/files to your
> > > > installation
> > > > > > of Python.
> > > > > >
> > > > > > ----------
> > > > > > nosy: +Jelle Zijlstra
> > > > > > resolution:  -> out of date
> > > > > > stage:  -> resolved
> > > > > > status: open -> closed
> > > > > >
> > > > > > _______________________________________
> > > > > > Python tracker <report at bugs.python.org>
> > > > > > <https://bugs.python.org/issue46859>
> > > > > > _______________________________________
> > > > > >
> > > > >
> > > > > ----------
> > > > >
> > > > > _______________________________________
> > > > > Python tracker <report at bugs.python.org>
> > > > > <https://bugs.python.org/issue46859>
> > > > > _______________________________________
> > > > >
> > > >
> > > > ----------
> > > >
> > > > _______________________________________
> > > > Python tracker <report at bugs.python.org>
> > > > <https://bugs.python.org/issue46859>
> > > > _______________________________________
> > > >
> > >
> > > ----------
> > >
> > > _______________________________________
> > > Python tracker <report at bugs.python.org>
> > > <https://bugs.python.org/issue46859>
> > > _______________________________________
> > >
> >
> > ----------
> >
> > _______________________________________
> > Python tracker <report at bugs.python.org>
> > <https://bugs.python.org/issue46859>
> > _______________________________________
> >
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue46859>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46859>
_______________________________________

From report at bugs.python.org  Sat Feb 26 06:15:17 2022
From: report at bugs.python.org (Inada Naoki)
Date: Sat, 26 Feb 2022 11:15:17 +0000
Subject: [issue46845] dict: Use smaller entry for Unicode-key only dict.
In-Reply-To: <1645688455.61.0.00785191075466.issue46845@roundup.psfhosted.org>
Message-ID: <1645874117.01.0.113083918904.issue46845@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

In most case, first PyDict_SetItem decides which format should be used.

But _PyDict_NewPresized() can be a problem. It creates a hash table before inserting the first key, when 5 < (expected size) < 87382.

In CPython code base, _PyDict_NewPresized() is called from three places:

1. call.c: Building kwargs dict -- all key should be Unicode.
2. ceval.c: BUILD_MAP and BUILD_CONST_KEY_MAP -- there is no guarantee that all keys are Unicode.


Current pull request assumes the dict keys are unicode-only key. So building dict from non-Unicode keys become slower.

```
$ ./python -m pyperf timeit --compare-to ../cpython/python -- '{(1,2):3, (4,5):6, (7,8):9, (10,11):12, (13,14):15, (16,17):18}'
/home/inada-n/work/python/cpython/python: ..................... 233 ns +- 1 ns
/home/inada-n/work/python/dict-compact/python: ..................... 328 ns +- 6 ns

Mean +- std dev: [/home/inada-n/work/python/cpython/python] 233 ns +- 1 ns -> [/home/inada-n/work/python/dict-compact/python] 328 ns +- 6 ns: 1.41x slower
```

There are some approaches to fix this problem:

1. Don't use _PyDict_NewPresized() in BUILD_MAP, BUILD_CONST_KEY_MAP

```
$ ./python -m pyperf timeit --compare-to ../cpython/python -- '{(1,2):3, (4,5):6, (7,8):9, (10,11):12, (13,14):15, (16,17):18}'
/home/inada-n/work/python/cpython/python: ..................... 233 ns +- 1 ns
/home/inada-n/work/python/dict-compact/python: ..................... 276 ns +- 1 ns

Mean +- std dev: [/home/inada-n/work/python/cpython/python] 233 ns +- 1 ns -> [/home/inada-n/work/python/dict-compact/python] 276 ns +- 1 ns: 1.18x slower
```

I think this performance regression is acceptable level.

2. Add an argument `unicode` to _PyDict_NewPresized(). -- Breaks some 3rd party codes using internal APIs.
3. Add a new internal C API such that _PyDict_NewPresizedUnicodeKey(). -- Most conservative.
4. Add a new internal C API that creates dict form keys and values for extreme performance, like this:

// Create a new dict from keys and values.
// Items are received as `{keys[i*keys_offset]: values[i*values_offset] for i in range(length)}`.
// When distinct=1, this function skips checking duplicated keys.
// So pass distinct=1 unless you can guarantee that there is no duplicated keys.
PyObject *
PyDict_FromKeysAndValues(PyObject **keys, Py_ssize_t keys_offset, PyObject **values, Py_ssize_t values_offset, Py_ssize_t lenghh, int distincit)
{
}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46845>
_______________________________________

From report at bugs.python.org  Sat Feb 26 06:37:49 2022
From: report at bugs.python.org (Sec)
Date: Sat, 26 Feb 2022 11:37:49 +0000
Subject: [issue46866] bytes class extension with slices
Message-ID: <1645875469.77.0.975365502417.issue46866@roundup.psfhosted.org>


New submission from Sec <sec at 42.org>:

When trying to extend the builtin bytes class, slices fall back to the builtin class.

```
class my_bytes(bytes):
  def dummy(self):
    print("dummy called")


x=my_bytes.fromhex("c0de c0de")
print(x.__class__)

print(x[1:].__class__)

```

x.__class__ returns <class '__main__.my_bytes'> as expected.

But x[1:].__class__ returns <class 'bytes'>

----------
components: Interpreter Core
files: bytes_test.py
messages: 414092
nosy: Sec42
priority: normal
severity: normal
status: open
title: bytes class extension with slices
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file50646/bytes_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46866>
_______________________________________

From report at bugs.python.org  Sat Feb 26 06:56:55 2022
From: report at bugs.python.org (Adam)
Date: Sat, 26 Feb 2022 11:56:55 +0000
Subject: [issue46863] Python 3.10 OpenSSL Configuration Issues
In-Reply-To: <1645852366.6.0.130545163871.issue46863@roundup.psfhosted.org>
Message-ID: <1645876615.21.0.378975356801.issue46863@roundup.psfhosted.org>


Adam <apinckard85 at gmail.com> added the comment:

Thanks for the quick reply. On both Ubuntu and Centos, I?m installing Python using Pyenv, testing with 3.9.10 and 3.10.2. Pyenv provides a verbose install flag, I can rebuild the Python versions and review the build commands, if helpful? I?m testing with clean Linux distributions and I believe there is only one OpenSSL installed and available. I don?t know if it?s possible to gain more details from the Python ssl module to confirm? I did confirm the OpenSSL versions aligns using ssl.OPENSSL_VERSION.

Command: pyenv install 3.10.2 --verbose

https://github.com/pyenv/pyenv

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46863>
_______________________________________

From report at bugs.python.org  Sat Feb 26 07:05:50 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 26 Feb 2022 12:05:50 +0000
Subject: [issue38415] @asynccontextmanager decorated functions are not
 callable like @contextmanager
In-Reply-To: <1570567549.28.0.993731185011.issue38415@roundup.psfhosted.org>
Message-ID: <1645877150.89.0.812038803057.issue38415@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset b57dbe5d1be925b99f16fe5893e339f92fc05888 by Thomas Grainger in branch 'main':
bpo-38415: Remove redundant AsyncContextDecorator.__call__ override from _AsyncGeneratorContextManager (GH-30233)
https://github.com/python/cpython/commit/b57dbe5d1be925b99f16fe5893e339f92fc05888


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38415>
_______________________________________

From report at bugs.python.org  Sat Feb 26 07:08:24 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 26 Feb 2022 12:08:24 +0000
Subject: [issue46866] bytes class extension with slices
In-Reply-To: <1645875469.77.0.975365502417.issue46866@roundup.psfhosted.org>
Message-ID: <1645877304.5.0.314393363157.issue46866@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Yes, it is consistent with all of builtin types. If you want to return a different type, override __getitem__().

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46866>
_______________________________________

From report at bugs.python.org  Sat Feb 26 07:14:43 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 26 Feb 2022 12:14:43 +0000
Subject: [issue46864] Deprecate ob_shash in BytesObject
In-Reply-To: <1645865345.09.0.509753942233.issue46864@roundup.psfhosted.org>
Message-ID: <1645877683.95.0.994605461376.issue46864@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I think it is a legacy of Python 2. Attributes and variable names are Unicode strings in Python 3, so the main reason of this optimization is no longer relevant.

But some programs can still work with encoded bytes instead of strings. In particular os.environ and os.environb are implemented as dict of bytes on non-Windows.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46864>
_______________________________________

From report at bugs.python.org  Sat Feb 26 07:36:06 2022
From: report at bugs.python.org (Adam)
Date: Sat, 26 Feb 2022 12:36:06 +0000
Subject: [issue46863] Python 3.10 OpenSSL Configuration Issues
In-Reply-To: <1645852366.6.0.130545163871.issue46863@roundup.psfhosted.org>
Message-ID: <1645878966.41.0.704171876827.issue46863@roundup.psfhosted.org>


Adam <apinckard85 at gmail.com> added the comment:

I found the Python build recipes and Pyenv does appear to install OpenSSL from source. The only difference I can see, aside from the Python version, is an update on the OpenSSL versions; openssl-1.1.1l (3.9.10) to openssl-1.1.1k (3.10.2). The OpenSSL release notes do not appear to suggest anything relevant.

https://github.com/pyenv/pyenv/blob/master/plugins/python-build/share/python-build/3.10.2

https://github.com/pyenv/pyenv/blob/master/plugins/python-build/share/python-build/3.9.10

https://github.com/pyenv/pyenv/blob/master/plugins/python-build/bin/python-build

https://www.openssl.org/news/openssl-1.1.1-notes.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46863>
_______________________________________

From report at bugs.python.org  Sat Feb 26 07:38:20 2022
From: report at bugs.python.org (tongxiaoge)
Date: Sat, 26 Feb 2022 12:38:20 +0000
Subject: [issue46849] Memory problems detected using Valgrind
In-Reply-To: <1645711886.58.0.922948546021.issue46849@roundup.psfhosted.org>
Message-ID: <1645879100.67.0.114216889491.issue46849@roundup.psfhosted.org>


tongxiaoge <shixuantong at huawei.com> added the comment:

The latest version is also problematic (Python 3.11.0a5). The above is the output stack information. Here are the steps to reproduce:

1. iotop -b -n 10 &

2. valgrind --leak-check=full /usr/sbin/iotop -b -n 5 > iotop_ test

----------
Added file: https://bugs.python.org/file50647/stack-information_python3.11.0a5.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46849>
_______________________________________

From report at bugs.python.org  Sat Feb 26 07:41:52 2022
From: report at bugs.python.org (tongxiaoge)
Date: Sat, 26 Feb 2022 12:41:52 +0000
Subject: [issue46849] Memory problems detected using Valgrind
In-Reply-To: <1645711886.58.0.922948546021.issue46849@roundup.psfhosted.org>
Message-ID: <1645879312.07.0.249877213712.issue46849@roundup.psfhosted.org>


tongxiaoge <shixuantong at huawei.com> added the comment:

I also installed Python3.7.9?Python3. 8.5 tested and found no problems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46849>
_______________________________________

From report at bugs.python.org  Sat Feb 26 08:05:40 2022
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 26 Feb 2022 13:05:40 +0000
Subject: [issue46863] Python 3.10 OpenSSL Configuration Issues
In-Reply-To: <1645852366.6.0.130545163871.issue46863@roundup.psfhosted.org>
Message-ID: <1645880740.17.0.902529453318.issue46863@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

This is a pyenv issue, not a Python issue. Custom builds of OpenSSL typically do not and cannot use global settings like crypto policies. They are missing distro downstream patches and use different config files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46863>
_______________________________________

From report at bugs.python.org  Sat Feb 26 08:06:50 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 26 Feb 2022 13:06:50 +0000
Subject: [issue44011] Borrow asyncio ssl implementation from uvloop
In-Reply-To: <1619987620.01.0.201978044819.issue44011@roundup.psfhosted.org>
Message-ID: <1645880810.54.0.0768011046636.issue44011@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset 41ddcd3f40f8171a396e57b841a74fcc83884eab by Kumar Aditya in branch 'main':
bpo-44011: Document ssl_shutdown_timeout added by revisited asyncio SSL implementation  (GH-31597)
https://github.com/python/cpython/commit/41ddcd3f40f8171a396e57b841a74fcc83884eab


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44011>
_______________________________________

From report at bugs.python.org  Sat Feb 26 08:33:34 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Sat, 26 Feb 2022 13:33:34 +0000
Subject: [issue46318] asyncio and ssl: ResourceWarning: unclosed transport
In-Reply-To: <1641740693.62.0.185226666966.issue46318@roundup.psfhosted.org>
Message-ID: <1645882414.12.0.700784422189.issue46318@roundup.psfhosted.org>


Kumar Aditya <rahuladitya303 at gmail.com> added the comment:

@asvetlov I tested it on main branch and indeed it is fixed on main branch with https://bugs.python.org/issue44011.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46318>
_______________________________________

From report at bugs.python.org  Sat Feb 26 08:39:28 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Sat, 26 Feb 2022 13:39:28 +0000
Subject: [issue46661] Duplicate deprecation warnings in docs for asyncio
In-Reply-To: <1644173025.54.0.0182116442771.issue46661@roundup.psfhosted.org>
Message-ID: <1645882768.54.0.515182290745.issue46661@roundup.psfhosted.org>


Kumar Aditya <rahuladitya303 at gmail.com> added the comment:

This was fixed in https://github.com/python/cpython/pull/31388, so this can be closed now.

----------
nosy: +kumaraditya303

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46661>
_______________________________________

From report at bugs.python.org  Sat Feb 26 09:11:44 2022
From: report at bugs.python.org (Adam)
Date: Sat, 26 Feb 2022 14:11:44 +0000
Subject: [issue46863] Python 3.10 OpenSSL Configuration Issues
In-Reply-To: <1645852366.6.0.130545163871.issue46863@roundup.psfhosted.org>
Message-ID: <1645884704.58.0.535891046159.issue46863@roundup.psfhosted.org>


Adam <apinckard85 at gmail.com> added the comment:

Yes agreed, it may well be a Pyenv issue. Interestingly we can demonstrate that the global OpenSSL crypto policies is respected with the 3.9.10 version, through adjusting the policy. The ssl error occurs with the default policy setting and is resolved with the legacy policy setting. With 3.10.2 this is no longer the case. I can?t see any obvious changes to the build recipe that would cause this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46863>
_______________________________________

From report at bugs.python.org  Sat Feb 26 09:17:03 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Sat, 26 Feb 2022 14:17:03 +0000
Subject: [issue45159] data_received called on protocol after call to
 pause_reading on ssl transport
In-Reply-To: <1631247832.37.0.646410094935.issue45159@roundup.psfhosted.org>
Message-ID: <1645885023.66.0.357528480204.issue45159@roundup.psfhosted.org>


Kumar Aditya <rahuladitya303 at gmail.com> added the comment:

Since https://bugs.python.org/issue44011 is fixed, this can be closed now.

----------
nosy: +kumaraditya303

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45159>
_______________________________________

From report at bugs.python.org  Sat Feb 26 09:18:58 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Sat, 26 Feb 2022 14:18:58 +0000
Subject: [issue45533] loop.sock_connect doesn't resolve the address parameter
 on Windows
In-Reply-To: <1634716632.31.0.427704063338.issue45533@roundup.psfhosted.org>
Message-ID: <1645885138.93.0.088721380815.issue45533@roundup.psfhosted.org>


Kumar Aditya <rahuladitya303 at gmail.com> added the comment:

Can you provide a minimal reproducer otherwise it is hard to know if there is any bug.

----------
nosy: +kumaraditya303

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45533>
_______________________________________

From report at bugs.python.org  Sat Feb 26 09:39:48 2022
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Feb 2022 14:39:48 +0000
Subject: [issue46855] printing a string with strange characters loops forever
In-Reply-To: <1645804177.22.0.124909459168.issue46855@roundup.psfhosted.org>
Message-ID: <1645886388.74.0.246605487603.issue46855@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> added the comment:

Note that the original issue seems to be that you had bytes but pasted it as a unicode string.  This works:

>>> b = b'Betrag gr\xc3\xb6\xc3\x9fer als Betrag der Original-Transaktion'
>>> s = b.decode('utf-8')
>>> print(s)
Betrag gr??er als Betrag der Original-Transaktion

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46855>
_______________________________________

From report at bugs.python.org  Sat Feb 26 09:44:57 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 26 Feb 2022 14:44:57 +0000
Subject: [issue46318] asyncio and ssl: ResourceWarning: unclosed transport
In-Reply-To: <1641740693.62.0.185226666966.issue46318@roundup.psfhosted.org>
Message-ID: <1645886697.97.0.661252195847.issue46318@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Awesome!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46318>
_______________________________________

From report at bugs.python.org  Sat Feb 26 09:45:10 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 26 Feb 2022 14:45:10 +0000
Subject: [issue46318] asyncio and ssl: ResourceWarning: unclosed transport
In-Reply-To: <1641740693.62.0.185226666966.issue46318@roundup.psfhosted.org>
Message-ID: <1645886710.22.0.869980395151.issue46318@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions:  -Python 3.10, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46318>
_______________________________________

From report at bugs.python.org  Sat Feb 26 09:47:06 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 26 Feb 2022 14:47:06 +0000
Subject: [issue45159] data_received called on protocol after call to
 pause_reading on ssl transport
In-Reply-To: <1631247832.37.0.646410094935.issue45159@roundup.psfhosted.org>
Message-ID: <1645886826.35.0.269413355092.issue45159@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.11 -Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45159>
_______________________________________

From report at bugs.python.org  Sat Feb 26 09:51:05 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Sat, 26 Feb 2022 14:51:05 +0000
Subject: [issue42760] inspect.iscoroutine returns False for asynchronous
 generator methods
In-Reply-To: <1609101687.37.0.151159530312.issue42760@roundup.psfhosted.org>
Message-ID: <1645887065.76.0.506107386152.issue42760@roundup.psfhosted.org>


Change by Kumar Aditya <rahuladitya303 at gmail.com>:


----------
nosy: +kumaraditya303

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42760>
_______________________________________

From report at bugs.python.org  Sat Feb 26 10:00:03 2022
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Feb 2022 15:00:03 +0000
Subject: [issue46833] Windows installer is unclear and has redundant settings
In-Reply-To: <1645604528.5.0.846357801282.issue46833@roundup.psfhosted.org>
Message-ID: <1645887603.0.0.813163195007.issue46833@roundup.psfhosted.org>


Change by ?ric Araujo <merwok at netwok.org>:


Removed file: https://bugs.python.org/file50645/??????? (????)?Benesse?????????????????????.pdf

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46833>
_______________________________________

From report at bugs.python.org  Sat Feb 26 10:00:05 2022
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Feb 2022 15:00:05 +0000
Subject: [issue46833] Windows installer is unclear and has redundant settings
In-Reply-To: <1645604528.5.0.846357801282.issue46833@roundup.psfhosted.org>
Message-ID: <1645887605.61.0.0690895755037.issue46833@roundup.psfhosted.org>


Change by ?ric Araujo <merwok at netwok.org>:


----------
Removed message: https://bugs.python.org/msg414082

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46833>
_______________________________________

From report at bugs.python.org  Sat Feb 26 10:05:37 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Sat, 26 Feb 2022 15:05:37 +0000
Subject: [issue46748] Python.h includes stdbool.h
In-Reply-To: <1644830899.62.0.590844926135.issue46748@roundup.psfhosted.org>
Message-ID: <1645887937.52.0.691948324131.issue46748@roundup.psfhosted.org>


Change by Kumar Aditya <rahuladitya303 at gmail.com>:


----------
nosy: +kumaraditya303
nosy_count: 5.0 -> 6.0
pull_requests: +29723
pull_request: https://github.com/python/cpython/pull/31600

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46748>
_______________________________________

From report at bugs.python.org  Sat Feb 26 10:06:27 2022
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Feb 2022 15:06:27 +0000
Subject: [issue46847] functools.update_wrapper doesn't understand partial
 objects and annotations
In-Reply-To: <1645696033.77.0.27320800273.issue46847@roundup.psfhosted.org>
Message-ID: <1645887987.63.0.377014987905.issue46847@roundup.psfhosted.org>


Change by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46847>
_______________________________________

From report at bugs.python.org  Sat Feb 26 11:12:51 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 26 Feb 2022 16:12:51 +0000
Subject: [issue46661] Duplicate deprecation warnings in docs for asyncio
In-Reply-To: <1644173025.54.0.0182116442771.issue46661@roundup.psfhosted.org>
Message-ID: <1645891971.26.0.485649009322.issue46661@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Thanks! Marking as duplicate.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Fix incorrect use of directives in asyncio documentation

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46661>
_______________________________________

From report at bugs.python.org  Sat Feb 26 11:13:00 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 26 Feb 2022 16:13:00 +0000
Subject: [issue46777] Fix incorrect use of directives in asyncio documentation
In-Reply-To: <1645102456.61.0.455925245808.issue46777@roundup.psfhosted.org>
Message-ID: <1645891980.38.0.203732122996.issue46777@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/issue46777>
_______________________________________

From report at bugs.python.org  Sat Feb 26 11:24:54 2022
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 26 Feb 2022 16:24:54 +0000
Subject: [issue42760] inspect.iscoroutine returns False for asynchronous
 generator methods
In-Reply-To: <1609101687.37.0.151159530312.issue42760@roundup.psfhosted.org>
Message-ID: <1645892694.06.0.51421169005.issue42760@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This seems to be a duplicate of https://bugs.python.org/issue37190

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42760>
_______________________________________

From report at bugs.python.org  Sat Feb 26 11:37:30 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 26 Feb 2022 16:37:30 +0000
Subject: [issue46430] intern strings in deepfrozen modules
In-Reply-To: <1642590983.92.0.896257318647.issue46430@roundup.psfhosted.org>
Message-ID: <1645893450.2.0.840191327771.issue46430@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/issue46430>
_______________________________________

From report at bugs.python.org  Sat Feb 26 13:12:37 2022
From: report at bugs.python.org (Stanley)
Date: Sat, 26 Feb 2022 18:12:37 +0000
Subject: [issue13821] [doc] misleading return from isidentifier
In-Reply-To: <1326934459.59.0.614334427327.issue13821@psf.upfronthosting.co.za>
Message-ID: <1645899157.63.0.973397946989.issue13821@roundup.psfhosted.org>


Stanley <ostanley.lee at gmail.com> added the comment:

For clarification then, would it be accurate to add a sentence like this in the documentation?

"Note that isidentifier() still returns True even if the string may not be normalized."

----------
nosy: +slateny

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13821>
_______________________________________

From report at bugs.python.org  Sat Feb 26 07:33:33 2022
From: report at bugs.python.org (tongxiaoge)
Date: Sat, 26 Feb 2022 12:33:33 +0000
Subject: [issue46849] Memory problems detected using Valgrind
In-Reply-To: <1645711886.58.0.922948546021.issue46849@roundup.psfhosted.org>
Message-ID: <1645878813.2.0.254807179506.issue46849@roundup.psfhosted.org>


tongxiaoge <shixuantong at huawei.com> added the comment:

==93405== Memcheck, a memory error detector
==93405== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==93405== Using Valgrind-3.16.0 and LibVEX; rerun with -h for copyright info
==93405== Command: /usr/sbin/iotop -b -n 5
==93405== 
==93405== Conditional jump or move depends on uninitialised value(s)
==93405==    at 0x4A26278: maybe_small_long (longobject.c:63)
==93405==    by 0x4A26278: _PyLong_FromByteArray (longobject.c:915)
==93405==    by 0x4A264C7: int_from_bytes_impl (longobject.c:5854)
==93405==    by 0x4A264C7: int_from_bytes (longobject.c.h:389)
==93405==    by 0x4A3D6B3: cfunction_vectorcall_FASTCALL_KEYWORDS (methodobject.c:446)
==93405==    by 0x49FBAE7: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBAE7: PyObject_Vectorcall (call.c:298)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405==    by 0x49FC17B: _PyObject_CallMethodIdObjArgs (call.c:875)
==93405==    by 0x4AEF4CF: import_find_and_load (import.c:1739)
==93405==    by 0x4AEF4CF: PyImport_ImportModuleLevelObject (import.c:1840)
==93405==    by 0x4ABFFCF: builtin___import__ (bltinmodule.c:272)
==93405==    by 0x4A3D5A3: cfunction_call (methodobject.c:543)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:342)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:312)
==93405== 
==93405== Use of uninitialised value of size 8
==93405==    at 0x4A2633C: _Py_INCREF (object.h:489)
==93405==    by 0x4A2633C: get_small_int (longobject.c:54)
==93405==    by 0x4A2633C: maybe_small_long (longobject.c:65)
==93405==    by 0x4A2633C: _PyLong_FromByteArray (longobject.c:915)
==93405==    by 0x4A264C7: int_from_bytes_impl (longobject.c:5854)
==93405==    by 0x4A264C7: int_from_bytes (longobject.c.h:389)
==93405==    by 0x4A3D6B3: cfunction_vectorcall_FASTCALL_KEYWORDS (methodobject.c:446)
==93405==    by 0x49FBAE7: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBAE7: PyObject_Vectorcall (call.c:298)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405==    by 0x49FC17B: _PyObject_CallMethodIdObjArgs (call.c:875)
==93405==    by 0x4AEF4CF: import_find_and_load (import.c:1739)
==93405==    by 0x4AEF4CF: PyImport_ImportModuleLevelObject (import.c:1840)
==93405==    by 0x4ABFFCF: builtin___import__ (bltinmodule.c:272)
==93405==    by 0x4A3D5A3: cfunction_call (methodobject.c:543)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:342)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:312)
==93405== 
==93405== Conditional jump or move depends on uninitialised value(s)
==93405==    at 0x4A264DC: int_from_bytes_impl (longobject.c:5859)
==93405==    by 0x4A264DC: int_from_bytes (longobject.c.h:389)
==93405==    by 0x4A3D6B3: cfunction_vectorcall_FASTCALL_KEYWORDS (methodobject.c:446)
==93405==    by 0x49FBAE7: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBAE7: PyObject_Vectorcall (call.c:298)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405==    by 0x49FC17B: _PyObject_CallMethodIdObjArgs (call.c:875)
==93405==    by 0x4AEF4CF: import_find_and_load (import.c:1739)
==93405==    by 0x4AEF4CF: PyImport_ImportModuleLevelObject (import.c:1840)
==93405==    by 0x4ABFFCF: builtin___import__ (bltinmodule.c:272)
==93405==    by 0x4A3D5A3: cfunction_call (methodobject.c:543)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:342)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:312)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405== 
==93405== Conditional jump or move depends on uninitialised value(s)
==93405==    at 0x49FAE84: _Py_CheckFunctionResult (call.c:38)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405==    by 0x49FC17B: _PyObject_CallMethodIdObjArgs (call.c:875)
==93405==    by 0x4AEF4CF: import_find_and_load (import.c:1739)
==93405==    by 0x4AEF4CF: PyImport_ImportModuleLevelObject (import.c:1840)
==93405==    by 0x4ABFFCF: builtin___import__ (bltinmodule.c:272)
==93405==    by 0x4A3D5A3: cfunction_call (methodobject.c:543)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:342)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:312)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405== 
==93405== Conditional jump or move depends on uninitialised value(s)
==93405==    at 0x49A98E4: _PyEval_EvalFrameDefault (ceval.c:4625)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405==    by 0x49FC17B: _PyObject_CallMethodIdObjArgs (call.c:875)
==93405==    by 0x4AEF4CF: import_find_and_load (import.c:1739)
==93405==    by 0x4AEF4CF: PyImport_ImportModuleLevelObject (import.c:1840)
==93405==    by 0x4ABFFCF: builtin___import__ (bltinmodule.c:272)
==93405==    by 0x4A3D5A3: cfunction_call (methodobject.c:543)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:342)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:312)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405==    by 0x49FC17B: _PyObject_CallMethodIdObjArgs (call.c:875)
==93405== 
==93405== Conditional jump or move depends on uninitialised value(s)
==93405==    at 0x49AB4C8: _PyEval_EvalFrameDefault (ceval.c:1821)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405==    by 0x49FC17B: _PyObject_CallMethodIdObjArgs (call.c:875)
==93405==    by 0x4AEF4CF: import_find_and_load (import.c:1739)
==93405==    by 0x4AEF4CF: PyImport_ImportModuleLevelObject (import.c:1840)
==93405==    by 0x4ABFFCF: builtin___import__ (bltinmodule.c:272)
==93405==    by 0x4A3D5A3: cfunction_call (methodobject.c:543)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:342)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:312)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405==    by 0x49FC17B: _PyObject_CallMethodIdObjArgs (call.c:875)
==93405== 
==93405== Use of uninitialised value of size 8
==93405==    at 0x49AB4F4: _Py_INCREF (object.h:489)
==93405==    by 0x49AB4F4: _PyEval_EvalFrameDefault (ceval.c:1824)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405==    by 0x49FC17B: _PyObject_CallMethodIdObjArgs (call.c:875)
==93405==    by 0x4AEF4CF: import_find_and_load (import.c:1739)
==93405==    by 0x4AEF4CF: PyImport_ImportModuleLevelObject (import.c:1840)
==93405==    by 0x4ABFFCF: builtin___import__ (bltinmodule.c:272)
==93405==    by 0x4A3D5A3: cfunction_call (methodobject.c:543)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:342)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:312)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405==    by 0x49FC17B: _PyObject_CallMethodIdObjArgs (call.c:875)
==93405== 
==93405== Conditional jump or move depends on uninitialised value(s)
==93405==    at 0x4AE1A8C: _Py_XDECREF (object.h:583)
==93405==    by 0x4AE1A8C: _PyFrame_Clear (frame.c:104)
==93405==    by 0x49AF34F: _PyEvalFrameClearAndPop (ceval.c:6123)
==93405==    by 0x49AF34F: pop_frame (ceval.c:1635)
==93405==    by 0x49AF34F: _PyEval_EvalFrameDefault (ceval.c:2425)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405==    by 0x49FC17B: _PyObject_CallMethodIdObjArgs (call.c:875)
==93405==    by 0x4AEF4CF: import_find_and_load (import.c:1739)
==93405==    by 0x4AEF4CF: PyImport_ImportModuleLevelObject (import.c:1840)
==93405==    by 0x4ABFFCF: builtin___import__ (bltinmodule.c:272)
==93405==    by 0x4A3D5A3: cfunction_call (methodobject.c:543)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:342)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:312)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405== 
==93405== Use of uninitialised value of size 8
==93405==    at 0x4AE1A90: _Py_DECREF (object.h:509)
==93405==    by 0x4AE1A90: _Py_XDECREF (object.h:584)
==93405==    by 0x4AE1A90: _PyFrame_Clear (frame.c:104)
==93405==    by 0x49AF34F: _PyEvalFrameClearAndPop (ceval.c:6123)
==93405==    by 0x49AF34F: pop_frame (ceval.c:1635)
==93405==    by 0x49AF34F: _PyEval_EvalFrameDefault (ceval.c:2425)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405==    by 0x49FC17B: _PyObject_CallMethodIdObjArgs (call.c:875)
==93405==    by 0x4AEF4CF: import_find_and_load (import.c:1739)
==93405==    by 0x4AEF4CF: PyImport_ImportModuleLevelObject (import.c:1840)
==93405==    by 0x4ABFFCF: builtin___import__ (bltinmodule.c:272)
==93405==    by 0x4A3D5A3: cfunction_call (methodobject.c:543)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:342)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:312)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405== 
==93405== Conditional jump or move depends on uninitialised value(s)
==93405==    at 0x4A21F64: maybe_small_long (longobject.c:63)
==93405==    by 0x49DEA83: binary_op1 (abstract.c:892)
==93405==    by 0x49E077B: binary_op (abstract.c:931)
==93405==    by 0x49E077B: PyNumber_And (abstract.c:1063)
==93405==    by 0x49A6D2B: _PyEval_EvalFrameDefault (ceval.c:5285)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405==    by 0x49FC17B: _PyObject_CallMethodIdObjArgs (call.c:875)
==93405==    by 0x4AEF4CF: import_find_and_load (import.c:1739)
==93405==    by 0x4AEF4CF: PyImport_ImportModuleLevelObject (import.c:1840)
==93405==    by 0x4ABFFCF: builtin___import__ (bltinmodule.c:272)
==93405==    by 0x4A3D5A3: cfunction_call (methodobject.c:543)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:342)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:312)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405== 
==93405== Use of uninitialised value of size 8
==93405==    at 0x4A21FAC: _Py_INCREF (object.h:489)
==93405==    by 0x4A21FAC: get_small_int (longobject.c:54)
==93405==    by 0x4A21FAC: maybe_small_long (longobject.c:65)
==93405==    by 0x49DEA83: binary_op1 (abstract.c:892)
==93405==    by 0x49E077B: binary_op (abstract.c:931)
==93405==    by 0x49E077B: PyNumber_And (abstract.c:1063)
==93405==    by 0x49A6D2B: _PyEval_EvalFrameDefault (ceval.c:5285)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405==    by 0x49FC17B: _PyObject_CallMethodIdObjArgs (call.c:875)
==93405==    by 0x4AEF4CF: import_find_and_load (import.c:1739)
==93405==    by 0x4AEF4CF: PyImport_ImportModuleLevelObject (import.c:1840)
==93405==    by 0x4ABFFCF: builtin___import__ (bltinmodule.c:272)
==93405==    by 0x4A3D5A3: cfunction_call (methodobject.c:543)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:342)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:312)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405== 
==93405== Conditional jump or move depends on uninitialised value(s)
==93405==    at 0x49DEA90: binary_op1 (abstract.c:894)
==93405==    by 0x49E077B: binary_op (abstract.c:931)
==93405==    by 0x49E077B: PyNumber_And (abstract.c:1063)
==93405==    by 0x49A6D2B: _PyEval_EvalFrameDefault (ceval.c:5285)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405==    by 0x49FC17B: _PyObject_CallMethodIdObjArgs (call.c:875)
==93405==    by 0x4AEF4CF: import_find_and_load (import.c:1739)
==93405==    by 0x4AEF4CF: PyImport_ImportModuleLevelObject (import.c:1840)
==93405==    by 0x4ABFFCF: builtin___import__ (bltinmodule.c:272)
==93405==    by 0x4A3D5A3: cfunction_call (methodobject.c:543)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:342)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:312)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== Conditional jump or move depends on uninitialised value(s)
==93405==    at 0x49E078C: binary_op (abstract.c:932)
==93405==    by 0x49E078C: PyNumber_And (abstract.c:1063)
==93405==    by 0x49A6D2B: _PyEval_EvalFrameDefault (ceval.c:5285)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405==    by 0x49FC17B: _PyObject_CallMethodIdObjArgs (call.c:875)
==93405==    by 0x4AEF4CF: import_find_and_load (import.c:1739)
==93405==    by 0x4AEF4CF: PyImport_ImportModuleLevelObject (import.c:1840)
==93405==    by 0x4ABFFCF: builtin___import__ (bltinmodule.c:272)
==93405==    by 0x4A3D5A3: cfunction_call (methodobject.c:543)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:342)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:312)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405== 
==93405== Conditional jump or move depends on uninitialised value(s)
==93405==    at 0x49A6D58: _PyEval_EvalFrameDefault (ceval.c:5289)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405==    by 0x49FC17B: _PyObject_CallMethodIdObjArgs (call.c:875)
==93405==    by 0x4AEF4CF: import_find_and_load (import.c:1739)
==93405==    by 0x4AEF4CF: PyImport_ImportModuleLevelObject (import.c:1840)
==93405==    by 0x4ABFFCF: builtin___import__ (bltinmodule.c:272)
==93405==    by 0x4A3D5A3: cfunction_call (methodobject.c:543)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:342)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:312)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405==    by 0x49FC17B: _PyObject_CallMethodIdObjArgs (call.c:875)
==93405== 
==93405== Conditional jump or move depends on uninitialised value(s)
==93405==    at 0x4A4246C: PyObject_RichCompare (object.c:738)
==93405==    by 0x49A55EF: _PyEval_EvalFrameDefault (ceval.c:3652)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405==    by 0x49FC17B: _PyObject_CallMethodIdObjArgs (call.c:875)
==93405==    by 0x4AEF4CF: import_find_and_load (import.c:1739)
==93405==    by 0x4AEF4CF: PyImport_ImportModuleLevelObject (import.c:1840)
==93405==    by 0x4ABFFCF: builtin___import__ (bltinmodule.c:272)
==93405==    by 0x4A3D5A3: cfunction_call (methodobject.c:543)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:342)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:312)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405== 
==93405== Use of uninitialised value of size 8
==93405==    at 0x4A42494: _Py_TYPE (object.h:138)
==93405==    by 0x4A42494: do_richcompare (object.c:687)
==93405==    by 0x4A42494: PyObject_RichCompare (object.c:747)
==93405==    by 0x49A55EF: _PyEval_EvalFrameDefault (ceval.c:3652)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405==    by 0x49FC17B: _PyObject_CallMethodIdObjArgs (call.c:875)
==93405==    by 0x4AEF4CF: import_find_and_load (import.c:1739)
==93405==    by 0x4AEF4CF: PyImport_ImportModuleLevelObject (import.c:1840)
==93405==    by 0x4ABFFCF: builtin___import__ (bltinmodule.c:272)
==93405==    by 0x4A3D5A3: cfunction_call (methodobject.c:543)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:342)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:312)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405== 
==93405== Use of uninitialised value of size 8
==93405==    at 0x4A42498: _Py_IS_TYPE (object.h:152)
==93405==    by 0x4A42498: do_richcompare (object.c:687)
==93405==    by 0x4A42498: PyObject_RichCompare (object.c:747)
==93405==    by 0x49A55EF: _PyEval_EvalFrameDefault (ceval.c:3652)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405==    by 0x49FC17B: _PyObject_CallMethodIdObjArgs (call.c:875)
==93405==    by 0x4AEF4CF: import_find_and_load (import.c:1739)
==93405==    by 0x4AEF4CF: PyImport_ImportModuleLevelObject (import.c:1840)
==93405==    by 0x4ABFFCF: builtin___import__ (bltinmodule.c:272)
==93405==    by 0x4A3D5A3: cfunction_call (methodobject.c:543)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:342)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:312)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405== 
==93405== Use of uninitialised value of size 8
==93405==    at 0x4A21DD0: PyType_HasFeature (object.h:746)
==93405==    by 0x4A21DD0: long_richcompare (longobject.c:3080)
==93405==    by 0x4A4252F: do_richcompare (object.c:697)
==93405==    by 0x4A4252F: PyObject_RichCompare (object.c:747)
==93405==    by 0x49A55EF: _PyEval_EvalFrameDefault (ceval.c:3652)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405==    by 0x49FC17B: _PyObject_CallMethodIdObjArgs (call.c:875)
==93405==    by 0x4AEF4CF: import_find_and_load (import.c:1739)
==93405==    by 0x4AEF4CF: PyImport_ImportModuleLevelObject (import.c:1840)
==93405==    by 0x4ABFFCF: builtin___import__ (bltinmodule.c:272)
==93405==    by 0x4A3D5A3: cfunction_call (methodobject.c:543)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:342)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:312)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== Use of uninitialised value of size 8
==93405==    at 0x4A21DDC: PyType_HasFeature (object.h:746)
==93405==    by 0x4A21DDC: long_richcompare (longobject.c:3080)
==93405==    by 0x4A4252F: do_richcompare (object.c:697)
==93405==    by 0x4A4252F: PyObject_RichCompare (object.c:747)
==93405==    by 0x49A55EF: _PyEval_EvalFrameDefault (ceval.c:3652)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405==    by 0x49FC17B: _PyObject_CallMethodIdObjArgs (call.c:875)
==93405==    by 0x4AEF4CF: import_find_and_load (import.c:1739)
==93405==    by 0x4AEF4CF: PyImport_ImportModuleLevelObject (import.c:1840)
==93405==    by 0x4ABFFCF: builtin___import__ (bltinmodule.c:272)
==93405==    by 0x4A3D5A3: cfunction_call (methodobject.c:543)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:342)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:312)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== Conditional jump or move depends on uninitialised value(s)
==93405==    at 0x4A21DEC: long_richcompare (longobject.c:3081)
==93405==    by 0x4A21DEC: long_richcompare (longobject.c:3077)
==93405==    by 0x4A4252F: do_richcompare (object.c:697)
==93405==    by 0x4A4252F: PyObject_RichCompare (object.c:747)
==93405==    by 0x49A55EF: _PyEval_EvalFrameDefault (ceval.c:3652)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405==    by 0x49FC17B: _PyObject_CallMethodIdObjArgs (call.c:875)
==93405==    by 0x4AEF4CF: import_find_and_load (import.c:1739)
==93405==    by 0x4AEF4CF: PyImport_ImportModuleLevelObject (import.c:1840)
==93405==    by 0x4ABFFCF: builtin___import__ (bltinmodule.c:272)
==93405==    by 0x4A3D5A3: cfunction_call (methodobject.c:543)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:342)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:312)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== Use of uninitialised value of size 8
==93405==    at 0x49A55F0: _Py_DECREF (object.h:509)
==93405==    by 0x49A55F0: _PyEval_EvalFrameDefault (ceval.c:3654)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405==    by 0x49FC17B: _PyObject_CallMethodIdObjArgs (call.c:875)
==93405==    by 0x4AEF4CF: import_find_and_load (import.c:1739)
==93405==    by 0x4AEF4CF: PyImport_ImportModuleLevelObject (import.c:1840)
==93405==    by 0x4ABFFCF: builtin___import__ (bltinmodule.c:272)
==93405==    by 0x4A3D5A3: cfunction_call (methodobject.c:543)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:342)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:312)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405==    by 0x49FC17B: _PyObject_CallMethodIdObjArgs (call.c:875)
==93405== 
==93405== Use of uninitialised value of size 8
==93405==    at 0x49A5608: _Py_DECREF (object.h:509)
==93405==    by 0x49A5608: _PyEval_EvalFrameDefault (ceval.c:3655)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405==    by 0x49FC17B: _PyObject_CallMethodIdObjArgs (call.c:875)
==93405==    by 0x4AEF4CF: import_find_and_load (import.c:1739)
==93405==    by 0x4AEF4CF: PyImport_ImportModuleLevelObject (import.c:1840)
==93405==    by 0x4ABFFCF: builtin___import__ (bltinmodule.c:272)
==93405==    by 0x4A3D5A3: cfunction_call (methodobject.c:543)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:342)
==93405==    by 0x49FB1EF: _PyObject_Call (call.c:312)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405==    by 0x49FC17B: _PyObject_CallMethodIdObjArgs (call.c:875)
==93405== 
==93405== Conditional jump or move depends on uninitialised value(s)
==93405==    at 0x49AA9AC: _PyEval_EvalFrameDefault (ceval.c:1883)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405==    by 0x49FC17B: _PyObject_CallMethodIdObjArgs (call.c:875)
==93405==    by 0x4AEF4CF: import_find_and_load (import.c:1739)
==93405==    by 0x4AEF4CF: PyImport_ImportModuleLevelObject (import.c:1840)
==93405==    by 0x49AF6C3: import_name (ceval.c:7106)
==93405==    by 0x49AF6C3: _PyEval_EvalFrameDefault (ceval.c:3885)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x4AC7877: PyEval_EvalCode (ceval.c:1120)
==93405==    by 0x4AC15BF: builtin_exec_impl (bltinmodule.c:1057)
==93405==    by 0x4AC15BF: builtin_exec (bltinmodule.c.h:371)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== Use of uninitialised value of size 8
==93405==    at 0x49AA9C0: _Py_INCREF (object.h:489)
==93405==    by 0x49AA9C0: _PyEval_EvalFrameDefault (ceval.c:1886)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405==    by 0x49FC17B: _PyObject_CallMethodIdObjArgs (call.c:875)
==93405==    by 0x4AEF4CF: import_find_and_load (import.c:1739)
==93405==    by 0x4AEF4CF: PyImport_ImportModuleLevelObject (import.c:1840)
==93405==    by 0x49AF6C3: import_name (ceval.c:7106)
==93405==    by 0x49AF6C3: _PyEval_EvalFrameDefault (ceval.c:3885)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x4AC7877: PyEval_EvalCode (ceval.c:1120)
==93405==    by 0x4AC15BF: builtin_exec_impl (bltinmodule.c:1057)
==93405==    by 0x4AC15BF: builtin_exec (bltinmodule.c.h:371)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== Conditional jump or move depends on uninitialised value(s)
==93405==    at 0x4A89020: PyUnicode_Decode (unicodeobject.c:3658)
==93405==    by 0x4A89020: PyUnicode_Decode (unicodeobject.c:3613)
==93405==    by 0x4A8965F: unicode_new_impl (unicodeobject.c:15365)
==93405==    by 0x4A8965F: unicode_new (unicodeobject.c.h:1325)
==93405==    by 0x4A573E7: type_call (typeobject.c:1129)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FB623: _PyObject_FastCallDictTstate (call.c:141)
==93405==    by 0x49FB93B: _PyObject_Call_Prepend (call.c:481)
==93405==    by 0x4A5E937: slot_tp_init (typeobject.c:7877)
==93405==    by 0x4A57437: type_call (typeobject.c:1141)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405== 
==93406== Warning: invalid file descriptor 1024 in syscall close()
==93406== Warning: invalid file descriptor 1025 in syscall close()
==93406== Warning: invalid file descriptor 1026 in syscall close()
==93406== Warning: invalid file descriptor 1027 in syscall close()
==93406==    Use --log-fd=<number> to select an alternative log fd.
==93406== Warning: invalid file descriptor 1028 in syscall close()
==93406== Warning: invalid file descriptor 1029 in syscall close()
==93407== Warning: invalid file descriptor 1024 in syscall close()
==93407== Warning: invalid file descriptor 1025 in syscall close()
==93407== Warning: invalid file descriptor 1026 in syscall close()
==93407== Warning: invalid file descriptor 1027 in syscall close()
==93407==    Use --log-fd=<number> to select an alternative log fd.
==93407== Warning: invalid file descriptor 1028 in syscall close()
==93407== Warning: invalid file descriptor 1029 in syscall close()
==93405== 
==93405== HEAP SUMMARY:
==93405==     in use at exit: 364,228 bytes in 2,851 blocks
==93405==   total heap usage: 756,807 allocs, 753,956 frees, 169,038,477 bytes allocated
==93405== 
==93405== 8 bytes in 1 blocks are possibly lost in loss record 5 of 819
==93405==    at 0x486933C: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46513: _PyObject_Calloc (obmalloc.c:2009)
==93405==    by 0x4A46513: _PyObject_Calloc (obmalloc.c:1998)
==93405==    by 0x4A1FB9F: PyList_New (listobject.c:179)
==93405==    by 0x49A5D2B: _PyEval_EvalFrameDefault (ceval.c:3192)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405==    by 0x49FC17B: _PyObject_CallMethodIdObjArgs (call.c:875)
==93405==    by 0x4AEF4CF: import_find_and_load (import.c:1739)
==93405==    by 0x4AEF4CF: PyImport_ImportModuleLevelObject (import.c:1840)
==93405==    by 0x49AF6C3: import_name (ceval.c:7106)
==93405==    by 0x49AF6C3: _PyEval_EvalFrameDefault (ceval.c:3885)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x4AC7877: PyEval_EvalCode (ceval.c:1120)
==93405==    by 0x4AC15BF: builtin_exec_impl (bltinmodule.c:1057)
==93405==    by 0x4AC15BF: builtin_exec (bltinmodule.c.h:371)
==93405== 
==93405== 28 bytes in 1 blocks are possibly lost in loss record 41 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A21FFB: _PyLong_New (longobject.c:153)
==93405==    by 0x4A2554F: PyLong_FromUnsignedLong (longobject.c:351)
==93405==    by 0x66593E7: py_dl_open (callproc.c:1540)
==93405==    by 0x4A3D57B: cfunction_call (methodobject.c:552)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FB623: _PyObject_FastCallDictTstate (call.c:141)
==93405==    by 0x49FB93B: _PyObject_Call_Prepend (call.c:481)
==93405==    by 0x4A5E937: slot_tp_init (typeobject.c:7877)
==93405== 
==93405== 32 bytes in 1 blocks are possibly lost in loss record 43 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A21D67: _PyLong_FromMedium (longobject.c:195)
==93405==    by 0x4AF8657: r_object (marshal.c:1036)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF95AB: read_object (marshal.c:1525)
==93405==    by 0x4AF9843: marshal_loads_impl (marshal.c:1834)
==93405==    by 0x4AF9843: marshal_loads (marshal.c.h:148)
==93405== 
==93405== 35 bytes in 1 blocks are possibly lost in loss record 45 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x49F121F: _PyBytes_FromSize (bytesobject.c:104)
==93405==    by 0x49F121F: _PyBytes_FromSize (bytesobject.c:85)
==93405==    by 0x49F1EAB: PyBytes_FromStringAndSize (bytesobject.c:134)
==93405==    by 0x49F1EAB: PyBytes_FromStringAndSize (bytesobject.c:117)
==93405==    by 0x4AF8673: r_object (marshal.c:1108)
==93405==    by 0x4AF8893: r_object (marshal.c:1397)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405== 
==93405== 36 bytes in 1 blocks are possibly lost in loss record 46 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x49F121F: _PyBytes_FromSize (bytesobject.c:104)
==93405==    by 0x49F121F: _PyBytes_FromSize (bytesobject.c:85)
==93405==    by 0x49F1EAB: PyBytes_FromStringAndSize (bytesobject.c:134)
==93405==    by 0x49F1EAB: PyBytes_FromStringAndSize (bytesobject.c:117)
==93405==    by 0x662D71B: Struct___init___impl (_struct.c:1479)
==93405==    by 0x662D71B: Struct___init__ (_struct.c.h:35)
==93405==    by 0x4A57437: type_call (typeobject.c:1141)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x49FBA93: _PyObject_VectorcallTstate (pycore_call.h:87)
==93405==    by 0x49FBA93: _PyObject_VectorcallTstate (pycore_call.h:74)
==93405==    by 0x49FBA93: PyObject_CallOneArg (call.c:375)
==93405==    by 0x662E397: cache_struct_converter (_struct.c:2137)
==93405==    by 0x662E523: pack (_struct.c:2199)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405== 
==93405== 40 bytes in 1 blocks are possibly lost in loss record 49 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A51647: tuple_create_empty_tuple_singleton (tupleobject.c:109)
==93405==    by 0x4A51647: _PyTuple_InitGlobalObjects (tupleobject.c:1090)
==93405==    by 0x4B008EF: pycore_init_global_objects (pylifecycle.c:693)
==93405==    by 0x4B008EF: pycore_interp_init (pylifecycle.c:833)
==93405==    by 0x4B0293F: pyinit_config (pylifecycle.c:900)
==93405==    by 0x4B0293F: pyinit_core.constprop.0 (pylifecycle.c:1063)
==93405==    by 0x4B02B67: Py_InitializeFromConfig (pylifecycle.c:1253)
==93405==    by 0x4B02B67: Py_InitializeFromConfig (pylifecycle.c:1238)
==93405==    by 0x4B24F3B: pymain_init (main.c:67)
==93405==    by 0x4B25F13: pymain_main (main.c:693)
==93405==    by 0x4B25F13: Py_BytesMain (main.c:726)
==93405==    by 0x4F2DF3B: __libc_start_call_main (libc_start_call_main.h:58)
==93405==    by 0x4F2E007: __libc_start_main@@GLIBC_2.34 (libc-start.c:409)
==93405== 
==93405== 41 bytes in 1 blocks are possibly lost in loss record 51 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x49F121F: _PyBytes_FromSize (bytesobject.c:104)
==93405==    by 0x49F121F: _PyBytes_FromSize (bytesobject.c:85)
==93405==    by 0x49F1EAB: PyBytes_FromStringAndSize (bytesobject.c:134)
==93405==    by 0x49F1EAB: PyBytes_FromStringAndSize (bytesobject.c:117)
==93405==    by 0x4AF8673: r_object (marshal.c:1108)
==93405==    by 0x4AF88E7: r_object (marshal.c:1412)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405== 
==93405== 48 bytes in 1 blocks are possibly lost in loss record 55 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A510CF: _PyTuple_FromArray (tupleobject.c:475)
==93405==    by 0x4A510CF: _PyTuple_FromArray (tupleobject.c:469)
==93405==    by 0x49E4A3F: PySequence_Tuple (abstract.c:2059)
==93405==    by 0x4A61A47: mro_invoke (typeobject.c:2109)
==93405==    by 0x4A61A47: mro_internal (typeobject.c:2161)
==93405==    by 0x4A57A9F: type_ready_mro (typeobject.c:6238)
==93405==    by 0x4A57A9F: type_ready (typeobject.c:6468)
==93405==    by 0x4A57A9F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x4A40D8B: _PyTypes_InitTypes (object.c:1966)
==93405==    by 0x4B0098B: pycore_init_types (pylifecycle.c:717)
==93405==    by 0x4B0098B: pycore_interp_init (pylifecycle.c:844)
==93405==    by 0x4B0293F: pyinit_config (pylifecycle.c:900)
==93405==    by 0x4B0293F: pyinit_core.constprop.0 (pylifecycle.c:1063)
==93405==    by 0x4B02B67: Py_InitializeFromConfig (pylifecycle.c:1253)
==93405==    by 0x4B02B67: Py_InitializeFromConfig (pylifecycle.c:1238)
==93405== 
==93405== 48 bytes in 1 blocks are possibly lost in loss record 56 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50F83: PyTuple_Pack (tupleobject.c:246)
==93405==    by 0x4A607BB: type_new_get_bases (typeobject.c:3246)
==93405==    by 0x4A607BB: type_new (typeobject.c:3337)
==93405==    by 0x4A573E7: type_call (typeobject.c:1129)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x49FB623: _PyObject_FastCallDictTstate (call.c:141)
==93405==    by 0x4AC427B: builtin___build_class__ (bltinmodule.c:224)
==93405==    by 0x4A3D6B3: cfunction_vectorcall_FASTCALL_KEYWORDS (methodobject.c:446)
==93405==    by 0x49FBAE7: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBAE7: PyObject_Vectorcall (call.c:298)
==93405== 
==93405== 48 bytes in 1 blocks are possibly lost in loss record 57 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A510CF: _PyTuple_FromArray (tupleobject.c:475)
==93405==    by 0x4A510CF: _PyTuple_FromArray (tupleobject.c:469)
==93405==    by 0x4A06AAF: method_vectorcall_VARARGS_KEYWORDS (descrobject.c:326)
==93405==    by 0x49FBAE7: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBAE7: PyObject_Vectorcall (call.c:298)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x4AC4237: builtin___build_class__ (bltinmodule.c:216)
==93405==    by 0x4A3D6B3: cfunction_vectorcall_FASTCALL_KEYWORDS (methodobject.c:446)
==93405==    by 0x49FBAE7: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBAE7: PyObject_Vectorcall (call.c:298)
==93405== 
==93405== 48 bytes in 1 blocks are possibly lost in loss record 58 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A510CF: _PyTuple_FromArray (tupleobject.c:475)
==93405==    by 0x4A510CF: _PyTuple_FromArray (tupleobject.c:469)
==93405==    by 0x49FB427: _PyObject_MakeTpCall (call.c:188)
==93405==    by 0x49FBA93: _PyObject_VectorcallTstate (pycore_call.h:87)
==93405==    by 0x49FBA93: _PyObject_VectorcallTstate (pycore_call.h:74)
==93405==    by 0x49FBA93: PyObject_CallOneArg (call.c:375)
==93405==    by 0x4ADF263: _PyErr_CreateException (errors.c:105)
==93405==    by 0x4ADFFDB: _PyErr_NormalizeException (errors.c:366)
==93405==    by 0x4A41943: set_attribute_error_context (object.c:902)
==93405==    by 0x4A41943: set_attribute_error_context (object.c:892)
==93405==    by 0x4A41943: PyObject_GetAttr (object.c:942)
==93405==    by 0x4A193B3: functools_copy_attr (funcobject.c:791)
==93405==    by 0x4A1950B: functools_wraps (funcobject.c:825)
==93405== 
==93405== 48 bytes in 1 blocks are possibly lost in loss record 59 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50F83: PyTuple_Pack (tupleobject.c:246)
==93405==    by 0x4A5905F: type_ready_set_bases (typeobject.c:6148)
==93405==    by 0x4A5905F: type_ready (typeobject.c:6465)
==93405==    by 0x4A5905F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x5903A67: PyInit__curses (_cursesmodule.c:4746)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== 48 bytes in 1 blocks are possibly lost in loss record 60 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50F83: PyTuple_Pack (tupleobject.c:246)
==93405==    by 0x4AE083F: PyErr_NewException (errors.c:1155)
==93405==    by 0x5903B47: PyInit__curses (_cursesmodule.c:4786)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== 48 bytes in 1 blocks are possibly lost in loss record 61 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x49F121F: _PyBytes_FromSize (bytesobject.c:104)
==93405==    by 0x49F121F: _PyBytes_FromSize (bytesobject.c:85)
==93405==    by 0x49F1EAB: PyBytes_FromStringAndSize (bytesobject.c:134)
==93405==    by 0x49F1EAB: PyBytes_FromStringAndSize (bytesobject.c:117)
==93405==    by 0x4AF8673: r_object (marshal.c:1108)
==93405==    by 0x4AF891B: r_object (marshal.c:1421)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF95AB: read_object (marshal.c:1525)
==93405==    by 0x4AF9843: marshal_loads_impl (marshal.c:1834)
==93405==    by 0x4AF9843: marshal_loads (marshal.c.h:148)
==93405==    by 0x49AA24F: _PyEval_EvalFrameDefault (ceval.c:4816)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== 48 bytes in 1 blocks are possibly lost in loss record 62 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50F83: PyTuple_Pack (tupleobject.c:246)
==93405==    by 0x4A59A6F: PyType_FromModuleAndSpec (typeobject.c:3507)
==93405==    by 0x662B467: _structmodule_exec (_struct.c:2393)
==93405==    by 0x4A3F7A3: PyModule_ExecDef (moduleobject.c:428)
==93405==    by 0x4AEC003: exec_builtin_or_dynamic (import.c:2354)
==93405==    by 0x4AEC003: exec_builtin_or_dynamic (import.c:2335)
==93405==    by 0x4AEC003: _imp_exec_dynamic_impl (import.c:2428)
==93405==    by 0x4AEC003: _imp_exec_dynamic (import.c.h:474)
==93405==    by 0x4A3DB73: cfunction_vectorcall_O (methodobject.c:516)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== 48 bytes in 1 blocks are possibly lost in loss record 63 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50F83: PyTuple_Pack (tupleobject.c:246)
==93405==    by 0x4AE083F: PyErr_NewException (errors.c:1155)
==93405==    by 0x662B4DF: _structmodule_exec (_struct.c:2442)
==93405==    by 0x4A3F7A3: PyModule_ExecDef (moduleobject.c:428)
==93405==    by 0x4AEC003: exec_builtin_or_dynamic (import.c:2354)
==93405==    by 0x4AEC003: exec_builtin_or_dynamic (import.c:2335)
==93405==    by 0x4AEC003: _imp_exec_dynamic_impl (import.c:2428)
==93405==    by 0x4AEC003: _imp_exec_dynamic (import.c.h:474)
==93405==    by 0x4A3DB73: cfunction_vectorcall_O (methodobject.c:516)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== 48 bytes in 1 blocks are possibly lost in loss record 64 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50F83: PyTuple_Pack (tupleobject.c:246)
==93405==    by 0x4AE083F: PyErr_NewException (errors.c:1155)
==93405==    by 0x6657983: _ctypes_mod_exec (_ctypes.c:5832)
==93405==    by 0x6657983: PyInit__ctypes (_ctypes.c:5859)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== 48 bytes in 1 blocks are possibly lost in loss record 65 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50F83: PyTuple_Pack (tupleobject.c:246)
==93405==    by 0x4A5905F: type_ready_set_bases (typeobject.c:6148)
==93405==    by 0x4A5905F: type_ready (typeobject.c:6465)
==93405==    by 0x4A5905F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x6657997: _ctypes_add_types (_ctypes.c:5709)
==93405==    by 0x6657997: _ctypes_mod_exec (_ctypes.c:5837)
==93405==    by 0x6657997: PyInit__ctypes (_ctypes.c:5859)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== 48 bytes in 1 blocks are possibly lost in loss record 66 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50F83: PyTuple_Pack (tupleobject.c:246)
==93405==    by 0x4A5905F: type_ready_set_bases (typeobject.c:6148)
==93405==    by 0x4A5905F: type_ready (typeobject.c:6465)
==93405==    by 0x4A5905F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x66579A7: _ctypes_add_types (_ctypes.c:5710)
==93405==    by 0x66579A7: _ctypes_mod_exec (_ctypes.c:5837)
==93405==    by 0x66579A7: PyInit__ctypes (_ctypes.c:5859)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== 48 bytes in 1 blocks are possibly lost in loss record 67 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50F83: PyTuple_Pack (tupleobject.c:246)
==93405==    by 0x4A5905F: type_ready_set_bases (typeobject.c:6148)
==93405==    by 0x4A5905F: type_ready (typeobject.c:6465)
==93405==    by 0x4A5905F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x66579BF: _ctypes_add_types (_ctypes.c:5711)
==93405==    by 0x66579BF: _ctypes_mod_exec (_ctypes.c:5837)
==93405==    by 0x66579BF: PyInit__ctypes (_ctypes.c:5859)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== 48 bytes in 1 blocks are possibly lost in loss record 68 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50F83: PyTuple_Pack (tupleobject.c:246)
==93405==    by 0x4A5905F: type_ready_set_bases (typeobject.c:6148)
==93405==    by 0x4A5905F: type_ready (typeobject.c:6465)
==93405==    by 0x4A5905F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x66579DB: _ctypes_add_types (_ctypes.c:5713)
==93405==    by 0x66579DB: _ctypes_mod_exec (_ctypes.c:5837)
==93405==    by 0x66579DB: PyInit__ctypes (_ctypes.c:5859)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== 48 bytes in 1 blocks are possibly lost in loss record 69 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50F83: PyTuple_Pack (tupleobject.c:246)
==93405==    by 0x4A5905F: type_ready_set_bases (typeobject.c:6148)
==93405==    by 0x4A5905F: type_ready (typeobject.c:6465)
==93405==    by 0x4A5905F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x66579FF: _ctypes_add_types (_ctypes.c:5719)
==93405==    by 0x66579FF: _ctypes_mod_exec (_ctypes.c:5837)
==93405==    by 0x66579FF: PyInit__ctypes (_ctypes.c:5859)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== 48 bytes in 1 blocks are possibly lost in loss record 70 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50F83: PyTuple_Pack (tupleobject.c:246)
==93405==    by 0x4A5905F: type_ready_set_bases (typeobject.c:6148)
==93405==    by 0x4A5905F: type_ready (typeobject.c:6465)
==93405==    by 0x4A5905F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x6657A0F: _ctypes_add_types (_ctypes.c:5720)
==93405==    by 0x6657A0F: _ctypes_mod_exec (_ctypes.c:5837)
==93405==    by 0x6657A0F: PyInit__ctypes (_ctypes.c:5859)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== 48 bytes in 1 blocks are possibly lost in loss record 71 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50F83: PyTuple_Pack (tupleobject.c:246)
==93405==    by 0x4A5905F: type_ready_set_bases (typeobject.c:6148)
==93405==    by 0x4A5905F: type_ready (typeobject.c:6465)
==93405==    by 0x4A5905F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x6657A2B: _ctypes_add_types (_ctypes.c:5721)
==93405==    by 0x6657A2B: _ctypes_mod_exec (_ctypes.c:5837)
==93405==    by 0x6657A2B: PyInit__ctypes (_ctypes.c:5859)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== 48 bytes in 1 blocks are possibly lost in loss record 72 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50F83: PyTuple_Pack (tupleobject.c:246)
==93405==    by 0x4A5905F: type_ready_set_bases (typeobject.c:6148)
==93405==    by 0x4A5905F: type_ready (typeobject.c:6465)
==93405==    by 0x4A5905F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x6657A43: _ctypes_add_types (_ctypes.c:5722)
==93405==    by 0x6657A43: _ctypes_mod_exec (_ctypes.c:5837)
==93405==    by 0x6657A43: PyInit__ctypes (_ctypes.c:5859)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== 48 bytes in 1 blocks are possibly lost in loss record 73 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50F83: PyTuple_Pack (tupleobject.c:246)
==93405==    by 0x4A5905F: type_ready_set_bases (typeobject.c:6148)
==93405==    by 0x4A5905F: type_ready (typeobject.c:6465)
==93405==    by 0x4A5905F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x6657A53: _ctypes_add_types (_ctypes.c:5723)
==93405==    by 0x6657A53: _ctypes_mod_exec (_ctypes.c:5837)
==93405==    by 0x6657A53: PyInit__ctypes (_ctypes.c:5859)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== 48 bytes in 1 blocks are possibly lost in loss record 74 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50F83: PyTuple_Pack (tupleobject.c:246)
==93405==    by 0x4A5905F: type_ready_set_bases (typeobject.c:6148)
==93405==    by 0x4A5905F: type_ready (typeobject.c:6465)
==93405==    by 0x4A5905F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x6657A67: _ctypes_add_types (_ctypes.c:5724)
==93405==    by 0x6657A67: _ctypes_mod_exec (_ctypes.c:5837)
==93405==    by 0x6657A67: PyInit__ctypes (_ctypes.c:5859)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== 48 bytes in 1 blocks are possibly lost in loss record 75 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50F83: PyTuple_Pack (tupleobject.c:246)
==93405==    by 0x4A5905F: type_ready_set_bases (typeobject.c:6148)
==93405==    by 0x4A5905F: type_ready (typeobject.c:6465)
==93405==    by 0x4A5905F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x4AFCBEF: PyModule_AddType (modsupport.c:706)
==93405==    by 0x6657A8B: _ctypes_add_types (_ctypes.c:5731)
==93405==    by 0x6657A8B: _ctypes_mod_exec (_ctypes.c:5837)
==93405==    by 0x6657A8B: PyInit__ctypes (_ctypes.c:5859)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405== 
==93405== 48 bytes in 1 blocks are possibly lost in loss record 76 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50F83: PyTuple_Pack (tupleobject.c:246)
==93405==    by 0x4A5905F: type_ready_set_bases (typeobject.c:6148)
==93405==    by 0x4A5905F: type_ready (typeobject.c:6465)
==93405==    by 0x4A5905F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x4AFCBEF: PyModule_AddType (modsupport.c:706)
==93405==    by 0x6657AA7: _ctypes_add_types (_ctypes.c:5732)
==93405==    by 0x6657AA7: _ctypes_mod_exec (_ctypes.c:5837)
==93405==    by 0x6657AA7: PyInit__ctypes (_ctypes.c:5859)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405== 
==93405== 48 bytes in 1 blocks are possibly lost in loss record 77 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50F83: PyTuple_Pack (tupleobject.c:246)
==93405==    by 0x4A5905F: type_ready_set_bases (typeobject.c:6148)
==93405==    by 0x4A5905F: type_ready (typeobject.c:6465)
==93405==    by 0x4A5905F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x4AFCBEF: PyModule_AddType (modsupport.c:706)
==93405==    by 0x6657ABF: _ctypes_add_types (_ctypes.c:5733)
==93405==    by 0x6657ABF: _ctypes_mod_exec (_ctypes.c:5837)
==93405==    by 0x6657ABF: PyInit__ctypes (_ctypes.c:5859)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405== 
==93405== 48 bytes in 1 blocks are possibly lost in loss record 78 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50F83: PyTuple_Pack (tupleobject.c:246)
==93405==    by 0x4A5905F: type_ready_set_bases (typeobject.c:6148)
==93405==    by 0x4A5905F: type_ready (typeobject.c:6465)
==93405==    by 0x4A5905F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x4AFCBEF: PyModule_AddType (modsupport.c:706)
==93405==    by 0x6657AD7: _ctypes_add_types (_ctypes.c:5734)
==93405==    by 0x6657AD7: _ctypes_mod_exec (_ctypes.c:5837)
==93405==    by 0x6657AD7: PyInit__ctypes (_ctypes.c:5859)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405== 
==93405== 48 bytes in 1 blocks are possibly lost in loss record 79 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50F83: PyTuple_Pack (tupleobject.c:246)
==93405==    by 0x4A5905F: type_ready_set_bases (typeobject.c:6148)
==93405==    by 0x4A5905F: type_ready (typeobject.c:6465)
==93405==    by 0x4A5905F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x4AFCBEF: PyModule_AddType (modsupport.c:706)
==93405==    by 0x6657AEF: _ctypes_add_types (_ctypes.c:5735)
==93405==    by 0x6657AEF: _ctypes_mod_exec (_ctypes.c:5837)
==93405==    by 0x6657AEF: PyInit__ctypes (_ctypes.c:5859)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405== 
==93405== 48 bytes in 1 blocks are possibly lost in loss record 80 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50F83: PyTuple_Pack (tupleobject.c:246)
==93405==    by 0x4A5905F: type_ready_set_bases (typeobject.c:6148)
==93405==    by 0x4A5905F: type_ready (typeobject.c:6465)
==93405==    by 0x4A5905F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x4AFCBEF: PyModule_AddType (modsupport.c:706)
==93405==    by 0x6657B07: _ctypes_add_types (_ctypes.c:5736)
==93405==    by 0x6657B07: _ctypes_mod_exec (_ctypes.c:5837)
==93405==    by 0x6657B07: PyInit__ctypes (_ctypes.c:5859)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405== 
==93405== 48 bytes in 1 blocks are possibly lost in loss record 81 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50F83: PyTuple_Pack (tupleobject.c:246)
==93405==    by 0x4A5905F: type_ready_set_bases (typeobject.c:6148)
==93405==    by 0x4A5905F: type_ready (typeobject.c:6465)
==93405==    by 0x4A5905F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x6657B17: _ctypes_add_types (_ctypes.c:5744)
==93405==    by 0x6657B17: _ctypes_mod_exec (_ctypes.c:5837)
==93405==    by 0x6657B17: PyInit__ctypes (_ctypes.c:5859)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== 48 bytes in 1 blocks are possibly lost in loss record 82 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50F83: PyTuple_Pack (tupleobject.c:246)
==93405==    by 0x4A5905F: type_ready_set_bases (typeobject.c:6148)
==93405==    by 0x4A5905F: type_ready (typeobject.c:6465)
==93405==    by 0x4A5905F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x6657B2F: _ctypes_add_types (_ctypes.c:5752)
==93405==    by 0x6657B2F: _ctypes_mod_exec (_ctypes.c:5837)
==93405==    by 0x6657B2F: PyInit__ctypes (_ctypes.c:5859)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== 48 bytes in 1 blocks are possibly lost in loss record 83 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50F83: PyTuple_Pack (tupleobject.c:246)
==93405==    by 0x4A5905F: type_ready_set_bases (typeobject.c:6148)
==93405==    by 0x4A5905F: type_ready (typeobject.c:6465)
==93405==    by 0x4A5905F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x6657B3B: _ctypes_add_types (_ctypes.c:5753)
==93405==    by 0x6657B3B: _ctypes_mod_exec (_ctypes.c:5837)
==93405==    by 0x6657B3B: PyInit__ctypes (_ctypes.c:5859)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== 48 bytes in 1 blocks are possibly lost in loss record 84 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50F83: PyTuple_Pack (tupleobject.c:246)
==93405==    by 0x4AE083F: PyErr_NewException (errors.c:1155)
==93405==    by 0x6AEC35F: PyInit__socket (socketmodule.c:7126)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== 48 bytes in 1 blocks are possibly lost in loss record 85 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50F83: PyTuple_Pack (tupleobject.c:246)
==93405==    by 0x4AE083F: PyErr_NewException (errors.c:1155)
==93405==    by 0x6AEC39F: PyInit__socket (socketmodule.c:7132)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== 50 bytes in 1 blocks are possibly lost in loss record 96 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A6B783: PyUnicode_New (unicodeobject.c:1471)
==93405==    by 0x4A6B9B3: get_latin1_char (unicodeobject.c:2170)
==93405==    by 0x4AF7EE3: r_object (marshal.c:1151)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF95AB: read_object (marshal.c:1525)
==93405==    by 0x4AF9843: marshal_loads_impl (marshal.c:1834)
==93405==    by 0x4AF9843: marshal_loads (marshal.c.h:148)
==93405==    by 0x49AA24F: _PyEval_EvalFrameDefault (ceval.c:4816)
==93405== 
==93405== 51 bytes in 1 blocks are possibly lost in loss record 97 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A6B783: PyUnicode_New (unicodeobject.c:1471)
==93405==    by 0x4A84007: unicode_decode_utf8 (unicodeobject.c:5184)
==93405==    by 0x4A8DDEF: PyUnicode_InternFromString (unicodeobject.c:15669)
==93405==    by 0x4A0728F: descr_new (descrobject.c:888)
==93405==    by 0x4A0728F: PyDescr_NewMember (descrobject.c:963)
==93405==    by 0x4A57C83: type_add_members (typeobject.c:5759)
==93405==    by 0x4A57C83: type_ready_fill_dict (typeobject.c:6221)
==93405==    by 0x4A57C83: type_ready (typeobject.c:6474)
==93405==    by 0x4A57C83: PyType_Ready (typeobject.c:6510)
==93405==    by 0x4A40D8B: _PyTypes_InitTypes (object.c:1966)
==93405==    by 0x4B0098B: pycore_init_types (pylifecycle.c:717)
==93405==    by 0x4B0098B: pycore_interp_init (pylifecycle.c:844)
==93405==    by 0x4B0293F: pyinit_config (pylifecycle.c:900)
==93405==    by 0x4B0293F: pyinit_core.constprop.0 (pylifecycle.c:1063)
==93405==    by 0x4B02B67: Py_InitializeFromConfig (pylifecycle.c:1253)
==93405==    by 0x4B02B67: Py_InitializeFromConfig (pylifecycle.c:1238)
==93405==    by 0x4B24F3B: pymain_init (main.c:67)
==93405== 
==93405== 51 bytes in 1 blocks are possibly lost in loss record 98 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A6B783: PyUnicode_New (unicodeobject.c:1471)
==93405==    by 0x4A6BA9B: _PyUnicode_FromUCS1 (unicodeobject.c:2476)
==93405==    by 0x4A6BA9B: _PyUnicode_FromUCS1 (unicodeobject.c:2462)
==93405==    by 0x4AF7EE3: r_object (marshal.c:1151)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8883: r_object (marshal.c:1394)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405== 
==93405== 52 bytes in 1 blocks are possibly lost in loss record 102 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A6B783: PyUnicode_New (unicodeobject.c:1471)
==93405==    by 0x4A84007: unicode_decode_utf8 (unicodeobject.c:5184)
==93405==    by 0x4A3420F: PyDict_SetItemString (dictobject.c:3574)
==93405==    by 0x4AC464B: _PyBuiltin_Init (bltinmodule.c:3028)
==93405==    by 0x4B00A9F: pycore_init_builtins (pylifecycle.c:780)
==93405==    by 0x4B00A9F: pycore_interp_init (pylifecycle.c:863)
==93405==    by 0x4B0293F: pyinit_config (pylifecycle.c:900)
==93405==    by 0x4B0293F: pyinit_core.constprop.0 (pylifecycle.c:1063)
==93405==    by 0x4B02B67: Py_InitializeFromConfig (pylifecycle.c:1253)
==93405==    by 0x4B02B67: Py_InitializeFromConfig (pylifecycle.c:1238)
==93405==    by 0x4B24F3B: pymain_init (main.c:67)
==93405==    by 0x4B25F13: pymain_main (main.c:693)
==93405==    by 0x4B25F13: Py_BytesMain (main.c:726)
==93405==    by 0x4F2DF3B: __libc_start_call_main (libc_start_call_main.h:58)
==93405== 
==93405== 52 bytes in 1 blocks are possibly lost in loss record 103 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A6B783: PyUnicode_New (unicodeobject.c:1471)
==93405==    by 0x4A84007: unicode_decode_utf8 (unicodeobject.c:5184)
==93405==    by 0x4A3420F: PyDict_SetItemString (dictobject.c:3574)
==93405==    by 0x4AC4747: _PyBuiltin_Init (bltinmodule.c:3037)
==93405==    by 0x4B00A9F: pycore_init_builtins (pylifecycle.c:780)
==93405==    by 0x4B00A9F: pycore_interp_init (pylifecycle.c:863)
==93405==    by 0x4B0293F: pyinit_config (pylifecycle.c:900)
==93405==    by 0x4B0293F: pyinit_core.constprop.0 (pylifecycle.c:1063)
==93405==    by 0x4B02B67: Py_InitializeFromConfig (pylifecycle.c:1253)
==93405==    by 0x4B02B67: Py_InitializeFromConfig (pylifecycle.c:1238)
==93405==    by 0x4B24F3B: pymain_init (main.c:67)
==93405==    by 0x4B25F13: pymain_main (main.c:693)
==93405==    by 0x4B25F13: Py_BytesMain (main.c:726)
==93405==    by 0x4F2DF3B: __libc_start_call_main (libc_start_call_main.h:58)
==93405== 
==93405== 52 bytes in 1 blocks are possibly lost in loss record 104 of 819
==93405==    at 0x4869534: realloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A63DA3: resize_compact (unicodeobject.c:1087)
==93405==    by 0x4A83ED7: _PyUnicodeWriter_Finish (unicodeobject.c:14118)
==93405==    by 0x4A8C4E7: PyUnicode_Format (unicodeobject.c:15329)
==93405==    by 0x49DEA83: binary_op1 (abstract.c:892)
==93405==    by 0x49E0D9B: binary_op (abstract.c:931)
==93405==    by 0x49E0D9B: PyNumber_Remainder (abstract.c:1147)
==93405==    by 0x49A6D2B: _PyEval_EvalFrameDefault (ceval.c:5285)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FB623: _PyObject_FastCallDictTstate (call.c:141)
==93405==    by 0x49FB93B: _PyObject_Call_Prepend (call.c:481)
==93405==    by 0x4A5E937: slot_tp_init (typeobject.c:7877)
==93405==    by 0x4A57437: type_call (typeobject.c:1141)
==93405== 
==93405== 53 bytes in 1 blocks are possibly lost in loss record 112 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A6B783: PyUnicode_New (unicodeobject.c:1471)
==93405==    by 0x4A6BA9B: _PyUnicode_FromUCS1 (unicodeobject.c:2476)
==93405==    by 0x4A6BA9B: _PyUnicode_FromUCS1 (unicodeobject.c:2462)
==93405==    by 0x4AF7EE3: r_object (marshal.c:1151)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8883: r_object (marshal.c:1394)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF95AB: read_object (marshal.c:1525)
==93405==    by 0x4AF9843: marshal_loads_impl (marshal.c:1834)
==93405==    by 0x4AF9843: marshal_loads (marshal.c.h:148)
==93405==    by 0x4A3DB73: cfunction_vectorcall_O (methodobject.c:516)
==93405== 
==93405== 53 bytes in 1 blocks are possibly lost in loss record 113 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A6B783: PyUnicode_New (unicodeobject.c:1471)
==93405==    by 0x4A6BA9B: _PyUnicode_FromUCS1 (unicodeobject.c:2476)
==93405==    by 0x4A6BA9B: _PyUnicode_FromUCS1 (unicodeobject.c:2462)
==93405==    by 0x4AF7EE3: r_object (marshal.c:1151)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF95AB: read_object (marshal.c:1525)
==93405==    by 0x4AF9843: marshal_loads_impl (marshal.c:1834)
==93405==    by 0x4AF9843: marshal_loads (marshal.c.h:148)
==93405== 
==93405== 54 bytes in 1 blocks are possibly lost in loss record 122 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A6B783: PyUnicode_New (unicodeobject.c:1471)
==93405==    by 0x4A84007: unicode_decode_utf8 (unicodeobject.c:5184)
==93405==    by 0x4A8DDEF: PyUnicode_InternFromString (unicodeobject.c:15669)
==93405==    by 0x4A41783: PyObject_SetAttrString (object.c:844)
==93405==    by 0x4A3E8F7: _add_methods_to_object (moduleobject.c:184)
==93405==    by 0x4A3F487: PyModule_AddFunctions (moduleobject.c:466)
==93405==    by 0x4A3F567: _PyModule_CreateInitialized (moduleobject.c:253)
==93405==    by 0x4B16007: _PySys_Create (sysmodule.c:3065)
==93405==    by 0x4B00A8B: pycore_interp_init (pylifecycle.c:858)
==93405==    by 0x4B0293F: pyinit_config (pylifecycle.c:900)
==93405==    by 0x4B0293F: pyinit_core.constprop.0 (pylifecycle.c:1063)
==93405== 
==93405== 54 bytes in 1 blocks are possibly lost in loss record 123 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A6B783: PyUnicode_New (unicodeobject.c:1471)
==93405==    by 0x4A84007: unicode_decode_utf8 (unicodeobject.c:5184)
==93405==    by 0x4A3420F: PyDict_SetItemString (dictobject.c:3574)
==93405==    by 0x4B16B2B: _PySys_InitCore (sysmodule.c:2839)
==93405==    by 0x4B16B2B: _PySys_Create (sysmodule.c:3086)
==93405==    by 0x4B00A8B: pycore_interp_init (pylifecycle.c:858)
==93405==    by 0x4B0293F: pyinit_config (pylifecycle.c:900)
==93405==    by 0x4B0293F: pyinit_core.constprop.0 (pylifecycle.c:1063)
==93405==    by 0x4B02B67: Py_InitializeFromConfig (pylifecycle.c:1253)
==93405==    by 0x4B02B67: Py_InitializeFromConfig (pylifecycle.c:1238)
==93405==    by 0x4B24F3B: pymain_init (main.c:67)
==93405==    by 0x4B25F13: pymain_main (main.c:693)
==93405==    by 0x4B25F13: Py_BytesMain (main.c:726)
==93405==    by 0x4F2DF3B: __libc_start_call_main (libc_start_call_main.h:58)
==93405== 
==93405== 54 bytes in 1 blocks are possibly lost in loss record 124 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A6B783: PyUnicode_New (unicodeobject.c:1471)
==93405==    by 0x4A84007: unicode_decode_utf8 (unicodeobject.c:5184)
==93405==    by 0x4A3420F: PyDict_SetItemString (dictobject.c:3574)
==93405==    by 0x4AC454F: _PyBuiltin_Init (bltinmodule.c:3019)
==93405==    by 0x4B00A9F: pycore_init_builtins (pylifecycle.c:780)
==93405==    by 0x4B00A9F: pycore_interp_init (pylifecycle.c:863)
==93405==    by 0x4B0293F: pyinit_config (pylifecycle.c:900)
==93405==    by 0x4B0293F: pyinit_core.constprop.0 (pylifecycle.c:1063)
==93405==    by 0x4B02B67: Py_InitializeFromConfig (pylifecycle.c:1253)
==93405==    by 0x4B02B67: Py_InitializeFromConfig (pylifecycle.c:1238)
==93405==    by 0x4B24F3B: pymain_init (main.c:67)
==93405==    by 0x4B25F13: pymain_main (main.c:693)
==93405==    by 0x4B25F13: Py_BytesMain (main.c:726)
==93405==    by 0x4F2DF3B: __libc_start_call_main (libc_start_call_main.h:58)
==93405== 
==93405== 54 bytes in 1 blocks are possibly lost in loss record 125 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A6B783: PyUnicode_New (unicodeobject.c:1471)
==93405==    by 0x4A84007: unicode_decode_utf8 (unicodeobject.c:5184)
==93405==    by 0x4A3420F: PyDict_SetItemString (dictobject.c:3574)
==93405==    by 0x4AC4763: _PyBuiltin_Init (bltinmodule.c:3038)
==93405==    by 0x4B00A9F: pycore_init_builtins (pylifecycle.c:780)
==93405==    by 0x4B00A9F: pycore_interp_init (pylifecycle.c:863)
==93405==    by 0x4B0293F: pyinit_config (pylifecycle.c:900)
==93405==    by 0x4B0293F: pyinit_core.constprop.0 (pylifecycle.c:1063)
==93405==    by 0x4B02B67: Py_InitializeFromConfig (pylifecycle.c:1253)
==93405==    by 0x4B02B67: Py_InitializeFromConfig (pylifecycle.c:1238)
==93405==    by 0x4B24F3B: pymain_init (main.c:67)
==93405==    by 0x4B25F13: pymain_main (main.c:693)
==93405==    by 0x4B25F13: Py_BytesMain (main.c:726)
==93405==    by 0x4F2DF3B: __libc_start_call_main (libc_start_call_main.h:58)
==93405== 
==93405== 54 bytes in 1 blocks are possibly lost in loss record 126 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A6B783: PyUnicode_New (unicodeobject.c:1471)
==93405==    by 0x4A84007: unicode_decode_utf8 (unicodeobject.c:5184)
==93405==    by 0x4A52427: type_module (typeobject.c:587)
==93405==    by 0x4A62457: type_getattro (typeobject.c:3995)
==93405==    by 0x4A41877: PyObject_GetAttr (object.c:933)
==93405==    by 0x4A193B3: functools_copy_attr (funcobject.c:791)
==93405==    by 0x4A1948B: functools_wraps (funcobject.c:821)
==93405==    by 0x4A199B3: cm_init (funcobject.c:916)
==93405==    by 0x4A57437: type_call (typeobject.c:1141)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405== 
==93405== 56 bytes in 1 blocks are possibly lost in loss record 166 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A6B783: PyUnicode_New (unicodeobject.c:1471)
==93405==    by 0x4A84007: unicode_decode_utf8 (unicodeobject.c:5184)
==93405==    by 0x4A3420F: PyDict_SetItemString (dictobject.c:3574)
==93405==    by 0x4B16383: _PySys_InitCore (sysmodule.c:2791)
==93405==    by 0x4B16383: _PySys_Create (sysmodule.c:3086)
==93405==    by 0x4B00A8B: pycore_interp_init (pylifecycle.c:858)
==93405==    by 0x4B0293F: pyinit_config (pylifecycle.c:900)
==93405==    by 0x4B0293F: pyinit_core.constprop.0 (pylifecycle.c:1063)
==93405==    by 0x4B02B67: Py_InitializeFromConfig (pylifecycle.c:1253)
==93405==    by 0x4B02B67: Py_InitializeFromConfig (pylifecycle.c:1238)
==93405==    by 0x4B24F3B: pymain_init (main.c:67)
==93405==    by 0x4B25F13: pymain_main (main.c:693)
==93405==    by 0x4B25F13: Py_BytesMain (main.c:726)
==93405==    by 0x4F2DF3B: __libc_start_call_main (libc_start_call_main.h:58)
==93405== 
==93405== 56 bytes in 1 blocks are possibly lost in loss record 167 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A510CF: _PyTuple_FromArray (tupleobject.c:475)
==93405==    by 0x4A510CF: _PyTuple_FromArray (tupleobject.c:469)
==93405==    by 0x49FB427: _PyObject_MakeTpCall (call.c:188)
==93405==    by 0x4A60F47: type_new_init_subclass (typeobject.c:8650)
==93405==    by 0x4A60F47: type_new_impl (typeobject.c:3225)
==93405==    by 0x4A60F47: type_new (typeobject.c:3349)
==93405==    by 0x4A573E7: type_call (typeobject.c:1129)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x49FB623: _PyObject_FastCallDictTstate (call.c:141)
==93405==    by 0x4AC427B: builtin___build_class__ (bltinmodule.c:224)
==93405==    by 0x4A3D6B3: cfunction_vectorcall_FASTCALL_KEYWORDS (methodobject.c:446)
==93405== 
==93405== 56 bytes in 1 blocks are possibly lost in loss record 168 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:155)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:147)
==93405==    by 0x49FACFB: _PyStack_UnpackDict (call.c:965)
==93405==    by 0x49FB683: _PyObject_FastCallDictTstate (call.c:146)
==93405==    by 0x49FB93B: _PyObject_Call_Prepend (call.c:481)
==93405==    by 0x4A5E937: slot_tp_init (typeobject.c:7877)
==93405==    by 0x4A57437: type_call (typeobject.c:1141)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405== 
==93405== 56 bytes in 1 blocks are possibly lost in loss record 169 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A510CF: _PyTuple_FromArray (tupleobject.c:475)
==93405==    by 0x4A510CF: _PyTuple_FromArray (tupleobject.c:469)
==93405==    by 0x4A06CAB: method_vectorcall_VARARGS (descrobject.c:302)
==93405==    by 0x49FBAE7: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBAE7: PyObject_Vectorcall (call.c:298)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x4AC7877: PyEval_EvalCode (ceval.c:1120)
==93405==    by 0x4AC15BF: builtin_exec_impl (bltinmodule.c:1057)
==93405==    by 0x4AC15BF: builtin_exec (bltinmodule.c.h:371)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405== 
==93405== 56 bytes in 1 blocks are possibly lost in loss record 170 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:155)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:147)
==93405==    by 0x4AF8323: r_object (marshal.c:1207)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405== 
==93405== 56 bytes in 1 blocks are possibly lost in loss record 171 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:155)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:147)
==93405==    by 0x4AF8323: r_object (marshal.c:1207)
==93405==    by 0x4AF8883: r_object (marshal.c:1394)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405== 
==93405== 56 bytes in 1 blocks are possibly lost in loss record 172 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:155)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:147)
==93405==    by 0x49A5CA3: _PyEval_EvalFrameDefault (ceval.c:3180)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x4AC7877: PyEval_EvalCode (ceval.c:1120)
==93405==    by 0x4AC15BF: builtin_exec_impl (bltinmodule.c:1057)
==93405==    by 0x4AC15BF: builtin_exec (bltinmodule.c.h:371)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== 56 bytes in 1 blocks are possibly lost in loss record 173 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A5688F: _PyType_AllocNoTrack (typeobject.c:1162)
==93405==    by 0x4A56953: PyType_GenericAlloc (typeobject.c:1186)
==93405==    by 0x4A1F8CB: list_vectorcall (listobject.c:2865)
==93405==    by 0x49AA19B: _PyEval_EvalFrameDefault (ceval.c:4785)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FB623: _PyObject_FastCallDictTstate (call.c:141)
==93405==    by 0x49FB93B: _PyObject_Call_Prepend (call.c:481)
==93405==    by 0x4A531DF: slot_tp_new (typeobject.c:7907)
==93405==    by 0x4A573E7: type_call (typeobject.c:1129)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405== 
==93405== 56 bytes in 1 blocks are possibly lost in loss record 174 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:155)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:147)
==93405==    by 0x4A6187F: mro_implementation (typeobject.c:1967)
==93405==    by 0x4A61BF3: mro_invoke (typeobject.c:2104)
==93405==    by 0x4A61BF3: mro_internal (typeobject.c:2161)
==93405==    by 0x4A57A9F: type_ready_mro (typeobject.c:6238)
==93405==    by 0x4A57A9F: type_ready (typeobject.c:6468)
==93405==    by 0x4A57A9F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x66579A7: _ctypes_add_types (_ctypes.c:5710)
==93405==    by 0x66579A7: _ctypes_mod_exec (_ctypes.c:5837)
==93405==    by 0x66579A7: PyInit__ctypes (_ctypes.c:5859)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405== 
==93405== 56 bytes in 1 blocks are possibly lost in loss record 175 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:155)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:147)
==93405==    by 0x4A6187F: mro_implementation (typeobject.c:1967)
==93405==    by 0x4A61BF3: mro_invoke (typeobject.c:2104)
==93405==    by 0x4A61BF3: mro_internal (typeobject.c:2161)
==93405==    by 0x4A57A9F: type_ready_mro (typeobject.c:6238)
==93405==    by 0x4A57A9F: type_ready (typeobject.c:6468)
==93405==    by 0x4A57A9F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x66579BF: _ctypes_add_types (_ctypes.c:5711)
==93405==    by 0x66579BF: _ctypes_mod_exec (_ctypes.c:5837)
==93405==    by 0x66579BF: PyInit__ctypes (_ctypes.c:5859)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405== 
==93405== 56 bytes in 1 blocks are possibly lost in loss record 176 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:155)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:147)
==93405==    by 0x4A6187F: mro_implementation (typeobject.c:1967)
==93405==    by 0x4A61BF3: mro_invoke (typeobject.c:2104)
==93405==    by 0x4A61BF3: mro_internal (typeobject.c:2161)
==93405==    by 0x4A57A9F: type_ready_mro (typeobject.c:6238)
==93405==    by 0x4A57A9F: type_ready (typeobject.c:6468)
==93405==    by 0x4A57A9F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x6657B17: _ctypes_add_types (_ctypes.c:5744)
==93405==    by 0x6657B17: _ctypes_mod_exec (_ctypes.c:5837)
==93405==    by 0x6657B17: PyInit__ctypes (_ctypes.c:5859)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405== 
==93405== 56 bytes in 1 blocks are possibly lost in loss record 177 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:155)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:147)
==93405==    by 0x4A6187F: mro_implementation (typeobject.c:1967)
==93405==    by 0x4A61BF3: mro_invoke (typeobject.c:2104)
==93405==    by 0x4A61BF3: mro_internal (typeobject.c:2161)
==93405==    by 0x4A57A9F: type_ready_mro (typeobject.c:6238)
==93405==    by 0x4A57A9F: type_ready (typeobject.c:6468)
==93405==    by 0x4A57A9F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x6657B2F: _ctypes_add_types (_ctypes.c:5752)
==93405==    by 0x6657B2F: _ctypes_mod_exec (_ctypes.c:5837)
==93405==    by 0x6657B2F: PyInit__ctypes (_ctypes.c:5859)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405== 
==93405== 56 bytes in 1 blocks are possibly lost in loss record 178 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:155)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:147)
==93405==    by 0x4A6187F: mro_implementation (typeobject.c:1967)
==93405==    by 0x4A61BF3: mro_invoke (typeobject.c:2104)
==93405==    by 0x4A61BF3: mro_internal (typeobject.c:2161)
==93405==    by 0x4A57A9F: type_ready_mro (typeobject.c:6238)
==93405==    by 0x4A57A9F: type_ready (typeobject.c:6468)
==93405==    by 0x4A57A9F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x6657B3B: _ctypes_add_types (_ctypes.c:5753)
==93405==    by 0x6657B3B: _ctypes_mod_exec (_ctypes.c:5837)
==93405==    by 0x6657B3B: PyInit__ctypes (_ctypes.c:5859)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405== 
==93405== 56 bytes in 1 blocks are possibly lost in loss record 179 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A5688F: _PyType_AllocNoTrack (typeobject.c:1162)
==93405==    by 0x4A56953: PyType_GenericAlloc (typeobject.c:1186)
==93405==    by 0x662BA67: s_new (_struct.c:1448)
==93405==    by 0x4A573E7: type_call (typeobject.c:1129)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x49FBA93: _PyObject_VectorcallTstate (pycore_call.h:87)
==93405==    by 0x49FBA93: _PyObject_VectorcallTstate (pycore_call.h:74)
==93405==    by 0x49FBA93: PyObject_CallOneArg (call.c:375)
==93405==    by 0x662E397: cache_struct_converter (_struct.c:2137)
==93405==    by 0x662E523: pack (_struct.c:2199)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405== 
==93405== 56 bytes in 1 blocks are possibly lost in loss record 180 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A5688F: _PyType_AllocNoTrack (typeobject.c:1162)
==93405==    by 0x4A56953: PyType_GenericAlloc (typeobject.c:1186)
==93405==    by 0x662BA67: s_new (_struct.c:1448)
==93405==    by 0x4A573E7: type_call (typeobject.c:1129)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x49FBA93: _PyObject_VectorcallTstate (pycore_call.h:87)
==93405==    by 0x49FBA93: _PyObject_VectorcallTstate (pycore_call.h:74)
==93405==    by 0x49FBA93: PyObject_CallOneArg (call.c:375)
==93405==    by 0x662E397: cache_struct_converter (_struct.c:2137)
==93405==    by 0x662E6D3: unpack (_struct.c.h:244)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49FBAE7: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBAE7: PyObject_Vectorcall (call.c:298)
==93405== 
==93405== 57 bytes in 1 blocks are possibly lost in loss record 203 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A6B783: PyUnicode_New (unicodeobject.c:1471)
==93405==    by 0x4A84007: unicode_decode_utf8 (unicodeobject.c:5184)
==93405==    by 0x4A3420F: PyDict_SetItemString (dictobject.c:3574)
==93405==    by 0x4B1634F: _PySys_InitCore (sysmodule.c:2790)
==93405==    by 0x4B1634F: _PySys_Create (sysmodule.c:3086)
==93405==    by 0x4B00A8B: pycore_interp_init (pylifecycle.c:858)
==93405==    by 0x4B0293F: pyinit_config (pylifecycle.c:900)
==93405==    by 0x4B0293F: pyinit_core.constprop.0 (pylifecycle.c:1063)
==93405==    by 0x4B02B67: Py_InitializeFromConfig (pylifecycle.c:1253)
==93405==    by 0x4B02B67: Py_InitializeFromConfig (pylifecycle.c:1238)
==93405==    by 0x4B24F3B: pymain_init (main.c:67)
==93405==    by 0x4B25F13: pymain_main (main.c:693)
==93405==    by 0x4B25F13: Py_BytesMain (main.c:726)
==93405==    by 0x4F2DF3B: __libc_start_call_main (libc_start_call_main.h:58)
==93405== 
==93405== 58 bytes in 1 blocks are possibly lost in loss record 227 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A6B783: PyUnicode_New (unicodeobject.c:1471)
==93405==    by 0x4A6BA9B: _PyUnicode_FromUCS1 (unicodeobject.c:2476)
==93405==    by 0x4A6BA9B: _PyUnicode_FromUCS1 (unicodeobject.c:2462)
==93405==    by 0x4AF7EE3: r_object (marshal.c:1151)
==93405==    by 0x4AF88B3: r_object (marshal.c:1403)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405== 
==93405== 59 bytes in 1 blocks are possibly lost in loss record 244 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x49F121F: _PyBytes_FromSize (bytesobject.c:104)
==93405==    by 0x49F121F: _PyBytes_FromSize (bytesobject.c:85)
==93405==    by 0x49F1EAB: PyBytes_FromStringAndSize (bytesobject.c:134)
==93405==    by 0x49F1EAB: PyBytes_FromStringAndSize (bytesobject.c:117)
==93405==    by 0x4AF8673: r_object (marshal.c:1108)
==93405==    by 0x4AF884F: r_object (marshal.c:1385)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405== 
==93405== 59 bytes in 1 blocks are possibly lost in loss record 245 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x49F121F: _PyBytes_FromSize (bytesobject.c:104)
==93405==    by 0x49F121F: _PyBytes_FromSize (bytesobject.c:85)
==93405==    by 0x49F1EAB: PyBytes_FromStringAndSize (bytesobject.c:134)
==93405==    by 0x49F1EAB: PyBytes_FromStringAndSize (bytesobject.c:117)
==93405==    by 0x4AF8673: r_object (marshal.c:1108)
==93405==    by 0x4AF8907: r_object (marshal.c:1418)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405== 
==93405== 61 bytes in 1 blocks are possibly lost in loss record 280 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A6B783: PyUnicode_New (unicodeobject.c:1471)
==93405==    by 0x4A84007: unicode_decode_utf8 (unicodeobject.c:5184)
==93405==    by 0x4A62457: type_getattro (typeobject.c:3995)
==93405==    by 0x4A41877: PyObject_GetAttr (object.c:933)
==93405==    by 0x4A193B3: functools_copy_attr (funcobject.c:791)
==93405==    by 0x4A194AB: functools_wraps (funcobject.c:822)
==93405==    by 0x4A199B3: cm_init (funcobject.c:916)
==93405==    by 0x4A57437: type_call (typeobject.c:1141)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405== 
==93405== 61 bytes in 1 blocks are possibly lost in loss record 281 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A6B783: PyUnicode_New (unicodeobject.c:1471)
==93405==    by 0x4A84007: unicode_decode_utf8 (unicodeobject.c:5184)
==93405==    by 0x4A62457: type_getattro (typeobject.c:3995)
==93405==    by 0x4A41877: PyObject_GetAttr (object.c:933)
==93405==    by 0x4A193B3: functools_copy_attr (funcobject.c:791)
==93405==    by 0x4A194CB: functools_wraps (funcobject.c:823)
==93405==    by 0x4A199B3: cm_init (funcobject.c:916)
==93405==    by 0x4A57437: type_call (typeobject.c:1141)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405== 
==93405== 61 bytes in 1 blocks are possibly lost in loss record 282 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A6B783: PyUnicode_New (unicodeobject.c:1471)
==93405==    by 0x4A84007: unicode_decode_utf8 (unicodeobject.c:5184)
==93405==    by 0x4A57D7F: type_dict_set_doc (typeobject.c:6191)
==93405==    by 0x4A57D7F: type_ready_fill_dict (typeobject.c:6227)
==93405==    by 0x4A57D7F: type_ready (typeobject.c:6474)
==93405==    by 0x4A57D7F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x66579A7: _ctypes_add_types (_ctypes.c:5710)
==93405==    by 0x66579A7: _ctypes_mod_exec (_ctypes.c:5837)
==93405==    by 0x66579A7: PyInit__ctypes (_ctypes.c:5859)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405== 
==93405== 64 bytes in 1 blocks are possibly lost in loss record 358 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B285FF: _PyObject_GC_New (gcmodule.c:2300)
==93405==    by 0x4A2D4EB: new_dict (dictobject.c:667)
==93405==    by 0x4A3EE6F: new_module_notrack (moduleobject.c:100)
==93405==    by 0x4A3EE6F: PyModule_NewObject (moduleobject.c:121)
==93405==    by 0x4A3EEFB: PyModule_New (moduleobject.c:141)
==93405==    by 0x4A3F543: _PyModule_CreateInitialized (moduleobject.c:239)
==93405==    by 0x4B16007: _PySys_Create (sysmodule.c:3065)
==93405==    by 0x4B00A8B: pycore_interp_init (pylifecycle.c:858)
==93405==    by 0x4B0293F: pyinit_config (pylifecycle.c:900)
==93405==    by 0x4B0293F: pyinit_core.constprop.0 (pylifecycle.c:1063)
==93405==    by 0x4B02B67: Py_InitializeFromConfig (pylifecycle.c:1253)
==93405==    by 0x4B02B67: Py_InitializeFromConfig (pylifecycle.c:1238)
==93405== 
==93405== 64 bytes in 1 blocks are possibly lost in loss record 359 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B285FF: _PyObject_GC_New (gcmodule.c:2300)
==93405==    by 0x4A2D4EB: new_dict (dictobject.c:667)
==93405==    by 0x4A3EE6F: new_module_notrack (moduleobject.c:100)
==93405==    by 0x4A3EE6F: PyModule_NewObject (moduleobject.c:121)
==93405==    by 0x4A3EEFB: PyModule_New (moduleobject.c:141)
==93405==    by 0x4A3F543: _PyModule_CreateInitialized (moduleobject.c:239)
==93405==    by 0x4AC444B: _PyBuiltin_Init (bltinmodule.c:2989)
==93405==    by 0x4B00A9F: pycore_init_builtins (pylifecycle.c:780)
==93405==    by 0x4B00A9F: pycore_interp_init (pylifecycle.c:863)
==93405==    by 0x4B0293F: pyinit_config (pylifecycle.c:900)
==93405==    by 0x4B0293F: pyinit_core.constprop.0 (pylifecycle.c:1063)
==93405==    by 0x4B02B67: Py_InitializeFromConfig (pylifecycle.c:1253)
==93405==    by 0x4B02B67: Py_InitializeFromConfig (pylifecycle.c:1238)
==93405== 
==93405== 64 bytes in 1 blocks are possibly lost in loss record 360 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B285FF: _PyObject_GC_New (gcmodule.c:2300)
==93405==    by 0x4A2D4EB: new_dict (dictobject.c:667)
==93405==    by 0x4A33AD7: PyDict_Copy (dictobject.c:2771)
==93405==    by 0x4A60E13: type_new_set_names (typeobject.c:8607)
==93405==    by 0x4A60E13: type_new_impl (typeobject.c:3221)
==93405==    by 0x4A60E13: type_new (typeobject.c:3349)
==93405==    by 0x4A573E7: type_call (typeobject.c:1129)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x49FC38B: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FC38B: _PyObject_CallFunctionVa (call.c:535)
==93405==    by 0x49FC61F: PyObject_CallFunction (call.c:557)
==93405==    by 0x4AE0723: PyErr_NewException (errors.c:1160)
==93405== 
==93405== 64 bytes in 1 blocks are possibly lost in loss record 361 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B285FF: _PyObject_GC_New (gcmodule.c:2300)
==93405==    by 0x4A2D4EB: new_dict (dictobject.c:667)
==93405==    by 0x49A621B: _PyEval_EvalFrameDefault (ceval.c:3360)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x4AC4237: builtin___build_class__ (bltinmodule.c:216)
==93405==    by 0x4A3D6B3: cfunction_vectorcall_FASTCALL_KEYWORDS (methodobject.c:446)
==93405==    by 0x49FBAE7: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBAE7: PyObject_Vectorcall (call.c:298)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== 64 bytes in 1 blocks are possibly lost in loss record 362 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B285FF: _PyObject_GC_New (gcmodule.c:2300)
==93405==    by 0x4A2D4EB: new_dict (dictobject.c:667)
==93405==    by 0x49A5567: _PyEval_EvalFrameDefault (ceval.c:3269)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405==    by 0x49FC17B: _PyObject_CallMethodIdObjArgs (call.c:875)
==93405==    by 0x4AEF4CF: import_find_and_load (import.c:1739)
==93405==    by 0x4AEF4CF: PyImport_ImportModuleLevelObject (import.c:1840)
==93405==    by 0x49AF6C3: import_name (ceval.c:7106)
==93405==    by 0x49AF6C3: _PyEval_EvalFrameDefault (ceval.c:3885)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== 64 bytes in 1 blocks are possibly lost in loss record 363 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B285FF: _PyObject_GC_New (gcmodule.c:2300)
==93405==    by 0x4A2D4EB: new_dict (dictobject.c:667)
==93405==    by 0x4A34C63: _PyObjectDict_SetItem (dictobject.c:5261)
==93405==    by 0x4A414F7: _PyObject_GenericSetAttrWithDict (object.c:1426)
==93405==    by 0x4A415FB: PyObject_SetAttr (object.c:1048)
==93405==    by 0x4B529C7: _io_FileIO___init___impl (fileio.c:479)
==93405==    by 0x4B529C7: _io_FileIO___init__ (fileio.c.h:100)
==93405==    by 0x4A57437: type_call (typeobject.c:1141)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x49FC503: _PyObject_VectorcallTstate (pycore_call.h:87)
==93405==    by 0x49FC503: _PyObject_VectorcallTstate (pycore_call.h:74)
==93405==    by 0x49FC503: _PyObject_CallFunctionVa (call.c:535)
==93405== 
==93405== 64 bytes in 1 blocks are possibly lost in loss record 364 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B285FF: _PyObject_GC_New (gcmodule.c:2300)
==93405==    by 0x4A2D4EB: new_dict (dictobject.c:667)
==93405==    by 0x4A3EE6F: new_module_notrack (moduleobject.c:100)
==93405==    by 0x4A3EE6F: PyModule_NewObject (moduleobject.c:121)
==93405==    by 0x4A3F2BB: PyModule_FromDefAndSpec2 (moduleobject.c:342)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405== 
==93405== 64 bytes in 1 blocks are possibly lost in loss record 365 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B285FF: _PyObject_GC_New (gcmodule.c:2300)
==93405==    by 0x4A2D4EB: new_dict (dictobject.c:667)
==93405==    by 0x4A3EE6F: new_module_notrack (moduleobject.c:100)
==93405==    by 0x4A3EE6F: PyModule_NewObject (moduleobject.c:121)
==93405==    by 0x4A3EEFB: PyModule_New (moduleobject.c:141)
==93405==    by 0x4A3F543: _PyModule_CreateInitialized (moduleobject.c:239)
==93405==    by 0x665793B: PyInit__ctypes (_ctypes.c:5854)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405== 
==93405== 64 bytes in 1 blocks are possibly lost in loss record 366 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:155)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:147)
==93405==    by 0x4A6187F: mro_implementation (typeobject.c:1967)
==93405==    by 0x4A61BF3: mro_invoke (typeobject.c:2104)
==93405==    by 0x4A61BF3: mro_internal (typeobject.c:2161)
==93405==    by 0x4A57A9F: type_ready_mro (typeobject.c:6238)
==93405==    by 0x4A57A9F: type_ready (typeobject.c:6468)
==93405==    by 0x4A57A9F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x66579FF: _ctypes_add_types (_ctypes.c:5719)
==93405==    by 0x66579FF: _ctypes_mod_exec (_ctypes.c:5837)
==93405==    by 0x66579FF: PyInit__ctypes (_ctypes.c:5859)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405== 
==93405== 64 bytes in 1 blocks are possibly lost in loss record 367 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:155)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:147)
==93405==    by 0x4A6187F: mro_implementation (typeobject.c:1967)
==93405==    by 0x4A61BF3: mro_invoke (typeobject.c:2104)
==93405==    by 0x4A61BF3: mro_internal (typeobject.c:2161)
==93405==    by 0x4A57A9F: type_ready_mro (typeobject.c:6238)
==93405==    by 0x4A57A9F: type_ready (typeobject.c:6468)
==93405==    by 0x4A57A9F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x6657A0F: _ctypes_add_types (_ctypes.c:5720)
==93405==    by 0x6657A0F: _ctypes_mod_exec (_ctypes.c:5837)
==93405==    by 0x6657A0F: PyInit__ctypes (_ctypes.c:5859)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405== 
==93405== 64 bytes in 1 blocks are possibly lost in loss record 368 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:155)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:147)
==93405==    by 0x4A6187F: mro_implementation (typeobject.c:1967)
==93405==    by 0x4A61BF3: mro_invoke (typeobject.c:2104)
==93405==    by 0x4A61BF3: mro_internal (typeobject.c:2161)
==93405==    by 0x4A57A9F: type_ready_mro (typeobject.c:6238)
==93405==    by 0x4A57A9F: type_ready (typeobject.c:6468)
==93405==    by 0x4A57A9F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x6657A2B: _ctypes_add_types (_ctypes.c:5721)
==93405==    by 0x6657A2B: _ctypes_mod_exec (_ctypes.c:5837)
==93405==    by 0x6657A2B: PyInit__ctypes (_ctypes.c:5859)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405== 
==93405== 64 bytes in 1 blocks are possibly lost in loss record 369 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:155)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:147)
==93405==    by 0x4A6187F: mro_implementation (typeobject.c:1967)
==93405==    by 0x4A61BF3: mro_invoke (typeobject.c:2104)
==93405==    by 0x4A61BF3: mro_internal (typeobject.c:2161)
==93405==    by 0x4A57A9F: type_ready_mro (typeobject.c:6238)
==93405==    by 0x4A57A9F: type_ready (typeobject.c:6468)
==93405==    by 0x4A57A9F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x6657A43: _ctypes_add_types (_ctypes.c:5722)
==93405==    by 0x6657A43: _ctypes_mod_exec (_ctypes.c:5837)
==93405==    by 0x6657A43: PyInit__ctypes (_ctypes.c:5859)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405== 
==93405== 64 bytes in 1 blocks are possibly lost in loss record 370 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:155)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:147)
==93405==    by 0x4A6187F: mro_implementation (typeobject.c:1967)
==93405==    by 0x4A61BF3: mro_invoke (typeobject.c:2104)
==93405==    by 0x4A61BF3: mro_internal (typeobject.c:2161)
==93405==    by 0x4A57A9F: type_ready_mro (typeobject.c:6238)
==93405==    by 0x4A57A9F: type_ready (typeobject.c:6468)
==93405==    by 0x4A57A9F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x6657A53: _ctypes_add_types (_ctypes.c:5723)
==93405==    by 0x6657A53: _ctypes_mod_exec (_ctypes.c:5837)
==93405==    by 0x6657A53: PyInit__ctypes (_ctypes.c:5859)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405== 
==93405== 64 bytes in 1 blocks are possibly lost in loss record 371 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:155)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:147)
==93405==    by 0x4A6187F: mro_implementation (typeobject.c:1967)
==93405==    by 0x4A61BF3: mro_invoke (typeobject.c:2104)
==93405==    by 0x4A61BF3: mro_internal (typeobject.c:2161)
==93405==    by 0x4A57A9F: type_ready_mro (typeobject.c:6238)
==93405==    by 0x4A57A9F: type_ready (typeobject.c:6468)
==93405==    by 0x4A57A9F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x6657A67: _ctypes_add_types (_ctypes.c:5724)
==93405==    by 0x6657A67: _ctypes_mod_exec (_ctypes.c:5837)
==93405==    by 0x6657A67: PyInit__ctypes (_ctypes.c:5859)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405== 
==93405== 64 bytes in 1 blocks are possibly lost in loss record 372 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B285FF: _PyObject_GC_New (gcmodule.c:2300)
==93405==    by 0x4A2D4EB: new_dict (dictobject.c:667)
==93405==    by 0x4A58EC3: type_ready_set_dict (typeobject.c:6166)
==93405==    by 0x4A58EC3: type_ready (typeobject.c:6462)
==93405==    by 0x4A58EC3: PyType_Ready (typeobject.c:6510)
==93405==    by 0x6657B3B: _ctypes_add_types (_ctypes.c:5753)
==93405==    by 0x6657B3B: _ctypes_mod_exec (_ctypes.c:5837)
==93405==    by 0x6657B3B: PyInit__ctypes (_ctypes.c:5859)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== 64 bytes in 1 blocks are possibly lost in loss record 373 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B285FF: _PyObject_GC_New (gcmodule.c:2300)
==93405==    by 0x4A2D4EB: new_dict (dictobject.c:667)
==93405==    by 0x4A33AD7: PyDict_Copy (dictobject.c:2771)
==93405==    by 0x4A60E13: type_new_set_names (typeobject.c:8607)
==93405==    by 0x4A60E13: type_new_impl (typeobject.c:3221)
==93405==    by 0x4A60E13: type_new (typeobject.c:3349)
==93405==    by 0x6655477: PyCSimpleType_new (_ctypes.c:2087)
==93405==    by 0x4A573E7: type_call (typeobject.c:1129)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x4AC427B: builtin___build_class__ (bltinmodule.c:224)
==93405==    by 0x4A3D6B3: cfunction_vectorcall_FASTCALL_KEYWORDS (methodobject.c:446)
==93405== 
==93405== 64 bytes in 1 blocks are possibly lost in loss record 374 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x662D4F7: prepare_s (_struct.c:1382)
==93405==    by 0x662D4F7: Struct___init___impl (_struct.c:1498)
==93405==    by 0x662D4F7: Struct___init__ (_struct.c.h:35)
==93405==    by 0x4A57437: type_call (typeobject.c:1141)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x49FBA93: _PyObject_VectorcallTstate (pycore_call.h:87)
==93405==    by 0x49FBA93: _PyObject_VectorcallTstate (pycore_call.h:74)
==93405==    by 0x49FBA93: PyObject_CallOneArg (call.c:375)
==93405==    by 0x662E397: cache_struct_converter (_struct.c:2137)
==93405==    by 0x662E6D3: unpack (_struct.c.h:244)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49FBAE7: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBAE7: PyObject_Vectorcall (call.c:298)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== 72 bytes in 1 blocks are possibly lost in loss record 431 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B285FF: _PyObject_GC_New (gcmodule.c:2300)
==93405==    by 0x4A3E067: PyCMethod_New (methodobject.c:101)
==93405==    by 0x4A3E8DF: _add_methods_to_object (moduleobject.c:180)
==93405==    by 0x4A3F0DB: PyModule_FromDefAndSpec2 (moduleobject.c:370)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405== 
==93405== 72 bytes in 1 blocks are possibly lost in loss record 432 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A510CF: _PyTuple_FromArray (tupleobject.c:475)
==93405==    by 0x4A510CF: _PyTuple_FromArray (tupleobject.c:469)
==93405==    by 0x49A587B: _PyEval_EvalFrameDefault (ceval.c:3205)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405==    by 0x49FC17B: _PyObject_CallMethodIdObjArgs (call.c:875)
==93405==    by 0x4AEF4CF: import_find_and_load (import.c:1739)
==93405==    by 0x4AEF4CF: PyImport_ImportModuleLevelObject (import.c:1840)
==93405==    by 0x49AF6C3: import_name (ceval.c:7106)
==93405==    by 0x49AF6C3: _PyEval_EvalFrameDefault (ceval.c:3885)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== 77 bytes in 1 blocks are possibly lost in loss record 437 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A6B783: PyUnicode_New (unicodeobject.c:1471)
==93405==    by 0x4A7EB1F: _PyUnicode_JoinArray (unicodeobject.c:10220)
==93405==    by 0x4A7EDAF: PyUnicode_Join (unicodeobject.c:10112)
==93405==    by 0x49AC5CB: _PyEval_EvalFrameDefault (ceval.c:5012)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405==    by 0x49FC17B: _PyObject_CallMethodIdObjArgs (call.c:875)
==93405==    by 0x4AEF4CF: import_find_and_load (import.c:1739)
==93405==    by 0x4AEF4CF: PyImport_ImportModuleLevelObject (import.c:1840)
==93405==    by 0x49AF6C3: import_name (ceval.c:7106)
==93405==    by 0x49AF6C3: _PyEval_EvalFrameDefault (ceval.c:3885)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== 80 bytes in 1 blocks are possibly lost in loss record 468 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:155)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:147)
==93405==    by 0x49A5CA3: _PyEval_EvalFrameDefault (ceval.c:3180)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x4AC4237: builtin___build_class__ (bltinmodule.c:216)
==93405==    by 0x4A3D6B3: cfunction_vectorcall_FASTCALL_KEYWORDS (methodobject.c:446)
==93405==    by 0x49FBAE7: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBAE7: PyObject_Vectorcall (call.c:298)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== 80 bytes in 1 blocks are possibly lost in loss record 469 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A510CF: _PyTuple_FromArray (tupleobject.c:475)
==93405==    by 0x4A510CF: _PyTuple_FromArray (tupleobject.c:469)
==93405==    by 0x49FB427: _PyObject_MakeTpCall (call.c:188)
==93405==    by 0x49FC503: _PyObject_VectorcallTstate (pycore_call.h:87)
==93405==    by 0x49FC503: _PyObject_VectorcallTstate (pycore_call.h:74)
==93405==    by 0x49FC503: _PyObject_CallFunctionVa (call.c:535)
==93405==    by 0x49FC61F: PyObject_CallFunction (call.c:557)
==93405==    by 0x4AEFCD7: PyImport_Import (import.c:2045)
==93405==    by 0x4AEFECF: PyImport_ImportModule (import.c:1452)
==93405==    by 0x4A136DB: PyFile_OpenCodeObject (fileobject.c:510)
==93405==    by 0x4B4DD23: _io_open_code_impl (_iomodule.c:543)
==93405==    by 0x4B4DD23: _io_open_code (_iomodule.c.h:352)
==93405== 
==93405== 88 bytes in 1 blocks are possibly lost in loss record 475 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:155)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:147)
==93405==    by 0x4AF8323: r_object (marshal.c:1207)
==93405==    by 0x4AF8873: r_object (marshal.c:1391)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405== 
==93405== 89 bytes in 1 blocks are possibly lost in loss record 478 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A6B783: PyUnicode_New (unicodeobject.c:1471)
==93405==    by 0x4A6BA9B: _PyUnicode_FromUCS1 (unicodeobject.c:2476)
==93405==    by 0x4A6BA9B: _PyUnicode_FromUCS1 (unicodeobject.c:2462)
==93405==    by 0x4AF7EE3: r_object (marshal.c:1151)
==93405==    by 0x4AF88C3: r_object (marshal.c:1406)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF95AB: read_object (marshal.c:1525)
==93405==    by 0x4AF9843: marshal_loads_impl (marshal.c:1834)
==93405==    by 0x4AF9843: marshal_loads (marshal.c.h:148)
==93405== 
==93405== 96 bytes in 1 blocks are possibly lost in loss record 481 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x662D4F7: prepare_s (_struct.c:1382)
==93405==    by 0x662D4F7: Struct___init___impl (_struct.c:1498)
==93405==    by 0x662D4F7: Struct___init__ (_struct.c.h:35)
==93405==    by 0x4A57437: type_call (typeobject.c:1141)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x49FBA93: _PyObject_VectorcallTstate (pycore_call.h:87)
==93405==    by 0x49FBA93: _PyObject_VectorcallTstate (pycore_call.h:74)
==93405==    by 0x49FBA93: PyObject_CallOneArg (call.c:375)
==93405==    by 0x662E397: cache_struct_converter (_struct.c:2137)
==93405==    by 0x662E523: pack (_struct.c:2199)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FB623: _PyObject_FastCallDictTstate (call.c:141)
==93405== 
==93405== 96 bytes in 2 blocks are possibly lost in loss record 482 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50F83: PyTuple_Pack (tupleobject.c:246)
==93405==    by 0x4A5905F: type_ready_set_bases (typeobject.c:6148)
==93405==    by 0x4A5905F: type_ready (typeobject.c:6465)
==93405==    by 0x4A5905F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x4A40D8B: _PyTypes_InitTypes (object.c:1966)
==93405==    by 0x4B0098B: pycore_init_types (pylifecycle.c:717)
==93405==    by 0x4B0098B: pycore_interp_init (pylifecycle.c:844)
==93405==    by 0x4B0293F: pyinit_config (pylifecycle.c:900)
==93405==    by 0x4B0293F: pyinit_core.constprop.0 (pylifecycle.c:1063)
==93405==    by 0x4B02B67: Py_InitializeFromConfig (pylifecycle.c:1253)
==93405==    by 0x4B02B67: Py_InitializeFromConfig (pylifecycle.c:1238)
==93405==    by 0x4B24F3B: pymain_init (main.c:67)
==93405==    by 0x4B25F13: pymain_main (main.c:693)
==93405==    by 0x4B25F13: Py_BytesMain (main.c:726)
==93405== 
==93405== 96 bytes in 2 blocks are possibly lost in loss record 483 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A510CF: _PyTuple_FromArray (tupleobject.c:475)
==93405==    by 0x4A510CF: _PyTuple_FromArray (tupleobject.c:469)
==93405==    by 0x49FB427: _PyObject_MakeTpCall (call.c:188)
==93405==    by 0x49FBA93: _PyObject_VectorcallTstate (pycore_call.h:87)
==93405==    by 0x49FBA93: _PyObject_VectorcallTstate (pycore_call.h:74)
==93405==    by 0x49FBA93: PyObject_CallOneArg (call.c:375)
==93405==    by 0x4ADF263: _PyErr_CreateException (errors.c:105)
==93405==    by 0x4ADF50F: _PyErr_SetObject (errors.c:147)
==93405==    by 0x4ADF50F: _PyErr_SetObject (errors.c:120)
==93405==    by 0x4ADF1AF: _PyErr_FormatV (errors.c:1068)
==93405==    by 0x4ADF1AF: PyErr_Format (errors.c:1108)
==93405==    by 0x4A625AF: type_getattro (typeobject.c:4007)
==93405==    by 0x4A42023: _PyObject_LookupAttr (object.c:971)
==93405== 
==93405== 100 bytes in 2 blocks are possibly lost in loss record 484 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A6B783: PyUnicode_New (unicodeobject.c:1471)
==93405==    by 0x4A6B9B3: get_latin1_char (unicodeobject.c:2170)
==93405==    by 0x4AF7EE3: r_object (marshal.c:1151)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF95AB: read_object (marshal.c:1525)
==93405==    by 0x4AF9B93: PyMarshal_ReadObjectFromString (marshal.c:1642)
==93405==    by 0x4B888C7: _PyConfig_InitPathConfig (getpath.c:847)
==93405==    by 0x4AF1087: config_init_import (initconfig.c:1967)
==93405==    by 0x4AF4163: _PyConfig_InitImportConfig (initconfig.c:2000)
==93405== 
==93405== 100 bytes in 2 blocks are possibly lost in loss record 485 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A6B783: PyUnicode_New (unicodeobject.c:1471)
==93405==    by 0x4A6B9B3: get_latin1_char (unicodeobject.c:2170)
==93405==    by 0x4AF7EE3: r_object (marshal.c:1151)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF95AB: read_object (marshal.c:1525)
==93405==    by 0x4AF9843: marshal_loads_impl (marshal.c:1834)
==93405==    by 0x4AF9843: marshal_loads (marshal.c.h:148)
==93405==    by 0x4A3DB73: cfunction_vectorcall_O (methodobject.c:516)
==93405== 
==93405== 100 bytes in 2 blocks are possibly lost in loss record 486 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A6B783: PyUnicode_New (unicodeobject.c:1471)
==93405==    by 0x4A6B9B3: get_latin1_char (unicodeobject.c:2170)
==93405==    by 0x4AF7EE3: r_object (marshal.c:1151)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF95AB: read_object (marshal.c:1525)
==93405== 
==93405== 102 bytes in 2 blocks are possibly lost in loss record 487 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A6B783: PyUnicode_New (unicodeobject.c:1471)
==93405==    by 0x4A6BA9B: _PyUnicode_FromUCS1 (unicodeobject.c:2476)
==93405==    by 0x4A6BA9B: _PyUnicode_FromUCS1 (unicodeobject.c:2462)
==93405==    by 0x4AF7EE3: r_object (marshal.c:1151)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF95AB: read_object (marshal.c:1525)
==93405==    by 0x4AF9843: marshal_loads_impl (marshal.c:1834)
==93405==    by 0x4AF9843: marshal_loads (marshal.c.h:148)
==93405==    by 0x49AA24F: _PyEval_EvalFrameDefault (ceval.c:4816)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405== 
==93405== 105 bytes in 2 blocks are possibly lost in loss record 489 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A6B783: PyUnicode_New (unicodeobject.c:1471)
==93405==    by 0x4A84007: unicode_decode_utf8 (unicodeobject.c:5184)
==93405==    by 0x4A8DDEF: PyUnicode_InternFromString (unicodeobject.c:15669)
==93405==    by 0x4A0733F: descr_new (descrobject.c:888)
==93405==    by 0x4A0733F: PyDescr_NewGetSet (descrobject.c:975)
==93405==    by 0x4A57CEB: type_add_getset (typeobject.c:5783)
==93405==    by 0x4A57CEB: type_ready_fill_dict (typeobject.c:6224)
==93405==    by 0x4A57CEB: type_ready (typeobject.c:6474)
==93405==    by 0x4A57CEB: PyType_Ready (typeobject.c:6510)
==93405==    by 0x4A40D8B: _PyTypes_InitTypes (object.c:1966)
==93405==    by 0x4B0098B: pycore_init_types (pylifecycle.c:717)
==93405==    by 0x4B0098B: pycore_interp_init (pylifecycle.c:844)
==93405==    by 0x4B0293F: pyinit_config (pylifecycle.c:900)
==93405==    by 0x4B0293F: pyinit_core.constprop.0 (pylifecycle.c:1063)
==93405==    by 0x4B02B67: Py_InitializeFromConfig (pylifecycle.c:1253)
==93405==    by 0x4B02B67: Py_InitializeFromConfig (pylifecycle.c:1238)
==93405==    by 0x4B24F3B: pymain_init (main.c:67)
==93405== 
==93405== 106 bytes in 3 blocks are possibly lost in loss record 490 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x49F121F: _PyBytes_FromSize (bytesobject.c:104)
==93405==    by 0x49F121F: _PyBytes_FromSize (bytesobject.c:85)
==93405==    by 0x49F1EAB: PyBytes_FromStringAndSize (bytesobject.c:134)
==93405==    by 0x49F1EAB: PyBytes_FromStringAndSize (bytesobject.c:117)
==93405==    by 0x4AF8673: r_object (marshal.c:1108)
==93405==    by 0x4AF8893: r_object (marshal.c:1397)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF95AB: read_object (marshal.c:1525)
==93405==    by 0x4AF9843: marshal_loads_impl (marshal.c:1834)
==93405==    by 0x4AF9843: marshal_loads (marshal.c.h:148)
==93405== 
==93405== 110 bytes in 3 blocks are possibly lost in loss record 494 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x49F121F: _PyBytes_FromSize (bytesobject.c:104)
==93405==    by 0x49F121F: _PyBytes_FromSize (bytesobject.c:85)
==93405==    by 0x49F1EAB: PyBytes_FromStringAndSize (bytesobject.c:134)
==93405==    by 0x49F1EAB: PyBytes_FromStringAndSize (bytesobject.c:117)
==93405==    by 0x662D71B: Struct___init___impl (_struct.c:1479)
==93405==    by 0x662D71B: Struct___init__ (_struct.c.h:35)
==93405==    by 0x4A57437: type_call (typeobject.c:1141)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x49FBA93: _PyObject_VectorcallTstate (pycore_call.h:87)
==93405==    by 0x49FBA93: _PyObject_VectorcallTstate (pycore_call.h:74)
==93405==    by 0x49FBA93: PyObject_CallOneArg (call.c:375)
==93405==    by 0x662E397: cache_struct_converter (_struct.c:2137)
==93405==    by 0x662E523: pack (_struct.c:2199)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49FBAE7: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBAE7: PyObject_Vectorcall (call.c:298)
==93405== 
==93405== 112 bytes in 2 blocks are possibly lost in loss record 495 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:155)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:147)
==93405==    by 0x4A6187F: mro_implementation (typeobject.c:1967)
==93405==    by 0x4A61BF3: mro_invoke (typeobject.c:2104)
==93405==    by 0x4A61BF3: mro_internal (typeobject.c:2161)
==93405==    by 0x4A57A9F: type_ready_mro (typeobject.c:6238)
==93405==    by 0x4A57A9F: type_ready (typeobject.c:6468)
==93405==    by 0x4A57A9F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x4A40D8B: _PyTypes_InitTypes (object.c:1966)
==93405==    by 0x4B0098B: pycore_init_types (pylifecycle.c:717)
==93405==    by 0x4B0098B: pycore_interp_init (pylifecycle.c:844)
==93405==    by 0x4B0293F: pyinit_config (pylifecycle.c:900)
==93405==    by 0x4B0293F: pyinit_core.constprop.0 (pylifecycle.c:1063)
==93405==    by 0x4B02B67: Py_InitializeFromConfig (pylifecycle.c:1253)
==93405==    by 0x4B02B67: Py_InitializeFromConfig (pylifecycle.c:1238)
==93405== 
==93405== 112 bytes in 2 blocks are possibly lost in loss record 496 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A5688F: _PyType_AllocNoTrack (typeobject.c:1162)
==93405==    by 0x4A56953: PyType_GenericAlloc (typeobject.c:1186)
==93405==    by 0x4A54CDF: object_new (typeobject.c:4599)
==93405==    by 0x4A573E7: type_call (typeobject.c:1129)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405==    by 0x49FC17B: _PyObject_CallMethodIdObjArgs (call.c:875)
==93405==    by 0x4AEF4CF: import_find_and_load (import.c:1739)
==93405==    by 0x4AEF4CF: PyImport_ImportModuleLevelObject (import.c:1840)
==93405== 
==93405== 112 bytes in 2 blocks are possibly lost in loss record 497 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:155)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:147)
==93405==    by 0x4A6187F: mro_implementation (typeobject.c:1967)
==93405==    by 0x4A61BF3: mro_invoke (typeobject.c:2104)
==93405==    by 0x4A61BF3: mro_internal (typeobject.c:2161)
==93405==    by 0x4A57A9F: type_ready_mro (typeobject.c:6238)
==93405==    by 0x4A57A9F: type_ready (typeobject.c:6468)
==93405==    by 0x4A57A9F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x4AFCBEF: PyModule_AddType (modsupport.c:706)
==93405==    by 0x4B47CDF: collections_exec (_collectionsmodule.c:2613)
==93405==    by 0x4A3F7A3: PyModule_ExecDef (moduleobject.c:428)
==93405==    by 0x4AEC003: exec_builtin_or_dynamic (import.c:2354)
==93405==    by 0x4AEC003: exec_builtin_or_dynamic (import.c:2335)
==93405==    by 0x4AEC003: _imp_exec_dynamic_impl (import.c:2428)
==93405==    by 0x4AEC003: _imp_exec_dynamic (import.c.h:474)
==93405== 
==93405== 116 bytes in 2 blocks are possibly lost in loss record 499 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A6B783: PyUnicode_New (unicodeobject.c:1471)
==93405==    by 0x4A84007: unicode_decode_utf8 (unicodeobject.c:5184)
==93405==    by 0x4A8DDEF: PyUnicode_InternFromString (unicodeobject.c:15669)
==93405==    by 0x4A07083: descr_new (descrobject.c:888)
==93405==    by 0x4A07083: PyDescr_NewMethod (descrobject.c:937)
==93405==    by 0x4A58373: type_add_method (typeobject.c:5695)
==93405==    by 0x4A58373: type_add_methods (typeobject.c:5741)
==93405==    by 0x4A58373: type_ready_fill_dict (typeobject.c:6218)
==93405==    by 0x4A58373: type_ready (typeobject.c:6474)
==93405==    by 0x4A58373: PyType_Ready (typeobject.c:6510)
==93405==    by 0x4A40D8B: _PyTypes_InitTypes (object.c:1966)
==93405==    by 0x4B0098B: pycore_init_types (pylifecycle.c:717)
==93405==    by 0x4B0098B: pycore_interp_init (pylifecycle.c:844)
==93405==    by 0x4B0293F: pyinit_config (pylifecycle.c:900)
==93405==    by 0x4B0293F: pyinit_core.constprop.0 (pylifecycle.c:1063)
==93405==    by 0x4B02B67: Py_InitializeFromConfig (pylifecycle.c:1253)
==93405==    by 0x4B02B67: Py_InitializeFromConfig (pylifecycle.c:1238)
==93405==    by 0x4B24F3B: pymain_init (main.c:67)
==93405== 
==93405== 120 bytes in 2 blocks are possibly lost in loss record 501 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A3452F: new_values (dictobject.c:641)
==93405==    by 0x4A3452F: init_inline_values (dictobject.c:4973)
==93405==    by 0x4A3452F: _PyObject_InitializeDict (dictobject.c:4995)
==93405==    by 0x4A54CEB: object_new (typeobject.c:4603)
==93405==    by 0x4A573E7: type_call (typeobject.c:1129)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405==    by 0x49FC17B: _PyObject_CallMethodIdObjArgs (call.c:875)
==93405==    by 0x4AEF4CF: import_find_and_load (import.c:1739)
==93405==    by 0x4AEF4CF: PyImport_ImportModuleLevelObject (import.c:1840)
==93405==    by 0x49AF6C3: import_name (ceval.c:7106)
==93405==    by 0x49AF6C3: _PyEval_EvalFrameDefault (ceval.c:3885)
==93405== 
==93405== 121 bytes in 3 blocks are possibly lost in loss record 502 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x49F121F: _PyBytes_FromSize (bytesobject.c:104)
==93405==    by 0x49F121F: _PyBytes_FromSize (bytesobject.c:85)
==93405==    by 0x49F1EAB: PyBytes_FromStringAndSize (bytesobject.c:134)
==93405==    by 0x49F1EAB: PyBytes_FromStringAndSize (bytesobject.c:117)
==93405==    by 0x4AF8673: r_object (marshal.c:1108)
==93405==    by 0x4AF88E7: r_object (marshal.c:1412)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF95AB: read_object (marshal.c:1525)
==93405==    by 0x4AF9843: marshal_loads_impl (marshal.c:1834)
==93405==    by 0x4AF9843: marshal_loads (marshal.c.h:148)
==93405== 
==93405== 124 bytes in 2 blocks are possibly lost in loss record 503 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A6B783: PyUnicode_New (unicodeobject.c:1471)
==93405==    by 0x4A6BA9B: _PyUnicode_FromUCS1 (unicodeobject.c:2476)
==93405==    by 0x4A6BA9B: _PyUnicode_FromUCS1 (unicodeobject.c:2462)
==93405==    by 0x4AF7EE3: r_object (marshal.c:1151)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8873: r_object (marshal.c:1391)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF95AB: read_object (marshal.c:1525)
==93405==    by 0x4AF9843: marshal_loads_impl (marshal.c:1834)
==93405==    by 0x4AF9843: marshal_loads (marshal.c.h:148)
==93405==    by 0x49AA24F: _PyEval_EvalFrameDefault (ceval.c:4816)
==93405== 
==93405== 144 bytes in 2 blocks are possibly lost in loss record 524 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B285FF: _PyObject_GC_New (gcmodule.c:2300)
==93405==    by 0x4A3E99F: new_module_notrack (moduleobject.c:93)
==93405==    by 0x4A3E99F: new_module (moduleobject.c:111)
==93405==    by 0x4A573E7: type_call (typeobject.c:1129)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405==    by 0x49FC17B: _PyObject_CallMethodIdObjArgs (call.c:875)
==93405==    by 0x4AEF4CF: import_find_and_load (import.c:1739)
==93405==    by 0x4AEF4CF: PyImport_ImportModuleLevelObject (import.c:1840)
==93405== 
==93405== 144 bytes in 3 blocks are possibly lost in loss record 525 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50F83: PyTuple_Pack (tupleobject.c:246)
==93405==    by 0x4A5905F: type_ready_set_bases (typeobject.c:6148)
==93405==    by 0x4A5905F: type_ready (typeobject.c:6465)
==93405==    by 0x4A5905F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x4A0D483: _PyExc_InitTypes (exceptions.c:3534)
==93405==    by 0x4B009FF: pycore_init_types (pylifecycle.c:747)
==93405==    by 0x4B009FF: pycore_interp_init (pylifecycle.c:844)
==93405==    by 0x4B0293F: pyinit_config (pylifecycle.c:900)
==93405==    by 0x4B0293F: pyinit_core.constprop.0 (pylifecycle.c:1063)
==93405==    by 0x4B02B67: Py_InitializeFromConfig (pylifecycle.c:1253)
==93405==    by 0x4B02B67: Py_InitializeFromConfig (pylifecycle.c:1238)
==93405==    by 0x4B24F3B: pymain_init (main.c:67)
==93405==    by 0x4B25F13: pymain_main (main.c:693)
==93405==    by 0x4B25F13: Py_BytesMain (main.c:726)
==93405== 
==93405== 144 bytes in 3 blocks are possibly lost in loss record 526 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A510CF: _PyTuple_FromArray (tupleobject.c:475)
==93405==    by 0x4A510CF: _PyTuple_FromArray (tupleobject.c:469)
==93405==    by 0x49FB427: _PyObject_MakeTpCall (call.c:188)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x4AC4237: builtin___build_class__ (bltinmodule.c:216)
==93405==    by 0x4A3D6B3: cfunction_vectorcall_FASTCALL_KEYWORDS (methodobject.c:446)
==93405==    by 0x49FBAE7: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBAE7: PyObject_Vectorcall (call.c:298)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405== 
==93405== 144 bytes in 3 blocks are possibly lost in loss record 527 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A510CF: _PyTuple_FromArray (tupleobject.c:475)
==93405==    by 0x4A510CF: _PyTuple_FromArray (tupleobject.c:469)
==93405==    by 0x4A06CAB: method_vectorcall_VARARGS (descrobject.c:302)
==93405==    by 0x49FBAE7: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBAE7: PyObject_Vectorcall (call.c:298)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBA3F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBA3F: PyObject_CallOneArg (call.c:375)
==93405==    by 0x4A41F0F: _PyObject_GenericGetAttrWithDict (object.c:1283)
==93405==    by 0x4A41877: PyObject_GetAttr (object.c:933)
==93405== 
==93405== 153 bytes in 1 blocks are possibly lost in loss record 530 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A6B783: PyUnicode_New (unicodeobject.c:1471)
==93405==    by 0x4A84007: unicode_decode_utf8 (unicodeobject.c:5184)
==93405==    by 0x4A62457: type_getattro (typeobject.c:3995)
==93405==    by 0x4A41877: PyObject_GetAttr (object.c:933)
==93405==    by 0x4A193B3: functools_copy_attr (funcobject.c:791)
==93405==    by 0x4A194EB: functools_wraps (funcobject.c:824)
==93405==    by 0x4A199B3: cm_init (funcobject.c:916)
==93405==    by 0x4A57437: type_call (typeobject.c:1141)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405== 
==93405== 160 bytes in 1 blocks are possibly lost in loss record 548 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A2CC2F: clone_combined_dict_keys (dictobject.c:720)
==93405==    by 0x4A33AC3: PyDict_Copy (dictobject.c:2767)
==93405==    by 0x4A607CB: type_new_init (typeobject.c:3162)
==93405==    by 0x4A607CB: type_new_impl (typeobject.c:3199)
==93405==    by 0x4A607CB: type_new (typeobject.c:3349)
==93405==    by 0x4A573E7: type_call (typeobject.c:1129)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x49FB623: _PyObject_FastCallDictTstate (call.c:141)
==93405==    by 0x4AC427B: builtin___build_class__ (bltinmodule.c:224)
==93405==    by 0x4A3D6B3: cfunction_vectorcall_FASTCALL_KEYWORDS (methodobject.c:446)
==93405==    by 0x49FBAE7: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBAE7: PyObject_Vectorcall (call.c:298)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405== 
==93405== 160 bytes in 1 blocks are possibly lost in loss record 549 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A2CC2F: clone_combined_dict_keys (dictobject.c:720)
==93405==    by 0x4A33AC3: PyDict_Copy (dictobject.c:2767)
==93405==    by 0x4A60E13: type_new_set_names (typeobject.c:8607)
==93405==    by 0x4A60E13: type_new_impl (typeobject.c:3221)
==93405==    by 0x4A60E13: type_new (typeobject.c:3349)
==93405==    by 0x4A573E7: type_call (typeobject.c:1129)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x49FB623: _PyObject_FastCallDictTstate (call.c:141)
==93405==    by 0x4AC427B: builtin___build_class__ (bltinmodule.c:224)
==93405==    by 0x4A3D6B3: cfunction_vectorcall_FASTCALL_KEYWORDS (methodobject.c:446)
==93405==    by 0x49FBAE7: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBAE7: PyObject_Vectorcall (call.c:298)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405== 
==93405== 160 bytes in 1 blocks are possibly lost in loss record 550 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A2C913: new_keys_object (dictobject.c:592)
==93405==    by 0x4A2F42B: insert_to_emptydict (dictobject.c:1148)
==93405==    by 0x49AC08B: _PyEval_EvalFrameDefault (ceval.c:2763)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x4AC4237: builtin___build_class__ (bltinmodule.c:216)
==93405==    by 0x4A3D6B3: cfunction_vectorcall_FASTCALL_KEYWORDS (methodobject.c:446)
==93405==    by 0x49FBAE7: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBAE7: PyObject_Vectorcall (call.c:298)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x4AC7877: PyEval_EvalCode (ceval.c:1120)
==93405== 
==93405== 160 bytes in 1 blocks are possibly lost in loss record 551 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A2C913: new_keys_object (dictobject.c:592)
==93405==    by 0x4A2F42B: insert_to_emptydict (dictobject.c:1148)
==93405==    by 0x49A6253: _PyEval_EvalFrameDefault (ceval.c:3368)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x4AC4237: builtin___build_class__ (bltinmodule.c:216)
==93405==    by 0x4A3D6B3: cfunction_vectorcall_FASTCALL_KEYWORDS (methodobject.c:446)
==93405==    by 0x49FBAE7: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBAE7: PyObject_Vectorcall (call.c:298)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x4AC7877: PyEval_EvalCode (ceval.c:1120)
==93405== 
==93405== 160 bytes in 1 blocks are possibly lost in loss record 552 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A2CC2F: clone_combined_dict_keys (dictobject.c:720)
==93405==    by 0x4A33AC3: PyDict_Copy (dictobject.c:2767)
==93405==    by 0x4A60E13: type_new_set_names (typeobject.c:8607)
==93405==    by 0x4A60E13: type_new_impl (typeobject.c:3221)
==93405==    by 0x4A60E13: type_new (typeobject.c:3349)
==93405==    by 0x4A573E7: type_call (typeobject.c:1129)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x49FC38B: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FC38B: _PyObject_CallFunctionVa (call.c:535)
==93405==    by 0x49FC61F: PyObject_CallFunction (call.c:557)
==93405==    by 0x4A9AA27: make_type (Python-ast.c:942)
==93405==    by 0x4A9B50B: init_types (Python-ast.c:1131)
==93405==    by 0x4A9DACF: get_ast_state (Python-ast.c:19)
==93405==    by 0x4A9DACF: astmodule_exec (Python-ast.c:11826)
==93405== 
==93405== 160 bytes in 1 blocks are possibly lost in loss record 553 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A2CC2F: clone_combined_dict_keys (dictobject.c:720)
==93405==    by 0x4A33AC3: PyDict_Copy (dictobject.c:2767)
==93405==    by 0x4A60E13: type_new_set_names (typeobject.c:8607)
==93405==    by 0x4A60E13: type_new_impl (typeobject.c:3221)
==93405==    by 0x4A60E13: type_new (typeobject.c:3349)
==93405==    by 0x4A573E7: type_call (typeobject.c:1129)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x49FC38B: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FC38B: _PyObject_CallFunctionVa (call.c:535)
==93405==    by 0x49FC61F: PyObject_CallFunction (call.c:557)
==93405==    by 0x4AE0723: PyErr_NewException (errors.c:1160)
==93405==    by 0x6657983: _ctypes_mod_exec (_ctypes.c:5832)
==93405==    by 0x6657983: PyInit__ctypes (_ctypes.c:5859)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405== 
==93405== 160 bytes in 1 blocks are possibly lost in loss record 554 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A2CC2F: clone_combined_dict_keys (dictobject.c:720)
==93405==    by 0x4A33AC3: PyDict_Copy (dictobject.c:2767)
==93405==    by 0x4A607CB: type_new_init (typeobject.c:3162)
==93405==    by 0x4A607CB: type_new_impl (typeobject.c:3199)
==93405==    by 0x4A607CB: type_new (typeobject.c:3349)
==93405==    by 0x6655477: PyCSimpleType_new (_ctypes.c:2087)
==93405==    by 0x4A573E7: type_call (typeobject.c:1129)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x4AC427B: builtin___build_class__ (bltinmodule.c:224)
==93405==    by 0x4A3D6B3: cfunction_vectorcall_FASTCALL_KEYWORDS (methodobject.c:446)
==93405==    by 0x49FBAE7: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBAE7: PyObject_Vectorcall (call.c:298)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405== 
==93405== 165 bytes in 3 blocks are possibly lost in loss record 557 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A6B783: PyUnicode_New (unicodeobject.c:1471)
==93405==    by 0x4A6BA9B: _PyUnicode_FromUCS1 (unicodeobject.c:2476)
==93405==    by 0x4A6BA9B: _PyUnicode_FromUCS1 (unicodeobject.c:2462)
==93405==    by 0x4AF7EE3: r_object (marshal.c:1151)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8883: r_object (marshal.c:1394)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF95AB: read_object (marshal.c:1525)
==93405==    by 0x4AF9843: marshal_loads_impl (marshal.c:1834)
==93405==    by 0x4AF9843: marshal_loads (marshal.c.h:148)
==93405==    by 0x49AA24F: _PyEval_EvalFrameDefault (ceval.c:4816)
==93405== 
==93405== 168 bytes in 3 blocks are possibly lost in loss record 560 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A5688F: _PyType_AllocNoTrack (typeobject.c:1162)
==93405==    by 0x4A56953: PyType_GenericAlloc (typeobject.c:1186)
==93405==    by 0x4A54CDF: object_new (typeobject.c:4599)
==93405==    by 0x4A573E7: type_call (typeobject.c:1129)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x4AC7877: PyEval_EvalCode (ceval.c:1120)
==93405==    by 0x4AC15BF: builtin_exec_impl (bltinmodule.c:1057)
==93405==    by 0x4AC15BF: builtin_exec (bltinmodule.c.h:371)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405== 
==93405== 168 bytes in 3 blocks are possibly lost in loss record 561 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A5688F: _PyType_AllocNoTrack (typeobject.c:1162)
==93405==    by 0x4A56953: PyType_GenericAlloc (typeobject.c:1186)
==93405==    by 0x662BA67: s_new (_struct.c:1448)
==93405==    by 0x4A573E7: type_call (typeobject.c:1129)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x49FBA93: _PyObject_VectorcallTstate (pycore_call.h:87)
==93405==    by 0x49FBA93: _PyObject_VectorcallTstate (pycore_call.h:74)
==93405==    by 0x49FBA93: PyObject_CallOneArg (call.c:375)
==93405==    by 0x662E397: cache_struct_converter (_struct.c:2137)
==93405==    by 0x662E523: pack (_struct.c:2199)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49FBAE7: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBAE7: PyObject_Vectorcall (call.c:298)
==93405== 
==93405== 176 bytes in 2 blocks are possibly lost in loss record 565 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:155)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:147)
==93405==    by 0x4A02197: _PyCode_ConstantKey (codeobject.c:1842)
==93405==    by 0x4ACC733: merge_const_one (compile.c:7753)
==93405==    by 0x4AD0B73: makecode (compile.c:7908)
==93405==    by 0x4AD0B73: assemble (compile.c:8359)
==93405==    by 0x4AD350B: compiler_lambda (compile.c:2944)
==93405==    by 0x4AD350B: compiler_visit_expr1 (compile.c:5711)
==93405==    by 0x4AD37DB: compiler_visit_expr (compile.c:5838)
==93405==    by 0x4ADC4B7: compiler_mod (compile.c:2081)
==93405==    by 0x4ADC4B7: _PyAST_Compile (compile.c:480)
==93405==    by 0x4B06CE7: run_mod (pythonrun.c:1723)
==93405== 
==93405== 192 bytes in 3 blocks are possibly lost in loss record 576 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:155)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:147)
==93405==    by 0x4A6187F: mro_implementation (typeobject.c:1967)
==93405==    by 0x4A61BF3: mro_invoke (typeobject.c:2104)
==93405==    by 0x4A61BF3: mro_internal (typeobject.c:2161)
==93405==    by 0x4A57A9F: type_ready_mro (typeobject.c:6238)
==93405==    by 0x4A57A9F: type_ready (typeobject.c:6468)
==93405==    by 0x4A57A9F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x4A0D483: _PyExc_InitTypes (exceptions.c:3534)
==93405==    by 0x4B009FF: pycore_init_types (pylifecycle.c:747)
==93405==    by 0x4B009FF: pycore_interp_init (pylifecycle.c:844)
==93405==    by 0x4B0293F: pyinit_config (pylifecycle.c:900)
==93405==    by 0x4B0293F: pyinit_core.constprop.0 (pylifecycle.c:1063)
==93405==    by 0x4B02B67: Py_InitializeFromConfig (pylifecycle.c:1253)
==93405==    by 0x4B02B67: Py_InitializeFromConfig (pylifecycle.c:1238)
==93405== 
==93405== 192 bytes in 4 blocks are possibly lost in loss record 577 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50F83: PyTuple_Pack (tupleobject.c:246)
==93405==    by 0x4A5905F: type_ready_set_bases (typeobject.c:6148)
==93405==    by 0x4A5905F: type_ready (typeobject.c:6465)
==93405==    by 0x4A5905F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x4AFCBEF: PyModule_AddType (modsupport.c:706)
==93405==    by 0x4B47CDF: collections_exec (_collectionsmodule.c:2613)
==93405==    by 0x4A3F7A3: PyModule_ExecDef (moduleobject.c:428)
==93405==    by 0x4AEC003: exec_builtin_or_dynamic (import.c:2354)
==93405==    by 0x4AEC003: exec_builtin_or_dynamic (import.c:2335)
==93405==    by 0x4AEC003: _imp_exec_dynamic_impl (import.c:2428)
==93405==    by 0x4AEC003: _imp_exec_dynamic (import.c.h:474)
==93405==    by 0x4A3DB73: cfunction_vectorcall_O (methodobject.c:516)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405== 
==93405== 200 bytes in 4 blocks are possibly lost in loss record 579 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A51203: _PyTuple_FromArraySteal (tupleobject.c:495)
==93405==    by 0x4AC6403: initialize_locals (ceval.c:5904)
==93405==    by 0x4AC6403: _PyEvalFramePushAndInit (ceval.c:6098)
==93405==    by 0x49A99AB: _PyEval_EvalFrameDefault (ceval.c:4586)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405==    by 0x49FC17B: _PyObject_CallMethodIdObjArgs (call.c:875)
==93405==    by 0x4AEF4CF: import_find_and_load (import.c:1739)
==93405==    by 0x4AEF4CF: PyImport_ImportModuleLevelObject (import.c:1840)
==93405==    by 0x49AF6C3: import_name (ceval.c:7106)
==93405==    by 0x49AF6C3: _PyEval_EvalFrameDefault (ceval.c:3885)
==93405== 
==93405== 203 bytes in 3 blocks are possibly lost in loss record 580 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x49F121F: _PyBytes_FromSize (bytesobject.c:104)
==93405==    by 0x49F121F: _PyBytes_FromSize (bytesobject.c:85)
==93405==    by 0x49F1EAB: PyBytes_FromStringAndSize (bytesobject.c:134)
==93405==    by 0x49F1EAB: PyBytes_FromStringAndSize (bytesobject.c:117)
==93405==    by 0x4AF8673: r_object (marshal.c:1108)
==93405==    by 0x4AF884F: r_object (marshal.c:1385)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF95AB: read_object (marshal.c:1525)
==93405==    by 0x4AF9843: marshal_loads_impl (marshal.c:1834)
==93405==    by 0x4AF9843: marshal_loads (marshal.c.h:148)
==93405== 
==93405== 203 bytes in 3 blocks are possibly lost in loss record 581 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x49F121F: _PyBytes_FromSize (bytesobject.c:104)
==93405==    by 0x49F121F: _PyBytes_FromSize (bytesobject.c:85)
==93405==    by 0x49F1EAB: PyBytes_FromStringAndSize (bytesobject.c:134)
==93405==    by 0x49F1EAB: PyBytes_FromStringAndSize (bytesobject.c:117)
==93405==    by 0x4AF8673: r_object (marshal.c:1108)
==93405==    by 0x4AF8907: r_object (marshal.c:1418)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF95AB: read_object (marshal.c:1525)
==93405==    by 0x4AF9843: marshal_loads_impl (marshal.c:1834)
==93405==    by 0x4AF9843: marshal_loads (marshal.c.h:148)
==93405== 
==93405== 208 bytes in 4 blocks are possibly lost in loss record 583 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A510CF: _PyTuple_FromArray (tupleobject.c:475)
==93405==    by 0x4A510CF: _PyTuple_FromArray (tupleobject.c:469)
==93405==    by 0x49FB427: _PyObject_MakeTpCall (call.c:188)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x4AC7877: PyEval_EvalCode (ceval.c:1120)
==93405==    by 0x4AC15BF: builtin_exec_impl (bltinmodule.c:1057)
==93405==    by 0x4AC15BF: builtin_exec (bltinmodule.c.h:371)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405== 
==93405== 224 bytes in 1 blocks are possibly lost in loss record 597 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A40FB7: _PyObject_New (object.c:187)
==93405==    by 0x49FFDAF: _PyCode_New (codeobject.c:389)
==93405==    by 0x4AF89BB: r_object (marshal.c:1456)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF95AB: read_object (marshal.c:1525)
==93405== 
==93405== 240 bytes in 5 blocks are possibly lost in loss record 601 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A510CF: _PyTuple_FromArray (tupleobject.c:475)
==93405==    by 0x4A510CF: _PyTuple_FromArray (tupleobject.c:469)
==93405==    by 0x49FB427: _PyObject_MakeTpCall (call.c:188)
==93405==    by 0x49FBA93: _PyObject_VectorcallTstate (pycore_call.h:87)
==93405==    by 0x49FBA93: _PyObject_VectorcallTstate (pycore_call.h:74)
==93405==    by 0x49FBA93: PyObject_CallOneArg (call.c:375)
==93405==    by 0x662E397: cache_struct_converter (_struct.c:2137)
==93405==    by 0x662E5DB: calcsize (_struct.c.h:202)
==93405==    by 0x49AA24F: _PyEval_EvalFrameDefault (ceval.c:4816)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x4AC7877: PyEval_EvalCode (ceval.c:1120)
==93405== 
==93405== 248 bytes in 1 blocks are possibly lost in loss record 602 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B0BB53: allocate (specialize.c:254)
==93405==    by 0x4B0BB53: _Py_Quicken (specialize.c:443)
==93405==    by 0x49AFFEF: _Py_IncrementCountAndMaybeQuicken (pycore_code.h:152)
==93405==    by 0x49AFFEF: _Py_IncrementCountAndMaybeQuicken (pycore_code.h:147)
==93405==    by 0x49AFFEF: _PyEval_EvalFrameDefault (ceval.c:1791)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x4AC7877: PyEval_EvalCode (ceval.c:1120)
==93405==    by 0x4AC15BF: builtin_exec_impl (bltinmodule.c:1057)
==93405==    by 0x4AC15BF: builtin_exec (bltinmodule.c.h:371)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405==    by 0x49FC17B: _PyObject_CallMethodIdObjArgs (call.c:875)
==93405== 
==93405== 256 bytes in 4 blocks are possibly lost in loss record 606 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B285FF: _PyObject_GC_New (gcmodule.c:2300)
==93405==    by 0x4A2D4EB: new_dict (dictobject.c:667)
==93405==    by 0x4A33AD7: PyDict_Copy (dictobject.c:2771)
==93405==    by 0x4A60E13: type_new_set_names (typeobject.c:8607)
==93405==    by 0x4A60E13: type_new_impl (typeobject.c:3221)
==93405==    by 0x4A60E13: type_new (typeobject.c:3349)
==93405==    by 0x4A573E7: type_call (typeobject.c:1129)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x49FB623: _PyObject_FastCallDictTstate (call.c:141)
==93405==    by 0x4AC427B: builtin___build_class__ (bltinmodule.c:224)
==93405==    by 0x4A3D6B3: cfunction_vectorcall_FASTCALL_KEYWORDS (methodobject.c:446)
==93405== 
==93405== 280 bytes in 5 blocks are possibly lost in loss record 610 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A5688F: _PyType_AllocNoTrack (typeobject.c:1162)
==93405==    by 0x4A56953: PyType_GenericAlloc (typeobject.c:1186)
==93405==    by 0x662BA67: s_new (_struct.c:1448)
==93405==    by 0x4A573E7: type_call (typeobject.c:1129)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x49FBA93: _PyObject_VectorcallTstate (pycore_call.h:87)
==93405==    by 0x49FBA93: _PyObject_VectorcallTstate (pycore_call.h:74)
==93405==    by 0x49FBA93: PyObject_CallOneArg (call.c:375)
==93405==    by 0x662E397: cache_struct_converter (_struct.c:2137)
==93405==    by 0x662E5DB: calcsize (_struct.c.h:202)
==93405==    by 0x49AA24F: _PyEval_EvalFrameDefault (ceval.c:4816)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== 288 bytes in 6 blocks are possibly lost in loss record 637 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A510CF: _PyTuple_FromArray (tupleobject.c:475)
==93405==    by 0x4A510CF: _PyTuple_FromArray (tupleobject.c:469)
==93405==    by 0x49FB427: _PyObject_MakeTpCall (call.c:188)
==93405==    by 0x49FBA93: _PyObject_VectorcallTstate (pycore_call.h:87)
==93405==    by 0x49FBA93: _PyObject_VectorcallTstate (pycore_call.h:74)
==93405==    by 0x49FBA93: PyObject_CallOneArg (call.c:375)
==93405==    by 0x662E397: cache_struct_converter (_struct.c:2137)
==93405==    by 0x662E5DB: calcsize (_struct.c.h:202)
==93405==    by 0x4A3DB73: cfunction_vectorcall_O (methodobject.c:516)
==93405==    by 0x49FBAE7: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBAE7: PyObject_Vectorcall (call.c:298)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405== 
==93405== 296 bytes in 5 blocks are possibly lost in loss record 638 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A510CF: _PyTuple_FromArray (tupleobject.c:475)
==93405==    by 0x4A510CF: _PyTuple_FromArray (tupleobject.c:469)
==93405==    by 0x49FB427: _PyObject_MakeTpCall (call.c:188)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FE5AF: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FE5AF: method_vectorcall (classobject.c:62)
==93405==    by 0x49A8073: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49A8073: _PyObject_CallNoArgs (pycore_call.h:104)
==93405==    by 0x49A8073: _PyEval_EvalFrameDefault (ceval.c:4310)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405== 
==93405== 320 bytes in 5 blocks are possibly lost in loss record 647 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B285FF: _PyObject_GC_New (gcmodule.c:2300)
==93405==    by 0x4A2D4EB: new_dict (dictobject.c:667)
==93405==    by 0x4A34BDB: PyObject_GenericGetDict (dictobject.c:5225)
==93405==    by 0x4A41F0F: _PyObject_GenericGetAttrWithDict (object.c:1283)
==93405==    by 0x4A41877: PyObject_GetAttr (object.c:933)
==93405==    by 0x49A5277: _PyEval_EvalFrameDefault (ceval.c:3432)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x4AC4237: builtin___build_class__ (bltinmodule.c:216)
==93405==    by 0x4A3D6B3: cfunction_vectorcall_FASTCALL_KEYWORDS (methodobject.c:446)
==93405== 
==93405== 320 bytes in 5 blocks are possibly lost in loss record 648 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x662D4F7: prepare_s (_struct.c:1382)
==93405==    by 0x662D4F7: Struct___init___impl (_struct.c:1498)
==93405==    by 0x662D4F7: Struct___init__ (_struct.c.h:35)
==93405==    by 0x4A57437: type_call (typeobject.c:1141)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x49FBA93: _PyObject_VectorcallTstate (pycore_call.h:87)
==93405==    by 0x49FBA93: _PyObject_VectorcallTstate (pycore_call.h:74)
==93405==    by 0x49FBA93: PyObject_CallOneArg (call.c:375)
==93405==    by 0x662E397: cache_struct_converter (_struct.c:2137)
==93405==    by 0x662E5DB: calcsize (_struct.c.h:202)
==93405==    by 0x49AA24F: _PyEval_EvalFrameDefault (ceval.c:4816)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x4AC7877: PyEval_EvalCode (ceval.c:1120)
==93405==    by 0x4AC15BF: builtin_exec_impl (bltinmodule.c:1057)
==93405==    by 0x4AC15BF: builtin_exec (bltinmodule.c.h:371)
==93405== 
==93405== 326 bytes in 9 blocks are possibly lost in loss record 649 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x49F121F: _PyBytes_FromSize (bytesobject.c:104)
==93405==    by 0x49F121F: _PyBytes_FromSize (bytesobject.c:85)
==93405==    by 0x49F1EAB: PyBytes_FromStringAndSize (bytesobject.c:134)
==93405==    by 0x49F1EAB: PyBytes_FromStringAndSize (bytesobject.c:117)
==93405==    by 0x4AF8673: r_object (marshal.c:1108)
==93405==    by 0x4AF8893: r_object (marshal.c:1397)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF95AB: read_object (marshal.c:1525)
==93405==    by 0x4AF9843: marshal_loads_impl (marshal.c:1834)
==93405==    by 0x4AF9843: marshal_loads (marshal.c.h:148)
==93405==    by 0x49AA24F: _PyEval_EvalFrameDefault (ceval.c:4816)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== 327 bytes in 6 blocks are possibly lost in loss record 650 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A6B783: PyUnicode_New (unicodeobject.c:1471)
==93405==    by 0x4A84007: unicode_decode_utf8 (unicodeobject.c:5184)
==93405==    by 0x4A8DDEF: PyUnicode_InternFromString (unicodeobject.c:15669)
==93405==    by 0x4A41783: PyObject_SetAttrString (object.c:844)
==93405==    by 0x4A3E8F7: _add_methods_to_object (moduleobject.c:184)
==93405==    by 0x4A3F487: PyModule_AddFunctions (moduleobject.c:466)
==93405==    by 0x4A3F567: _PyModule_CreateInitialized (moduleobject.c:253)
==93405==    by 0x4AC444B: _PyBuiltin_Init (bltinmodule.c:2989)
==93405==    by 0x4B00A9F: pycore_init_builtins (pylifecycle.c:780)
==93405==    by 0x4B00A9F: pycore_interp_init (pylifecycle.c:863)
==93405==    by 0x4B0293F: pyinit_config (pylifecycle.c:900)
==93405==    by 0x4B0293F: pyinit_core.constprop.0 (pylifecycle.c:1063)
==93405== 
==93405== 358 bytes in 6 blocks are possibly lost in loss record 654 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A6B783: PyUnicode_New (unicodeobject.c:1471)
==93405==    by 0x4A84007: unicode_decode_utf8 (unicodeobject.c:5184)
==93405==    by 0x4A3420F: PyDict_SetItemString (dictobject.c:3574)
==93405==    by 0x4A0DB57: _PyBuiltins_AddExceptions (exceptions.c:3632)
==93405==    by 0x4B00AE3: pycore_init_builtins (pylifecycle.c:796)
==93405==    by 0x4B00AE3: pycore_interp_init (pylifecycle.c:863)
==93405==    by 0x4B0293F: pyinit_config (pylifecycle.c:900)
==93405==    by 0x4B0293F: pyinit_core.constprop.0 (pylifecycle.c:1063)
==93405==    by 0x4B02B67: Py_InitializeFromConfig (pylifecycle.c:1253)
==93405==    by 0x4B02B67: Py_InitializeFromConfig (pylifecycle.c:1238)
==93405==    by 0x4B24F3B: pymain_init (main.c:67)
==93405==    by 0x4B25F13: pymain_main (main.c:693)
==93405==    by 0x4B25F13: Py_BytesMain (main.c:726)
==93405==    by 0x4F2DF3B: __libc_start_call_main (libc_start_call_main.h:58)
==93405== 
==93405== 368 bytes in 4 blocks are possibly lost in loss record 663 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:155)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:147)
==93405==    by 0x4AF8323: r_object (marshal.c:1207)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF95AB: read_object (marshal.c:1525)
==93405==    by 0x4AF9843: marshal_loads_impl (marshal.c:1834)
==93405==    by 0x4AF9843: marshal_loads (marshal.c.h:148)
==93405==    by 0x49AA24F: _PyEval_EvalFrameDefault (ceval.c:4816)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== 376 bytes in 3 blocks are possibly lost in loss record 664 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A3452F: new_values (dictobject.c:641)
==93405==    by 0x4A3452F: init_inline_values (dictobject.c:4973)
==93405==    by 0x4A3452F: _PyObject_InitializeDict (dictobject.c:4995)
==93405==    by 0x4A54CEB: object_new (typeobject.c:4603)
==93405==    by 0x4A573E7: type_call (typeobject.c:1129)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x4AC7877: PyEval_EvalCode (ceval.c:1120)
==93405==    by 0x4AC15BF: builtin_exec_impl (bltinmodule.c:1057)
==93405==    by 0x4AC15BF: builtin_exec (bltinmodule.c.h:371)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405== 
==93405== 384 bytes in 3 blocks are possibly lost in loss record 666 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x662D4F7: prepare_s (_struct.c:1382)
==93405==    by 0x662D4F7: Struct___init___impl (_struct.c:1498)
==93405==    by 0x662D4F7: Struct___init__ (_struct.c.h:35)
==93405==    by 0x4A57437: type_call (typeobject.c:1141)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x49FBA93: _PyObject_VectorcallTstate (pycore_call.h:87)
==93405==    by 0x49FBA93: _PyObject_VectorcallTstate (pycore_call.h:74)
==93405==    by 0x49FBA93: PyObject_CallOneArg (call.c:375)
==93405==    by 0x662E397: cache_struct_converter (_struct.c:2137)
==93405==    by 0x662E523: pack (_struct.c:2199)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49FBAE7: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBAE7: PyObject_Vectorcall (call.c:298)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== 384 bytes in 6 blocks are possibly lost in loss record 667 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:155)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:147)
==93405==    by 0x4AF8323: r_object (marshal.c:1207)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF95AB: read_object (marshal.c:1525)
==93405== 
==93405== 384 bytes in 6 blocks are possibly lost in loss record 668 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:155)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:147)
==93405==    by 0x4A6187F: mro_implementation (typeobject.c:1967)
==93405==    by 0x4A6236F: type_mro_impl (typeobject.c:2034)
==93405==    by 0x4A6236F: type_mro (typeobject.c.h:76)
==93405==    by 0x4A06EB3: method_vectorcall_NOARGS (descrobject.c:432)
==93405==    by 0x49FBA3F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBA3F: PyObject_CallOneArg (call.c:375)
==93405==    by 0x4A61B2B: call_unbound_noarg (typeobject.c:1677)
==93405==    by 0x4A61B2B: mro_invoke (typeobject.c:2100)
==93405==    by 0x4A61B2B: mro_internal (typeobject.c:2161)
==93405==    by 0x4A57A9F: type_ready_mro (typeobject.c:6238)
==93405==    by 0x4A57A9F: type_ready (typeobject.c:6468)
==93405==    by 0x4A57A9F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x4AFCBEF: PyModule_AddType (modsupport.c:706)
==93405== 
==93405== 409 bytes in 7 blocks are possibly lost in loss record 672 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x49F121F: _PyBytes_FromSize (bytesobject.c:104)
==93405==    by 0x49F121F: _PyBytes_FromSize (bytesobject.c:85)
==93405==    by 0x49F1EAB: PyBytes_FromStringAndSize (bytesobject.c:134)
==93405==    by 0x49F1EAB: PyBytes_FromStringAndSize (bytesobject.c:117)
==93405==    by 0x4AF8673: r_object (marshal.c:1108)
==93405==    by 0x4AF88F7: r_object (marshal.c:1415)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF95AB: read_object (marshal.c:1525)
==93405==    by 0x4AF9843: marshal_loads_impl (marshal.c:1834)
==93405==    by 0x4AF9843: marshal_loads (marshal.c.h:148)
==93405==    by 0x49AA24F: _PyEval_EvalFrameDefault (ceval.c:4816)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== 432 bytes in 9 blocks are possibly lost in loss record 676 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A510CF: _PyTuple_FromArray (tupleobject.c:475)
==93405==    by 0x4A510CF: _PyTuple_FromArray (tupleobject.c:469)
==93405==    by 0x4AC3D2F: builtin___build_class__ (bltinmodule.c:131)
==93405==    by 0x4A3D6B3: cfunction_vectorcall_FASTCALL_KEYWORDS (methodobject.c:446)
==93405==    by 0x49FBAE7: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBAE7: PyObject_Vectorcall (call.c:298)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x4AC7877: PyEval_EvalCode (ceval.c:1120)
==93405==    by 0x4AC15BF: builtin_exec_impl (bltinmodule.c:1057)
==93405==    by 0x4AC15BF: builtin_exec (bltinmodule.c.h:371)
==93405== 
==93405== 440 bytes in 7 blocks are possibly lost in loss record 678 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:155)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:147)
==93405==    by 0x4AF8323: r_object (marshal.c:1207)
==93405==    by 0x4AF8883: r_object (marshal.c:1394)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF95AB: read_object (marshal.c:1525)
==93405==    by 0x4AF9843: marshal_loads_impl (marshal.c:1834)
==93405==    by 0x4AF9843: marshal_loads (marshal.c.h:148)
==93405==    by 0x49AA24F: _PyEval_EvalFrameDefault (ceval.c:4816)
==93405== 
==93405== 448 bytes in 8 blocks are possibly lost in loss record 682 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A5688F: _PyType_AllocNoTrack (typeobject.c:1162)
==93405==    by 0x4A56953: PyType_GenericAlloc (typeobject.c:1186)
==93405==    by 0x662BA67: s_new (_struct.c:1448)
==93405==    by 0x4A573E7: type_call (typeobject.c:1129)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x49FBA93: _PyObject_VectorcallTstate (pycore_call.h:87)
==93405==    by 0x49FBA93: _PyObject_VectorcallTstate (pycore_call.h:74)
==93405==    by 0x49FBA93: PyObject_CallOneArg (call.c:375)
==93405==    by 0x662E397: cache_struct_converter (_struct.c:2137)
==93405==    by 0x662E5DB: calcsize (_struct.c.h:202)
==93405==    by 0x4A3DB73: cfunction_vectorcall_O (methodobject.c:516)
==93405==    by 0x49FBAE7: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBAE7: PyObject_Vectorcall (call.c:298)
==93405== 
==93405== 454 bytes in 8 blocks are possibly lost in loss record 683 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A6B783: PyUnicode_New (unicodeobject.c:1471)
==93405==    by 0x4A6BA9B: _PyUnicode_FromUCS1 (unicodeobject.c:2476)
==93405==    by 0x4A6BA9B: _PyUnicode_FromUCS1 (unicodeobject.c:2462)
==93405==    by 0x4AF7EE3: r_object (marshal.c:1151)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF95AB: read_object (marshal.c:1525)
==93405== 
==93405== 465 bytes in 9 blocks are possibly lost in loss record 685 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x49F121F: _PyBytes_FromSize (bytesobject.c:104)
==93405==    by 0x49F121F: _PyBytes_FromSize (bytesobject.c:85)
==93405==    by 0x49F1EAB: PyBytes_FromStringAndSize (bytesobject.c:134)
==93405==    by 0x49F1EAB: PyBytes_FromStringAndSize (bytesobject.c:117)
==93405==    by 0x4AF8673: r_object (marshal.c:1108)
==93405==    by 0x4AF88E7: r_object (marshal.c:1412)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF95AB: read_object (marshal.c:1525)
==93405==    by 0x4AF9843: marshal_loads_impl (marshal.c:1834)
==93405==    by 0x4AF9843: marshal_loads (marshal.c.h:148)
==93405==    by 0x49AA24F: _PyEval_EvalFrameDefault (ceval.c:4816)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== 512 bytes in 8 blocks are possibly lost in loss record 692 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x662D4F7: prepare_s (_struct.c:1382)
==93405==    by 0x662D4F7: Struct___init___impl (_struct.c:1498)
==93405==    by 0x662D4F7: Struct___init__ (_struct.c.h:35)
==93405==    by 0x4A57437: type_call (typeobject.c:1141)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x49FBA93: _PyObject_VectorcallTstate (pycore_call.h:87)
==93405==    by 0x49FBA93: _PyObject_VectorcallTstate (pycore_call.h:74)
==93405==    by 0x49FBA93: PyObject_CallOneArg (call.c:375)
==93405==    by 0x662E397: cache_struct_converter (_struct.c:2137)
==93405==    by 0x662E5DB: calcsize (_struct.c.h:202)
==93405==    by 0x4A3DB73: cfunction_vectorcall_O (methodobject.c:516)
==93405==    by 0x49FBAE7: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBAE7: PyObject_Vectorcall (call.c:298)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== 535 bytes in 9 blocks are possibly lost in loss record 694 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A6B783: PyUnicode_New (unicodeobject.c:1471)
==93405==    by 0x4A84007: unicode_decode_utf8 (unicodeobject.c:5184)
==93405==    by 0x4A8DDEF: PyUnicode_InternFromString (unicodeobject.c:15669)
==93405==    by 0x4A41783: PyObject_SetAttrString (object.c:844)
==93405==    by 0x4A3E8F7: _add_methods_to_object (moduleobject.c:184)
==93405==    by 0x4A3F487: PyModule_AddFunctions (moduleobject.c:466)
==93405==    by 0x4A3F567: _PyModule_CreateInitialized (moduleobject.c:253)
==93405==    by 0x665793B: PyInit__ctypes (_ctypes.c:5854)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405== 
==93405== 560 bytes in 9 blocks are possibly lost in loss record 695 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:155)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:147)
==93405==    by 0x4AF8323: r_object (marshal.c:1207)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF95AB: read_object (marshal.c:1525)
==93405==    by 0x4AF9843: marshal_loads_impl (marshal.c:1834)
==93405==    by 0x4AF9843: marshal_loads (marshal.c.h:148)
==93405==    by 0x49AA24F: _PyEval_EvalFrameDefault (ceval.c:4816)
==93405== 
==93405== 568 bytes in 1 blocks are possibly lost in loss record 702 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A2C913: new_keys_object (dictobject.c:592)
==93405==    by 0x4A2D0FB: dictresize (dictobject.c:1225)
==93405==    by 0x4A3001F: insertion_resize (dictobject.c:1018)
==93405==    by 0x4A3001F: insertdict (dictobject.c:1084)
==93405==    by 0x4A414F7: _PyObject_GenericSetAttrWithDict (object.c:1426)
==93405==    by 0x4A415FB: PyObject_SetAttr (object.c:1048)
==93405==    by 0x4A4179B: PyObject_SetAttrString (object.c:847)
==93405==    by 0x4A3E8F7: _add_methods_to_object (moduleobject.c:184)
==93405==    by 0x4A3F0DB: PyModule_FromDefAndSpec2 (moduleobject.c:370)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405== 
==93405== 568 bytes in 1 blocks are possibly lost in loss record 703 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A2C913: new_keys_object (dictobject.c:592)
==93405==    by 0x4A2D0FB: dictresize (dictobject.c:1225)
==93405==    by 0x4A3001F: insertion_resize (dictobject.c:1018)
==93405==    by 0x4A3001F: insertdict (dictobject.c:1084)
==93405==    by 0x662E3BB: cache_struct_converter (_struct.c:2142)
==93405==    by 0x662E5DB: calcsize (_struct.c.h:202)
==93405==    by 0x49AA24F: _PyEval_EvalFrameDefault (ceval.c:4816)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x4AC7877: PyEval_EvalCode (ceval.c:1120)
==93405==    by 0x4AC15BF: builtin_exec_impl (bltinmodule.c:1057)
==93405==    by 0x4AC15BF: builtin_exec (bltinmodule.c.h:371)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405== 
==93405== 570 bytes in 9 blocks are possibly lost in loss record 704 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A6B783: PyUnicode_New (unicodeobject.c:1471)
==93405==    by 0x4A6BA9B: _PyUnicode_FromUCS1 (unicodeobject.c:2476)
==93405==    by 0x4A6BA9B: _PyUnicode_FromUCS1 (unicodeobject.c:2462)
==93405==    by 0x4AF7EE3: r_object (marshal.c:1151)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8873: r_object (marshal.c:1391)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF95AB: read_object (marshal.c:1525)
==93405== 
==93405== 610 bytes in 10 blocks are possibly lost in loss record 708 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A6B783: PyUnicode_New (unicodeobject.c:1471)
==93405==    by 0x4A6BA9B: _PyUnicode_FromUCS1 (unicodeobject.c:2476)
==93405==    by 0x4A6BA9B: _PyUnicode_FromUCS1 (unicodeobject.c:2462)
==93405==    by 0x4AF7EE3: r_object (marshal.c:1151)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF95AB: read_object (marshal.c:1525)
==93405==    by 0x4AF9843: marshal_loads_impl (marshal.c:1834)
==93405==    by 0x4AF9843: marshal_loads (marshal.c.h:148)
==93405==    by 0x49AA24F: _PyEval_EvalFrameDefault (ceval.c:4816)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== 631 bytes in 2 blocks are possibly lost in loss record 709 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A60C3B: type_new_set_doc (typeobject.c:2906)
==93405==    by 0x4A60C3B: type_new_set_attrs (typeobject.c:3095)
==93405==    by 0x4A60C3B: type_new_impl (typeobject.c:3204)
==93405==    by 0x4A60C3B: type_new (typeobject.c:3349)
==93405==    by 0x4A573E7: type_call (typeobject.c:1129)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x49FB623: _PyObject_FastCallDictTstate (call.c:141)
==93405==    by 0x4AC427B: builtin___build_class__ (bltinmodule.c:224)
==93405==    by 0x4A3D6B3: cfunction_vectorcall_FASTCALL_KEYWORDS (methodobject.c:446)
==93405==    by 0x49FBAE7: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBAE7: PyObject_Vectorcall (call.c:298)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x4AC7877: PyEval_EvalCode (ceval.c:1120)
==93405== 
==93405== 653 bytes in 12 blocks are possibly lost in loss record 716 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A6B783: PyUnicode_New (unicodeobject.c:1471)
==93405==    by 0x4A6BA9B: _PyUnicode_FromUCS1 (unicodeobject.c:2476)
==93405==    by 0x4A6BA9B: _PyUnicode_FromUCS1 (unicodeobject.c:2462)
==93405==    by 0x4AF7EE3: r_object (marshal.c:1151)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8883: r_object (marshal.c:1394)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF95AB: read_object (marshal.c:1525)
==93405== 
==93405== 672 bytes in 3 blocks are possibly lost in loss record 718 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A40FB7: _PyObject_New (object.c:187)
==93405==    by 0x49FFDAF: _PyCode_New (codeobject.c:389)
==93405==    by 0x4AF89BB: r_object (marshal.c:1456)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF95AB: read_object (marshal.c:1525)
==93405==    by 0x4AF9843: marshal_loads_impl (marshal.c:1834)
==93405==    by 0x4AF9843: marshal_loads (marshal.c.h:148)
==93405==    by 0x49AA24F: _PyEval_EvalFrameDefault (ceval.c:4816)
==93405== 
==93405== 696 bytes in 9 blocks are possibly lost in loss record 719 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:155)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:147)
==93405==    by 0x4AF8323: r_object (marshal.c:1207)
==93405==    by 0x4AF8873: r_object (marshal.c:1391)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF95AB: read_object (marshal.c:1525)
==93405==    by 0x4AF9843: marshal_loads_impl (marshal.c:1834)
==93405==    by 0x4AF9843: marshal_loads (marshal.c.h:148)
==93405==    by 0x49AA24F: _PyEval_EvalFrameDefault (ceval.c:4816)
==93405== 
==93405== 760 bytes in 11 blocks are possibly lost in loss record 723 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:155)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:147)
==93405==    by 0x4AF8323: r_object (marshal.c:1207)
==93405==    by 0x4AF8883: r_object (marshal.c:1394)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF95AB: read_object (marshal.c:1525)
==93405== 
==93405== 1,000 bytes in 5 blocks are possibly lost in loss record 740 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A5688F: _PyType_AllocNoTrack (typeobject.c:1162)
==93405==    by 0x4A56953: PyType_GenericAlloc (typeobject.c:1186)
==93405==    by 0x6651937: GenericPyCData_new (_ctypes.c:3239)
==93405==    by 0x6654C6F: PyCFuncPtr_new (_ctypes.c:3736)
==93405==    by 0x4A573E7: type_call (typeobject.c:1129)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x4AC7877: PyEval_EvalCode (ceval.c:1120)
==93405==    by 0x4AC15BF: builtin_exec_impl (bltinmodule.c:1057)
==93405==    by 0x4AC15BF: builtin_exec (bltinmodule.c.h:371)
==93405== 
==93405== 1,008 bytes in 12 blocks are possibly lost in loss record 741 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:155)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:147)
==93405==    by 0x4AF8323: r_object (marshal.c:1207)
==93405==    by 0x4AF8873: r_object (marshal.c:1391)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF95AB: read_object (marshal.c:1525)
==93405== 
==93405== 1,008 bytes in 21 blocks are possibly lost in loss record 742 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50F83: PyTuple_Pack (tupleobject.c:246)
==93405==    by 0x4A5905F: type_ready_set_bases (typeobject.c:6148)
==93405==    by 0x4A5905F: type_ready (typeobject.c:6465)
==93405==    by 0x4A5905F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x4AFCBEF: PyModule_AddType (modsupport.c:706)
==93405==    by 0x4B630DF: itertoolsmodule_exec (itertoolsmodule.c:4873)
==93405==    by 0x4A3F7A3: PyModule_ExecDef (moduleobject.c:428)
==93405==    by 0x4AEC003: exec_builtin_or_dynamic (import.c:2354)
==93405==    by 0x4AEC003: exec_builtin_or_dynamic (import.c:2335)
==93405==    by 0x4AEC003: _imp_exec_dynamic_impl (import.c:2428)
==93405==    by 0x4AEC003: _imp_exec_dynamic (import.c.h:474)
==93405==    by 0x4A3DB73: cfunction_vectorcall_O (methodobject.c:516)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405== 
==93405== 1,063 bytes in 9 blocks are possibly lost in loss record 745 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x49F121F: _PyBytes_FromSize (bytesobject.c:104)
==93405==    by 0x49F121F: _PyBytes_FromSize (bytesobject.c:85)
==93405==    by 0x49F1EAB: PyBytes_FromStringAndSize (bytesobject.c:134)
==93405==    by 0x49F1EAB: PyBytes_FromStringAndSize (bytesobject.c:117)
==93405==    by 0x4AF8673: r_object (marshal.c:1108)
==93405==    by 0x4AF884F: r_object (marshal.c:1385)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF95AB: read_object (marshal.c:1525)
==93405==    by 0x4AF9843: marshal_loads_impl (marshal.c:1834)
==93405==    by 0x4AF9843: marshal_loads (marshal.c.h:148)
==93405==    by 0x49AA24F: _PyEval_EvalFrameDefault (ceval.c:4816)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== 1,064 bytes in 19 blocks are possibly lost in loss record 746 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B2868B: _PyObject_GC_NewVar (gcmodule.c:2320)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:155)
==93405==    by 0x4A50C27: PyTuple_New (tupleobject.c:147)
==93405==    by 0x4A6187F: mro_implementation (typeobject.c:1967)
==93405==    by 0x4A61BF3: mro_invoke (typeobject.c:2104)
==93405==    by 0x4A61BF3: mro_internal (typeobject.c:2161)
==93405==    by 0x4A57A9F: type_ready_mro (typeobject.c:6238)
==93405==    by 0x4A57A9F: type_ready (typeobject.c:6468)
==93405==    by 0x4A57A9F: PyType_Ready (typeobject.c:6510)
==93405==    by 0x4AFCBEF: PyModule_AddType (modsupport.c:706)
==93405==    by 0x4B630DF: itertoolsmodule_exec (itertoolsmodule.c:4873)
==93405==    by 0x4A3F7A3: PyModule_ExecDef (moduleobject.c:428)
==93405==    by 0x4AEC003: exec_builtin_or_dynamic (import.c:2354)
==93405==    by 0x4AEC003: exec_builtin_or_dynamic (import.c:2335)
==93405==    by 0x4AEC003: _imp_exec_dynamic_impl (import.c:2428)
==93405==    by 0x4AEC003: _imp_exec_dynamic (import.c.h:474)
==93405== 
==93405== 1,110 bytes in 10 blocks are possibly lost in loss record 753 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x49F121F: _PyBytes_FromSize (bytesobject.c:104)
==93405==    by 0x49F121F: _PyBytes_FromSize (bytesobject.c:85)
==93405==    by 0x49F1EAB: PyBytes_FromStringAndSize (bytesobject.c:134)
==93405==    by 0x49F1EAB: PyBytes_FromStringAndSize (bytesobject.c:117)
==93405==    by 0x4AF8673: r_object (marshal.c:1108)
==93405==    by 0x4AF8907: r_object (marshal.c:1418)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF95AB: read_object (marshal.c:1525)
==93405==    by 0x4AF9843: marshal_loads_impl (marshal.c:1834)
==93405==    by 0x4AF9843: marshal_loads (marshal.c.h:148)
==93405==    by 0x49AA24F: _PyEval_EvalFrameDefault (ceval.c:4816)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== 1,520 bytes in 10 blocks are possibly lost in loss record 761 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4B28597: gc_alloc (gcmodule.c:2285)
==93405==    by 0x4B285FF: _PyObject_GC_New (gcmodule.c:2300)
==93405==    by 0x4A1A367: PyFunction_NewWithQualName (funcobject.c:96)
==93405==    by 0x49A718B: _PyEval_EvalFrameDefault (ceval.c:5130)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x4AC7877: PyEval_EvalCode (ceval.c:1120)
==93405==    by 0x4AC15BF: builtin_exec_impl (bltinmodule.c:1057)
==93405==    by 0x4AC15BF: builtin_exec (bltinmodule.c.h:371)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405== 
==93405== 1,704 bytes in 3 blocks are possibly lost in loss record 767 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A2C913: new_keys_object (dictobject.c:592)
==93405==    by 0x4A3444F: _PyDict_NewKeysForClass (dictobject.c:4945)
==93405==    by 0x4A61053: type_new_impl (typeobject.c:3218)
==93405==    by 0x4A61053: type_new (typeobject.c:3349)
==93405==    by 0x4A573E7: type_call (typeobject.c:1129)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x49FB623: _PyObject_FastCallDictTstate (call.c:141)
==93405==    by 0x4AC427B: builtin___build_class__ (bltinmodule.c:224)
==93405==    by 0x4A3D6B3: cfunction_vectorcall_FASTCALL_KEYWORDS (methodobject.c:446)
==93405==    by 0x49FBAE7: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBAE7: PyObject_Vectorcall (call.c:298)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405== 
==93405== 2,124 bytes in 13 blocks are possibly lost in loss record 778 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A6B783: PyUnicode_New (unicodeobject.c:1471)
==93405==    by 0x4A6BA9B: _PyUnicode_FromUCS1 (unicodeobject.c:2476)
==93405==    by 0x4A6BA9B: _PyUnicode_FromUCS1 (unicodeobject.c:2462)
==93405==    by 0x4AF7EE3: r_object (marshal.c:1151)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF95AB: read_object (marshal.c:1525)
==93405==    by 0x4AF9843: marshal_loads_impl (marshal.c:1834)
==93405==    by 0x4AF9843: marshal_loads (marshal.c.h:148)
==93405==    by 0x49AA24F: _PyEval_EvalFrameDefault (ceval.c:4816)
==93405== 
==93405== 2,200 bytes in 1 blocks are possibly lost in loss record 784 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A2C913: new_keys_object (dictobject.c:592)
==93405==    by 0x4A2D0FB: dictresize (dictobject.c:1225)
==93405==    by 0x4A3001F: insertion_resize (dictobject.c:1018)
==93405==    by 0x4A3001F: insertdict (dictobject.c:1084)
==93405==    by 0x4A3422F: PyDict_SetItemString (dictobject.c:3578)
==93405==    by 0x4AFC9C7: PyModule_AddObjectRef (modsupport.c:662)
==93405==    by 0x6657E1F: _ctypes_add_objects (_ctypes.c:5812)
==93405==    by 0x6657E1F: _ctypes_mod_exec (_ctypes.c:5844)
==93405==    by 0x6657E1F: PyInit__ctypes (_ctypes.c:5859)
==93405==    by 0x4AF06FB: _PyImport_LoadDynamicModuleWithSpec (importdl.c:167)
==93405==    by 0x4AED6C7: _imp_create_dynamic_impl (import.c:2406)
==93405==    by 0x4AED6C7: _imp_create_dynamic (import.c.h:446)
==93405==    by 0x4A3DDFF: cfunction_vectorcall_FASTCALL (methodobject.c:430)
==93405==    by 0x49A6F6B: do_call_core (ceval.c:7033)
==93405==    by 0x49A6F6B: _PyEval_EvalFrameDefault (ceval.c:5114)
==93405== 
==93405== 2,240 bytes in 10 blocks are possibly lost in loss record 785 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A40FB7: _PyObject_New (object.c:187)
==93405==    by 0x49FFDAF: _PyCode_New (codeobject.c:389)
==93405==    by 0x4AF89BB: r_object (marshal.c:1456)
==93405==    by 0x4AF8343: r_object (marshal.c:1213)
==93405==    by 0x4AF8863: r_object (marshal.c:1388)
==93405==    by 0x4AF95AB: read_object (marshal.c:1525)
==93405==    by 0x4AF9843: marshal_loads_impl (marshal.c:1834)
==93405==    by 0x4AF9843: marshal_loads (marshal.c.h:148)
==93405==    by 0x49AA24F: _PyEval_EvalFrameDefault (ceval.c:4816)
==93405==    by 0x4AC77DB: _PyEval_EvalFrame (pycore_ceval.h:53)
==93405==    by 0x4AC77DB: _PyEval_Vector (ceval.c:6149)
==93405==    by 0x49FBE0F: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBE0F: object_vacall (call.c:784)
==93405== 
==93405== 2,856 bytes in 3 blocks are possibly lost in loss record 797 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A5688F: _PyType_AllocNoTrack (typeobject.c:1162)
==93405==    by 0x4A56953: PyType_GenericAlloc (typeobject.c:1186)
==93405==    by 0x4A60A9F: type_new_alloc (typeobject.c:2763)
==93405==    by 0x4A60A9F: type_new_init (typeobject.c:3176)
==93405==    by 0x4A60A9F: type_new_impl (typeobject.c:3199)
==93405==    by 0x4A60A9F: type_new (typeobject.c:3349)
==93405==    by 0x4A573E7: type_call (typeobject.c:1129)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x49FB623: _PyObject_FastCallDictTstate (call.c:141)
==93405==    by 0x4AC427B: builtin___build_class__ (bltinmodule.c:224)
==93405==    by 0x4A3D6B3: cfunction_vectorcall_FASTCALL_KEYWORDS (methodobject.c:446)
==93405==    by 0x49FBAE7: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBAE7: PyObject_Vectorcall (call.c:298)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405== 
==93405== 5,680 bytes in 10 blocks are possibly lost in loss record 808 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A2C913: new_keys_object (dictobject.c:592)
==93405==    by 0x4A3444F: _PyDict_NewKeysForClass (dictobject.c:4945)
==93405==    by 0x4A61053: type_new_impl (typeobject.c:3218)
==93405==    by 0x4A61053: type_new (typeobject.c:3349)
==93405==    by 0x6655477: PyCSimpleType_new (_ctypes.c:2087)
==93405==    by 0x4A573E7: type_call (typeobject.c:1129)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x4AC427B: builtin___build_class__ (bltinmodule.c:224)
==93405==    by 0x4A3D6B3: cfunction_vectorcall_FASTCALL_KEYWORDS (methodobject.c:446)
==93405==    by 0x49FBAE7: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBAE7: PyObject_Vectorcall (call.c:298)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405== 
==93405== 9,520 bytes in 10 blocks are possibly lost in loss record 817 of 819
==93405==    at 0x4866EC0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-arm64-linux.so)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1989)
==93405==    by 0x4A46377: _PyObject_Malloc (obmalloc.c:1982)
==93405==    by 0x4A5688F: _PyType_AllocNoTrack (typeobject.c:1162)
==93405==    by 0x4A56953: PyType_GenericAlloc (typeobject.c:1186)
==93405==    by 0x4A60A9F: type_new_alloc (typeobject.c:2763)
==93405==    by 0x4A60A9F: type_new_init (typeobject.c:3176)
==93405==    by 0x4A60A9F: type_new_impl (typeobject.c:3199)
==93405==    by 0x4A60A9F: type_new (typeobject.c:3349)
==93405==    by 0x6655477: PyCSimpleType_new (_ctypes.c:2087)
==93405==    by 0x4A573E7: type_call (typeobject.c:1129)
==93405==    by 0x49FB473: _PyObject_MakeTpCall (call.c:214)
==93405==    by 0x4AC427B: builtin___build_class__ (bltinmodule.c:224)
==93405==    by 0x4A3D6B3: cfunction_vectorcall_FASTCALL_KEYWORDS (methodobject.c:446)
==93405==    by 0x49FBAE7: _PyObject_VectorcallTstate (pycore_call.h:89)
==93405==    by 0x49FBAE7: PyObject_Vectorcall (call.c:298)
==93405==    by 0x49A9953: _PyEval_EvalFrameDefault (ceval.c:4611)
==93405== 
==93405== LEAK SUMMARY:
==93405==    definitely lost: 0 bytes in 0 blocks
==93405==    indirectly lost: 0 bytes in 0 blocks
==93405==      possibly lost: 60,305 bytes in 532 blocks
==93405==    still reachable: 303,923 bytes in 2,319 blocks
==93405==         suppressed: 0 bytes in 0 blocks
==93405== Reachable blocks (those to which a pointer was found) are not shown.
==93405== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==93405== 
==93405== Use --track-origins=yes to see where uninitialised values come from
==93405== For lists of detected and suppressed errors, rerun with: -s
==93405== ERROR SUMMARY: 293 errors from 210 contexts (suppressed: 0 from 0)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46849>
_______________________________________

From report at bugs.python.org  Sat Feb 26 14:28:21 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Feb 2022 19:28:21 +0000
Subject: [issue46849] Memory problems detected using Valgrind
In-Reply-To: <1645711886.58.0.922948546021.issue46849@roundup.psfhosted.org>
Message-ID: <1645903701.47.0.884975682695.issue46849@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Posting a thousand line message makes following a discussion extremely difficult.  Move it into an attachment, if you did not do that already, and delete the message by 'editing' it.  As I said, I cannot otherwise respond to this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46849>
_______________________________________

From report at bugs.python.org  Sat Feb 26 15:01:19 2022
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 26 Feb 2022 20:01:19 +0000
Subject: [issue44035] Regenerating the configure script fails even if
 dependencies are satisfied
In-Reply-To: <1620147514.31.0.864280114209.issue44035@roundup.psfhosted.org>
Message-ID: <1645905679.94.0.82673364647.issue44035@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

For me it took `docker run -v (pwd):/src quay.io/tiran/cpython_autoconf` (on fish and didn't run `docker pull` ahead of time).

@tiran are you  okay if we document your image and how to run it at https://devguide.python.org/setup/?highlight=autoconf#regenerate-configure ?

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44035>
_______________________________________

From report at bugs.python.org  Sat Feb 26 17:10:23 2022
From: report at bugs.python.org (benrg)
Date: Sat, 26 Feb 2022 22:10:23 +0000
Subject: [issue28824] os.environ should preserve the case of the OS keys ?
In-Reply-To: <1480359346.4.0.287394822331.issue28824@psf.upfronthosting.co.za>
Message-ID: <1645913423.06.0.727059274858.issue28824@roundup.psfhosted.org>


benrg <benrudiak at gmail.com> added the comment:

This issue should be marked dependent on issue 43702 or issue 46862, since fixing it could break third-party code unless they're fixed first.


> Given 'nt.environ' is available without case remapping, I think that's the best workaround.

Right now, it's not a good workaround because it contains the environment at the time the interpreter was started, not the current environment. On Posix, _Environ takes a reference to posix.environ and uses it directly, so it does get updated. On Windows, _Environ gets a rewritten dictionary and nt.environ is just a space-wasting attractive nuisance. I think it should be replaced with getenviron() which builds a dict from the environment block each time it's called. But posix.environ is documented (though nt.environ isn't), so maybe not.


> class _CaseInsensitiveString(str):

I think there should be a public class like this. It could be useful to email.message.Message and its clients like urllib. They currently store headers in a list and every operation is O(n).

The semantics are tricky. As written, it violates the requirement that equal objects have equal hashes. To fix that, you'd have to make every CIS compare unequal to every str. At that point, it probably shouldn't be a str subclass, which also has the advantage that it's not limited to strings. It can be a generic compare-by-key wrapper.

----------
nosy: +benrg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28824>
_______________________________________

From report at bugs.python.org  Sat Feb 26 18:08:33 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Feb 2022 23:08:33 +0000
Subject: [issue46852] Remove the float.__setformat__() method
In-Reply-To: <1645747677.37.0.919337626983.issue46852@roundup.psfhosted.org>
Message-ID: <1645916913.44.0.771411835977.issue46852@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +29724
pull_request: https://github.com/python/cpython/pull/31601

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46852>
_______________________________________

From report at bugs.python.org  Sat Feb 26 18:14:35 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Feb 2022 23:14:35 +0000
Subject: [issue46606] Large C stack usage of os.getgroups() and os.setgroups()
In-Reply-To: <1643771204.31.0.0513908090604.issue46606@roundup.psfhosted.org>
Message-ID: <1645917275.92.0.00168969682576.issue46606@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset e02c47528b31f513d5f5d6eb91b8c9714134cea2 by Victor Stinner in branch 'main':
bpo-46606: os.getgroups() doesn't overallocate (GH-31569)
https://github.com/python/cpython/commit/e02c47528b31f513d5f5d6eb91b8c9714134cea2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46606>
_______________________________________

From report at bugs.python.org  Sat Feb 26 18:16:35 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Feb 2022 23:16:35 +0000
Subject: [issue46606] Large C stack usage of os.getgroups() and os.setgroups()
In-Reply-To: <1643771204.31.0.0513908090604.issue46606@roundup.psfhosted.org>
Message-ID: <1645917395.82.0.890844238537.issue46606@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> NGROUPS_MAX is 65536 and sizeof(gid_t) is 4 on Ubuntu 20.04, so grouplist is 262144bytes.

Oops, that's a lot! Nicely spotted! Yeah, it's perfectly fine to allocate a temporary array on the heap memory. There is no need to micro-optimize this function.

Maybe the code was written when NGROUPS_MAX was way smaller (64?).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46606>
_______________________________________

From report at bugs.python.org  Sat Feb 26 18:17:50 2022
From: report at bugs.python.org (grifonice99)
Date: Sat, 26 Feb 2022 23:17:50 +0000
Subject: [issue46867] difference of work
Message-ID: <1645917470.03.0.0455277149527.issue46867@roundup.psfhosted.org>


New submission from grifonice99 <grifonice99 at gmail.com>:

I was developing a ThreadPool with priority on windows, once done all the tests on windows I moved to linux and once I moved it didn't work anymore, because in the thread_start function there is the self that doesn't "update", thing that it does on windows

----------
files: ThreadPool.py
messages: 414118
nosy: grifonice99
priority: normal
severity: normal
status: open
title: difference of work
type: behavior
versions: Python 3.10
Added file: https://bugs.python.org/file50648/ThreadPool.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46867>
_______________________________________

From report at bugs.python.org  Sat Feb 26 18:18:50 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Feb 2022 23:18:50 +0000
Subject: [issue46430] intern strings in deepfrozen modules
In-Reply-To: <1642590983.92.0.896257318647.issue46430@roundup.psfhosted.org>
Message-ID: <1645917530.37.0.857129336764.issue46430@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

commit 0d9b565e62a5fc8c3e9b8c64cce764fe084ccb2b
Author: Kumar Aditya <59607654+kumaraditya303 at users.noreply.github.com>
Date:   Sat Feb 26 22:05:03 2022 +0530

    Propagate errors (however unlikely) from _Py_Deepfreeze_Init() (GH-31596)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46430>
_______________________________________

From report at bugs.python.org  Sat Feb 26 18:21:02 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Feb 2022 23:21:02 +0000
Subject: [issue46430] intern strings in deepfrozen modules
In-Reply-To: <1642590983.92.0.896257318647.issue46430@roundup.psfhosted.org>
Message-ID: <1645917662.95.0.13226435189.issue46430@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> The other functions you are calling *do* return errors. You should not ignore those. If any errors are reported the caller can decide what to do (e.g. call Py_FatalError().

PEP 587 introduced PyStatus to Python startup code which let the Py_Initialize() caller to decide how to handle errors ;-) For example, you can open a graphical popup rather than killing the process with SIGABRT (Py_FatalError() behavior) which might be more user friendly :-D Or just log the error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46430>
_______________________________________

From report at bugs.python.org  Sat Feb 26 18:25:57 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Feb 2022 23:25:57 +0000
Subject: [issue46748] Python.h includes stdbool.h
In-Reply-To: <1644830899.62.0.590844926135.issue46748@roundup.psfhosted.org>
Message-ID: <1645917957.82.0.365175039028.issue46748@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset e182c660b63bc23420fb9f0593d77a3fa3b7f1c7 by Kumar Aditya in branch 'main':
bpo-46748: Fix ctypes test_frozentable() (GH-31600)
https://github.com/python/cpython/commit/e182c660b63bc23420fb9f0593d77a3fa3b7f1c7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46748>
_______________________________________

From report at bugs.python.org  Sat Feb 26 18:27:26 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Feb 2022 23:27:26 +0000
Subject: [issue46608] Exclude marshalled-frozen data if deep-freezing to save
 300 KB space
In-Reply-To: <1643792907.85.0.286906427988.issue46608@roundup.psfhosted.org>
Message-ID: <1645918046.28.0.928455385166.issue46608@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

https://docs.python.org/dev/whatsnew/3.11.html#c-api-changes documents the addition of the "is_package" member to the _frozen structure, but it doesn't mention the new "get_code" member. Can it be also documented?

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46608>
_______________________________________

From report at bugs.python.org  Sat Feb 26 18:28:44 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Feb 2022 23:28:44 +0000
Subject: [issue46857] Python leaks one reference at exit on Windows
In-Reply-To: <1645808231.81.0.426207041717.issue46857@roundup.psfhosted.org>
Message-ID: <1645918124.1.0.679822022707.issue46857@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset ad56919c5ed54523f866e6605a2573ab7b7d5235 by Victor Stinner in branch 'main':
bpo-46857: Fix refleak in OSError INIT_ALIAS() (GH-31594)
https://github.com/python/cpython/commit/ad56919c5ed54523f866e6605a2573ab7b7d5235


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46857>
_______________________________________

From report at bugs.python.org  Sat Feb 26 18:29:11 2022
From: report at bugs.python.org (grifonice99)
Date: Sat, 26 Feb 2022 23:29:11 +0000
Subject: [issue46867] difference of work
In-Reply-To: <1645917470.03.0.0455277149527.issue46867@roundup.psfhosted.org>
Message-ID: <1645918151.21.0.10019420069.issue46867@roundup.psfhosted.org>


Change by grifonice99 <grifonice99 at gmail.com>:


----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46867>
_______________________________________

From report at bugs.python.org  Sat Feb 26 18:31:59 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Feb 2022 23:31:59 +0000
Subject: [issue46857] Python leaks one reference at exit on Windows
In-Reply-To: <1645808231.81.0.426207041717.issue46857@roundup.psfhosted.org>
Message-ID: <1645918319.27.0.55790404767.issue46857@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Initially, I modified Py_INCREF to dump the object (addr & tp_name) on
> initial inc (ob_refcnt == 1) and Py_DECREF to dump on final dec
> (ob_refcnt == 0). Then filter that list (~65K) to find objects not
> dealloc'ed.  Given those names (~200), cross-check with source files
> containing 'ifdef MS_WINDOWS' (and related spellings).

That's smart! Thanks for sharing. It may help to identify future leaks.


> Even using that change, I still have negative refs (but I still have
Py_TRACE_REFS defined)

Ah, maybe testing with Py_TRACE_REFS shows more bugs. I didn't try Py_TRACE_REFS recently. Well, if someone finds why it's becoming negative, a fix would be welcomed :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46857>
_______________________________________

From report at bugs.python.org  Sat Feb 26 18:34:34 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Feb 2022 23:34:34 +0000
Subject: [issue46857] Python leaks one reference at exit on Windows
In-Reply-To: <1645808231.81.0.426207041717.issue46857@roundup.psfhosted.org>
Message-ID: <1645918474.22.0.36233776395.issue46857@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I just built Python with --with-trace-refs. On Linux, it works as expected:

$ ./python -I -X showrefcount -c pass 
[0 refs, 0 blocks]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46857>
_______________________________________

From report at bugs.python.org  Sat Feb 26 18:35:53 2022
From: report at bugs.python.org (benrg)
Date: Sat, 26 Feb 2022 23:35:53 +0000
Subject: [issue46868] Improve performance of math.prod with bignums (and
 functools.reduce?)
Message-ID: <1645918553.19.0.346410511769.issue46868@roundup.psfhosted.org>


New submission from benrg <benrudiak at gmail.com>:

math.prod is slow at multiplying arbitrary-precision numbers. E.g., compare the run time of factorial(50000) to prod(range(2, 50001)).

factorial has some special-case optimizations, but the bulk of the difference is due to prod evaluating an expression tree of depth n. If you re-parenthesize the product so that the tree has depth log n, as factorial does, it's much faster. The evaluation order of prod isn't documented, so I think the change would be safe.

factorial uses recursion to build the tree, but it can be done iteratively with no advance knowledge of the total number of nodes.

This trick is widely useful for turning a way of combining two things into a way of combining many things, so I wouldn't mind seeing a generic version of it in the standard library, e.g. reduce(..., order='mid'). For many specific cases there are more efficient alternatives (''.join, itertools.chain, set.unions, heapq.merge), but it's nice to have a recipe that saves you the trouble of writing special-case algorithms at the cost of a log factor that's often ignorable.

----------
components: Library (Lib)
messages: 414126
nosy: benrg
priority: normal
severity: normal
status: open
title: Improve performance of math.prod with bignums (and functools.reduce?)
type: enhancement
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46868>
_______________________________________

From report at bugs.python.org  Sat Feb 26 18:45:31 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 26 Feb 2022 23:45:31 +0000
Subject: [issue46430] intern strings in deepfrozen modules
In-Reply-To: <1642590983.92.0.896257318647.issue46430@roundup.psfhosted.org>
Message-ID: <1645919131.42.0.154509176144.issue46430@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

> PEP 587 introduced PyStatus to Python startup code which let the Py_Initialize() caller to decide how to handle errors ;-) For example, you can open a graphical popup rather than killing the process with SIGABRT (Py_FatalError() behavior) which might be more user friendly :-D Or just log the error.

That's up to pycore_interp_init() in pylifecycle.c now. Kumar called _PyStatus_ERR() there, so I think nothing more needs to be done.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46430>
_______________________________________

From report at bugs.python.org  Sat Feb 26 18:52:08 2022
From: report at bugs.python.org (Jeremy Kloth)
Date: Sat, 26 Feb 2022 23:52:08 +0000
Subject: [issue46857] Python leaks one reference at exit on Windows
In-Reply-To: <1645918474.22.0.36233776395.issue46857@roundup.psfhosted.org>
Message-ID: <CAGvrs3JrGOEa=L7aeopWB8CYCHgSB=7hpN=tZ-boM28JEW+K-g@mail.gmail.com>


Jeremy Kloth <jeremy.kloth at gmail.com> added the comment:

Did you also modify initconfig.c?  That part is required as the usual
processing of the environment variable PYTHONDUMPREFS needed to enable
tracing output is ignored with -I

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46857>
_______________________________________

From report at bugs.python.org  Sat Feb 26 19:05:23 2022
From: report at bugs.python.org (Ned Deily)
Date: Sun, 27 Feb 2022 00:05:23 +0000
Subject: [issue46868] Improve performance of math.prod with bignums (and
 functools.reduce?)
In-Reply-To: <1645918553.19.0.346410511769.issue46868@roundup.psfhosted.org>
Message-ID: <1645920323.47.0.688118251317.issue46868@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
nosy: +mark.dickinson, rhettinger, tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46868>
_______________________________________

From report at bugs.python.org  Sat Feb 26 19:09:37 2022
From: report at bugs.python.org (Evernow)
Date: Sun, 27 Feb 2022 00:09:37 +0000
Subject: [issue46869] platform.release() and sys returns wrong version on
 Windows 11
Message-ID: <1645920577.85.0.691364066718.issue46869@roundup.psfhosted.org>


New submission from Evernow <danielsuarez369 at protonmail.com>:

Hello.

On Windows 11 the platform module returns Windows 10 instead of Windows 11, same for the sys module. 

Python 3.10.2 (tags/v3.10.2:a58ebcc, Jan 17 2022, 14:12:15) [MSC v.1929 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform
>>> platform.release()
'10'
>>> import sys
>>> sys.getwindowsversion().platform_version
(10, 0, 22000)

----------
components: Windows
messages: 414129
nosy: Evernow, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: platform.release() and sys returns wrong version on Windows 11
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46869>
_______________________________________

From report at bugs.python.org  Sat Feb 26 19:11:40 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 27 Feb 2022 00:11:40 +0000
Subject: [issue46857] Python leaks one reference at exit on Windows
In-Reply-To: <1645808231.81.0.426207041717.issue46857@roundup.psfhosted.org>
Message-ID: <1645920700.07.0.560494654002.issue46857@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Ah, with PYTHONDUMPREFS=1 (and without -I), I get a negative ref count:

$ PYTHONDUMPREFS=1 ./python -X showrefcount -c pass
[-10 refs, 0 blocks]

I don't plan to investigate this issue. I'm not using PYTHONDUMPREFS=1 anymore.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46857>
_______________________________________

From report at bugs.python.org  Sat Feb 26 19:12:37 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 27 Feb 2022 00:12:37 +0000
Subject: [issue46852] Remove the float.__setformat__() method
In-Reply-To: <1645747677.37.0.919337626983.issue46852@roundup.psfhosted.org>
Message-ID: <1645920757.15.0.885158114676.issue46852@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 5a1c637ec6264790d3cfeef46815c62c32b510f3 by Victor Stinner in branch 'main':
bpo-46852: Restore test_getformat() test (GH-31601)
https://github.com/python/cpython/commit/5a1c637ec6264790d3cfeef46815c62c32b510f3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46852>
_______________________________________

From report at bugs.python.org  Sat Feb 26 20:12:03 2022
From: report at bugs.python.org (Pocas)
Date: Sun, 27 Feb 2022 01:12:03 +0000
Subject: [issue46870] Improper Input Validation in urlparse
Message-ID: <1645924323.46.0.342217272005.issue46870@roundup.psfhosted.org>


New submission from Pocas <pocas.cyber at gmail.com>:

If http:@localhost url is entered as an argument value of the urlpasre() function, the parser cannot parse it properly. Since http:@localhost is a valid URL, the character after the @ character must be parsed as a hostname.

Python 3.9.10 (main, Jan 15 2022, 11:48:04)
[Clang 13.0.0 (clang-1300.0.29.3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from urllib.parse import urlparse
>>> print(urlparse('http:@localhost'))
ParseResult(scheme='http', netloc='', path='@localhost', params='', query='', fragment='')
>>>

----------
messages: 414132
nosy: P0cas
priority: normal
severity: normal
status: open
title: Improper Input Validation in urlparse
type: performance
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46870>
_______________________________________

From report at bugs.python.org  Sat Feb 26 20:12:54 2022
From: report at bugs.python.org (Pocas)
Date: Sun, 27 Feb 2022 01:12:54 +0000
Subject: [issue46870] Improper Input Validation in urlparse
In-Reply-To: <1645924323.46.0.342217272005.issue46870@roundup.psfhosted.org>
Message-ID: <1645924374.11.0.224625880872.issue46870@roundup.psfhosted.org>


Change by Pocas <pocas.cyber at gmail.com>:


----------
type: performance -> security

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46870>
_______________________________________

From report at bugs.python.org  Sat Feb 26 20:17:24 2022
From: report at bugs.python.org (Pocas)
Date: Sun, 27 Feb 2022 01:17:24 +0000
Subject: [issue46870] Improper Input Validation in urlparse
In-Reply-To: <1645924323.46.0.342217272005.issue46870@roundup.psfhosted.org>
Message-ID: <1645924644.11.0.346726622626.issue46870@roundup.psfhosted.org>


Pocas <pocas.cyber at gmail.com> added the comment:

>>> print(urlparse('https:\\google.com'))
ParseResult(scheme='https', netloc='', path='\\google.com', params='', query='', fragment='')
>>> print(urlparse('https://google.com at localhost'))
ParseResult(scheme='https', netloc='google.com at localhost', path='', params='', query='', fragment='')
>>>

Perhaps this parser is not able to parse the URL normally.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46870>
_______________________________________

From report at bugs.python.org  Sat Feb 26 21:35:42 2022
From: report at bugs.python.org (Inada Naoki)
Date: Sun, 27 Feb 2022 02:35:42 +0000
Subject: [issue46864] Deprecate ob_shash in BytesObject
In-Reply-To: <1645865345.09.0.509753942233.issue46864@roundup.psfhosted.org>
Message-ID: <1645929342.02.0.669268178347.issue46864@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

> But some programs can still work with encoded bytes instead of strings. In particular os.environ and os.environb are implemented as dict of bytes on non-Windows.

This change doesn't affect to os.environ.

os.environ[key] does `key.encode(sys.getfilesystemencoding(), "surrogateescape")` internally. So the encoded key doesn't have cached hash.
On the other hand, dict (`self._data`) has own hash cache. So it don't use hash cached in the bytes objects.

On the other hand, this change will affect `os.environb[key]` if key is used repeatedly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46864>
_______________________________________

From report at bugs.python.org  Sat Feb 26 21:42:33 2022
From: report at bugs.python.org (Inada Naoki)
Date: Sun, 27 Feb 2022 02:42:33 +0000
Subject: [issue46845] dict: Use smaller entry for Unicode-key only dict.
In-Reply-To: <1645688455.61.0.00785191075466.issue46845@roundup.psfhosted.org>
Message-ID: <1645929753.44.0.433894582777.issue46845@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

I added _PyDict_FromItems() to the PR.
It checks that all keys are Unicode or not before creating dict.
_PyDict_NewPresized() just returns general-purpose dict. But it isn't used from CPython core. It is just kept for compatibility (for Cython).

```
$ ./python -m pyperf timeit --compare-to ../cpython/python -- '{"k1":1, "k2":2, "k3":3, "k4":4, "k5":5, "k6":6}'
/home/inada-n/work/python/cpython/python: ..................... 198 ns +- 5 ns
/home/inada-n/work/python/dict-compact/python: ..................... 213 ns +- 6 ns

Mean +- std dev: [/home/inada-n/work/python/cpython/python] 198 ns +- 5 ns -> [/home/inada-n/work/python/dict-compact/python] 213 ns +- 6 ns: 1.07x slower
```

Overhead of checking keys types is not so large.
Additionally, we can reduce some code from ceval.c.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46845>
_______________________________________

From report at bugs.python.org  Sat Feb 26 21:52:55 2022
From: report at bugs.python.org (Inada Naoki)
Date: Sun, 27 Feb 2022 02:52:55 +0000
Subject: [issue46864] Deprecate ob_shash in BytesObject
In-Reply-To: <1645865345.09.0.509753942233.issue46864@roundup.psfhosted.org>
Message-ID: <1645930375.63.0.402828804487.issue46864@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

When removed shash:

```
## small key
$ ./python -m pyperf timeit --compare-to ../cpython/python -s 'd={b"foo":1, b"bar":2, b"buzz":3}' -- 'b"key" in d'
/home/inada-n/work/python/cpython/python: ..................... 23.2 ns +- 1.7 ns
/home/inada-n/work/python/remove-bytes-hash/python: ..................... 40.0 ns +- 1.5 ns

Mean +- std dev: [/home/inada-n/work/python/cpython/python] 23.2 ns +- 1.7 ns -> [/home/inada-n/work/python/remove-bytes-hash/python] 40.0 ns +- 1.5 ns: 1.73x slower

## large key
$ ./python -m pyperf timeit --compare-to ../cpython/python -s 'd={b"foo":1, b"bar":2, b"buzz":3};k=b"key"*100' -- 'k in d'
/home/inada-n/work/python/cpython/python: ..................... 22.3 ns +- 1.2 ns
/home/inada-n/work/python/remove-bytes-hash/python: ..................... 108 ns +- 2 ns

Mean +- std dev: [/home/inada-n/work/python/cpython/python] 22.3 ns +- 1.2 ns -> [/home/inada-n/work/python/remove-bytes-hash/python] 108 ns +- 2 ns: 4.84x slower
```


I will reconsider the removal before remove the cache.
We changed code object too often. If Python 3.13 don't use so much bytes objects, we don't need to remove the hash to save some RAM.

----------
Added file: https://bugs.python.org/file50649/remove-bytes-hash.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46864>
_______________________________________

From report at bugs.python.org  Sat Feb 26 21:58:03 2022
From: report at bugs.python.org (Kyle Smith)
Date: Sun, 27 Feb 2022 02:58:03 +0000
Subject: [issue46871] BaseManager.register no longer supports lambda callable
 3.8.12+
Message-ID: <1645930683.9.0.146416539661.issue46871@roundup.psfhosted.org>


New submission from Kyle Smith <kyle.smith at meraki.net>:

The below code works on versions 3.5.2 to 3.8.10. Higher versions tested, such as 3.9.12 and 3.10.2 result in the error:
 "AttributeError: Can't pickle local object".


from multiprocessing import Lock
from multiprocessing.managers import AcquirerProxy, BaseManager, DictProxy

def get_shared_state(host, port, key):
    shared_dict = {}
    shared_lock = Lock()
    manager = BaseManager((host, port), key)
    manager.register("get_dict", lambda: shared_dict, DictProxy)
    manager.register("get_lock", lambda: shared_lock, AcquirerProxy)
    try:
        manager.get_server()
        manager.start()
    except OSError:  # Address already in use
        manager.connect()
    return manager.get_dict(), manager.get_lock()

HOST = "127.0.0.1"
PORT = 35791
KEY = b"secret"
shared_dict, shared_lock = get_shared_state(HOST, PORT, KEY)

shared_dict["number"] = 0
shared_dict["text"] = "Hello World"


This code was pulled from this article: https://stackoverflow.com/questions/57734298/how-can-i-provide-shared-state-to-my-flask-app-with-multiple-workers-without-dep/57810915#57810915


I looked around and couldn't find any open or closed bugs for this, so I'm sorry in advance if this is new expected behavior.

----------
components: Interpreter Core
messages: 414137
nosy: kyle.smith
priority: normal
severity: normal
status: open
title: BaseManager.register no longer supports lambda callable 3.8.12+
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46871>
_______________________________________

From report at bugs.python.org  Sat Feb 26 22:07:19 2022
From: report at bugs.python.org (Tim Peters)
Date: Sun, 27 Feb 2022 03:07:19 +0000
Subject: [issue46868] Improve performance of math.prod with bignums (and
 functools.reduce?)
In-Reply-To: <1645918553.19.0.346410511769.issue46868@roundup.psfhosted.org>
Message-ID: <1645931239.8.0.354042341591.issue46868@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

I don't know that there's a good use case for this. For floating addition, tree-based summation can greatly reduce total roundoff error, but that's not true of floating multiplication.

The advantage for prod(range(2, 50001)) doesn't really stem from turning it into a tree reduction, but instead for that specific input sequence "the tree" happens to do a decent job of keeping multiplicands more-or-less balanced in size (bit length), which eventually allows Karatsuba multiplication to come into play. If CPython didn't implement Karatsuba multiplication, tree reduction wouldn't improve speed: if the inputs are in sequence xs, regardless how school-book multiplication is grouped, or rearranged, the time needed is proportional to

    sum(a * b for a, b in combinations([x.bit_length() for x in xs], 2))

So if the real point is to speed large products of integers, a different approach is wanted: keep track of intermediate products' bit lengths, and at each step strive to multiply partial products near the same length. This will reliably get Karatsuba into play if possible, and caters too to that Karatsuba is most valuable on multiplicands of the same bit length. When any of that happens from blind tree reduction, it's down to luck.

I've seen decent results from doing that with a fixed, small array A, which (very roughly speaking) combines "the next" integer `i` to multiply with the array entry A[i.bit_length().bit_length()] (and continues that with the new partial product, & so on, until hitting an array slot containing 1).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46868>
_______________________________________

From report at bugs.python.org  Sat Feb 26 22:45:24 2022
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 27 Feb 2022 03:45:24 +0000
Subject: [issue46871] BaseManager.register no longer supports lambda callable
 3.8.12+
In-Reply-To: <1645930683.9.0.146416539661.issue46871@roundup.psfhosted.org>
Message-ID: <1645933524.01.0.850759327543.issue46871@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Works for me in Python 3.10.0 on Linux.

After running your code, I get shared_dict is a DictProxy:

>>> shared_dict
<DictProxy object, typeid 'get_dict' at 0x7f092ccd6530>
>>> list(shared_dict.items())
[('number', 0), ('text', 'Hello World')]

and shared_lock an AcquirerProxy object.

Please double-check that the code you posted is the actual code that is failing, and copy and paste the full traceback you receive, not just a one-line summary.

Even if the error is reproducible, I doubt that the cause is what you state in the title of this issue:

BaseManager.register no longer supports lambda callable

Lambdas are just functions, they aren't a different type of callable. So the register method cannot distinguish between a lambda argument written directly in place, and a named def defined earlier then passed by name. So whatever error might be happening on your system, I doubt it has anything to do with the use of lambda syntax

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46871>
_______________________________________

From report at bugs.python.org  Sat Feb 26 23:33:01 2022
From: report at bugs.python.org (Stanley)
Date: Sun, 27 Feb 2022 04:33:01 +0000
Subject: [issue29251] [doc] Class __dict__ is only a mapping proxy
In-Reply-To: <1484222660.7.0.65822313324.issue29251@psf.upfronthosting.co.za>
Message-ID: <1645936381.02.0.855399381343.issue29251@roundup.psfhosted.org>


Stanley <ostanley.lee at gmail.com> added the comment:

>From what I can see, the original patch changed

... and the *dict* dictionary is the namespace containing definitions for class body and is copied to a standard dictionary to become the __dict__ attribute

into this

... and the *dict* dictionary is copied to the namespace containing definitions for the class body, which is referenced by the __dict__ attribute

so that the documentation avoids saying that the attribute is a dictionary, instead saying it just references a dictionary. However, current documentation says that

... it may be copied or wrapped before becoming the __dict__ attribute

which implies some sort of change already. In this case, is the patch for the functions page still applicable?

----------
nosy: +slateny

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29251>
_______________________________________

From report at bugs.python.org  Sun Feb 27 00:47:18 2022
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 27 Feb 2022 05:47:18 +0000
Subject: [issue28824] os.environ should preserve the case of the OS keys ?
In-Reply-To: <1480359346.4.0.287394822331.issue28824@psf.upfronthosting.co.za>
Message-ID: <1645940838.4.0.177709998636.issue28824@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> I think there should be a public class like this.

I wrote a basic implementation of _CaseInsensitiveString under the assumption that it's hidden behind the __getitem__(), __setitem__(), and __delitem__() methods of the _Environ class. I don't want to complicate the implementation.

The problem of case-insensitive names in file/registry paths and environment variables should be addressed with ntpath.normcase(). This should be based on WinAPI LCMapStringEx() with LOCALE_NAME_INVARIANT and LCMAP_UPPERCASE. The current implementation of ntpath.normcase() uses str.lower(), which depends on Python's Unicode database. This possibly differs from what Windows considers to be lower case in the invariant locale. It's also wrong because Windows uses upper case for cases-insensitive comparisons, which matters when sorting names. See bpo-42658.

> Right now, it's not a good workaround because it contains the 
> environment at the time the interpreter was started, not the 
> current environment.

Note that in some cases the "current environment" is the process environment, which isn't necessarily consistent with os.environ on any platform.

In POSIX, posix.environ is created from C environ, which is kept in sync with changes to posix.environ via C putenv() and unsetenv(). However, directly calling os.putenv() or os.unsetenv(), or the underlying C functions, modifies the process environment without changing posix.environ. If subprocess.Popen() is called without overriding env, the child inherits the process environment, not posix.environ.

In Windows, os.environ is created from nt.environ, with variables names converted to upper case. nt.environ is created from C _wenviron, which is created from the process environment, as returned by WinAPI GetEnvironmentStringsW(), except with variable names that begin with "=" filtered out. os.putenv() and os.unsetenv() are based on C _wputenv(), which updates C _wenviron and also updates the process environment via WinAPI SetEnvironmentVariableW(). If either os.putenv() or os.unsetenv() is called directly, or _wputenv() at a lower level, then the variables in C _wenviron (not just the letter case of the names) will be out of sync with os.environ. Additionally, if SetEnvironmentVariableW() is called directly to set or unset a variable, then both os.environ and C _wenviron will be out of sync with the process environment. If subprocess.Popen() is called without overriding env, the child inherits the process environment, not os.environ or C _wenviron.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28824>
_______________________________________

From report at bugs.python.org  Sun Feb 27 01:48:02 2022
From: report at bugs.python.org (Maximilian Hils)
Date: Sun, 27 Feb 2022 06:48:02 +0000
Subject: [issue40124] Clearer assertion error
In-Reply-To: <1585654498.8.0.880221845215.issue40124@roundup.psfhosted.org>
Message-ID: <1645944482.53.0.478462145326.issue40124@roundup.psfhosted.org>


Maximilian Hils <python-bugs at maximilianhils.com> added the comment:

I'm pretty sure this issue is a duplicate of bpo-issue29930.

----------
nosy: +mhils
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40124>
_______________________________________

From report at bugs.python.org  Sun Feb 27 02:29:28 2022
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 27 Feb 2022 07:29:28 +0000
Subject: [issue46869] platform.release() and sys returns wrong version on
 Windows 11
In-Reply-To: <1645920577.85.0.691364066718.issue46869@roundup.psfhosted.org>
Message-ID: <1645946968.67.0.0705048554148.issue46869@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

platform.release() returns platform.uname().release, which comes from platform.win32_ver() in Windows [1]. The issue with Windows 11 is being discussed in bpo-45382, but no PR has been submitted yet to resolve the issue.

> >>> sys.getwindowsversion().platform_version
> (10, 0, 22000)

This result is correct [2], but you should use platform.version() instead. The major.minor version of Windows 11 is 10.0. The build number for Windows 11 is 22000 and above. The latest build number for Windows 10, in contrast, is 19044.

The system version number concerns API compatibility, not user-interface updates or marketing names. Windows XP, XP Professional x64 Edition, Vista, 7, 8, and 8.1 correspond respectively to Windows system versions 5.1, 5.2, 6.0, 6.1, 6.2, and 6.3. System versions 7.x, 8.x, and 9.x were skipped. Version 10.0 is the first system version with two client workstation releases, Windows 10 and Windows 11. It's thus the first time that the build number is required to differentiate the release name.

The `platform_version` attribute of the sys.getwindowsversion() result is supposed to be the true OS version in case the API is using a compatibility-mode version. It's based on the product version of the system file "kernel32.dll". However, it turns out that this is also not reliably the true OS version. The sys documentation was updated with a note that suggests using the platform module instead [3].

---

[1] https://docs.python.org/3/library/platform.html#platform.win32_ver
[2] https://en.wikipedia.org/wiki/Windows_11_version_history#Version_history
[3] https://docs.python.org/3/library/sys.html#sys.getwindowsversion

----------
nosy: +eryksun
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> platform() is not able to detect windows 11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46869>
_______________________________________

From report at bugs.python.org  Sun Feb 27 02:34:00 2022
From: report at bugs.python.org (Stanley)
Date: Sun, 27 Feb 2022 07:34:00 +0000
Subject: [issue20970] [doc] contradictory documentation for prog option of
 argparse
In-Reply-To: <1395160969.17.0.758674872934.issue20970@psf.upfronthosting.co.za>
Message-ID: <1645947240.27.0.658817503916.issue20970@roundup.psfhosted.org>


Change by Stanley <ostanley.lee at gmail.com>:


----------
keywords: +patch
nosy: +slateny
nosy_count: 6.0 -> 7.0
pull_requests: +29725
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31602

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20970>
_______________________________________

From report at bugs.python.org  Sun Feb 27 03:36:09 2022
From: report at bugs.python.org (benrg)
Date: Sun, 27 Feb 2022 08:36:09 +0000
Subject: [issue46868] Improve performance of math.prod with bignums (and
 functools.reduce?)
In-Reply-To: <1645918553.19.0.346410511769.issue46868@roundup.psfhosted.org>
Message-ID: <1645950969.76.0.924703679546.issue46868@roundup.psfhosted.org>


benrg <benrudiak at gmail.com> added the comment:

My example used ints, but I was being deliberately vague when I said "bignums". Balanced-tree reduction certainly isn't optimal for ints, and may not be optimal for anything, but it's pretty good for a lot of things. It's the comparison-based sorting of reduction algorithms.

* When the inputs are of similar sizes, it tends to produce intermediate operands of similar sizes, which helps with Karatsuba multiplication (as you said).

* When the inputs are of different sizes, it limits the "damage" any one of them can do, since they only participate in log2(n) operations each.

* It doesn't look at the values, so it works with third-party types that are unknown to the stdlib.

There's always a fallback case, and balanced reduction is good for that. If there's a faster path for ints that looks at their bit lengths, great.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46868>
_______________________________________

From report at bugs.python.org  Sun Feb 27 03:43:39 2022
From: report at bugs.python.org (Niyas Sait)
Date: Sun, 27 Feb 2022 08:43:39 +0000
Subject: [issue46567] Add Tcl/Tk builds for ARM64
In-Reply-To: <1643388941.84.0.746346851464.issue46567@roundup.psfhosted.org>
Message-ID: <1645951419.22.0.668439668362.issue46567@roundup.psfhosted.org>


Change by Niyas Sait <niyas.sait at linaro.org>:


----------
nosy: +nsait-linaro
nosy_count: 5.0 -> 6.0
pull_requests: +29726
pull_request: https://github.com/python/cpython/pull/31603

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46567>
_______________________________________

From report at bugs.python.org  Sun Feb 27 03:44:39 2022
From: report at bugs.python.org (Ting-Che Lin)
Date: Sun, 27 Feb 2022 08:44:39 +0000
Subject: [issue46799] ShareableList memory bloat and performance improvement
In-Reply-To: <1645272150.7.0.530571625794.issue46799@roundup.psfhosted.org>
Message-ID: <1645951479.36.0.903329240178.issue46799@roundup.psfhosted.org>


Ting-Che Lin <lintingche2012 at gmail.com> added the comment:

So I wrote a patch for this issue and published submitted a MR. When I was working on the patch, I realized that there is another issue related to how string and byte array size alignment is calculated. As seen here: https://github.com/python/cpython/blob/3.10/Lib/multiprocessing/shared_memory.py#L303. 

>>> from multiprocessing.shared_memory import ShareableList
>>> s_list = ShareableList(["12345678"])
>>> s_list.format
'16s'

I changed the calculation of 
self._alignment * (len(item) // self._alignment + 1),
to
self._alignment * max(1, (len(item) - 1) // self._alignment + 1)

With the patch, this will give
>>> from multiprocessing.shared_memory import ShareableList
>>> s_list = ShareableList(["12345678"])
>>> s_list.format
'8s'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46799>
_______________________________________

From report at bugs.python.org  Sun Feb 27 05:43:38 2022
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 27 Feb 2022 10:43:38 +0000
Subject: [issue46849] Memory problems detected using Valgrind
In-Reply-To: <1645711886.58.0.922948546021.issue46849@roundup.psfhosted.org>
Message-ID: <1645958618.53.0.0573787986542.issue46849@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
Removed message: https://bugs.python.org/msg414097

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46849>
_______________________________________

From report at bugs.python.org  Sun Feb 27 05:45:33 2022
From: report at bugs.python.org (aklajnert)
Date: Sun, 27 Feb 2022 10:45:33 +0000
Subject: [issue46806] Overlapping PYTHONPATH may cause import already imported
 module
In-Reply-To: <1645360487.42.0.278270431314.issue46806@roundup.psfhosted.org>
Message-ID: <1645958733.01.0.322427857206.issue46806@roundup.psfhosted.org>


aklajnert <python at aklajnert.pl> added the comment:

Honestly, it seems to me that the documents that you mentioned are discussing different problems, that may be related, but are not the same as the one I've described here.

I'm not arguing - you're clearly more experienced and that's not my area of expertise, but out of curiosity - can you mention some example use cases where the behavior I've described is useful?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46806>
_______________________________________

From report at bugs.python.org  Sun Feb 27 05:50:30 2022
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 27 Feb 2022 10:50:30 +0000
Subject: [issue46849] Memory problems detected using Valgrind
In-Reply-To: <1645711886.58.0.922948546021.issue46849@roundup.psfhosted.org>
Message-ID: <1645959030.78.0.882445193849.issue46849@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Valgrind does not understand Python's custom obmalloc allocator. You have to run valgrind with our suppression rules Misc/valgrind-python.supp to ignore false errors.

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46849>
_______________________________________

From report at bugs.python.org  Sun Feb 27 06:26:00 2022
From: report at bugs.python.org (Dan Snider)
Date: Sun, 27 Feb 2022 11:26:00 +0000
Subject: [issue46872] Odd handling of signal raised if an illegal syscall is
 attempted on Android
Message-ID: <1645961160.27.0.346757629998.issue46872@roundup.psfhosted.org>


New submission from Dan Snider <mr.assume.away at gmail.com>:

On Android, the following calls generate a SIGSYS signal that is neither blocked by pthread_sigmask(SIG_BLOCK, {SIGSYS}) nor ignored after its handler is set to SIG_IGN:

    (os.chroot(path))
    os.setgid(rgid)
    os.setuid(ruid) 
    (os.setegid(gid))
    os.setregid(rgid, egid)
    os.setreuid(ruid, euid)
    os.setresgid(rgid, egid, sgid)
    time.clock_settime(clock, time)
    time.clock_settime_ns(clock, time)
    (socket.sethostname(name))


On the other hand, signal(SIGSYS, lambda s, p: None) will catch the signal, but based on frame it receives (None), I suspect this is a coincidence. Also, the functions with parenthesized names in that list raise the equivalent of OSError(0, "Error", "%s"%args[0]).

----------
components: C API
messages: 414148
nosy: bup
priority: normal
severity: normal
status: open
title: Odd handling of signal raised if an illegal syscall is attempted on Android
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46872>
_______________________________________

From report at bugs.python.org  Sun Feb 27 08:15:29 2022
From: report at bugs.python.org (Adam Hopkins)
Date: Sun, 27 Feb 2022 13:15:29 +0000
Subject: [issue46873] inspect.getsource with some lambdas in decorators does
 not get the full source
Message-ID: <1645967729.03.0.78553115173.issue46873@roundup.psfhosted.org>


New submission from Adam Hopkins <adam at amhopkins.com>:

I believe the following produces an unexpected behavior:

    from inspect import getsource


    def bar(*funcs):
        def decorator(func):
            return func

        return decorator


    @bar(lambda x: bool(True), lambda x: False)
    async def foo():
        ...


    print(getsource(foo))

The output shows only the decorator declaration and none of the function:

    @bar(lambda x: bool(True), lambda x: False)


>From my investigation, it seems like this requires the following conditions to be true:
- lambdas are passed in decorator arguments
- there is more than one lambda
- at least one of the lambdas has a function call

Passing the lambdas as default function arguments seems okay:

    async def foo(bar=[lambda x: bool(True), lambda x: False]):
        ...

A single lambda seems okay:

    @bar(lambda x: bool(True))
    async def foo():
        ...

Lambdas with no function calls also seem okay:

    @bar(lambda x: not x, lambda: True)
    async def foo():
        ...

Tested this on:
- Python 3.10.2
- Python 3.9.9
- Python 3.8.11
- Python 3.7.12

----------
messages: 414149
nosy: ahopkins2
priority: normal
severity: normal
status: open
title: inspect.getsource with some lambdas in decorators does not get the full source
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46873>
_______________________________________

From report at bugs.python.org  Sun Feb 27 08:22:15 2022
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 27 Feb 2022 13:22:15 +0000
Subject: [issue46852] Remove the float.__setformat__() method
In-Reply-To: <1645747677.37.0.919337626983.issue46852@roundup.psfhosted.org>
Message-ID: <1645968135.4.0.961770731779.issue46852@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks, Victor. I think this can be closed now.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46852>
_______________________________________

From report at bugs.python.org  Sun Feb 27 08:40:10 2022
From: report at bugs.python.org (Erlend E. Aasland)
Date: Sun, 27 Feb 2022 13:40:10 +0000
Subject: [issue46874] [sqlite3] optimise user-defined functions
Message-ID: <1645969210.54.0.240452719118.issue46874@roundup.psfhosted.org>


New submission from Erlend E. Aasland <erlend.aasland at innova.no>:

Currently, the `step` method of user-defined functions is looked up using `PyObject_GetAttrString`. Using an interned string and `PyObject_GetAttr`, we can speed up this a little bit.

----------
components: Library (Lib)
messages: 414151
nosy: erlendaasland
priority: normal
severity: normal
status: open
title: [sqlite3] optimise user-defined functions
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46874>
_______________________________________

From report at bugs.python.org  Sun Feb 27 08:40:19 2022
From: report at bugs.python.org (Erlend E. Aasland)
Date: Sun, 27 Feb 2022 13:40:19 +0000
Subject: [issue46874] [sqlite3] optimise user-defined functions
In-Reply-To: <1645969210.54.0.240452719118.issue46874@roundup.psfhosted.org>
Message-ID: <1645969219.57.0.529676984509.issue46874@roundup.psfhosted.org>


Change by Erlend E. Aasland <erlend.aasland at innova.no>:


----------
assignee:  -> erlendaasland

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46874>
_______________________________________

From report at bugs.python.org  Sun Feb 27 08:49:39 2022
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 27 Feb 2022 13:49:39 +0000
Subject: [issue46852] Remove the float.__setformat__() method
In-Reply-To: <1645747677.37.0.919337626983.issue46852@roundup.psfhosted.org>
Message-ID: <1645969779.24.0.599871340198.issue46852@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I reopen the issue for the second part of my plan:

"Once they will be removed, it will become possible to move the detection of the IEEE 754 format in the build step (./configure script) rather than doing the detection at runtime (slower). It would remove an "if" in _PyFloat_Pack4() and _PyFloat_Pack8(), and allow to specialize these functions for the detected format at build time. These functions are used by serialization formats: marshal, pickle and struct."

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46852>
_______________________________________

From report at bugs.python.org  Sun Feb 27 08:51:58 2022
From: report at bugs.python.org (Erlend E. Aasland)
Date: Sun, 27 Feb 2022 13:51:58 +0000
Subject: [issue46874] [sqlite3] optimise user-defined functions
In-Reply-To: <1645969210.54.0.240452719118.issue46874@roundup.psfhosted.org>
Message-ID: <1645969918.56.0.963357051753.issue46874@roundup.psfhosted.org>


Change by Erlend E. Aasland <erlend.aasland at innova.no>:


----------
keywords: +patch
pull_requests: +29727
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31604

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46874>
_______________________________________

From report at bugs.python.org  Sun Feb 27 08:56:09 2022
From: report at bugs.python.org (Kyle Smith)
Date: Sun, 27 Feb 2022 13:56:09 +0000
Subject: [issue46871] BaseManager.register no longer supports lambda callable
 3.8.12+
In-Reply-To: <1645930683.9.0.146416539661.issue46871@roundup.psfhosted.org>
Message-ID: <1645970169.65.0.942120138478.issue46871@roundup.psfhosted.org>


Kyle Smith <kyle.smith at meraki.net> added the comment:

Interesting. I did try between MacOS (12.2) and Ubuntu since I have servers with older python versions. For scoping then, this appears to be related only to MacOS since you were able to confirm it working correctly on Linux. 

The code is the same, but here's the entire traceback. All below examples were run on MacOS:

bash-3.2$ python3 --version
Python 3.9.6
bash-3.2$ python3 main.py
Traceback (most recent call last):
  File "/Volumes/Workspace/co/router/main.py", line 21, in <module>
    shared_dict, shared_lock = get_shared_state(HOST, PORT, KEY)
  File "/Volumes/Workspace/co/router/main.py", line 12, in get_shared_state
    manager.start()
  File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/managers.py", line 553, in start
    self._process.start()
  File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/process.py", line 121, in start
    self._popen = self._Popen(self)
  File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/context.py", line 284, in _Popen
    return Popen(process_obj)
  File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/popen_spawn_posix.py", line 32, in __init__
    super().__init__(process_obj)
  File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/popen_fork.py", line 19, in __init__
    self._launch(process_obj)
  File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/popen_spawn_posix.py", line 47, in _launch
    reduction.dump(process_obj, fp)
  File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/reduction.py", line 60, in dump
    ForkingPickler(file, protocol).dump(obj)
AttributeError: Can't pickle local object 'get_shared_state.<locals>.<lambda>'


Running this with 3.7.9 works:
bash-3.2$ python3.7 --version
Python 3.7.9
bash-3.2$ python3.7 main.py
{'number': 0, 'text': 'Hello World'}


If it's of interest, 3.10.2 is also failing on Mac.

bash-3.2$ /usr/local/opt/python\@3.10/bin/python3 --version
Python 3.10.2
bash-3.2$ /usr/local/opt/python\@3.10/bin/python3 main.py
Traceback (most recent call last):
  File "/Volumes/Workspace/co/router/main.py", line 21, in <module>
    shared_dict, shared_lock = get_shared_state(HOST, PORT, KEY)
  File "/Volumes/Workspace/co/router/main.py", line 12, in get_shared_state
    manager.start()
  File "/usr/local/Cellar/python at 3.10/3.10.2/Frameworks/Python.framework/Versions/3.10/lib/python3.10/multiprocessing/managers.py", line 562, in start
    self._process.start()
  File "/usr/local/Cellar/python at 3.10/3.10.2/Frameworks/Python.framework/Versions/3.10/lib/python3.10/multiprocessing/process.py", line 121, in start
    self._popen = self._Popen(self)
  File "/usr/local/Cellar/python at 3.10/3.10.2/Frameworks/Python.framework/Versions/3.10/lib/python3.10/multiprocessing/context.py", line 284, in _Popen
    return Popen(process_obj)
  File "/usr/local/Cellar/python at 3.10/3.10.2/Frameworks/Python.framework/Versions/3.10/lib/python3.10/multiprocessing/popen_spawn_posix.py", line 32, in __init__
    super().__init__(process_obj)
  File "/usr/local/Cellar/python at 3.10/3.10.2/Frameworks/Python.framework/Versions/3.10/lib/python3.10/multiprocessing/popen_fork.py", line 19, in __init__
    self._launch(process_obj)
  File "/usr/local/Cellar/python at 3.10/3.10.2/Frameworks/Python.framework/Versions/3.10/lib/python3.10/multiprocessing/popen_spawn_posix.py", line 47, in _launch
    reduction.dump(process_obj, fp)
  File "/usr/local/Cellar/python at 3.10/3.10.2/Frameworks/Python.framework/Versions/3.10/lib/python3.10/multiprocessing/reduction.py", line 60, in dump
    ForkingPickler(file, protocol).dump(obj)
AttributeError: Can't pickle local object 'get_shared_state.<locals>.<lambda>'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46871>
_______________________________________

From report at bugs.python.org  Sun Feb 27 09:00:51 2022
From: report at bugs.python.org (Alex Waygood)
Date: Sun, 27 Feb 2022 14:00:51 +0000
Subject: [issue46873] inspect.getsource with some lambdas in decorators does
 not get the full source
In-Reply-To: <1645967729.03.0.78553115173.issue46873@roundup.psfhosted.org>
Message-ID: <1645970451.95.0.452729170139.issue46873@roundup.psfhosted.org>


Alex Waygood <Alex.Waygood at Gmail.com> added the comment:

I'm removing 3.7 and 3.8 from the "versions" field, since they're currently only accepting patches for security-related bugs. But thanks for testing on those versions as well ? that's useful information!

----------
components: +Library (Lib)
nosy: +AlexWaygood, yselivanov
type:  -> behavior
versions:  -Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46873>
_______________________________________

From report at bugs.python.org  Sun Feb 27 09:07:17 2022
From: report at bugs.python.org (Kyle Smith)
Date: Sun, 27 Feb 2022 14:07:17 +0000
Subject: [issue46871] BaseManager.register no longer supports lambda callable
 3.8.12+
In-Reply-To: <1645930683.9.0.146416539661.issue46871@roundup.psfhosted.org>
Message-ID: <1645970837.53.0.401624466723.issue46871@roundup.psfhosted.org>


Kyle Smith <kyle.smith at meraki.net> added the comment:

Since you were able to help me scope that this is probably an MacOS specific issue, I was able to find this report:
https://github.com/pytest-dev/pytest-flask/issues/104

Setting `multiprocessing.set_start_method("fork")` _BEFORE_ the code is called resolves this.

I don't understand enough of MP to understand why this is a problem, and why I need to do this, but alas, at least I have a path forward. 


Since this behavior changed, and it _doesn't_ work cleanly anymore with MacOS, I would say this is a bug (from my casual understanding of python), because it's mentioned in the documentation that using "fork" can be problematic and lead to crashes outlined in bpo-33725.
> Changed in version 3.8: On macOS, the spawn start method is now the default.
> The fork start method should be considered unsafe as it can lead to crashes 
> of the subprocess. See bpo-33725.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46871>
_______________________________________

From report at bugs.python.org  Sun Feb 27 09:15:27 2022
From: report at bugs.python.org (Adam Hopkins)
Date: Sun, 27 Feb 2022 14:15:27 +0000
Subject: [issue46873] inspect.getsource with some lambdas in decorators does
 not get the full source
In-Reply-To: <1645967729.03.0.78553115173.issue46873@roundup.psfhosted.org>
Message-ID: <1645971327.18.0.139249880347.issue46873@roundup.psfhosted.org>


Adam Hopkins <adam at amhopkins.com> added the comment:

Sorry about that. I am doing some more digging to see if I can find the route of it and a proposal for a non-breaking patch. The problem seems to be in BlockFinder.tokeneater.

----------
type: behavior -> 
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46873>
_______________________________________

From report at bugs.python.org  Sun Feb 27 09:21:28 2022
From: report at bugs.python.org (Alex Waygood)
Date: Sun, 27 Feb 2022 14:21:28 +0000
Subject: [issue46873] inspect.getsource with some lambdas in decorators does
 not get the full source
In-Reply-To: <1645967729.03.0.78553115173.issue46873@roundup.psfhosted.org>
Message-ID: <1645971688.13.0.759853073551.issue46873@roundup.psfhosted.org>


Change by Alex Waygood <Alex.Waygood at Gmail.com>:


----------
type:  -> behavior
versions:  -Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46873>
_______________________________________

From report at bugs.python.org  Sun Feb 27 09:26:21 2022
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 27 Feb 2022 14:26:21 +0000
Subject: [issue46786] embed, source, track,
 wbr HTML elements not considered empty
In-Reply-To: <1645179799.58.0.92424391054.issue46786@roundup.psfhosted.org>
Message-ID: <1645971981.18.0.564219382866.issue46786@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:


New changeset 345572a1a0263076081020524016eae867677cac by Jannis Vajen in branch 'main':
bpo-46786: Make ElementTree write the HTML tags embed, source, track, wbr as empty tags (GH-31406)
https://github.com/python/cpython/commit/345572a1a0263076081020524016eae867677cac


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46786>
_______________________________________

From report at bugs.python.org  Sun Feb 27 09:26:44 2022
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 27 Feb 2022 14:26:44 +0000
Subject: [issue46786] embed, source, track,
 wbr HTML elements not considered empty
In-Reply-To: <1645179799.58.0.92424391054.issue46786@roundup.psfhosted.org>
Message-ID: <1645972004.88.0.774673127562.issue46786@roundup.psfhosted.org>


Change by Stefan Behnel <stefan_ml at behnel.de>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46786>
_______________________________________

From report at bugs.python.org  Sun Feb 27 10:11:54 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 27 Feb 2022 15:11:54 +0000
Subject: [issue46849] Memory problems detected using Valgrind
In-Reply-To: <1645711886.58.0.922948546021.issue46849@roundup.psfhosted.org>
Message-ID: <1645974714.92.0.59930465769.issue46849@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy:  -terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46849>
_______________________________________

From report at bugs.python.org  Sun Feb 27 10:30:31 2022
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 27 Feb 2022 15:30:31 +0000
Subject: [issue46852] Remove the float.__setformat__() method
In-Reply-To: <1645747677.37.0.919337626983.issue46852@roundup.psfhosted.org>
Message-ID: <1645975831.31.0.0521351098609.issue46852@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I reopen the issue for the second part of my plan

Hmm. That sounds like it should be a separate issue, or at the least, this issue should be retitled. It's helpful to keep issue titles accurate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46852>
_______________________________________

From report at bugs.python.org  Sun Feb 27 10:51:01 2022
From: report at bugs.python.org (Vidhya)
Date: Sun, 27 Feb 2022 15:51:01 +0000
Subject: [issue21761] [doc] language reference describes the role of
 module.__file__ inaccurately
In-Reply-To: <1402778004.82.0.418404996295.issue21761@psf.upfronthosting.co.za>
Message-ID: <1645977061.27.0.990235652998.issue21761@roundup.psfhosted.org>


Vidhya <vidhya.friend at gmail.com> added the comment:

If this is still open, I would like to work on this. Please let me know.

----------
nosy: +vidhya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21761>
_______________________________________

From report at bugs.python.org  Sun Feb 27 11:29:07 2022
From: report at bugs.python.org (Alex Waygood)
Date: Sun, 27 Feb 2022 16:29:07 +0000
Subject: [issue21761] [doc] language reference describes the role of
 module.__file__ inaccurately
In-Reply-To: <1402778004.82.0.418404996295.issue21761@psf.upfronthosting.co.za>
Message-ID: <1645979347.52.0.283240475748.issue21761@roundup.psfhosted.org>


Alex Waygood <Alex.Waygood at Gmail.com> added the comment:

Hi Vidhya ? @slateny submitted a PR for this issue only two days ago (you can see that it's linked to this BPO issue in the "Pull Requests" field). I think it would be good to wait until that has been reviewed before doing any work on a possible PR for this issue :)

If you'd like to help out with this issue, you'd of course be very welcome to submit a review for @slateny's patch.

----------
nosy: +AlexWaygood

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21761>
_______________________________________

From report at bugs.python.org  Sun Feb 27 11:40:41 2022
From: report at bugs.python.org (Joongi Kim)
Date: Sun, 27 Feb 2022 16:40:41 +0000
Subject: [issue46843] PersistentTaskGroup API
In-Reply-To: <1645680865.21.0.230450894933.issue46843@roundup.psfhosted.org>
Message-ID: <1645980041.04.0.565562712444.issue46843@roundup.psfhosted.org>


Joongi Kim <me at daybreaker.info> added the comment:

I have updated the PersistentTaskGroup implementation referring asyncio.TaskGroup and added more detailed test cases, which works with the latest Python 3.11 GitHub checkout.

https://github.com/achimnol/aiotools/pull/36/files

Please have a look at the class docstring.
There are two different usage: async context manager vs. attributes of long-lived objects.

One of the point is to "revive" asyncio.gather() with return_exceptions=True but let it handle/report exceptions immediately with customizable exception handler.

Currently two-phase shutdown is not implemented yet as I'm still thinking about how to adapt the current implementation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46843>
_______________________________________

From report at bugs.python.org  Sun Feb 27 13:30:02 2022
From: report at bugs.python.org (Joongi Kim)
Date: Sun, 27 Feb 2022 18:30:02 +0000
Subject: [issue46875] Missing name in TaskGroup.__repr__()
Message-ID: <1645986602.91.0.613273361615.issue46875@roundup.psfhosted.org>


New submission from Joongi Kim <me at daybreaker.info>:

The __repr__() method in asyncio.TaskGroup does not include self._name.
I think this is a simple overlook, because asyncio.Task includes the task name in __repr__(). :wink:

https://github.com/python/cpython/blob/345572a1a02/Lib/asyncio/taskgroups.py#L28-L42

I'll make a simple PR to fix it.

----------
components: asyncio
messages: 414162
nosy: achimnol, asvetlov, gvanrossum, yselivanov
priority: normal
severity: normal
status: open
title: Missing name in TaskGroup.__repr__()
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46875>
_______________________________________

From report at bugs.python.org  Sun Feb 27 13:41:28 2022
From: report at bugs.python.org (Joongi Kim)
Date: Sun, 27 Feb 2022 18:41:28 +0000
Subject: [issue46875] Missing name in TaskGroup.__repr__()
In-Reply-To: <1645986602.91.0.613273361615.issue46875@roundup.psfhosted.org>
Message-ID: <1645987288.65.0.70120625022.issue46875@roundup.psfhosted.org>


Joongi Kim <me at daybreaker.info> added the comment:

Ah, I'm confused with aiotools.TaskGroup (originated from EdgeDB's TaskGroup) code while browsing both aiotools and stdlib asyncio.TaskGroup source codes.

The naming facility seems to be intentionally removed when ported to the stdlib.
So I am closing this and sorry fo the noise.

Though, is there any particular reason to remove it?
My guess is that you think that TaskGroup is more like a control-flow structure which does not need to be named, just like we don't name "for loop" for instance.

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46875>
_______________________________________

From report at bugs.python.org  Sun Feb 27 15:25:43 2022
From: report at bugs.python.org (Kyle Smith)
Date: Sun, 27 Feb 2022 20:25:43 +0000
Subject: [issue46871] Lambda can't be pickled with "spawn" and only "fork"
In-Reply-To: <1645930683.9.0.146416539661.issue46871@roundup.psfhosted.org>
Message-ID: <1645993543.27.0.186509179941.issue46871@roundup.psfhosted.org>


Change by Kyle Smith <kyle.smith at meraki.net>:


----------
title: BaseManager.register no longer supports lambda callable 3.8.12+ -> Lambda can't be pickled with "spawn" and only "fork"

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46871>
_______________________________________

From report at bugs.python.org  Sun Feb 27 15:58:48 2022
From: report at bugs.python.org (Adam Hopkins)
Date: Sun, 27 Feb 2022 20:58:48 +0000
Subject: [issue46873] inspect.getsource with some lambdas in decorators does
 not get the full source
In-Reply-To: <1645967729.03.0.78553115173.issue46873@roundup.psfhosted.org>
Message-ID: <1645995528.15.0.225066080708.issue46873@roundup.psfhosted.org>


Change by Adam Hopkins <adam at amhopkins.com>:


----------
keywords: +patch
pull_requests: +29728
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31605

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46873>
_______________________________________

From report at bugs.python.org  Sun Feb 27 16:12:26 2022
From: report at bugs.python.org (Tim Peters)
Date: Sun, 27 Feb 2022 21:12:26 +0000
Subject: [issue46868] Improve performance of math.prod with bignums (and
 functools.reduce?)
In-Reply-To: <1645918553.19.0.346410511769.issue46868@roundup.psfhosted.org>
Message-ID: <1645996346.64.0.609115478894.issue46868@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Hi. "It's pretty good for a lot of things" is precisely what I'm questioning. Name some, and please be specific ;-)

Tree reduction is very popular in the parallel processing world, for obvious reasons. But we're talking about a single thread here, and there aren't all that many associative binary operators (or, depending on implementation, they may need also to be commutative).

I gave floating * as an example: tree reduction buys nothing for accuracy, and would be both slower and consume more memory. Other associative operators for which all the same are true include bitwise &, bitwise |, bitwise ^, min, and max.

Floating + can benefit for accuracy, but we already have math.fsum() for that, which delivers the most accurate possible result.

The only unaddressed example we have here so far that could actually benefit is bigint *. If that's the real use case, fine, but there are better ways to address that case.

I've searched in vain for other languages that try to address this "in general", except in the context of parallelization. As Guido will tell you, the only original idea in Python is adding an "else" clause to loops ;-)

In any case, I don't believe this belongs hiding in reduce(). As above, it's a net loss for most binary operators. Too close to "attractive nuisance" territory. Adding a new, e.g., treereduce() would be better - provided that it is in fact "pretty good for a lot of things".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46868>
_______________________________________

From report at bugs.python.org  Sun Feb 27 16:42:22 2022
From: report at bugs.python.org (Erlend E. Aasland)
Date: Sun, 27 Feb 2022 21:42:22 +0000
Subject: [issue46748] Python.h includes stdbool.h
In-Reply-To: <1644830899.62.0.590844926135.issue46748@roundup.psfhosted.org>
Message-ID: <1645998142.77.0.29496466734.issue46748@roundup.psfhosted.org>


Erlend E. Aasland <erlend.aasland at innova.no> added the comment:

Can we close this?

----------
nosy: +erlendaasland
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46748>
_______________________________________

From report at bugs.python.org  Sun Feb 27 17:30:48 2022
From: report at bugs.python.org (Sanchayan Ghosh)
Date: Sun, 27 Feb 2022 22:30:48 +0000
Subject: [issue36484] Can't reorder TLS 1.3 ciphersuites
In-Reply-To: <1553945035.34.0.303610202958.issue36484@roundup.psfhosted.org>
Message-ID: <1646001048.87.0.865524235059.issue36484@roundup.psfhosted.org>


Sanchayan Ghosh <sanchayanghosh at outlook.com> added the comment:

I have written a function that will allow us to reorder TLS v1.3. Since I have tried to keep a 1-1 binding, you will have to first remove the cipher suites entirely by giving a blank string, and then add TLS v1.2 and v1.3 cipher suites.

----------
keywords: +patch
nosy: +sanchayanghosh
Added file: https://bugs.python.org/file50650/0001-Add-TLS-v1.3-cipher-suite-set-function.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36484>
_______________________________________

From report at bugs.python.org  Sun Feb 27 17:47:48 2022
From: report at bugs.python.org (Sanchayan Ghosh)
Date: Sun, 27 Feb 2022 22:47:48 +0000
Subject: [issue36484] Can't reorder TLS 1.3 ciphersuites
In-Reply-To: <1553945035.34.0.303610202958.issue36484@roundup.psfhosted.org>
Message-ID: <1646002068.45.0.0514592059114.issue36484@roundup.psfhosted.org>


Sanchayan Ghosh <sanchayanghosh at outlook.com> added the comment:

Here is the PR as well. While I agree that there is no more a reason to reorder cipher suites and that we should use our certificates to basically ensure a secure connection, the advantage of the OpenSSL API is it provides us the function to influence the selection of cipher suites.

So, as a first step, I have added the binding for selecting TLS v1.3 cipher suites. And in 2 other pull requests, I will provide the API implementation for the other, for users who may just want a way to access OpenSSL through Python.

----------
message_count: 4.0 -> 5.0
pull_requests: +29730
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31607

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36484>
_______________________________________

From report at bugs.python.org  Sun Feb 27 19:01:24 2022
From: report at bugs.python.org (Mohammad Mahdi Zojaji Monfared)
Date: Mon, 28 Feb 2022 00:01:24 +0000
Subject: [issue46876] Walrus operator not in help
Message-ID: <1646006484.73.0.147239709954.issue46876@roundup.psfhosted.org>


New submission from Mohammad Mahdi Zojaji Monfared <mmahdizojajim at gmail.com>:

Walrus oprator := not in help("symbols")
and help(":=") does not work.

----------
components: Interpreter Core
files: walrus.png
messages: 414168
nosy: mmahdizojajim
priority: normal
severity: normal
status: open
title: Walrus operator not in help
type: behavior
versions: Python 3.10
Added file: https://bugs.python.org/file50651/walrus.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46876>
_______________________________________

From report at bugs.python.org  Sun Feb 27 19:18:49 2022
From: report at bugs.python.org (Adrian Garcia Badaracco)
Date: Mon, 28 Feb 2022 00:18:49 +0000
Subject: [issue44807] typing.Protocol silently overrides __init__ method of
 delivered class
In-Reply-To: <1627898026.7.0.991897199639.issue44807@roundup.psfhosted.org>
Message-ID: <1646007529.98.0.00803339215344.issue44807@roundup.psfhosted.org>


Adrian Garcia Badaracco <adrian at adriangb.com> added the comment:

While this is figured out, would it be possible to remove the silent overriding? This seems like something type checkers should be doing, not silent runtime modification of classes. Pyright already (correctly) checks this, so I think it would just need to be added to MyPy.

>>> class C(Protocol):
...   def __init__(self) -> None:
...     print('init!')
...
>>> c = C()  # Pyright error, MyPy says it's okay

I came across this while trying to create a class that requires concrete subclasses to define a specific field, and it seems like Protocol is the only thing that can pull this off because of how type checkers special case it: https://gist.github.com/adriangb/6c1a001ee7035bad5bd56df70e0cf5e6

I don't particularly like this use of Protocol, but it works (aside from the overriding issue).

I don't know if this usage of implementing `__init__` on a protocol class should be valid or not, but I do think it's interesting that `__init__` is never called on the protocol class itself, even if the protocol class is the one defining it. It is only called on `MyAPIKey`, which is a concrete class that happens to inherit the implementation from a protocol class. So maybe that should be valid? I'm not sure.

But I do know that making type checkers enforce this instead runtime would allow this use case to work while still prohibiting the (in my opinion invalid) use case of calling `__init__` on the protocol class itself.

----------
nosy: +adriangb
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44807>
_______________________________________

From report at bugs.python.org  Sun Feb 27 20:51:26 2022
From: report at bugs.python.org (Andrei Kulakov)
Date: Mon, 28 Feb 2022 01:51:26 +0000
Subject: [issue45326] Unexpected TypeError with type alias+issubclass+ABC
In-Reply-To: <1632950049.79.0.711339156878.issue45326@roundup.psfhosted.org>
Message-ID: <1646013086.33.0.288995930159.issue45326@roundup.psfhosted.org>


Andrei Kulakov <andrei.avk at gmail.com> added the comment:

This error was added in https://bugs.python.org/issue33018 . See some discussion on that issue.

Note that first arg needs to be a type (i.e. instance of `type`) to avoid this error:

[ins] In [41]: class C(ABC):0

[ins] In [42]: issubclass(dict, C)
Out[42]: False

[ins] In [43]: issubclass('', C)  # TypeError: issubclass() arg 1 must be a class

[ins] In [44]: issubclass(typing.Dict, C)   # same error as above

----------
nosy: +andrei.avk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45326>
_______________________________________

From report at bugs.python.org  Sun Feb 27 20:52:34 2022
From: report at bugs.python.org (Andrei Kulakov)
Date: Mon, 28 Feb 2022 01:52:34 +0000
Subject: [issue45326] Unexpected TypeError with type alias+issubclass+ABC
In-Reply-To: <1632950049.79.0.711339156878.issue45326@roundup.psfhosted.org>
Message-ID: <1646013154.63.0.420385794249.issue45326@roundup.psfhosted.org>


Change by Andrei Kulakov <andrei.avk at gmail.com>:


----------
nosy: +kj
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45326>
_______________________________________

From report at bugs.python.org  Sun Feb 27 21:02:25 2022
From: report at bugs.python.org (Karan)
Date: Mon, 28 Feb 2022 02:02:25 +0000
Subject: [issue46870] Improper Input Validation in urlparse
In-Reply-To: <1645924323.46.0.342217272005.issue46870@roundup.psfhosted.org>
Message-ID: <1646013745.87.0.149081517321.issue46870@roundup.psfhosted.org>


Karan <fghjklp at gmail.com> added the comment:

Here are the results from other languages. Go parses incorrectly at the same time rust does it correctly.

Go- https://go.dev/play/p/nNMhyznuGpn
&url.URL{Scheme:"http", Opaque:"@localhost", User:(*url.Userinfo)(nil), Host:"", Path:"", RawPath:"", ForceQuery:false, RawQuery:"", Fragment:"", RawFragment:""}


Rust- https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=92681b56f7cbd62b7735c962a2f5321e
Url { scheme: "http", cannot_be_a_base: false, username: "", password: None, host: Some(Domain("localhost")), port: None, path: "/", query: None, fragment: None }

----------
nosy: +karanchaudhary

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46870>
_______________________________________

From report at bugs.python.org  Sun Feb 27 21:06:42 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Mon, 28 Feb 2022 02:06:42 +0000
Subject: [issue44807] typing.Protocol silently overrides __init__ method of
 delivered class
In-Reply-To: <1627898026.7.0.991897199639.issue44807@roundup.psfhosted.org>
Message-ID: <1646014002.24.0.12383975231.issue44807@roundup.psfhosted.org>


Change by Jelle Zijlstra <jelle.zijlstra at gmail.com>:


----------
nosy: +Jelle Zijlstra

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44807>
_______________________________________

From report at bugs.python.org  Sun Feb 27 21:08:32 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 28 Feb 2022 02:08:32 +0000
Subject: [issue46541] Replace _Py_IDENTIFIER() with statically initialized
 objects.
In-Reply-To: <1643234464.46.0.949364478641.issue46541@roundup.psfhosted.org>
Message-ID: <1646014112.18.0.0995213967757.issue46541@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
pull_requests: +29731
pull_request: https://github.com/python/cpython/pull/31608

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46541>
_______________________________________

From report at bugs.python.org  Sun Feb 27 23:48:21 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 28 Feb 2022 04:48:21 +0000
Subject: [issue44807] typing.Protocol silently overrides __init__ method of
 delivered class
In-Reply-To: <1627898026.7.0.991897199639.issue44807@roundup.psfhosted.org>
Message-ID: <1646023701.91.0.982360344881.issue44807@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

If the problem is in mypy, it should be filed in the mypy tracker, not here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44807>
_______________________________________

From report at bugs.python.org  Mon Feb 28 00:04:06 2022
From: report at bugs.python.org (Adrian Garcia Badaracco)
Date: Mon, 28 Feb 2022 05:04:06 +0000
Subject: [issue44807] typing.Protocol silently overrides __init__ method of
 delivered class
In-Reply-To: <1627898026.7.0.991897199639.issue44807@roundup.psfhosted.org>
Message-ID: <1646024646.77.0.552514421905.issue44807@roundup.psfhosted.org>


Adrian Garcia Badaracco <adrian at adriangb.com> added the comment:

Apologies if that was noise, I filed an issue on the MyPy issue tracker: https://github.com/python/mypy/issues/12261

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44807>
_______________________________________

From report at bugs.python.org  Mon Feb 28 00:55:53 2022
From: report at bugs.python.org (Adam Hopkins)
Date: Mon, 28 Feb 2022 05:55:53 +0000
Subject: [issue46873] inspect.getsource with some lambdas in decorators does
 not get the full source
In-Reply-To: <1645967729.03.0.78553115173.issue46873@roundup.psfhosted.org>
Message-ID: <1646027753.46.0.212254206643.issue46873@roundup.psfhosted.org>


Adam Hopkins <adam at amhopkins.com> added the comment:

Duplicate of https://bugs.python.org/issue38854

Sorry I didn't come across our before submitting.

----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46873>
_______________________________________

From report at bugs.python.org  Mon Feb 28 01:07:59 2022
From: report at bugs.python.org (Ofey Chan)
Date: Mon, 28 Feb 2022 06:07:59 +0000
Subject: [issue46761] functools.update_wrapper breaks the signature of
 functools.partial objects
In-Reply-To: <1644948374.87.0.765462873315.issue46761@roundup.psfhosted.org>
Message-ID: <1646028479.41.0.494798372965.issue46761@roundup.psfhosted.org>


Ofey Chan <ofey206 at gmail.com> added the comment:

> Maybe we can loop in someone who works on a popular runtime function introspection library (FastAPI, Pydantic) to see if they have any take on it.

I've checked issues of FastAPI and Pydantic. There is only one issue about `update_wrapper()`, and it's about documentation generation:

https://github.com/samuelcolvin/pydantic/issues/1032

Would it be proper to open an issue under FastAPI and Pydantic, to describe the situation, and collect their feedbacks?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46761>
_______________________________________

From report at bugs.python.org  Mon Feb 28 01:21:48 2022
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 28 Feb 2022 06:21:48 +0000
Subject: [issue46761] functools.update_wrapper breaks the signature of
 functools.partial objects
In-Reply-To: <1644948374.87.0.765462873315.issue46761@roundup.psfhosted.org>
Message-ID: <1646029308.01.0.649684331422.issue46761@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

I emailed the Pydantic and FastAPI guys and didn't hear back.  Given what you found on their issue trackers, I think it's unlikely that they care a lot about this issue (but were too busy to reply).  It's far more likely that they don't care.

Doing a little research (git blame), it looks like the "follow the wrapped chain to find the original signature" work was done by Nick Coghlan about nine years ago; he touched both functools.update_wrapper and the inspect module.

The only other people to touch the code recently are Yuri and Batuhan.  I've nosied Nick and Batuhan (already looped in Yuri), just to ping them and see if they have any strong opinions.

If nobody has anything remarkable to say about it, honestly we probably *can* just merge your patch, Ofey.  I see your name is now marked with a star; are you now authorized to contribute to CPython?

(Note that I only glanced at your patch so far; if we were going to merge this bugfix I would of course first do a full review.)

----------
nosy: +BTaskaya, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46761>
_______________________________________

From report at bugs.python.org  Mon Feb 28 01:41:43 2022
From: report at bugs.python.org (Martin Fischer)
Date: Mon, 28 Feb 2022 06:41:43 +0000
Subject: [issue46877] unittest.doModuleCleanups() does not exist
Message-ID: <1646030503.89.0.975314565573.issue46877@roundup.psfhosted.org>


New submission from Martin Fischer <martin at push-f.com>:

The unittest documentation[1] describes unittest.doModuleCleanups().

That function however doesn't exist since it's only in the unittest.case module and not re-exported in the unittest module (unlike addModuleCleanup).

So I think either the documentation should be corrected or doModuleCleanups should be re-exported in unittest/__init__.py to match the documentation.

[1]: https://docs.python.org/3.8/library/unittest.html

----------
assignee: docs at python
components: Documentation
messages: 414177
nosy: docs at python, lisroach, michael.foord, push-f
priority: normal
severity: normal
status: open
title: unittest.doModuleCleanups() does not exist
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46877>
_______________________________________

From report at bugs.python.org  Mon Feb 28 02:07:26 2022
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 28 Feb 2022 07:07:26 +0000
Subject: [issue46541] Replace _Py_IDENTIFIER() with statically initialized
 objects.
In-Reply-To: <1643234464.46.0.949364478641.issue46541@roundup.psfhosted.org>
Message-ID: <1646032046.04.0.186198840103.issue46541@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset 088dd76dba68c2538776d9920607f81e54544cbd by Dong-hee Na in branch 'main':
bpo-46541: Remove unnecessary Py_VISIT (GH-31608)
https://github.com/python/cpython/commit/088dd76dba68c2538776d9920607f81e54544cbd


----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46541>
_______________________________________

From report at bugs.python.org  Mon Feb 28 02:19:18 2022
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 28 Feb 2022 07:19:18 +0000
Subject: [issue46877] unittest.doModuleCleanups() does not exist
In-Reply-To: <1646030503.89.0.975314565573.issue46877@roundup.psfhosted.org>
Message-ID: <1646032758.25.0.916315701669.issue46877@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/issue46877>
_______________________________________

From report at bugs.python.org  Mon Feb 28 02:19:59 2022
From: report at bugs.python.org (Niyas Sait)
Date: Mon, 28 Feb 2022 07:19:59 +0000
Subject: [issue46567] Add Tcl/Tk builds for ARM64
In-Reply-To: <1643388941.84.0.746346851464.issue46567@roundup.psfhosted.org>
Message-ID: <1646032799.72.0.942245670191.issue46567@roundup.psfhosted.org>


Niyas Sait <niyas.sait at linaro.org> added the comment:

Based on my investigation so far, I think Tcl/Tk package generated with VS 2022 seems to have some issues when used with Tkinter. I could be wrong.

I've created https://github.com/python/cpython/pull/31603 to force the Tcl/Tk package build on the fly with VS 2019 and I can see it is passing all tests.

If my analysis is correct, I think it would be better to rebuild Tcl/Tk with VS 2019 for cpython-bin-deps while we investigate the issue with the compiler.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46567>
_______________________________________

From report at bugs.python.org  Mon Feb 28 02:39:46 2022
From: report at bugs.python.org (Stanley)
Date: Mon, 28 Feb 2022 07:39:46 +0000
Subject: [issue25743] [doc] Clarify exactly what \w matches in UNICODE mode
In-Reply-To: <1448639458.78.0.12264064003.issue25743@psf.upfronthosting.co.za>
Message-ID: <1646033986.54.0.931352718696.issue25743@roundup.psfhosted.org>


Stanley <ostanley.lee at gmail.com> added the comment:

Would a change like this be accurate?

Matches Unicode word characters; this includes most alphanumeric characters as well as the underscore. In Unicode, alphanumeric characters are defined to be the general categories L + N (see https://unicode.org/reports/tr44/#General_Category_Values). If the :const:`ASCII` flag is used, only ``[a-zA-Z0-9_]`` is matched.

----------
nosy: +slateny

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25743>
_______________________________________

From report at bugs.python.org  Mon Feb 28 02:48:58 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Mon, 28 Feb 2022 07:48:58 +0000
Subject: [issue30698] asyncio sslproto do not shutdown ssl layer cleanly
In-Reply-To: <1497823715.09.0.154341862456.issue30698@psf.upfronthosting.co.za>
Message-ID: <1646034538.11.0.137118950514.issue30698@roundup.psfhosted.org>


Kumar Aditya <rahuladitya303 at gmail.com> added the comment:

Since https://bugs.python.org/issue44011 is fixed now, this can be closed.
@asvetlov

----------
nosy: +kumaraditya303
versions: +Python 3.11 -Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30698>
_______________________________________

From report at bugs.python.org  Mon Feb 28 03:17:54 2022
From: report at bugs.python.org (Erlend E. Aasland)
Date: Mon, 28 Feb 2022 08:17:54 +0000
Subject: [issue46541] Replace _Py_IDENTIFIER() with statically initialized
 objects.
In-Reply-To: <1643234464.46.0.949364478641.issue46541@roundup.psfhosted.org>
Message-ID: <1646036274.98.0.678370582193.issue46541@roundup.psfhosted.org>


Change by Erlend E. Aasland <erlend.aasland at innova.no>:


----------
pull_requests: +29732
pull_request: https://github.com/python/cpython/pull/31609

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46541>
_______________________________________

From report at bugs.python.org  Mon Feb 28 03:18:42 2022
From: report at bugs.python.org (Sanchayan Ghosh)
Date: Mon, 28 Feb 2022 08:18:42 +0000
Subject: [issue36484] Can't reorder TLS 1.3 ciphersuites
In-Reply-To: <1553945035.34.0.303610202958.issue36484@roundup.psfhosted.org>
Message-ID: <1646036322.29.0.835493133846.issue36484@roundup.psfhosted.org>


Change by Sanchayan Ghosh <sanchayanghosh at outlook.com>:


Removed file: https://bugs.python.org/file50650/0001-Add-TLS-v1.3-cipher-suite-set-function.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36484>
_______________________________________

From report at bugs.python.org  Mon Feb 28 03:19:24 2022
From: report at bugs.python.org (Sanchayan Ghosh)
Date: Mon, 28 Feb 2022 08:19:24 +0000
Subject: [issue36484] Can't reorder TLS 1.3 ciphersuites
In-Reply-To: <1553945035.34.0.303610202958.issue36484@roundup.psfhosted.org>
Message-ID: <1646036364.68.0.961117873204.issue36484@roundup.psfhosted.org>


Change by Sanchayan Ghosh <sanchayanghosh at outlook.com>:


Added file: https://bugs.python.org/file50652/0001-Add-TLS-v1.3-cipher-suite-set-function.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36484>
_______________________________________

From report at bugs.python.org  Mon Feb 28 03:40:18 2022
From: report at bugs.python.org (Stanley)
Date: Mon, 28 Feb 2022 08:40:18 +0000
Subject: [issue23453] [doc] Clarify bytes vs text with non-seeking tarfile
 stream
In-Reply-To: <1423739998.49.0.706967373594.issue23453@psf.upfronthosting.co.za>
Message-ID: <1646037618.69.0.527391748225.issue23453@roundup.psfhosted.org>


Change by Stanley <ostanley.lee at gmail.com>:


----------
keywords: +patch
nosy: +slateny
nosy_count: 3.0 -> 4.0
pull_requests: +29733
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31610

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23453>
_______________________________________

From report at bugs.python.org  Mon Feb 28 03:52:28 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Mon, 28 Feb 2022 08:52:28 +0000
Subject: [issue43884] Cannot cleanly kill a subprocess using high-level
 asyncio APIs
In-Reply-To: <1618800458.29.0.766698985684.issue43884@roundup.psfhosted.org>
Message-ID: <1646038348.77.0.811637073756.issue43884@roundup.psfhosted.org>


Change by Kumar Aditya <rahuladitya303 at gmail.com>:


----------
versions: +Python 3.11 -Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43884>
_______________________________________

From report at bugs.python.org  Mon Feb 28 03:52:48 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Mon, 28 Feb 2022 08:52:48 +0000
Subject: [issue43884] Cannot cleanly kill a subprocess using high-level
 asyncio APIs
In-Reply-To: <1618800458.29.0.766698985684.issue43884@roundup.psfhosted.org>
Message-ID: <1646038368.35.0.408005090076.issue43884@roundup.psfhosted.org>


Change by Kumar Aditya <rahuladitya303 at gmail.com>:


----------
keywords: +patch
nosy: +kumaraditya303
nosy_count: 5.0 -> 6.0
pull_requests: +29734
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31611

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43884>
_______________________________________

From report at bugs.python.org  Mon Feb 28 04:07:44 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 28 Feb 2022 09:07:44 +0000
Subject: [issue46541] Replace _Py_IDENTIFIER() with statically initialized
 objects.
In-Reply-To: <1643234464.46.0.949364478641.issue46541@roundup.psfhosted.org>
Message-ID: <1646039264.28.0.840456086839.issue46541@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:


New changeset c32aef48533769161e1247927a5b418322e0860c by Erlend Egeberg Aasland in branch 'main':
bpo-46541: Remove unneeded visits from sqlite3 (GH-31609)
https://github.com/python/cpython/commit/c32aef48533769161e1247927a5b418322e0860c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46541>
_______________________________________

From report at bugs.python.org  Mon Feb 28 04:48:40 2022
From: report at bugs.python.org (Petr Viktorin)
Date: Mon, 28 Feb 2022 09:48:40 +0000
Subject: [issue46748] Python.h includes stdbool.h
In-Reply-To: <1644830899.62.0.590844926135.issue46748@roundup.psfhosted.org>
Message-ID: <1646041720.97.0.526533845961.issue46748@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

Thank you, Kumar & Victor, for fixing up the issue!

I meant to check the buildbots before closing the issue, but got side-tracked.

----------
stage: patch review -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46748>
_______________________________________

From report at bugs.python.org  Mon Feb 28 04:57:37 2022
From: report at bugs.python.org (Steve Dower)
Date: Mon, 28 Feb 2022 09:57:37 +0000
Subject: [issue46567] Add Tcl/Tk builds for ARM64
In-Reply-To: <1643388941.84.0.746346851464.issue46567@roundup.psfhosted.org>
Message-ID: <1646042257.46.0.384520440379.issue46567@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Thanks for the analysis. It should be fine to set PlatformToolset=v142 to choose the older compiler, so I'll give that a go.

Anything I can do to help the compiler team figure out what's broken?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46567>
_______________________________________

From report at bugs.python.org  Mon Feb 28 05:18:24 2022
From: report at bugs.python.org (Steve Dower)
Date: Mon, 28 Feb 2022 10:18:24 +0000
Subject: [issue46567] Add Tcl/Tk builds for ARM64
In-Reply-To: <1643388941.84.0.746346851464.issue46567@roundup.psfhosted.org>
Message-ID: <1646043504.16.0.153573875354.issue46567@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I updated the builds in cpython-bin-deps and retriggered the PR tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46567>
_______________________________________

From report at bugs.python.org  Mon Feb 28 05:42:23 2022
From: report at bugs.python.org (Martin Fischer)
Date: Mon, 28 Feb 2022 10:42:23 +0000
Subject: [issue46877] [doc] unittest.doModuleCleanups() does not exist
In-Reply-To: <1646030503.89.0.975314565573.issue46877@roundup.psfhosted.org>
Message-ID: <1646044943.06.0.336405843872.issue46877@roundup.psfhosted.org>


Change by Martin Fischer <martin at push-f.com>:


----------
title: unittest.doModuleCleanups() does not exist -> [doc] unittest.doModuleCleanups() does not exist

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46877>
_______________________________________

From report at bugs.python.org  Mon Feb 28 05:50:28 2022
From: report at bugs.python.org (Erlend E. Aasland)
Date: Mon, 28 Feb 2022 10:50:28 +0000
Subject: [issue46878] [sqlite3] remove "non-standard" from docstrings
Message-ID: <1646045428.22.0.0724822171916.issue46878@roundup.psfhosted.org>


New submission from Erlend E. Aasland <erlend.aasland at innova.no>:

Several sqlite3 methods are "marked" as non-standard in their docstrings. This is an historic artefact which (I assume) implies that a method is not a part of the DB-API defined by PEP 249. Questions regarding the "non-standard" strings arise from time to time, as the meaning is not immediately obvious.

The question surfaced in a code review in October 2021[^1], and again in a more recent PR[^2].

Suggesting to purge "non-standard" from all docstrings once and for all to avoid more confusion.

[^1]: https://github.com/python/cpython/pull/28463#discussion_r724371832
[^2]: https://github.com/python/cpython/pull/26728#discussion_r815523101

----------
messages: 414186
nosy: Jelle Zijlstra, erlendaasland
priority: normal
severity: normal
status: open
title: [sqlite3] remove "non-standard" from docstrings
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46878>
_______________________________________

From report at bugs.python.org  Mon Feb 28 05:53:44 2022
From: report at bugs.python.org (Erlend E. Aasland)
Date: Mon, 28 Feb 2022 10:53:44 +0000
Subject: [issue46878] [sqlite3] remove "non-standard" from docstrings
In-Reply-To: <1646045428.22.0.0724822171916.issue46878@roundup.psfhosted.org>
Message-ID: <1646045624.79.0.570805229606.issue46878@roundup.psfhosted.org>


Change by Erlend E. Aasland <erlend.aasland at innova.no>:


----------
keywords: +patch
pull_requests: +29735
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31612

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46878>
_______________________________________

From report at bugs.python.org  Mon Feb 28 06:07:22 2022
From: report at bugs.python.org (Adam Hopkins)
Date: Mon, 28 Feb 2022 11:07:22 +0000
Subject: [issue38854] Decorator with paren tokens in arguments breaks
 inspect.getsource
In-Reply-To: <1574199462.47.0.0804409972746.issue38854@roundup.psfhosted.org>
Message-ID: <1646046442.91.0.454659755395.issue38854@roundup.psfhosted.org>


Change by Adam Hopkins <adam at amhopkins.com>:


----------
nosy: +ahopkins
nosy_count: 3.0 -> 4.0
pull_requests: +29736
pull_request: https://github.com/python/cpython/pull/31605

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38854>
_______________________________________

From report at bugs.python.org  Mon Feb 28 06:07:50 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Mon, 28 Feb 2022 11:07:50 +0000
Subject: [issue46877] [doc] unittest.doModuleCleanups() does not exist
In-Reply-To: <1646030503.89.0.975314565573.issue46877@roundup.psfhosted.org>
Message-ID: <1646046470.36.0.405396362357.issue46877@roundup.psfhosted.org>


Change by Kumar Aditya <rahuladitya303 at gmail.com>:


----------
nosy: +kumaraditya303

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46877>
_______________________________________

From report at bugs.python.org  Mon Feb 28 06:08:40 2022
From: report at bugs.python.org (Alex Waygood)
Date: Mon, 28 Feb 2022 11:08:40 +0000
Subject: [issue38854] Decorator with paren tokens in arguments breaks
 inspect.getsource
In-Reply-To: <1574199462.47.0.0804409972746.issue38854@roundup.psfhosted.org>
Message-ID: <1646046520.72.0.2432824071.issue38854@roundup.psfhosted.org>


Change by Alex Waygood <Alex.Waygood at Gmail.com>:


----------
nosy: +yselivanov
versions:  -Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38854>
_______________________________________

From report at bugs.python.org  Mon Feb 28 06:08:51 2022
From: report at bugs.python.org (Alex Waygood)
Date: Mon, 28 Feb 2022 11:08:51 +0000
Subject: [issue38854] Decorator with paren tokens in arguments breaks
 inspect.getsource
In-Reply-To: <1574199462.47.0.0804409972746.issue38854@roundup.psfhosted.org>
Message-ID: <1646046531.18.0.453897562214.issue38854@roundup.psfhosted.org>


Change by Alex Waygood <Alex.Waygood at Gmail.com>:


----------
nosy: +AlexWaygood

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38854>
_______________________________________

From report at bugs.python.org  Mon Feb 28 06:10:31 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Mon, 28 Feb 2022 11:10:31 +0000
Subject: [issue46877] [doc] unittest.doModuleCleanups() does not exist
In-Reply-To: <1646030503.89.0.975314565573.issue46877@roundup.psfhosted.org>
Message-ID: <1646046631.72.0.114008830472.issue46877@roundup.psfhosted.org>


Change by Kumar Aditya <rahuladitya303 at gmail.com>:


----------
keywords: +patch
pull_requests: +29737
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31611

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46877>
_______________________________________

From report at bugs.python.org  Mon Feb 28 06:12:19 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Mon, 28 Feb 2022 11:12:19 +0000
Subject: [issue46877] [doc] unittest.doModuleCleanups() does not exist
In-Reply-To: <1646030503.89.0.975314565573.issue46877@roundup.psfhosted.org>
Message-ID: <1646046739.58.0.93325616029.issue46877@roundup.psfhosted.org>


Change by Kumar Aditya <rahuladitya303 at gmail.com>:


----------
pull_requests: +29738
pull_request: https://github.com/python/cpython/pull/31613

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46877>
_______________________________________

From report at bugs.python.org  Mon Feb 28 06:36:37 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 28 Feb 2022 11:36:37 +0000
Subject: [issue30698] asyncio sslproto do not shutdown ssl layer cleanly
In-Reply-To: <1497823715.09.0.154341862456.issue30698@psf.upfronthosting.co.za>
Message-ID: <1646048197.28.0.402423756662.issue30698@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Agree

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30698>
_______________________________________

From report at bugs.python.org  Mon Feb 28 06:54:26 2022
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 28 Feb 2022 11:54:26 +0000
Subject: [issue46841] Inline bytecode caches
In-Reply-To: <1645669034.5.0.77775951626.issue46841@roundup.psfhosted.org>
Message-ID: <1646049266.52.0.747797215978.issue46841@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset 424ecab494d538650ba34937cdd710094ccb2275 by Brandt Bucher in branch 'main':
bpo-46841: Use inline caching for `UNPACK_SEQUENCE` (GH-31591)
https://github.com/python/cpython/commit/424ecab494d538650ba34937cdd710094ccb2275


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46841>
_______________________________________

From report at bugs.python.org  Mon Feb 28 07:06:47 2022
From: report at bugs.python.org (Steve Dower)
Date: Mon, 28 Feb 2022 12:06:47 +0000
Subject: [issue46567] Add Tcl/Tk builds for ARM64
In-Reply-To: <1643388941.84.0.746346851464.issue46567@roundup.psfhosted.org>
Message-ID: <1646050007.94.0.759438166811.issue46567@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset da7d99a4de72aac8d436cecedf16ab2676f9b785 by Steve Dower in branch 'main':
bpo-46567: Add Tcl/Tk build for Windows ARM64 (GH-31574)
https://github.com/python/cpython/commit/da7d99a4de72aac8d436cecedf16ab2676f9b785


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46567>
_______________________________________

From report at bugs.python.org  Mon Feb 28 07:07:40 2022
From: report at bugs.python.org (Steve Dower)
Date: Mon, 28 Feb 2022 12:07:40 +0000
Subject: [issue46567] Add Tcl/Tk builds for ARM64
In-Reply-To: <1643388941.84.0.746346851464.issue46567@roundup.psfhosted.org>
Message-ID: <1646050060.05.0.907077253854.issue46567@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Build and tests were fine, and a test release build was too, so merging and closing this.

Any new Tcl/Tk issues should get a new bug. If they only affect ARM64, just mention that in the issue.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46567>
_______________________________________

From report at bugs.python.org  Mon Feb 28 07:28:14 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 28 Feb 2022 12:28:14 +0000
Subject: [issue46672] NameError in asyncio.gather when passing a invalid type
 as an arg with multiple awaitables
In-Reply-To: <1644211485.82.0.488303396987.issue46672@roundup.psfhosted.org>
Message-ID: <1646051294.59.0.796207687117.issue46672@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Correct. 
3.8 is in security mode.
It doesn't accept regular patches

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46672>
_______________________________________

From report at bugs.python.org  Mon Feb 28 07:47:50 2022
From: report at bugs.python.org (Martin Fischer)
Date: Mon, 28 Feb 2022 12:47:50 +0000
Subject: [issue46879] [doc] incorrect sphinx object names
Message-ID: <1646052470.1.0.108518625091.issue46879@roundup.psfhosted.org>


New submission from Martin Fischer <martin at push-f.com>:

API members documented in sphinx have an object name, which allow the
documentation to be linked from other projects. Sphinx calculates the
object name by prefixing the current module name to the directive
argument, e.g:

.. module:: foo
.. function:: bar.baz

becomes foo.bar.baz. Since these anchors aren't displayed in the
documentation, some mistakes have crept in, namely the Python stdlib
documentation currently contains the objects:

* asyncio.asyncio.subprocess.DEVNULL
* asyncio.asyncio.subprocess.PIPE
* asyncio.asyncio.subprocess.STDOUT
* asyncio.asyncio.subprocess.Process
* multiprocessing.sharedctypes.multiprocessing.Manager
* xml.etree.ElementTree.xml.etree.ElementInclude

As can be observed in the URL fragments:
https://docs.python.org/3/library/asyncio-subprocess.html#asyncio.asyncio.subprocess.Process
https://docs.python.org/3/library/multiprocessing.html#multiprocessing.sharedctypes.multiprocessing.Manager
https://docs.python.org/3/library/xml.etree.elementtree.html#xml.etree.ElementTree.xml.etree.ElementInclude.default_loader

I have a patch, prepared, I'll send a PR straight away.

----------
assignee: docs at python
components: Documentation
messages: 414192
nosy: docs at python, push-f
priority: normal
severity: normal
status: open
title: [doc] incorrect sphinx object names
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46879>
_______________________________________

From report at bugs.python.org  Mon Feb 28 07:48:44 2022
From: report at bugs.python.org (Nimrod Fiat)
Date: Mon, 28 Feb 2022 12:48:44 +0000
Subject: [issue46880] zipfile library doesn't extract windows zip files
 properly on linux
Message-ID: <1646052524.98.0.628413785417.issue46880@roundup.psfhosted.org>


New submission from Nimrod Fiat <nimrodf at google.com>:

Created a zip file using Powershell's Compress-Archive method. 
Moved the file to Debian. 
Used zipfile's extractall method to extract. 
The result was a flat directory with long file names such as:
"migrated-image952821\\m4a\\runiis.ps". 
I would expect instead for a "migrated-image952821" directory to be created, containing an "m4a" directory which contains "runiis.ps"

----------
components: Library (Lib)
messages: 414193
nosy: nimrodf
priority: normal
severity: normal
status: open
title: zipfile library doesn't extract windows zip files properly on linux
type: behavior
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46880>
_______________________________________

From report at bugs.python.org  Mon Feb 28 07:48:48 2022
From: report at bugs.python.org (Martin Fischer)
Date: Mon, 28 Feb 2022 12:48:48 +0000
Subject: [issue46879] [doc] incorrect sphinx object names
In-Reply-To: <1646052470.1.0.108518625091.issue46879@roundup.psfhosted.org>
Message-ID: <1646052528.59.0.199874915663.issue46879@roundup.psfhosted.org>


Change by Martin Fischer <martin at push-f.com>:


----------
keywords: +patch
pull_requests: +29739
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31615

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46879>
_______________________________________

From report at bugs.python.org  Mon Feb 28 07:56:35 2022
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 28 Feb 2022 12:56:35 +0000
Subject: [issue46841] Inline bytecode caches
In-Reply-To: <1645669034.5.0.77775951626.issue46841@roundup.psfhosted.org>
Message-ID: <1646052995.42.0.922660172561.issue46841@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset 4558af5a8f8e56a9b0dc11f6e834c47e0fd05f9e by Mark Shannon in branch 'main':
bpo-46841: Move the cache for `LOAD_GLOBAL` inline. (GH-31575)
https://github.com/python/cpython/commit/4558af5a8f8e56a9b0dc11f6e834c47e0fd05f9e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46841>
_______________________________________

From report at bugs.python.org  Mon Feb 28 08:02:28 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Mon, 28 Feb 2022 13:02:28 +0000
Subject: [issue46881] Statically allocate and initialize the latin1 characters.
Message-ID: <1646053348.55.0.937753092888.issue46881@roundup.psfhosted.org>


New submission from Kumar Aditya <rahuladitya303 at gmail.com>:

Statically allocate and initialize the latin1 characters. This *should* make iterating over a ascii strings faster as it avoids an atomic read in PyInterpreterState_GET() to get unicode state in get_latin1_char, makes get_latin1_char branchless and can be used in deepfreeze for identifiers.

----------
components: Interpreter Core
messages: 414195
nosy: Mark.Shannon, eric.snow, gvanrossum, kumaraditya303
priority: normal
severity: normal
status: open
title: Statically allocate and initialize the latin1 characters.
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46881>
_______________________________________

From report at bugs.python.org  Mon Feb 28 08:04:52 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Mon, 28 Feb 2022 13:04:52 +0000
Subject: [issue46881] Statically allocate and initialize the latin1 characters.
In-Reply-To: <1646053348.55.0.937753092888.issue46881@roundup.psfhosted.org>
Message-ID: <1646053492.51.0.995446320572.issue46881@roundup.psfhosted.org>


Change by Kumar Aditya <rahuladitya303 at gmail.com>:


----------
keywords: +patch
pull_requests: +29741
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31616

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46881>
_______________________________________

From report at bugs.python.org  Mon Feb 28 08:54:49 2022
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 28 Feb 2022 13:54:49 +0000
Subject: [issue46871] Lambda can't be pickled with "spawn" and only "fork"
In-Reply-To: <1645930683.9.0.146416539661.issue46871@roundup.psfhosted.org>
Message-ID: <1646056489.93.0.565903867503.issue46871@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The default start method for multirprocessing was changed from "fork" to "spawn" on macOS. This was done because the "fork" method can easily be triggered into causing hard crashes (on macOS), in particular when the parent proces has called higher-level systemen APIs.

The "spawn" method requires pickling the data and callable passed to the child proces, and that's not supported for lambda's.

----------
components: +macOS
nosy: +ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46871>
_______________________________________

From report at bugs.python.org  Mon Feb 28 09:14:07 2022
From: report at bugs.python.org (tongxiaoge)
Date: Mon, 28 Feb 2022 14:14:07 +0000
Subject: [issue46849] Memory problems detected using Valgrind
In-Reply-To: <1645711886.58.0.922948546021.issue46849@roundup.psfhosted.org>
Message-ID: <1646057647.81.0.701947560812.issue46849@roundup.psfhosted.org>


tongxiaoge <shixuantong at huawei.com> added the comment:

Ok, thanks. There is no memory problem exposed when I add --suppressions=Misc/valgrind-python.supp. I will close this issue.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46849>
_______________________________________

From report at bugs.python.org  Mon Feb 28 09:28:31 2022
From: report at bugs.python.org (Rotzbua)
Date: Mon, 28 Feb 2022 14:28:31 +0000
Subject: [issue46882] Clarify argument type of platform.platform(aliased,
 terse) to boolean
Message-ID: <1646058511.8.0.677652153168.issue46882@roundup.psfhosted.org>


New submission from Rotzbua <bugs.python.org at kryx.de>:

Problem:
Both arguments `aliased` and `terse` should be boolean instead of integer.

Description:
The function is as `platform.platform(aliased=0, terse=0)` so both arguments `aliased` and `terse` seems to be numbers.
The documentation says: "If aliased is true,[..]" which gives a hint that the type should be boolean instead of an integer.
Looking into the implementation both arguments used as boolean.

Solution:
Update documentation and set default argument values to `False` instead of `0`.

Reference:
Current documentation: https://docs.python.org/3.11/library/platform.html#platform.platform

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 414198
nosy: Rotzbua, docs at python
priority: normal
severity: normal
status: open
title: Clarify argument type of platform.platform(aliased, terse) to boolean
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46882>
_______________________________________

From report at bugs.python.org  Mon Feb 28 09:30:28 2022
From: report at bugs.python.org (Rotzbua)
Date: Mon, 28 Feb 2022 14:30:28 +0000
Subject: [issue46882] Clarify argument type of platform.platform(aliased,
 terse) to boolean
In-Reply-To: <1646058511.8.0.677652153168.issue46882@roundup.psfhosted.org>
Message-ID: <1646058628.08.0.0273538700055.issue46882@roundup.psfhosted.org>


Change by Rotzbua <bugs.python.org at kryx.de>:


----------
keywords: +patch
pull_requests: +29742
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31617

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46882>
_______________________________________

From report at bugs.python.org  Mon Feb 28 09:49:34 2022
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 28 Feb 2022 14:49:34 +0000
Subject: [issue46882] Clarify argument type of platform.platform(aliased,
 terse) to boolean
In-Reply-To: <1646058511.8.0.677652153168.issue46882@roundup.psfhosted.org>
Message-ID: <1646059774.35.0.903635655114.issue46882@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

> Both arguments `aliased` and `terse` should be boolean instead of integer.

Why should they be strictly True/False booleans? I disagree strongly that they should be. Any object that duck-types as a true or false value is sufficient.

Treated as a documentation change, your PR is wrong because it implies that *only* the singletons `True` and `False` are acceptable, when in fact any true and false (note the lowercase) values are acceptable.

Personally, I prefer the terms "truthy" and "falsey", or "a true value" and "a false value" over a bare true/false, but some people do not, and it is a long-standing tradition in Python circles to understand lowercase true/false as the duck-typed values as opposed to the `True` and `False` bool singletons.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46882>
_______________________________________

From report at bugs.python.org  Mon Feb 28 10:02:34 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Feb 2022 15:02:34 +0000
Subject: [issue46748] Python.h includes stdbool.h
In-Reply-To: <1644830899.62.0.590844926135.issue46748@roundup.psfhosted.org>
Message-ID: <1646060554.51.0.822026371812.issue46748@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Thank you, Kumar & Victor, for fixing up the issue!

You're welcome. I'm happy to see that you reduced the number of #include in the C API ;-) I made similar changes in bpo-45434.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46748>
_______________________________________

From report at bugs.python.org  Mon Feb 28 10:04:16 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Feb 2022 15:04:16 +0000
Subject: [issue45431] [C API] Rename CFrame or hide it to only export names
 starting with Py
In-Reply-To: <1633945803.57.0.940910379519.issue45431@roundup.psfhosted.org>
Message-ID: <1646060656.92.0.714048630221.issue45431@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 7496f9587306772b56ed074092c020f3ef16bf95 by Victor Stinner in branch 'main':
bpo-45431: Rename CFrame to _PyCFrame in the C API (GH-31584)
https://github.com/python/cpython/commit/7496f9587306772b56ed074092c020f3ef16bf95


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45431>
_______________________________________

From report at bugs.python.org  Mon Feb 28 10:05:21 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Feb 2022 15:05:21 +0000
Subject: [issue45431] [C API] Rename CFrame or hide it to only export names
 starting with Py
In-Reply-To: <1633945803.57.0.940910379519.issue45431@roundup.psfhosted.org>
Message-ID: <1646060721.64.0.58544964059.issue45431@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Ok, CFrame has been renamed.

> We should either make the whole PyThreadState structure private (move it to the internal C API)

This idea is tracked by bpo-39947.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45431>
_______________________________________

From report at bugs.python.org  Mon Feb 28 10:07:04 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Feb 2022 15:07:04 +0000
Subject: [issue45431] [C API] Rename CFrame or hide it to only export names
 starting with Py
In-Reply-To: <1633945803.57.0.940910379519.issue45431@roundup.psfhosted.org>
Message-ID: <1646060824.28.0.413748648514.issue45431@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/issue45431>
_______________________________________

From report at bugs.python.org  Mon Feb 28 10:07:40 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Mon, 28 Feb 2022 15:07:40 +0000
Subject: [issue46878] [sqlite3] remove "non-standard" from docstrings
In-Reply-To: <1646045428.22.0.0724822171916.issue46878@roundup.psfhosted.org>
Message-ID: <1646060860.16.0.0599338303941.issue46878@roundup.psfhosted.org>


Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:

As one of the people confused by this wording, I agree with dropping it. There is no documentation that I can find that explains what "non-standard" means.

I'll leave the PR for some time though in case others have objections.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46878>
_______________________________________

From report at bugs.python.org  Mon Feb 28 10:18:18 2022
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 28 Feb 2022 15:18:18 +0000
Subject: [issue46883] Add glossary entries to clarify the true/True and
 false/False distinction
Message-ID: <1646061498.87.0.521811715231.issue46883@roundup.psfhosted.org>


New submission from Steven D'Aprano <steve+python at pearwood.info>:

There is a long-standing tradition, going back to Python 1.x days before we had dedicated True and False values, to use the lowercase "true" and "false" to mean *any value that duck-types as True* and *any value that duck-types as False* in a boolean context.

Other terms for this same concept include "truthy/falsey" and using true/false as adjectives rather than nouns, e.g. "a true value".

But I am not sure whether this is actually written down anywhere in the documentation.

It would be useful for those who are not aware of the convention (e.g. beginners and people coming from other languages) if the Glossary had entries for lowercase "true" and "false" that explained the usage and referred back to PEP 285. See for example #46882 where this came up.

I suggest something like the following:

boolean context
  Code such as ``if condition:`` and ``while condition:`` which causes the expression ``condition`` to be evaluated as if it were a :class:`bool`.

false
  Any object which evaluates to the :class:`bool` singleton ``False`` in a :term:`boolean context`. Informally known as "falsey". See :term:`true` and :pep:`285`. Among the builtins , false values include ``None``, empty containers and strings, and zero numbers.

true
  Any object which evaluates to the :class:`bool` singleton ``True`` in a :term:`boolean context`. Informally known as "truthy". See :term:`false` and :pep:`285`. Among the builtins , true values include non-empty containers and strings, non-zero numbers (including NANs), and all other objects by default.

----------
assignee: docs at python
components: Documentation
messages: 414204
nosy: docs at python, steven.daprano
priority: normal
severity: normal
status: open
title: Add glossary entries to clarify the true/True and false/False distinction
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46883>
_______________________________________

From report at bugs.python.org  Mon Feb 28 10:20:05 2022
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 28 Feb 2022 15:20:05 +0000
Subject: [issue46882] Clarify argument type of platform.platform(aliased,
 terse) to boolean
In-Reply-To: <1646058511.8.0.677652153168.issue46882@roundup.psfhosted.org>
Message-ID: <1646061605.55.0.975782382818.issue46882@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

See #46883

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46882>
_______________________________________

From report at bugs.python.org  Mon Feb 28 10:29:38 2022
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 28 Feb 2022 15:29:38 +0000
Subject: [issue46883] Add glossary entries to clarify the true/True and
 false/False distinction
In-Reply-To: <1646061498.87.0.521811715231.issue46883@roundup.psfhosted.org>
Message-ID: <1646062178.35.0.51257018302.issue46883@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Note also that this is mentioned here:

https://docs.python.org/3/library/stdtypes.html#boolean-values

"[True and False] are used to represent truth values (although other values can also be considered false or true)."

although it is perhaps not as clear as I would prefer.

Also relevant is this:

https://docs.python.org/3/library/stdtypes.html#truth-value-testing

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46883>
_______________________________________

From report at bugs.python.org  Mon Feb 28 10:56:13 2022
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 28 Feb 2022 15:56:13 +0000
Subject: [issue46841] Inline bytecode caches
In-Reply-To: <1645669034.5.0.77775951626.issue46841@roundup.psfhosted.org>
Message-ID: <1646063773.34.0.604269517155.issue46841@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
pull_requests: +29743
pull_request: https://github.com/python/cpython/pull/31618

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46841>
_______________________________________

From report at bugs.python.org  Mon Feb 28 11:26:50 2022
From: report at bugs.python.org (Vidhya)
Date: Mon, 28 Feb 2022 16:26:50 +0000
Subject: [issue21761] [doc] language reference describes the role of
 module.__file__ inaccurately
In-Reply-To: <1402778004.82.0.418404996295.issue21761@psf.upfronthosting.co.za>
Message-ID: <1646065610.96.0.598013200058.issue21761@roundup.psfhosted.org>


Vidhya <vidhya.friend at gmail.com> added the comment:

Thanks Alex. I will look into @slateny's patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21761>
_______________________________________

From report at bugs.python.org  Mon Feb 28 11:41:36 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 28 Feb 2022 16:41:36 +0000
Subject: [issue44807] typing.Protocol silently overrides __init__ method of
 delivered class
In-Reply-To: <1627898026.7.0.991897199639.issue44807@roundup.psfhosted.org>
Message-ID: <1646066496.93.0.176900085865.issue44807@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
resolution:  -> third party
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44807>
_______________________________________

From report at bugs.python.org  Mon Feb 28 11:58:45 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 28 Feb 2022 16:58:45 +0000
Subject: [issue46814] Documentation for constructing abstract base classes is
 misleading
In-Reply-To: <1645431945.33.0.392126816255.issue46814@roundup.psfhosted.org>
Message-ID: <1646067525.8.0.39645670829.issue46814@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Raymond, I agree that this is going too far. I believe the OP has taken the position that "abstract" has only one meaning and it is defined by inspect.isabstract(). I disagree with this.

An ABC is an ABC is an ABC, and it provides certain functionality through the ABCMeta metaclass: (1) forbid instantiation when at least one @abstractmethod-decorated method exist that isn't overridden, and (2) virtual subclasses.

Calling out that a class with metaclass=ABCMeta is only abstract when it has at least one @abstractmethod left, over and over, is not helpful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46814>
_______________________________________

From report at bugs.python.org  Mon Feb 28 12:33:33 2022
From: report at bugs.python.org (Martin Fischer)
Date: Mon, 28 Feb 2022 17:33:33 +0000
Subject: [issue46884] [doc] msilib.rst uses data directive to document modules
Message-ID: <1646069613.09.0.14886937024.issue46884@roundup.psfhosted.org>


New submission from Martin Fischer <martin at push-f.com>:

As per [1] the py:data directive describes data in a module.
It should not be used for submodules, that's what the module directive is for. A side-effect that this is causing is that msilib.schema,     msilib.sequence and msilib.text do not show up in the Python Module Index[2] as they should.

[1]: https://www.sphinx-doc.org/en/master/usage/restructuredtext/domains.html
[2]: file:///home/martin/repos-contrib/cpython/Doc/build/html/py-modindex.html#cap-m

----------
assignee: docs at python
components: Documentation
messages: 414209
nosy: docs at python, push-f
priority: normal
severity: normal
status: open
title: [doc] msilib.rst uses data directive to document modules
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46884>
_______________________________________

From report at bugs.python.org  Mon Feb 28 12:34:13 2022
From: report at bugs.python.org (Martin Fischer)
Date: Mon, 28 Feb 2022 17:34:13 +0000
Subject: [issue46884] [doc] msilib.rst uses data directive to document modules
In-Reply-To: <1646069613.09.0.14886937024.issue46884@roundup.psfhosted.org>
Message-ID: <1646069653.5.0.143715942676.issue46884@roundup.psfhosted.org>


Change by Martin Fischer <martin at push-f.com>:


----------
keywords: +patch
pull_requests: +29744
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31620

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46884>
_______________________________________

From report at bugs.python.org  Mon Feb 28 12:35:51 2022
From: report at bugs.python.org (Martin Fischer)
Date: Mon, 28 Feb 2022 17:35:51 +0000
Subject: [issue46884] [doc] msilib.rst uses data directive to document modules
In-Reply-To: <1646069613.09.0.14886937024.issue46884@roundup.psfhosted.org>
Message-ID: <1646069751.86.0.522823656803.issue46884@roundup.psfhosted.org>


Martin Fischer <martin at push-f.com> added the comment:

([2] was meant to be an online link: https://docs.python.org/3.9/py-modindex.html#cap-m)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46884>
_______________________________________

From report at bugs.python.org  Mon Feb 28 12:38:55 2022
From: report at bugs.python.org (Martin Fischer)
Date: Mon, 28 Feb 2022 17:38:55 +0000
Subject: [issue46880] zipfile library doesn't extract windows zip files
 properly on linux
In-Reply-To: <1646052524.98.0.628413785417.issue46880@roundup.psfhosted.org>
Message-ID: <1646069935.78.0.128143766012.issue46880@roundup.psfhosted.org>


Martin Fischer <martin at push-f.com> added the comment:

Can you attach such a .zip file so that others can reproduce the bug?

----------
nosy: +push-f

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46880>
_______________________________________

From report at bugs.python.org  Mon Feb 28 12:43:13 2022
From: report at bugs.python.org (Kevin Hock)
Date: Mon, 28 Feb 2022 17:43:13 +0000
Subject: [issue45991] Improve ambiguous docstrings in pkgutil
In-Reply-To: <1638730607.25.0.754715317111.issue45991@roundup.psfhosted.org>
Message-ID: <1646070193.39.0.139397868602.issue45991@roundup.psfhosted.org>


Kevin Hock <khock at pinterest.com> added the comment:

> Maybe instead a note could be put in the Pathlib doc noting functions that accept path arguments might not accept Path objects?

My concern with that is that someone using `pkgutil` wouldn't see it. However, I can see the argument that fixing the 'source' is better than each use. I'm not sure how wide-spread these kind of issues are to weigh in on how many 'uses' there are. If that makes sense.

>Should pkgutil call os.fspath() in this case?

I really like that idea. (I haven't contributed to CPython before, so I'll let someone else weigh in on if that is standard practice.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45991>
_______________________________________

From report at bugs.python.org  Mon Feb 28 13:33:36 2022
From: report at bugs.python.org (Rotzbua)
Date: Mon, 28 Feb 2022 18:33:36 +0000
Subject: [issue46882] Clarify argument type of platform.platform(aliased,
 terse) to boolean
In-Reply-To: <1646058511.8.0.677652153168.issue46882@roundup.psfhosted.org>
Message-ID: <1646073216.15.0.554173505707.issue46882@roundup.psfhosted.org>


Change by Rotzbua <bugs.python.org at kryx.de>:


----------
pull_requests: +29745
pull_request: https://github.com/python/cpython/pull/31621

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46882>
_______________________________________

From report at bugs.python.org  Mon Feb 28 13:49:58 2022
From: report at bugs.python.org (Rotzbua)
Date: Mon, 28 Feb 2022 18:49:58 +0000
Subject: [issue46882] Clarify argument type of platform.platform(aliased,
 terse) to boolean
In-Reply-To: <1646058511.8.0.677652153168.issue46882@roundup.psfhosted.org>
Message-ID: <1646074198.27.0.944877056853.issue46882@roundup.psfhosted.org>


Rotzbua <bugs.python.org at kryx.de> added the comment:

Thanks for pointing out the logical change from "true" to "True".
I do not want to start a discussion about principles.

Nevertheless I think a change from `platform(aliased=0, terse=0)` to `platform(aliased=False, terse=False)` makes the how-to-use more intuitive.

The change does not change any function behavior or breaks any backwards compatibilities.

I created a new PR without the change of "true".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46882>
_______________________________________

From report at bugs.python.org  Mon Feb 28 13:53:32 2022
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 28 Feb 2022 18:53:32 +0000
Subject: [issue46885] Ensure PEP 663 changes are reverted from 3.11
Message-ID: <1646074412.45.0.770188341113.issue46885@roundup.psfhosted.org>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

As PEP 663 https://github.com/python/steering-council/issues/76 was rejected, we need to ensure that the changes made in 3.11 (see https://github.com/python/steering-council/issues/76#issuecomment-970668967) are rejected.

I am marking this as a release blocker so we don't forget.

----------
assignee: ethan.furman
messages: 414214
nosy: ethan.furman, pablogsal
priority: release blocker
severity: normal
status: open
title: Ensure PEP 663 changes are reverted from 3.11
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46885>
_______________________________________

From report at bugs.python.org  Mon Feb 28 13:56:31 2022
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 28 Feb 2022 18:56:31 +0000
Subject: [issue46885] Ensure PEP 663 changes are reverted from 3.11
In-Reply-To: <1646074412.45.0.770188341113.issue46885@roundup.psfhosted.org>
Message-ID: <1646074591.25.0.059710448245.issue46885@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> we need to ensure that the changes made in 3.11 (see https://github.com/python/steering-council/issues/76#issuecomment-970668967) are rejected.

Apologies, I meant "we need to ensure that the changes made in 3.11 are **reverted**.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46885>
_______________________________________

From report at bugs.python.org  Mon Feb 28 14:09:45 2022
From: report at bugs.python.org (benrg)
Date: Mon, 28 Feb 2022 19:09:45 +0000
Subject: [issue46868] Improve performance of math.prod with bignums (and
 functools.reduce?)
In-Reply-To: <1645918553.19.0.346410511769.issue46868@roundup.psfhosted.org>
Message-ID: <1646075385.81.0.168111910593.issue46868@roundup.psfhosted.org>


benrg <benrudiak at gmail.com> added the comment:

Anything that produces output of O(m+n) size in O(m+n) time. Ordered merging operations. Mergesort is a binary ordered merge with log-depth tree reduction, and insertion sort is the same binary operation with linear-depth tree reduction. Say you're merging sorted lists of intervals, and overlapping intervals need special treatment. It's easier to write a manifestly correct binary merge than an n-way merge, or a filter after heapq.merge that needs to deal with complex interval clusters. I've written that sort of code.

Any situation that resembles a fast path but doesn't qualify for the fast path. For example, there's an optimized factorial function in math, but you need double factorial. Or math.prod is optimized for ints as you suggested, but you have a class that uses ints internally but doesn't pass the CheckExact test. Usually when you miss out on a fast path, you just take a (sometimes large) constant-factor penalty, but here it pushes you into a different complexity class. Or you have a class that uses floats internally and wants to limit accumulated roundoff errors, but the struture of the computation doesn't fit fsum.

>Tree reduction is very popular in the parallel processing world, for obvious reasons.

It's the same reason in every case: the log depth limits the accumulation of some bad thing. In parallel computing it's critical-path length, in factorial and mergesort it's size, in fsum it's roundoff error. Log depth helps in a range of situations.

>I've searched in vain for other languages that try to address this "in general"

You've got me there.

>As Guido will tell you, the only original idea in Python is adding an "else" clause to loops ;-)

I don't think that's really true, except in the sense that there's nothing new under the sun. No one would use Python if it was just like other languages except slower and with for-else.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46868>
_______________________________________

From report at bugs.python.org  Mon Feb 28 14:14:19 2022
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 28 Feb 2022 19:14:19 +0000
Subject: [issue46885] Ensure PEP 663 changes are reverted from 3.11
In-Reply-To: <1646074412.45.0.770188341113.issue46885@roundup.psfhosted.org>
Message-ID: <1646075659.45.0.277945880616.issue46885@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

This has been taken care of in issue40066.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46885>
_______________________________________

From report at bugs.python.org  Mon Feb 28 14:29:35 2022
From: report at bugs.python.org (Thomas Wouters)
Date: Mon, 28 Feb 2022 19:29:35 +0000
Subject: [issue46885] Ensure PEP 663 changes are reverted from 3.11
In-Reply-To: <1646074412.45.0.770188341113.issue46885@roundup.psfhosted.org>
Message-ID: <1646076575.6.0.894783615142.issue46885@roundup.psfhosted.org>


Change by Thomas Wouters <thomas at python.org>:


----------
nosy: +twouters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46885>
_______________________________________

From report at bugs.python.org  Mon Feb 28 14:38:17 2022
From: report at bugs.python.org (Irit Katriel)
Date: Mon, 28 Feb 2022 19:38:17 +0000
Subject: [issue26175] Fully implement IOBase abstract on SpooledTemporaryFile
In-Reply-To: <1453413274.25.0.536987988375.issue26175@psf.upfronthosting.co.za>
Message-ID: <1646077097.58.0.712873933941.issue26175@roundup.psfhosted.org>


Irit Katriel <iritkatriel at gmail.com> added the comment:

> Irit, you just patched Temp file doc, can you look at the PR code?


I don't consider myself and expert here, but I left a comment on PR29560 just to be a good sport.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26175>
_______________________________________

From report at bugs.python.org  Mon Feb 28 14:44:10 2022
From: report at bugs.python.org (Irit Katriel)
Date: Mon, 28 Feb 2022 19:44:10 +0000
Subject: [issue46808] remove NEXT_BLOCK() from compile.c
In-Reply-To: <1645368528.16.0.363497063609.issue46808@roundup.psfhosted.org>
Message-ID: <1646077450.45.0.956471279665.issue46808@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46808>
_______________________________________

From report at bugs.python.org  Mon Feb 28 14:47:30 2022
From: report at bugs.python.org (Tim Peters)
Date: Mon, 28 Feb 2022 19:47:30 +0000
Subject: [issue46868] Improve performance of math.prod with bignums (and
 functools.reduce?)
In-Reply-To: <1645918553.19.0.346410511769.issue46868@roundup.psfhosted.org>
Message-ID: <1646077650.96.0.738076407872.issue46868@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Too abstract for me to find compelling. I suspect the title of this report referenced "math.prod with bignums" because it's the only actual concrete use case you had ;-)

Here's another: math.lcm. That can benefit for the same reason as math.prod - provoking Karatsuba multiplication. However, applying lcm to a largish collection of ints is so rare I can't recall ever seeing it done.

Here's a related anti-example: math.gcd. Tree reduction hurts that. It typically falls to 1 quickly, and tree reduction just delays that.

So I'm at best -0 on this, and I'll stop now.

For reference, here's a Python implementation that strives to match functools.reduce's signature and endcase behaviors. It accepts any iterable, and requires temp space at most about log2(number of elements the iterable delivers in all).

That memory frugality adds a log2 factor to the runtime. The O() speed penalty could be eliminated by using temp memory that grows to about half the number of elements in the iterable.

    def treereduce(function, iterable, initializer=None):
        levels = []
        if initializer is not None:
            levels.append(initializer)
        NULL = object()
        for y in iterable:
            for i, x in enumerate(levels):
                if x is NULL:
                    levels[i] = y
                    break
                y = function(x, y)
                levels[i] = NULL
            else:
                levels.append(y)
        y = NULL
        for x in levels:
            if x is not NULL:
                y = x if y is NULL else function(x, y)
        if y is NULL:
            raise TypeError("treereduce() of empty iterable with no initial value")
        return y

Then, for example,

>>> treereduce(lambda x, y: f"({x}+{y})", "abcdefghijk")
'((((a+b)+(c+d))+((e+f)+(g+h)))+((i+j)+k))'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46868>
_______________________________________

From report at bugs.python.org  Mon Feb 28 14:59:50 2022
From: report at bugs.python.org (benrg)
Date: Mon, 28 Feb 2022 19:59:50 +0000
Subject: [issue46791] Allow os.remove to defer to rmdir
In-Reply-To: <1645206913.87.0.447648839641.issue46791@roundup.psfhosted.org>
Message-ID: <1646078390.72.0.0100923337547.issue46791@roundup.psfhosted.org>


benrg <benrudiak at gmail.com> added the comment:

The REMOVE_DIR case reduces to

    return RemoveDirectoryW(path->wide) ? 0 : -1;

so I think there's no reason to combine it with the other two.

The REMOVE_BOTH case is

    attrs = GetFileAttributesW(path->wide);

    if (attrs != INVALID_FILE_ATTRIBUTES && (attrs & FILE_ATTRIBUTE_DIRECTORY)) {
        success = RemoveDirectoryW(path->wide);
    } else {
        success = DeleteFileW(path->wide);
    }

    return success ? 0 : -1;

For REMOVE_BOTH, I don't see the need of calling GetFileAttributes - couldn't you just try DeleteFile, and if that fails, RemoveDirectory?

----------
nosy: +benrg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46791>
_______________________________________

From report at bugs.python.org  Mon Feb 28 15:04:35 2022
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 28 Feb 2022 20:04:35 +0000
Subject: [issue38576] CVE-2019-18348: CRLF injection via the host part of the
 url passed to urlopen()
In-Reply-To: <1571903478.88.0.753943817426.issue38576@roundup.psfhosted.org>
Message-ID: <1646078675.67.0.505620050005.issue38576@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
nosy: +python-dev
nosy_count: 17.0 -> 18.0
pull_requests: +29746
pull_request: https://github.com/python/cpython/pull/31606

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38576>
_______________________________________

From report at bugs.python.org  Mon Feb 28 15:08:32 2022
From: report at bugs.python.org (Brandt Bucher)
Date: Mon, 28 Feb 2022 20:08:32 +0000
Subject: [issue46841] Inline bytecode caches
In-Reply-To: <1645669034.5.0.77775951626.issue46841@roundup.psfhosted.org>
Message-ID: <1646078912.71.0.324527884971.issue46841@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
pull_requests: +29747
pull_request: https://github.com/python/cpython/pull/31622

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46841>
_______________________________________

From report at bugs.python.org  Mon Feb 28 15:21:12 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 28 Feb 2022 20:21:12 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1646079672.42.0.0172756269547.issue46771@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
pull_requests: +29748
pull_request: https://github.com/python/cpython/pull/31623

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Mon Feb 28 15:23:46 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 28 Feb 2022 20:23:46 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1646079826.9.0.9675563443.issue46771@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Everyone,

I've sent a PR (which I expect will make it into alpha 6) that restores the old cancel() semantics. This should make Tin happy, but I think we'll still have to have a longer discussion about the downsides.

https://github.com/python/cpython/pull/31623

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Mon Feb 28 15:23:55 2022
From: report at bugs.python.org (Ned Deily)
Date: Mon, 28 Feb 2022 20:23:55 +0000
Subject: [issue38576] CVE-2019-18348: CRLF injection via the host part of the
 url passed to urlopen()
In-Reply-To: <1571903478.88.0.753943817426.issue38576@roundup.psfhosted.org>
Message-ID: <1646079835.13.0.183723026003.issue38576@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
pull_requests:  -29746

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38576>
_______________________________________

From report at bugs.python.org  Mon Feb 28 17:15:58 2022
From: report at bugs.python.org (Eric Snow)
Date: Mon, 28 Feb 2022 22:15:58 +0000
Subject: [issue46753] Statically allocate and initialize the empty tuple.
In-Reply-To: <1644878407.77.0.113778164261.issue46753@roundup.psfhosted.org>
Message-ID: <1646086558.47.0.886654880201.issue46753@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:


New changeset 08deed1af56bec8668c6cb4d5cfd89e393e1fe5e by Eric Snow in branch 'main':
bpo-46753: Add the empty tuple to the _PyRuntimeState.global_objects. (gh-31345)
https://github.com/python/cpython/commit/08deed1af56bec8668c6cb4d5cfd89e393e1fe5e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46753>
_______________________________________

From report at bugs.python.org  Mon Feb 28 17:53:09 2022
From: report at bugs.python.org (Eric Snow)
Date: Mon, 28 Feb 2022 22:53:09 +0000
Subject: [issue46886] pyexpat occasionally fails to build on the ARM64 Windows
 Non-Debug 3.x buildbot
Message-ID: <1646088788.98.0.693772071082.issue46886@roundup.psfhosted.org>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

example: https://buildbot.python.org/all/#/builders/730/builds/4081

----------
components: Build
messages: 414223
nosy: eric.snow, vstinner
priority: normal
severity: normal
stage: needs patch
status: open
title: pyexpat occasionally fails to build on the ARM64 Windows Non-Debug 3.x buildbot
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46886>
_______________________________________

From report at bugs.python.org  Mon Feb 28 18:16:09 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 28 Feb 2022 23:16:09 +0000
Subject: [issue46771] Add some form of cancel scopes
In-Reply-To: <1645034352.96.0.773044052656.issue46771@roundup.psfhosted.org>
Message-ID: <1646090169.4.0.0285182575881.issue46771@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset 7d611b4cabaf7925f5f94daddf711d54aeae2cf9 by Guido van Rossum in branch 'main':
bpo-46771: Remove two controversial lines from Task.cancel() (GH-31623)
https://github.com/python/cpython/commit/7d611b4cabaf7925f5f94daddf711d54aeae2cf9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________

From report at bugs.python.org  Mon Feb 28 18:27:29 2022
From: report at bugs.python.org (benrg)
Date: Mon, 28 Feb 2022 23:27:29 +0000
Subject: [issue46868] Improve performance of math.prod with bignums (and
 functools.reduce?)
In-Reply-To: <1645918553.19.0.346410511769.issue46868@roundup.psfhosted.org>
Message-ID: <1646090849.71.0.951569082559.issue46868@roundup.psfhosted.org>


benrg <benrudiak at gmail.com> added the comment:

>That memory frugality adds a log2 factor to the runtime.

Your iterative algorithm is exactly the one I had in mind, but it doesn't have the run time that you seem to think. Is that the whole reason for our disagreement?

It does only O(1) extra work (not even amortized O(1), really O(1)) for each call of the binary function, and there are exactly n-1 calls. There's a log(n) term (not factor) for expanding the array and skipping NULLs in the final cleanup. The constant factor for it is tiny since the array is so small.

I implemented it in C and benchmarked it against reduce with unvarying arguments (binary | on identical ints), and it's slightly slower around 75% of the time, and slightly faster around 25% of the time, seemingly at random, even in the same test, which I suppose is related to where the allocator decides to put the temporaries. The reordering only needs to have a sliver of a benefit for it to come out on top.

When I said "at the cost of a log factor" in the first message, I meant relative to algorithms like ''.join, not left-reduce.


>I suspect the title of this report referenced "math.prod with bignums" because it's the only actual concrete use case you had ;-)

I led with math.prod because its evaluation order isn't documented, so it can be changed (and I guess I should have said explicitly that there is no up-front penalty to changing it beyond tricky cache locality issues). I said "bignums" because I had in mind third-party libraries and the custom classes that I mentioned in my last message. I put ? after reduce because its left-associativity is documented and useful (e.g. with nonassociative functions), so it would have to be extended or a new function added, which is always a hard sell. I also wanted the title to be short. I did the best I could.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46868>
_______________________________________

From report at bugs.python.org  Mon Feb 28 18:44:58 2022
From: report at bugs.python.org (Eric Snow)
Date: Mon, 28 Feb 2022 23:44:58 +0000
Subject: [issue46753] Statically allocate and initialize the empty tuple.
In-Reply-To: <1644878407.77.0.113778164261.issue46753@roundup.psfhosted.org>
Message-ID: <1646091898.9.0.413734689651.issue46753@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46753>
_______________________________________

From report at bugs.python.org  Mon Feb 28 18:46:33 2022
From: report at bugs.python.org (Adam)
Date: Mon, 28 Feb 2022 23:46:33 +0000
Subject: [issue46863] Python 3.10 OpenSSL Configuration Issues
In-Reply-To: <1645852366.6.0.130545163871.issue46863@roundup.psfhosted.org>
Message-ID: <1646091993.15.0.653445875942.issue46863@roundup.psfhosted.org>


Adam <apinckard85 at gmail.com> added the comment:

Update, the Pyenv team confirmed that they do not install OpenSSL in linux, its only installed for MacOS, and it should be built using the system OpenSSL within Linux.

We're investigating further to attempt to debug the issue. Interestingly the OpenSSL build flags for both Python versions appear to be the same.

`Trying link with OPENSSL_LDFLAGS=; OPENSSL_LIBS=-lssl -lcrypto; OPENSSL_INCLUDES=`

I've attached the build logs for both the Python 3.9.10 and 3.10.2 build, in case you're able to review. Many thanks.

https://github.com/pyenv/pyenv/issues/2257

----------
Added file: https://bugs.python.org/file50653/python_builds.tar.gz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46863>
_______________________________________

From report at bugs.python.org  Mon Feb 28 19:05:50 2022
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 01 Mar 2022 00:05:50 +0000
Subject: [issue46791] Allow os.remove to defer to rmdir
In-Reply-To: <1645206913.87.0.447648839641.issue46791@roundup.psfhosted.org>
Message-ID: <1646093150.53.0.0337011816081.issue46791@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> For REMOVE_BOTH, I don't see the need of calling GetFileAttributes

I was thinking that the NtQueryAttributesFile() system call is relatively cheap compared to a full open, especially if the attributes of a remote file are cached locally. However, on second thought, it's probably not. An open can fail as soon as it knows that there's a file/directory type mismatch. This should be able to take advantage of a local attribute cache instead of incurring network latency.

> so I think there's no reason to combine it with the other two.

REMOVE_DIR can be separate, for the current behavior. But I wanted all modes handled in one function in case later on we decide to fix os.rmdir() in Windows. It allows deleting a directory symlink. Note that the os.lstat() result reports a directory symlink as an S_IFLNK file, not S_IFDIR, so the os.rmdir() behavior is internally inconsistent. This could be corrected by forcing the REMOVE_DIR mode to raise NotADirectoryError. For example:

        } else { // mode != REMOVE_BOTH

            WIN32_FIND_DATAW data;
            BOOL isDir = FALSE;
            BOOL isLnk = FALSE;

            HANDLE hFind = FindFirstFileW(path->wide, &data);
            if (hFind != INVALID_HANDLE_VALUE) {
                FindClose(hFind);
                isDir = data.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY;
                if (data.dwFileAttributes & FILE_ATTRIBUTE_REPARSE_POINT) {
                    if (mode == REMOVE_DIR) {
                        isLnk = data.dwReserved0 == IO_REPARSE_TAG_SYMLINK;
                    } else {
                        isLnk = IsReparseTagNameSurrogate(data.dwReserved0);
                    }
                }
            }

            if ((mode == REMOVE_DIR) && (isDir && isLnk)) {
                SetLastError(ERROR_DIRECTORY); // POSIX ENOTDIR
            } else if ((mode == REMOVE_DIR) || (isDir && isLnk)) {
                success = RemoveDirectoryW(path->wide);
            } else {
                success = DeleteFileW(path->wide);
            }
        }

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46791>
_______________________________________

From report at bugs.python.org  Mon Feb 28 20:09:24 2022
From: report at bugs.python.org (Dennis Sweeney)
Date: Tue, 01 Mar 2022 01:09:24 +0000
Subject: [issue46848] Use optimized string search function in mmap.find()
In-Reply-To: <1645706630.43.0.574969248824.issue46848@roundup.psfhosted.org>
Message-ID: <1646096964.25.0.715721420903.issue46848@roundup.psfhosted.org>


Change by Dennis Sweeney <sweeney.dennis650 at gmail.com>:


----------
nosy: +Dennis Sweeney
nosy_count: 2.0 -> 3.0
pull_requests: +29749
pull_request: https://github.com/python/cpython/pull/31625

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46848>
_______________________________________

From report at bugs.python.org  Mon Feb 28 20:11:45 2022
From: report at bugs.python.org (Vidhya)
Date: Tue, 01 Mar 2022 01:11:45 +0000
Subject: [issue17505] [doc] email.header.Header.__unicode__ does not decode
 header
In-Reply-To: <1363852013.63.0.253070231302.issue17505@psf.upfronthosting.co.za>
Message-ID: <1646097105.47.0.328959765798.issue17505@roundup.psfhosted.org>


Vidhya <vidhya.friend at gmail.com> added the comment:

[Entry level contributor seeking guidance] If this is still open, I like to work on this.

Also, planning to add the following(if no PR yet created) at make_header API at https://docs.python.org/3/library/email.header.html :

To get unicode strings use the API as shown below:
 unicode(make_header(decode_header('=?gb2312?b?1eLKx9bQzsSy4srUo6E=?=')))

If email policy parameter is set as 'policy.default' then the default policy, for that Python version, is used for header encoding and decoding. 

Please correct me if anything wrong.

----------
nosy: +vidhya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17505>
_______________________________________

From report at bugs.python.org  Mon Feb 28 20:17:14 2022
From: report at bugs.python.org (Vidhya)
Date: Tue, 01 Mar 2022 01:17:14 +0000
Subject: [issue6634] [doc] sys.exit() called from threads other than the main
 one: undocumented behaviour
In-Reply-To: <1249327311.32.0.926815032903.issue6634@psf.upfronthosting.co.za>
Message-ID: <1646097434.58.0.725134727788.issue6634@roundup.psfhosted.org>


Vidhya <vidhya.friend at gmail.com> added the comment:

[Entry level contributor seeking guidance]
If this is still open, I can work on this.

I plan to add the following in sys.exit() and add a reference to thread.exit() at https://docs.python.org/3/library/sys.html#sys.exit:

When called from a thread other than the main thread, this causes the thread to exit silently, and is equivalent to calling :func:`thread.exit`.

Please correct if anything wrong.

----------
nosy: +vidhya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6634>
_______________________________________

From report at bugs.python.org  Mon Feb 28 20:22:11 2022
From: report at bugs.python.org (Stanley)
Date: Tue, 01 Mar 2022 01:22:11 +0000
Subject: [issue45991] Improve ambiguous docstrings in pkgutil
In-Reply-To: <1638730607.25.0.754715317111.issue45991@roundup.psfhosted.org>
Message-ID: <1646097731.81.0.708280113621.issue45991@roundup.psfhosted.org>


Stanley <ostanley.lee at gmail.com> added the comment:

I feel like there might be some backwards compatibility issues if pkgutil wraps it like that, but similarly I'm not at all familiar with how common the package is used and whether it'd be fine to make that change, so I'll also differ judgement here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45991>
_______________________________________

From report at bugs.python.org  Mon Feb 28 20:32:22 2022
From: report at bugs.python.org (Tim Peters)
Date: Tue, 01 Mar 2022 01:32:22 +0000
Subject: [issue46868] Improve performance of math.prod with bignums (and
 functools.reduce?)
In-Reply-To: <1645918553.19.0.346410511769.issue46868@roundup.psfhosted.org>
Message-ID: <1646098342.09.0.0194288553258.issue46868@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

About runtime, you're right. I did a ballpark "OK, if there are N incoming values, the inner loop has to go around, for each one, looking for a NULL, across a vector of at most log2(N) entries. So N * log2(N)". But, in fact, it's highly skewed toward getting out early, and 2*N is an upper bound on the total number of inner loop iterations. Strongly related to that the total number of trailing 1 bits in the integers from 1 through N inclusive is N - N.bit_count().

For the rest, I'll only repeat that if this goes in, it should be as a new function. Special-casing, e.g., math.prod() is a Bad Idea. We can have no idea in advance whether the iterable is type-homogenous, or even whether the __mul__ methods the types involved implement are even intended to be associative. 

functools.reduce() clearly documents strict "left to right" evaluation.

But a new treereduce() can do anything it feels like promising.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46868>
_______________________________________

From report at bugs.python.org  Mon Feb 28 20:54:54 2022
From: report at bugs.python.org (Vidhya)
Date: Tue, 01 Mar 2022 01:54:54 +0000
Subject: [issue28516] contextlib.ExitStack.__enter__ has trivial but
 undocumented behavior
In-Reply-To: <1477276611.77.0.31268131141.issue28516@psf.upfronthosting.co.za>
Message-ID: <1646099694.69.0.437859503874.issue28516@roundup.psfhosted.org>


Vidhya <vidhya.friend at gmail.com> added the comment:

[Entry level contributor seeking guidance] If this is still open, I can update the document.

After reading all the above comments, planning to add 

"The __enter__ method returns the ExitStack instance, and performs no additional operations." 

at

https://docs.python.org/3/library/contextlib.html#contextlib.ExitStack.enter_context. 

Please let me know your thoughts.

----------
nosy: +vidhya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28516>
_______________________________________

From report at bugs.python.org  Mon Feb 28 21:08:14 2022
From: report at bugs.python.org (Paola Cosio)
Date: Tue, 01 Mar 2022 02:08:14 +0000
Subject: [issue6778] False positives given through bisect module (binary
 search)
In-Reply-To: <1251147558.19.0.488929549089.issue6778@psf.upfronthosting.co.za>
Message-ID: <1646100494.77.0.763057567115.issue6778@roundup.psfhosted.org>


Change by Paola Cosio <funeral.moon43 at gmail.com>:


----------
assignee:  -> docs at python
components: +Distutils, Documentation, Installation, Parser, email
nosy: +barry, docs at python, dstufft, eric.araujo, lys.nikolaou, pablogsal
type: behavior -> security

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6778>
_______________________________________

From report at bugs.python.org  Mon Feb 28 21:30:42 2022
From: report at bugs.python.org (Tim Peters)
Date: Tue, 01 Mar 2022 02:30:42 +0000
Subject: [issue46868] Improve performance of math.prod with bignums (and
 functools.reduce?)
In-Reply-To: <1645918553.19.0.346410511769.issue46868@roundup.psfhosted.org>
Message-ID: <1646101842.07.0.888433156053.issue46868@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

> the total number of trailing 1 bits in the integers from 1
> through N inclusive is N - N.bit_count()

Sorry, that's the total number of trailing 0 bits. The total number of trailing 1 bits is (N+1) - (N+1).bit_count().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46868>
_______________________________________

From report at bugs.python.org  Mon Feb 28 21:59:16 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Tue, 01 Mar 2022 02:59:16 +0000
Subject: [issue17505] [doc] email.header.Header.__unicode__ does not decode
 header
In-Reply-To: <1363852013.63.0.253070231302.issue17505@psf.upfronthosting.co.za>
Message-ID: <1646103556.07.0.635917119562.issue17505@roundup.psfhosted.org>


Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:

The messages above are very old and seem to be discussing Python 2. There is no `__unicode__` method any more, for example, though there is a `__str__` method which presumably does what `__unicode__` used to do. It is documented now at https://docs.python.org/3.10/library/email.header.html#email.header.Header.__str__ . You'll have to do some more digging to figure out whether the OP's complaint still applies.

----------
nosy: +Jelle Zijlstra

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17505>
_______________________________________

From report at bugs.python.org  Mon Feb 28 22:00:35 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Tue, 01 Mar 2022 03:00:35 +0000
Subject: [issue28516] contextlib.ExitStack.__enter__ has trivial but
 undocumented behavior
In-Reply-To: <1477276611.77.0.31268131141.issue28516@psf.upfronthosting.co.za>
Message-ID: <1646103635.5.0.531591851007.issue28516@roundup.psfhosted.org>


Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:

That sounds good. Feel free to request review from me if you make a PR.

----------
nosy: +Jelle Zijlstra

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28516>
_______________________________________

From report at bugs.python.org  Mon Feb 28 22:20:11 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Tue, 01 Mar 2022 03:20:11 +0000
Subject: [issue44807] typing.Protocol silently overrides __init__ method of
 delivered class
In-Reply-To: <1627898026.7.0.991897199639.issue44807@roundup.psfhosted.org>
Message-ID: <1646104811.59.0.181592858635.issue44807@roundup.psfhosted.org>


Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:

Regardless of mypy's behavior (which isn't impacted by what typing.py does), there's a legitimate complaint here about the runtime behavior: any `__init__` method defined in a Protocol gets silently replaced.

>>> from typing import Protocol
>>> class X(Protocol):
...     def __init__(self, x, y): pass
... 
>>> X.__init__
<function _no_init_or_replace_init at 0x10de4e5c0>

Fixing that won't be easy though, unless we give up on making it impossible to instantiate a Protocol.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44807>
_______________________________________

From report at bugs.python.org  Mon Feb 28 22:30:19 2022
From: report at bugs.python.org (Dennis Sweeney)
Date: Tue, 01 Mar 2022 03:30:19 +0000
Subject: [issue46848] Use optimized string search function in mmap.find()
In-Reply-To: <1645706630.43.0.574969248824.issue46848@roundup.psfhosted.org>
Message-ID: <1646105419.44.0.918199475061.issue46848@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

PR 31625 is an alternative proposal.

It uses the Crochemore and Perrin's Two-Way algorithm that @benrg references (see Objects/stringlib/fastsearch.h and Objects/stringlib/stringlib_find_two_way_notes.txt), and is platform-independent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46848>
_______________________________________