From report at bugs.python.org  Mon Mar  1 00:27:39 2021
From: report at bugs.python.org (Ned Deily)
Date: Mon, 01 Mar 2021 05:27:39 +0000
Subject: [issue42603] Tkinter: pkg-config is not used to get location of tcl
 and tk headers/libraries
In-Reply-To: <1607450864.79.0.446942772761.issue42603@roundup.psfhosted.org>
Message-ID: <1614576459.9.0.862394982687.issue42603@roundup.psfhosted.org>


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


New changeset a65b050516a4ec8f5fc591119b94ceaaa5f7afe3 by Ned Deily in branch 'master':
bpo-42603: Add whatsnew and ACKS entries. (GH-24675)
https://github.com/python/cpython/commit/a65b050516a4ec8f5fc591119b94ceaaa5f7afe3


----------

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

From report at bugs.python.org  Mon Mar  1 01:39:49 2021
From: report at bugs.python.org (Ned Deily)
Date: Mon, 01 Mar 2021 06:39:49 +0000
Subject: [issue43103] Add configure --without-static-libpython to not build
 libpython3.10.a
In-Reply-To: <1612279427.78.0.51879378101.issue43103@roundup.psfhosted.org>
Message-ID: <1614580789.54.0.132140941922.issue43103@roundup.psfhosted.org>


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


----------
nosy: +ned.deily
nosy_count: 2.0 -> 3.0
pull_requests: +23461
pull_request: https://github.com/python/cpython/pull/24676

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

From report at bugs.python.org  Mon Mar  1 01:40:12 2021
From: report at bugs.python.org (Christian Bachmaier)
Date: Mon, 01 Mar 2021 06:40:12 +0000
Subject: [issue43229] freeze searches libpython3.9.so in /usr/lib instead
 /usr/lib/x86_64-linux-gnu
In-Reply-To: <1613399795.84.0.430887747566.issue43229@roundup.psfhosted.org>
Message-ID: <1614580812.37.0.214288918395.issue43229@roundup.psfhosted.org>


Christian Bachmaier <chris at infosun.fim.uni-passau.de> added the comment:

Anyone?

----------

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

From report at bugs.python.org  Mon Mar  1 02:04:12 2021
From: report at bugs.python.org (Ned Deily)
Date: Mon, 01 Mar 2021 07:04:12 +0000
Subject: [issue43103] Add configure --without-static-libpython to not build
 libpython3.10.a
In-Reply-To: <1612279427.78.0.51879378101.issue43103@roundup.psfhosted.org>
Message-ID: <1614582252.06.0.0240329903832.issue43103@roundup.psfhosted.org>


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


New changeset 0608425944932f46b544afea04ae6d301a76f5f2 by Ned Deily in branch 'master':
bpo-43103: Fix build failure with macOS framework builds. (GH-24676)
https://github.com/python/cpython/commit/0608425944932f46b544afea04ae6d301a76f5f2


----------

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

From report at bugs.python.org  Mon Mar  1 02:09:51 2021
From: report at bugs.python.org (NateScarlet)
Date: Mon, 01 Mar 2021 07:09:51 +0000
Subject: [issue42627] urllib.request.getproxies() misparses Windows registry
 proxy settings
In-Reply-To: <1607804872.9.0.5170746987.issue42627@roundup.psfhosted.org>
Message-ID: <1614582591.32.0.544466540954.issue42627@roundup.psfhosted.org>


Change by NateScarlet <nate_s at qq.com>:


----------
nosy: +NateScarlet

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

From report at bugs.python.org  Mon Mar  1 02:15:22 2021
From: report at bugs.python.org (Ned Deily)
Date: Mon, 01 Mar 2021 07:15:22 +0000
Subject: [issue41837] Upgrade installers to OpenSSL 1.1.1j
In-Reply-To: <1600822748.89.0.850484234677.issue41837@roundup.psfhosted.org>
Message-ID: <1614582922.14.0.986412717698.issue41837@roundup.psfhosted.org>


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


----------
pull_requests: +23462
pull_request: https://github.com/python/cpython/pull/24677

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

From report at bugs.python.org  Mon Mar  1 02:33:09 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 01 Mar 2021 07:33:09 +0000
Subject: [issue43349] [doc] incorrect tuning(7) manpage link
Message-ID: <1614583989.29.0.630028464305.issue43349@roundup.psfhosted.org>


New submission from Erlend Egeberg Aasland <erlend.aasland at innova.no>:

In https://docs.python.org/3.10/library/resource.html#resource.RLIMIT_SWAP, tuning(7) points to https://manpages.debian.org/tuning(7), however this is a FreeBSD only (?) system call, so the link is incorrect.

I suggest linking to either:
- https://docs.freebsd.org/en/books/handbook/config/
- https://www.freebsd.org/cgi/man.cgi?query=tuning&sektion=7&format=html

----------
assignee: docs at python
components: Documentation
messages: 387845
nosy: docs at python, erlendaasland
priority: normal
severity: normal
status: open
title: [doc] incorrect tuning(7) manpage link
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Mar  1 02:39:20 2021
From: report at bugs.python.org (Ned Deily)
Date: Mon, 01 Mar 2021 07:39:20 +0000
Subject: [issue41837] Upgrade installers to OpenSSL 1.1.1j
In-Reply-To: <1600822748.89.0.850484234677.issue41837@roundup.psfhosted.org>
Message-ID: <1614584360.24.0.720996330067.issue41837@roundup.psfhosted.org>


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


New changeset 0242494a156970186cbc4121ccf03aefbddea716 by Ned Deily in branch 'master':
bpo-41837: Update macOS installer build to use OpenSSL 1.1.1j. (GH-24677)
https://github.com/python/cpython/commit/0242494a156970186cbc4121ccf03aefbddea716


----------

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

From report at bugs.python.org  Mon Mar  1 02:39:43 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 01 Mar 2021 07:39:43 +0000
Subject: [issue41837] Upgrade installers to OpenSSL 1.1.1j
In-Reply-To: <1600822748.89.0.850484234677.issue41837@roundup.psfhosted.org>
Message-ID: <1614584383.67.0.0236879606601.issue41837@roundup.psfhosted.org>


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


----------
pull_requests: +23463
pull_request: https://github.com/python/cpython/pull/24678

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

From report at bugs.python.org  Mon Mar  1 02:39:49 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 01 Mar 2021 07:39:49 +0000
Subject: [issue41837] Upgrade installers to OpenSSL 1.1.1j
In-Reply-To: <1600822748.89.0.850484234677.issue41837@roundup.psfhosted.org>
Message-ID: <1614584389.73.0.478425140391.issue41837@roundup.psfhosted.org>


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


----------
pull_requests: +23464
pull_request: https://github.com/python/cpython/pull/24679

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

From report at bugs.python.org  Mon Mar  1 02:58:15 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 01 Mar 2021 07:58:15 +0000
Subject: [issue43349] [doc] incorrect tuning(7) manpage link
In-Reply-To: <1614583989.29.0.630028464305.issue43349@roundup.psfhosted.org>
Message-ID: <1614585495.56.0.0402530152077.issue43349@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

> FreeBSD only (?) system call [...]

Correction, it's not a sys call. It belongs to the misc manpage section.

----------

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

From report at bugs.python.org  Mon Mar  1 03:00:16 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 01 Mar 2021 08:00:16 +0000
Subject: [issue41837] Upgrade installers to OpenSSL 1.1.1j
In-Reply-To: <1600822748.89.0.850484234677.issue41837@roundup.psfhosted.org>
Message-ID: <1614585616.44.0.229195951903.issue41837@roundup.psfhosted.org>


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


New changeset e2f6ed89aeaa0b723f45f914dba92e1b42518395 by Miss Islington (bot) in branch '3.8':
bpo-41837: Update macOS installer build to use OpenSSL 1.1.1j. (GH-24677)
https://github.com/python/cpython/commit/e2f6ed89aeaa0b723f45f914dba92e1b42518395


----------

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

From report at bugs.python.org  Mon Mar  1 03:01:50 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 01 Mar 2021 08:01:50 +0000
Subject: [issue41837] Upgrade installers to OpenSSL 1.1.1j
In-Reply-To: <1600822748.89.0.850484234677.issue41837@roundup.psfhosted.org>
Message-ID: <1614585710.6.0.544755192863.issue41837@roundup.psfhosted.org>


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


New changeset 982e8ecbdf216bc1fa285a4ff45c84c6778856e5 by Miss Islington (bot) in branch '3.9':
bpo-41837: Update macOS installer build to use OpenSSL 1.1.1j. (GH-24677)
https://github.com/python/cpython/commit/982e8ecbdf216bc1fa285a4ff45c84c6778856e5


----------

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

From report at bugs.python.org  Mon Mar  1 03:04:48 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 01 Mar 2021 08:04:48 +0000
Subject: [issue43349] [doc] incorrect tuning(7) manpage link
In-Reply-To: <1614583989.29.0.630028464305.issue43349@roundup.psfhosted.org>
Message-ID: <1614585888.71.0.498489270102.issue43349@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


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

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

From report at bugs.python.org  Mon Mar  1 04:52:49 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 01 Mar 2021 09:52:49 +0000
Subject: [issue43350] [sqlite3] Active statements are reset twice in
 _pysqlite_query_execute()
Message-ID: <1614592369.49.0.483199992415.issue43350@roundup.psfhosted.org>


New submission from Erlend Egeberg Aasland <erlend.aasland at innova.no>:

In _pysqlite_query_execute(), if the cursor already has a statement object, it is reset twice before the cache is queried.

----------
components: Library (Lib)
messages: 387850
nosy: berker.peksag, erlendaasland, serhiy.storchaka
priority: normal
severity: normal
status: open
title: [sqlite3] Active statements are reset twice in _pysqlite_query_execute()
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Mon Mar  1 04:54:16 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 01 Mar 2021 09:54:16 +0000
Subject: [issue43350] [sqlite3] Active statements are reset twice in
 _pysqlite_query_execute()
In-Reply-To: <1614592369.49.0.483199992415.issue43350@roundup.psfhosted.org>
Message-ID: <1614592456.45.0.134542075816.issue43350@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


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

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

From report at bugs.python.org  Mon Mar  1 05:26:57 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 01 Mar 2021 10:26:57 +0000
Subject: [issue43340] json.load() can raise UnicodeDecodeError,
 but this is not documented
In-Reply-To: <1614450261.52.0.147425024304.issue43340@roundup.psfhosted.org>
Message-ID: <1614594417.1.0.454800559263.issue43340@roundup.psfhosted.org>


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

json.loads() accepts also data encoded with UTF-16 and UTF-32.

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

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

From report at bugs.python.org  Mon Mar  1 05:47:12 2021
From: report at bugs.python.org (Andrew V. Jones)
Date: Mon, 01 Mar 2021 10:47:12 +0000
Subject: [issue43351] `RecursionError` during deallocation
Message-ID: <1614595632.86.0.935465611369.issue43351@roundup.psfhosted.org>


New submission from Andrew V. Jones <andrewvaughanj at gmail.com>:

I am currently working with "porting" some code from Python 2.7.14 to Python 3.7.5, but the process running the Python code seems to terminate in the following way:

```
#0  0x00002aaaaef63337 in raise () from /lib64/libc.so.6
#1  0x00002aaaaef64a28 in abort () from /lib64/libc.so.6
#2  0x00002aaaae726e18 in fatal_error (prefix=0x0, msg=0x2aaaae8091f0 "Cannot recover from stack overflow.", status=-1) at Python/pylifecycle.c:2187
#3  0x00002aaaae727603 in Py_FatalError (msg=0x9bf0 <Address 0x9bf0 out of bounds>) at Python/pylifecycle.c:2197
#4  0x00002aaaae6ede2b in _Py_CheckRecursiveCall (where=<optimized out>) at Python/ceval.c:489
#5  0x00002aaaae62b61d in _PyMethodDef_RawFastCallDict (method=0x2aaaaeae2740 <textiowrapper_methods+160>, self=0x2aaabb1d4d70, args=0x0, nargs=0, kwargs=0x0) at Objects/call.c:464
#6  0x00002aaaae62b6a9 in _PyCFunction_FastCallDict (func=0x2aaabeaa5690, args=0x6, nargs=0, kwargs=0x0) at Objects/call.c:586
#7  0x00002aaaae62c56c in _PyObject_CallFunctionVa (callable=0x9bf0, format=<optimized out>, va=<optimized out>, is_size_t=<optimized out>) at Objects/call.c:935
#8  0x00002aaaae62cc80 in callmethod (is_size_t=<optimized out>, va=<optimized out>, format=<optimized out>, callable=<optimized out>) at Objects/call.c:1031
#9  _PyObject_CallMethodId (obj=<optimized out>, name=<optimized out>, format=0x0) at Objects/call.c:1100
#10 0x00002aaaae724c51 in flush_std_files () at Python/pylifecycle.c:1083
#11 0x00002aaaae72704f in fatal_error (prefix=0x0, msg=<optimized out>, status=-1) at Python/pylifecycle.c:2175
#12 0x00002aaaae727603 in Py_FatalError (msg=0x9bf0 <Address 0x9bf0 out of bounds>) at Python/pylifecycle.c:2197
#13 0x00002aaaae6ede2b in _Py_CheckRecursiveCall (where=<optimized out>) at Python/ceval.c:489
#14 0x00002aaaae62ba3d in _PyObject_FastCallDict (callable=0x2aaabeab8790, args=<optimized out>, nargs=<optimized out>, kwargs=0x0) at Objects/call.c:120
#15 0x00002aaaae62c2f0 in object_vacall (callable=0x2aaabeab8790, vargs=0x7ffffff54d40) at Objects/call.c:1202
#16 0x00002aaaae62c3fd in PyObject_CallFunctionObjArgs (callable=0x9bf0) at Objects/call.c:1267
#17 0x00002aaaae6c1bf0 in PyObject_ClearWeakRefs (object=<optimized out>) at Objects/weakrefobject.c:872
#18 0x00002aaaae4b26f6 in instance_dealloc () from /home/LOCAL/avj/build/vc21__90601_pyedg_improvements/vc/lib64/libboost_python37.so.1.69.0
#19 0x00002aaaae67c3e0 in subtype_dealloc (self=0x2aaabeab9e40) at Objects/typeobject.c:1176
#20 0x00002aaaae4ba63f in life_support_call () from /home/LOCAL/avj/build/vc21__90601_pyedg_improvements/vc/lib64/libboost_python37.so.1.69.0
#21 0x00002aaaae62b9c4 in _PyObject_FastCallDict (callable=0x2aaabeab87b0, args=<optimized out>, nargs=<optimized out>, kwargs=0x0) at Objects/call.c:125
#22 0x00002aaaae62c2f0 in object_vacall (callable=0x2aaabeab87b0, vargs=0x7ffffff54fd0) at Objects/call.c:1202
#23 0x00002aaaae62c3fd in PyObject_CallFunctionObjArgs (callable=0x9bf0) at Objects/call.c:1267
#24 0x00002aaaae6c1bf0 in PyObject_ClearWeakRefs (object=<optimized out>) at Objects/weakrefobject.c:872
#25 0x00002aaaae4b26f6 in instance_dealloc () from /home/LOCAL/avj/build/vc21__90601_pyedg_improvements/vc/lib64/libboost_python37.so.1.69.0
#26 0x00002aaaae67c3e0 in subtype_dealloc (self=0x2aaabeab9e90) at Objects/typeobject.c:1176
#27 0x00002aaaae4ba63f in life_support_call () from /home/LOCAL/avj/build/vc21__90601_pyedg_improvements/vc/lib64/libboost_python37.so.1.69.0
#28 0x00002aaaae62b9c4 in _PyObject_FastCallDict (callable=0x2aaabeab87d0, args=<optimized out>, nargs=<optimized out>, kwargs=0x0) at Objects/call.c:125
#29 0x00002aaaae62c2f0 in object_vacall (callable=0x2aaabeab87d0, vargs=0x7ffffff55260) at Objects/call.c:1202
#30 0x00002aaaae62c3fd in PyObject_CallFunctionObjArgs (callable=0x9bf0) at Objects/call.c:1267
#31 0x00002aaaae6c1bf0 in PyObject_ClearWeakRefs (object=<optimized out>) at Objects/weakrefobject.c:872
#32 0x00002aaaae4b26f6 in instance_dealloc () from /home/LOCAL/avj/build/vc21__90601_pyedg_improvements/vc/lib64/libboost_python37.so.1.69.0
#33 0x00002aaaae67c3e0 in subtype_dealloc (self=0x2aaabeab9ee0) at Objects/typeobject.c:1176
#34 0x00002aaaae4ba63f in life_support_call () from /home/LOCAL/avj/build/vc21__90601_pyedg_improvements/vc/lib64/libboost_python37.so.1.69.0
```

This is only the inner most 35 frames -- the actual back-trace is 7375 frames deep, and ends with:

```
#7358 0x00002aaaae4b26f6 in instance_dealloc () from /home/LOCAL/avj/build/vc21__90601_pyedg_improvements/vc/lib64/libboost_python37.so.1.69.0
#7359 0x00002aaaae67c3e0 in subtype_dealloc (self=0x2aaabeaefdf0) at Objects/typeobject.c:1176
#7360 0x00002aaaae6f2f46 in _PyEval_EvalFrameDefault (f=0x2aaabce48b30, throwflag=39920) at Python/ceval.c:1098
#7361 0x00002aaaae62a959 in function_code_fastcall (co=<optimized out>, args=0x7fffffffd088, nargs=1, globals=<optimized out>) at Objects/call.c:283
#7362 0x00002aaaae62ae44 in _PyFunction_FastCallDict (func=0x2aaabda07950, args=0x7fffffffd080, nargs=1, kwargs=0x0) at Objects/call.c:322
#7363 0x00002aaaae62bbea in _PyObject_Call_Prepend (callable=0x2aaabda07950, obj=0x2aaabea92590, args=0x2aaabb193050, kwargs=0x0) at Objects/call.c:908
#7364 0x00002aaaae62b9c4 in _PyObject_FastCallDict (callable=0x2aaabb253a50, args=<optimized out>, nargs=<optimized out>, kwargs=0x0) at Objects/call.c:125
#7365 0x00002aaaae62c677 in _PyObject_CallFunctionVa (callable=0x2aaabb253a50, format=<optimized out>, va=<optimized out>, is_size_t=<optimized out>) at Objects/call.c:956
#7366 0x00002aaaae62c93a in PyEval_CallFunction (callable=0x9bf0, format=0x9bf0 <Address 0x9bf0 out of bounds>, format at entry=0x2aaaaaedba92 "()") at Objects/call.c:998
#7367 0x00002aaaaae6ae16 in boost::python::call<boost::python::api::object> (callable=<optimized out>) at /home/BUILD64/lib/boost-1.69.0-py37/include/boost/python/call.hpp:56
#7368 0x00002aaaaae6ae5a in boost::python::api::object_operators<boost::python::api::proxy<boost::python::api::attribute_policies> >::operator() (this=<optimized out>) at /home/BUILD64/lib/boost-1.69.0-py37/include/boost/python/object_core.hpp:440
#7369 0x00002aaaabc8b287 in PyEDGInterface::py_backend (this=<optimized out>) at /home/Users/avj/vector/source/vc21__90601_pyedg_improvements/lib/libcommoncpp/src/PyEDGInterface.cpp:192
#7370 0x00002aaaabc8c136 in PyEDGInterface::backend () at /home/Users/avj/vector/source/vc21__90601_pyedg_improvements/lib/libcommoncpp/inc/PyEDGInterface.h:38
#7371 0x00000000004195b5 in back_end () at /home/Users/avj/vector/source/vc21__90601_pyedg_improvements/progs/pyedg/main.cpp:77
#7372 0x000000000050ab21 in cfe_main (argc=argc at entry=9, argv=argv at entry=0x7fffffffd6c8) at /home/Users/avj/vector/source/vc21__90601_pyedg_improvements/progs/edg/src/cfe.cpp:141
#7373 0x000000000050abda in edg_main (argc=argc at entry=9, argv=argv at entry=0x7fffffffd6c8) at /home/Users/avj/vector/source/vc21__90601_pyedg_improvements/progs/edg/src/cfe.cpp:202
#7374 0x0000000000419752 in main (argc=9, argv=0x7fffffffd6c8) at /home/Users/avj/vector/source/vc21__90601_pyedg_improvements/progs/pyedg/main.cpp:43
```

Where `progs/pyedg/main.cpp` is our `main` and uses an embedded Python interpreter (either 2.7.14 or 3.7.5).

The application actually terminates with printed to stderr:

```
Exception ignored in: <Boost.Python.life_support object at 0x2acf473c5d10>
RecursionError: maximum recursion depth exceeded while calling a Python object
Fatal Python error: Cannot recover from stack overflow.
```

The code that is running does not (itself) have any loops -- it simply walks a linked list (of length ~1400) returned via Boost Python. When moving to the next element of the list, the previous element should be "unreachable garbage" (indeed, inspecting gc.get_referrers/gc.get_referents gives 0).

I've attached the whole back-trace to this issue, and it seems like, when recursing, the `current` argument to `PyObject_ClearWeakRefs` is different (i.e., it doesn't seem to be an infinite recursion, just a very _deep_ recursion when deallocating).

Some other observations:

   1) If I increase the size of the stack (using `sys.setrecursionlimit` set to a "suitably large" value), then the process complete successfully

   2) The value of `ulimit -s` makes no difference

   3) If I run the same code, with the same Boost Python bindings, except targetting Python 2.7.14 the process completes successfully

Right now, I am not able to provide a simple reproducer, but I am wondering if this is a bug I've hit in Python 3.7.5 (maybe it is fixed by https://bugs.python.org/issue38006, which seems very similar) or if this is my "user code" that is doing something weird.

If this appears to be a new bug, I will do my utmost to create a reproducer for it, but if the cause is obvious without it, then that would be helpful (the reproducer is tied to a proprietary code, so will be hard to extricate).

One thing I will try is to update our version of Python to 3.9.2 and see the issue is still there, after the fix for #38006.

----------
files: python_bt.txt.gz
messages: 387852
nosy: andrewvaughanj
priority: normal
severity: normal
status: open
title: `RecursionError` during deallocation
versions: Python 3.7
Added file: https://bugs.python.org/file49841/python_bt.txt.gz

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

From report at bugs.python.org  Mon Mar  1 06:04:29 2021
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 01 Mar 2021 11:04:29 +0000
Subject: [issue43271] AMD64 Windows10 3.x crash with Windows fatal exception:
 stack overflow
In-Reply-To: <1613766414.64.0.363657915419.issue43271@roundup.psfhosted.org>
Message-ID: <1614596669.98.0.341591571313.issue43271@roundup.psfhosted.org>


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

PEP 651 would prevent any crashes, although some of the tests might still fail with a StackOverflowException, if they weren't expecting a RecursionError.

----------

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

From report at bugs.python.org  Mon Mar  1 06:18:43 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 01 Mar 2021 11:18:43 +0000
Subject: [issue11717] conflicting definition of ssize_t in pyconfig.h
In-Reply-To: <1301443864.94.0.799403342642.issue11717@psf.upfronthosting.co.za>
Message-ID: <1614597523.18.0.331173863999.issue11717@roundup.psfhosted.org>


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


New changeset c994ffe69553cbb34f1cea6a4494d6e7657f41b0 by Jozef Grajciar in branch 'master':
bpo-11717: fix ssize_t redefinition error when targeting 32bit Windows app (GH-24479)
https://github.com/python/cpython/commit/c994ffe69553cbb34f1cea6a4494d6e7657f41b0


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

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

From report at bugs.python.org  Mon Mar  1 06:19:01 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 01 Mar 2021 11:19:01 +0000
Subject: [issue11717] conflicting definition of ssize_t in pyconfig.h
In-Reply-To: <1301443864.94.0.799403342642.issue11717@psf.upfronthosting.co.za>
Message-ID: <1614597541.91.0.368967082886.issue11717@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/issue11717>
_______________________________________

From report at bugs.python.org  Mon Mar  1 06:22:03 2021
From: report at bugs.python.org (Julien Castiaux)
Date: Mon, 01 Mar 2021 11:22:03 +0000
Subject: [issue43330] xmlrpc.Server URI query and fragment are discarded from
 HTTP query since py3
In-Reply-To: <1614358939.96.0.184711772416.issue43330@roundup.psfhosted.org>
Message-ID: <1614597723.9.0.353511393656.issue43330@roundup.psfhosted.org>


Change by Julien Castiaux <julien.castiaux at gmail.com>:


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

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

From report at bugs.python.org  Mon Mar  1 06:39:56 2021
From: report at bugs.python.org (Yves Duprat)
Date: Mon, 01 Mar 2021 11:39:56 +0000
Subject: [issue43352] Add a Barrier object in asyncio lib
Message-ID: <1614598796.36.0.0905111746151.issue43352@roundup.psfhosted.org>


New submission from Yves Duprat <yduprat at gmail.com>:

Add a synchronized primitive Barrier in asyncio, in order to be consistent with them we have for threading.

Barrier object will have a similar design from that of threading lib.
(May be we have to think about a backport ?)


Initial discussion started here: https://mail.python.org/archives/list/python-ideas at python.org/thread/IAFAH7PWMUDUTLXYLNSXES7VMDQ26A3W/

----------
components: asyncio
messages: 387855
nosy: asvetlov, yduprat, yselivanov
priority: normal
severity: normal
status: open
title: Add a Barrier object in asyncio lib
type: enhancement
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Mar  1 07:00:00 2021
From: report at bugs.python.org (Mariusz Felisiak)
Date: Mon, 01 Mar 2021 12:00:00 +0000
Subject: [issue43353] Document that logging.getLevelName() can return a
 numeric value.
Message-ID: <1614600000.66.0.180359096956.issue43353@roundup.psfhosted.org>


New submission from Mariusz Felisiak <felisiak.mariusz at gmail.com>:

Can we document[1] that `logging.getLevelName()` returns a numeric value when corresponding string is passed in (related with https://bugs.python.org/issue1008295). I know that we have "Changed in version 3.4" annotation but I think it's worth mentioning in the main description.

I hope it's not a duplicate, I tried to find matching ticket. 

I can submit PR if accepted.

[1] https://docs.python.org/3.10/library/logging.html?highlight=getlevelname#logging.getLevelName

----------
components: Library (Lib)
messages: 387856
nosy: felixxm, vinay.sajip
priority: normal
severity: normal
status: open
title: Document that logging.getLevelName() can return a numeric value.

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

From report at bugs.python.org  Mon Mar  1 07:00:27 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 01 Mar 2021 12:00:27 +0000
Subject: [issue43342] Error while using Python C API
In-Reply-To: <1614452939.17.0.0398730160049.issue43342@roundup.psfhosted.org>
Message-ID: <1614600027.72.0.718786712434.issue43342@roundup.psfhosted.org>


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

You're going to get more help by posting your question elsewhere. This isn't a forum where we can help you debug your code: it's for reporting bugs in Python.

You might try https://discuss.python.org/c/users/, or maybe the python-list mailing list.

Good luck!

----------
nosy: +eric.smith
status: open -> pending

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

From report at bugs.python.org  Mon Mar  1 07:15:06 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 01 Mar 2021 12:15:06 +0000
Subject: [issue43350] [sqlite3] Active statements are reset twice in
 _pysqlite_query_execute()
In-Reply-To: <1614592369.49.0.483199992415.issue43350@roundup.psfhosted.org>
Message-ID: <1614600906.35.0.225535353108.issue43350@roundup.psfhosted.org>


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

There are three calls of pysqlite_statement_reset() in _pysqlite_query_execute(). And all three of them can be called with the same statement object. But repeated calls are no-ops because pysqlite_statement_reset() clears flag in_use and calls sqlite3_reset() only if it was set before. So additional call of pysqlite_statement_reset() does not harm. You can call it as many times as you want. On other hand removing it can introduce race condition.

Maybe the code could be rewritten in more explicit way and call pysqlite_statement_reset() only when it is necessary, but for now I don't think that just removing one call will make the code better.

----------

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

From report at bugs.python.org  Mon Mar  1 07:38:31 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 01 Mar 2021 12:38:31 +0000
Subject: [issue43350] [sqlite3] Active statements are reset twice in
 _pysqlite_query_execute()
In-Reply-To: <1614592369.49.0.483199992415.issue43350@roundup.psfhosted.org>
Message-ID: <1614602311.06.0.658123980375.issue43350@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

> There are three calls of pysqlite_statement_reset() in _pysqlite_query_execute()

Yes, but only two before the cache is queried.

> So additional call of pysqlite_statement_reset() does not harm.

That's true, but removing redundant code makes it easier to read and maintain, IMO.

> On other hand removing it can introduce race condition.

How?

> Maybe the code could be rewritten in more explicit way and call pysqlite_statement_reset() only when it is necessary

Most of _pysqlite_query_execute() could be rewritten in order to make the code clearer. An alternative is to clean it up part by part.

----------

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

From report at bugs.python.org  Mon Mar  1 07:38:35 2021
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 01 Mar 2021 12:38:35 +0000
Subject: [issue31447] proc communicate not exiting on python subprocess
 timeout using PIPES
In-Reply-To: <1505297487.8.0.0553413859223.issue31447@psf.upfronthosting.co.za>
Message-ID: <1614602315.18.0.658589294541.issue31447@roundup.psfhosted.org>


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

I'm changing this to a documentation issue and removing the Windows component. The documentation doesn't make it clear that communicate() may block indefinitely (in both POSIX and Windows) even after the process has terminated. As currently implemented, this claim and the example need to be corrected. 

Depending on one's needs, the Popen() instance can be used as context manager to ensure that communication is finalized (e.g. in Windows, the synchronous reads in worker threads need to be canceled) and that the pipes are closed -- presuming you don't need to read more data after the timeout. If issue 43346 is resolved as suggested, then the following will work without blocking indefinitely in the second communicate() call:

    proc = subprocess.Popen(...)
    try:
        out, err = proc.communicate(timeout=15)
    except subprocess.TimeoutExpired:
        with proc:
            proc.kill()
        out, err = proc.communicate()

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

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

From report at bugs.python.org  Mon Mar  1 08:02:07 2021
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 01 Mar 2021 13:02:07 +0000
Subject: [issue33105] os.path.isfile returns false on Windows when file path
 is longer than 260 characters
In-Reply-To: <1521484111.52.0.467229070634.issue33105@psf.upfronthosting.co.za>
Message-ID: <1614603727.4.0.324400942003.issue33105@roundup.psfhosted.org>


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

I'm closing this as not a bug. If the process limits DOS paths to MAX_PATH, then checking os.path.isfile() should not be special cased to support longer DOS paths because calling open() on such a path will raise FileNotFoundError. My suggestion in msg314126 to have stat() fall back on querying the directory in this case is too magical, even if it does make os.stat() more consistent with os.listdir() and the stat result from os.scandir().

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

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

From report at bugs.python.org  Mon Mar  1 08:08:49 2021
From: report at bugs.python.org (Andrew V. Jones)
Date: Mon, 01 Mar 2021 13:08:49 +0000
Subject: [issue43351] `RecursionError` during deallocation
In-Reply-To: <1614595632.86.0.935465611369.issue43351@roundup.psfhosted.org>
Message-ID: <1614604129.67.0.509570596366.issue43351@roundup.psfhosted.org>


Andrew V. Jones <andrewvaughanj at gmail.com> added the comment:

Here's some representative code that triggers the issue:

```
def loop():
    a_node = boost_python_library.get_linked_list()
    all_elems = []
    while a_node is not None:
        #
        # Uncomment the below to make the crash disappear
        #
        # all_elems.append(a_node)
        #
        a_node = a_node.next
```

The *really* interesting bit is that if we save what comes off the Boost.Python linked list into a Python-proper list (`all_elems` as above), then the crash goes away.

----------

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

From report at bugs.python.org  Mon Mar  1 08:25:57 2021
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 01 Mar 2021 13:25:57 +0000
Subject: [issue14597] Cannot unload dll in ctypes until script exits
In-Reply-To: <1334581773.77.0.209505875468.issue14597@psf.upfronthosting.co.za>
Message-ID: <1614605157.3.0.122229410837.issue14597@roundup.psfhosted.org>


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

Automatically decrementing the reference count of a shared library (e.g. via WinAPI FreeLibrary or POSIX dlclose) when a CDLL instance is finalized would require significant design changes to ensure that all ctypes pointers, scalars, and aggregates that reference memory in the DLL also always reference the CDLL instance in their _objects attribute. I don't think this feature request is worth the work that involves, or the risk of crashing if some case is overlooked in the implementation. Nothing prevents a script from implementing this manually on a case by case basis.

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

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

From report at bugs.python.org  Mon Mar  1 08:33:50 2021
From: report at bugs.python.org (Andrew V. Jones)
Date: Mon, 01 Mar 2021 13:33:50 +0000
Subject: [issue43351] `RecursionError` during deallocation
In-Reply-To: <1614595632.86.0.935465611369.issue43351@roundup.psfhosted.org>
Message-ID: <1614605630.72.0.70353352935.issue43351@roundup.psfhosted.org>


Andrew V. Jones <andrewvaughanj at gmail.com> added the comment:

Same logic, but this crashes:

```
def loop():
    a_node = boost_python_library.get_linked_list()
    temp = []
    while True:
        assert a_node is not None
        temp.append(a_node)
        prev = a_node   # <-- comment this out to make the crash go away
        a_node = a_node.next
        if not a_node:
            break
```

----------

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

From report at bugs.python.org  Mon Mar  1 08:35:28 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 01 Mar 2021 13:35:28 +0000
Subject: [issue43350] [sqlite3] Active statements are reset twice in
 _pysqlite_query_execute()
In-Reply-To: <1614592369.49.0.483199992415.issue43350@roundup.psfhosted.org>
Message-ID: <1614605728.7.0.174838736831.issue43350@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

Hm, I guess we could use sqlite3_stmt_busy() instead of the in_use flag.

----------

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

From report at bugs.python.org  Mon Mar  1 08:42:31 2021
From: report at bugs.python.org (=?utf-8?q?J=C3=BCrgen_Gmach?=)
Date: Mon, 01 Mar 2021 13:42:31 +0000
Subject: [issue43354] xmlrpc.client: Fault.faultCode erroneously documented to
 be a string, should be int
Message-ID: <1614606151.94.0.783784524766.issue43354@roundup.psfhosted.org>


New submission from J?rgen Gmach <juergen.gmach at googlemail.com>:

I created a XMLRPC API (via Zope), which gets consumed by a C# application.

C#'s XMLRPC lib expects an `int` for the `faultCode` but I currently return a string, as this is the type which is currently documented in the official docs
https://docs.python.org/3/library/xmlrpc.client.html#xmlrpc.client.Fault.faultCode

This leads to a `TypeMismatch` error on the client's side.


The documentation for `faultCode` is pretty much unchanged since 2007, when `xmlrpc.client.rst` was first created (at least at that place) by Georg Brandl. The docs are most probably older, but I do not know where they were managed before.

I had a look at the cpython source code, and at least the tests all use ints for `faultCode` (both of them :-) )

eg https://github.com/python/cpython/blob/255f53bdb54a64b93035374ca4484ba0cc1b41e1/Lib/test/test_xmlrpc.py#L166

Having a look at the XMLRPC spec at http://xmlrpc.com/spec.md it is clearly shown that `faultCode` has to be an int.

Typeshed recently added type hints for xmlrpc lib, and they used string for `faultCode` - but I guess this is just an aftereffect from the faulty documentation.
https://github.com/python/typeshed/pull/3834

I suggest to both update cpython's documentation and to create a PR for typeshed in order to fix the type issue.

If any core dev agrees on this, I'd like to prepare the pull requests.

Thanks for taking your time to look into this!

----------
assignee: docs at python
components: Documentation
messages: 387866
nosy: docs at python, jugmac00
priority: normal
severity: normal
status: open
title: xmlrpc.client: Fault.faultCode erroneously documented to be a string, should be int
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Mar  1 08:47:24 2021
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 01 Mar 2021 13:47:24 +0000
Subject: [issue33245] Unable to send CTRL_BREAK_EVENT
In-Reply-To: <1523245650.34.0.682650639539.issue33245@psf.upfronthosting.co.za>
Message-ID: <1614606444.63.0.708149589919.issue33245@roundup.psfhosted.org>


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


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Windows: SystemError during os.kill(..., signal.CTRL_C_EVENT)

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

From report at bugs.python.org  Mon Mar  1 09:16:58 2021
From: report at bugs.python.org (Tim Magee)
Date: Mon, 01 Mar 2021 14:16:58 +0000
Subject: [issue43348] XMLRPC behaves strangely under pythonw, not under python
In-Reply-To: <1614572178.19.0.35807455239.issue43348@roundup.psfhosted.org>
Message-ID: <1614608218.07.0.0118000668232.issue43348@roundup.psfhosted.org>


Tim Magee <python-ir at qkhx.uk> added the comment:

Fragment more info.  First a typo in the description, at the end of the MTR "unexpected connection" should read "unexpected disconnection" of course (no-one expects the unexpected connection ho ho).

Looking at calls to socket functions, Procmon shows the client repeating the call to a server running in pythonw.exe. It seems as though the client is instigating the badness, but...

In a Wireshark capture each of the two sessions the client holds with that 'bad' server is identical, and the difference between each of those and the 'good' session (with the server in python.exe) is that the server under pythonw doesn't return a methodResponse packet, but instead begins tearing down the connection.  Which is what the exception message says, but it's still startling to see it actually happening.

I'll have a squint at the source.

----------

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

From report at bugs.python.org  Mon Mar  1 09:37:29 2021
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 01 Mar 2021 14:37:29 +0000
Subject: [issue34064] subprocess functions with shell=1 pass wrong command to
 win32 shell
In-Reply-To: <1530959407.22.0.56676864532.issue34064@psf.upfronthosting.co.za>
Message-ID: <1614609449.23.0.643691928875.issue34064@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Mon Mar  1 09:44:57 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 01 Mar 2021 14:44:57 +0000
Subject: [issue43349] [doc] incorrect tuning(7) manpage link
In-Reply-To: <1614583989.29.0.630028464305.issue43349@roundup.psfhosted.org>
Message-ID: <1614609897.15.0.320741598347.issue43349@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: +23468
pull_request: https://github.com/python/cpython/pull/24684

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

From report at bugs.python.org  Mon Mar  1 09:45:04 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 01 Mar 2021 14:45:04 +0000
Subject: [issue43349] [doc] incorrect tuning(7) manpage link
In-Reply-To: <1614583989.29.0.630028464305.issue43349@roundup.psfhosted.org>
Message-ID: <1614609904.85.0.800647830942.issue43349@roundup.psfhosted.org>


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


----------
pull_requests: +23469
pull_request: https://github.com/python/cpython/pull/24685

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

From report at bugs.python.org  Mon Mar  1 09:45:07 2021
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 01 Mar 2021 14:45:07 +0000
Subject: [issue43349] [doc] incorrect tuning(7) manpage link
In-Reply-To: <1614583989.29.0.630028464305.issue43349@roundup.psfhosted.org>
Message-ID: <1614609907.83.0.671191824668.issue43349@roundup.psfhosted.org>


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


New changeset f4d7d46cb48aa3a1bf3c2c7e2d7d71cbf49dea69 by Erlend Egeberg Aasland in branch 'master':
closes bpo-43349: Fix tuning(7) manpage hyperlink. (GH-24680)
https://github.com/python/cpython/commit/f4d7d46cb48aa3a1bf3c2c7e2d7d71cbf49dea69


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Mar  1 09:54:39 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 01 Mar 2021 14:54:39 +0000
Subject: [issue43349] [doc] incorrect tuning(7) manpage link
In-Reply-To: <1614583989.29.0.630028464305.issue43349@roundup.psfhosted.org>
Message-ID: <1614610479.35.0.982584496575.issue43349@roundup.psfhosted.org>


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


New changeset 643939a07e480ed88a6eca9793157f1c695a418e by Miss Islington (bot) in branch '3.8':
closes bpo-43349: Fix tuning(7) manpage hyperlink. (GH-24680)
https://github.com/python/cpython/commit/643939a07e480ed88a6eca9793157f1c695a418e


----------

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

From report at bugs.python.org  Mon Mar  1 10:13:27 2021
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 01 Mar 2021 15:13:27 +0000
Subject: [issue43344] RotatingFileHandler breaks file type associations
In-Reply-To: <1614465857.24.0.529577943251.issue43344@roundup.psfhosted.org>
Message-ID: <1614611607.82.0.732318865366.issue43344@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

As per the documentation at

https://docs.python.org/3/library/logging.handlers.html#logging.handlers.BaseRotatingHandler.namer

You can set the handler's "namer" attribute to a callable that returns a computed name for the rotated file - this can be computed as per your requirements. The cookbook also has an entry about this:

https://docs.python.org/3/howto/logging-cookbook.html#using-a-rotator-and-namer-to-customize-log-rotation-processing

----------

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

From report at bugs.python.org  Mon Mar  1 10:16:28 2021
From: report at bugs.python.org (Piyush Patel)
Date: Mon, 01 Mar 2021 15:16:28 +0000
Subject: [issue43342] Error while using Python C API
In-Reply-To: <1614452939.17.0.0398730160049.issue43342@roundup.psfhosted.org>
Message-ID: <1614611788.48.0.229950722367.issue43342@roundup.psfhosted.org>


Piyush Patel <piyush.428ec at gmail.com> added the comment:

Hi 

Thanks for your time.

Just wanted to add that earlier I used

PyImport_AddModule(""__main__").

but now I used PyImport_ImportModule(""__main__") 

resolved the issue for me regardless of installation path it worked.

Thanks 
Piyush

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

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

From report at bugs.python.org  Mon Mar  1 10:17:05 2021
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 01 Mar 2021 15:17:05 +0000
Subject: [issue43353] Document that logging.getLevelName() can return a
 numeric value.
In-Reply-To: <1614600000.66.0.180359096956.issue43353@roundup.psfhosted.org>
Message-ID: <1614611825.62.0.45775547172.issue43353@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Sure, I'll look at a PR that mentions the other usage above the "changed in 3.4" section.

----------

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

From report at bugs.python.org  Mon Mar  1 10:24:56 2021
From: report at bugs.python.org (Paul Ganssle)
Date: Mon, 01 Mar 2021 15:24:56 +0000
Subject: [issue43354] xmlrpc.client: Fault.faultCode erroneously documented to
 be a string, should be int
In-Reply-To: <1614606151.94.0.783784524766.issue43354@roundup.psfhosted.org>
Message-ID: <1614612296.23.0.979123143238.issue43354@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

The evidence you have here seems pretty compelling and this change seems straightforward enough. I don't see an expert listed here, but I'm happy to merge a docs PR fixing this.

Probably a good idea to make a PR to typeshed in parallel, in case they have some further insight into this.

----------
nosy: +p-ganssle

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

From report at bugs.python.org  Mon Mar  1 10:27:31 2021
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 01 Mar 2021 15:27:31 +0000
Subject: [issue8036] raise ValueError for empty `path` in os.spawnv[e]
In-Reply-To: <1267477949.48.0.216202239381.issue8036@psf.upfronthosting.co.za>
Message-ID: <1614612451.04.0.954090822562.issue8036@roundup.psfhosted.org>


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

The internal spawn function in ucrt, common_spawnv(), verifies its parameters as follows:

    _VALIDATE_RETURN(file_name       != nullptr, EINVAL, -1);
    _VALIDATE_RETURN(file_name[0]    != '\0',    EINVAL, -1);
    _VALIDATE_RETURN(arguments       != nullptr, EINVAL, -1);
    _VALIDATE_RETURN(arguments[0]    != nullptr, EINVAL, -1);
    _VALIDATE_RETURN(arguments[0][0] != '\0',    EINVAL, -1);

Currently os.spawnv() and os.spawnve() check for and raise ValueError for all of these cases except the second one, in which file_name is an empty string. Microsoft doesn't document this case [1]:

    These functions validate their parameters. If either cmdname or argv 
    is a null pointer, or if argv points to null pointer, or argv[0] is 
    an empty string, the invalid parameter handler is invoked, as 
    described in Parameter Validation.

In a release build, this case fails with EINVAL. In a debug build, the default error-reporting settings display a pop message about the invalid argument. The message box is easy enough to suppress. But for the sake of consistency with the other cases, os_spawnv_impl in Modules/posixmodule.c should raise a ValueError if `path` is an empty string. For example:

    #ifdef HAVE_WSPAWNV
        if (!path->wide[0]) {
            PyErr_SetString(PyExc_ValueError,
                "spawnv() arg 1 cannot be an empty string");
            return NULL;
        }
    #endif

---
[1] https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/spawnv-wspawnv

----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
priority: high -> normal
title: Interpreter crashes on invalid arg to spawnl on Windows -> raise ValueError for empty `path` in os.spawnv[e]
type: crash -> behavior
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Mar  1 10:32:00 2021
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 01 Mar 2021 15:32:00 +0000
Subject: [issue18597] On Windows sys.stdin.readline() doesn't handle Ctrl-C
 properly
In-Reply-To: <1375175592.24.0.539816782076.issue18597@psf.upfronthosting.co.za>
Message-ID: <1614612720.18.0.902727011116.issue18597@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Mon Mar  1 10:34:30 2021
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 01 Mar 2021 15:34:30 +0000
Subject: [issue19050] [Windows] fflush called on pointer to potentially closed
 file
In-Reply-To: <1379595509.08.0.968867256316.issue19050@psf.upfronthosting.co.za>
Message-ID: <1614612870.24.0.879685041286.issue19050@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Mon Mar  1 10:37:34 2021
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 01 Mar 2021 15:37:34 +0000
Subject: [issue33515] subprocess.Popen on a Windows batch file always acts as
 if shell=True
In-Reply-To: <1526382091.26.0.682650639539.issue33515@psf.upfronthosting.co.za>
Message-ID: <1614613054.65.0.850480533412.issue33515@roundup.psfhosted.org>


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


----------
stage: patch review -> 
versions: +Python 3.10, Python 3.9 -Python 2.7, Python 3.6, Python 3.7

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

From report at bugs.python.org  Mon Mar  1 11:02:00 2021
From: report at bugs.python.org (Eric Engestrom)
Date: Mon, 01 Mar 2021 16:02:00 +0000
Subject: [issue43355] __future__.annotations breaks inspect.signature()
Message-ID: <1614614520.28.0.353733927276.issue43355@roundup.psfhosted.org>


New submission from Eric Engestrom <eric.engestrom at gmail.com>:

We have a pytest that boils down to the following:

```
#from __future__ import annotations
from inspect import Parameter, signature


def foo(x: str) -> str:
    return x + x


def test_foo():
    expected = (
        Parameter("x", Parameter.POSITIONAL_OR_KEYWORD, annotation=str),
    )

    actual = tuple(signature(foo).parameters.values())

    assert expected == actual
```

(execute with `pip install pytest && pytest -vv test_foo.py`)

I tried importing 3.10 annotations (so that we can get rid of quotes around the class containing `foo()`, which is omitted here because it isn't necessary to reproduce the bug), but doing so changes the output of `inspect.signature()` but not the output `inspect.Parameter()`, causing a mismatch between the two that breaks the test.

The above passes on 3.7.9, 3.8.7 & 3.9.1, and if I uncomment the first line, it fails on those same versions.
As can be expected, the annotations import is a no-op on 3.10.0a5 and the test passes either way.

I expect `inspect` might have not been correctly updated to support postponed annotations, but I haven't looked at the implementation (I'm not familiar with the CPython codebase at all) so it's just a guess.

----------
components: Library (Lib)
messages: 387875
nosy: 1ace
priority: normal
severity: normal
status: open
title: __future__.annotations breaks inspect.signature()
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Mar  1 11:06:50 2021
From: report at bugs.python.org (Tim Magee)
Date: Mon, 01 Mar 2021 16:06:50 +0000
Subject: [issue43348] XMLRPC behaves strangely under pythonw, not under python
In-Reply-To: <1614572178.19.0.35807455239.issue43348@roundup.psfhosted.org>
Message-ID: <1614614810.34.0.707081949692.issue43348@roundup.psfhosted.org>


Tim Magee <python-ir at qkhx.uk> added the comment:

After a peep at the source I theorised that using logRequests=False when constructing the base class, SimpleXMLRPCServer. would see me right, and so it did.

When logRequests is True control ultimately passes to BaseHTTPRequestHandler.log_message which is a write to sys.stderr, meaning the code is unsuitable for running under pythonw.

This might be a special sort of https://bugs.python.org/issue38533 -- special because the code that offends pythonw is in the library.

Anyhow, now I know what the problem is I can work round it, and I'll leave it to you what to do with the ticket.

----------

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

From report at bugs.python.org  Mon Mar  1 11:47:09 2021
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 01 Mar 2021 16:47:09 +0000
Subject: [issue43284] Wrong windows build in 20H2
In-Reply-To: <1613904146.72.0.850542213327.issue43284@roundup.psfhosted.org>
Message-ID: <1614617229.29.0.0185314484745.issue43284@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/issue43284>
_______________________________________

From report at bugs.python.org  Mon Mar  1 12:20:53 2021
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 01 Mar 2021 17:20:53 +0000
Subject: [issue43354] xmlrpc.client: Fault.faultCode erroneously documented to
 be a string, should be int
In-Reply-To: <1614606151.94.0.783784524766.issue43354@roundup.psfhosted.org>
Message-ID: <1614619253.7.0.149912559197.issue43354@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/issue43354>
_______________________________________

From report at bugs.python.org  Mon Mar  1 12:41:48 2021
From: report at bugs.python.org (hai shi)
Date: Mon, 01 Mar 2021 17:41:48 +0000
Subject: [issue43244] Move PyArena C API to the internal C API
In-Reply-To: <1613586690.19.0.383646964758.issue43244@roundup.psfhosted.org>
Message-ID: <1614620508.81.0.401660697453.issue43244@roundup.psfhosted.org>


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


----------
keywords: +patch
nosy: +shihai1991
nosy_count: 1.0 -> 2.0
pull_requests: +23470
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24688

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

From report at bugs.python.org  Mon Mar  1 12:55:28 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Mar 2021 17:55:28 +0000
Subject: [issue43356] PyErr_SetInterrupt should have an equivalent that takes
 a signal number
Message-ID: <1614621328.26.0.486134499262.issue43356@roundup.psfhosted.org>


New submission from Antoine Pitrou <pitrou at free.fr>:

PyErr_SetInterrupt() is useful if you want to simulate the effect of a SIGINT.
It would be helpful to provide a similar primitive for other signal numbers, e.g. `PyErr_SetInterruptEx(int signum)`.

----------
components: C API
messages: 387877
nosy: pitrou
priority: normal
severity: normal
status: open
title: PyErr_SetInterrupt should have an equivalent that takes a signal number
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Tue Mar  2 13:43:45 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 02 Mar 2021 18:43:45 +0000
Subject: [issue43315] Decimal.__str__ has no way to force exact decimal
 representation
In-Reply-To: <1614164388.53.0.057673280167.issue43315@roundup.psfhosted.org>
Message-ID: <1614710625.81.0.524449307547.issue43315@roundup.psfhosted.org>


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

Closing here; the built-in formatting should be sufficient, as discussed.

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

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

From report at bugs.python.org  Tue Mar  2 15:39:17 2021
From: report at bugs.python.org (Neil Schemenauer)
Date: Tue, 02 Mar 2021 20:39:17 +0000
Subject: [issue42212] Check if generated files are up-to-date in Github Actions
In-Reply-To: <1604078604.78.0.892502447015.issue42212@roundup.psfhosted.org>
Message-ID: <1614717557.99.0.833527381105.issue42212@roundup.psfhosted.org>


Change by Neil Schemenauer <nas-python at arctrix.com>:


----------
nosy: +nascheme
nosy_count: 3.0 -> 4.0
pull_requests: +23486
pull_request: https://github.com/python/cpython/pull/24708

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

From report at bugs.python.org  Tue Mar  2 07:40:42 2021
From: report at bugs.python.org (John Belmonte)
Date: Tue, 02 Mar 2021 12:40:42 +0000
Subject: [issue43370] thread_time not available on python.org OS X builds
Message-ID: <1614688842.62.0.631384615998.issue43370@roundup.psfhosted.org>


New submission from John Belmonte <john at neggie.net>:

time.thread_time is supposed to be available on OS X 10.12 and newer.

Yet it's reported to raise ImportError on macOS Big Sur (11.2.1) on Python 3.9.2 (python.org download).  (Reported by Quentin Pradet.)

It is available in other OS X Python builds, such as published by Home Brew.  (I confirm it's available on macOS 10.13, Python 3.7.7.)

----------
components: Build
messages: 387925
nosy: John Belmonte
priority: normal
severity: normal
status: open
title: thread_time not available on python.org OS X builds
type: behavior

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

From report at bugs.python.org  Tue Mar  2 14:43:33 2021
From: report at bugs.python.org (Neil Schemenauer)
Date: Tue, 02 Mar 2021 19:43:33 +0000
Subject: [issue43372] ctypes: test_frozentable fails when make regen-frozen
In-Reply-To: <1614696034.15.0.923342699637.issue43372@roundup.psfhosted.org>
Message-ID: <1614714213.15.0.911401876104.issue43372@roundup.psfhosted.org>


Neil Schemenauer <nas-python at arctrix.com> added the comment:

I believe the line table format got changed but the frozen code didn't get re-generated.  If you try to call co_lines() on the __hello__ code, Python crashes.

>>> import __hello__
Hello world!
>>> co = __hello__.__spec__.loader.get_code('__hello__')
>>> co.co_linetable
b'\x04\x01'
>>> list(co.co_lines())
python: ../Objects/codeobject.c:1185: PyLineTable_NextAddressRange: Assertion `!at_end(range)' failed.

My PR re-generates the code and fixes the test.  Perhaps I should also add a test to exercise co_lines() on the frozen code object.

----------

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

From report at bugs.python.org  Tue Mar  2 14:44:03 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Mar 2021 19:44:03 +0000
Subject: [issue43060] Convert _decimal C API from pointer array to struct
In-Reply-To: <1611913613.83.0.451385849535.issue43060@roundup.psfhosted.org>
Message-ID: <1614714243.14.0.196043771417.issue43060@roundup.psfhosted.org>


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

I have no opinion about *adding* a struct, but we shouldn't remove the existing array of pointers, or this will needlessly break compatibility for existing users of the C API.

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

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

From report at bugs.python.org  Tue Mar  2 15:42:17 2021
From: report at bugs.python.org (Maxime Belanger)
Date: Tue, 02 Mar 2021 20:42:17 +0000
Subject: [issue43377] _PyErr_Display should be available in the
 CPython-specific API
Message-ID: <1614717737.06.0.355391552087.issue43377@roundup.psfhosted.org>


New submission from Maxime Belanger <max at dropbox.com>:

We have found `_PyErr_Display` to be quite helpful in embedding situations, in particular as a way to capture errors to a custom buffer rather than to `stderr`. Otherwise, embedders often have to replicate logic in `PyErr_Print`, etc. 

Since the header restructuring in Python 3.8+, that function is a bit harder to call. It's exported, but is considered "internal" and thus requires defining `Py_BUILD_CORE`.

I was wondering: why not expose it under "Include/cpython"? It seems like a generic-enough helper, similar to `_PyErr_WriteUnraisableMsg`.

----------
components: C API
messages: 387965
nosy: Maxime Belanger
priority: normal
severity: normal
status: open
title: _PyErr_Display should be available in the CPython-specific API
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Tue Mar  2 15:18:17 2021
From: report at bugs.python.org (Kevin Hollingshead)
Date: Tue, 02 Mar 2021 20:18:17 +0000
Subject: [issue43344] RotatingFileHandler breaks file type associations
In-Reply-To: <1614715715.39.0.890737175443.issue43344@roundup.psfhosted.org>
Message-ID: <CAAFLtXrymMDXXW5RofzLjBwGhZGR-FyOzcrT9UbJywRoF4btRw@mail.gmail.com>


Kevin Hollingshead <kh14821 at gmail.com> added the comment:

Sure. Thanks for your help.

On Tue, Mar 2, 2021, 1:08 PM Vinay Sajip <report at bugs.python.org> wrote:

>
> Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:
>
> I'll add to the cookbook recipe with this real-world example, when I get a
> chance.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue43344>
> _______________________________________
>

----------

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

From report at bugs.python.org  Tue Mar  2 15:43:45 2021
From: report at bugs.python.org (David Bolen)
Date: Tue, 02 Mar 2021 20:43:45 +0000
Subject: [issue43271] AMD64 Windows10 3.x crash with Windows fatal exception:
 stack overflow
In-Reply-To: <1613766414.64.0.363657915419.issue43271@roundup.psfhosted.org>
Message-ID: <1614717825.63.0.0586057142556.issue43271@roundup.psfhosted.org>


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

Steve, where is that configured?  If reducing that further would resolve the crashes while retaining ceval debugging, maybe that's a reasonable trade-off, though based on my testing, reverting still seems simpler.

Right now the debug build on the buildbot appears use the standard recursion limit of 1000, and some quick grep-fu didn't find a clear spot (either internally or just for the tests) where it would be reduced.  Could perhaps how it's done be something that doesn't influence buildbot builds?

The failing tests do all appear to be recursion tests of one form or another.  Based on further testing, we'd need to have a recursion limit of 290 or below to get most of the test suite to pass.  Presumably something like 250 for a bit of head room.

However, lowering the limit appears to cover only most of the failures, not all.  Some tests directly play with the limits (like test_exceptions.test_recursion_in_except_handler and test_sys.test_recursionlimit_recovery) and still get into trouble, aborting the process, no matter how low the default recursion limit is.  so those tests also need changes to pass.  In addition, lowering to 290 created one new failure - test_compile.test_extended_arg now fails with a recursion error.  It seems to need a limit of about 900 to pass; I guess the test could temporarily reset or something but that seems especially kludgy.

Out of curiousity, are these these failures not occurring elsewhere?  It seems like something that would be happening in general (at least for anyone compiling debug builds).  I thought of checking CI builds, but they appear to use release mode, so would be unaffected.

----------

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

From report at bugs.python.org  Tue Mar  2 14:49:51 2021
From: report at bugs.python.org (Brandt Bucher)
Date: Tue, 02 Mar 2021 19:49:51 +0000
Subject: [issue43376] Add PyComplex_FromString
Message-ID: <1614714591.46.0.224854150713.issue43376@roundup.psfhosted.org>


New submission from Brandt Bucher <brandtbucher at gmail.com>:

I recently came across a case where this functionality would be quite useful (parsing complex values from delimited text files). We have PyLong_FromString and PyFloat_FromString, but no PyComplex_FromString (I can't find a reason why it might have been deliberately omitted).

I *think* the best current workaround is to use sscanf to parse out two floats, then feed that to PyComplex_FromDoubles, which is non-trivial.

Do others support this addition? I imagine we would just use something similar to the _Py_string_to_number_with_underscores call at the end of complex_subtype_from_string in Objects/complexobject.c.

----------
components: C API
keywords: easy (C)
messages: 387958
nosy: brandtbucher
priority: normal
severity: normal
status: open
title: Add PyComplex_FromString
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Tue Mar  2 15:45:20 2021
From: report at bugs.python.org (Alex Willmer)
Date: Tue, 02 Mar 2021 20:45:20 +0000
Subject: [issue23740] http.client request and send method have some datatype
 issues
In-Reply-To: <1427052524.74.0.134908492197.issue23740@psf.upfronthosting.co.za>
Message-ID: <1614717920.75.0.750901275623.issue23740@roundup.psfhosted.org>


Alex Willmer <alex at moreati.org.uk> added the comment:

A data point found while I researched this

MyPy typeshed [1] currently declares

_DataType = Union[bytes, IO[Any], Iterable[bytes], str]
class HTTPConnection:
    def send(self, data: _DataType) -> None: ...


[1] https://github.com/python/typeshed/blob/e2967a8beee9e079963ea91a67087ba8fded1d0b/stdlib/http/client.pyi#L26

----------
nosy: +Alex.Willmer

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

From report at bugs.python.org  Tue Mar  2 13:51:07 2021
From: report at bugs.python.org (Igor Mandrichenko)
Date: Tue, 02 Mar 2021 18:51:07 +0000
Subject: [issue43375] memory leak in threading ?
In-Reply-To: <1614708658.89.0.572605723578.issue43375@roundup.psfhosted.org>
Message-ID: <1614711067.66.0.561114179045.issue43375@roundup.psfhosted.org>


Igor Mandrichenko <igorvm at gmail.com> added the comment:

You are right. When I add join(), the memory does not grow any more.
Thanks !

----------

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

From report at bugs.python.org  Tue Mar  2 13:51:37 2021
From: report at bugs.python.org (Igor Mandrichenko)
Date: Tue, 02 Mar 2021 18:51:37 +0000
Subject: [issue43375] memory leak in threading ?
In-Reply-To: <1614708658.89.0.572605723578.issue43375@roundup.psfhosted.org>
Message-ID: <1614711097.45.0.345226907104.issue43375@roundup.psfhosted.org>


Change by Igor Mandrichenko <igorvm at gmail.com>:


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

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

From report at bugs.python.org  Tue Mar  2 11:51:53 2021
From: report at bugs.python.org (hai shi)
Date: Tue, 02 Mar 2021 16:51:53 +0000
Subject: [issue43060] Convert _decimal C API from pointer array to struct
In-Reply-To: <1611913613.83.0.451385849535.issue43060@roundup.psfhosted.org>
Message-ID: <1614703913.2.0.575586652947.issue43060@roundup.psfhosted.org>


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

> It is not "bad"; it is just more wordy.

Agree. Using sturct will be more easy check the members.

But converting the decimal c api may breaks the compatibility, because some macros like `PyDec_TypeCheck_INDEX` have been exposed in headers.

----------

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

From report at bugs.python.org  Tue Mar  2 07:53:44 2021
From: report at bugs.python.org (=?utf-8?q?J=C3=BCrgen_Gmach?=)
Date: Tue, 02 Mar 2021 12:53:44 +0000
Subject: [issue43354] xmlrpc.client: Fault.faultCode erroneously documented to
 be a string, should be int
In-Reply-To: <1614606151.94.0.783784524766.issue43354@roundup.psfhosted.org>
Message-ID: <1614689624.83.0.122147135538.issue43354@roundup.psfhosted.org>


Change by J?rgen Gmach <juergen.gmach at googlemail.com>:


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

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

From report at bugs.python.org  Tue Mar  2 14:54:30 2021
From: report at bugs.python.org (Ned Deily)
Date: Tue, 02 Mar 2021 19:54:30 +0000
Subject: [issue43374] Apple refuses apps written in Python
In-Reply-To: <1614708610.18.0.213124723322.issue43374@roundup.psfhosted.org>
Message-ID: <1614714870.59.0.320641863963.issue43374@roundup.psfhosted.org>


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

>From where are you getting the Python that you are using in the app? A number of those libraries are not part of the python.org Mac binaries.  And are you compiling with c++ by any chance?

----------

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

From report at bugs.python.org  Tue Mar  2 15:50:26 2021
From: report at bugs.python.org (Brandt Bucher)
Date: Tue, 02 Mar 2021 20:50:26 +0000
Subject: [issue42128] Structural Pattern Matching (PEP 634)
In-Reply-To: <1603466540.96.0.7677855399.issue42128@roundup.psfhosted.org>
Message-ID: <1614718226.9.0.184259173278.issue42128@roundup.psfhosted.org>


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

I'm currently working on some performance benchmarks for PEP 634:

https://github.com/brandtbucher/patmaperformance

Hopefully they will help inform future improvements. I already have benchmarks for class patterns and mapping patterns, and am still searching for a good problem that really stresses all of the different variations of sequence patterns. Maybe a generalized Tower of Hanoi or something?

----------

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

From report at bugs.python.org  Tue Mar  2 15:52:46 2021
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 02 Mar 2021 20:52:46 +0000
Subject: [issue42782] shutil.move creates a new directory even on failure
In-Reply-To: <1609267376.56.0.274024517588.issue42782@roundup.psfhosted.org>
Message-ID: <1614718366.08.0.499301500018.issue42782@roundup.psfhosted.org>


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


----------
versions:  -Python 3.6, Python 3.7

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

From report at bugs.python.org  Tue Mar  2 15:52:51 2021
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 02 Mar 2021 20:52:51 +0000
Subject: [issue42782] shutil.move creates a new directory even on failure
In-Reply-To: <1609267376.56.0.274024517588.issue42782@roundup.psfhosted.org>
Message-ID: <1614718371.73.0.705107691115.issue42782@roundup.psfhosted.org>


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


----------
assignee:  -> orsenthil
nosy: +orsenthil

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

From report at bugs.python.org  Tue Mar  2 15:53:27 2021
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 02 Mar 2021 20:53:27 +0000
Subject: [issue42782] shutil.move creates a new directory even on failure
In-Reply-To: <1609267376.56.0.274024517588.issue42782@roundup.psfhosted.org>
Message-ID: <1614718407.69.0.871965462901.issue42782@roundup.psfhosted.org>


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


New changeset 132131b404e06ee1a19b040a1f96cd1118abed0c by Winson Luk in branch 'master':
bpo-42782: Fail fast for permission errors in shutil.move() (GH-24001)
https://github.com/python/cpython/commit/132131b404e06ee1a19b040a1f96cd1118abed0c


----------

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

From report at bugs.python.org  Tue Mar  2 15:53:49 2021
From: report at bugs.python.org (miss-islington)
Date: Tue, 02 Mar 2021 20:53:49 +0000
Subject: [issue42782] shutil.move creates a new directory even on failure
In-Reply-To: <1609267376.56.0.274024517588.issue42782@roundup.psfhosted.org>
Message-ID: <1614718429.73.0.269707079825.issue42782@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: +23487
pull_request: https://github.com/python/cpython/pull/24709

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

From report at bugs.python.org  Tue Mar  2 15:53:56 2021
From: report at bugs.python.org (miss-islington)
Date: Tue, 02 Mar 2021 20:53:56 +0000
Subject: [issue42782] shutil.move creates a new directory even on failure
In-Reply-To: <1609267376.56.0.274024517588.issue42782@roundup.psfhosted.org>
Message-ID: <1614718436.42.0.786014021538.issue42782@roundup.psfhosted.org>


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


----------
pull_requests: +23488
pull_request: https://github.com/python/cpython/pull/24710

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

From report at bugs.python.org  Tue Mar  2 11:53:59 2021
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 02 Mar 2021 16:53:59 +0000
Subject: [issue43211] Python is not responding after running program
In-Reply-To: <1613166912.2.0.538494691419.issue43211@roundup.psfhosted.org>
Message-ID: <1614704039.26.0.202433385711.issue43211@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


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

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

From report at bugs.python.org  Tue Mar  2 13:59:32 2021
From: report at bugs.python.org (Neil Schemenauer)
Date: Tue, 02 Mar 2021 18:59:32 +0000
Subject: [issue42246] Implement PEP 626 -- Precise line numbers for debugging
In-Reply-To: <1604331162.26.0.596873070589.issue42246@roundup.psfhosted.org>
Message-ID: <1614711572.42.0.652448719966.issue42246@roundup.psfhosted.org>


Change by Neil Schemenauer <nas-python at arctrix.com>:


----------
nosy: +nascheme
nosy_count: 7.0 -> 8.0
pull_requests: +23485
pull_request: https://github.com/python/cpython/pull/24708

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

From report at bugs.python.org  Tue Mar  2 13:59:32 2021
From: report at bugs.python.org (Neil Schemenauer)
Date: Tue, 02 Mar 2021 18:59:32 +0000
Subject: [issue43372] ctypes: test_frozentable fails when make regen-frozen
In-Reply-To: <1614696034.15.0.923342699637.issue43372@roundup.psfhosted.org>
Message-ID: <1614711572.34.0.19693149976.issue43372@roundup.psfhosted.org>


Change by Neil Schemenauer <nas-python at arctrix.com>:


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

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

From report at bugs.python.org  Tue Mar  2 07:57:40 2021
From: report at bugs.python.org (=?utf-8?q?J=C3=BCrgen_Gmach?=)
Date: Tue, 02 Mar 2021 12:57:40 +0000
Subject: [issue43354] xmlrpc.client: Fault.faultCode erroneously documented to
 be a string, should be int
In-Reply-To: <1614606151.94.0.783784524766.issue43354@roundup.psfhosted.org>
Message-ID: <1614689860.36.0.794657879398.issue43354@roundup.psfhosted.org>


J?rgen Gmach <juergen.gmach at googlemail.com> added the comment:

The approved typeshed PR:
https://github.com/python/typeshed/pull/5083

----------

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

From report at bugs.python.org  Tue Mar  2 14:59:20 2021
From: report at bugs.python.org (Cody Fox)
Date: Tue, 02 Mar 2021 19:59:20 +0000
Subject: [issue36480] .strip() unexpected output on Windows
In-Reply-To: <1553904887.35.0.429598620868.issue36480@roundup.psfhosted.org>
Message-ID: <1614715160.76.0.461951186322.issue36480@roundup.psfhosted.org>


Change by Cody Fox <cfox9284 at gmail.com>:


Added file: https://bugs.python.org/file49847/tac.eml

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

From report at bugs.python.org  Tue Mar  2 15:03:35 2021
From: report at bugs.python.org (Adrian)
Date: Tue, 02 Mar 2021 20:03:35 +0000
Subject: [issue43374] Apple refuses apps written in Python
In-Reply-To: <1614714870.59.0.320641863963.issue43374@roundup.psfhosted.org>
Message-ID: <A1DDCADD-D66E-47B5-B6AC-659FF9C6CCBB@ag-projects.com>


Adrian <ag at ag-projects.com> added the comment:

My apologies, you may disregard any libraries not downloaded from python.org <http://python.org/>

I am strictly speaking about the following items related to this mailing list:

? Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/_wadd_wchnstr
? Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/_wins_wch
? Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/_win_wch
? Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/_win_wchnstr
? Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/_win_wchnstr
? Contents/Frameworks/Python.framework/Versions/3.9/lib/libpanelw.5.dylib/_SP
? Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/_SP
? Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/___sprintf_chk
? Contents/Frameworks/Python.framework/Versions/3.9/lib/libcrypto.1.1.dylib/___sprintf_chk
? Contents/Frameworks/Python.framework/Versions/3.9/Python/___sprintf_chk
? Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawn
? Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawn_file_actions_addclose
? Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawn_file_actions_adddup2
? Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawn_file_actions_addopen
? Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawn_file_actions_destroy
? Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawn_file_actions_init
? Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnattr_destroy
? Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnattr_init
? Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnattr_setflags
? Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnattr_setpgroup
? Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnattr_setsigdefault
? Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnattr_setsigmask
? Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnp
? Contents/Frameworks/Python.framework/Versions/3.9/lib/libssl.1.1.dylib/___sprintf_chk
? Contents/Frameworks/Python.framework/Versions/3.9/lib/libmenuw.5.dylib/_SP
? Contents/Frameworks/Python.framework/Versions/3.9/lib/libpanelw.5.dylib/__nc_panelhook
? Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/__nc_wcrtomb

All of them are part of Python 3.9 for Mac downloaded from:

https://www.python.org/downloads/ <https://www.python.org/downloads/>

--
Adrian

> On 2 Mar 2021, at 16:54, Ned Deily <report at bugs.python.org> wrote:
> 
> 
> Ned Deily <nad at python.org> added the comment:
> 
>> From where are you getting the Python that you are using in the app? A number of those libraries are not part of the python.org Mac binaries.  And are you compiling with c++ by any chance?
> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue43374>
> _______________________________________
>

----------

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

From report at bugs.python.org  Tue Mar  2 15:04:00 2021
From: report at bugs.python.org (Adrian)
Date: Tue, 02 Mar 2021 20:04:00 +0000
Subject: [issue43374] Apple refuses apps written in Python
In-Reply-To: <1614714870.59.0.320641863963.issue43374@roundup.psfhosted.org>
Message-ID: <5B8B5A8C-001C-4FC0-B593-ACACBFC4D7EB@ag-projects.com>


Adrian <ag at ag-projects.com> added the comment:

My apologies, you may disregard any libraries not downloaded from python.org <http://python.org/>

I am strictly speaking about the following items related to this mailing list:

? Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/_wadd_wchnstr
? Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/_wins_wch
? Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/_win_wch
? Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/_win_wchnstr
? Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/_win_wchnstr
? Contents/Frameworks/Python.framework/Versions/3.9/lib/libpanelw.5.dylib/_SP
? Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/_SP
? Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/___sprintf_chk
? Contents/Frameworks/Python.framework/Versions/3.9/lib/libcrypto.1.1.dylib/___sprintf_chk
? Contents/Frameworks/Python.framework/Versions/3.9/Python/___sprintf_chk
? Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawn
? Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawn_file_actions_addclose
? Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawn_file_actions_adddup2
? Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawn_file_actions_addopen
? Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawn_file_actions_destroy
? Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawn_file_actions_init
? Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnattr_destroy
? Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnattr_init
? Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnattr_setflags
? Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnattr_setpgroup
? Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnattr_setsigdefault
? Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnattr_setsigmask
? Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnp
? Contents/Frameworks/Python.framework/Versions/3.9/lib/libssl.1.1.dylib/___sprintf_chk
? Contents/Frameworks/Python.framework/Versions/3.9/lib/libmenuw.5.dylib/_SP
? Contents/Frameworks/Python.framework/Versions/3.9/lib/libpanelw.5.dylib/__nc_panelhook
? Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/__nc_wcrtomb

All of them are part of Python 3.9 for Mac downloaded from:

https://www.python.org/downloads/ <https://www.python.org/downloads/>

--
Adrian

> On 2 Mar 2021, at 16:54, Ned Deily <report at bugs.python.org <mailto:report at bugs.python.org>> wrote:
> 
> 
> Ned Deily <nad at python.org <mailto:nad at python.org>> added the comment:
> 
>> From where are you getting the Python that you are using in the app? A number of those libraries are not part of the python.org <http://python.org/> Mac binaries.  And are you compiling with c++ by any chance?
> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org <mailto:report at bugs.python.org>>
> <https://bugs.python.org/issue43374 <https://bugs.python.org/issue43374>>
> _______________________________________
>

----------

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

From report at bugs.python.org  Tue Mar  2 14:05:09 2021
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 02 Mar 2021 19:05:09 +0000
Subject: [issue43162] Enum regression: AttributeError when accessing class
 variables on instances
In-Reply-To: <1612786979.73.0.896348338765.issue43162@roundup.psfhosted.org>
Message-ID: <1614711909.86.0.699133876584.issue43162@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

DeprecationWarning will be active in 3.10 and 3.11 with removal in 3.12.

----------

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

From report at bugs.python.org  Tue Mar  2 15:07:33 2021
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 02 Mar 2021 20:07:33 +0000
Subject: [issue43344] RotatingFileHandler breaks file type associations
In-Reply-To: <1614465857.24.0.529577943251.issue43344@roundup.psfhosted.org>
Message-ID: <1614715653.98.0.525110330253.issue43344@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> Thanks Vinay, I was able to do this

Glad to hear it, Kevin. That namer is exactly what I had in my mind's eye ;-)

So shall I close the issue?

----------

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

From report at bugs.python.org  Tue Mar  2 15:08:35 2021
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 02 Mar 2021 20:08:35 +0000
Subject: [issue43344] RotatingFileHandler breaks file type associations
In-Reply-To: <1614465857.24.0.529577943251.issue43344@roundup.psfhosted.org>
Message-ID: <1614715715.39.0.890737175443.issue43344@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I'll add to the cookbook recipe with this real-world example, when I get a chance.

----------

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

From report at bugs.python.org  Tue Mar  2 15:08:55 2021
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 02 Mar 2021 20:08:55 +0000
Subject: [issue36480] .strip() unexpected output on Windows
In-Reply-To: <1553904887.35.0.429598620868.issue36480@roundup.psfhosted.org>
Message-ID: <1614715735.7.0.589287223653.issue36480@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


Removed file: https://bugs.python.org/file49847/tac.eml

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

From report at bugs.python.org  Tue Mar  2 12:06:28 2021
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 02 Mar 2021 17:06:28 +0000
Subject: [issue1812] doctest _load_testfile function -- newline handling seems
 incorrect
In-Reply-To: <1200117455.4.0.563963262174.issue1812@psf.upfronthosting.co.za>
Message-ID: <1614704788.03.0.688463529043.issue1812@roundup.psfhosted.org>


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


New changeset b36349a647b2bf8174f0e736a4fc347e92ae204e by Peter Donis in branch 'master':
bpo-43049: Use io.IncrementalNewlineDecoder for doctest newline conversion (GH-24359)
https://github.com/python/cpython/commit/b36349a647b2bf8174f0e736a4fc347e92ae204e


----------

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

From report at bugs.python.org  Tue Mar  2 12:08:19 2021
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 02 Mar 2021 17:08:19 +0000
Subject: [issue43049] Use io.IncrementalNewlineDecoder for doctest newline
 conversion
In-Reply-To: <1611799804.84.0.215071854075.issue43049@roundup.psfhosted.org>
Message-ID: <1614704899.13.0.268348605511.issue43049@roundup.psfhosted.org>


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

Thanks for the patch!

----------
components: +Library (Lib) -Tests
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Mar  2 14:09:49 2021
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 02 Mar 2021 19:09:49 +0000
Subject: [issue43364] Add shortcut to enable UTF-8 mode in start menu.
In-Reply-To: <1614675827.66.0.411790166938.issue43364@roundup.psfhosted.org>
Message-ID: <1614712189.1.0.504252426745.issue43364@roundup.psfhosted.org>


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

> `cmd.exe /c "SETX PYTHONUTF8 1

You can run "[WindowsFolder]System32\setx.exe" directly. It's not a shell command.

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

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

From report at bugs.python.org  Tue Mar  2 12:06:27 2021
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 02 Mar 2021 17:06:27 +0000
Subject: [issue43049] Use io.IncrementalNewlineDecoder for doctest newline
 conversion
In-Reply-To: <1611799804.84.0.215071854075.issue43049@roundup.psfhosted.org>
Message-ID: <1614704787.97.0.424946904386.issue43049@roundup.psfhosted.org>


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


New changeset b36349a647b2bf8174f0e736a4fc347e92ae204e by Peter Donis in branch 'master':
bpo-43049: Use io.IncrementalNewlineDecoder for doctest newline conversion (GH-24359)
https://github.com/python/cpython/commit/b36349a647b2bf8174f0e736a4fc347e92ae204e


----------

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

From report at bugs.python.org  Tue Mar  2 16:08:16 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Mar 2021 21:08:16 +0000
Subject: [issue43356] PyErr_SetInterrupt should have an equivalent that takes
 a signal number
In-Reply-To: <1614621328.26.0.486134499262.issue43356@roundup.psfhosted.org>
Message-ID: <1614719296.92.0.715190051802.issue43356@roundup.psfhosted.org>


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


----------
nosy: +neologix, vstinner

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

From report at bugs.python.org  Tue Mar  2 16:09:02 2021
From: report at bugs.python.org (Ned Deily)
Date: Tue, 02 Mar 2021 21:09:02 +0000
Subject: [issue43374] Apple refuses apps written in Python
In-Reply-To: <1614708610.18.0.213124723322.issue43374@roundup.psfhosted.org>
Message-ID: <1614719342.14.0.772735507422.issue43374@roundup.psfhosted.org>


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

Hmm, yours is the first report of this here that I'm aware of. I see other reports on the web of other non-Python projects running into similar problems. So one question is what has changed? Can you report the version info string of this Python? Have you previously successfully submitted apps using this particular build of Python 3.9? If not, can you say exactly which version of Python last worked for this?

----------

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

From report at bugs.python.org  Tue Mar  2 12:11:49 2021
From: report at bugs.python.org (Andre Roberge)
Date: Tue, 02 Mar 2021 17:11:49 +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: <1614705109.69.0.899204696717.issue43366@roundup.psfhosted.org>


Andre Roberge <andre.roberge at gmail.com> added the comment:

I understand the challenge of reproducing the behaviour of the Python interpreter for this case. If it cannot be reproduced, then the documentation for https://docs.python.org/3/library/code.html#code.InteractiveConsole.interact and others on that page should probably be modified as it states that it "Closely emulate the interactive Python console."

----------

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

From report at bugs.python.org  Tue Mar  2 08:14:30 2021
From: report at bugs.python.org (Yannick Jadoul)
Date: Tue, 02 Mar 2021 13:14:30 +0000
Subject: [issue43367] submodule of c-extension module is quirky
In-Reply-To: <1614685283.59.0.727643422908.issue43367@roundup.psfhosted.org>
Message-ID: <1614690870.85.0.137167848996.issue43367@roundup.psfhosted.org>


Change by Yannick Jadoul <yannick.jadoul at gmail.com>:


----------
nosy: +YannickJadoul

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

From report at bugs.python.org  Tue Mar  2 14:20:01 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Tue, 02 Mar 2021 19:20:01 +0000
Subject: [issue43060] Convert _decimal C API from pointer array to struct
In-Reply-To: <1611913613.83.0.451385849535.issue43060@roundup.psfhosted.org>
Message-ID: <1614712801.76.0.720971616385.issue43060@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

> But converting the decimal c api may breaks the compatibility, because some macros like `PyDec_TypeCheck_INDEX` have been exposed in headers.

True. Is there many external users of this API? I could not find any relevant examples using searchcode.com.

----------

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

From report at bugs.python.org  Tue Mar  2 16:16:20 2021
From: report at bugs.python.org (miss-islington)
Date: Tue, 02 Mar 2021 21:16:20 +0000
Subject: [issue42782] shutil.move creates a new directory even on failure
In-Reply-To: <1609267376.56.0.274024517588.issue42782@roundup.psfhosted.org>
Message-ID: <1614719780.43.0.0948568426188.issue42782@roundup.psfhosted.org>


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


----------
pull_requests: +23489
pull_request: https://github.com/python/cpython/pull/24711

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

From report at bugs.python.org  Tue Mar  2 16:20:35 2021
From: report at bugs.python.org (Ned Deily)
Date: Tue, 02 Mar 2021 21:20:35 +0000
Subject: [issue43374] Apple refuses apps written in Python
In-Reply-To: <1614708610.18.0.213124723322.issue43374@roundup.psfhosted.org>
Message-ID: <1614720035.68.0.823639334642.issue43374@roundup.psfhosted.org>


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

BTW, if you haven't already, I would strongly suggest you ask on one of the Apple Developer Forums. My first guess is that the App Store validation process is trying to incorrectly apply rules to your local Python framework (from the Python.org installed framework). But that's just a guess at this point.

----------

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

From report at bugs.python.org  Tue Mar  2 16:22:01 2021
From: report at bugs.python.org (Luciano Ramalho)
Date: Tue, 02 Mar 2021 21:22:01 +0000
Subject: [issue43378] Pattern Matching section in tutorial refers to | as
Message-ID: <1614720121.97.0.0865243171415.issue43378@roundup.psfhosted.org>


Change by Luciano Ramalho <luciano at ramalho.org>:


----------
nosy: ramalho
priority: normal
severity: normal
status: open
title: Pattern Matching section in tutorial refers to | as

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

From report at bugs.python.org  Tue Mar  2 12:26:29 2021
From: report at bugs.python.org (Steve Dower)
Date: Tue, 02 Mar 2021 17:26:29 +0000
Subject: [issue43271] AMD64 Windows10 3.x crash with Windows fatal exception:
 stack overflow
In-Reply-To: <1613766414.64.0.363657915419.issue43271@roundup.psfhosted.org>
Message-ID: <1614705989.06.0.155206148991.issue43271@roundup.psfhosted.org>


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

We already have a separate recursion limit for debug builds on Windows, so it's probably best all around to reduce that (if it's only recursion tests that are failing). That way, we won't forget to fix up debugging later if/when we fix recursion.

----------

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

From report at bugs.python.org  Tue Mar  2 16:29:07 2021
From: report at bugs.python.org (Adrian)
Date: Tue, 02 Mar 2021 21:29:07 +0000
Subject: [issue43374] Apple refuses apps written in Python
In-Reply-To: <1614720035.68.0.823639334642.issue43374@roundup.psfhosted.org>
Message-ID: <5E4BA4D3-667A-44AE-89F9-F8807AB53025@ag-projects.com>


Adrian <ag at ag-projects.com> added the comment:

Hi Ned,

I have a ticket opened with Apple. They refuse the software as it, they are in a position of absolute power, to reject and drop many years of work on a dime.

What am I suppose to do? I can fix my own software, but then there are dependencies like Python itself. Hence my question on this forum. I don?t expect miracles or people doing works for free for me to solve my problem. I think I am not the only one confronted with this problem, Python has a pretty large installed base. 

I am looking for practical suggestions.

Regards,
Adrian

> On 2 Mar 2021, at 18:20, Ned Deily <report at bugs.python.org> wrote:
> 
> 
> Ned Deily <nad at python.org> added the comment:
> 
> BTW, if you haven't already, I would strongly suggest you ask on one of the Apple Developer Forums. My first guess is that the App Store validation process is trying to incorrectly apply rules to your local Python framework (from the Python.org installed framework). But that's just a guess at this point.
> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue43374>
> _______________________________________
>

----------

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

From report at bugs.python.org  Tue Mar  2 16:29:27 2021
From: report at bugs.python.org (Luciano Ramalho)
Date: Tue, 02 Mar 2021 21:29:27 +0000
Subject: [issue43378] Pattern Matching section in tutorial refers to | as or
Message-ID: <1614720567.85.0.819945578913.issue43378@roundup.psfhosted.org>


New submission from Luciano Ramalho <luciano at ramalho.org>:

Section 4.6. "match Statements" of the Python 3.10 tutorial says:

"""
You can combine several literals in a single pattern using | (?or?):
"""

For someone just learning Python, this may suggest that | is always "or", when in fact it is a bitwise operator (that may be overloaded), but inside a match clause has this special meaning without any overloading. 

I believe this exception should be made explicit in section 4.6, otherwise it may lead readers of the tutorial to a misconception.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
title: Pattern Matching section in tutorial refers to | as -> Pattern Matching section in tutorial refers to | as or
type:  -> enhancement
versions: +Python 3.10

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

From report at bugs.python.org  Tue Mar  2 16:36:39 2021
From: report at bugs.python.org (Alex Willmer)
Date: Tue, 02 Mar 2021 21:36:39 +0000
Subject: [issue23740] http.client request and send method have some datatype
 issues
In-Reply-To: <1427052524.74.0.134908492197.issue23740@psf.upfronthosting.co.za>
Message-ID: <1614720999.51.0.338296607718.issue23740@roundup.psfhosted.org>


Alex Willmer <alex at moreati.org.uk> added the comment:

First stab at characterising http.client.HTTPConnnection.send().

https://github.com/moreati/bpo-23740

This uses a webserver that returns request details, in the body of the response. Raw (TCP level) content is included. It shares a similar purpose to HTTP TRACE command. In principal the bytes that HTTPConection.send() writes will match to the bytes returned (after they're decapsulated from the JSON). I've not tested that aspect yet.

TODO
- further testing (verify round trip, bytes in = bytes out) 
- cover multiple Python versions
- cover cases such client manually setting Content-Length

----------

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

From report at bugs.python.org  Tue Mar  2 16:36:34 2021
From: report at bugs.python.org (Ned Deily)
Date: Tue, 02 Mar 2021 21:36:34 +0000
Subject: [issue43374] Apple refuses apps written in Python
In-Reply-To: <1614708610.18.0.213124723322.issue43374@roundup.psfhosted.org>
Message-ID: <1614720994.3.0.940911418.issue43374@roundup.psfhosted.org>


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

> What am I suppose to do?

I appreciate that it's a nasty problem. Unfortunately, this is unknown territory for me: I have no experience with the Mac App Store and this is the first time I've run across a report like this. So the question again is: what has changed? Were you able to successfully submit Python apps before? If so, exactly what version worked and what version is failing now/ There are some differences in how we have and are now building the Mac binaries for the python.org installers.  But I'm working blind here.  Perhaps some other people have experience with this.

----------

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

From report at bugs.python.org  Tue Mar  2 08:40:49 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 02 Mar 2021 13:40:49 +0000
Subject: [issue43233] test_os: test_copy_file_range_offset fails on FreeBSD
 CURRENT
In-Reply-To: <1613417170.64.0.402539389952.issue43233@roundup.psfhosted.org>
Message-ID: <1614692449.98.0.183260401593.issue43233@roundup.psfhosted.org>


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

Buildbot is green! 
https://buildbot.python.org/all/#/builders/483/builds/841

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

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

From report at bugs.python.org  Tue Mar  2 08:41:06 2021
From: report at bugs.python.org (Ken Teh)
Date: Tue, 02 Mar 2021 13:41:06 +0000
Subject: [issue20074] open() of read-write non-seekable streams broken
In-Reply-To: <1388088109.09.0.0894725958863.issue20074@psf.upfronthosting.co.za>
Message-ID: <1614692466.96.0.342647182323.issue20074@roundup.psfhosted.org>


Ken Teh <teh at anl.gov> added the comment:

It works on macos but not on linux, ie, I have a usb-serial dongle connected to a serial device (a CAMAC controller), and I do an os.open() with 'wb+', followed by a io.fdopen().  I can talk to my device on macos BigSur 11.2, buffered, but not on Linux which throws the non-seekable error when I do the io.fdopen().

----------
nosy: +ken.teh

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

From report at bugs.python.org  Tue Mar  2 13:10:58 2021
From: report at bugs.python.org (Igor Mandrichenko)
Date: Tue, 02 Mar 2021 18:10:58 +0000
Subject: [issue43375] memory leak in threading ?
Message-ID: <1614708658.89.0.572605723578.issue43375@roundup.psfhosted.org>


New submission from Igor Mandrichenko <igorvm at gmail.com>:

There is an apparent memory leak in threading. It looks like memory grows when I create, run and destroy threads. The memory keeps adding at the rate of about 100 bytes per thread.

I am attaching the code, which works for Linux. getMemory() function is Linux-specific, it gets current process memory utilization

----------
components: Extension Modules
files: memleak.py
messages: 387948
nosy: igorvm
priority: normal
severity: normal
status: open
title: memory leak in threading ?
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file49846/memleak.py

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

From report at bugs.python.org  Tue Mar  2 16:45:36 2021
From: report at bugs.python.org (Romain Vincent)
Date: Tue, 02 Mar 2021 21:45:36 +0000
Subject: [issue43379] Pasting multiple lines in the REPL is broken since 3.9
Message-ID: <1614721536.12.0.538890122544.issue43379@roundup.psfhosted.org>


New submission from Romain Vincent <romain at rwigo.com>:

DISCLAIMER: This is the first time I submit an issue here. In advance, my humble apologies if I missed something.
Feel free to correct me :)

--

I regularly test snippets of code by pasting them from a code editor to a shell REPL.

It works perfectly well in python 3.8 or 3.7 but not in python 3.9.

Demonstration:

Try to copy and paste the following simple snippet:

---

def f():
    print("hello world")

---

The result in a python 3.8 REPL (same with 3.7):

---

$ python3.8
Python 3.8.6 (default, Nov 20 2020, 18:29:40)
[Clang 12.0.0 (clang-1200.0.32.27)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> def f():
    print("hello world")
>>> f()
hello world

---

But with python 3.9:

---

$ python3.9
Python 3.9.1 (default, Dec 10 2020, 10:36:35)
[Clang 12.0.0 (clang-1200.0.32.27)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> def f():
    print("hello world")
  File "<stdin>", line 1

    ^
SyntaxError: multiple statements found while compiling a single statement

---

This behavior happens with any snippet of code containing at least one indented line, whether by tabs or spaces and whatever the number of spaces.


Regards.

----------
components: IO
messages: 387976
nosy: romainfv
priority: normal
severity: normal
status: open
title: Pasting multiple lines in the REPL is broken since 3.9
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Tue Mar  2 12:53:31 2021
From: report at bugs.python.org (Gaming With Skytorrush)
Date: Tue, 02 Mar 2021 17:53:31 +0000
Subject: [issue43373] Tensorflow
Message-ID: <1614707611.34.0.215212100924.issue43373@roundup.psfhosted.org>


New submission from Gaming With Skytorrush <clashwithchiefrpjyt at gmail.com>:

I was unable to install Tensorflow via pip in python 3.9 but its working fine with 3.8

----------
components: Library (Lib)
messages: 387944
nosy: clashwithchiefrpjyt
priority: normal
severity: normal
status: open
title: Tensorflow
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Tue Mar  2 16:51:15 2021
From: report at bugs.python.org (Adrian)
Date: Tue, 02 Mar 2021 21:51:15 +0000
Subject: [issue43374] Apple refuses apps written in Python
In-Reply-To: <1614720994.3.0.940911418.issue43374@roundup.psfhosted.org>
Message-ID: <DC285A12-6ECE-46EF-8DA3-3718C17976FA@ag-projects.com>


Adrian <ag at ag-projects.com> added the comment:

Hi Ned,

Yes, I have submitted Python apps to Mac App Store since 2009, for 12 years.

Each new push opens a new pandoras box with different questions asked than previously. There is no learning curve, is just walls with more walls behind each submission. The official reasoning behind all these controls is more security for end-users at the cost of less and less freedom for developers.

The app is a the result of the collaboration effort of many people and years of IETF works related to standards based real-time communications.

Two years ago we almost dropped the app because of almost impossible to solve issues raised by Apple. 

In the last year we spent many efforts to see if and how we can still comply with the more and more authoritarian demands of Apple to keep these works alive. 

I resigned myself to the thought that at some point we will hit a unsolvable issue, I just hope is not this one and now.

Adrian

> On 2 Mar 2021, at 18:36, Ned Deily <report at bugs.python.org> wrote:
> 
> 
> Ned Deily <nad at python.org> added the comment:
> 
>> What am I suppose to do?
> 
> I appreciate that it's a nasty problem. Unfortunately, this is unknown territory for me: I have no experience with the Mac App Store and this is the first time I've run across a report like this. So the question again is: what has changed? Were you able to successfully submit Python apps before? If so, exactly what version worked and what version is failing now/ There are some differences in how we have and are now building the Mac binaries for the python.org installers.  But I'm working blind here.  Perhaps some other people have experience with this.
> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue43374>
> _______________________________________
>

----------

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

From report at bugs.python.org  Tue Mar  2 13:04:15 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 02 Mar 2021 18:04:15 +0000
Subject: [issue43373] Tensorflow
In-Reply-To: <1614707611.34.0.215212100924.issue43373@roundup.psfhosted.org>
Message-ID: <1614708255.6.0.769182940863.issue43373@roundup.psfhosted.org>


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

Wrong tracker. Try https://github.com/tensorflow/tensorflow. (See in particular https://github.com/tensorflow/tensorflow/issues/44485.)

----------
nosy: +mark.dickinson
resolution:  -> third party
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Mar  2 13:05:29 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 02 Mar 2021 18:05:29 +0000
Subject: [issue43373] Tensorflow
In-Reply-To: <1614707611.34.0.215212100924.issue43373@roundup.psfhosted.org>
Message-ID: <1614708329.77.0.831508478019.issue43373@roundup.psfhosted.org>


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

Hmm. Somehow the trailing dot became part of the second URL.

Trying again: https://github.com/tensorflow/tensorflow/issues/44485

----------

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

From report at bugs.python.org  Tue Mar  2 13:10:10 2021
From: report at bugs.python.org (Adrian)
Date: Tue, 02 Mar 2021 18:10:10 +0000
Subject: [issue43374] Apple refuses apps written in Python
Message-ID: <1614708610.18.0.213124723322.issue43374@roundup.psfhosted.org>


New submission from Adrian <ag at ag-projects.com>:

My company maintains several Python related projects, one of them being an application published for many years in the Mac App Store.

During the submittion of the last update for the app, we were refused by Apple to publish the software with the following reason:

Guideline 2.5.1 - Performance
Your app links against the following non-public framework(s):

? Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/_wadd_wchnstr
? Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/_wins_wch
? Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/_win_wch
? Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/_win_wchnstr
? Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/_win_wchnstr
? Contents/Frameworks/libpython3.9.dylib/___sprintf_chk
? Contents/Frameworks/libpython3.9.dylib/_posix_spawn
? Contents/Frameworks/libpython3.9.dylib/_posix_spawn_file_actions_addclose
? Contents/Frameworks/libpython3.9.dylib/_posix_spawn_file_actions_adddup2
? Contents/Frameworks/libpython3.9.dylib/_posix_spawn_file_actions_addopen
? Contents/Frameworks/libpython3.9.dylib/_posix_spawn_file_actions_destroy
? Contents/Frameworks/libpython3.9.dylib/_posix_spawn_file_actions_init
? Contents/Frameworks/libpython3.9.dylib/_posix_spawnattr_destroy
? Contents/Frameworks/libpython3.9.dylib/_posix_spawnattr_init
? Contents/Frameworks/libpython3.9.dylib/_posix_spawnattr_setflags
? Contents/Frameworks/libpython3.9.dylib/_posix_spawnattr_setpgroup
? Contents/Frameworks/libpython3.9.dylib/_posix_spawnattr_setsigdefault
? Contents/Frameworks/libpython3.9.dylib/_posix_spawnattr_setsigmask
? Contents/Frameworks/libpython3.9.dylib/_posix_spawnp
? Contents/Frameworks/libcrypto.1.1.dylib/___sprintf_chk
? Contents/Frameworks/libp11-kit.0.dylib/___sprintf_chk
? Contents/Frameworks/Python.framework/Versions/3.9/lib/libpanelw.5.dylib/_SP
? Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/_SP
? Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/___sprintf_chk
? Contents/Frameworks/libmpfr.6.dylib/___sprintf_chk
? Contents/Frameworks/libgnutls.30.dylib/___sprintf_chk
? Contents/Frameworks/libgnutls.30.dylib/_p11_kit_space_strdup
? Contents/Frameworks/libgnutls.30.dylib/_p11_kit_space_strlen
? Contents/Frameworks/libidn2.0.dylib/_sprintf
? Contents/Frameworks/libx264.157.dylib/___sprintf_chk
? Contents/Frameworks/Python.framework/Versions/3.9/lib/libcrypto.1.1.dylib/___sprintf_chk
? Contents/Frameworks/libssl.1.1.dylib/___sprintf_chk
? Contents/Frameworks/libxml2.2.dylib/___sprintf_chk
? Contents/Frameworks/Python.framework/Versions/3.9/Python/___sprintf_chk
? Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawn
? Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawn_file_actions_addclose
? Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawn_file_actions_adddup2
? Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawn_file_actions_addopen
? Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawn_file_actions_destroy
? Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawn_file_actions_init
? Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnattr_destroy
? Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnattr_init
? Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnattr_setflags
? Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnattr_setpgroup
? Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnattr_setsigdefault
? Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnattr_setsigmask
? Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnp
? Contents/Frameworks/Python.framework/Versions/3.9/lib/libssl.1.1.dylib/___sprintf_chk
? Contents/Frameworks/libhogweed.6.dylib/_nettle_buffer_space
? Contents/Frameworks/libicui18n.67.dylib/_sprintf
? Contents/Frameworks/Python.framework/Versions/3.9/lib/libmenuw.5.dylib/_SP
? Contents/Frameworks/libavfilter.7.dylib/_avformat_match_stream_specifier
? Contents/Frameworks/libmpc.3.dylib/___sprintf_chk
? Contents/Frameworks/libunistring.2.dylib/___sprintf_chk
? Contents/Frameworks/libunistring.2.dylib/_sprintf
? Contents/Frameworks/Python.framework/Versions/3.9/lib/libpanelw.5.dylib/__nc_panelhook
? Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/__nc_wcrtomb

Next Steps

The use of non-public APIs is not permitted on the App Store as it can lead to a poor user experience should these APIs change.

----------
components: C API, Interpreter Core, macOS
messages: 387947
nosy: adigeo, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Apple refuses apps written in Python
type: security
versions: Python 3.9

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

From report at bugs.python.org  Tue Mar  2 17:09:21 2021
From: report at bugs.python.org (Ned Deily)
Date: Tue, 02 Mar 2021 22:09:21 +0000
Subject: [issue43374] Apple refuses apps written in Python
In-Reply-To: <1614708610.18.0.213124723322.issue43374@roundup.psfhosted.org>
Message-ID: <1614722961.84.0.0485516591289.issue43374@roundup.psfhosted.org>


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


----------
type: security -> 

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

From report at bugs.python.org  Tue Mar  2 13:14:11 2021
From: report at bugs.python.org (Kevin Hollingshead)
Date: Tue, 02 Mar 2021 18:14:11 +0000
Subject: [issue43344] RotatingFileHandler breaks file type associations
In-Reply-To: <1614611607.82.0.732318865366.issue43344@roundup.psfhosted.org>
Message-ID: <CAAFLtXpRP+2kGN6WwrO2wM=4Fts3qCFDcnWhpbkQiN21DLYMWw@mail.gmail.com>


Kevin Hollingshead <kh14821 at gmail.com> added the comment:

Thanks Vinay, I was able to do this with:

def namer(name):
    return name.replace(".log", "") + ".log"

Then when initializing the logger:

handler.namer = namer

My full initializer script:

import os
import logging
from logging.handlers import TimedRotatingFileHandler
from config import constants

def namer(name):
    return name.replace(".log", "") + ".log"

def init(baseFilename):
    logPath = constants.LOGGING_DIR
    envSuffix = '-prod' if constants.ENV == 'prod' else '-dev'
    logFilename = os.path.join(logPath, baseFilename + envSuffix + '.log')
    print(f"Logging to {logFilename}")

    handler = TimedRotatingFileHandler(logFilename,
        when = "midnight",
        backupCount = 30,
        encoding = 'utf8')
    handler.setLevel(logging.DEBUG)
    handler.suffix = "%Y%m%d"
    handler.namer = namer

    formatter = logging.Formatter('%(asctime)s %(levelname)s %(message)s
[%(module)s:%(lineno)d]')
    handler.setFormatter(formatter)

    logging.basicConfig(
        handlers = [handler],
        format = '%(asctime)s %(levelname)s %(message)s
[%(module)s:%(lineno)d]',
        level = logging.DEBUG,
        datefmt = '%Y-%m-%d %H:%M:%S')

if __name__ == '__main__':
    init('testing')
    logging.error("ohai")
    logging.debug("ohai debug")
    logging.getLogger().handlers[0].doRollover()
    logging.error("ohai next day")
    logging.debug("ohai debug next day")

On Mon, Mar 1, 2021 at 8:13 AM Vinay Sajip <report at bugs.python.org> wrote:

>
> Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:
>
> As per the documentation at
>
>
> https://docs.python.org/3/library/logging.handlers.html#logging.handlers.BaseRotatingHandler.namer
>
> You can set the handler's "namer" attribute to a callable that returns a
> computed name for the rotated file - this can be computed as per your
> requirements. The cookbook also has an entry about this:
>
>
> https://docs.python.org/3/howto/logging-cookbook.html#using-a-rotator-and-namer-to-customize-log-rotation-processing
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue43344>
> _______________________________________
>

----------

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

From report at bugs.python.org  Tue Mar  2 09:24:14 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 02 Mar 2021 14:24:14 +0000
Subject: [issue40701] tempfile mixes str and bytes in an inconsistent manner
In-Reply-To: <1590002424.23.0.821521735552.issue40701@roundup.psfhosted.org>
Message-ID: <1614695054.06.0.480504366041.issue40701@roundup.psfhosted.org>


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

I clarified the documentation in the PR and added a regression test.

I chose to explicitly document that tempfile.tempdir may only be str or bytes and cannot be a path-like object.

We already document that people really should not set it and instead pass dir= to their APIs.  Now the docs make that more clear when it comes to setting it to a bytes object due to the global API return type change consequences.

I view this PR as cleaning up a partial misbehavior while preserving an API wart of it ever working in any manner when set to a bytes value.

getting rid of tempfile.tempdir entirely or preventing it from being a bytes value at all would be much more of a breaking change, even though desirable.  Not a bugfix.  Now with the PR as is, we at least document that people should avoid doing that and make it clear what consistent behavior happens when they do it anyways.  With a test.

----------

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

From report at bugs.python.org  Tue Mar  2 09:25:34 2021
From: report at bugs.python.org (OrbitalHorizons)
Date: Tue, 02 Mar 2021 14:25:34 +0000
Subject: [issue43284] Wrong windows build post version 2004
In-Reply-To: <1613904146.72.0.850542213327.issue43284@roundup.psfhosted.org>
Message-ID: <1614695134.64.0.275564743591.issue43284@roundup.psfhosted.org>


OrbitalHorizons <moserm1103 at gmail.com> added the comment:

Running `platform.platform()` on Windows 10 21H1 results in the build number 19041:

Python 3.8.8 (tags/v3.8.8:024d805, Feb 19 2021, 13:18:16) [MSC v.1928 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform
>>> platform.platform()
'Windows-10-10.0.19041-SP0'
This is incorrect, the correct build number is 19043.

----------
nosy: +Orbital
title: Wrong windows build in 20H2 -> Wrong windows build post version 2004
versions: +Python 3.8

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

From report at bugs.python.org  Tue Mar  2 09:31:34 2021
From: report at bugs.python.org (Dmitriy Mironiyk)
Date: Tue, 02 Mar 2021 14:31:34 +0000
Subject: [issue43371] Mock.assert_has_calls works strange
Message-ID: <1614695494.31.0.773020245058.issue43371@roundup.psfhosted.org>


New submission from Dmitriy Mironiyk <dmitriy.mironiyk at thras.io>:

I think that behavior of Mock.assert_has_calls is misleading. 
- When I call Mock.assert_has_calls with any_order=False it checks that expected calls are the same calls as performed on mock and raise an error if mock has some calls other than expected.
- When I call Mock.assert_has_calls with any_order=True it checks that mock has expected calls and not raise an error when mock has other calls than expected.

I suppose should be two separate methods:
- Mock.assert_has_only_calls that always raise an error when mock has calls other than expected(not regarding any_order).
- Mock.assert_has_calls that raise error only when no calls that provided in expected or if order of calls is wrong when any_order=False.

----------
components: Tests
files: test_mock_asser_has_calls.py
messages: 387932
nosy: dmitriy.mironiyk
priority: normal
severity: normal
status: open
title: Mock.assert_has_calls works strange
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file49845/test_mock_asser_has_calls.py

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

From report at bugs.python.org  Tue Mar  2 13:32:56 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 02 Mar 2021 18:32:56 +0000
Subject: [issue43375] memory leak in threading ?
In-Reply-To: <1614708658.89.0.572605723578.issue43375@roundup.psfhosted.org>
Message-ID: <1614709976.91.0.9679369133.issue43375@roundup.psfhosted.org>


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

I'm not sure that this counts as a bug.

Each non-daemon thread adds a lock to the threading._shutdown_locks set: https://github.com/python/cpython/blob/8b795ab5541d8a4e69be4137dfdc207714270b77/Lib/threading.py#L933-L935.

That lock is removed when the thread is "join"ed: https://github.com/python/cpython/blob/8b795ab5541d8a4e69be4137dfdc207714270b77/Lib/threading.py#L988-L990

So the simple solution is to make sure that you always join your threads (which I'd expect normal code to do for non-daemon threads anyway), or to make your threads daemon threads.

----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Tue Mar  2 17:30:39 2021
From: report at bugs.python.org (Steve Dower)
Date: Tue, 02 Mar 2021 22:30:39 +0000
Subject: [issue43271] AMD64 Windows10 3.x crash with Windows fatal exception:
 stack overflow
In-Reply-To: <1613766414.64.0.363657915419.issue43271@roundup.psfhosted.org>
Message-ID: <1614724239.98.0.23808593707.issue43271@roundup.psfhosted.org>


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

Hmm, yeah, it seems like the debug-specific definition has gone. Wonder when that happened.

In that case, go ahead and revert, but I'd suggest doing it by just removing the new Py_DEBUG condition rather than undoing all the changes. Should be nothing wrong with the rest of it.

IIRC, PR builds run under release because the compile-time increase is more than made up by the test time decrease.

----------

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

From report at bugs.python.org  Tue Mar  2 09:41:26 2021
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Tue, 02 Mar 2021 14:41:26 +0000
Subject: [issue39448] Add regen-frozen makefile target
In-Reply-To: <1579899167.9.0.743060780992.issue39448@roundup.psfhosted.org>
Message-ID: <1614696086.65.0.765282873045.issue39448@roundup.psfhosted.org>


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

I think something is broken with this, full report in: https://bugs.python.org/issue43372

----------
nosy: +hroncok

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

From report at bugs.python.org  Tue Mar  2 17:39:20 2021
From: report at bugs.python.org (Steve Dower)
Date: Tue, 02 Mar 2021 22:39:20 +0000
Subject: [issue43284] Wrong windows build post version 2004
In-Reply-To: <1614695134.64.0.275564743591.issue43284@roundup.psfhosted.org>
Message-ID: <6f9c48f6-df5b-5bfe-fdf0-8dc4a58dcb50@python.org>


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

So somehow Windows made a rebuild *without* having to touch 
kernel32.dll, which is fairly impressive.

That version number comes from kernel32.dll, because there's no good way 
to get the build number via an API and also avoid compatibility settings 
lying about it.

I *guess* we need to find a better API for querying the current build 
number, hopefully without having to set up a whole WMI query.

----------

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

From report at bugs.python.org  Tue Mar  2 17:43:04 2021
From: report at bugs.python.org (bugale bugale)
Date: Tue, 02 Mar 2021 22:43:04 +0000
Subject: [issue43284] Wrong windows build post version 2004
In-Reply-To: <1613904146.72.0.850542213327.issue43284@roundup.psfhosted.org>
Message-ID: <1614724984.58.0.169705616713.issue43284@roundup.psfhosted.org>


bugale bugale <bugalit at gmail.com> added the comment:

Is there a good reason to not use GetVersionEx?

----------

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

From report at bugs.python.org  Tue Mar  2 09:40:34 2021
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Tue, 02 Mar 2021 14:40:34 +0000
Subject: [issue43372] ctypes: test_frozentable fails when make regen-frozen
Message-ID: <1614696034.15.0.923342699637.issue43372@roundup.psfhosted.org>


New submission from Miro Hron?ok <miro at hroncok.cz>:

The following test failure happens on Python 3.10.0a6+ when we make regen-frozen with the same Python version we test:

======================================================================
FAIL: test_frozentable (ctypes.test.test_values.PythonValuesTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/churchyard/Dokumenty/RedHat/cpython/Lib/ctypes/test/test_values.py", line 87, in test_frozentable
    self.assertEqual(items, expected, "PyImport_FrozenModules example "
AssertionError: Lists differ: [('__hello__', 129), ('__phello__', -129), ('__phello__.spam', 129)] != [('__hello__', 125), ('__phello__', -125), ('__phello__.spam', 125)]

First differing element 0:
('__hello__', 129)
('__hello__', 125)

- [('__hello__', 129), ('__phello__', -129), ('__phello__.spam', 129)]
?                  ^                     ^                         ^

+ [('__hello__', 125), ('__phello__', -125), ('__phello__.spam', 125)]
?                  ^                     ^                         ^
 : PyImport_FrozenModules example in Doc/library/ctypes.rst may be out of date

----------------------------------------------------------------------
Ran 494 tests in 0.466s

FAILED (failures=1, skipped=87)


Reproducer:

1. Build Python from source: $ ./configure && make -j...
2. Run ctypes tests: $ ./python -m ctypes.test
3. Regenerate frozen: $ PYTHON_FOR_REGEN=./python make regen-frozen
4. Build Python from source again: $ ./configure && make -j...
5. Run ctypes tests: $ ./python -m ctypes.test

Actual result:

Tests in (2) pass, tests in (5) fail.

The difference after (3) is:

diff --git a/Python/frozen_hello.h b/Python/frozen_hello.h
index 9c566cc81e..d58b726aa8 100644
--- a/Python/frozen_hello.h
+++ b/Python/frozen_hello.h
@@ -9,5 +9,5 @@ static unsigned char M___hello__[] = {
     100,218,5,112,114,105,110,116,169,0,114,2,0,
     0,0,114,2,0,0,0,218,4,110,111,110,101,
     218,8,60,109,111,100,117,108,101,62,1,0,0,
-    0,115,2,0,0,0,4,1,
+    0,115,6,0,0,0,4,0,12,1,255,128,
 };


Expected results:

Tests pass, no diff.

----------
components: Tests, ctypes
messages: 387933
nosy: hrnciar, hroncok
priority: normal
severity: normal
status: open
title: ctypes: test_frozentable fails when make regen-frozen
type: compile error
versions: Python 3.10

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

From report at bugs.python.org  Tue Mar  2 17:44:47 2021
From: report at bugs.python.org (OrbitalHorizons)
Date: Tue, 02 Mar 2021 22:44:47 +0000
Subject: [issue43284] Wrong windows build post version 2004
In-Reply-To: <1613904146.72.0.850542213327.issue43284@roundup.psfhosted.org>
Message-ID: <1614725087.33.0.391255557263.issue43284@roundup.psfhosted.org>


OrbitalHorizons <moserm1103 at gmail.com> added the comment:

Node Js version of os wasnt affected. If this is having an issue then they used some bootleg method to fetch the build number in the first place.

----------

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

From report at bugs.python.org  Tue Mar  2 09:48:40 2021
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Tue, 02 Mar 2021 14:48:40 +0000
Subject: [issue43372] ctypes: test_frozentable fails when make regen-frozen
In-Reply-To: <1614696034.15.0.923342699637.issue43372@roundup.psfhosted.org>
Message-ID: <1614696520.38.0.640598053931.issue43372@roundup.psfhosted.org>


Change by Miro Hron?ok <miro at hroncok.cz>:


----------
nosy: +nascheme

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

From report at bugs.python.org  Tue Mar  2 17:47:37 2021
From: report at bugs.python.org (Steve Dower)
Date: Tue, 02 Mar 2021 22:47:37 +0000
Subject: [issue43364] Add shortcut to enable UTF-8 mode in start menu.
In-Reply-To: <1614675827.66.0.411790166938.issue43364@roundup.psfhosted.org>
Message-ID: <1614725257.35.0.962962218519.issue43364@roundup.psfhosted.org>


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

For modifying an environment variable, please clone the entire path MSI and use an Environment element to update it. Should be a little simpler than that one, because it's a constant.

I'm always very hesitant to modify system-wide (or user-wide) settings like this though. I'd be more comfortable if we made it a PYTHONUTF8_310 variable that _only_ applies to that specific version. Otherwise someone might install an update and break existing apps.

Alternatively, for this kind of policy option, it might be nice to set up some common registry keys to define it. That is a function I've been thinking about for enabling some security features (such as malware scanning), and it mimics how Windows distributes its own configuration already. That'll take a whole PEP, though, and I doubt I'll get it ready in time for 3.10 given the other stuff I've got going on right now.

So provided we adequately document that the setting may impact other versions of Python besides the one being installed, and it's not enabled by default, I'm okay with an MSI-based addable/removable setting for PYTHONUTF8.

----------

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

From report at bugs.python.org  Tue Mar  2 09:54:05 2021
From: report at bugs.python.org (Sebastian Koslowski)
Date: Tue, 02 Mar 2021 14:54:05 +0000
Subject: [issue43367] submodule of c-extension module is quirky
In-Reply-To: <1614685283.59.0.727643422908.issue43367@roundup.psfhosted.org>
Message-ID: <1614696845.77.0.509207905.issue43367@roundup.psfhosted.org>


Sebastian Koslowski <sebastian.koslowski at gmail.com> added the comment:

>>> import parent.child

first imports "parent" (successfully) but then fails, because the import code has no knowledge of were to find ".child". This is because 
a) the module "parent" is not marked as a package (hence the error message) 
b) even if it were a package, there is no (ext) module file to locate and load.

If you instead run

>> from parent import child

only "parent" is imported, and "child" is retrieved as an attribute - which it actually is. The import code itself will add such an attribute, too [1]. However, that is after the submodule was located and loaded. Attribute lookup on the parent is not part of the submodule import itself.

A (hacky) work-around would be to add an entry for "parent.child" in sys.modules. This prevents the import machinery from running. 

A (more) proper solution would be to mark "parent" as a package and install some importlib hooks. See [2] for an example from Cython-land. 

Finally there is PyImport_AppendInittab() [3], which could possibly be used to register "parent.child". I have never tried that. Even if this worked, it would be unsupported and probably not without side-effects.

[1] https://docs.python.org/3/reference/import.html#submodules
[2] https://stackoverflow.com/questions/30157363/collapse-multiple-submodules-to-one-cython-extension
[3] https://docs.python.org/3/c-api/import.html?highlight=inittab#c.PyImport_AppendInittab

----------
nosy: +skoslowski

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

From report at bugs.python.org  Tue Mar  2 17:51:42 2021
From: report at bugs.python.org (=?utf-8?q?Filipe_La=C3=ADns?=)
Date: Tue, 02 Mar 2021 22:51:42 +0000
Subject: [issue42994] Missing MIME types for opus, AAC, 3gpp and 3gpp2
In-Reply-To: <1611265312.85.0.212937423943.issue42994@roundup.psfhosted.org>
Message-ID: <1614725502.06.0.992545612697.issue42994@roundup.psfhosted.org>


Change by Filipe La?ns <lains at riseup.net>:


----------
nosy: +barry, maxking, r.david.murray

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

From report at bugs.python.org  Tue Mar  2 09:54:35 2021
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Tue, 02 Mar 2021 14:54:35 +0000
Subject: [issue43372] ctypes: test_frozentable fails when make regen-frozen
In-Reply-To: <1614696034.15.0.923342699637.issue43372@roundup.psfhosted.org>
Message-ID: <1614696875.56.0.361316444675.issue43372@roundup.psfhosted.org>


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

When I run `PYTHON_FOR_REGEN=python3.10 make regen-frozen` with Python 3.10.0a5, I get the same diff and the same problem.

When I run `PYTHON_FOR_REGEN=python3.9 make regen-frozen` with Python 3.9.2, I get no diff and no problem (similarly with Python 3.8.8).

----------

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

From report at bugs.python.org  Tue Mar  2 18:11:16 2021
From: report at bugs.python.org (David Bolen)
Date: Tue, 02 Mar 2021 23:11:16 +0000
Subject: [issue43271] AMD64 Windows10 3.x crash with Windows fatal exception:
 stack overflow
In-Reply-To: <1613766414.64.0.363657915419.issue43271@roundup.psfhosted.org>
Message-ID: <1614726676.59.0.303028529229.issue43271@roundup.psfhosted.org>


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

Yes, that was the idea (revert the PyDEBUG condition only); it sounds like everyone is on the same page.

I've been doing buildbot duties only for a while (no code contributions since long before the current process), so there may be a short delay while I figure out this newfangled PR thing...

----------

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

From report at bugs.python.org  Tue Mar  2 18:14:30 2021
From: report at bugs.python.org (Steve Dower)
Date: Tue, 02 Mar 2021 23:14:30 +0000
Subject: [issue43284] Wrong windows build post version 2004
In-Reply-To: <1614725087.33.0.391255557263.issue43284@roundup.psfhosted.org>
Message-ID: <abcf82aa-f13e-2531-44f9-36e689173872@python.org>


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

The reason to avoid the GetVersion API is that certain automatic 
compatibility modes will lie about what the version number is, and 
people complained that it was wrong (kind of like this complaint ;) ). 
Reading the version from a system DLL bypasses that risk.

If your aim is to check the version for API compatibility/behaviour, 
then GetVersion is exactly the right thing to use, because it'll be 
adapted to match any compatibility options that are in effect. However, 
the platform module is not for this purpose, but is for logging system 
information. So we read from kernel32.dll instead (which is, yes, a 
bootleg way of doing it).

Node.js has some fairly horrible ways of doing this stuff on Windows. I 
haven't looked into this one in particular, but if they're not using 
GetVersion it wouldn't surprise me if they're running "cmd /C ver" and 
reading the output (don't even get me started on the security risks of 
that).

The most correct way is to query the system information service via WMI 
(which I'm 99% sure is what msinfo32.exe does). However, that's a _big_ 
step up in complexity, which is why we've avoided doing it to date. It 
might be the only viable option here if Windows is getting this good at 
shipping incremental rebuilds.

----------

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

From report at bugs.python.org  Tue Mar  2 11:10:31 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 02 Mar 2021 16:10:31 +0000
Subject: [issue43355] __future__.annotations breaks inspect.signature()
In-Reply-To: <1614614520.28.0.353733927276.issue43355@roundup.psfhosted.org>
Message-ID: <1614701431.28.0.755952514091.issue43355@roundup.psfhosted.org>


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

Can you show the values of ?expected? and ?actual? for both the failures and successes?

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

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

From report at bugs.python.org  Tue Mar  2 19:20:26 2021
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 03 Mar 2021 00:20:26 +0000
Subject: [issue42994] Missing MIME types for opus, AAC, 3gpp and 3gpp2
In-Reply-To: <1611265312.85.0.212937423943.issue42994@roundup.psfhosted.org>
Message-ID: <1614730826.05.0.0253761245374.issue42994@roundup.psfhosted.org>


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


New changeset 3a87e562ea21a5083e9f168e02e8ec3e6611e167 by Nathan Beals in branch 'master':
bpo-42994: Add MIME types for opus, AAC, 3gpp and 3gpp2 (#24287)
https://github.com/python/cpython/commit/3a87e562ea21a5083e9f168e02e8ec3e6611e167


----------
nosy: +orsenthil

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

From report at bugs.python.org  Tue Mar  2 19:21:02 2021
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 03 Mar 2021 00:21:02 +0000
Subject: [issue42994] Missing MIME types for opus, AAC, 3gpp and 3gpp2
In-Reply-To: <1611265312.85.0.212937423943.issue42994@roundup.psfhosted.org>
Message-ID: <1614730862.32.0.015924780254.issue42994@roundup.psfhosted.org>


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

Thanks for the this contribution, Nathan.

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

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

From report at bugs.python.org  Tue Mar  2 19:36:29 2021
From: report at bugs.python.org (jennydaman)
Date: Wed, 03 Mar 2021 00:36:29 +0000
Subject: [issue43380] Assigning function parameter to class attribute by the
 same name
Message-ID: <1614731789.13.0.0370276321832.issue43380@roundup.psfhosted.org>


New submission from jennydaman <jdmzh+python at protonmail.com>:

# Example

Consider these three examples, which are theoretically identical

```
a = 4

class A:
    a = a

print(A.a)

def createB(b):
    class B:
        z = b
    print(B.z)
    
createB(5)

def createD(D):
    class D:
        d = d
    print(D.d)
    
createD(6)
```

## Expected Output

```
4
5
6
```

## Actual Output

```
4
5
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in createD
  File "<stdin>", line 3, in D
NameError: name 'd' is not defined
```

----------
components: Interpreter Core
messages: 387987
nosy: jennydaman
priority: normal
severity: normal
status: open
title: Assigning function parameter to class attribute by the same name
type: behavior
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Tue Mar  2 19:45:29 2021
From: report at bugs.python.org (Peter Donis)
Date: Wed, 03 Mar 2021 00:45:29 +0000
Subject: [issue43049] Use io.IncrementalNewlineDecoder for doctest newline
 conversion
In-Reply-To: <1611799804.84.0.215071854075.issue43049@roundup.psfhosted.org>
Message-ID: <1614732329.11.0.49002577082.issue43049@roundup.psfhosted.org>


Peter Donis <peterdonis at alum.mit.edu> added the comment:

Thanks for merging!

----------

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

From report at bugs.python.org  Tue Mar  2 19:47:15 2021
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 03 Mar 2021 00:47:15 +0000
Subject: [issue43288] test_importlib failure due to missing skip() method
In-Reply-To: <1613934277.61.0.647402041317.issue43288@roundup.psfhosted.org>
Message-ID: <1614732435.53.0.307044302603.issue43288@roundup.psfhosted.org>


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


----------
assignee:  -> nascheme
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/issue43288>
_______________________________________

From report at bugs.python.org  Tue Mar  2 19:50:17 2021
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 03 Mar 2021 00:50:17 +0000
Subject: [issue43075] ReDoS in request
In-Reply-To: <1611994306.46.0.333529770265.issue43075@roundup.psfhosted.org>
Message-ID: <1614732617.75.0.134196804029.issue43075@roundup.psfhosted.org>


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


----------
keywords: +easy (C)

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

From report at bugs.python.org  Tue Mar  2 19:52:30 2021
From: report at bugs.python.org (Neil Schemenauer)
Date: Wed, 03 Mar 2021 00:52:30 +0000
Subject: [issue43381] add small test for frozen module line number table
Message-ID: <1614732750.02.0.00856334728328.issue43381@roundup.psfhosted.org>


New submission from Neil Schemenauer <nas-python at arctrix.com>:

In bug #43372, we didn't notice that the code for the __hello__ module was not re-generated.  Things seems to be okay but the line number table was corrupted.  It seems a good idea to add a small test to ensure that doesn't happen again.

I marked the test as CPython implementation specific.

----------
components: Tests
messages: 387989
nosy: nascheme
priority: low
severity: normal
stage: patch review
status: open
title: add small test for frozen module line number table
type: enhancement

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

From report at bugs.python.org  Tue Mar  2 20:01:59 2021
From: report at bugs.python.org (Neil Schemenauer)
Date: Wed, 03 Mar 2021 01:01:59 +0000
Subject: [issue43381] add small test for frozen module line number table
In-Reply-To: <1614732750.02.0.00856334728328.issue43381@roundup.psfhosted.org>
Message-ID: <1614733319.37.0.297082691224.issue43381@roundup.psfhosted.org>


Change by Neil Schemenauer <nas-python at arctrix.com>:


----------
keywords: +patch
pull_requests: +23490
pull_request: https://github.com/python/cpython/pull/24712

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

From report at bugs.python.org  Tue Mar  2 20:21:09 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 03 Mar 2021 01:21:09 +0000
Subject: [issue43380] Assigning function parameter to class attribute by the
 same name
In-Reply-To: <1614731789.13.0.0370276321832.issue43380@roundup.psfhosted.org>
Message-ID: <1614734469.73.0.859525117126.issue43380@roundup.psfhosted.org>


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

Was 
def createD(D):

supposed to be:
def createD(d):

?

Not that that changes your problem. I just want to understand the exact issue.

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

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

From report at bugs.python.org  Tue Mar  2 20:22:53 2021
From: report at bugs.python.org (jennydaman)
Date: Wed, 03 Mar 2021 01:22:53 +0000
Subject: [issue43380] Assigning function parameter to class attribute by the
 same name
In-Reply-To: <1614731789.13.0.0370276321832.issue43380@roundup.psfhosted.org>
Message-ID: <1614734573.45.0.695209278745.issue43380@roundup.psfhosted.org>


jennydaman <jdmzh+python at protonmail.com> added the comment:

# Example

Consider these three examples, which are theoretically identical

```
a = 4

class A:
    a = a

print(A.a)

def createB(b):
    class B:
        z = b
    print(B.z)
    
createB(5)

def createD(d):
    class D:
        d = d
    print(D.d)
    
createD(6)
```

## Expected Output

```
4
5
6
```

## Actual Output

```
4
5
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in createD
  File "<stdin>", line 3, in D
NameError: name 'd' is not defined
```

----------

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

From report at bugs.python.org  Tue Mar  2 20:23:09 2021
From: report at bugs.python.org (jennydaman)
Date: Wed, 03 Mar 2021 01:23:09 +0000
Subject: [issue43380] Assigning function parameter to class attribute by the
 same name
In-Reply-To: <1614731789.13.0.0370276321832.issue43380@roundup.psfhosted.org>
Message-ID: <1614734589.01.0.893908252586.issue43380@roundup.psfhosted.org>


jennydaman <jdmzh+python at protonmail.com> added the comment:

Yes sorry that was a typo

----------

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

From report at bugs.python.org  Tue Mar  2 20:26:08 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 03 Mar 2021 01:26:08 +0000
Subject: [issue43378] Pattern Matching section in tutorial refers to | as or
In-Reply-To: <1614720567.85.0.819945578913.issue43378@roundup.psfhosted.org>
Message-ID: <1614734768.1.0.742485592093.issue43378@roundup.psfhosted.org>


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

This seems fine to me.   In pattern matching, it has both the meaning and pronunciation of "or":

    case "this" | "that": ...

It has similar mean in the re module:

    r'abc|def'

And it is also used the same way in typing:

   s: list | tuple

We've also long used it for sets:

   rich | tall       # People who are either rich OR tall  

Based on this, I don't there is any reason to suspect it will be confused with bitwise-or.

The only place the operator really isn't harmonious is with dicts where its meaning is "update" and where it isn't commutative.

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

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

From report at bugs.python.org  Tue Mar  2 21:29:54 2021
From: report at bugs.python.org (Neil Schemenauer)
Date: Wed, 03 Mar 2021 02:29:54 +0000
Subject: [issue43372] ctypes: test_frozentable fails when make regen-frozen
In-Reply-To: <1614696034.15.0.923342699637.issue43372@roundup.psfhosted.org>
Message-ID: <1614738594.62.0.40887056502.issue43372@roundup.psfhosted.org>


Change by Neil Schemenauer <nas-python at arctrix.com>:


----------
pull_requests: +23491
pull_request: https://github.com/python/cpython/pull/24714

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

From report at bugs.python.org  Tue Mar  2 21:29:54 2021
From: report at bugs.python.org (Neil Schemenauer)
Date: Wed, 03 Mar 2021 02:29:54 +0000
Subject: [issue42246] Implement PEP 626 -- Precise line numbers for debugging
In-Reply-To: <1604331162.26.0.596873070589.issue42246@roundup.psfhosted.org>
Message-ID: <1614738594.69.0.551716658599.issue42246@roundup.psfhosted.org>


Change by Neil Schemenauer <nas-python at arctrix.com>:


----------
pull_requests: +23492
pull_request: https://github.com/python/cpython/pull/24714

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

From report at bugs.python.org  Tue Mar  2 21:45:12 2021
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 03 Mar 2021 02:45:12 +0000
Subject: [issue43075] ReDoS in urllib.request
In-Reply-To: <1611994306.46.0.333529770265.issue43075@roundup.psfhosted.org>
Message-ID: <1614739512.43.0.636763428441.issue43075@roundup.psfhosted.org>


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


----------
title: ReDoS in request -> ReDoS in urllib.request

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

From report at bugs.python.org  Tue Mar  2 21:56:46 2021
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 03 Mar 2021 02:56:46 +0000
Subject: [issue43363] memcpy writes to wrong destination
In-Reply-To: <1614657972.58.0.514518205696.issue43363@roundup.psfhosted.org>
Message-ID: <1614740206.52.0.607960478263.issue43363@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

Agreed, stack is a PyObject**, so adding an integer (pto_nargs) to the pointer (stack) is implicitly by multiples of sizeof(PyObject*). This is how pointer arithmetic works in all versions of C I'm aware of. The code is correct.

----------
nosy: +josh.r
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Mar  2 22:00:23 2021
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 03 Mar 2021 03:00:23 +0000
Subject: [issue43075] ReDoS in urllib.request
In-Reply-To: <1611994306.46.0.333529770265.issue43075@roundup.psfhosted.org>
Message-ID: <1614740423.2.0.288182227114.issue43075@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
keywords: +easy -easy (C), patch

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

From report at bugs.python.org  Tue Mar  2 22:02:02 2021
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 03 Mar 2021 03:02:02 +0000
Subject: [issue43075] ReDoS in urllib.request
In-Reply-To: <1611994306.46.0.333529770265.issue43075@roundup.psfhosted.org>
Message-ID: <1614740522.66.0.608240316738.issue43075@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
keywords: +patch

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

From report at bugs.python.org  Tue Mar  2 22:14:51 2021
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 03 Mar 2021 03:14:51 +0000
Subject: [issue43371] Mock.assert_has_calls works strange
In-Reply-To: <1614695494.31.0.773020245058.issue43371@roundup.psfhosted.org>
Message-ID: <1614741291.25.0.990203518103.issue43371@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/issue43371>
_______________________________________

From report at bugs.python.org  Tue Mar  2 22:38:42 2021
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 03 Mar 2021 03:38:42 +0000
Subject: [issue43364] Add shortcut to enable UTF-8 mode in start menu.
In-Reply-To: <1614675827.66.0.411790166938.issue43364@roundup.psfhosted.org>
Message-ID: <1614742722.49.0.691829702285.issue43364@roundup.psfhosted.org>


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

> You can run "[WindowsFolder]System32\setx.exe" directly. It's not a shell command.

Thank you. I will do.

> For modifying an environment variable, please clone the entire path MSI and use an Environment element to update it. Should be a little simpler than that one, because it's a constant.

How about having both? Shortcut menu is more accessible when user want to enable UTF-8 mode after they install Python. (e.g. they got troubled by UnicodeDecodeError and are adviced to enable UTF-8 mode).

> Alternatively, for this kind of policy option, it might be nice to set up some common registry keys to define it. That is a function I've been thinking about for enabling some security features (such as malware scanning), and it mimics how Windows distributes its own configuration already. That'll take a whole PEP, though, and I doubt I'll get it ready in time for 3.10 given the other stuff I've got going on right now.

Registry is also discussed in the thread, but there are no consensus about adding new way to enable UTF-8 mode.
I conclude that we should promote existing way (i.e. envvar) and get feedback from users.

> So provided we adequately document that the setting may impact other versions of Python besides the one being installed, and it's not enabled by default, I'm okay with an MSI-based addable/removable setting for PYTHONUTF8.

----------

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

From report at bugs.python.org  Tue Mar  2 22:41:59 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 03 Mar 2021 03:41:59 +0000
Subject: [issue43378] Pattern Matching section in tutorial refers to | as or
In-Reply-To: <1614720567.85.0.819945578913.issue43378@roundup.psfhosted.org>
Message-ID: <1614742919.84.0.237896171801.issue43378@roundup.psfhosted.org>


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

Another other thought, PEP 634 defines "|" as being an "or-pattern", so it part of the spec:

  https://www.python.org/dev/peps/pep-0634/#or-patterns

----------

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

From report at bugs.python.org  Tue Mar  2 22:43:07 2021
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 03 Mar 2021 03:43:07 +0000
Subject: [issue35935] threading.Event().wait() not interruptable with Ctrl-C
 on Windows
In-Reply-To: <1549588377.49.0.765820535798.issue35935@roundup.psfhosted.org>
Message-ID: <1614742987.13.0.0094804134135.issue35935@roundup.psfhosted.org>


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

> But on this particular issue, making the unconditional wait be 
> interruptable by signals shouldn't be impossible.

PyThread_acquire_lock_timed() in Python/thread_nt.h currently ignores intr_flag. The current implementation calls EnterNonRecursiveMutex(), which in turn calls PyCOND_WAIT() / PyCOND_TIMEDWAIT() in Python/condvar.h. EnterNonRecursiveMutex() needs to support intr_flag and support a return value that indicates the wait was interrupted. PyThread_acquire_lock_timed() needs to handle this value by returning PY_LOCK_INTR.

When using emulated condition variables, a lock combines a semaphore and a critical section. Waiting on the semaphore can be integrated with the SIGINT event via WaitForMultipleObjects(). 

Here's a replacement for WaitForSingleObject() that integrates the SIGINT event, and supports long waits passed as a PY_TIMEOUT_T in microseconds (just for the sake of discussion; it's not rigorously tested code):

    unsigned long
    _Py_WaitForSingleObject(void *handle, PY_TIMEOUT_T microseconds,
                            int intr_flag)
    {
        DWORD result;
        DWORD handle_count;
        HANDLE handle_array[2];
        HANDLE sigint_event = NULL;

        LONGLONG timeout = -1;
        ULONGLONG deadline = 0;

        /* Store timeout in system time units of 100 ns. */
        if (microseconds >= 0) {
            QueryUnbiasedInterruptTime(&deadline);
            timeout = microseconds * 10;
            deadline += timeout;
        }

        handle_count = 1;
        handle_array[0] = (HANDLE)handle;

        if (intr_flag) {
            sigint_event = _PyOS_SigintEvent();
            if (sigint_event) {
                handle_array[handle_count++] = sigint_event;
                ResetEvent(sigint_event);
            }
        }

        do {
            ULONGLONG now;
            DWORD milliseconds;

            if (timeout < 0) {
                milliseconds = INFINITE;
            } else if (timeout < INFINITE * 10000) {
                milliseconds = timeout / 10000;
            } else {
                milliseconds = INFINITE - 1;
            }

            result = WaitForMultipleObjectsEx(
                        handle_count, handle_array, FALSE,
                        milliseconds, FALSE);

            if (sigint_event && result == WAIT_OBJECT_0 + 1) {
                /* Pretend that this was an alertable wait that
                   was interrupted by a user-mode APC queued to
                   the main thread by the C signal handler. It's
                   not implemented that way, but it could be. */
                result = STATUS_USER_APC;
            }

            if (result != WAIT_TIMEOUT) {
                break;
            }

            QueryUnbiasedInterruptTime(&now);
            timeout = deadline - now;
        } while (timeout >= 0);

        return result;
    }

If the wait returns STATUS_USER_APC, then the caller should call PyErr_CheckSignals(). intr_flag would presumably only be true when called from a thread that can handle signals, i.e. when _PyOS_IsMainThread() is true.

That said, if actual Windows condition variables are used (an alternate implementation in Python/condvar.h), then waiting is implemented via SleepConditionVariableSRW(). There's no way to integrate the SIGINT event with this wait, nor any documented way to cancel the wait from the console control thread. If this implementation is adopted, then maybe the few cases that require locks that support an interruptible wait can be implemented as a separate thread API.

----------
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.7, Python 3.7

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

From report at bugs.python.org  Tue Mar  2 23:07:07 2021
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 03 Mar 2021 04:07:07 +0000
Subject: [issue43371] Mock.assert_has_calls works strange
In-Reply-To: <1614695494.31.0.773020245058.issue43371@roundup.psfhosted.org>
Message-ID: <1614744427.98.0.800737251048.issue43371@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/issue43371>
_______________________________________

From report at bugs.python.org  Tue Mar  2 23:29:04 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 03 Mar 2021 04:29:04 +0000
Subject: [issue43382] github CI blocked by the Ubuntu CI with an SSL error
Message-ID: <1614745744.43.0.675662116863.issue43382@roundup.psfhosted.org>


New submission from Gregory P. Smith <greg at krypto.org>:

https://github.com/python/cpython/pull/20442/checks?check_run_id=2018900756

 ssl.SSLError: [SSL: TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca (_ssl.c:1122)
[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1122)
 ssl.SSLError: [SSL: SSLV3_ALERT_BAD_CERTIFICATE] sslv3 alert bad certificate (_ssl.c:1122)
 ssl.SSLError: [SSL] internal error (_ssl.c:1122)
 ssl.SSLError: [SSL] called a function you should not call (_ssl.c:1122)
 ssl.SSLEOFError: EOF occurred in violation of protocol (_ssl.c:1122)
 ssl.SSLError: [SSL: UNEXPECTED_MESSAGE] unexpected message (_ssl.c:1122)
ssl.SSLError: [SSL: TLSV1_ALERT_INTERNAL_ERROR] tlsv1 alert internal error (_ssl.c:1122)
[SSL: NO_PROTOCOLS_AVAILABLE] no protocols available (_ssl.c:1122)

... and so on ...

This CI failure is preventing any PR from being merged.

Do we have a bad test certificate in the tree we need to update?
Or did some Ubuntu CI infrastructure just fall over and start rejecting a certificate it used to accept?

I believe this started around ~20210302T1500 UTC.

----------
assignee: christian.heimes
components: Build, SSL, Tests
messages: 387998
nosy: christian.heimes, gregory.p.smith, lukasz.langa, ned.deily
priority: release blocker
severity: normal
status: open
title: github CI blocked by the Ubuntu CI with an SSL error
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/issue43382>
_______________________________________

From report at bugs.python.org  Tue Mar  2 23:48:00 2021
From: report at bugs.python.org (Konrad Schwarz)
Date: Wed, 03 Mar 2021 04:48:00 +0000
Subject: [issue43383] imprecise handling of weakref callbacks
Message-ID: <1614746880.88.0.974985202377.issue43383@roundup.psfhosted.org>


New submission from Konrad Schwarz <konrad.schwarz at gmail.com>:

I am seeing the following non-deterministic behavior:

My code processes DeviceTree, a tree-based specification format for hardware descriptions, that includes cross-references ("phandles").  For all intents and purposes, this format is similar to XML; phandles are analog to ID/IDREFS.

To prevent reference cycles and avoid the need for garbage collection, my code uses weakref.proxy for parent pointers and weakref.ref for cross-references.

My goal is to provide a "projection" operation on a DeviceTree: creating derived DeviceTrees that model subsets of the hardware (this is to partition the hardware into multiple independent sub-machines).  The projection is specified by newly introduced nodes and attributes (aka properties) in the tree; phandles are used to indicate which part belongs to which partition.

Python weak references provide a callback interface to indicate the demise of their referents and my code uses that to prune the tree: e.g., if a node modeling a partition is deleted, nodes that reference that node (i.e., indicate they belong to that partition) are deleted in the corresponding weakref callback.  So technically, the code implicitly uses the interpreters list of weak referrers (__weakref__) to find and execute code on them when the referent's state changes.

This works exactly as envisioned when single-stepping in PDB.

When running at full speed however, I see that weak reference callbacks are being triggered after the corresponding weak reference has been deleted with del (the weak reference is a value of a Python dict holding a node's attributes.)

I suspect that this is because of some batching or deferred processing in the Python interpreter.

Ultimately, this is a violation of the semantics and must be classified as a bug.

However, in my case, it would suffice to have a "memory barrier" type of operation that flushes the queue of deferred deletions before continuing.  Something like that must exist, because single stepping in PDB is successful.

Initial tests of calling the garbage collector to this end were inconclusive, unfortunately.

----------
components: Interpreter Core
messages: 387999
nosy: konrad.schwarz
priority: normal
severity: normal
status: open
title: imprecise handling of weakref callbacks
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Wed Mar  3 00:35:10 2021
From: report at bugs.python.org (Brandt Bucher)
Date: Wed, 03 Mar 2021 05:35:10 +0000
Subject: [issue43382] github CI blocked by the Ubuntu CI with an SSL error
In-Reply-To: <1614745744.43.0.675662116863.issue43382@roundup.psfhosted.org>
Message-ID: <1614749710.46.0.544580501532.issue43382@roundup.psfhosted.org>


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

It seems that GitHub recently changed their "ubuntu-latest" image from Ubuntu 18.04 to Ubuntu 20.04.

A good temporary workaround would probably be to change this line:

https://github.com/python/cpython/blob/727a68b6e592eada5a65935de5c8428ef50e8741/.github/workflows/build.yml#L130

...to read "ubuntu-18.04".

----------
nosy: +brandtbucher

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

From report at bugs.python.org  Wed Mar  3 00:39:58 2021
From: report at bugs.python.org (Eli Schwartz)
Date: Wed, 03 Mar 2021 05:39:58 +0000
Subject: [issue40059] Provide a toml module in the standard library
In-Reply-To: <1585119261.47.0.818238682424.issue40059@roundup.psfhosted.org>
Message-ID: <1614749998.17.0.91147209166.issue40059@roundup.psfhosted.org>


Change by Eli Schwartz <eschwartz93 at gmail.com>:


----------
nosy: +eschwartz

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

From report at bugs.python.org  Wed Mar  3 00:48:48 2021
From: report at bugs.python.org (Brandt Bucher)
Date: Wed, 03 Mar 2021 05:48:48 +0000
Subject: [issue43382] github CI blocked by the Ubuntu CI with an SSL error
In-Reply-To: <1614745744.43.0.675662116863.issue43382@roundup.psfhosted.org>
Message-ID: <1614750528.36.0.532870926341.issue43382@roundup.psfhosted.org>


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

I forgot to mention that I confirmed that the last passing test run used 18.04 (click "set up job" -> "Operating System" to see):

https://github.com/python/cpython/runs/2013210763?check_suite_focus=true

The next one, which started the current chain of failures, used 20.04:

https://github.com/python/cpython/runs/2018900756?check_suite_focus=true

I'm still not sure *why* this broke CI, though. Perhaps our cached OpenSSL is no longer valid?

----------

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

From report at bugs.python.org  Wed Mar  3 01:05:29 2021
From: report at bugs.python.org (Brandt Bucher)
Date: Wed, 03 Mar 2021 06:05:29 +0000
Subject: [issue43382] github CI blocked by the Ubuntu CI with an SSL error
In-Reply-To: <1614745744.43.0.675662116863.issue43382@roundup.psfhosted.org>
Message-ID: <1614751529.0.0.529726369617.issue43382@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Wed Mar  3 01:42:16 2021
From: report at bugs.python.org (Neil Schemenauer)
Date: Wed, 03 Mar 2021 06:42:16 +0000
Subject: [issue43382] github CI blocked by the Ubuntu CI with an SSL error
In-Reply-To: <1614745744.43.0.675662116863.issue43382@roundup.psfhosted.org>
Message-ID: <1614753736.68.0.644043450667.issue43382@roundup.psfhosted.org>


Neil Schemenauer <nas-python at arctrix.com> added the comment:

I think it may be related to bpo-41561.  There is a bug in the Ubuntu tracker as well:

https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1899878

I agree with the temporary fix to use "ubuntu-18.04" for CI testing.

----------
nosy: +nascheme

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

From report at bugs.python.org  Wed Mar  3 02:08:09 2021
From: report at bugs.python.org (Neil Schemenauer)
Date: Wed, 03 Mar 2021 07:08:09 +0000
Subject: [issue43384] Include regen-stdlib-module-names in regen-all
Message-ID: <1614755289.13.0.914626827133.issue43384@roundup.psfhosted.org>


New submission from Neil Schemenauer <nas-python at arctrix.com>:

While I was fixing the regen-frozen issue, I noticed it seems unnecessary to have regen-stdlib-module-names separate from regen-all.  Maybe Victor knows why it needs to be separate.  If it doesn't need to be separate, the CI scripts can be slightly simplified.

----------
components: Build
messages: 388003
nosy: nascheme
priority: normal
severity: normal
stage: patch review
status: open
title: Include regen-stdlib-module-names in regen-all
type: enhancement

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

From report at bugs.python.org  Wed Mar  3 02:08:35 2021
From: report at bugs.python.org (Neil Schemenauer)
Date: Wed, 03 Mar 2021 07:08:35 +0000
Subject: [issue43384] Include regen-stdlib-module-names in regen-all
In-Reply-To: <1614755289.13.0.914626827133.issue43384@roundup.psfhosted.org>
Message-ID: <1614755315.59.0.0183501130913.issue43384@roundup.psfhosted.org>


Change by Neil Schemenauer <nas-python at arctrix.com>:


----------
keywords: +patch
pull_requests: +23494
pull_request: https://github.com/python/cpython/pull/24713

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

From report at bugs.python.org  Wed Mar  3 02:29:51 2021
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 03 Mar 2021 07:29:51 +0000
Subject: [issue43382] github CI blocked by the Ubuntu CI with an SSL error
In-Reply-To: <1614745744.43.0.675662116863.issue43382@roundup.psfhosted.org>
Message-ID: <1614756591.36.0.226583117906.issue43382@roundup.psfhosted.org>


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

Thanks for the quick workaround!

The problem could be caused by a downstream patch in Ubuntu's OpenSSL version. Vanilla OpenSSL doesn't fail like that.

----------

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

From report at bugs.python.org  Wed Mar  3 03:22:36 2021
From: report at bugs.python.org (=?utf-8?q?Max_B=C3=A9langer?=)
Date: Wed, 03 Mar 2021 08:22:36 +0000
Subject: [issue43377] _PyErr_Display should be available in the
 CPython-specific API
In-Reply-To: <1614717737.06.0.355391552087.issue43377@roundup.psfhosted.org>
Message-ID: <1614759756.42.0.238720840142.issue43377@roundup.psfhosted.org>


Change by Max B?langer <aeromax at gmail.com>:


----------
keywords: +patch
nosy: +maxbelanger
nosy_count: 1.0 -> 2.0
pull_requests: +23495
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24719

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

From report at bugs.python.org  Wed Mar  3 03:55:52 2021
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 03 Mar 2021 08:55:52 +0000
Subject: [issue43380] Assigning function parameter to class attribute by the
 same name
In-Reply-To: <1614731789.13.0.0370276321832.issue43380@roundup.psfhosted.org>
Message-ID: <1614761752.62.0.570140244342.issue43380@roundup.psfhosted.org>


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

Here's an example that shows what is going on:


def demo():
    a = 1
    class B:
        x = a
    print(B.x)  # Okay.
    
    class C:
        x = a  # Fails.
        if False:
            a = None
    print(C.x)


If you run that, B.x is printed (1) but assigning to C.x fails:

>>> demo()
1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 7, in demo
  File "<stdin>", line 8, in C
NameError: name 'a' is not defined


The reason is that inside a function, assignment to a name makes it a local. This interacts oddly with class scope.

By the way, I get the same results with this all the way back to Python 2.4. (I don't have older versions to test.) So this has existed for a very long time.

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

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

From report at bugs.python.org  Wed Mar  3 03:59:15 2021
From: report at bugs.python.org (Dimitri John Ledkov)
Date: Wed, 03 Mar 2021 08:59:15 +0000
Subject: [issue43382] github CI blocked by the Ubuntu CI with an SSL error
In-Reply-To: <1614745744.43.0.675662116863.issue43382@roundup.psfhosted.org>
Message-ID: <1614761955.11.0.441886705407.issue43382@roundup.psfhosted.org>


Dimitri John Ledkov <dimitri.ledkov at canonical.com> added the comment:

Ubuntu 20.04+ compile OpenSSL with default security level set to 2, and further customized security level 2 to prohibit TLS below v1.2 and DTLS below v1.2.

You can export custom openssl configuration that sets security level back to 1, which is compatible across any openssl series.

```
export OPENSSL_CONF=`pwd`/openssl.cnf
cat openssl.cnf
openssl_conf = default_conf
[default_conf]
ssl_conf = ssl_sect
[ssl_sect]
system_default = system_default_sect
[system_default_sect]
CipherString = DEFAULT at SECLEVEL=1
```

Or you can use native APIs to reset the security level to 1 in the test-suite. I.e. via the SSL_CTX_set_security_level api binding.

This is documented behaviour in Ubuntu manpages of OpenSSL and on Ubuntu Discourse

https://manpages.ubuntu.com/manpages/focal/en/man3/SSL_CTX_set_security_level.3ssl.html

https://discourse.ubuntu.com/t/default-to-tls-v1-2-in-all-tls-libraries-in-20-04-lts/12464/8

OpenSSL upstream for 3.0.0 series are refusing to bump minimum required protocol versions to prohibit out of the box old version of TLS and also don't have a standard way to disable this. Hence implementation is different in Debian, Ubuntu and Fedora. Debian's implementation is buggy with respect to DTLS and default openssl.cnf breaks 1.0.2x series libssl. And as far as I know Fedora implementation requires use of crypto-policies package which is quite advanced and not trivial to integrate in smaller environments.

----------
nosy: +xnox

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

From report at bugs.python.org  Wed Mar  3 04:00:57 2021
From: report at bugs.python.org (Dimitri John Ledkov)
Date: Wed, 03 Mar 2021 09:00:57 +0000
Subject: [issue43382] github CI blocked by the Ubuntu CI with an SSL error
In-Reply-To: <1614745744.43.0.675662116863.issue43382@roundup.psfhosted.org>
Message-ID: <1614762057.24.0.89735871888.issue43382@roundup.psfhosted.org>


Dimitri John Ledkov <dimitri.ledkov at canonical.com> added the comment:

BTW.

It would be advisable for Python3 to start enforcing security level 2, and prohibit DTLS v1.1 and lower by default too. By configuring openssl library on the host with setting security level, and/or setting min versions (if openssl on the host supports such api). Because allowing to use TLS v1.1 and lower out of the box is irresponsible.

----------

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

From report at bugs.python.org  Wed Mar  3 04:19:41 2021
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 03 Mar 2021 09:19:41 +0000
Subject: [issue43380] Assigning function parameter to class attribute by the
 same name
In-Reply-To: <1614731789.13.0.0370276321832.issue43380@roundup.psfhosted.org>
Message-ID: <1614763181.37.0.736687024796.issue43380@roundup.psfhosted.org>


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

Looking at the disassembly of the demo() function also shows differences between the B and C classes.

I seem to recall discussion about this on, maybe, the Python-Dev list. I think resolving this will probably have to wait on a re-design of the exact scoping rules with respect to classes inside functions.

----------

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

From report at bugs.python.org  Wed Mar  3 04:23:41 2021
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 03 Mar 2021 09:23:41 +0000
Subject: [issue43382] github CI blocked by the Ubuntu CI with an SSL error
In-Reply-To: <1614745744.43.0.675662116863.issue43382@roundup.psfhosted.org>
Message-ID: <1614763421.21.0.612976619052.issue43382@roundup.psfhosted.org>


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

Dimitri, thanks for your feedback.

I'm very well aware of the crypto policy settings and security level settings. The problem is not the fact that Ubuntu sets a higher security level and disables insecure TLS versions. The problem is the way how Ubuntu has implemented the policy to enforce the crypto settings.

Other Linux distributions like Debian and Fedora also raise the security level and disable TLS 1.0 and 1.1. Python's test suite introspects OpenSSL settings and skips tests accordingly. test_ssl is passing fine on Debian testing (updated 15 minutes ago) and Fedora 33 with similar crypto policies. Since the tests are working fine on Debian, Fedora, RHEL/CentOS, vanilla OpenSSL, our OpenSSL builds on macOS and Windows, and other Linux distros, the issue is likely caused by a downstream discrepancy in Ubuntu.

# Python main branch on Fedora 33
$ ./python 
Python 3.10.0a5+ (heads/master:cd80f430daa, Feb 24 2021, 19:44:57) 
[GCC 10.2.1 20201125 (Red Hat 10.2.1-9)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ssl
>>> ctx = ssl.create_default_context()
>>> ctx.minimum_version
<TLSVersion.TLSv1_2: 771>
>>> ctx.security_level
2

# Python main branch on Debian testing
$ ./python 
Python 3.10.0a6+ (heads/master:94894dd45e, Mar  3 2021, 09:11:22) [GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ssl
>>> ctx = ssl.create_default_context()
>>> ctx.minimum_version
<TLSVersion.TLSv1_2: 771>
>>> ctx.security_level
2

$ ./python -m test test_ssl
0:00:00 load avg: 0.89 Run tests sequentially
0:00:00 load avg: 0.89 [1/1] test_ssl

== Tests result: SUCCESS ==

1 test OK.

Total duration: 2.6 sec
Tests result: SUCCESS

# dpkg -l openssl
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version      Architecture Description
+++-==============-============-============-====================================================
ii  openssl        1.1.1j-1     amd64        Secure Sockets Layer toolkit - cryptographic utility

----------

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

From report at bugs.python.org  Wed Mar  3 04:27:53 2021
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 03 Mar 2021 09:27:53 +0000
Subject: [issue43382] github CI blocked by the Ubuntu CI with an SSL error
In-Reply-To: <1614745744.43.0.675662116863.issue43382@roundup.psfhosted.org>
Message-ID: <1614763673.51.0.107197216363.issue43382@roundup.psfhosted.org>


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

> It would be advisable for Python3 to start enforcing security level 2, and prohibit DTLS v1.1 and lower by default too. By configuring openssl library on the host with setting security level, and/or setting min versions (if openssl on the host supports such api). Because allowing to use TLS v1.1 and lower out of the box is irresponsible.

We are going to change the default settings in our own OpenSSL builds together with https://www.python.org/dev/peps/pep-0644/ . For Linux distros we will rely on distro-wide crypto policies.

----------

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

From report at bugs.python.org  Wed Mar  3 04:58:42 2021
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 03 Mar 2021 09:58:42 +0000
Subject: [issue43382] github CI blocked by the Ubuntu CI with an SSL error
In-Reply-To: <1614745744.43.0.675662116863.issue43382@roundup.psfhosted.org>
Message-ID: <1614765522.74.0.97347295649.issue43382@roundup.psfhosted.org>


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

I have backported the workaround to 3.7, 3.8, and 3.9. There was some issue with the backport bot and I didn't have time to investigate. PRs are:

https://github.com/python/cpython/pull/24716
https://github.com/python/cpython/pull/24717
https://github.com/python/cpython/pull/24718

----------

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

From report at bugs.python.org  Wed Mar  3 05:09:09 2021
From: report at bugs.python.org (=?utf-8?q?Micha=C5=82_Kozik?=)
Date: Wed, 03 Mar 2021 10:09:09 +0000
Subject: [issue43385] heapq fails to sort tuples by datetime correctly
Message-ID: <1614766149.48.0.609887863234.issue43385@roundup.psfhosted.org>


New submission from Micha? Kozik <mike.koikos at gmail.com>:

Tuples (datetime, description) all are sorted by the date except one entry (2021-03-09) which is out of order:

        Expected order:             Actual order:
        2021-03-04 Event E          2021-03-04 Event E
        2021-03-07 Event B          2021-03-07 Event B
        2021-03-08 Event C          2021-03-08 Event C
        2021-03-09 Event A          2021-03-11 Event D
        2021-03-11 Event D          2021-03-09 Event A

In REPL it can be replicated by pasting the following code:

import heapq
from datetime import datetime

event_a = (datetime.strptime('2021-03-09', '%Y-%m-%d'), "Event A")
event_b = (datetime.strptime('2021-03-07', '%Y-%m-%d'), "Event B")
event_c = (datetime.strptime('2021-03-08', '%Y-%m-%d'), "Event C")
event_d = (datetime.strptime('2021-03-11', '%Y-%m-%d'), "Event D")
event_e = (datetime.strptime('2021-03-04', '%Y-%m-%d'), "Event E")

events = []
heapq.heappush(events, event_a)
heapq.heappush(events, event_b)
heapq.heappush(events, event_c)
heapq.heappush(events, event_d)
heapq.heappush(events, event_e)

expected_list = [event_e, event_b, event_c, event_a, event_d]

assert events == expected_list

----------
components: Library (Lib)
files: test_heapq.py
messages: 388012
nosy: mike.koikos
priority: normal
severity: normal
status: open
title: heapq fails to sort tuples by datetime correctly
type: behavior
versions: Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49848/test_heapq.py

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

From report at bugs.python.org  Wed Mar  3 06:15:32 2021
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 03 Mar 2021 11:15:32 +0000
Subject: [issue43385] heapq fails to sort tuples by datetime correctly
In-Reply-To: <1614766149.48.0.609887863234.issue43385@roundup.psfhosted.org>
Message-ID: <1614770132.66.0.782794591437.issue43385@roundup.psfhosted.org>


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

Heaps are not sorted lists! It is true that a sorted list is a heap, but heaps are not necessarily sorted.

Here is another heap which is not sorted:

>>> L = []
>>> for n in (9, 7, 8, 11, 4):
...     heapq.heappush(L, n)
... 
>>> L
[4, 7, 8, 11, 9]


https://en.wikipedia.org/wiki/Heap_(data_structure)


Also:

>>> L = [9, 8, 7, 2, 3, 5, 4, 1, 0, 6]
>>> heapq.heapify(L)
>>> L
[0, 1, 4, 2, 3, 5, 7, 8, 9, 6]


If we change the order of the initial values, the heap changes too:


>>> L = [9, 8, 7, 2, 3, 5, 4, 1, 0, 6]
>>> L.reverse()
>>> heapq.heapify(L)
>>> L
[0, 4, 1, 6, 5, 3, 2, 7, 8, 9]

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

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

From report at bugs.python.org  Wed Mar  3 06:34:00 2021
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=)
Date: Wed, 03 Mar 2021 11:34:00 +0000
Subject: [issue43386] test_ctypes hangs inside Portage build env since
 'subprocess: Use vfork() instead of fork() [...]'
Message-ID: <1614771240.05.0.187208683071.issue43386@roundup.psfhosted.org>


New submission from Micha? G?rny <mgorny at gentoo.org>:

So I've finally found time to bisect this.

Long story short, test_ctypes started hanging on Gentoo package builds since 3.10.0a2.  Previously, the test took less than a second.  Now, it just keeps running for minutes until I kill it.

The weird thing is that I can't reproduce it when running it manually.  I've tried hard to rebuild Portage-like environment to make it hang, to no avail.

I've finally gotten around to bisecting it, and established that the problem is caused by the following change:

```
commit 976da903a746a5455998e9ca45fbc4d3ad3479d8
Author: Alexey Izbyshev <izbyshev at ispras.ru>
Date:   2020-10-24 02:47:01 +0200

    bpo-35823: subprocess: Use vfork() instead of fork() on Linux when safe (GH-11671)
[...]
```

After running the test with a timeout, I get the following backtrace:

```
test_issue_8959_a (ctypes.test.test_callbacks.SampleCallbacksTestCase) ... Timeout (0:00:30)!
Thread 0x00007f72f2507740 (most recent call first):
  File "/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/subprocess.py", line 1773 in _execute_child
  File "/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/subprocess.py", line 962 in __init__
  File "/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/ctypes/util.py", line 289 in _findSoname_ldconfig
  File "/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/ctypes/util.py", line 329 in find_library
  File "/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/ctypes/test/test_callbacks.py", line 183 in test_issue_8959_a
  File "/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/unittest/case.py", line 549 in _callTestMethod
  File "/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/unittest/case.py", line 592 in run
  File "/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/unittest/case.py", line 652 in __call__
  File "/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/unittest/suite.py", line 122 in run
  File "/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/unittest/suite.py", line 84 in __call__
  File "/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/unittest/suite.py", line 122 in run
  File "/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/unittest/suite.py", line 84 in __call__
  File "/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/unittest/suite.py", line 122 in run
  File "/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/unittest/suite.py", line 84 in __call__
  File "/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/unittest/suite.py", line 122 in run
  File "/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/unittest/suite.py", line 84 in __call__
  File "/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/unittest/suite.py", line 122 in run
  File "/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/unittest/suite.py", line 84 in __call__
  File "/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/unittest/runner.py", line 176 in run
  File "/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/test/support/__init__.py", line 959 in _run_suite
  File "/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/test/support/__init__.py", line 1082 in run_unittest
  File "/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/test/libregrtest/runtest.py", line 211 in _test_module
  File "/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/test/libregrtest/runtest.py", line 236 in _runtest_inner2
  File "/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/test/libregrtest/runtest.py", line 272 in _runtest_inner
  File "/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/test/libregrtest/runtest.py", line 155 in _runtest
  File "/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/test/libregrtest/runtest.py", line 195 in runtest
  File "/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/test/libregrtest/main.py", line 319 in rerun_failed_tests
  File "/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/test/libregrtest/main.py", line 696 in _main
  File "/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/test/libregrtest/main.py", line 639 in main
  File "/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/test/libregrtest/main.py", line 717 in main
  File "/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/test/__main__.py", line 2 in <module>
  File "/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/runpy.py", line 87 in _run_code
  File "/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/runpy.py", line 197 in _run_module_as_main
make: *** [Makefile:1204: test] Error 1
```

I'd appreciate any help in debugging this further.

----------
components: Tests
messages: 388014
nosy: izbyshev, mgorny
priority: normal
severity: normal
status: open
title: test_ctypes hangs inside Portage build env since 'subprocess: Use vfork() instead of fork() [...]'
versions: Python 3.10

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

From report at bugs.python.org  Wed Mar  3 07:29:43 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 03 Mar 2021 12:29:43 +0000
Subject: [issue43376] Add PyComplex_FromString
In-Reply-To: <1614714591.46.0.224854150713.issue43376@roundup.psfhosted.org>
Message-ID: <1614774583.4.0.800714281354.issue43376@roundup.psfhosted.org>


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

I'd imagine "PyComplex_FromString" would be of limited utility in parsing complex data produced by something other than Python, because of Python's quirks with "j" rather than "i". But I guess you're talking about a case where the creation of the text file involved using the repr or str of Python complex values?

But I don't see any reason in principle why it shouldn't/couldn't be added.

----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Wed Mar  3 07:30:56 2021
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=)
Date: Wed, 03 Mar 2021 12:30:56 +0000
Subject: [issue43386] test_ctypes hangs inside Portage build env since
 'subprocess: Use vfork() instead of fork() [...]'
In-Reply-To: <1614771240.05.0.187208683071.issue43386@roundup.psfhosted.org>
Message-ID: <1614774656.25.0.872622362479.issue43386@roundup.psfhosted.org>


Micha? G?rny <mgorny at gentoo.org> added the comment:

Nevermind, I've been testing wrong and this is most likely our fault.  I'm sorry about the noise.  I am going to investigate further and reopen if it turns out the problem's on CPython end.

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

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

From report at bugs.python.org  Wed Mar  3 08:20:38 2021
From: report at bugs.python.org (Ivan Marton)
Date: Wed, 03 Mar 2021 13:20:38 +0000
Subject: [issue43382] github CI blocked by the Ubuntu CI with an SSL error
In-Reply-To: <1614745744.43.0.675662116863.issue43382@roundup.psfhosted.org>
Message-ID: <1614777638.06.0.838611995492.issue43382@roundup.psfhosted.org>


Change by Ivan Marton <github at martonivan.hu>:


----------
nosy: +martonivan

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

From report at bugs.python.org  Wed Mar  3 08:34:22 2021
From: report at bugs.python.org (digitaldragon)
Date: Wed, 03 Mar 2021 13:34:22 +0000
Subject: [issue43387] Enable pydoc to run as background job
Message-ID: <1614778462.01.0.596151563335.issue43387@roundup.psfhosted.org>


New submission from digitaldragon <raphael at pdev.de>:

The pydoc tool can serve a website for browsing the docs interactively with the -p or -b option. While serving, it enters a simple command line interface:
Server commands: [b]rowser, [q]uit
server> 

Because it is reading from stdin, it is not possible to straightforwardly run the progress in the background of a linux shell. Normally, this is achieved by appending a & to the command, starting it in the background, or using the shell's job control features to put it in the background after starting normally: Usually Ctrl-Z and issuing the command 'bg'.

In both cases, any attempt to read from stdin causes a SIGTTIN signal, suspending the process if not caught. The webserver then cannot process any requests.

I reproduced the behavior in python versions 3.5, 3.7, 3.8 and 3.9. In 2.7, no interactive interface is present.

Possible fixes:
- remove the interactive command line altogether (it does not offer more functionality than the -b flag, and the shell's handling of Ctrl-C, which sends a SIGINT anyway)
- catch SIGTTIN (handles a subsequent sending-to-background)
- detecting if started in background (https://stackoverflow.com/a/24862213, can't handle subsequent sending-to-background)

----------
components: Library (Lib)
messages: 388017
nosy: digitaldragon
priority: normal
severity: normal
status: open
title: Enable pydoc to run as background job
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Wed Mar  3 08:41:53 2021
From: report at bugs.python.org (Eric Engestrom)
Date: Wed, 03 Mar 2021 13:41:53 +0000
Subject: [issue43355] __future__.annotations breaks inspect.signature()
In-Reply-To: <1614614520.28.0.353733927276.issue43355@roundup.psfhosted.org>
Message-ID: <1614778913.8.0.737981250681.issue43355@roundup.psfhosted.org>


Eric Engestrom <eric.engestrom at gmail.com> added the comment:

Sure thing.

Putting the reproducing code in `test_foo.py` and running `docker run --rm -it -v $PWD:/code python sh -c 'pip install pytest && pytest -vvv /code/test_foo.py'` yields:

```
Collecting pytest
  Downloading pytest-6.2.2-py3-none-any.whl (280 kB)
     |????????????????????????????????| 280 kB 516 kB/s
Collecting toml
  Downloading toml-0.10.2-py2.py3-none-any.whl (16 kB)
Collecting py>=1.8.2
  Downloading py-1.10.0-py2.py3-none-any.whl (97 kB)
     |????????????????????????????????| 97 kB 1.6 MB/s
Collecting attrs>=19.2.0
  Downloading attrs-20.3.0-py2.py3-none-any.whl (49 kB)
     |????????????????????????????????| 49 kB 1.8 MB/s
Collecting iniconfig
  Downloading iniconfig-1.1.1-py2.py3-none-any.whl (5.0 kB)
Collecting packaging
  Downloading packaging-20.9-py2.py3-none-any.whl (40 kB)
     |????????????????????????????????| 40 kB 833 kB/s
Collecting pluggy<1.0.0a1,>=0.12
  Downloading pluggy-0.13.1-py2.py3-none-any.whl (18 kB)
Collecting pyparsing>=2.0.2
  Downloading pyparsing-2.4.7-py2.py3-none-any.whl (67 kB)
     |????????????????????????????????| 67 kB 1.5 MB/s
Installing collected packages: pyparsing, toml, py, pluggy, packaging, iniconfig, attrs, pytest
Successfully installed attrs-20.3.0 iniconfig-1.1.1 packaging-20.9 pluggy-0.13.1 py-1.10.0 pyparsing-2.4.7 pytest-6.2.2 toml-0.10.2
============================= test session starts ==============================
platform linux -- Python 3.9.2, pytest-6.2.2, py-1.10.0, pluggy-0.13.1 -- /usr/local/bin/python
cachedir: .pytest_cache
rootdir: /code
collected 1 item

code/test_foo.py::test_foo FAILED                                        [100%]

=================================== FAILURES ===================================
___________________________________ test_foo ___________________________________

    def test_foo():
        expected = (
            Parameter("x", Parameter.POSITIONAL_OR_KEYWORD, annotation=str),
        )

        actual = tuple(signature(foo).parameters.values())

>       assert expected == actual
E       assert (<Parameter "x: str">,) == (<Parameter "x: 'str'">,)
E         At index 0 diff: <Parameter "x: str"> != <Parameter "x: 'str'">
E         Full diff:
E         - (<Parameter "x: 'str'">,)
E         ?                 -   -
E         + (<Parameter "x: str">,)

code/test_foo.py:16: AssertionError
=========================== short test summary info ============================
FAILED code/test_foo.py::test_foo - assert (<Parameter "x: str">,) == (<Param...
============================== 1 failed in 0.02s ===============================
```

----------

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

From report at bugs.python.org  Wed Mar  3 08:42:33 2021
From: report at bugs.python.org (Tal Einat)
Date: Wed, 03 Mar 2021 13:42:33 +0000
Subject: [issue43075] ReDoS in urllib.request
In-Reply-To: <1611994306.46.0.333529770265.issue43075@roundup.psfhosted.org>
Message-ID: <1614778953.21.0.994033780681.issue43075@roundup.psfhosted.org>


Change by Tal Einat <taleinat+python at gmail.com>:


----------
keywords: +newcomer friendly

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

From report at bugs.python.org  Wed Mar  3 08:42:44 2021
From: report at bugs.python.org (digitaldragon)
Date: Wed, 03 Mar 2021 13:42:44 +0000
Subject: [issue43387] Enable pydoc to run as background job
In-Reply-To: <1614778462.01.0.596151563335.issue43387@roundup.psfhosted.org>
Message-ID: <1614778964.28.0.630112271825.issue43387@roundup.psfhosted.org>


Change by digitaldragon <raphael at pdev.de>:


----------
versions: +Python 3.10, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Wed Mar  3 08:45:41 2021
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 03 Mar 2021 13:45:41 +0000
Subject: [issue43382] github CI blocked by the Ubuntu CI with an SSL error
In-Reply-To: <1614745744.43.0.675662116863.issue43382@roundup.psfhosted.org>
Message-ID: <1614779141.71.0.597655136879.issue43382@roundup.psfhosted.org>


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

Downstream has asked me to file a separate bug for internal error during handshake. The problem is tracked at https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1917625 .

----------

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

From report at bugs.python.org  Wed Mar  3 08:45:52 2021
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 03 Mar 2021 13:45:52 +0000
Subject: [issue41561] test_ssl fails in Ubuntu 20.04:
 test_min_max_version_mismatch
In-Reply-To: <1597551049.14.0.0578030464715.issue41561@roundup.psfhosted.org>
Message-ID: <1614779152.93.0.693273068039.issue41561@roundup.psfhosted.org>


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

Downstream has asked me to file a separate bug for internal error during handshake. The problem is tracked at https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1917625 .

----------

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

From report at bugs.python.org  Wed Mar  3 09:16:31 2021
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 03 Mar 2021 14:16:31 +0000
Subject: [issue43368] Empty bytestrings are not longer returned on SQLite.
In-Reply-To: <1614685928.78.0.886404151832.issue43368@roundup.psfhosted.org>
Message-ID: <1614780991.06.0.625948945397.issue43368@roundup.psfhosted.org>


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


New changeset 3b4b2cf418707c79f96689e401e3c703c0fdd4d2 by Mariusz Felisiak in branch 'master':
bpo-43368: Fix fetching empty bytes in sqlite3 (GH-24706)
https://github.com/python/cpython/commit/3b4b2cf418707c79f96689e401e3c703c0fdd4d2


----------

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

From report at bugs.python.org  Wed Mar  3 09:16:41 2021
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 03 Mar 2021 14:16:41 +0000
Subject: [issue43368] Empty bytestrings are not longer returned on SQLite.
In-Reply-To: <1614685928.78.0.886404151832.issue43368@roundup.psfhosted.org>
Message-ID: <1614781001.46.0.0442437784953.issue43368@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Wed Mar  3 09:22:00 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Wed, 03 Mar 2021 14:22:00 +0000
Subject: [issue43369] [sqlite3] Handle out-of-memory errors in
 sqlite3_column_*()
In-Reply-To: <1614688659.29.0.386186084124.issue43369@roundup.psfhosted.org>
Message-ID: <1614781320.6.0.766854995219.issue43369@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


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

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

From report at bugs.python.org  Wed Mar  3 09:33:43 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Wed, 03 Mar 2021 14:33:43 +0000
Subject: [issue43369] [sqlite3] Handle out-of-memory errors in
 sqlite3_column_*()
In-Reply-To: <1614688659.29.0.386186084124.issue43369@roundup.psfhosted.org>
Message-ID: <1614782023.88.0.0680148134478.issue43369@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

Quoting from the SQLite docs:
"As long as the input parameters are correct, these routines will only fail if an out-of-memory error occurs during a format conversion"

----------

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

From report at bugs.python.org  Wed Mar  3 09:41:54 2021
From: report at bugs.python.org (Ken Jin)
Date: Wed, 03 Mar 2021 14:41:54 +0000
Subject: [issue43355] __future__.annotations breaks inspect.signature()
In-Reply-To: <1614614520.28.0.353733927276.issue43355@roundup.psfhosted.org>
Message-ID: <1614782514.53.0.356595907008.issue43355@roundup.psfhosted.org>


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

@eric.smith, here's a summarized version. I hope it helps:

def foo(x: str) -> str: ...

In Python 3.7 - 3.9 with from __future__ import annotations, inspect.signature sees foo's parameter as:

<Parameter "x: 'str'">

Without the future import (and also in Python 3.10):

<Parameter "x: str">

The reason for the difference in 3.10 (IIRC) is that inspect.signature auto converts all strings to typing.ForwardRef internally and then resolves them. This is a result of PEP 563 becoming default (also mentioned here https://docs.python.org/3.10/whatsnew/3.10.html#pep-563-postponed-evaluation-of-annotations-becomes-default )

Prior to 3.10, the future import treats function annotations as strings and inspect.signature _doesn't_ convert them. I don't know of this is a bug or intentional. Especially considering what PEP 563 has to say: https://www.python.org/dev/peps/pep-0563/#resolving-type-hints-at-runtime

@1ace, a possible workaround if you want full compatibility regardless of the future import is to use typing.get_type_hints:

(The result doesn't change even with from __future__ import annotations. This also works from 3.7-3.10)
>>> from typing import get_type_hints
>>> get_type_hints(foo)
{'x': <class 'str'>, 'return': <class 'str'>}

----------
nosy: +kj

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

From report at bugs.python.org  Wed Mar  3 10:17:03 2021
From: report at bugs.python.org (miss-islington)
Date: Wed, 03 Mar 2021 15:17:03 +0000
Subject: [issue42782] shutil.move creates a new directory even on failure
In-Reply-To: <1609267376.56.0.274024517588.issue42782@roundup.psfhosted.org>
Message-ID: <1614784623.99.0.309057457323.issue42782@roundup.psfhosted.org>


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


----------
pull_requests: +23497
pull_request: https://github.com/python/cpython/pull/24724

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

From report at bugs.python.org  Wed Mar  3 10:34:48 2021
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 03 Mar 2021 15:34:48 +0000
Subject: [issue42782] shutil.move creates a new directory even on failure
In-Reply-To: <1609267376.56.0.274024517588.issue42782@roundup.psfhosted.org>
Message-ID: <1614785688.25.0.540002293999.issue42782@roundup.psfhosted.org>


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


----------
pull_requests: +23498
pull_request: https://github.com/python/cpython/pull/24725

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

From report at bugs.python.org  Wed Mar  3 10:37:29 2021
From: report at bugs.python.org (miss-islington)
Date: Wed, 03 Mar 2021 15:37:29 +0000
Subject: [issue42782] shutil.move creates a new directory even on failure
In-Reply-To: <1609267376.56.0.274024517588.issue42782@roundup.psfhosted.org>
Message-ID: <1614785849.11.0.378355225895.issue42782@roundup.psfhosted.org>


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


New changeset 59e857650cf49a5e28cb82acc2641b1b53efeeeb by Miss Islington (bot) in branch '3.8':
bpo-42782: Fail fast for permission errors in shutil.move() (GH-24001)
https://github.com/python/cpython/commit/59e857650cf49a5e28cb82acc2641b1b53efeeeb


----------

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

From report at bugs.python.org  Wed Mar  3 10:56:46 2021
From: report at bugs.python.org (Eric Engestrom)
Date: Wed, 03 Mar 2021 15:56:46 +0000
Subject: [issue43355] __future__.annotations breaks inspect.signature()
In-Reply-To: <1614614520.28.0.353733927276.issue43355@roundup.psfhosted.org>
Message-ID: <1614787006.88.0.00339389241142.issue43355@roundup.psfhosted.org>


Eric Engestrom <eric.engestrom at gmail.com> added the comment:

Sorry, I just realized you asked for the "success" value as well.

For python 3.7-3.9 without the `import annotations`, and for python 3.10, the type annotation is a class, ie. `<Parameter "x: str">`.

----------

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

From report at bugs.python.org  Wed Mar  3 11:04:08 2021
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 03 Mar 2021 16:04:08 +0000
Subject: [issue42782] shutil.move creates a new directory even on failure
In-Reply-To: <1609267376.56.0.274024517588.issue42782@roundup.psfhosted.org>
Message-ID: <1614787448.07.0.399147779804.issue42782@roundup.psfhosted.org>


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


New changeset bf566847f5a97e6ce391f8fb94185ee756cb94a2 by Senthil Kumaran in branch '3.9':
[3.9] bpo-42782: Fail fast for permission errors in shutil.move() (GH-24001) (#24725)
https://github.com/python/cpython/commit/bf566847f5a97e6ce391f8fb94185ee756cb94a2


----------

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

From report at bugs.python.org  Wed Mar  3 11:04:24 2021
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 03 Mar 2021 16:04:24 +0000
Subject: [issue42782] shutil.move creates a new directory even on failure
In-Reply-To: <1609267376.56.0.274024517588.issue42782@roundup.psfhosted.org>
Message-ID: <1614787464.3.0.479843332211.issue42782@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Wed Mar  3 11:06:53 2021
From: report at bugs.python.org (=?utf-8?q?Lorenz_H=C3=BCdepohl?=)
Date: Wed, 03 Mar 2021 16:06:53 +0000
Subject: [issue43388] shutil._fastcopy_sendfile() makes wrong (?) assumption
 about sendfile() return value
Message-ID: <1614787613.45.0.094604330239.issue43388@roundup.psfhosted.org>


New submission from Lorenz H?depohl <bugs at stellardeath.org>:

Since version 3.8, the shutil.copyfile() function tries to make use of os.sendfile(). Currently, this is done in a loop that aborts as soon as sendfile() returns 0, as it is assumed that this signifies the end of the file.

The problem: the return value of sendfile() is simply the amount of bytes that could be successfully copied in that one syscall, with no guarantee that a return value of 0 only happens when there is truly no data left to copy. Some other urgent task could have interrupted the kernel before any data was copied. At least, I could not find documentation to the contrary.

(Note: This might or might not be actual behavior of current Linux kernels today, but the spec of sendfile() certainly allows this)


In any case, in that same routine the size of the source file is anyway requested in an os.fstat() call, one could thus restructure the loop like this, for example:


filesize = os.fstat(infd).st_size
offset = 0
while offset < filesize:
   sent = os.sendfile(outfd, infd, offset, blocksize)
   offset += sent

(Error handling etc. left out for clarity, just to point out the new structure)

This would also optimize the case of an empty input file, in that case the loop is never entered and no os.sendfile() call is issued, at all.

In the normal case, it would also save the unnecessary last os.sendfile() call, when 'offset' has already grown to 'filesize'. (This was the actual reason for me to look into this in the first place, a filesystem bug where sendfile() called with an offset set to the file's size returns "EAGAIN" in certain cases. But this is another topic entirely and has nothing to do with Python, of course.)


Note that in Modules/posixmodule.c os_sendfile_impl() there is also another loop around individual actual sendfile() system call, but a return value of 0 there would also exit that loop and be passed up:

    do {
        Py_BEGIN_ALLOW_THREADS
#ifdef __APPLE__
        ret = sendfile(in_fd, out_fd, offset, &sbytes, &sf, flags);
#else
        ret = sendfile(in_fd, out_fd, offset, count, &sf, &sbytes, flags);
#endif
        Py_END_ALLOW_THREADS
    } while (ret < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals()));


Kind regards,
  Lorenz

----------
components: Library (Lib)
messages: 388027
nosy: lhuedepohl
priority: normal
severity: normal
status: open
title: shutil._fastcopy_sendfile() makes wrong (?) assumption about sendfile() return value
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Mar  3 11:11:27 2021
From: report at bugs.python.org (Paul Ganssle)
Date: Wed, 03 Mar 2021 16:11:27 +0000
Subject: [issue43382] github CI blocked by the Ubuntu CI with an SSL error
In-Reply-To: <1614745744.43.0.675662116863.issue43382@roundup.psfhosted.org>
Message-ID: <1614787887.6.0.679559710608.issue43382@roundup.psfhosted.org>


Change by Paul Ganssle <p.ganssle at gmail.com>:


----------
nosy: +p-ganssle

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

From report at bugs.python.org  Wed Mar  3 11:15:32 2021
From: report at bugs.python.org (Alexander Grigoriev)
Date: Wed, 03 Mar 2021 16:15:32 +0000
Subject: [issue35935] threading.Event().wait() not interruptable with Ctrl-C
 on Windows
In-Reply-To: <1549588377.49.0.765820535798.issue35935@roundup.psfhosted.org>
Message-ID: <1614788132.23.0.188223451284.issue35935@roundup.psfhosted.org>


Alexander Grigoriev <alegrigoriev at gmail.com> added the comment:

@ericsun:

Windows calls the console event handler in a separate thread. The console event handler receives CTRL_C_EVENT, CTRL_BREAK_EVENT, console close, logoff, system shutdown events.

Originally, Windows devised an APC mechanism to simulate asynchronous delivery of Posix signal to threads. Those APCs are invoked during alertable wait functions. Delivery of an APS also aborts the wait with WAIT_IO_COMPLETION return code.

An APC can be queued by QueueUserAPC function.

An APC queue can be processed at any time by calling an alertable wait function with zero timeout, for example SleepEx(0, TRUE).

If you need an APC to break wait for asynchronous input (like console or serial port), use overlapped I/O with GetOverlappedResultEx function. To cancel the I/O request, use CancelIo function on the thread which issued the request. Note that you still need to wait for the cancelled request to complete the cancellation with GetOverlappedResult.

----------
nosy: +alegrigoriev

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

From report at bugs.python.org  Wed Mar  3 11:25:11 2021
From: report at bugs.python.org (Eric Engestrom)
Date: Wed, 03 Mar 2021 16:25:11 +0000
Subject: [issue43355] __future__.annotations breaks inspect.signature()
In-Reply-To: <1614614520.28.0.353733927276.issue43355@roundup.psfhosted.org>
Message-ID: <1614788711.7.0.809827287342.issue43355@roundup.psfhosted.org>


Eric Engestrom <eric.engestrom at gmail.com> added the comment:

(... and I had the window open for too long and didn't notice Ken's reply before mine ^^')

@kj: thanks for the workaround! it's good to be able to change our code and not have to depend on a yet-to-be-released patch on each python version :)

That said, typing.get_type_hints() only returns the type hint, whereas our current test checks for other things (like the default value) which need to match (I think) for cython's use of `__signature__`? (I inherited all this code, so I'm not familiar with it and its history, and I'm beginning to question this test's necessity.)

----------

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

From report at bugs.python.org  Wed Mar  3 11:39:26 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 03 Mar 2021 16:39:26 +0000
Subject: [issue43383] imprecise handling of weakref callbacks
In-Reply-To: <1614746880.88.0.974985202377.issue43383@roundup.psfhosted.org>
Message-ID: <1614789566.91.0.756372884445.issue43383@roundup.psfhosted.org>


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

If I understand correctly, the reported bug is that you're seeing a weakref callback being executed after the weakref.ref instance it's attached to is deleted. Is that correct?

Do you have a minimal example we can use to reproduce the effect? Without such an example, there's not much of a realistic path to moving this forward.

Without the code: I can't see a plausible mechanism by which the callback could execute after the weakref.ref has ceased to exist.

However, my suspicion is that that's not what's actually happening here. I suspect that when you say "after the corresponding weak reference has been deleted with del", that the "del" statement you refer to is not actually deleting the last reference to the weakref.ref object, so the weakref still exists after the "del". One easy way that this could happen is if the weakref is part of a reference cycle (and I know from personal experience that it's horribly easy to accidentally *create* reference cycles via weakref callbacks, especially if those callbacks refer to instance methods).

Furthermore, if the weakref exists as part of a cycle and that cycle is being collected by the garbage collector, I could see how the callback could be sometimes executed and sometimes not depending on the exact order in which the cycle is cleaned up.

----------
nosy: +mark.dickinson, pitrou

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

From report at bugs.python.org  Wed Mar  3 11:43:03 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 03 Mar 2021 16:43:03 +0000
Subject: [issue39199] Improve the AST documentation
In-Reply-To: <1578056721.05.0.299258437761.issue39199@roundup.psfhosted.org>
Message-ID: <1614789783.2.0.826967150192.issue39199@roundup.psfhosted.org>


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


----------
pull_requests: +23499
pull_request: https://github.com/python/cpython/pull/24727

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

From report at bugs.python.org  Wed Mar  3 11:46:53 2021
From: report at bugs.python.org (Brandt Bucher)
Date: Wed, 03 Mar 2021 16:46:53 +0000
Subject: [issue43382] github CI blocked by the Ubuntu CI with an SSL error
In-Reply-To: <1614745744.43.0.675662116863.issue43382@roundup.psfhosted.org>
Message-ID: <1614790013.38.0.421263131407.issue43382@roundup.psfhosted.org>


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

@ned.deily, I think the 3.7 backport needs RM approval (or something?):

https://github.com/python/cpython/pull/24716

The others branches are fine now... thanks, Christian!

----------

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

From report at bugs.python.org  Wed Mar  3 11:50:58 2021
From: report at bugs.python.org (nmatravolgyi)
Date: Wed, 03 Mar 2021 16:50:58 +0000
Subject: [issue43389] Cancellation ignored by asyncio.wait_for can hang
 application
Message-ID: <1614790258.6.0.416802160939.issue43389@roundup.psfhosted.org>


New submission from nmatravolgyi <nandor.matra at gmail.com>:

I have found myself debugging a *very* not intuitive behavior regarding asyncio.wait_for that I'd consider a bug/deficiency. The problem very simply put: wait_for will return the wrapped future's result even when it is being cancelled, ignoring the cancellation as it has never existed.

This will make parallel execution-waits hang forever if some simple conditions are met. From the perspective of this snippet every task must exit so it just needs to wait. I know cancellation *can* be ignored, but it is discouraged by the documentation for this reason exactly.

tasks = [...]
for t in tasks:
    t.cancel()
results = await asyncio.gather(*tasks, return_exceptions=True)

I already know that this behavior has been chosen because otherwise the returned value would be lost. But for many applications, losing an explicit cancellation error/event is just as bad.

The reason why ignoring the cancellation is critical is because the cancelling (arbiter) task cannot reliably solve it. In most cases having repeated cancellations in a polling wait can solve this, but it is ugly and does not work if the original wait_for construct is in a loop and will always ignore the cancellation.

The most sensible solution would be to allow the user to handle both the return value and the cancellation if they do happen at once. This can be done by subclassing the CancelledError as CancelledWithResultError and raising that instead. If the user code does not handle that exception specifically then the user "chose" to ignore the result. Even if this is not intuitive, it would give the user the control over what really is happening. Right now, the user cannot prefer to handle the cancellation or both.

Lastly, I may have overlooked something trivial to make this work well. Right now I'm considering replacing all of the asyncio.wait_for constructs with asyncio.wait constructs. I can fully control all tasks and cancellations with that. I've made a simple demonstration of my problem, maybe someone can shed some light onto it.

----------
components: asyncio
files: aio_wait_for_me.py
messages: 388032
nosy: asvetlov, nmatravolgyi, yselivanov
priority: normal
severity: normal
status: open
title: Cancellation ignored by asyncio.wait_for can hang application
type: behavior
versions: Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49849/aio_wait_for_me.py

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

From report at bugs.python.org  Wed Mar  3 11:57:55 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 03 Mar 2021 16:57:55 +0000
Subject: [issue43355] __future__.annotations breaks inspect.signature()
In-Reply-To: <1614614520.28.0.353733927276.issue43355@roundup.psfhosted.org>
Message-ID: <1614790675.87.0.32395082767.issue43355@roundup.psfhosted.org>


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

I think this is all about: should inspect.signature() resolve string annotations into actual types (via get_type_hints, or whatever)? I don't use expect much, so I can't offer an opinion there.

----------

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

From report at bugs.python.org  Wed Mar  3 11:59:05 2021
From: report at bugs.python.org (miss-islington)
Date: Wed, 03 Mar 2021 16:59:05 +0000
Subject: [issue43295] datetime.strptime emits IndexError on parsing 'z' as %z
In-Reply-To: <1614002299.86.0.551520528109.issue43295@roundup.psfhosted.org>
Message-ID: <1614790745.92.0.889848827219.issue43295@roundup.psfhosted.org>


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


New changeset 04f6fbb6969e9860783b9ab4dc24b6fe3c6dab8d by Noor Michael in branch 'master':
bpo-43295: Fix error handling of datetime.strptime format string '%z' (GH-24627)
https://github.com/python/cpython/commit/04f6fbb6969e9860783b9ab4dc24b6fe3c6dab8d


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

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

From report at bugs.python.org  Wed Mar  3 11:59:17 2021
From: report at bugs.python.org (miss-islington)
Date: Wed, 03 Mar 2021 16:59:17 +0000
Subject: [issue43295] datetime.strptime emits IndexError on parsing 'z' as %z
In-Reply-To: <1614002299.86.0.551520528109.issue43295@roundup.psfhosted.org>
Message-ID: <1614790757.75.0.986159805102.issue43295@roundup.psfhosted.org>


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


----------
pull_requests: +23500
pull_request: https://github.com/python/cpython/pull/24728

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

From report at bugs.python.org  Wed Mar  3 11:59:29 2021
From: report at bugs.python.org (miss-islington)
Date: Wed, 03 Mar 2021 16:59:29 +0000
Subject: [issue43295] datetime.strptime emits IndexError on parsing 'z' as %z
In-Reply-To: <1614002299.86.0.551520528109.issue43295@roundup.psfhosted.org>
Message-ID: <1614790769.63.0.808743080382.issue43295@roundup.psfhosted.org>


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


----------
pull_requests: +23501
pull_request: https://github.com/python/cpython/pull/24729

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

From report at bugs.python.org  Wed Mar  3 12:28:10 2021
From: report at bugs.python.org (Ned Deily)
Date: Wed, 03 Mar 2021 17:28:10 +0000
Subject: [issue43382] github CI blocked by the Ubuntu CI with an SSL error
In-Reply-To: <1614745744.43.0.675662116863.issue43382@roundup.psfhosted.org>
Message-ID: <1614792490.58.0.373071564719.issue43382@roundup.psfhosted.org>


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

3.7 backport is now merged, too.

----------

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

From report at bugs.python.org  Wed Mar  3 12:45:04 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 03 Mar 2021 17:45:04 +0000
Subject: [issue43390] Set the SA_ONSTACK in PyOS_setsig to play well with
 other VMs like Golang
Message-ID: <1614793504.75.0.801298006043.issue43390@roundup.psfhosted.org>


New submission from Gregory P. Smith <greg at krypto.org>:

PyOS_setsig currently sets the struct sigaction context.sa_flags = 0 before calling sigaction.

Other virtual machines such as Golang depend on signals using SA_ONSTACK such that signal handlers use a specially allocated stack that runtime sets up for reliability reasons as they use tiny stacks on normal threads.

SA_ONSTACK is a no-op flag in the typical case where no sigaltstack() call has been made to setup an alternate signal handling stack.  (as in 99.99% of all CPython applications)

When a C/C++ extension module is linked with cgo to call into a Golang library, doing this increases reliability.

As much as I try to dissuade anyone from creating and relying on hidden complexity multi-VM-hybrids in a single process like this, some people do, and this one line change helps.

Golang references:
  https://golang.org/pkg/os/signal/#hdr-Go_programs_that_use_cgo_or_SWIG
 and
  https://go-review.googlesource.com/c/go/+/298269/ (which clarifies that SA_RESTART is no longer a requirement. Good. Because Python won't get along well with that one.)

----------
assignee: gregory.p.smith
components: Interpreter Core
messages: 388036
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: Set the SA_ONSTACK in PyOS_setsig to play well with other VMs like Golang
versions: Python 3.10

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

From report at bugs.python.org  Wed Mar  3 12:50:09 2021
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 03 Mar 2021 17:50:09 +0000
Subject: [issue35935] threading.Event().wait() not interruptable with Ctrl-C
 on Windows
In-Reply-To: <1549588377.49.0.765820535798.issue35935@roundup.psfhosted.org>
Message-ID: <1614793809.94.0.783699002887.issue35935@roundup.psfhosted.org>


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

Alexander, I wrote the above sample function to be slotted directly into the existing design based on the SIGINT event. I wasn't looking to rewrite everything using user-mode APCs and alertable waits. A change like that could have ramifications for applications that already use alertable waits, depending on how resiliently they're designed.

> Originally, Windows devised an APC mechanism to simulate asynchronous
> delivery of Posix signal to threads. 

IIRC, Iterix (i.e. SUA -- replaced nowadays by WSL) used Asynchronous Procedure Calls (APCs) to implement Unix signals. But APCs certainly weren't devised solely for the purpose of the providing signals in the POSIX subsystem. They're an evolution of Asynchronous System Traps (ASTs) in DEC VMS. (The lead designer of NT and most of the development team originally designed and implemented VMS at DEC. They began working at Microsoft to design the NT system and OS/2, Win32, and POSIX subsystems starting in late 1988.) Kernel-mode and user-mode APCs are fundamental and critical to NT (e.g. thread termination uses an APC), and particularly the I/O system, which uses a special kernel-mode APC for I/O request completion. (An I/O request is often serviced in an arbitrary thread context. Buffered I/O completion has to be queued back to the calling thread in order to copy from a system buffer to the user buffer.)

> Those APCs are invoked during alertable wait functions. Delivery 
> of an APS also aborts the wait with WAIT_IO_COMPLETION return code.

WAIT_IO_COMPLETION is the same as STATUS_USER_APC, because I/O completion routines are queued as user-mode APCs (e.g. by ReadFileEx). Using the name "WAIT_IO_COMPLETION" clarifies the intent in this case. In general, I prefer "STATUS_USER_APC".

> An APC queue can be processed at any time by calling an alertable 
> wait function with zero timeout, for example SleepEx(0, TRUE).

The user-mode APC queue can also be pumped by calling the NtTestAlert() system function. For example:

    import ctypes
    ntdll = ctypes.WinDLL('ntdll')
    kernel32 = ctypes.WinDLL('kernel32', use_last_error=True)

    @ctypes.WINFUNCTYPE(None, ctypes.c_void_p)
    def apc(p):
        print('spam APC')

    hthread = ctypes.c_void_p(-2)
    kernel32.QueueUserAPC(apc, hthread, None)


    >>> ntdll.NtTestAlert(hthread)
    spam APC
    0

----------

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

From report at bugs.python.org  Wed Mar  3 12:54:37 2021
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 03 Mar 2021 17:54:37 +0000
Subject: [issue43162] Enum regression: AttributeError when accessing class
 variables on instances
In-Reply-To: <1612786979.73.0.896348338765.issue43162@roundup.psfhosted.org>
Message-ID: <1614794077.22.0.431937513833.issue43162@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:


New changeset 44e580f448016b86807465a186d03d9074e2b589 by Ethan Furman in branch 'master':
bpo-43162: [Enum] update docs, renable doc tests (GH-24487)
https://github.com/python/cpython/commit/44e580f448016b86807465a186d03d9074e2b589


----------

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

From report at bugs.python.org  Wed Mar  3 13:01:13 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 03 Mar 2021 18:01:13 +0000
Subject: [issue43390] Set the SA_ONSTACK in PyOS_setsig to play well with
 other VMs like Golang
In-Reply-To: <1614793504.75.0.801298006043.issue43390@roundup.psfhosted.org>
Message-ID: <1614794473.6.0.780299446091.issue43390@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


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

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

From report at bugs.python.org  Wed Mar  3 13:03:32 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 03 Mar 2021 18:03:32 +0000
Subject: [issue43390] Set the SA_ONSTACK in PyOS_setsig to play well with
 other VMs like Golang
In-Reply-To: <1614793504.75.0.801298006043.issue43390@roundup.psfhosted.org>
Message-ID: <1614794612.94.0.211074767914.issue43390@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
type:  -> resource usage

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

From report at bugs.python.org  Wed Mar  3 13:20:35 2021
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 03 Mar 2021 18:20:35 +0000
Subject: [issue42782] shutil.move creates a new directory even on failure
In-Reply-To: <1609267376.56.0.274024517588.issue42782@roundup.psfhosted.org>
Message-ID: <1614795635.35.0.155665497024.issue42782@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Wed Mar  3 13:31:01 2021
From: report at bugs.python.org (Konrad Schwarz)
Date: Wed, 03 Mar 2021 18:31:01 +0000
Subject: [issue43383] imprecise handling of weakref callbacks
In-Reply-To: <1614789566.91.0.756372884445.issue43383@roundup.psfhosted.org>
Message-ID: <017001d7105b$5b37a240$11a6e6c0$@gmail.com>


Konrad Schwarz <konrad.schwarz at gmail.com> added the comment:

> If I understand correctly, the reported bug is that you're seeing a weakref callback being executed
> after the weakref.ref instance it's attached to is deleted. Is that correct?

Exactly.  I del what should be the only reference to the weakref.ref/proxy, then del the weakref.ref's referent.
The weakref.ref's callback is executed.

> Do you have a minimal example we can use to reproduce the effect? Without such an example, there's not
> much of a realistic path to moving this forward.

Unfortunately, not at the moment.

> However, my suspicion is that that's not what's actually happening here. I suspect that when you say
> "after the corresponding weak reference has been deleted with del", that the "del" statement you refer
> to is not actually deleting the last reference to the weakref.ref object, so the weakref still exists
> after the "del". One easy way that this could happen is if the weakref is part of a reference cycle
> (and I know from personal experience that it's horribly easy to accidentally *create* reference cycles
> via weakref callbacks, especially if those callbacks refer to instance methods).

I tried to be as punctilious as I could to prevent this sort of thing from happening.
The weird thing is that the error does not occur when I single step the code in PDB.
It must be something internal to CPython, some sort of optimization.
Are local variables/stack frames cleaned lazily?  Is the last accessed value of a
dictionary cached internally, increasing its reference count?

I've worked around the problem by double checking in the callback method that it actually should execute;
i.e. in my case, that the object has not been removed (del) from a dictionary (which should be the
single reference to the object).

If the problem does indeed lie with CPython, but has too much of a performance/maintenance impact,
perhaps a caveat could be added to the documentation to the effect of "The lifetime of an object
may be longer than what a programmer expects causing a weakref's callback to be invoked at
a surprising time; it is good practice to program the callback defensively."

----------

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

From report at bugs.python.org  Wed Mar  3 13:34:10 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 03 Mar 2021 18:34:10 +0000
Subject: [issue42128] Structural Pattern Matching (PEP 634)
In-Reply-To: <1603466540.96.0.7677855399.issue42128@roundup.psfhosted.org>
Message-ID: <1614796450.24.0.952086965869.issue42128@roundup.psfhosted.org>


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

Should __match_args__ be added to Objects/structseq.c ?

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

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

From report at bugs.python.org  Wed Mar  3 13:39:15 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 03 Mar 2021 18:39:15 +0000
Subject: [issue43378] Pattern Matching section in tutorial refers to | as or
In-Reply-To: <1614720567.85.0.819945578913.issue43378@roundup.psfhosted.org>
Message-ID: <1614796755.7.0.0537528974843.issue43378@roundup.psfhosted.org>


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


----------
nosy: +Daniel Moisset, brandtbucher, gvanrossum, willingc

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

From report at bugs.python.org  Wed Mar  3 13:45:20 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 03 Mar 2021 18:45:20 +0000
Subject: [issue43383] imprecise handling of weakref callbacks
In-Reply-To: <1614746880.88.0.974985202377.issue43383@roundup.psfhosted.org>
Message-ID: <1614797120.35.0.630411948594.issue43383@roundup.psfhosted.org>


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

Have you tried doing a "gc.get_referrers" on your weakref, to verify that there aren't any references that you don't expect to be there?

Another diagnostic would be to run with cyclic garbage collection disabled (via gc.disable). If you're seeing different behaviour with gc disabled versus enabled, that would at least confirm the presence of reference cycles.

> Are local variables/stack frames cleaned lazily? Is the last accessed
> value of a dictionary cached internally, increasing its reference count?

My knowledge of current Python internals isn't as deep as it used to be, but I'd be quite surprised if either of these were true.

----------

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

From report at bugs.python.org  Wed Mar  3 13:49:46 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 03 Mar 2021 18:49:46 +0000
Subject: [issue43383] imprecise handling of weakref callbacks
In-Reply-To: <1614746880.88.0.974985202377.issue43383@roundup.psfhosted.org>
Message-ID: <1614797386.3.0.0366631397014.issue43383@roundup.psfhosted.org>


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

One more thing: I'm assuming that everything in sight is single-threaded? With more than one Python thread (even if that thread is auxiliary to anything you're doing - e.g., if you're working at an IPython prompt, there will likely be at least a couple of extra Python threads around), there's always the exciting possibility that the cyclic garbage collection can end up running on an essentially arbitrary Python thread; it would be good to rule that possibility out.

----------

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

From report at bugs.python.org  Wed Mar  3 13:51:37 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 03 Mar 2021 18:51:37 +0000
Subject: [issue43382] github CI blocked by the Ubuntu CI with an SSL error
In-Reply-To: <1614745744.43.0.675662116863.issue43382@roundup.psfhosted.org>
Message-ID: <1614797497.19.0.0812121899524.issue43382@roundup.psfhosted.org>


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

How do I get a CI run on a PR to actually pickup this change?  clicking rerun failed.

----------

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

From report at bugs.python.org  Wed Mar  3 13:56:47 2021
From: report at bugs.python.org (Brandt Bucher)
Date: Wed, 03 Mar 2021 18:56:47 +0000
Subject: [issue42128] Structural Pattern Matching (PEP 634)
In-Reply-To: <1603466540.96.0.7677855399.issue42128@roundup.psfhosted.org>
Message-ID: <1614797807.07.0.152970016883.issue42128@roundup.psfhosted.org>


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

Yeah, probably.

I'm not too familiar with the design of those objects... would it make more sense to have the implementation be a single descriptor shared by all derived types, or should we precompute the tuple of strings when each new type is defined?

I'm also not entirely sure how "unnamed fields" work, or what they're used for. Presumably we'd want to end the __match_args__ tuple upon hitting one of these?

----------

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

From report at bugs.python.org  Wed Mar  3 14:01:07 2021
From: report at bugs.python.org (Ned Deily)
Date: Wed, 03 Mar 2021 19:01:07 +0000
Subject: [issue43382] github CI blocked by the Ubuntu CI with an SSL error
In-Reply-To: <1614745744.43.0.675662116863.issue43382@roundup.psfhosted.org>
Message-ID: <1614798067.58.0.846049806884.issue43382@roundup.psfhosted.org>


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

You may have to refresh the PR so that is uses the latest HEAD that includes the config change.

----------

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

From report at bugs.python.org  Wed Mar  3 14:05:08 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 03 Mar 2021 19:05:08 +0000
Subject: [issue42128] Structural Pattern Matching (PEP 634)
In-Reply-To: <1603466540.96.0.7677855399.issue42128@roundup.psfhosted.org>
Message-ID: <1614798308.38.0.371784810051.issue42128@roundup.psfhosted.org>


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


----------
pull_requests: +23503
pull_request: https://github.com/python/cpython/pull/24732

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

From report at bugs.python.org  Wed Mar  3 14:06:47 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 03 Mar 2021 19:06:47 +0000
Subject: [issue42128] Structural Pattern Matching (PEP 634)
In-Reply-To: <1603466540.96.0.7677855399.issue42128@roundup.psfhosted.org>
Message-ID: <1614798407.95.0.704355075035.issue42128@roundup.psfhosted.org>


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

Opened https://github.com/python/cpython/pull/24732

> I'm also not entirely sure how "unnamed fields" work, or what they're used for. Presumably, we'd want to end the __match_args__ tuple upon hitting one of these?

AFAIK, they should be just excluded from __match_args__

----------

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

From report at bugs.python.org  Wed Mar  3 14:19:28 2021
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 03 Mar 2021 19:19:28 +0000
Subject: [issue43382] github CI blocked by the Ubuntu CI with an SSL error
In-Reply-To: <1614745744.43.0.675662116863.issue43382@roundup.psfhosted.org>
Message-ID: <1614799168.86.0.184011601603.issue43382@roundup.psfhosted.org>


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

Yeah, that's the annoying part. Users have to rebase all their PRs in order to make CI pass. It's going to be painful. :(

----------

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

From report at bugs.python.org  Wed Mar  3 14:20:03 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 03 Mar 2021 19:20:03 +0000
Subject: [issue42128] Structural Pattern Matching (PEP 634)
In-Reply-To: <1603466540.96.0.7677855399.issue42128@roundup.psfhosted.org>
Message-ID: <1614799203.64.0.620353359439.issue42128@roundup.psfhosted.org>


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


----------
pull_requests: +23504
pull_request: https://github.com/python/cpython/pull/24733

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

From report at bugs.python.org  Wed Mar  3 14:42:57 2021
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 03 Mar 2021 19:42:57 +0000
Subject: [issue43162] Enum regression: AttributeError when accessing class
 variables on instances
In-Reply-To: <1612786979.73.0.896348338765.issue43162@roundup.psfhosted.org>
Message-ID: <1614800577.06.0.939253795224.issue43162@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/issue43162>
_______________________________________

From report at bugs.python.org  Wed Mar  3 14:47:44 2021
From: report at bugs.python.org (Brandt Bucher)
Date: Wed, 03 Mar 2021 19:47:44 +0000
Subject: [issue43382] github CI blocked by the Ubuntu CI with an SSL error
In-Reply-To: <1614745744.43.0.675662116863.issue43382@roundup.psfhosted.org>
Message-ID: <1614800864.93.0.796552171035.issue43382@roundup.psfhosted.org>


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

Closing and reopening may work, or pushing an empty commit. I know that's helped appease some GitHub CI weirdness in the past.

----------

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

From report at bugs.python.org  Wed Mar  3 14:55:37 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 03 Mar 2021 19:55:37 +0000
Subject: [issue41561] test_ssl fails in Ubuntu 20.04:
 test_min_max_version_mismatch
In-Reply-To: <1597551049.14.0.0578030464715.issue41561@roundup.psfhosted.org>
Message-ID: <1614801337.86.0.728151042251.issue41561@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/issue41561>
_______________________________________

From report at bugs.python.org  Wed Mar  3 14:59:51 2021
From: report at bugs.python.org (Jake Gustafson)
Date: Wed, 03 Mar 2021 19:59:51 +0000
Subject: [issue43391] The comments have invalid license information (broken
 Python 2.4 URL for Python 3)
Message-ID: <1614801590.99.0.0824232667755.issue43391@roundup.psfhosted.org>


New submission from Jake Gustafson <tertiary at expertmultimedia.com>:

Steps to reproduce the issue:
- Run Python 3.7.3 (or later, possibly) with the following code:

    import subprocess
    import inspect
    with open("subprocess-py3.py", 'w') as outs:
        outs.write(inspect.getsource(subprocess).replace("\\n","\n"))

The resulting ./subprocess-py3.py contains the source code for subprocess including:

# Copyright (c) 2003-2005 by Peter Astrand <astrand at lysator.liu.se>
#
# Licensed to PSF under a Contributor Agreement.
# See http://www.python.org/2.4/license for licensing details.

However, the URL is broken, and whatever code Peter Astrand developed may be long gone--I'll leave it up to the devs to determine the correct license, but the link is broken and the code is significantly different even than Python 2.4's.

----------
assignee: docs at python
components: Documentation
messages: 388049
nosy: docs at python, poikilos
priority: normal
severity: normal
status: open
title: The comments have invalid license information (broken Python 2.4 URL for Python 3)
versions: Python 3.7

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

From report at bugs.python.org  Wed Mar  3 15:00:56 2021
From: report at bugs.python.org (Jake Gustafson)
Date: Wed, 03 Mar 2021 20:00:56 +0000
Subject: [issue43391] The comments have invalid license information (broken
 Python 2.4 URL for Python 3)
In-Reply-To: <1614801590.99.0.0824232667755.issue43391@roundup.psfhosted.org>
Message-ID: <1614801656.88.0.41275466625.issue43391@roundup.psfhosted.org>


Jake Gustafson <tertiary at expertmultimedia.com> added the comment:

*significantly different even than Python 2.7.16's.

----------

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

From report at bugs.python.org  Wed Mar  3 15:01:28 2021
From: report at bugs.python.org (Igor Mandrichenko)
Date: Wed, 03 Mar 2021 20:01:28 +0000
Subject: [issue43375] memory leak in threading ?
In-Reply-To: <1614708658.89.0.572605723578.issue43375@roundup.psfhosted.org>
Message-ID: <1614801688.88.0.705574445498.issue43375@roundup.psfhosted.org>


Igor Mandrichenko <igorvm at gmail.com> added the comment:

Since Timer thread is never joined, should not it be a daemon ?

----------

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

From report at bugs.python.org  Wed Mar  3 15:08:51 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 03 Mar 2021 20:08:51 +0000
Subject: [issue43382] github CI blocked by the Ubuntu CI with an SSL error
In-Reply-To: <1614745744.43.0.675662116863.issue43382@roundup.psfhosted.org>
Message-ID: <1614802131.01.0.932008089823.issue43382@roundup.psfhosted.org>


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

yeah i figured it might require a rebase.  if anyone has the appropriate git command to do that to a branch, creating a 2-4 step CLI playbook for people to apply to pending PR branches would be useful.

----------

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

From report at bugs.python.org  Wed Mar  3 15:13:22 2021
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Wed, 03 Mar 2021 20:13:22 +0000
Subject: [issue43162] Enum regression: AttributeError when accessing class
 variables on instances
In-Reply-To: <1612786979.73.0.896348338765.issue43162@roundup.psfhosted.org>
Message-ID: <1614802402.48.0.580817994597.issue43162@roundup.psfhosted.org>


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

Thank you, Ethan.

----------

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

From report at bugs.python.org  Wed Mar  3 15:17:20 2021
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 03 Mar 2021 20:17:20 +0000
Subject: [issue43391] The comments have invalid license information (broken
 Python 2.4 URL for Python 3)
In-Reply-To: <1614801590.99.0.0824232667755.issue43391@roundup.psfhosted.org>
Message-ID: <1614802640.89.0.923363464458.issue43391@roundup.psfhosted.org>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

https://www.python.org/download/releases/2.4/license/ is the correct link for the Python 2.4 license.

Note that the contributor agreement allows the PSF to distribute the code under a different OSS license and so the current Python license applies for whatever version of Python you are using applies.

Peter Astrand still owns the copyright to the code he contributed and so the notice may not be removed until everything he contributed is gone. Even then, it's a courtesy to the author to leave an authorship notice in the code, since the original contribution motivated the API, which mostly still is in place. In fact, the contrib agreement probably doesn't even allow removing it at all, since it requires:

"""
Contributor shall identify each Contribution by placing the following notice in its source code adjacent to Contributor's valid copyright notice: "Licensed to PSF under a Contributor Agreement." 
"""

This is the original file which was added:

https://github.com/python/cpython/blob/5b3687df2e6dce2c09662ec9287e8f23075c4f1d/Lib/subprocess.py

At that time we did not have contributor agreements in place, AFAIR. The contrib agreement came later and allowed the removal of the verbatim 3-clause BSD license.

It's probably good idea to remove the reference to Python 2.4 from the doc-string.

----------
nosy: +lemburg

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

From report at bugs.python.org  Wed Mar  3 15:28:02 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 03 Mar 2021 20:28:02 +0000
Subject: [issue43382] github CI blocked by the Ubuntu CI with an SSL error
In-Reply-To: <1614745744.43.0.675662116863.issue43382@roundup.psfhosted.org>
Message-ID: <1614803282.12.0.362293923745.issue43382@roundup.psfhosted.org>


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

we may not need that: Closing and reopening the PR worked.  I suspect the github CI "rerun" button was "rerun in the exact same config".

----------

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

From report at bugs.python.org  Wed Mar  3 15:36:30 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 03 Mar 2021 20:36:30 +0000
Subject: [issue40701] tempfile mixes str and bytes in an inconsistent manner
In-Reply-To: <1590002424.23.0.821521735552.issue40701@roundup.psfhosted.org>
Message-ID: <1614803790.85.0.96470936529.issue40701@roundup.psfhosted.org>


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


New changeset 9c7927400cd8f1d283bf7915b6b33fea81b8655d by Eric L in branch 'master':
bpo-40701: tempfile mixes str and bytes in an inconsistent manner (GH-20442)
https://github.com/python/cpython/commit/9c7927400cd8f1d283bf7915b6b33fea81b8655d


----------

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

From report at bugs.python.org  Wed Mar  3 15:36:42 2021
From: report at bugs.python.org (miss-islington)
Date: Wed, 03 Mar 2021 20:36:42 +0000
Subject: [issue40701] tempfile mixes str and bytes in an inconsistent manner
In-Reply-To: <1590002424.23.0.821521735552.issue40701@roundup.psfhosted.org>
Message-ID: <1614803802.4.0.757649881025.issue40701@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: +23505
pull_request: https://github.com/python/cpython/pull/24734

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

From report at bugs.python.org  Wed Mar  3 15:48:50 2021
From: report at bugs.python.org (=?utf-8?b?R2VybcOhbiBNw6luZGV6IEJyYXZv?=)
Date: Wed, 03 Mar 2021 20:48:50 +0000
Subject: [issue43392] Optimize repeated calls to `__import__()`
Message-ID: <1614804530.16.0.0156925953016.issue43392@roundup.psfhosted.org>


New submission from Germ?n M?ndez Bravo <german.mb at gmail.com>:

A call to `importlib.__import__()` normally locks the import for the module being worked on; this, however has a performance impact for modules that are already imported and fully initialized. An example of this are inline `__import__()` calls in a hot path that is called repeatedly during the life of the process.

Proposal: A two steps check in `importlib._bootstrap._find_and_load()` to avoid locking when the module has been already imported and it's ready.

----------
components: Library (Lib)
messages: 388057
nosy: Kronuz
priority: normal
severity: normal
status: open
title: Optimize repeated calls to `__import__()`
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Mar  3 16:02:29 2021
From: report at bugs.python.org (=?utf-8?b?R2VybcOhbiBNw6luZGV6IEJyYXZv?=)
Date: Wed, 03 Mar 2021 21:02:29 +0000
Subject: [issue43392] Optimize repeated calls to `__import__()`
In-Reply-To: <1614804530.16.0.0156925953016.issue43392@roundup.psfhosted.org>
Message-ID: <1614805349.14.0.753277462916.issue43392@roundup.psfhosted.org>


Change by Germ?n M?ndez Bravo <german.mb at gmail.com>:


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

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

From report at bugs.python.org  Wed Mar  3 16:07:23 2021
From: report at bugs.python.org (Tim Peters)
Date: Wed, 03 Mar 2021 21:07:23 +0000
Subject: [issue43383] imprecise handling of weakref callbacks
In-Reply-To: <1614746880.88.0.974985202377.issue43383@roundup.psfhosted.org>
Message-ID: <1614805643.91.0.893190678267.issue43383@roundup.psfhosted.org>


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

This won't go anywhere without code (preferably minimal) we can run to reproduce the complaint. If there were a "general principle" at work here, someone else would surely have reported it over the last few decades ;-)

To the contrary, the common confusion is in the _other_ direction: a weakref callback _not_ getting invoked when a programmer thinks it "should be". The cause for that is always the same: the weakref object died before the weakly referenced object died. That was the primary motivation for introducing `weakref.finalize()`.

CPython does not, in general, "batch" (or in any other way delay) object destruction. An object is destroyed - immediately - when its refcount falls to 0. In a technical sense, that's also true in the case of cycles (in which case the gc module artificially drives refcounts to 0, based on liveness and reachability analysis). With very few exceptions, neither does it hang on to "hidden" references. The primary exception to that is in interactive shells, where the module-global identifier "_" is typically bound, by magic, to the object most recently displayed. In the case of exceptions, it's also possible for programs to accidentally hang on to the exception object, from which the entire chain of stack frames back to the source of the exception can be reached.

So, based on what you said, this is the best attempt I can make:

    import sys, weakref

    class C:
        def __del__(self):
            print("__del__ called")

    def wrcb(x):
        print("weakref callback called")

    c = C()
    d = {"x" : weakref.ref(c, wrcb)}
    print(sys.getrefcount(d["x"]))

    #del d["x"]
    del c

which displays:

    2
    __del__ called
    weakref callback called

Note the 2! If the moral equivalent in your code displays a number larger than 2, then there are more references to the weakref object than just as a dict value (that's one; the other reference comes from temporarily incrementing the refcount of `d["x"]` to pass it as an argument to `getrefcount()`).

If I uncomment the penultimate line, to destroy the weakref before `c` is destroyed, the output changes to:

    2
    __del__ called

So it's all as expected. Can you change that code to demonstrate your case?

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

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

From report at bugs.python.org  Wed Mar  3 16:18:09 2021
From: report at bugs.python.org (nmatravolgyi)
Date: Wed, 03 Mar 2021 21:18:09 +0000
Subject: [issue43389] Cancellation ignored by asyncio.wait_for can hang
 application
In-Reply-To: <1614790258.6.0.416802160939.issue43389@roundup.psfhosted.org>
Message-ID: <1614806289.45.0.299347842878.issue43389@roundup.psfhosted.org>


nmatravolgyi <nandor.matra at gmail.com> added the comment:

I've quickly wanted to create a suitable solution for myself. I made a small library with a asyncio.wait_for()-like function using asyncio.wait(). The prototype worked, so I put together a small project. When I ran tox and realized that this issue with wait_for is only present on py38 and py39 (possibly py310). The wait_for does not get stuck with py36, py37 and pypy3.

The repo is a little bare bones, but you can run tox after checkout: https://github.com/Traktormaster/wait-for2

Right now the tests are set-up that they expect wait_for to get stuck so only py38 and py39 passes.

I'm pretty sure the side-effect of returning the future's result when handling cancellation is not desired. However I'm not sure how to handle it correctly. The repo holds a demo of what I suggested in the beginning of this thread (CancelledWithResultError). It works but it is limited.

----------

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

From report at bugs.python.org  Wed Mar  3 16:18:48 2021
From: report at bugs.python.org (Neil Schemenauer)
Date: Wed, 03 Mar 2021 21:18:48 +0000
Subject: [issue43382] github CI blocked by the Ubuntu CI with an SSL error
In-Reply-To: <1614745744.43.0.675662116863.issue43382@roundup.psfhosted.org>
Message-ID: <1614806328.27.0.67681098813.issue43382@roundup.psfhosted.org>


Neil Schemenauer <nas-python at arctrix.com> added the comment:

It seems it is enough to make a new commit.  The CI seems to re-base and re-run the PR.  At least, it worked on two of my PRs.

----------

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

From report at bugs.python.org  Wed Mar  3 16:19:04 2021
From: report at bugs.python.org (Kamil Turek)
Date: Wed, 03 Mar 2021 21:19:04 +0000
Subject: [issue43371] Mock.assert_has_calls works strange
In-Reply-To: <1614695494.31.0.773020245058.issue43371@roundup.psfhosted.org>
Message-ID: <1614806344.13.0.611950542526.issue43371@roundup.psfhosted.org>


Change by Kamil Turek <tazzu at live.com>:


----------
nosy: +kamilturek

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

From report at bugs.python.org  Wed Mar  3 16:33:14 2021
From: report at bugs.python.org (nmatravolgyi)
Date: Wed, 03 Mar 2021 21:33:14 +0000
Subject: [issue43389] Cancellation ignored by asyncio.wait_for can hang
 application
In-Reply-To: <1614790258.6.0.416802160939.issue43389@roundup.psfhosted.org>
Message-ID: <1614807194.9.0.422304083833.issue43389@roundup.psfhosted.org>


nmatravolgyi <nandor.matra at gmail.com> added the comment:

One more thing. I've figured out that I can fix the cancellation around the asyncio.wait_for() with asyncio.shield() like:

try:
    await asyncio.shield(wf := asyncio.ensure_future(asyncio.wait_for(self.event.wait(), timeout=60.0)))
except asyncio.CancelledError:
    wf.cancel()
    result = await asyncio.gather(wf, return_exceptions=True)
    # here I know there is a cancellation AND I might have a result as well!
    raise

However I don't like the idea of writing all that boilerplate for every wait_for usage. I still might be overlooking something, but at least I have adequate workarounds.

I'm curious what the consensus will be on this issue. I'm certain it should be documented though. Right now there is no mention of ignoring/eating a cancellation.

----------

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

From report at bugs.python.org  Wed Mar  3 16:45:25 2021
From: report at bugs.python.org (Kamil Turek)
Date: Wed, 03 Mar 2021 21:45:25 +0000
Subject: [issue43340] json.load() can raise UnicodeDecodeError,
 but this is not documented
In-Reply-To: <1614450261.52.0.147425024304.issue43340@roundup.psfhosted.org>
Message-ID: <1614807925.23.0.391971492016.issue43340@roundup.psfhosted.org>


Change by Kamil Turek <tazzu at live.com>:


----------
nosy: +kamilturek

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

From report at bugs.python.org  Wed Mar  3 16:56:18 2021
From: report at bugs.python.org (Kamil Turek)
Date: Wed, 03 Mar 2021 21:56:18 +0000
Subject: [issue43391] The comments have invalid license information (broken
 Python 2.4 URL for Python 3)
In-Reply-To: <1614801590.99.0.0824232667755.issue43391@roundup.psfhosted.org>
Message-ID: <1614808578.4.0.944595272181.issue43391@roundup.psfhosted.org>


Change by Kamil Turek <tazzu at live.com>:


----------
nosy: +kamilturek

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

From report at bugs.python.org  Wed Mar  3 17:17:03 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 03 Mar 2021 22:17:03 +0000
Subject: [issue43393] Older Python builds are missing a required file on Big
 Sur
Message-ID: <1614809823.25.0.747126603146.issue43393@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

When I upgraded to Big Sur, all my older builds stopped working.

Do we have any known workarounds or can we publish updated builds that work?

Like a lot of consultants, I still have to help clients maintain older code.  Having a standard working build is essential.


$ python3.5
dyld: Library not loaded: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
  Referenced from: /Library/Frameworks/Python.framework/Versions/3.5/Resources/Python.app/Contents/MacOS/Python
  Reason: image not found
Abort trap: 6

----------
components: macOS
messages: 388062
nosy: ned.deily, rhettinger, ronaldoussoren
priority: normal
severity: normal
status: open
title: Older Python builds are missing a required file on Big Sur
type: crash

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

From report at bugs.python.org  Wed Mar  3 17:22:26 2021
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 03 Mar 2021 22:22:26 +0000
Subject: [issue43162] Enum regression: AttributeError when accessing class
 variables on instances
In-Reply-To: <1612786979.73.0.896348338765.issue43162@roundup.psfhosted.org>
Message-ID: <1614810146.29.0.702289686615.issue43162@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

You're welcome.  Thank you for pushing the issue!  :-)

----------

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

From report at bugs.python.org  Wed Mar  3 17:35:35 2021
From: report at bugs.python.org (Kamil Turek)
Date: Wed, 03 Mar 2021 22:35:35 +0000
Subject: [issue43391] The comments have invalid license information (broken
 Python 2.4 URL for Python 3)
In-Reply-To: <1614801590.99.0.0824232667755.issue43391@roundup.psfhosted.org>
Message-ID: <1614810935.25.0.449701952063.issue43391@roundup.psfhosted.org>


Change by Kamil Turek <tazzu at live.com>:


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

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

From report at bugs.python.org  Wed Mar  3 17:42:16 2021
From: report at bugs.python.org (Kamil Turek)
Date: Wed, 03 Mar 2021 22:42:16 +0000
Subject: [issue43393] Older Python builds are missing a required file on Big
 Sur
In-Reply-To: <1614809823.25.0.747126603146.issue43393@roundup.psfhosted.org>
Message-ID: <1614811336.26.0.0944356455632.issue43393@roundup.psfhosted.org>


Change by Kamil Turek <tazzu at live.com>:


----------
nosy: +kamilturek

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

From report at bugs.python.org  Wed Mar  3 17:44:24 2021
From: report at bugs.python.org (Brandt Bucher)
Date: Wed, 03 Mar 2021 22:44:24 +0000
Subject: [issue43394] Compiler warnings on master (-Wstrict-prototypes)
Message-ID: <1614811464.76.0.205706240961.issue43394@roundup.psfhosted.org>


New submission from Brandt Bucher <brandtbucher at gmail.com>:

We're getting "function declaration isn?t a prototype [-Wstrict-prototypes]" warnings in Modules/_zoneinfo.c and Modules/_xxtestfuzz/fuzzer.c.

I'll have a patch up momentarily.

----------
assignee: brandtbucher
components: Build
messages: 388064
nosy: brandtbucher
priority: normal
severity: normal
status: open
title: Compiler warnings on master (-Wstrict-prototypes)
type: compile error
versions: Python 3.10

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

From report at bugs.python.org  Wed Mar  3 17:46:53 2021
From: report at bugs.python.org (Brandt Bucher)
Date: Wed, 03 Mar 2021 22:46:53 +0000
Subject: [issue43394] Compiler warnings on master (-Wstrict-prototypes)
In-Reply-To: <1614811464.76.0.205706240961.issue43394@roundup.psfhosted.org>
Message-ID: <1614811613.7.0.470729755255.issue43394@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Wed Mar  3 18:33:17 2021
From: report at bugs.python.org (Brandt Bucher)
Date: Wed, 03 Mar 2021 23:33:17 +0000
Subject: [issue43376] Add PyComplex_FromString
In-Reply-To: <1614714591.46.0.224854150713.issue43376@roundup.psfhosted.org>
Message-ID: <1614814397.72.0.719654356381.issue43376@roundup.psfhosted.org>


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

Hm, I didn't realize until now that PyFloat_FromString parses a Python string, while PyLong_FromString parses a C string (with very different signatures). That's a bit annoying. 

Regardless, I misunderstood the original issue: in this particular case we are converting *Python* strings, so just doing the equivalent of a "complex(s)" call is fine.

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

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

From report at bugs.python.org  Wed Mar  3 19:03:48 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 04 Mar 2021 00:03:48 +0000
Subject: [issue42128] Structural Pattern Matching (PEP 634)
In-Reply-To: <1603466540.96.0.7677855399.issue42128@roundup.psfhosted.org>
Message-ID: <1614816228.85.0.734129382428.issue42128@roundup.psfhosted.org>


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


New changeset 0632b1012d4dfa81ffef0d686a4710f6134f77a8 by Pablo Galindo in branch 'master':
bpo-42128: Add __match_args__ to structseq-based classes (GH-24732)
https://github.com/python/cpython/commit/0632b1012d4dfa81ffef0d686a4710f6134f77a8


----------

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

From report at bugs.python.org  Wed Mar  3 20:21:51 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 04 Mar 2021 01:21:51 +0000
Subject: [issue42202] Optimize function annotation
In-Reply-To: <1604040435.44.0.369975398522.issue42202@roundup.psfhosted.org>
Message-ID: <1614820911.23.0.306667893145.issue42202@roundup.psfhosted.org>


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


----------
nosy: +pablogsal
nosy_count: 7.0 -> 8.0
pull_requests: +23509
pull_request: https://github.com/python/cpython/pull/24738

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

From report at bugs.python.org  Wed Mar  3 20:29:33 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 04 Mar 2021 01:29:33 +0000
Subject: [issue42202] Optimize function annotation
In-Reply-To: <1604040435.44.0.369975398522.issue42202@roundup.psfhosted.org>
Message-ID: <1614821373.2.0.7530177076.issue42202@roundup.psfhosted.org>


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


New changeset 8747c1f233fc1a3dd5ee3d8e163317f28b4d7568 by Pablo Galindo in branch 'master':
Improve the description of the improvements in bpo-42202 (GH-24738)
https://github.com/python/cpython/commit/8747c1f233fc1a3dd5ee3d8e163317f28b4d7568


----------

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

From report at bugs.python.org  Wed Mar  3 20:58:32 2021
From: report at bugs.python.org (David Bolen)
Date: Thu, 04 Mar 2021 01:58:32 +0000
Subject: [issue43271] AMD64 Windows10 3.x crash with Windows fatal exception:
 stack overflow
In-Reply-To: <1613766414.64.0.363657915419.issue43271@roundup.psfhosted.org>
Message-ID: <1614823112.04.0.688173938244.issue43271@roundup.psfhosted.org>


Change by David Bolen <db3l.net at gmail.com>:


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

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

From report at bugs.python.org  Wed Mar  3 21:16:26 2021
From: report at bugs.python.org (Ned Deily)
Date: Thu, 04 Mar 2021 02:16:26 +0000
Subject: [issue43393] Older Python builds are missing a required file on Big
 Sur
In-Reply-To: <1614809823.25.0.747126603146.issue43393@roundup.psfhosted.org>
Message-ID: <1614824186.06.0.114759104526.issue43393@roundup.psfhosted.org>


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

In summary, the Python binaries provided by python.org macOS installers for already end-of-life versions of Python, like 3.5 and earlier 3.x versions, do not run on macOS 11 Big Sur and attempting to build these end-of-life versions from source will still not produce a fully-functional Python on macOS 11.

For others reading this, per PEP 478, Python 3.5.4 was the last "bugfix" release of 3.5 back in August 2017 and, per long-standing release policy, binary installers for Windows and macOS are no longer manufactured once a version transitions from its "bugfix" to its "security-fix-only" phase. Further, Python 3.5 reached "end-of-life" in September 2020, five years after its initial release. So, technically, Python 3.5 is totally unsupported by the CPython project.

That said, I did take a quick look at this. A web search found a number of other similar reports dating back to the initial release of Big Sur last year. The error message is definitely not very helpful (the CoreFoundation framework remains an essential piece of macOS) and I still have not seen a total explanation of what is going on but I'm 99% sure that the problem is that python.org macOS installers for Python 3.5 were built for macOS 10.6+ and it is likely that there is some old cruft in the macOS CoreFoundation framework that Apple decided it no longer wanted to support as of macOS 11 (Apple did a lot of "housecleaning" in and leading up to Big Sur, one reason for the numbering change from 10.x to 11) and likely bumped a minimum supported version of CoreFoundation thus preventing executables that dynamically link to the older version to fail on launch, as in this case.

Note that the most recent python.org macOS installers for releases since 3.5 (including the final bugfix/binary releases of 3.7.x, 3.6.x, and 2.7.x) were built for at least macOS 10.9+ and do not exhibit this problem on macOS 11 Big Sur. So it's only an issue for 3.5 and earlier 3.x versions of the python.org installers, all of which have reached end-of-life.

I'm not aware of any way practical way to workaround this problem and make those installer binaries load on Big Sur. Clearly, the best longer-term solution is to upgrade to a supported version (like 3.9.x).  But possible workarounds:
1. If 3.5.x is absolutely needed, there are third-party distributors that continue to support older versions of Python. In particular, the MacPorts project provides pre-built binaries of Python 3.5 (and other releases) that run on macOS 11 (and for older releases of macOS, too).
2. If the python.org 3.5 is absolutely needed, don't upgrade to Big Sur or run MacOS 10.15 (or earlier) in a virtual machine.
3. Build from source on Big Sur.

But keep in mind that, with any of those workarounds, there still is the fundamental issue that there were a number of changes in Big Sur that affect Python; there are build changes needed and, even when those are overcome, some things just don't work correctly on Big Sur without fixes; distutils and ctypes find_library of a system library (see Issue41116), come to mind. At the moment, only Python 3.9.1 and later are fully supported on Big Sur.

Sorry I don't have a more positive answer.

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

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

From report at bugs.python.org  Wed Mar  3 21:33:03 2021
From: report at bugs.python.org (Ned Deily)
Date: Thu, 04 Mar 2021 02:33:03 +0000
Subject: [issue43370] thread_time not available on python.org OS X builds
In-Reply-To: <1614688842.62.0.631384615998.issue43370@roundup.psfhosted.org>
Message-ID: <1614825183.1.0.336681370177.issue43370@roundup.psfhosted.org>


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

The reason time.thread_time() and several other functions in other modules that all depend on features in newer versions of macOS were not available in python.org macOS binaries because the installers are meant to support a range of operating system releases (rather than just one operating system version as with most other distributors) and, up until recently, the only supported way to do that was to build the binaries on the oldest supported system. Thus most python.org installers in recent years were built on macOS 10.9 where time.thread_time() does not exist. As of Python 3.9.1, with the addition of support for macOS 11 and Apple Silicon Macs, support for "weak-linking" was also added meaning that it is now possible to build Python 3.9.1+ on, say, macOS 11 and have it work without crashing on older systems. Currently, we only test back as far as 10.9. This feature is in the 10.9+ "universal2" variants available for 3.9.1+ releases and for 3.10 pre-releases.

https://docs.python.org/3/whatsnew/3.9.html#notable-changes-in-python-3-9-1

----------
nosy: +ned.deily
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Wed Mar  3 22:03:54 2021
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 04 Mar 2021 03:03:54 +0000
Subject: [issue36067] subprocess terminate() "invalid handle" error when
 process is gone
In-Reply-To: <1550763482.04.0.374893682062.issue36067@roundup.psfhosted.org>
Message-ID: <1614827034.76.0.904362011707.issue36067@roundup.psfhosted.org>


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

> I don't understand why any patch for CPython is needed at all.

If and operation on self._handle fails as an invalid handle (due to an underlying STATUS_INVALID_HANDLE or STATUS_OBJECT_TYPE_MISMATCH), then call self._handle.Detach() and re-raise the exception.

It wouldn't hurt to also address the case in which coincidentally the handle value currently references another process. When the process is spawned, save the (process_id, creation_time) via GetProcessId() and GetProcessTimes(). Implement a function that validates these values before calling WaitForSingleObject(), GetExitCodeProcess(), or TerminateProcess(). If validation fails, call self._handle.Detach() and raise OSError.

----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
stage: needs patch -> 
type: behavior -> enhancement
versions: +Python 3.10, Python 3.9 -Python 2.7, Python 3.6, Python 3.7

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

From report at bugs.python.org  Wed Mar  3 22:08:58 2021
From: report at bugs.python.org (Ned Deily)
Date: Thu, 04 Mar 2021 03:08:58 +0000
Subject: [issue43379] Pasting multiple lines in the REPL is broken since 3.9
In-Reply-To: <1614721536.12.0.538890122544.issue43379@roundup.psfhosted.org>
Message-ID: <1614827338.07.0.753083034786.issue43379@roundup.psfhosted.org>


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

Sorry, I cannot reproduce that behavior. The output you show isn't what I would expect, in any case.

$ python3.8
Python 3.8.7 (v3.8.7:6503f05dd5, Dec 21 2020, 12:45:15)
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> def f():
...     print("hello world")
...
>>> ^D
$ python3.9
Python 3.9.1 (v3.9.1:1e5d33e9b9, Dec  7 2020, 12:44:01)
[Clang 12.0.0 (clang-1200.0.32.27)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> def f():
...     print("hello world")
...
>>> ^D

Note the missing '...' continuation prompts.  So can you verify that the text when you paste it includes just a standard linefeed (LF) control character as the end-of-line delimiter?  Other possible differences might be whether the python in use was linked with the BSD libedit library or with GNU readline but that shouldn't make a difference unless you have some non-default options in their configuration files.  You can check which one is in use with this:

$ python3.8 -c "import readline;print(readline.__doc__)"
Importing this module enables command line editing using GNU readline.
$ python3.9 -c "import readline;print(readline.__doc__)"
Importing this module enables command line editing using libedit readline.

If all else fails, from where did you obtain the pythons that you are using?  And in what environment are you running those commands, i.e. the macOS Terminal.app?

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

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

From report at bugs.python.org  Wed Mar  3 22:09:56 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 04 Mar 2021 03:09:56 +0000
Subject: [issue43271] AMD64 Windows10 3.x crash with Windows fatal exception:
 stack overflow
In-Reply-To: <1613766414.64.0.363657915419.issue43271@roundup.psfhosted.org>
Message-ID: <1614827396.02.0.262390479273.issue43271@roundup.psfhosted.org>


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


New changeset 131d5516409791b170b09a6ef8ed8463c9b09015 by db3l in branch 'master':
bpo-43271: Re-enable ceval.c optimizations for Windows debug builds (GH-24739)
https://github.com/python/cpython/commit/131d5516409791b170b09a6ef8ed8463c9b09015


----------

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

From report at bugs.python.org  Wed Mar  3 22:30:07 2021
From: report at bugs.python.org (David Bolen)
Date: Thu, 04 Mar 2021 03:30:07 +0000
Subject: [issue43271] AMD64 Windows10 3.x crash with Windows fatal exception:
 stack overflow
In-Reply-To: <1613766414.64.0.363657915419.issue43271@roundup.psfhosted.org>
Message-ID: <1614828607.24.0.391808633195.issue43271@roundup.psfhosted.org>


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

The win10 buildbot is green again, so I think this can be closed.

----------

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

From report at bugs.python.org  Wed Mar  3 23:21:30 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 04 Mar 2021 04:21:30 +0000
Subject: [issue43271] AMD64 Windows10 3.x crash with Windows fatal exception:
 stack overflow
In-Reply-To: <1613766414.64.0.363657915419.issue43271@roundup.psfhosted.org>
Message-ID: <1614831690.35.0.440609039164.issue43271@roundup.psfhosted.org>


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

Thanks for all your research and the PR!

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

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

From report at bugs.python.org  Wed Mar  3 23:39:37 2021
From: report at bugs.python.org (cmhzc)
Date: Thu, 04 Mar 2021 04:39:37 +0000
Subject: [issue43319] A possible misleading expression in the Virtual
 Environment Tutorial
In-Reply-To: <1614242172.25.0.356452528592.issue43319@roundup.psfhosted.org>
Message-ID: <1614832777.95.0.709547243182.issue43319@roundup.psfhosted.org>


Change by cmhzc <chmhzc at 126.com>:


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

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

From report at bugs.python.org  Thu Mar  4 00:05:16 2021
From: report at bugs.python.org (hai shi)
Date: Thu, 04 Mar 2021 05:05:16 +0000
Subject: [issue43060] Convert _decimal C API from pointer array to struct
In-Reply-To: <1611913613.83.0.451385849535.issue43060@roundup.psfhosted.org>
Message-ID: <1614834316.46.0.978853379418.issue43060@roundup.psfhosted.org>


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

> True. Is there many external users of this API? I could not find any relevant examples using searchcode.com.

Hm, many teams don't open their code, so we get check all user cases by searchcode web. So I have no any better sugesstion about it :(

----------

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

From report at bugs.python.org  Thu Mar  4 00:39:50 2021
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 04 Mar 2021 05:39:50 +0000
Subject: [issue43344] RotatingFileHandler breaks file type associations
In-Reply-To: <1614465857.24.0.529577943251.issue43344@roundup.psfhosted.org>
Message-ID: <1614836390.79.0.372179206402.issue43344@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


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

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

From report at bugs.python.org  Thu Mar  4 00:54:06 2021
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 04 Mar 2021 05:54:06 +0000
Subject: [issue43394] Compiler warnings on master (-Wstrict-prototypes)
In-Reply-To: <1614811464.76.0.205706240961.issue43394@roundup.psfhosted.org>
Message-ID: <1614837246.0.0.725885791443.issue43394@roundup.psfhosted.org>


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


New changeset c61ec7e6b892313cd3ecbaf02227bacb9d5ddaa2 by Brandt Bucher in branch 'master':
bpo-43394: Fix -Wstrict-prototypes warnings (GH-24737)
https://github.com/python/cpython/commit/c61ec7e6b892313cd3ecbaf02227bacb9d5ddaa2


----------

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

From report at bugs.python.org  Thu Mar  4 00:54:23 2021
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 04 Mar 2021 05:54:23 +0000
Subject: [issue43394] Compiler warnings on master (-Wstrict-prototypes)
In-Reply-To: <1614811464.76.0.205706240961.issue43394@roundup.psfhosted.org>
Message-ID: <1614837263.96.0.464782496451.issue43394@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/issue43394>
_______________________________________

From report at bugs.python.org  Thu Mar  4 01:31:25 2021
From: report at bugs.python.org (Eric L.)
Date: Thu, 04 Mar 2021 06:31:25 +0000
Subject: [issue43395] os.path states that bytes can't represent all MBCS paths
 under Windows
Message-ID: <1614839485.4.0.948731177165.issue43395@roundup.psfhosted.org>


New submission from Eric L. <ewl+python at lavar.de>:

The os.path documentation at https://docs.python.org/3/library/os.path.html states that:

> Vice versa, using bytes objects cannot represent all file names on Windows (in the standard mbcs encoding), hence Windows applications should use string objects to access all files.

This doesn't sound right and is at least misleading because anything can be represented as bytes, as everything (in a computer) is bytes at the end of the day, unless mbcs is really using something like half-bytes, which I couldn't find any sign of (skimming through the documentation, Microsoft seems to interpret it as DBCS, one or two bytes).

I could imagine that the meaning is that some bytes combinations can't be used as path under Windows, but I just don't know, and that wouldn't be a valid reason to not use bytes under Windows (IMHO).

----------
assignee: docs at python
components: Documentation
messages: 388077
nosy: docs at python, ericzolf
priority: normal
severity: normal
status: open
title: os.path states that bytes can't represent all MBCS paths under Windows
type: enhancement
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Mar  4 01:44:56 2021
From: report at bugs.python.org (Tore Anderson)
Date: Thu, 04 Mar 2021 06:44:56 +0000
Subject: [issue43396] Non-existent method sqlite3.Connection.fetchone() used
 in docs
Message-ID: <1614840295.99.0.480319283179.issue43396@roundup.psfhosted.org>


New submission from Tore Anderson <tore at fud.no>:

In https://docs.python.org/3/library/sqlite3.html, the following example code is found:

> # Do this instead
> t = ('RHAT',)
> c.execute('SELECT * FROM stocks WHERE symbol=?', t)
> print(c.fetchone())

However this fails as follows:

> Traceback (most recent call last):
>   File "./test.py", line 8, in <module>
>     print(c.fetchone())
> AttributeError: 'sqlite3.Connection' object has no attribute 'fetchone'

I believe the correct code should have been (at least it works for me):

> # Do this instead
> t = ('RHAT',)
> cursor = c.execute('SELECT * FROM stocks WHERE symbol=?', t)
> print(cursor.fetchone())

Tore

----------
assignee: docs at python
components: Documentation
messages: 388078
nosy: docs at python, toreanderson
priority: normal
severity: normal
status: open
title: Non-existent method sqlite3.Connection.fetchone() used in docs
versions: Python 3.9

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

From report at bugs.python.org  Thu Mar  4 03:05:24 2021
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 04 Mar 2021 08:05:24 +0000
Subject: [issue43364] Add shortcut to enable UTF-8 mode in start menu.
In-Reply-To: <1614675827.66.0.411790166938.issue43364@roundup.psfhosted.org>
Message-ID: <1614845124.66.0.976490338935.issue43364@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Thu Mar  4 03:46:59 2021
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 04 Mar 2021 08:46:59 +0000
Subject: [issue43364] Add shortcut to enable UTF-8 mode in start menu.
In-Reply-To: <1614675827.66.0.411790166938.issue43364@roundup.psfhosted.org>
Message-ID: <1614847619.23.0.994484393441.issue43364@roundup.psfhosted.org>


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


----------
pull_requests: +23513
pull_request: https://github.com/python/cpython/pull/24743

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

From report at bugs.python.org  Thu Mar  4 04:42:06 2021
From: report at bugs.python.org (=?utf-8?b?0KHQtdGA0LPQtdC5INCc?=)
Date: Thu, 04 Mar 2021 09:42:06 +0000
Subject: [issue43397] Incorrect conversion path case with german character
Message-ID: <1614850926.28.0.842904177967.issue43397@roundup.psfhosted.org>


New submission from ?????? ? <voramva at gmail.com>:

I try to normalize case for path with german characters:

```
>os.path.normcase(r'c:\asd\ASD?')
'c:\\asd\\asd?'
```

But in OS Windows r'c:\asd\ASD?' and r'c:\asd\asd?' are different paths.

----------
components: Windows
messages: 388079
nosy: paul.moore, steve.dower, tim.golden, voramva, zach.ware
priority: normal
severity: normal
status: open
title: Incorrect conversion path case with german character
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Thu Mar  4 04:50:40 2021
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 04 Mar 2021 09:50:40 +0000
Subject: [issue43369] [sqlite3] Handle out-of-memory errors in
 sqlite3_column_*()
In-Reply-To: <1614688659.29.0.386186084124.issue43369@roundup.psfhosted.org>
Message-ID: <1614851440.09.0.819557549145.issue43369@roundup.psfhosted.org>


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


New changeset e161ec5dd7ba9355eb06757b9304019ac53cdf69 by Erlend Egeberg Aasland in branch 'master':
bpo-43369: sqlite3_column_{text,blob} failures now raise MemoryError (GH-24723)
https://github.com/python/cpython/commit/e161ec5dd7ba9355eb06757b9304019ac53cdf69


----------

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

From report at bugs.python.org  Thu Mar  4 04:51:00 2021
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 04 Mar 2021 09:51:00 +0000
Subject: [issue43369] [sqlite3] Handle out-of-memory errors in
 sqlite3_column_*()
In-Reply-To: <1614688659.29.0.386186084124.issue43369@roundup.psfhosted.org>
Message-ID: <1614851460.04.0.873025549051.issue43369@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Thu Mar  4 05:29:36 2021
From: report at bugs.python.org (Xi Ruoyao)
Date: Thu, 04 Mar 2021 10:29:36 +0000
Subject: [issue40642] Cpython "pystate.h" subdirectory wrong
In-Reply-To: <1589614857.55.0.73631693439.issue40642@roundup.psfhosted.org>
Message-ID: <1614853776.6.0.629701135804.issue40642@roundup.psfhosted.org>


Change by Xi Ruoyao <xry111 at mengyan1223.wang>:


----------
keywords: +patch
nosy: +xry111
nosy_count: 3.0 -> 4.0
pull_requests: +23514
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24744

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

From report at bugs.python.org  Thu Mar  4 05:35:43 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Thu, 04 Mar 2021 10:35:43 +0000
Subject: [issue43396] Non-existent method sqlite3.Connection.fetchone() used
 in docs
In-Reply-To: <1614840295.99.0.480319283179.issue43396@roundup.psfhosted.org>
Message-ID: <1614854143.71.0.920532088075.issue43396@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

Correct, fetchone() is a cursor method. Thanks for the report!

----------
nosy: +berker.peksag, erlendaasland

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

From report at bugs.python.org  Thu Mar  4 05:39:59 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Thu, 04 Mar 2021 10:39:59 +0000
Subject: [issue43396] Non-existent method sqlite3.Connection.fetchone() used
 in docs
In-Reply-To: <1614840295.99.0.480319283179.issue43396@roundup.psfhosted.org>
Message-ID: <1614854399.15.0.239901936326.issue43396@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


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

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

From report at bugs.python.org  Thu Mar  4 05:54:37 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Thu, 04 Mar 2021 10:54:37 +0000
Subject: [issue43398] [sqlite3] sqlite3.connect() segfaults if given a faulty
 Connection factory
Message-ID: <1614855277.19.0.209861526791.issue43398@roundup.psfhosted.org>


New submission from Erlend Egeberg Aasland <erlend.aasland at innova.no>:

If the connection factory __init__ method fails, we hit a seg. fault when pysqlite_do_all_statements() is called to clean up the defect connection: PyList_Size received a NULL pointer.

Suggested fix:
Split pysqlite_do_all_statements() in two: one function for resetting cursors, and one for resetting/finalising statements. In each function, check if the respective lists are NULL pointers before iterating. See attached proposed patch.

Test:
    def test_invalid_connection_factory(self):
        class DefectFactory(sqlite.Connection):
            def __init__(self, *args, **kwargs):
                return None
        self.con = sqlite.connect(":memory:", factory=DefectFactory)

----------
components: Library (Lib)
files: patch.diff
keywords: patch
messages: 388082
nosy: berker.peksag, erlendaasland, serhiy.storchaka
priority: normal
severity: normal
status: open
title: [sqlite3] sqlite3.connect() segfaults if given a faulty Connection factory
type: crash
versions: Python 3.10
Added file: https://bugs.python.org/file49850/patch.diff

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

From report at bugs.python.org  Thu Mar  4 06:53:51 2021
From: report at bugs.python.org (Tomy Hsieh)
Date: Thu, 04 Mar 2021 11:53:51 +0000
Subject: [issue32824] Docs: Using Python on a Macintosh has bad info per Apple
 site
In-Reply-To: <1518392554.24.0.467229070634.issue32824@psf.upfronthosting.co.za>
Message-ID: <1614858831.54.0.96996566187.issue32824@roundup.psfhosted.org>


Change by Tomy Hsieh <tomy0000000 at gmail.com>:


----------
nosy: +tomy0000000

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

From report at bugs.python.org  Thu Mar  4 06:54:11 2021
From: report at bugs.python.org (Tomy Hsieh)
Date: Thu, 04 Mar 2021 11:54:11 +0000
Subject: [issue12594] Docs for "Using Python on a Macintosh" needs to be
 updated
In-Reply-To: <1311174057.47.0.56455855185.issue12594@psf.upfronthosting.co.za>
Message-ID: <1614858851.86.0.55873110922.issue12594@roundup.psfhosted.org>


Change by Tomy Hsieh <tomy0000000 at gmail.com>:


----------
nosy: +tomy0000000

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

From report at bugs.python.org  Thu Mar  4 08:09:54 2021
From: report at bugs.python.org (Konrad Schwarz)
Date: Thu, 04 Mar 2021 13:09:54 +0000
Subject: [issue43383] imprecise handling of weakref callbacks
In-Reply-To: <1614746880.88.0.974985202377.issue43383@roundup.psfhosted.org>
Message-ID: <1614863394.71.0.914055606805.issue43383@roundup.psfhosted.org>


Konrad Schwarz <konrad.schwarz at gmail.com> added the comment:

Unfortunately, my management has impressed other priorities upon me; I can't delve deeper into this subject at the moment.

My takeaway is that the error very likely lies on my side; maybe I need to re-check local variables and del them explicitly.  In any case, I can work around the situation by being extra careful in the callback.  I don't know how well all of this would work in a truly multi-threaded environment, but the application doesn't require that at all.

In any case, thank you for the insightful comments and the willingness to understand my problem!  I certainly have learned a lot.

----------

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

From report at bugs.python.org  Thu Mar  4 08:10:31 2021
From: report at bugs.python.org (Konrad Schwarz)
Date: Thu, 04 Mar 2021 13:10:31 +0000
Subject: [issue43383] imprecise handling of weakref callbacks
In-Reply-To: <1614746880.88.0.974985202377.issue43383@roundup.psfhosted.org>
Message-ID: <1614863431.67.0.407937421411.issue43383@roundup.psfhosted.org>


Change by Konrad Schwarz <konrad.schwarz at gmail.com>:


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

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

From report at bugs.python.org  Thu Mar  4 08:14:39 2021
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 04 Mar 2021 13:14:39 +0000
Subject: [issue43364] Add shortcut to enable UTF-8 mode in start menu.
In-Reply-To: <1614675827.66.0.411790166938.issue43364@roundup.psfhosted.org>
Message-ID: <1614863679.11.0.998642661406.issue43364@roundup.psfhosted.org>


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

> I'm always very hesitant to modify system-wide (or user-wide) settings 
> like this though. I'd be more comfortable if we made it a PYTHONUTF8_310
> variable that _only_ applies to that specific version. Otherwise someone
> might install an update and break existing apps.

Yes, if the installer directly sets an environment variable, then the setting should be specific to the installed version, such as PYTHONUTF8_310-32.

Maybe this could be implemented more generally by supporting a "PYTHONX_{py_version_short_plat}" environment variable that contains a list of -X implementation-specific boolean options to enable by default, e.g. set "PYTHONX_3.10-32=utf8;dev". In POSIX, name it "PYTHONX_{py_version_short}". In Windows, "{py_version_short_plat}" would be sys.winver.

----------

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

From report at bugs.python.org  Thu Mar  4 08:46:03 2021
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 04 Mar 2021 13:46:03 +0000
Subject: [issue43396] Non-existent method sqlite3.Connection.fetchone() used
 in docs
In-Reply-To: <1614840295.99.0.480319283179.issue43396@roundup.psfhosted.org>
Message-ID: <1614865563.84.0.131264999195.issue43396@roundup.psfhosted.org>


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

Could you please post the full snippet?

c is already set to a cursor at https://github.com/python/cpython/blame/e161ec5dd7ba9355eb06757b9304019ac53cdf69/Doc/library/sqlite3.rst#L56:

    c = conn.cursor()

And the following example works fine:

    >>> import sqlite3 as s
    >>> conn = s.connect(":memory:")
    >>> c = conn.cursor()
    >>> c.execute("select 1")
    <sqlite3.Cursor object at 0x00000291A5A1F960>
    >>> c.fetchone()
    (1,)

----------

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

From report at bugs.python.org  Thu Mar  4 08:48:15 2021
From: report at bugs.python.org (Tore Anderson)
Date: Thu, 04 Mar 2021 13:48:15 +0000
Subject: [issue43396] Non-existent method sqlite3.Connection.fetchone() used
 in docs
In-Reply-To: <1614840295.99.0.480319283179.issue43396@roundup.psfhosted.org>
Message-ID: <1614865695.33.0.279893680906.issue43396@roundup.psfhosted.org>


Tore Anderson <tore at fud.no> added the comment:

You're looking in the wrong place, the buggy ones are at https://github.com/python/cpython/blame/e161ec5dd7ba9355eb06757b9304019ac53cdf69/Doc/library/sqlite3.rst#L74-L76

Tore

----------

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

From report at bugs.python.org  Thu Mar  4 08:55:07 2021
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 04 Mar 2021 13:55:07 +0000
Subject: [issue43396] Non-existent method sqlite3.Connection.fetchone() used
 in docs
In-Reply-To: <1614840295.99.0.480319283179.issue43396@roundup.psfhosted.org>
Message-ID: <1614866107.98.0.598281070477.issue43396@roundup.psfhosted.org>


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

https://github.com/python/cpython/blame/e161ec5dd7ba9355eb06757b9304019ac53cdf69/Doc/library/sqlite3.rst#L74-L76 is not a standalone snippet. It uses the cursor object created at https://github.com/python/cpython/blame/e161ec5dd7ba9355eb06757b9304019ac53cdf69/Doc/library/sqlite3.rst#L54-L56 So there is nothing wrong here.

Maybe we can rename c to cur to make it more readable and harder to be confused with a connection object.

----------

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

From report at bugs.python.org  Thu Mar  4 09:18:56 2021
From: report at bugs.python.org (Tore Anderson)
Date: Thu, 04 Mar 2021 14:18:56 +0000
Subject: [issue43396] Non-existent method sqlite3.Connection.fetchone() used
 in docs
In-Reply-To: <1614840295.99.0.480319283179.issue43396@roundup.psfhosted.org>
Message-ID: <1614867536.32.0.353801658875.issue43396@roundup.psfhosted.org>


Tore Anderson <tore at fud.no> added the comment:

You're right. I got it confused with the conn object in the code I was working on, because it turns out that it has an execute() method:

>>> import sqlite3
>>> c = sqlite3.connect('test.db')
>>> c.execute('SELECT * FROM tbl')
<sqlite3.Cursor object at 0x7f6dc7a07c00>

Closing, apologies for the noise!

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

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

From report at bugs.python.org  Thu Mar  4 09:20:34 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Thu, 04 Mar 2021 14:20:34 +0000
Subject: [issue43396] Non-existent method sqlite3.Connection.fetchone() used
 in docs
In-Reply-To: <1614840295.99.0.480319283179.issue43396@roundup.psfhosted.org>
Message-ID: <1614867634.01.0.0450157199176.issue43396@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

Right, got me confused as well! I guess a clarification would be an improvement :)

----------

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

From report at bugs.python.org  Thu Mar  4 09:27:28 2021
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 04 Mar 2021 14:27:28 +0000
Subject: [issue43395] os.path states that bytes can't represent all MBCS paths
 under Windows
In-Reply-To: <1614839485.4.0.948731177165.issue43395@roundup.psfhosted.org>
Message-ID: <1614868048.12.0.322783874664.issue43395@roundup.psfhosted.org>


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

> Vice versa, using bytes objects cannot represent all file names 
> on Windows (in the standard mbcs encoding), hence Windows 
> applications should use string objects to access all files.

This is outdated advice that should be removed, or at least reworded to emphasize that the 'mbcs' encoding is only used in legacy mode, with a link to the documentation of sys._enablelegacywindowsfsencoding [1].

Starting in Python 3.6, the default filesystem encoding in Windows is UTF-8. Internally, what happens is that a UTF-8 byte string gets translated to UTF-16 (2 or 4 bytes per character), the native Unicode encoding of the Windows API. 

A caveat is that Windows filesystems use 16-bit characters that are not restricted to valid Unicode. In particular, ordinals U+D800-U+DFFF are not reserved for use in surrogate pairs. This is "Wobbly" Unicode, and the filesystem encoding thus needs to be "Wobbly Transformation Format, 8-bit" (WTF-8). This is implemented in Python by setting the encode errors handler to "surrogatepass", in contrast to using "surrogateescape" in POSIX. For example, os.fsencode('\ud800') succeeds in Windows but fails in POSIX, while os.fsdecode(b'\x80') fails in Windows but succeeds in POSIX. The latter case is not a practical problem since filesystem functions will never return an invalid WTF-8 byte string.

---
[1] https://docs.python.org/3/library/sys.html#sys._enablelegacywindowsfsencoding

----------
components: +Unicode, Windows
nosy: +eryksun, ezio.melotti, paul.moore, steve.dower, tim.golden, vstinner, zach.ware

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

From report at bugs.python.org  Thu Mar  4 09:32:29 2021
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 04 Mar 2021 14:32:29 +0000
Subject: [issue43364] Add shortcut to enable UTF-8 mode in start menu.
In-Reply-To: <1614675827.66.0.411790166938.issue43364@roundup.psfhosted.org>
Message-ID: <1614868349.96.0.380471880478.issue43364@roundup.psfhosted.org>


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

User may install Python from python.org installer, scoop, conda, and Windows Store.
So envvar is not a right tool to configure only one installation.

Anyway, adding more complex way to configure Python can be discussed later.

Paul Moore againsted adding more way to configure Python [1].
So let's focus on promoting existing way in Python 3.10.

[1] https://mail.python.org/archives/list/python-ideas at python.org/message/BDOV2F3LDSC2YDUR4LCPNHZFJWEZNX5U/

> Yes, if the installer directly sets an environment variable, then the setting should be specific to the installed version, such as PYTHONUTF8_310-32.

Then, suspend GH-24742 (adding checkbox to installer).

In GH-24743, I added the shortcut from the installer. But I am not sure it is the best way, because only Python installed from the installer have it.

I will check how conda installs Python on Windows. If it contains Tools, we may add `enable-utf8mode.bat` and `disable-utf8mode.bat` to the Tools.

----------

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

From report at bugs.python.org  Thu Mar  4 09:51:46 2021
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 04 Mar 2021 14:51:46 +0000
Subject: [issue43396] Non-existent method sqlite3.Connection.fetchone() used
 in docs
In-Reply-To: <1614840295.99.0.480319283179.issue43396@roundup.psfhosted.org>
Message-ID: <1614869506.81.0.580899847033.issue43396@roundup.psfhosted.org>


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

No problem and thank you for taking time to report!

I'd be happy to merge a PR that renames c to cur in the documentation (I counted four instances.) We can then reopen and retarget this isssue.

----------
resolution:  -> not a bug

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

From report at bugs.python.org  Thu Mar  4 09:56:14 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Thu, 04 Mar 2021 14:56:14 +0000
Subject: [issue43396] Non-existent method sqlite3.Connection.fetchone() used
 in docs
In-Reply-To: <1614840295.99.0.480319283179.issue43396@roundup.psfhosted.org>
Message-ID: <1614869774.48.0.314853630462.issue43396@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

'con' and 'cur' seems to be used in a majority of the examples. I suggest normalising to always using these two in code examples.

----------

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

From report at bugs.python.org  Thu Mar  4 10:00:24 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Thu, 04 Mar 2021 15:00:24 +0000
Subject: [issue43396] Non-existent method sqlite3.Connection.fetchone() used
 in docs
In-Reply-To: <1614840295.99.0.480319283179.issue43396@roundup.psfhosted.org>
Message-ID: <1614870024.24.0.343234130893.issue43396@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

Attached patch consists of two commits: one to rename "conn" to "con", and one to rename "c" to "cur". Are you ok with that, Berker?

----------
Added file: https://bugs.python.org/file49851/patch.diff

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

From report at bugs.python.org  Thu Mar  4 10:21:05 2021
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 04 Mar 2021 15:21:05 +0000
Subject: [issue20088] locale.getlocale() fails if locale name doesn't include
 encoding
In-Reply-To: <1388223842.98.0.521951916148.issue20088@psf.upfronthosting.co.za>
Message-ID: <1614871265.62.0.866773934487.issue20088@roundup.psfhosted.org>


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

The locale_alias database was extended to support "en_AG" and many others, but I'd still prefer Serhiy's suggestion to not guess the codeset when checking the default LC_CTYPE category. Use locale.nl_langinfo(locale.CODESET), if it's available. 

In Windows, I'd prefer to never guess since the encoding for a BCP-47 locale name can be directly queried. But this issue can be restricted to POSIX. What to do in Windows is already being considered in more recent issues: bpo-23425, bpo-37945, and bpo-43115.

----------
components:  -Windows
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Mar  4 10:24:58 2021
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 04 Mar 2021 15:24:58 +0000
Subject: [issue43396] Use more descriptive variable names in sqlite3 docs
In-Reply-To: <1614840295.99.0.480319283179.issue43396@roundup.psfhosted.org>
Message-ID: <1614871498.15.0.872001153856.issue43396@roundup.psfhosted.org>


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

LGTM!

----------
resolution: not a bug -> 
stage: resolved -> needs patch
status: closed -> open
title: Non-existent method sqlite3.Connection.fetchone() used in docs -> Use more descriptive variable names in sqlite3 docs
type:  -> enhancement
versions: +Python 3.10

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

From report at bugs.python.org  Thu Mar  4 10:28:39 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Thu, 04 Mar 2021 15:28:39 +0000
Subject: [issue43396] Use more descriptive variable names in sqlite3 docs
In-Reply-To: <1614840295.99.0.480319283179.issue43396@roundup.psfhosted.org>
Message-ID: <1614871718.99.0.689039340188.issue43396@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


----------
pull_requests: +23516
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/24746

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

From report at bugs.python.org  Thu Mar  4 10:46:21 2021
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 04 Mar 2021 15:46:21 +0000
Subject: [issue43396] Use more descriptive variable names in sqlite3 docs
In-Reply-To: <1614840295.99.0.480319283179.issue43396@roundup.psfhosted.org>
Message-ID: <1614872781.59.0.0687223730318.issue43396@roundup.psfhosted.org>


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


New changeset 40d1b831ecd1b5b6a4fce9a908a6e61b50b360a0 by Erlend Egeberg Aasland in branch 'master':
bpo-43396: Normalise naming in sqlite3 doc examples (GH-24746)
https://github.com/python/cpython/commit/40d1b831ecd1b5b6a4fce9a908a6e61b50b360a0


----------

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

From report at bugs.python.org  Thu Mar  4 10:47:16 2021
From: report at bugs.python.org (miss-islington)
Date: Thu, 04 Mar 2021 15:47:16 +0000
Subject: [issue43396] Use more descriptive variable names in sqlite3 docs
In-Reply-To: <1614840295.99.0.480319283179.issue43396@roundup.psfhosted.org>
Message-ID: <1614872836.39.0.720743122587.issue43396@roundup.psfhosted.org>


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


----------
pull_requests: +23518
pull_request: https://github.com/python/cpython/pull/24748

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

From report at bugs.python.org  Thu Mar  4 10:47:04 2021
From: report at bugs.python.org (miss-islington)
Date: Thu, 04 Mar 2021 15:47:04 +0000
Subject: [issue43396] Use more descriptive variable names in sqlite3 docs
In-Reply-To: <1614840295.99.0.480319283179.issue43396@roundup.psfhosted.org>
Message-ID: <1614872824.11.0.163763889801.issue43396@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: +23517
pull_request: https://github.com/python/cpython/pull/24747

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

From report at bugs.python.org  Thu Mar  4 10:49:16 2021
From: report at bugs.python.org (miss-islington)
Date: Thu, 04 Mar 2021 15:49:16 +0000
Subject: [issue37193] Memory leak while running TCP/UDPServer with
 socketserver.ThreadingMixIn
In-Reply-To: <1559908419.41.0.390422965351.issue37193@roundup.psfhosted.org>
Message-ID: <1614872956.77.0.362037843641.issue37193@roundup.psfhosted.org>


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


----------
pull_requests: +23519
pull_request: https://github.com/python/cpython/pull/24749

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

From report at bugs.python.org  Thu Mar  4 10:49:32 2021
From: report at bugs.python.org (miss-islington)
Date: Thu, 04 Mar 2021 15:49:32 +0000
Subject: [issue37193] Memory leak while running TCP/UDPServer with
 socketserver.ThreadingMixIn
In-Reply-To: <1559908419.41.0.390422965351.issue37193@roundup.psfhosted.org>
Message-ID: <1614872972.31.0.452031711054.issue37193@roundup.psfhosted.org>


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


----------
pull_requests: +23520
pull_request: https://github.com/python/cpython/pull/24750

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

From report at bugs.python.org  Thu Mar  4 10:59:11 2021
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 04 Mar 2021 15:59:11 +0000
Subject: [issue3905] subprocess failing in GUI applications on Windows
In-Reply-To: <1221779222.6.0.581055626962.issue3905@psf.upfronthosting.co.za>
Message-ID: <1614873551.58.0.0684654253438.issue3905@roundup.psfhosted.org>


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

For whatever the reason and Windows version, it's still the case that _get_handles() should work around any bad standard handles in the current process. In bpo-25492, I suggested checking os.get_handle_inheritable(). That's too permissive. It should require a valid file handle, checked via _winapi.GetFileType(). For example:

    if stdin is None:
        p2cread = _winapi.GetStdHandle(_winapi.STD_INPUT_HANDLE)
        if p2cread is not None:
            try:
                _winapi.GetFileType(p2cread)
            except OSError:
                p2cread = None

----------
components: +Library (Lib)
versions: +Python 3.10, Python 3.9 -Python 2.7, Python 3.7

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

From report at bugs.python.org  Thu Mar  4 10:59:21 2021
From: report at bugs.python.org (Alex)
Date: Thu, 04 Mar 2021 15:59:21 +0000
Subject: [issue43399] xml.etree.ElementTree.extend does not work with
 iterators when using the Python implementation
Message-ID: <1614873561.76.0.875762243403.issue43399@roundup.psfhosted.org>


New submission from Alex <alexprengere at gmail.com>:

This issue is only visible when the C accelerator of ElementTree is *not* used. It is the counterpart of the following issue on PyPy3: https://foss.heptapod.net/pypy/pypy/-/issues/3181

 >>> from xml.etree.ElementTree import Element
 >>> r = Element("root")
 >>> r.extend((Element(str(i)) for i in range(3)))
 >>> print(list(r))
 []

When using the C accelerator, the list is not empty, as expected. In the Python code, a check on the input empties the input iterator.

The fix is trivial (one-line change), so if you are interested I could open a PR, which would be my first, so a good occasion to go through the devguide ;)
I understand that since Python3.3 the C accelerator is used by default, so I would agree that this is not really a bug, and I can just fix it on PyPy side.

----------
components: XML
messages: 388099
nosy: alexprengere
priority: normal
severity: normal
status: open
title: xml.etree.ElementTree.extend does not work with iterators when using the Python implementation
type: behavior
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Mar  4 11:02:03 2021
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 04 Mar 2021 16:02:03 +0000
Subject: [issue29829] Documentation lacks clear warning of subprocess issue
 with pythonw
In-Reply-To: <1489683501.47.0.952186876903.issue29829@psf.upfronthosting.co.za>
Message-ID: <1614873723.91.0.584788394263.issue29829@roundup.psfhosted.org>


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

I forgot about the much older issue for this problem. I'm closing this issue, because the broken behavior should be fixed, not documented.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> subprocess failing in GUI applications on Windows

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

From report at bugs.python.org  Thu Mar  4 11:36:48 2021
From: report at bugs.python.org (Alex)
Date: Thu, 04 Mar 2021 16:36:48 +0000
Subject: [issue43399] xml.etree.ElementTree.extend does not work with
 iterators when using the Python implementation
In-Reply-To: <1614873561.76.0.875762243403.issue43399@roundup.psfhosted.org>
Message-ID: <1614875808.24.0.890369404306.issue43399@roundup.psfhosted.org>


Change by Alex <alexprengere at gmail.com>:


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

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

From report at bugs.python.org  Thu Mar  4 11:36:50 2021
From: report at bugs.python.org (miss-islington)
Date: Thu, 04 Mar 2021 16:36:50 +0000
Subject: [issue37193] Memory leak while running TCP/UDPServer with
 socketserver.ThreadingMixIn
In-Reply-To: <1559908419.41.0.390422965351.issue37193@roundup.psfhosted.org>
Message-ID: <1614875810.96.0.26432021643.issue37193@roundup.psfhosted.org>


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


New changeset 0e76157b0ca70bd38157fed56680a7752a52668d by Miss Islington (bot) in branch '3.9':
[3.9] bpo-37193: Remove thread objects which finished process its request (GH-23127) (GH-24750)
https://github.com/python/cpython/commit/0e76157b0ca70bd38157fed56680a7752a52668d


----------

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

From report at bugs.python.org  Thu Mar  4 11:43:32 2021
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 04 Mar 2021 16:43:32 +0000
Subject: [issue43399] xml.etree.ElementTree.extend does not work with
 iterators when using the Python implementation
In-Reply-To: <1614873561.76.0.875762243403.issue43399@roundup.psfhosted.org>
Message-ID: <1614876212.2.0.417287183037.issue43399@roundup.psfhosted.org>


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


----------
nosy: +eli.bendersky, scoder, serhiy.storchaka

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

From report at bugs.python.org  Thu Mar  4 11:43:58 2021
From: report at bugs.python.org (Eddie Peters)
Date: Thu, 04 Mar 2021 16:43:58 +0000
Subject: [issue43400] Remove "Mock is very easy to use" from unittest.mock
 documentation
Message-ID: <1614876238.1.0.922616136062.issue43400@roundup.psfhosted.org>


New submission from Eddie Peters <eddie at dinogalactic.com>:

The unittest.mock library is very useful and very powerful, but it is not "very easy to use." Docs are useful and important, or we wouldn't be here in a documentation issue.

I have watched several of the most experienced Python programmers I know struggle with various aspects of mock, including basic usage. I have sat with frustrated developers who have used mocking utilities in other languages but had little Python experience, and they were surprised by some mock behaviors and just couldn't get things "right" until they were helped by someone with all the tiny little healed-over cuts from lots of mock usage.

Again, mock is great, but maybe if I have these opinions, I should contribute to making mock more intuitive. That's true. For now, though, the documentation contains this little line in the opening paragraphs that is unnecessary and can only make new mock users feel bad about having trouble: "Mock is very easy to use and is designed for use with unittest."

I propose we remove the opinion "Mock is very easy to use" and change this line to "Mock is designed for use with unittest." The rest of the paragraph flows just fine without this:

"Mock is very easy to use and is designed for use with unittest. Mock is based on the ?action -> assertion? pattern instead of ?record -> replay? used by many mocking frameworks."

----------
assignee: docs at python
components: Documentation
messages: 388102
nosy: docs at python, eppeters
priority: normal
severity: normal
status: open
title: Remove "Mock is very easy to use" from unittest.mock documentation
type: enhancement
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Mar  4 11:47:49 2021
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 04 Mar 2021 16:47:49 +0000
Subject: [issue19809] Doc: subprocess should warn uses on race conditions when
 multiple threads spawn child processes
In-Reply-To: <1385544646.44.0.340337636792.issue19809@psf.upfronthosting.co.za>
Message-ID: <1614876469.13.0.473663919868.issue19809@roundup.psfhosted.org>


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

I'm closing this issue because the behavior was addressed for Python 3 in POSIX and mostly addressed in Windows (PEP 443, bpo-19764). The switch to using PROC_THREAD_ATTRIBUTE_HANDLE_LIST with subprocess.Popen() in Windows at least makes scripts safe from race conditions as long as only the subprocess module is used. 

Eventually it would be better to use subprocess.Popen() to implement os.system() and, in Windows, os.spawnv[e] -- as was already implemented for os.popen(). In that case it may even be reasonable to use the handle list to implement pass_fds in Windows.

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

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

From report at bugs.python.org  Thu Mar  4 11:51:53 2021
From: report at bugs.python.org (Eddie Peters)
Date: Thu, 04 Mar 2021 16:51:53 +0000
Subject: [issue43400] Remove "Mock is very easy to use" from unittest.mock
 documentation
In-Reply-To: <1614876238.1.0.922616136062.issue43400@roundup.psfhosted.org>
Message-ID: <1614876713.58.0.24567387134.issue43400@roundup.psfhosted.org>


Change by Eddie Peters <eddie at dinogalactic.com>:


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

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

From report at bugs.python.org  Thu Mar  4 11:55:43 2021
From: report at bugs.python.org (miss-islington)
Date: Thu, 04 Mar 2021 16:55:43 +0000
Subject: [issue37193] Memory leak while running TCP/UDPServer with
 socketserver.ThreadingMixIn
In-Reply-To: <1559908419.41.0.390422965351.issue37193@roundup.psfhosted.org>
Message-ID: <1614876943.88.0.134321489099.issue37193@roundup.psfhosted.org>


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


New changeset 0064d561b8e44f7a991188d7c5016c165bc89326 by Miss Islington (bot) in branch '3.8':
[3.8] bpo-37193: Remove thread objects which finished process its request (GH-23127) (GH-24749)
https://github.com/python/cpython/commit/0064d561b8e44f7a991188d7c5016c165bc89326


----------

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

From report at bugs.python.org  Thu Mar  4 11:59:16 2021
From: report at bugs.python.org (miss-islington)
Date: Thu, 04 Mar 2021 16:59:16 +0000
Subject: [issue42405] Add distutils mvsccompiler support for Windows ARM64
 build
In-Reply-To: <1605787478.54.0.45093731424.issue42405@roundup.psfhosted.org>
Message-ID: <1614877156.57.0.585091099476.issue42405@roundup.psfhosted.org>


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


New changeset cb7bc7640935f6b05e9d2acfe4b33d496e8f8666 by Adrian Vladu in branch 'master':
bpo-42405: fix C extensions build on Windows ARM64 (GH-23399)
https://github.com/python/cpython/commit/cb7bc7640935f6b05e9d2acfe4b33d496e8f8666


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

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

From report at bugs.python.org  Thu Mar  4 12:11:49 2021
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 04 Mar 2021 17:11:49 +0000
Subject: [issue43396] Use more descriptive variable names in sqlite3 docs
In-Reply-To: <1614840295.99.0.480319283179.issue43396@roundup.psfhosted.org>
Message-ID: <1614877909.44.0.675171653908.issue43396@roundup.psfhosted.org>


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


New changeset 374ee449331bc95d18c37f5032aaea1448462e58 by Miss Islington (bot) in branch '3.9':
bpo-43396: Normalise naming in sqlite3 doc examples (GH-24746)
https://github.com/python/cpython/commit/374ee449331bc95d18c37f5032aaea1448462e58


----------

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

From report at bugs.python.org  Thu Mar  4 12:12:14 2021
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 04 Mar 2021 17:12:14 +0000
Subject: [issue43396] Use more descriptive variable names in sqlite3 docs
In-Reply-To: <1614840295.99.0.480319283179.issue43396@roundup.psfhosted.org>
Message-ID: <1614877934.65.0.973601793284.issue43396@roundup.psfhosted.org>


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


New changeset 213c155a460b8dd9e43901e4d61aa088cbac4221 by Miss Islington (bot) in branch '3.8':
bpo-43396: Normalise naming in sqlite3 doc examples (GH-24746)
https://github.com/python/cpython/commit/213c155a460b8dd9e43901e4d61aa088cbac4221


----------

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

From report at bugs.python.org  Thu Mar  4 12:13:49 2021
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 04 Mar 2021 17:13:49 +0000
Subject: [issue43396] Use more descriptive variable names in sqlite3 docs
In-Reply-To: <1614840295.99.0.480319283179.issue43396@roundup.psfhosted.org>
Message-ID: <1614878029.99.0.376134110147.issue43396@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Thu Mar  4 12:16:38 2021
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 04 Mar 2021 17:16:38 +0000
Subject: [issue4928] tempfile.NamedTemporaryFile: automatic cleanup by OS
In-Reply-To: <1231838566.25.0.143957228078.issue4928@psf.upfronthosting.co.za>
Message-ID: <1614878198.91.0.572098203269.issue4928@roundup.psfhosted.org>


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


----------
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Mar  4 12:17:41 2021
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 04 Mar 2021 17:17:41 +0000
Subject: [issue43400] Remove "Mock is very easy to use" from unittest.mock
 documentation
In-Reply-To: <1614876238.1.0.922616136062.issue43400@roundup.psfhosted.org>
Message-ID: <1614878261.43.0.514272494819.issue43400@roundup.psfhosted.org>


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

I don't have any opinion on removing the part of the sentence. It will be helpful if you can list the scenarios where you feel document is lacking so that it can be improved. One area I have found to be little tricky is patching the correct object during testing which has a section and needs some understanding of Python's import mechanism. The other was about setting return value properly for nested attributes.

Mock has a lot of features and has a wide range of API so listing places where you feel some of the things are not clear will help in improving them.

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

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

From report at bugs.python.org  Thu Mar  4 12:19:31 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 04 Mar 2021 17:19:31 +0000
Subject: [issue43400] Remove "Mock is very easy to use" from unittest.mock
 documentation
In-Reply-To: <1614876238.1.0.922616136062.issue43400@roundup.psfhosted.org>
Message-ID: <1614878371.99.0.304800550696.issue43400@roundup.psfhosted.org>


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

+1 for the OP's suggestion.

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

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

From report at bugs.python.org  Thu Mar  4 12:31:44 2021
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 04 Mar 2021 17:31:44 +0000
Subject: [issue22107] tempfile module misinterprets access denied error on
 Windows
In-Reply-To: <1406724041.52.0.0365391579019.issue22107@psf.upfronthosting.co.za>
Message-ID: <1614879104.98.0.057101249331.issue22107@roundup.psfhosted.org>


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


----------
versions: +Python 3.10, Python 3.9 -Python 2.7, Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Thu Mar  4 12:53:03 2021
From: report at bugs.python.org (Doug Harris)
Date: Thu, 04 Mar 2021 17:53:03 +0000
Subject: [issue43400] Remove "Mock is very easy to use" from unittest.mock
 documentation
In-Reply-To: <1614876238.1.0.922616136062.issue43400@roundup.psfhosted.org>
Message-ID: <1614880383.54.0.250745559049.issue43400@roundup.psfhosted.org>


Doug Harris <dharris at gmail.com> added the comment:

+1 on this documentation change.

@xtreak yes, patching the correct object has bit me a couple times.

The pattern that I work with the most is when mocking calls to external services and APIs. I want to test my code that, say, sends email or sends user information to a partner, but without actual HTTP calls. Whenever I add a new test that does this, I need to rethink exactly what the sequence of mocked objects, calls, and returns will be.

The HOWTO section of the official Python docs has nothing on unittest or mock. Perhaps something there... (makes note to think about drafting something).

----------
nosy: +dougharris

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

From report at bugs.python.org  Thu Mar  4 12:55:37 2021
From: report at bugs.python.org (Steve Dower)
Date: Thu, 04 Mar 2021 17:55:37 +0000
Subject: [issue43364] Add shortcut to enable UTF-8 mode in start menu.
In-Reply-To: <1614675827.66.0.411790166938.issue43364@roundup.psfhosted.org>
Message-ID: <1614880537.51.0.817137211665.issue43364@roundup.psfhosted.org>


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

Maybe as a global setting, the better thing to copy is the button at the end of installation that offers to change the long path policy?

That would give a bit more room that a checkbox to explain what is being set and what the implications are, which will help users who select it when they shouldn't.

IIRC, all of that code exists in the boostrapper app (one of the .cpp files). The UI is probably in the bundle wxl/thm files.

----------

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

From report at bugs.python.org  Thu Mar  4 13:00:04 2021
From: report at bugs.python.org (Steve Dower)
Date: Thu, 04 Mar 2021 18:00:04 +0000
Subject: [issue42405] Add distutils mvsccompiler support for Windows ARM64
 build
In-Reply-To: <1605787478.54.0.45093731424.issue42405@roundup.psfhosted.org>
Message-ID: <1614880804.72.0.505838833331.issue42405@roundup.psfhosted.org>


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

Jason, this issue and the associated PR are out of date and should not be merged.

The PR also only affects completely unused code, so it has no value whatsoever being in CPython. I don't really care too much about the unused code, but I will *insist* on the NEWS entry being reverted, to avoid causing confusion.

(As an aside, I'd love setuptools to gain this functionality, and I'm trying to get access to hardware for you so you can validate it in CI.)

----------

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

From report at bugs.python.org  Thu Mar  4 13:03:22 2021
From: report at bugs.python.org (Numerlor)
Date: Thu, 04 Mar 2021 18:03:22 +0000
Subject: [issue43401] dbm module doc page redirects to itself
Message-ID: <1614881002.06.0.413665275054.issue43401@roundup.psfhosted.org>


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

In [32]: requests.get("https://docs.python.org/3/library/dbm.html", allow_redirects=False)
Out[32]: <Response [301]>

In [33]: _.headers["Location"]
Out[33]: 'https://docs.python.org/3/library/dbm.html#module-dbm.ndbm'

----------
assignee: docs at python
components: Documentation
messages: 388113
nosy: Numerlor, docs at python
priority: normal
severity: normal
status: open
title: dbm module doc page redirects to itself

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

From report at bugs.python.org  Thu Mar  4 13:04:16 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 04 Mar 2021 18:04:16 +0000
Subject: [issue42405] Add distutils mvsccompiler support for Windows ARM64
 build
In-Reply-To: <1605787478.54.0.45093731424.issue42405@roundup.psfhosted.org>
Message-ID: <1614881056.3.0.483749083758.issue42405@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Hey Steve. Thanks for the clarification. I'd forgotten the context, specifically that any patches needed to be merged before the PEP was accepted, and was working from a memory that we were willing to accept this change. Happy to revert it, as that also saves me the time of making sure the change is backported to pypa/distutils. Adrian, please submit the change to pypa/distutils.

----------

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

From report at bugs.python.org  Thu Mar  4 13:06:21 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 04 Mar 2021 18:06:21 +0000
Subject: [issue42405] Add distutils mvsccompiler support for Windows ARM64
 build
In-Reply-To: <1605787478.54.0.45093731424.issue42405@roundup.psfhosted.org>
Message-ID: <1614881181.2.0.251271248313.issue42405@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
pull_requests: +23524
pull_request: https://github.com/python/cpython/pull/24753

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

From report at bugs.python.org  Thu Mar  4 13:14:22 2021
From: report at bugs.python.org (Hugo Nobrega)
Date: Thu, 04 Mar 2021 18:14:22 +0000
Subject: [issue43402] IDLE shell adds newline after print even when `end=''`
 is specificied
Message-ID: <1614881662.35.0.881061659082.issue43402@roundup.psfhosted.org>


New submission from Hugo Nobrega <hugonobrega at dcc.ufrj.br>:

When evaluting a call to the `print` function with argument `end=''` in the IDLE shell, a newline is unexpectedly added at the end, before the next shell prompt.

The expected behavior is to have the shell prompt next to the last printed line. The expected behavior is seen when evaluting the same expression in an interactive python shell from a terminal (`python -i`)

Example:

IDLE shell (not expected):
>>> print('a',end='')
a
>>> 

Interactive python shell (expected): 
>>> print('a',end='')
a>>>

I could not find any settings in IDLE that might be governing this behavior, not any other issues mentioning this same thing.


Tested on Python 3.9.1 on Manjaro Linux.

----------
assignee: terry.reedy
components: IDLE
messages: 388115
nosy: hugonobrega, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE shell adds newline after print even when `end=''` is specificied
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Thu Mar  4 13:14:22 2021
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 04 Mar 2021 18:14:22 +0000
Subject: [issue23946] zero-valued timestamps are mishandled by os.stat() in
 Windows
In-Reply-To: <1429012619.96.0.846306201826.issue23946@psf.upfronthosting.co.za>
Message-ID: <1614881662.51.0.298872198606.issue23946@roundup.psfhosted.org>


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

For example, the named-pipe filesystem (NPFS), doesn't return timestamps for pipes in the directory listing, so the timestamps are all 0 (i.e. 1601-01-01):

    >>> write_time = win32file.FindFilesW('//./pipe/*')[0][3]
    >>> format(write_time, '%Y-%m-%d %H:%M')
    '1601-01-01 00:00'

    >>> next(os.scandir('//./pipe')).stat().st_mtime
    -11644473600.0

I agree that a zero-valued NT timestamp should be converted to a zero-valued Unix timestamp. No one has a file that was created, modified, changed, or accessed in 1601.

As mentioned above, the 1601 date doesn't roundtrip in Windows as a Unix timestamp since dates before the Unix epoch aren't supported:

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

----------
components: +Library (Lib) -Interpreter Core
nosy: +paul.moore
title: Invalid timestamps reported by os.stat() when Windows FILETIME structures are mistakenly reset. -> zero-valued timestamps are mishandled by os.stat() in Windows
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.7

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

From report at bugs.python.org  Thu Mar  4 13:23:52 2021
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 04 Mar 2021 18:23:52 +0000
Subject: [issue39375] Document os.environ[x] = y and os.putenv() as thread
 unsafe
In-Reply-To: <1579307768.04.0.648412303004.issue39375@roundup.psfhosted.org>
Message-ID: <1614882232.58.0.0029851384193.issue39375@roundup.psfhosted.org>


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


----------
type:  -> enhancement
versions: +Python 3.10 -Python 2.7, Python 3.7

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

From report at bugs.python.org  Thu Mar  4 13:25:02 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 04 Mar 2021 18:25:02 +0000
Subject: [issue43391] The comments have invalid license information (broken
 Python 2.4 URL for Python 3)
In-Reply-To: <1614801590.99.0.0824232667755.issue43391@roundup.psfhosted.org>
Message-ID: <1614882302.5.0.307517100909.issue43391@roundup.psfhosted.org>


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


New changeset b225d91f0a92d657d9a1b62daa53ab239c8191e3 by Kamil Turek in branch 'master':
bpo-43391: Remove the broken Python 2.4 link from the comment (GH-24736)
https://github.com/python/cpython/commit/b225d91f0a92d657d9a1b62daa53ab239c8191e3


----------
nosy: +gregory.p.smith

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

From report at bugs.python.org  Thu Mar  4 13:32:45 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 04 Mar 2021 18:32:45 +0000
Subject: [issue43399] xml.etree.ElementTree.extend does not work with
 iterators when using the Python implementation
In-Reply-To: <1614873561.76.0.875762243403.issue43399@roundup.psfhosted.org>
Message-ID: <1614882765.81.0.50384883781.issue43399@roundup.psfhosted.org>


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

Your proposed fix LGTM. Please open a PR. Don't forget about test and NEWS entry.

----------

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

From report at bugs.python.org  Thu Mar  4 13:39:15 2021
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 04 Mar 2021 18:39:15 +0000
Subject: [issue43399] xml.etree.ElementTree.extend does not work with
 iterators when using the Python implementation
In-Reply-To: <1614873561.76.0.875762243403.issue43399@roundup.psfhosted.org>
Message-ID: <1614883155.31.0.363832817846.issue43399@roundup.psfhosted.org>


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

Thanks for the report and the PR. I would argue that this can still be fixed in Py3.8, given the low impact (but not earlier). The behaviour is clearly wrong (in a subtle way) and most users won't notice it because they won't switch off the C accelerator module.

----------
versions:  -Python 3.6, Python 3.7

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

From report at bugs.python.org  Thu Mar  4 13:41:58 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 04 Mar 2021 18:41:58 +0000
Subject: [issue42405] Add distutils mvsccompiler support for Windows ARM64
 build
In-Reply-To: <1605787478.54.0.45093731424.issue42405@roundup.psfhosted.org>
Message-ID: <1614883318.01.0.745432048401.issue42405@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:


New changeset fbf75b9997e280b1220755d0a17dbed71240d42e by Jason R. Coombs in branch 'master':
Revert "bpo-42405: fix C extensions build on Windows ARM64 (GH-23399)" (#24753)
https://github.com/python/cpython/commit/fbf75b9997e280b1220755d0a17dbed71240d42e


----------

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

From report at bugs.python.org  Thu Mar  4 13:43:09 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 04 Mar 2021 18:43:09 +0000
Subject: [issue42129] Support resources in namespace packages
In-Reply-To: <1603469006.87.0.128715336786.issue42129@roundup.psfhosted.org>
Message-ID: <1614883389.94.0.855066215648.issue42129@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:


New changeset 67148254146948041a77d8a2989f41b88cdb2f99 by Jason R. Coombs in branch 'master':
bpo-42129: Add support for resources in namespaces (GH-24670)
https://github.com/python/cpython/commit/67148254146948041a77d8a2989f41b88cdb2f99


----------

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

From report at bugs.python.org  Thu Mar  4 13:43:43 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 04 Mar 2021 18:43:43 +0000
Subject: [issue42129] Support resources in namespace packages
In-Reply-To: <1603469006.87.0.128715336786.issue42129@roundup.psfhosted.org>
Message-ID: <1614883423.33.0.320536711261.issue42129@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


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

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

From report at bugs.python.org  Thu Mar  4 13:43:56 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 04 Mar 2021 18:43:56 +0000
Subject: [issue43403] Misleading statement about bytes not being able to
 represent windows filenames in documentation
Message-ID: <1614883436.88.0.196877066023.issue43403@roundup.psfhosted.org>


New submission from Gregory P. Smith <greg at krypto.org>:

As noted in the comment on https://github.com/rdiff-backup/rdiff-backup/issues/540#issuecomment-789485896

The Python documentation in https://docs.python.org/3/library/os.path.html makes an odd claim that bytes cannot represent all file names on Windows.  That doesn't make sense.  bytes can by definition represent everything.

"""Vice versa, using bytes objects cannot represent all file names on Windows (in the standard mbcs encoding), hence Windows applications should use string objects to access all files."""

Could we get this clarified and corrected to cover what any actual technical limitation is?

Every OS is going to reject some bytes objects as a pathname for containing invalid byte sequences for their filesystem (ex: I doubt any OS allows null b'\0' characters).  But lets not claim that bytes cannot represent everything on a filesystem with an encoding.

----------
assignee: docs at python
components: Documentation
messages: 388122
nosy: docs at python, gregory.p.smith, steve.dower
priority: normal
severity: normal
stage: needs patch
status: open
title: Misleading statement about bytes not being able to represent windows filenames in documentation
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Mar  4 13:44:56 2021
From: report at bugs.python.org (Ammar Askar)
Date: Thu, 04 Mar 2021 18:44:56 +0000
Subject: [issue43403] Misleading statement about bytes not being able to
 represent windows filenames in documentation
In-Reply-To: <1614883436.88.0.196877066023.issue43403@roundup.psfhosted.org>
Message-ID: <1614883496.84.0.60146279838.issue43403@roundup.psfhosted.org>


Change by Ammar Askar <ammar at ammaraskar.com>:


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

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

From report at bugs.python.org  Thu Mar  4 13:53:25 2021
From: report at bugs.python.org (Sam Bull)
Date: Thu, 04 Mar 2021 18:53:25 +0000
Subject: [issue43404] No SSL certificates when using the Mac installer
Message-ID: <1614884005.35.0.786100424357.issue43404@roundup.psfhosted.org>


New submission from Sam Bull <m6f6g7 at sambull.org>:

After installing the latest version of Python on Mac OS X using the installer downloaded from python.org (https://www.python.org/ftp/python/3.9.2/python-3.9.2-macosx10.9.pkg), the installed version of Python is unable to find the system certificates.

Using the old version of Python located at /usr/local/Cellar/python/3.7.5/bin/python3, I get:

>>> ssl.create_default_context().cert_store_stats()
{'x509': 168, 'crl': 0, 'x509_ca': 168}

But, with the new version located at /Library/Frameworks/Python.framework/Versions/3.9/bin/python3, I get:

>>> ssl.create_default_context().cert_store_stats()
{'x509': 0, 'crl': 0, 'x509_ca': 0}


Looking around on the internet, this seems to be a pretty common issue on Mac, but is often getting misdiagnosed as an actual problem with the server's certificate. Because of that, nobody seems to have proposed any methods to fix it.

Examples:
https://github.com/aio-libs/aiohttp/issues/5375
https://stackoverflow.com/questions/65039677/unable-to-get-local-issuer-certificate-mac-os#comment115039330_65040851

----------
assignee: christian.heimes
components: SSL
messages: 388123
nosy: christian.heimes, dreamsorcerer
priority: normal
severity: normal
status: open
title: No SSL certificates when using the Mac installer
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Thu Mar  4 13:56:07 2021
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 04 Mar 2021 18:56:07 +0000
Subject: [issue36021] [Security][Windows] webbrowser: WindowsDefault uses
 os.startfile() and so can be abused to run arbitrary commands
In-Reply-To: <1550487653.15.0.496398912417.issue36021@roundup.psfhosted.org>
Message-ID: <1614884167.58.0.148096490632.issue36021@roundup.psfhosted.org>


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


----------
versions: +Python 3.10, Python 3.9 -Python 2.7, Python 3.7

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

From report at bugs.python.org  Thu Mar  4 14:07:25 2021
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 04 Mar 2021 19:07:25 +0000
Subject: [issue43403] Misleading statement about bytes not being able to
 represent windows filenames in documentation
In-Reply-To: <1614883436.88.0.196877066023.issue43403@roundup.psfhosted.org>
Message-ID: <1614884845.94.0.0555025480818.issue43403@roundup.psfhosted.org>


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


----------
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> os.path states that bytes can't represent all MBCS paths under Windows

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

From report at bugs.python.org  Thu Mar  4 14:26:58 2021
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 04 Mar 2021 19:26:58 +0000
Subject: [issue43403] Misleading statement about bytes not being able to
 represent windows filenames in documentation
In-Reply-To: <1614883436.88.0.196877066023.issue43403@roundup.psfhosted.org>
Message-ID: <1614886018.33.0.991838036762.issue43403@roundup.psfhosted.org>


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

> lets not claim that bytes cannot represent everything on a filesystem 
> with an encoding.

Gregory, before changing the filesystem encoding to UTF-8 in Python 3.6, the [A]NSI file API (e.g. CreateFileA) was used for bytes paths and the [W]ide character file API was used for str paths (e.g. CreateFileW). The ANSI API is a set of wrapper functions that automatically translate strings between the ANSI code page of the current process and the system's native UTF-16 encoding, before and after calling the wide-character function (or a common internal function). Starting with Windows 10, the ANSI and OEM code pages of a process are finally allowed to be UTF-8 (code page 65001), but it's still considered beta and barely used. Usually the ANSI API is set to a legacy single-byte or double-byte code page such as 1252 (Western Europe) or 932 (Japanese). 

Natively, Windows is UTF-16, and native Windows filesystems store filenames on disk using 16-bit characters. The system doesn't check for valid Unicode, so lone surrogate codes are allowed. This is sometimes called a "Wobbly" format. In Python it requires the "surrogatepass" error handler.

----------

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

From report at bugs.python.org  Thu Mar  4 14:46:39 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 04 Mar 2021 19:46:39 +0000
Subject: [issue43375] memory leak in threading ?
In-Reply-To: <1614708658.89.0.572605723578.issue43375@roundup.psfhosted.org>
Message-ID: <1614887199.11.0.433634323942.issue43375@roundup.psfhosted.org>


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

> Since Timer thread is never joined, should not it be a daemon?

Possibly, but I think that's a new question/issue. :-) And presumably there's no reason you can't make your Timer threads into daemon threads if you have a need to.

----------

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

From report at bugs.python.org  Thu Mar  4 14:49:59 2021
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 04 Mar 2021 19:49:59 +0000
Subject: [issue30431] input function truncates prompt by NULL byte
In-Reply-To: <1495465744.13.0.0864396942618.issue30431@psf.upfronthosting.co.za>
Message-ID: <1614887399.07.0.513879318418.issue30431@roundup.psfhosted.org>


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


----------
components: +Interpreter Core -IO
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.7, Python 3.6, Python 3.7

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

From report at bugs.python.org  Thu Mar  4 15:00:53 2021
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 04 Mar 2021 20:00:53 +0000
Subject: [issue29561] Interactive mode gives sys.ps2 not sys.ps1 after
 comment-only line
In-Reply-To: <1487104479.95.0.807901019481.issue29561@psf.upfronthosting.co.za>
Message-ID: <1614888053.25.0.723620410742.issue29561@roundup.psfhosted.org>


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

The is fixed in 3.7+.

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

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

From report at bugs.python.org  Thu Mar  4 15:04:09 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 04 Mar 2021 20:04:09 +0000
Subject: [issue43402] IDLE shell adds newline after print even when `end=''`
 is specificied
In-Reply-To: <1614881662.35.0.881061659082.issue43402@roundup.psfhosted.org>
Message-ID: <1614888249.41.0.858608282528.issue43402@roundup.psfhosted.org>


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

Starting interactive code input on a new line is intentional and not a bug.  IDLE has other code to keep user program output separate from user code input, as when there is delayed asynchonous output. I plan to do more work to keep the two separate.

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

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

From report at bugs.python.org  Thu Mar  4 15:17:39 2021
From: report at bugs.python.org (Hugo Nobrega)
Date: Thu, 04 Mar 2021 20:17:39 +0000
Subject: [issue43402] IDLE shell adds newline after print even when `end=''`
 is specificied
In-Reply-To: <1614881662.35.0.881061659082.issue43402@roundup.psfhosted.org>
Message-ID: <1614889059.89.0.220346475405.issue43402@roundup.psfhosted.org>


Hugo Nobrega <hugonobrega at dcc.ufrj.br> added the comment:

I see, thank you. But, in that case, shouldn't the interactive `python -i` shell have the same (now seen as desired) behavior as the IDLE shell?

----------

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

From report at bugs.python.org  Thu Mar  4 15:29:15 2021
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 04 Mar 2021 20:29:15 +0000
Subject: [issue43405] DeprecationWarnings in test_unicode
Message-ID: <1614889755.46.0.756872715083.issue43405@roundup.psfhosted.org>


New submission from Zackery Spytz <zspytz at gmail.com>:

./python -m test test_unicode
0:00:00 load avg: 0.33 Run tests sequentially
0:00:00 load avg: 0.33 [1/1] test_unicode
/home/lubuntu2/cpython/Lib/test/test_unicode.py:2941: DeprecationWarning: getargs: The 'u' format is deprecated. Use 'U' instead.
  self.assertEqual(unicode_encodedecimal('123'),
/home/lubuntu2/cpython/Lib/test/test_unicode.py:2943: DeprecationWarning: getargs: The 'u' format is deprecated. Use 'U' instead.
  self.assertEqual(unicode_encodedecimal('\u0663.\u0661\u0664'),
/home/lubuntu2/cpython/Lib/test/test_unicode.py:2945: DeprecationWarning: getargs: The 'u' format is deprecated. Use 'U' instead.
  self.assertEqual(unicode_encodedecimal("\N{EM SPACE}3.14\N{EN SPACE}"),
/home/lubuntu2/cpython/Lib/unittest/case.py:201: DeprecationWarning: getargs: The 'u' format is deprecated. Use 'U' instead.
  callable_obj(*args, **kwargs)
/home/lubuntu2/cpython/Lib/test/test_unicode.py:2958: DeprecationWarning: getargs: The 'u' format is deprecated. Use 'U' instead.
  self.assertEqual(transform_decimal('123'),
/home/lubuntu2/cpython/Lib/test/test_unicode.py:2960: DeprecationWarning: getargs: The 'u' format is deprecated. Use 'U' instead.
  self.assertEqual(transform_decimal('\u0663.\u0661\u0664'),
/home/lubuntu2/cpython/Lib/test/test_unicode.py:2962: DeprecationWarning: getargs: The 'u' format is deprecated. Use 'U' instead.
  self.assertEqual(transform_decimal("\N{EM SPACE}3.14\N{EN SPACE}"),
/home/lubuntu2/cpython/Lib/test/test_unicode.py:2964: DeprecationWarning: getargs: The 'u' format is deprecated. Use 'U' instead.
  self.assertEqual(transform_decimal('123\u20ac'),

== Tests result: SUCCESS ==

1 test OK.

Total duration: 12.8 sec
Tests result: SUCCESS

----------
components: Tests
messages: 388129
nosy: ZackerySpytz
priority: normal
severity: normal
status: open
title: DeprecationWarnings in test_unicode
versions: Python 3.10

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

From report at bugs.python.org  Thu Mar  4 15:31:33 2021
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 04 Mar 2021 20:31:33 +0000
Subject: [issue43405] DeprecationWarnings in test_unicode
In-Reply-To: <1614889755.46.0.756872715083.issue43405@roundup.psfhosted.org>
Message-ID: <1614889893.65.0.423725285869.issue43405@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Thu Mar  4 15:51:58 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Mar 2021 20:51:58 +0000
Subject: [issue43356] PyErr_SetInterrupt should have an equivalent that takes
 a signal number
In-Reply-To: <1614621328.26.0.486134499262.issue43356@roundup.psfhosted.org>
Message-ID: <1614891118.64.0.486175822826.issue43356@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Thu Mar  4 16:15:30 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 04 Mar 2021 21:15:30 +0000
Subject: [issue43402] IDLE shell adds newline after print even when `end=''`
 is specificied
In-Reply-To: <1614881662.35.0.881061659082.issue43402@roundup.psfhosted.org>
Message-ID: <1614892530.27.0.869612582146.issue43402@roundup.psfhosted.org>


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

I don't know how many core devs would agree that inserting '\n' would be preferable.  They might say that users who want clean interaction should not use the 'end' parameter the way you did in interactive mode.

IDLE is more aimed at beginners and can be more protective and/or opinionated.  In any case, I agree with whoever wrote or edited this part of IDLE before me as to what IDLE should do.

There are also technical  issues.  Interactive python uses the common features of the various OS text and line-oriented terminal/consoles.  These do not know and do not care that they are displaying python input and output.  They display chars received from the executing program and have no way of knowing that the last n chars match python's sys.ps1 or sys.ps2.  The prompts comes from python executing "input(prompt)" after user code finishes.  To conditionally insert a newline, python would have to keep track of whether or not the last char sent by user code was a newline or not.

IDLE, on the other hand, is customized to run python code.  It *emulates* interactive mode with exec() calls.  IDLE, not python, displays prompts however programmed to do so.  It is trivial to check whether the last char inserted in the text widget is '\n' or not.

Side note: you only need '-i' for interactive mode when you also run a file because 'python -i' by itself is the same as 'python'.

'python -i somefile' is different from 'python somefile' because in the latter case, python exits after executing somefile, whereas in the former case, python executes 'input(sys.ps1)' and possibly 'input(sys.ps2)' until told to quit.  'Run module' in an IDLE editor emulates 'python -i <filename>'.

----------

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

From report at bugs.python.org  Thu Mar  4 16:31:08 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Mar 2021 21:31:08 +0000
Subject: [issue43406] Possible race condition between signal catching and
 signal.signal
Message-ID: <1614893468.93.0.265748275948.issue43406@roundup.psfhosted.org>


New submission from Antoine Pitrou <pitrou at free.fr>:

We can receive signals (at the C level, in trip_signal() in signalmodule.c) while signal.signal is being called to modify the corresponding handler.  Later when PyErr_CheckSignals() is called to handle the given signal, the handler may be a non-callable object and will raise a cryptic asynchronous exception.

----------
components: Interpreter Core, Library (Lib)
messages: 388131
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Possible race condition between signal catching and signal.signal
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Mar  4 16:32:14 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Mar 2021 21:32:14 +0000
Subject: [issue43406] Possible race condition between signal catching and
 signal.signal
In-Reply-To: <1614893468.93.0.265748275948.issue43406@roundup.psfhosted.org>
Message-ID: <1614893534.34.0.740829782322.issue43406@roundup.psfhosted.org>


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

Here is a reproducer:
https://gist.github.com/pitrou/e5a566e644730516b51de71145c5ea06

If you execute it, it will fail after a few iterations:

sig 2
sig 2
sig 2
Traceback (most recent call last):
  File "/home/antoine/cpython/default/setinterrupt.py", line 30, in <module>
    main()
  File "/home/antoine/cpython/default/setinterrupt.py", line 27, in main
    cycle_handlers(signum)
  File "/home/antoine/cpython/default/setinterrupt.py", line 19, in cycle_handlers
    signal.signal(signum, handler)
  File "/home/antoine/cpython/default/Lib/signal.py", line 48, in signal
    return _int_to_enum(handler, Handlers)
  File "/home/antoine/cpython/default/Lib/signal.py", line 30, in _int_to_enum
    return enum_klass(value)
  File "/home/antoine/cpython/default/Lib/enum.py", line 606, in __call__
    return cls.__new__(cls, value)
  File "/home/antoine/cpython/default/Lib/enum.py", line 927, in __new__
    ve_exc = ValueError("%r is not a valid %s" % (value, cls.__qualname__))
TypeError: 'int' object is not callable

----------

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

From report at bugs.python.org  Thu Mar  4 16:56:19 2021
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 04 Mar 2021 21:56:19 +0000
Subject: [issue28712] Non-Windows mappings for a couple of Windows code pages
In-Reply-To: <1479274828.26.0.726447169651.issue28712@psf.upfronthosting.co.za>
Message-ID: <1614894979.27.0.14379098271.issue28712@roundup.psfhosted.org>


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


----------
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.7, Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Thu Mar  4 16:57:31 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Mar 2021 21:57:31 +0000
Subject: [issue43406] Possible race condition between signal catching and
 signal.signal
In-Reply-To: <1614893468.93.0.265748275948.issue43406@roundup.psfhosted.org>
Message-ID: <1614895051.75.0.979763970532.issue43406@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Thu Mar  4 17:00:42 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Mar 2021 22:00:42 +0000
Subject: [issue43406] Possible race condition between signal catching and
 signal.signal
In-Reply-To: <1614893468.93.0.265748275948.issue43406@roundup.psfhosted.org>
Message-ID: <1614895242.59.0.900801074707.issue43406@roundup.psfhosted.org>


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


----------
nosy: +neologix

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

From report at bugs.python.org  Thu Mar  4 17:21:10 2021
From: report at bugs.python.org (Alex Willmer)
Date: Thu, 04 Mar 2021 22:21:10 +0000
Subject: [issue43407] time.monotonic(): Docs imply comparing call N and call
 N+M is invalid for M>1
Message-ID: <1614896470.36.0.766208602401.issue43407@roundup.psfhosted.org>


New submission from Alex Willmer <alex at moreati.org.uk>:

I believe the documentation for time.monotonic() and time.perf_counter() could be misleading. Taken literally they could imply that given

delta = 0.1
a = time.monotonic()
b = time.monotonic()
c = time.monotonic()

the comparisons `b - a < delta`, and `c - b < delta` are valid; but `c - a < delta` is not valid.

I believe that `c - a < delta` is a valid comparison, and that what the documentation means to say is "only the difference between the results of *subsequent* calls is valid."

The exact wording (present since the functions were added in https://hg.python.org/cpython/rev/376ce937823c)

> The reference point of the returned value is undefined, so that only
> the difference between the results of consecutive calls is valid.

If there is agreement I'll submit a PR.

----------
assignee: docs at python
components: Documentation
messages: 388133
nosy: Alex.Willmer, docs at python
priority: normal
severity: normal
status: open
title: time.monotonic(): Docs imply comparing call N and call N+M is invalid for M>1
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Mar  4 17:28:09 2021
From: report at bugs.python.org (mattip)
Date: Thu, 04 Mar 2021 22:28:09 +0000
Subject: [issue41324] Add a minimal decimal capsule API
In-Reply-To: <1594984713.74.0.721782226907.issue41324@roundup.psfhosted.org>
Message-ID: <1614896889.23.0.57633485943.issue41324@roundup.psfhosted.org>


mattip <matti.picus at gmail.com> added the comment:

Was expanding the C-API discussed on the mailing list or in any wider forum? It seems vstinner is working hard to reduce the public API exposure while this issue + PR makes it even larger. Please reconsider putting this in for 3.10.

----------
nosy: +mattip

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

From report at bugs.python.org  Thu Mar  4 17:30:28 2021
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 04 Mar 2021 22:30:28 +0000
Subject: [issue28712] Non-Windows mappings for a couple of Windows code pages
In-Reply-To: <1479274828.26.0.726447169651.issue28712@psf.upfronthosting.co.za>
Message-ID: <1614897028.89.0.77714136562.issue28712@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Thu Mar  4 17:34:08 2021
From: report at bugs.python.org (Alex Willmer)
Date: Thu, 04 Mar 2021 22:34:08 +0000
Subject: [issue43407] time.monotonic(): Docs imply comparing call N and call
 N+M is invalid for M>1
In-Reply-To: <1614896470.36.0.766208602401.issue43407@roundup.psfhosted.org>
Message-ID: <1614897248.6.0.983455919755.issue43407@roundup.psfhosted.org>


Alex Willmer <alex at moreati.org.uk> added the comment:

Discussion from #python IRC

[21:51] <moreati> Given `a=time.monotonic(); b=time.monotonic(); c=time.monotonic()` is `c-a < delta` a valid comparison? Until this evening I thought so, but I've just read https://docs.python.org/3/library/time.html#time.monotonic and the wording it uses is "only the difference between the results of consecutive calls is valid" implying `b-a < delta` is valid, or `c-b < delta`; but not `c-a < delta`. Am I understanding the wording correctly?
[21:52] <moreati> IOW is it literally only call n, and n+1. or n, and n+m?
[21:53] <SnoopJ> moreati, I think "consecutive" is incorrect there, based on the rest of that sentence.
[21:57] <jarthur> moreati SnoopJ yes, I agree, the consecutive wording has tripped me up when I first started using monotonic. I think there's an understated transitive property that allows a to c comparisons just fine.
[21:58] <SnoopJ> jarthur, yea, it would be deeply weird if `b-a` and `c-b` were meaningful deltas, but `c-a` was not
[21:59] <moreati> re time.monotonic() the only reason I could of for the literal interpretation of the wording is an overflow, or integer wraparound corner case
[22:00] <SnoopJ> weirdly, the CPython doc uses the same language
[22:02] <jarthur> I actually ended up looking at the monotonic code a while back, and at least back then the wraparound case is really hard to reach, maybe possible on Windows if you haven't called it in a while. Either way, there was nothing in the Linux/glibc or Windows calls used that would have made the wraparound/overflow case apply to skipped evaluation of a middle observation more than it would consecutive observations.
...
[22:06] <SnoopJ> moreati, looks like this language was added when the function was, and I guess maybe nobody's ever raised this complaint about the wording: https://hg.python.org/cpython/rev/376ce937823c
[22:07] <SnoopJ> nice catch :)
...
[22:22] <moreati> FTR https://bugs.python.org/issue43407
[22:28] <SnoopJ> moreati, I would recommend just submitting the PR, since it's docs.
[22:28] <moreati> ok
[22:28] <SnoopJ> but I think the best wording would be something like "only the difference between two calls of this function is meaningful"
[22:30] <moreati> agreed, subsequent is a $5 word in a 50c requirement. May I quote our conversation in the ticket? Ditto jarthur
[22:30] <SnoopJ> absolutely
[22:30] <jarthur> yep
[22:30] <moreati> ty
[22:30] <SnoopJ> but yea, just open a PR, that way you need a single pass from someone with authority here rather than two ;)
[22:31] <grym> >Never use a long word where a short one will do.

----------

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

From report at bugs.python.org  Thu Mar  4 17:54:32 2021
From: report at bugs.python.org (Alex Willmer)
Date: Thu, 04 Mar 2021 22:54:32 +0000
Subject: [issue43407] time.monotonic(): Docs imply comparing call N and call
 N+M is invalid for M>1
In-Reply-To: <1614896470.36.0.766208602401.issue43407@roundup.psfhosted.org>
Message-ID: <1614898472.64.0.622471318107.issue43407@roundup.psfhosted.org>


Change by Alex Willmer <alex at moreati.org.uk>:


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

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

From report at bugs.python.org  Thu Mar  4 18:20:50 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Mar 2021 23:20:50 +0000
Subject: [issue39169] TypeError: 'int' object is not callable if the signal
 handler is SIG_IGN
In-Reply-To: <1577750785.74.0.863762449142.issue39169@roundup.psfhosted.org>
Message-ID: <1614900050.88.0.65593736005.issue39169@roundup.psfhosted.org>


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


----------
resolution:  -> duplicate
stage: test needed -> resolved
status: open -> closed
superseder:  -> Possible race condition between signal catching and signal.signal

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

From report at bugs.python.org  Thu Mar  4 18:22:55 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Mar 2021 23:22:55 +0000
Subject: [issue23395] _thread.interrupt_main() errors if SIGINT handler in
 SIG_DFL, SIG_IGN
In-Reply-To: <1423093850.42.0.241477195496.issue23395@psf.upfronthosting.co.za>
Message-ID: <1614900175.11.0.550585461237.issue23395@roundup.psfhosted.org>


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

Turns out this didn't fix all possible situations. See bpo-43406 for an updated patch.

----------

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

From report at bugs.python.org  Thu Mar  4 18:29:56 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 04 Mar 2021 23:29:56 +0000
Subject: [issue43399] xml.etree.ElementTree.extend does not work with
 iterators when using the Python implementation
In-Reply-To: <1614873561.76.0.875762243403.issue43399@roundup.psfhosted.org>
Message-ID: <1614900596.51.0.147596034414.issue43399@roundup.psfhosted.org>


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

+1 for back porting, but check with the RM first.

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

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

From report at bugs.python.org  Thu Mar  4 18:39:37 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 04 Mar 2021 23:39:37 +0000
Subject: [issue43400] Remove "Mock is very easy to use" from unittest.mock
 documentation
In-Reply-To: <1614876238.1.0.922616136062.issue43400@roundup.psfhosted.org>
Message-ID: <1614901177.0.0.0668991878313.issue43400@roundup.psfhosted.org>


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


New changeset 2122e486307d5577cb5fb5e7cfd24095695bc7e9 by Eddie Peters in branch 'master':
bpo-43400: Remove "easy to use" from mock docs (GH-24752)
https://github.com/python/cpython/commit/2122e486307d5577cb5fb5e7cfd24095695bc7e9


----------

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

From report at bugs.python.org  Thu Mar  4 18:39:40 2021
From: report at bugs.python.org (miss-islington)
Date: Thu, 04 Mar 2021 23:39:40 +0000
Subject: [issue43400] Remove "Mock is very easy to use" from unittest.mock
 documentation
In-Reply-To: <1614876238.1.0.922616136062.issue43400@roundup.psfhosted.org>
Message-ID: <1614901180.29.0.948486238169.issue43400@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: +23530
pull_request: https://github.com/python/cpython/pull/24758

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

From report at bugs.python.org  Thu Mar  4 18:39:52 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 04 Mar 2021 23:39:52 +0000
Subject: [issue43400] Remove "Mock is very easy to use" from unittest.mock
 documentation
In-Reply-To: <1614876238.1.0.922616136062.issue43400@roundup.psfhosted.org>
Message-ID: <1614901192.06.0.660677627865.issue43400@roundup.psfhosted.org>


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


----------
assignee: docs at python -> rhettinger

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

From report at bugs.python.org  Thu Mar  4 18:41:57 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 04 Mar 2021 23:41:57 +0000
Subject: [issue43399] xml.etree.ElementTree.extend does not work with
 iterators when using the Python implementation
In-Reply-To: <1614873561.76.0.875762243403.issue43399@roundup.psfhosted.org>
Message-ID: <1614901317.1.0.584971240466.issue43399@roundup.psfhosted.org>


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


----------
nosy: +lukasz.langa

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

From report at bugs.python.org  Thu Mar  4 19:33:16 2021
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 05 Mar 2021 00:33:16 +0000
Subject: [issue43364] Windows: Make UTF-8 mode more accessible
In-Reply-To: <1614675827.66.0.411790166938.issue43364@roundup.psfhosted.org>
Message-ID: <1614904396.07.0.23891053083.issue43364@roundup.psfhosted.org>


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


----------
title: Add shortcut to enable UTF-8 mode in start menu. -> Windows: Make UTF-8 mode more accessible

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

From report at bugs.python.org  Thu Mar  4 19:35:54 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 05 Mar 2021 00:35:54 +0000
Subject: [issue43400] Remove "Mock is very easy to use" from unittest.mock
 documentation
In-Reply-To: <1614876238.1.0.922616136062.issue43400@roundup.psfhosted.org>
Message-ID: <1614904554.61.0.103663898353.issue43400@roundup.psfhosted.org>


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


New changeset 0dd4cb944b497dc6bd0b3763e461d72e9a7b6490 by Miss Islington (bot) in branch '3.9':
bpo-43400: Remove "easy to use" from mock docs (GH-24752) (GH-24758)
https://github.com/python/cpython/commit/0dd4cb944b497dc6bd0b3763e461d72e9a7b6490


----------

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

From report at bugs.python.org  Thu Mar  4 20:10:03 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 05 Mar 2021 01:10:03 +0000
Subject: [issue40578] Deprecate numeric item access for platform.uname()
In-Reply-To: <1589033216.57.0.707246281717.issue40578@roundup.psfhosted.org>
Message-ID: <1614906603.85.0.591393626285.issue40578@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

For posterity, I'll share my motivation.

> Why is it a problem that people are using something which is documented as a tuple?

It's not a problem that they access it by tuple if it's documented.

The problem is that it's documented for access as a tuple when there is a superior method to access (by attribute) that's less opaque than the historical method by index.

I apologize for not documenting that in the original post. It seemed obvious to me at the time that having one obvious way to access the items would be preferred.

For example, `uname()[0]` doesn't mean anything to me without a comment or referencing the documetation, whereas `uname().system` does.

Access by numerical index hearkens back to C-style arrays and in my mind is an anti-pattern.

----------

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

From report at bugs.python.org  Thu Mar  4 20:15:38 2021
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 05 Mar 2021 01:15:38 +0000
Subject: [issue43400] Remove "Mock is very easy to use" from unittest.mock
 documentation
In-Reply-To: <1614876238.1.0.922616136062.issue43400@roundup.psfhosted.org>
Message-ID: <1614906938.9.0.772209197109.issue43400@roundup.psfhosted.org>


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

Mock has a section on getting started that has several recipes but it's not under howto section. Perhaps this page could be updated if you want to make a PR : https://docs.python.org/3/library/unittest.mock-examples.html

There is also a section on where to patch : https://docs.python.org/3/library/unittest.mock.html#where-to-patch

I admit it also bites me few times and I have to do trial and error to get the right patch object.

----------

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

From report at bugs.python.org  Thu Mar  4 20:27:05 2021
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 05 Mar 2021 01:27:05 +0000
Subject: [issue43405] DeprecationWarnings in test_unicode
In-Reply-To: <1614889755.46.0.756872715083.issue43405@roundup.psfhosted.org>
Message-ID: <1614907625.39.0.138537758174.issue43405@roundup.psfhosted.org>


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

The changes were introduced in https://bugs.python.org/issue36346

----------
nosy: +methane, xtreak

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

From report at bugs.python.org  Thu Mar  4 20:39:12 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 05 Mar 2021 01:39:12 +0000
Subject: [issue43400] Improve recipes and howtos for the unittest.mock
In-Reply-To: <1614876238.1.0.922616136062.issue43400@roundup.psfhosted.org>
Message-ID: <1614908352.31.0.067499281294.issue43400@roundup.psfhosted.org>


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

Renaming this issue to reflect a shift in focus towards broader improvements to the documentation.

----------
title: Remove "Mock is very easy to use" from unittest.mock documentation -> Improve recipes and howtos for the unittest.mock
versions:  -Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Thu Mar  4 20:39:19 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 05 Mar 2021 01:39:19 +0000
Subject: [issue43400] Improve recipes and howtos for the unittest.mock
In-Reply-To: <1614876238.1.0.922616136062.issue43400@roundup.psfhosted.org>
Message-ID: <1614908359.02.0.215211539857.issue43400@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/issue43400>
_______________________________________

From report at bugs.python.org  Thu Mar  4 21:34:55 2021
From: report at bugs.python.org (Neil Schemenauer)
Date: Fri, 05 Mar 2021 02:34:55 +0000
Subject: [issue43372] ctypes: test_frozentable fails when make regen-frozen
In-Reply-To: <1614696034.15.0.923342699637.issue43372@roundup.psfhosted.org>
Message-ID: <1614911695.89.0.0326889392946.issue43372@roundup.psfhosted.org>


Change by Neil Schemenauer <nas-python at arctrix.com>:


----------
pull_requests: +23531
pull_request: https://github.com/python/cpython/pull/24759

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

From report at bugs.python.org  Thu Mar  4 21:34:56 2021
From: report at bugs.python.org (Neil Schemenauer)
Date: Fri, 05 Mar 2021 02:34:56 +0000
Subject: [issue42246] Implement PEP 626 -- Precise line numbers for debugging
In-Reply-To: <1604331162.26.0.596873070589.issue42246@roundup.psfhosted.org>
Message-ID: <1614911696.17.0.252955888684.issue42246@roundup.psfhosted.org>


Change by Neil Schemenauer <nas-python at arctrix.com>:


----------
pull_requests: +23532
pull_request: https://github.com/python/cpython/pull/24759

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

From report at bugs.python.org  Thu Mar  4 21:39:10 2021
From: report at bugs.python.org (Neil Schemenauer)
Date: Fri, 05 Mar 2021 02:39:10 +0000
Subject: [issue43372] ctypes: test_frozentable fails when make regen-frozen
In-Reply-To: <1614696034.15.0.923342699637.issue43372@roundup.psfhosted.org>
Message-ID: <1614911950.72.0.548463682492.issue43372@roundup.psfhosted.org>


Change by Neil Schemenauer <nas-python at arctrix.com>:


----------
assignee:  -> nascheme

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

From report at bugs.python.org  Fri Mar  5 00:47:32 2021
From: report at bugs.python.org (Ned Deily)
Date: Fri, 05 Mar 2021 05:47:32 +0000
Subject: [issue43404] No SSL certificates when using the Mac installer
In-Reply-To: <1614884005.35.0.786100424357.issue43404@roundup.psfhosted.org>
Message-ID: <1614923252.31.7.85524248579e-05.issue43404@roundup.psfhosted.org>


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

When installing current Pythons for macOS downloaded from python.org, you will need to run the "Install Certificates.command" file installed into the /Applications/Python 3.x" folder for the version installed. This is noted in the initial screen when running the installer:

"At the end of this install, click on Install Certificates to install a set of current SSL root certificates."

It is also described in more detail in the "Read Me" file is also displayed by the installer and a copy of which is also installed in the /Applications/Python 3.x folder.

"Certificate verification and OpenSSL

This package includes its own private copy of OpenSSL 1.1.1.   The trust certificates in system and user keychains managed by the Keychain Access application and the security command line utility are not used as defaults by the Python ssl module.  A sample command script is included in /Applications/Python 3.9 to install a curated bundle of default root certificates from the third-party certifi package (https://pypi.org/project/certifi/).  Double-click on Install Certificates to run it.

The bundled pip has its own default certificate store for verifying download connections."

The installer also opens the /Applications/Python 3.x folder in a Finder window to make all of these files immediately accessible.

----------
nosy: +ned.deily
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Mar  5 00:49:37 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 05 Mar 2021 05:49:37 +0000
Subject: [issue43390] Set the SA_ONSTACK in PyOS_setsig to play well with
 other VMs like Golang
In-Reply-To: <1614793504.75.0.801298006043.issue43390@roundup.psfhosted.org>
Message-ID: <1614923377.89.0.0984407619018.issue43390@roundup.psfhosted.org>


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


New changeset 02ac6f41e5569ec28d625bb005155903f64cc9ee by Gregory P. Smith in branch 'master':
bpo-43390: Set SA_ONSTACK in PyOS_setsig (GH-24730)
https://github.com/python/cpython/commit/02ac6f41e5569ec28d625bb005155903f64cc9ee


----------

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

From report at bugs.python.org  Fri Mar  5 00:52:11 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 05 Mar 2021 05:52:11 +0000
Subject: [issue43390] Set the SA_ONSTACK in PyOS_setsig to play well with
 other VMs like Golang
In-Reply-To: <1614793504.75.0.801298006043.issue43390@roundup.psfhosted.org>
Message-ID: <1614923531.78.0.249031276297.issue43390@roundup.psfhosted.org>


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

I expect zero fallout from this given the semantics.  SA_ONSTACK really appears to be something that should've been the POSIX default since it was introduced as a feature in ~BSD4.2 in the early 80s.  But it never was.

It'll be good to have in the beta releases to see if anyone pipes up.

We'll be running our interpreter inside Google with this flag enabled.

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

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

From report at bugs.python.org  Fri Mar  5 00:52:56 2021
From: report at bugs.python.org (=?utf-8?b?54uC55S36aOO?=)
Date: Fri, 05 Mar 2021 05:52:56 +0000
Subject: [issue42627] urllib.request.getproxies() misparses Windows registry
 proxy settings
In-Reply-To: <1607804872.9.0.5170746987.issue42627@roundup.psfhosted.org>
Message-ID: <1614923576.05.0.0877428953948.issue42627@roundup.psfhosted.org>


Change by ??? <crazyboyfeng at qq.com>:


----------
nosy: +CrazyBoyFeng

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

From report at bugs.python.org  Fri Mar  5 01:03:36 2021
From: report at bugs.python.org (Eric L.)
Date: Fri, 05 Mar 2021 06:03:36 +0000
Subject: [issue43395] os.path states that bytes can't represent all MBCS paths
 under Windows
In-Reply-To: <1614839485.4.0.948731177165.issue43395@roundup.psfhosted.org>
Message-ID: <1614924216.81.0.175096129663.issue43395@roundup.psfhosted.org>


Eric L. <ewl+python at lavar.de> added the comment:

Very confusing but very interesting. I'm trying to follow as I'm the main maintainer of the rdiff-backup software, which goes cross-platforms, so these small differences might become important.

Now, looking into the docs, following your explanations, I noticed that https://docs.python.org/3/library/os.html#os.fsencode and https://docs.python.org/3/library/os.html#os.fsdecode state that the 'strict' error handler is used under Windows instead of the stated 'surrogatepass'. Again an issue with the documentation?

Also, the 2nd paragraph of https://docs.python.org/3.8/library/os.html#file-names-command-line-arguments-and-environment-variables speaks only of surrogateescape and doesn't make the difference between POSIX and Windows.

Very interesting but very confusing...

----------

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

From report at bugs.python.org  Fri Mar  5 01:06:29 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 05 Mar 2021 06:06:29 +0000
Subject: [issue43300] "bisect" module should support reverse-sorted sequences
In-Reply-To: <1614017554.0.0.495039898854.issue43300@roundup.psfhosted.org>
Message-ID: <1614924389.09.0.827639258193.issue43300@roundup.psfhosted.org>


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

Thank you for the suggestion, but am going close this for the reasons mentioned above.

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

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

From report at bugs.python.org  Fri Mar  5 02:49:58 2021
From: report at bugs.python.org (=?utf-8?b?54uC55S36aOO?=)
Date: Fri, 05 Mar 2021 07:49:58 +0000
Subject: [issue42627] urllib.request.getproxies() misparses Windows registry
 proxy settings
In-Reply-To: <1607804872.9.0.5170746987.issue42627@roundup.psfhosted.org>
Message-ID: <1614930598.98.0.858332388758.issue42627@roundup.psfhosted.org>


??? <crazyboyfeng at qq.com> added the comment:

We know Windows reslove:
`http=host:port;https=host:port;ftp=host:port;socks=host:port`
as:
`http=http://host:port;https=http://host:port;ftp=http://host:port;socks=socks://host:port`
means:  
Using HTTP type proxy for HTTP, HTTPS and FTP requests, but Socks4/4a type proxy for the other TCP requests.
We notice that socks are different from the others.

Now I want to know what if Windows slove this:
`http=socks://host:port;ftp=https://host:port;socks=https://host:port`
Does it mean using Socks4/4a type proxy for HTTP requests, HTTPS type proxy for FTP requests, and HTTP type proxy for the other TCP requests? 
Or just invalid settings?

----------

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

From report at bugs.python.org  Fri Mar  5 04:33:19 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Mar 2021 09:33:19 +0000
Subject: [issue43406] Possible race condition between signal catching and
 signal.signal
In-Reply-To: <1614893468.93.0.265748275948.issue43406@roundup.psfhosted.org>
Message-ID: <1614936799.86.0.885319423682.issue43406@roundup.psfhosted.org>


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


New changeset 68245b7a1030287294c65c298975ab9026543fd2 by Antoine Pitrou in branch 'master':
bpo-43406: Fix possible race condition where ``PyErr_CheckSignals`` tries to execute a non-Python signal handler (GH-24756)
https://github.com/python/cpython/commit/68245b7a1030287294c65c298975ab9026543fd2


----------

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

From report at bugs.python.org  Fri Mar  5 04:33:27 2021
From: report at bugs.python.org (miss-islington)
Date: Fri, 05 Mar 2021 09:33:27 +0000
Subject: [issue43406] Possible race condition between signal catching and
 signal.signal
In-Reply-To: <1614893468.93.0.265748275948.issue43406@roundup.psfhosted.org>
Message-ID: <1614936807.5.0.168932908398.issue43406@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: +23533
pull_request: https://github.com/python/cpython/pull/24761

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

From report at bugs.python.org  Fri Mar  5 04:45:10 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Mar 2021 09:45:10 +0000
Subject: [issue43406] Possible race condition between signal catching and
 signal.signal
In-Reply-To: <1614893468.93.0.265748275948.issue43406@roundup.psfhosted.org>
Message-ID: <1614937510.9.0.655692849976.issue43406@roundup.psfhosted.org>


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


----------
pull_requests: +23534
pull_request: https://github.com/python/cpython/pull/24762

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

From report at bugs.python.org  Fri Mar  5 05:49:06 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 05 Mar 2021 10:49:06 +0000
Subject: [issue43395] os.path states that bytes can't represent all MBCS paths
 under Windows
In-Reply-To: <1614839485.4.0.948731177165.issue43395@roundup.psfhosted.org>
Message-ID: <1614941346.23.0.754010393276.issue43395@roundup.psfhosted.org>


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

>  instead of the stated 'surrogatepass'

In Python 3.6 and above, you can check this as follows:

    >>> sys.getfilesystemencoding()
    'utf-8'
    >>> sys.getfilesystemencodeerrors()
    'surrogatepass'

In Python 3.5 and previous:

    >>> sys.getfilesystemencoding()
    'mbcs'

In 3.5, the error handler used by fsencode() and fsdecode() was hard coded as 'strict' for the 'mbcs' encoding, and otherwise 'surrogateescape'.

> https://docs.python.org/3/library/os.html#os.fsencode
> https://docs.python.org/3/library/os.html#os.fsdecode

The above documentation needs to be updated to reference sys.getfilesystemencodeerrors(), as do the doc strings:

    >>> print(textwrap.dedent(os.fsencode.__doc__))

    Encode filename to the filesystem encoding with 'surrogateescape' error
    handler, return bytes unchanged. On Windows, use 'strict' error handler if
    the file system encoding is 'mbcs' (which is the default encoding).

    >>> print(textwrap.dedent(os.fsdecode.__doc__))

    Decode filename from the filesystem encoding with 'surrogateescape' error
    handler, return str unchanged. On Windows, use 'strict' error handler if
    the file system encoding is 'mbcs' (which is the default encoding).

> https://docs.python.org/3/library/os.html#file-names-command-line-arguments-and-environment-variables

This should be rewritten to link to sys.getfilesystemencodeerrors(). I'm fine with only discussing the use of "surrogateescape", which is a significant concern in POSIX systems, for which it is very easy and common for filenames to be created with an arbitrary encoding. 

I don't know if the use of "surrogatepass" in Windows warrants discussion. It is uncommon to need the error handler because the filesystem is Unicode. A user is unlikely to create a filename with an unpaired surrogate code. 

That said, before Windows 10, the legacy console allowed copying half of a surrogate pair to the clipboard, and a program could have a bug that nulls the second surrogate code in the pair (e.g. when limiting the length of a filename). Anyway, it's technically possible, so we support it. For example, "?" (U+0001F608) is encoded in UTF-16 as the pair (U+D83D, U+DE08). A filename could end up with only the first of the two codes:

    >>> open('devil\ud83d', 'w').close()
    >>> print(ascii(os.listdir('.')[0]))
    'devil\ud83d'

----------

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

From report at bugs.python.org  Fri Mar  5 07:14:47 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 05 Mar 2021 12:14:47 +0000
Subject: [issue25731] Assigning and deleting __new__ attr on the class does
 not allow to create instances of this class
In-Reply-To: <1448454590.41.0.350843358205.issue25731@psf.upfronthosting.co.za>
Message-ID: <1614946487.73.0.52711443723.issue25731@roundup.psfhosted.org>


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


----------
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.7, Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Fri Mar  5 07:15:56 2021
From: report at bugs.python.org (=?utf-8?b?54uC55S36aOO?=)
Date: Fri, 05 Mar 2021 12:15:56 +0000
Subject: [issue42627] urllib.request.getproxies() misparses Windows registry
 proxy settings
In-Reply-To: <1607804872.9.0.5170746987.issue42627@roundup.psfhosted.org>
Message-ID: <1614946556.69.0.450262849687.issue42627@roundup.psfhosted.org>


??? <crazyboyfeng at qq.com> added the comment:

I make some black box tests with the HTTPS proxy. 
Set system proxy `http=https://host:port` and start a HTTPS proxy, then IE, Edge (Chromium) and benrg's code (using `urllib3`) work fine while fetching `http://website`. Then I shutdown the HTTPS proxy and start a HTTP proxy on the same port, I get SSLError. That's it.

benrg should add your patch as soon as possible.
Too few people actually use HTTPS proxy. Even if there is a bug with HTTPS proxy, it will not be too late to fix it when it is discovered.

----------

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

From report at bugs.python.org  Fri Mar  5 07:26:34 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 05 Mar 2021 12:26:34 +0000
Subject: [issue28356] Windows: os.rename different in python 2.7.12 and python
 3.5.2
In-Reply-To: <1475588552.47.0.916118565333.issue28356@psf.upfronthosting.co.za>
Message-ID: <1614947194.07.0.750173890027.issue28356@roundup.psfhosted.org>


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


----------
type: behavior -> enhancement
versions:  -Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Fri Mar  5 08:23:25 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 05 Mar 2021 13:23:25 +0000
Subject: [issue29533] urllib2 works slowly with proxy on windows
In-Reply-To: <1486802607.23.0.387912582288.issue29533@psf.upfronthosting.co.za>
Message-ID: <1614950605.56.0.337949296872.issue29533@roundup.psfhosted.org>


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


----------
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.7, Python 3.6

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

From report at bugs.python.org  Fri Mar  5 08:28:09 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 05 Mar 2021 13:28:09 +0000
Subject: [issue16272] C-API documentation clarification for tp_dictoffset
In-Reply-To: <1350520063.61.0.687481658196.issue16272@psf.upfronthosting.co.za>
Message-ID: <1614950889.75.0.668677700476.issue16272@roundup.psfhosted.org>


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


----------
Removed message: https://bugs.python.org/msg221020

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

From report at bugs.python.org  Fri Mar  5 08:35:24 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 05 Mar 2021 13:35:24 +0000
Subject: [issue16272] C-API documentation clarification for tp_dictoffset
In-Reply-To: <1350520063.61.0.687481658196.issue16272@psf.upfronthosting.co.za>
Message-ID: <1614951324.6.0.979307051191.issue16272@roundup.psfhosted.org>


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


----------
type:  -> enhancement
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Mar  5 08:43:39 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 05 Mar 2021 13:43:39 +0000
Subject: [issue30469] Inconsistent Execution of Generic Descriptor Attributes
In-Reply-To: <1495671188.71.0.216050990731.issue30469@psf.upfronthosting.co.za>
Message-ID: <1614951819.61.0.895934137088.issue30469@roundup.psfhosted.org>


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


----------
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.7, Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Fri Mar  5 08:49:26 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 05 Mar 2021 13:49:26 +0000
Subject: [issue30469] Inconsistent Execution of Generic Descriptor Attributes
In-Reply-To: <1495671188.71.0.216050990731.issue30469@psf.upfronthosting.co.za>
Message-ID: <1614952166.17.0.881875701112.issue30469@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/issue30469>
_______________________________________

From report at bugs.python.org  Fri Mar  5 09:09:39 2021
From: report at bugs.python.org (Qihao Chen)
Date: Fri, 05 Mar 2021 14:09:39 +0000
Subject: [issue43408] about the method: title()
Message-ID: <1614953379.79.0.488838369469.issue43408@roundup.psfhosted.org>


New submission from Qihao Chen <chinkikoo227 at gmail.com>:

Hello, I'm a student from China, and I think there is a bug in Python3.7.

When I use the method "title()", I think the method should not make "'s" upper.

I would appreciate it if you could consider my advice.

----------
files: title().png
messages: 388153
nosy: chinkikoo227
priority: normal
severity: normal
status: open
title: about the method: title()
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file49852/title().png

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

From report at bugs.python.org  Fri Mar  5 09:47:44 2021
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 05 Mar 2021 14:47:44 +0000
Subject: [issue43408] about the method: title()
In-Reply-To: <1614953379.79.0.488838369469.issue43408@roundup.psfhosted.org>
Message-ID: <1614955664.6.0.80639940519.issue43408@roundup.psfhosted.org>


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

This behavior is documented, https://docs.python.org/3/library/stdtypes.html#str.title

> The algorithm uses a simple language-independent definition of a word as groups of consecutive letters. The definition works in many contexts but it means that apostrophes in contractions and possessives form word boundaries, which may not be the desired result

The documentation also mentions a workaround.

----------
nosy: +christian.heimes
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Mar  5 10:23:08 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 05 Mar 2021 15:23:08 +0000
Subject: [issue8557] subprocess PATH semantics and portability
In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>
Message-ID: <1614957788.27.0.622951910626.issue8557@roundup.psfhosted.org>


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

The Popen() docs begin by explaining that it has "os.execvp()-like" behavior in POSIX and uses CreateProcess() in Windows. Personally, I do not think it's proper for Python's documentation to discuss details of  how CreateProcess() handles lpCommandLine (args), lpApplicationName (executable), lpCurrentDirectory (cwd), and lpEnvironment (env). So maybe all this needs is to clearly map Popen() parameters to the corresponding CreateProcess() parameters.

If Popen() implements a parameter on its own, then it makes sense to me to document the behavior. For example, in POSIX the behavior of `cwd` is implemented by Popen(), and documented as follows:

    In particular, the function looks for executable (or for the first 
    item in args) relative to cwd if the executable path is a relative
    path.

This claim is not always true in POSIX since a base filename without a slash in it, which is a relative path, is not searched for in the current directory unless "." is in PATH. But the main problem with the above sentence is the lack of a disclaimer that it only applies to POSIX. In Windows, `cwd` is passed through directly as the lpCurrentDirectory of CreateProcess(). This parameter sets the working directory of the child process and has nothing to do with searching for an executable parsed out of lpCommandLine or resolving a relative path in lpApplicationName. It may affect the result with shell=True, but even in that case there are caveats. Regardless, Python doesn't do anything with `cwd` in Windows except pass it to CreateProcess(), so the cwd -> lpCurrentDirectory parameter mapping is all there is to document.

----------
status: languishing -> open
type: behavior -> enhancement
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.7, Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Fri Mar  5 10:40:25 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 05 Mar 2021 15:40:25 +0000
Subject: [issue25653] ctypes+callbacks+fork+selinux = crash
In-Reply-To: <1447826584.36.0.973987165664.issue25653@psf.upfronthosting.co.za>
Message-ID: <1614958825.05.0.774326184891.issue25653@roundup.psfhosted.org>


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


----------
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Mar  5 11:00:34 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 05 Mar 2021 16:00:34 +0000
Subject: [issue27803] ctypes automatic byref failing on custom classes
 attributes
In-Reply-To: <1471630297.02.0.563258836934.issue27803@psf.upfronthosting.co.za>
Message-ID: <1614960034.71.0.702883530403.issue27803@roundup.psfhosted.org>


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


----------
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.7, Python 3.5

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

From report at bugs.python.org  Fri Mar  5 11:16:07 2021
From: report at bugs.python.org (Zhang Boyang)
Date: Fri, 05 Mar 2021 16:16:07 +0000
Subject: [issue43409] [Win] Call subprocess.Popen() twice makes Thread.join()
 interruptible and deadlock
Message-ID: <1614960967.41.0.0636989902685.issue43409@roundup.psfhosted.org>


New submission from Zhang Boyang <zhangboyang.id at gmail.com>:

Please run joinbug.py and press Ctrl-C twice.

============= The output  =============

1st join
PLEASE PRESS CTRL-C TWICE, IGNORE THE 'Press any key to continue'
Press any key to continue . . . Press any key to continue . . .

thread exit
Traceback (most recent call last):
  File "D:\xxx\joinbug.py", line 21, in <module>
    t.join() # subprocess.Popen() makes join() can be interrupted
  File "C:\Users\xxx\AppData\Local\Programs\Python\Python39\lib\threading.py", line 1033, in join
    self._wait_for_tstate_lock()
  File "C:\Users\xxx\AppData\Local\Programs\Python\Python39\lib\threading.py", line 1049, in _wait_for_tstate_lock
    elif lock.acquire(block, timeout):
KeyboardInterrupt
2nd join
(stuck here)


============= Expected behaviour =============
either join uninterruptible
or the 2nd join doesn't deadlock.

----------
components: Windows
files: joinbug.py
messages: 388156
nosy: paul.moore, steve.dower, tim.golden, zach.ware, zby1234
priority: normal
severity: normal
status: open
title: [Win] Call subprocess.Popen() twice makes Thread.join() interruptible and deadlock
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file49853/joinbug.py

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

From report at bugs.python.org  Fri Mar  5 12:22:18 2021
From: report at bugs.python.org (Yunfan Zhan)
Date: Fri, 05 Mar 2021 17:22:18 +0000
Subject: [issue41180] marshal load bypass code.__new__ audit event
In-Reply-To: <1593586712.19.0.6550600191.issue41180@roundup.psfhosted.org>
Message-ID: <1614964938.46.0.138651353804.issue41180@roundup.psfhosted.org>


Change by Yunfan Zhan <yfzhan at sjtu.edu.cn>:


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

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

From report at bugs.python.org  Fri Mar  5 12:22:35 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 05 Mar 2021 17:22:35 +0000
Subject: [issue43410] Parser does not handle correctly some errors when parsin
 from stdin
Message-ID: <1614964955.39.0.913568985121.issue43410@roundup.psfhosted.org>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

The parser crashes when there are some syntax errors from stdin:

> echo "(1+34"  | ./python.exe -
[1]    54046 done                echo "(1+34" |
       54047 segmentation fault  ./python.exe -

----------
components: Interpreter Core
messages: 388157
nosy: lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Parser does not handle correctly some errors when parsin from stdin
versions: Python 3.10

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

From report at bugs.python.org  Fri Mar  5 12:25:21 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 05 Mar 2021 17:25:21 +0000
Subject: [issue43410] Parser does not handle correctly some errors when parsin
 from stdin
In-Reply-To: <1614964955.39.0.913568985121.issue43410@roundup.psfhosted.org>
Message-ID: <1614965121.67.0.850484578366.issue43410@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Fri Mar  5 12:31:23 2021
From: report at bugs.python.org (Numerlor)
Date: Fri, 05 Mar 2021 17:31:23 +0000
Subject: [issue43401] dbm module doc page redirects to itself
In-Reply-To: <1614881002.06.0.413665275054.issue43401@roundup.psfhosted.org>
Message-ID: <1614965483.95.0.681437326908.issue43401@roundup.psfhosted.org>


Numerlor <miso1038 at gmail.com> added the comment:

The issue seems to have resolved itself now, but may be worth a look for the cause.

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

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

From report at bugs.python.org  Fri Mar  5 12:33:23 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 05 Mar 2021 17:33:23 +0000
Subject: [issue43410] Parser does not handle correctly some errors when parsin
 from stdin
In-Reply-To: <1614964955.39.0.913568985121.issue43410@roundup.psfhosted.org>
Message-ID: <1614965603.29.0.858134957498.issue43410@roundup.psfhosted.org>


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

I think we should look into having some variable holding all the text that we have parsed so far. All the workarounds to fetch the text from the file or from stdin or whatnot are getting very very complicated.

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

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

From report at bugs.python.org  Fri Mar  5 12:46:34 2021
From: report at bugs.python.org (pmp-p)
Date: Fri, 05 Mar 2021 17:46:34 +0000
Subject: [issue43410] Parser does not handle correctly some errors when parsin
 from stdin
In-Reply-To: <1614964955.39.0.913568985121.issue43410@roundup.psfhosted.org>
Message-ID: <1614966394.77.0.0251543912848.issue43410@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/issue43410>
_______________________________________

From report at bugs.python.org  Fri Mar  5 12:51:25 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 05 Mar 2021 17:51:25 +0000
Subject: [issue43409] [Win] Call subprocess.Popen() twice makes Thread.join()
 interruptible and deadlock
In-Reply-To: <1614960967.41.0.0636989902685.issue43409@roundup.psfhosted.org>
Message-ID: <1614966685.5.0.494438524478.issue43409@roundup.psfhosted.org>


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

This is a variation on bpo-21822. If join() is called in the main thread, and it gets interrupted immediately after the lock.acquire(block, timeout) call, then subsequent calls will hang. In Windows, the acquire() call is not interruptible with Ctrl+C, so the KeyboardInterrupt gets raised immediately after acquire() returns, so the problem is easy to reproduce in Windows.

----------
nosy: +eryksun
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> KeyboardInterrupt during Thread.join hangs that Thread

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

From report at bugs.python.org  Fri Mar  5 13:54:35 2021
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 05 Mar 2021 18:54:35 +0000
Subject: [issue22708] httplib/http.client in method _tunnel used HTTP/1.0
 CONNECT method
In-Reply-To: <1414045283.61.0.401738994501.issue22708@psf.upfronthosting.co.za>
Message-ID: <1614970475.11.0.227888879738.issue22708@roundup.psfhosted.org>


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


----------
assignee:  -> orsenthil
nosy: +orsenthil

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

From report at bugs.python.org  Fri Mar  5 14:07:48 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 05 Mar 2021 19:07:48 +0000
Subject: [issue27926] ctypes is too slow to convert a Python list to a C array
In-Reply-To: <1472722275.26.0.560476389343.issue27926@psf.upfronthosting.co.za>
Message-ID: <1614971268.48.0.716717280703.issue27926@roundup.psfhosted.org>


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


----------
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Mar  5 14:25:19 2021
From: report at bugs.python.org (Martin Cooper)
Date: Fri, 05 Mar 2021 19:25:19 +0000
Subject: [issue43411] wm_manage fails with ttk.Frame
Message-ID: <1614972319.75.0.638524894464.issue43411@roundup.psfhosted.org>


New submission from Martin Cooper <mfncooper at gmail.com>:

Attempting to use a ttk.Frame with wm_manage() causes a TclError:

_tkinter.TclError: window ".!frame" is not manageable: must be a frame, labelframe or toplevel

The (Tcl) documentation for wm manage states "Only frame, labelframe and toplevel widgets can be used with this command." One might reasonably expect a ttk.Frame to appropriately fall under this requirement, especially since the name 'frame' is used for them, but it does not. One must use a tk.Frame instead to make this work.

At the very least, this needs to be documented. Looking at the error message and seeing it complain that a 'frame' is not one of 'frame', 'labelframe' or 'toplevel' is extremely confusing. There is nothing to lead to the conclusion that a ttk Frame is not a 'frame'. Better than documenting it, of course, would be to make wm_manage actually work properly with a ttk.Frame, as developers would expect.

----------
components: Tkinter
messages: 388161
nosy: mfncooper
priority: normal
severity: normal
status: open
title: wm_manage fails with ttk.Frame
type: behavior

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

From report at bugs.python.org  Fri Mar  5 14:34:04 2021
From: report at bugs.python.org (Emmanuel Arias)
Date: Fri, 05 Mar 2021 19:34:04 +0000
Subject: [issue43352] Add a Barrier object in asyncio lib
In-Reply-To: <1614598796.36.0.0905111746151.issue43352@roundup.psfhosted.org>
Message-ID: <1614972844.74.0.287026558728.issue43352@roundup.psfhosted.org>


Change by Emmanuel Arias <eamanu at yaerobi.com>:


----------
nosy: +eamanu

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

From report at bugs.python.org  Fri Mar  5 14:59:59 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 05 Mar 2021 19:59:59 +0000
Subject: [issue27803] ctypes automatic byref failing on custom classes
 attributes
In-Reply-To: <1471630297.02.0.563258836934.issue27803@psf.upfronthosting.co.za>
Message-ID: <1614974399.54.0.642752883049.issue27803@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/issue27803>
_______________________________________

From report at bugs.python.org  Fri Mar  5 15:49:15 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 05 Mar 2021 20:49:15 +0000
Subject: [issue28259] Ctypes bug windows
In-Reply-To: <1474647946.24.0.533944480109.issue28259@psf.upfronthosting.co.za>
Message-ID: <1614977355.91.0.700610148478.issue28259@roundup.psfhosted.org>


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

I didn't have time to look deeper into this. I'm sorry for not getting back to you. The rather-large example that you uploaded didn't and doesn't run for me, so I wasn't able to reproduce the problem.

The one bit of advice I have is to always declare required argument types in the `argtypes` attribute of ctypes functions. It can be very useful to take advantage of the type checking that ctypes provides in order to catch problems before they lead to stack or heap corruption, or bad values that lead to corruption later on. 

I'm closing this issue as not a bug. ctypes and libffi have been used in a broad range of cases in 32-bit Windows for many years, and I wasn't able to reproduce the problem with a function of the given call signature when I checked in 2016.

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

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

From report at bugs.python.org  Fri Mar  5 15:57:28 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 05 Mar 2021 20:57:28 +0000
Subject: [issue43332] Make http.client._tunnel send one byte string over the
 network
In-Reply-To: <1614370680.1.0.103129903648.issue43332@roundup.psfhosted.org>
Message-ID: <1614977848.1.0.660702542779.issue43332@roundup.psfhosted.org>


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

I changed the title to what a PR/commit title should look like.  Your justification is that "Multiple writes possibly cause excessive network usage and increased implementation complexity on the other end."

I see no problem with the formatting of your first post.

I presume the proposal is to make a list of bytes and then b''.join(the_list).  This is now a standard idiom.  Have you tested a patch locally?  Can you make a PR?

I don't know if there was a particular reason to not join before sending.  Perhaps because successive sends effectively do the same thing, though with the possible  downsides you note.  I am not an expert on network usage.

The _connect method was added by Senthil Kumaran in 2009 in #1424152 and revised since.  There is no current http maintainer, so I added as nosy  Senthil and others who have worked on the module.

----------
nosy: +berker.peksag, gregory.p.smith, orsenthil, terry.reedy
title: http/client.py: - uses multiple network writes, possibly causing excessive network usage and increased implementation complexity on the other end -> Make http.client._tunnel send one byte string over the network

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

From report at bugs.python.org  Fri Mar  5 16:02:21 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 05 Mar 2021 21:02:21 +0000
Subject: [issue43336] document whether io.TextIOBase.readline(size>0) will
 always read the full newline
In-Reply-To: <1614392137.45.0.448589201829.issue43336@roundup.psfhosted.org>
Message-ID: <1614978141.32.0.155622945712.issue43336@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Fri Mar  5 16:03:13 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 05 Mar 2021 21:03:13 +0000
Subject: [issue43337] export the set newline value on TextIOBase/TextIOWrapper
In-Reply-To: <1614404728.94.0.258919800539.issue43337@roundup.psfhosted.org>
Message-ID: <1614978193.67.0.428842065018.issue43337@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Fri Mar  5 16:04:21 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 05 Mar 2021 21:04:21 +0000
Subject: [issue43332] Make http.client._tunnel send one byte string over the
 network
In-Reply-To: <1614370680.1.0.103129903648.issue43332@roundup.psfhosted.org>
Message-ID: <1614978261.1.0.591551418701.issue43332@roundup.psfhosted.org>


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

yep, that'd be a worthwhile improvement.  note that the send method in that code also accepts BytesIO objects so rather than doing our own sequence of bytes and join we could just buffer in one of those.

----------

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

From report at bugs.python.org  Fri Mar  5 16:04:41 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 05 Mar 2021 21:04:41 +0000
Subject: [issue43332] Make http.client._tunnel send one byte string over the
 network
In-Reply-To: <1614370680.1.0.103129903648.issue43332@roundup.psfhosted.org>
Message-ID: <1614978281.52.0.862189502694.issue43332@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
stage:  -> needs patch

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

From report at bugs.python.org  Fri Mar  5 16:15:27 2021
From: report at bugs.python.org (Alex Willmer)
Date: Fri, 05 Mar 2021 21:15:27 +0000
Subject: [issue23740] http.client request and send method have some datatype
 issues
In-Reply-To: <1427052524.74.0.134908492197.issue23740@psf.upfronthosting.co.za>
Message-ID: <1614978927.13.0.379536000558.issue23740@roundup.psfhosted.org>


Alex Willmer <alex at moreati.org.uk> added the comment:

http_dump.py now covers CPython 3.6-3.10 (via Tox), and HTTPSConnection https://github.com/moreati/bpo-23740

----------

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

From report at bugs.python.org  Fri Mar  5 16:51:55 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 05 Mar 2021 21:51:55 +0000
Subject: [issue43338] Provide offical installers for security releases
In-Reply-To: <1614420445.03.0.702209147206.issue43338@roundup.psfhosted.org>
Message-ID: <1614981115.64.0.111236111627.issue43338@roundup.psfhosted.org>


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

This tracker is only concerned with the PSF/python.org Windows and macOS installers, not the *nix distributions, so I assume that one the former is your concern.

For those, your request has been made and rejected multiple times before.  A request on the tracker won't change this policy decision.  Briefly, we consider other actions by the volunteers who make those installers to be more valuable.  Making more installers means not doing something else, like fixing bugs or keeping up with OS changes or enhancing something.

A little more: 1. Many -- maybe most -- security fixes are only or mainly of concern to server maintainers.  They mostly run *nix or compile their own binaries or pay someone to do so.  2. Running older Python versions instead of newer versions is a user choice, not ours.  3. Non-PSF distributors of Python for Windows and Mac are free to recompile their binaries whenever they want to.

For Windows, I don't know what your concern is about 'signed' binaries.  Anyone can install the Visual Studio Community Edition and Git and clone and compile their own binary.  This is at least as secure as a downloaded binary.  If more instructions are needed for how to use that binary for production use, that would be a different issue. (And perhaps git should be told to git-ignore additions to site-packages.)

----------
nosy: +ned.deily, steve.dower, terry.reedy
resolution:  -> rejected
stage:  -> resolved
status: open -> closed
title: [feature request] Please provide offical installers for security releases -> Provide offical installers for security releases

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

From report at bugs.python.org  Fri Mar  5 17:12:41 2021
From: report at bugs.python.org (Peter Eisentraut)
Date: Fri, 05 Mar 2021 22:12:41 +0000
Subject: [issue43412] object.h -Wcast-qual warning
Message-ID: <1614982361.61.0.858230879301.issue43412@roundup.psfhosted.org>


New submission from Peter Eisentraut <peter at eisentraut.org>:

object.h contains an inline function that causes a -Wcast-qual warning from gcc.  Since this file ends up visible in third-party code that includes Python.h, this makes it impossible to use -Wcast-qual in such code.

The problem is the change c5cb077ab3c88394b7ac8ed4e746bd31b53e39f1, which replaced ob->ob_type by Py_TYPE(ob), which seems reasonable by itself, but Py_TYPE casts away the const, so it creates this problem.

This is a regression in Python 3.10.

----------
components: Interpreter Core
messages: 388167
nosy: petere
priority: normal
severity: normal
status: open
title: object.h -Wcast-qual warning
versions: Python 3.10

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

From report at bugs.python.org  Fri Mar  5 17:13:24 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 05 Mar 2021 22:13:24 +0000
Subject: [issue43332] Make http.client._tunnel send one byte string over the
 network
In-Reply-To: <1614370680.1.0.103129903648.issue43332@roundup.psfhosted.org>
Message-ID: <1614982404.13.0.552837667384.issue43332@roundup.psfhosted.org>


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

FYI another common socket idiom for this, specifically added for use in old HTTP 1.x servers building up responses, is setting and clearing the TCP_CORK (Linux) or TCP_NOPUSH (FreeBSD, and maybe macos? [buggy?]) socket option before and after the set of send()s you want to be optimally buffered into packets.

A more modern approach (often used with TCP_CORK) is not to build up a single buffer at all.  Instead use writev().  os.writev() exists in Python these days.  It limits userspace data shuffling in the normal case of everything getting written.

Unfortunately... this old http client code and API isn't really setup for that.  Everything is required to go through the HTTPConnection.send method.  And the send method is not defined to take a list of bytes objects as writev() would require.  

So for this code, the patch we want is just the joined bytes or BytesIO. It is the simple better change that works everywhere without getting into platform specific idioms.

For modern best practices I'd look to the async frameworks instead of this older library.

----------

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

From report at bugs.python.org  Fri Mar  5 17:19:41 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 05 Mar 2021 22:19:41 +0000
Subject: [issue43355] __future__.annotations breaks inspect.signature()
In-Reply-To: <1614614520.28.0.353733927276.issue43355@roundup.psfhosted.org>
Message-ID: <1614982781.73.0.443985101403.issue43355@roundup.psfhosted.org>


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

3.7 only gets security fixes

----------
nosy: +terry.reedy
versions:  -Python 3.7

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

From report at bugs.python.org  Fri Mar  5 17:30:57 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 05 Mar 2021 22:30:57 +0000
Subject: [issue43359] Dead assignment in Py_UniversalNewlineFgets
In-Reply-To: <1614651387.39.0.0295195640102.issue43359@roundup.psfhosted.org>
Message-ID: <1614983457.23.0.514919496772.issue43359@roundup.psfhosted.org>


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

Victor and/or Serhiy: This and #43360 and #43361 are similar 1-line changes, suggested by scan-build, to eliminate dead or duplicate initializations in C code.  Can either of you either handle these or suggest someone else?  Would we have preferred 1 issue and PR?  Do we backport such changes?

All 3 diffs have a bunch of github beta check annotation warnings for an otherwise unchanged C file.  Fix?  Suppress somehow?

----------
nosy: +serhiy.storchaka, terry.reedy, vstinner

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

From report at bugs.python.org  Fri Mar  5 17:43:20 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 05 Mar 2021 22:43:20 +0000
Subject: [issue43365] Operation conflict between time package and file in
 python 3.8 3.9
In-Reply-To: <1614682163.99.0.9936995249.issue43365@roundup.psfhosted.org>
Message-ID: <1614984200.1.0.305434400945.issue43365@roundup.psfhosted.org>


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


----------
Removed message: https://bugs.python.org/msg387907

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

From report at bugs.python.org  Fri Mar  5 17:43:29 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 05 Mar 2021 22:43:29 +0000
Subject: [issue43365] Operation conflict between time package and file in
 python 3.8 3.9
In-Reply-To: <1614682265.1.0.879800153503.issue43365@roundup.psfhosted.org>
Message-ID: <1614984209.06.0.120251513547.issue43365@roundup.psfhosted.org>


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


----------
Removed message: https://bugs.python.org/msg387908

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

From report at bugs.python.org  Fri Mar  5 17:56:17 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 05 Mar 2021 22:56:17 +0000
Subject: [issue43365] Operation conflict between time package and file
In-Reply-To: <1614682265.1.0.879800153503.issue43365@roundup.psfhosted.org>
Message-ID: <1614984977.64.0.262962983547.issue43365@roundup.psfhosted.org>


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

I unlinked the preliminary versions of the code minimized in the 3 post.

The posted code is buggy: it opens a file and then start an infinite loop.  It has to be interrupted someway, and the file may not be properly closed and flushed to disk.  When I make the loop finite and explicitly close the file, or even better, use a 'with' statement, the file is written as expected.  At least on Windows, it runs noticeably slower with the sleep because the minimum sleep is 1/16 second.

Minaki, if you find a problem with unbuggy code, you can post and reopen.  If you are a beginner who does not know about things like closing file, flushing to disk, and the with statement, you should post to a question and answer forum such as python-list and ask 'Is Python or my code buggy?'

----------
nosy: +terry.reedy
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
title: Operation conflict between time package and file in python 3.8 3.9 -> Operation conflict between time package and file
versions: +Python 3.10 -Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Mar  5 18:47:26 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 05 Mar 2021 23:47:26 +0000
Subject: [issue43410] Parser does not handle correctly some errors when parsin
 from stdin
In-Reply-To: <1614964955.39.0.913568985121.issue43410@roundup.psfhosted.org>
Message-ID: <1614988046.96.0.372977526576.issue43410@roundup.psfhosted.org>


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

I modified PR 24763 to implement this idea.

----------

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

From report at bugs.python.org  Fri Mar  5 19:13:14 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 06 Mar 2021 00:13:14 +0000
Subject: [issue24890] Windows launcher docs don't fully explain shebang
 semantics
In-Reply-To: <1439932466.21.0.43365988759.issue24890@psf.upfronthosting.co.za>
Message-ID: <1614989594.43.0.566560773511.issue24890@roundup.psfhosted.org>


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

In summary, the launcher documentation needs to be extended as follows:

    * Include an example of a shebang with a normal Windows path:

      #!"C:\Program Files\Python310\python.exe"

      Highlight the importance of quoting paths that contain spaces.
      Also, quoting ensures a real filesystem path will never
      mistakenly match a virtual command. 

      Due to questionable design in the launcher, it will still try 
      searching [1] for part of the name up to the first space, such
      as "C:\Program", but, presuming the path is quoted, the search
      will at least never succeed since double quotes are not
      allowed in filenames.

    * Show how to define custom commands in py.ini:

      [commands]
      pypy3=C:\pypy3.7\pypy3.exe

      The launcher is limited to 100 commands since it uses a hard-
      coded array size.

      Note that regular CLI commands take precedence. In other words,
      if a command name is found in the standard search path [1], then
      the search result is used instead of the value defined in py.ini.

      This is buggy behavior that should be fixed. When reading py.ini, 
      it should not search for the command. The find_command() function
      needs a `search` parameter to support this. If it's false, 
      find_command() should only check its `commands` array.

    * Explain that the Unix path prefixes "/usr/bin/env ", 
      "/usr/bin/", and "/usr/local/bin/" are ignored when matching
      a command name -- except for the already documented case of
      "/usr/bin/env python" (without a version spec).

      Except for reserved "python" commands, currently any command
      name will be searched for [1], with or without the
      "/usr/bin/env " prefix. For example:
     
      #!name

      The launcher will search for "name.COM", "name.EXE",
      "name.BAT", and so on.

      This is buggy behavior that should be fixed. The skip-prefix 
      feature needs to be smarter. The launcher should only search
      the filesystem for commands that use the "/usr/bin/env "
      prefix. The find_command() function needs a `search`
      parameter to support this, as mentioned above.


Bugs mentioned in this message need a separate issue. I don't know to what extent questionable behavior should be documented, with warnings about security and misbehavior. In practice it seems that most users limit themselves to a restricted subset of the launcher's capabilities, and never stray from the well-worn path. So I don't want to needlessly scare or worry people. But the buggy behavior SHOULD be taken seriously and fixed.

---

[1] The launcher uses the system's default non-safe search path
    for data files. It should enable the safe search via

    SetSearchPathMode(BASE_SEARCH_PATH_ENABLE_SAFE_SEARCHMODE)

    The non-safe search path includes the application directory
    (of the launcher); the current directory; the System32,
    System and Windows directories (unsafe because they're after
    the current directory); and the directories in the PATH
    environment variable.

    If there's no "." in the name, the launcher tries searching 
    for the name plus each extension that's listed in the PATHEXT 
    environment variable. To search for a filename that has no
    extension, add a trailing dot to the command name, e.g.
    "spam.".

----------
type: behavior -> enhancement
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Mar  5 19:43:53 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 06 Mar 2021 00:43:53 +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: <1614991433.46.0.0299583371152.issue43366@roundup.psfhosted.org>


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

#43163 was about the opposite problem of raising SyntaxError too soon, when a valid continuation to imcomplete code is possible.  As with that issue, IDLE has the same problem, which is not in code.interact() itself but in codeop._maybe_compile.. 

Calling compile with, gives message, resulting in user seeing
'[def'                unclosed [      
'[def\n'              bad syntax     Syntax Error
'[\ndef'              unclosed [
'[\ndef\n'            unclosed [     prompt for more input

In the last line, the added \n after [ changes the compile SyntaxError message and, after PR 24483 for #43163, results in fruitlessly waiting for non-existent correct input until the user enters garbage or hits ^C. This is at best a codeop-specific regression from better behavior in 3.9

Changing 'def' to 'def f():' only changes the first message to 'invalid syntax' but not the user-visible result.

As near as I can tell, compile('[\n1,', ...) and compile('[\ndef', ...) give the same unclosed message pointing to the opening [.  How does the regular REPL know to prompt for input for the first and raise SyntaxError for the second?  Some unobvious flag combination?  (It is not 'exec' versus 'single'.)

>>> [
... 1,
... def
  File "<stdin>", line 3
    def
    ^
SyntaxError: invalid syntax

Guido, do you have any idea how python decides this or where the code is or who might know better?

----------
nosy: +gvanrossum, terry.reedy

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

From report at bugs.python.org  Fri Mar  5 19:48:07 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 06 Mar 2021 00:48:07 +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: <1614991687.45.0.362650372066.issue43366@roundup.psfhosted.org>


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

This is a change I implemented and is explicitly deactivated in the reprl:

https://github.com/python/cpython/blob/master/Parser/pegen.c#L1191

The problem here is that when you call compile() there is no way to know if you are doing it to simulate a reprl() or not.

----------

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

From report at bugs.python.org  Fri Mar  5 19:50:58 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 06 Mar 2021 00:50:58 +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: <1614991858.08.0.71266686859.issue43366@roundup.psfhosted.org>


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

Maybe we need to add an API (e.g. a flag to compile()) so that we can ask the actual parser the question we're interested in, rather than having to use hacks and heuristics?

----------

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

From report at bugs.python.org  Fri Mar  5 19:51:29 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 06 Mar 2021 00:51:29 +0000
Subject: [issue43374] Apple refuses apps written in Python
In-Reply-To: <1614708610.18.0.213124723322.issue43374@roundup.psfhosted.org>
Message-ID: <1614991889.47.0.940750587039.issue43374@roundup.psfhosted.org>


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

Adrian, when responding by email, please delete the copy of the email you are responding to, except maybe a line or two, as it is redundant when posted on the web page.

Have you tried forums where there might be other Apple app developers with similar issues?

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Fri Mar  5 19:53:39 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 06 Mar 2021 00:53: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: <1614992019.01.0.137740876226.issue43366@roundup.psfhosted.org>


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

> Maybe we need to add an API (e.g. a flag to compile()) so that we can ask the actual parser the question we're interested in, rather than having to use hacks and heuristics?

I was thinking about that, but we need to fix some inconsistencies along the way first. I am currently already doing that work (starting with https://github.com/python/cpython/pull/24763) and once that is fixed we can pass that down with some flags to the compiler.

----------

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

From report at bugs.python.org  Fri Mar  5 20:02:47 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 06 Mar 2021 01:02:47 +0000
Subject: [issue43379] Pasting multiple lines in the REPL is broken since 3.9
In-Reply-To: <1614721536.12.0.538890122544.issue43379@roundup.psfhosted.org>
Message-ID: <1614992567.43.0.39262197954.issue43379@roundup.psfhosted.org>


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

On both Windows and macOS Mohave with both 3.9 and 3.10 I get normal behavior.

If it were not for the $ python3.x line, the missing '... ' in Romain's output would have suggested that he was using IDLE.  But IDLE should accept pasted ascii statements just fine.

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Fri Mar  5 20:04:07 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 06 Mar 2021 01:04:07 +0000
Subject: [issue43387] Enable pydoc to run as background job
In-Reply-To: <1614778462.01.0.596151563335.issue43387@roundup.psfhosted.org>
Message-ID: <1614992647.96.0.644253254528.issue43387@roundup.psfhosted.org>


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


----------
stage:  -> test needed
type: behavior -> enhancement
versions:  -Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Mar  5 20:22:33 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 06 Mar 2021 01:22:33 +0000
Subject: [issue43407] time.monotonic(): Docs imply comparing call N and call
 N+M is invalid for M>1
In-Reply-To: <1614896470.36.0.766208602401.issue43407@roundup.psfhosted.org>
Message-ID: <1614993753.44.0.101842186128.issue43407@roundup.psfhosted.org>


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


New changeset ff5f05934db241dfafc604989b2de3487b09ca82 by Alex Willmer in branch 'master':
bpo-43407: Clarify comparisons of time.monotonic() et al results (GH-24757)
https://github.com/python/cpython/commit/ff5f05934db241dfafc604989b2de3487b09ca82


----------
nosy: +terry.reedy

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

From report at bugs.python.org  Fri Mar  5 20:22:32 2021
From: report at bugs.python.org (miss-islington)
Date: Sat, 06 Mar 2021 01:22:32 +0000
Subject: [issue43407] time.monotonic(): Docs imply comparing call N and call
 N+M is invalid for M>1
In-Reply-To: <1614896470.36.0.766208602401.issue43407@roundup.psfhosted.org>
Message-ID: <1614993752.33.0.919397352022.issue43407@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: +23536
pull_request: https://github.com/python/cpython/pull/24768

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

From report at bugs.python.org  Fri Mar  5 20:23:22 2021
From: report at bugs.python.org (miss-islington)
Date: Sat, 06 Mar 2021 01:23:22 +0000
Subject: [issue43407] time.monotonic(): Docs imply comparing call N and call
 N+M is invalid for M>1
In-Reply-To: <1614896470.36.0.766208602401.issue43407@roundup.psfhosted.org>
Message-ID: <1614993802.93.0.454149642296.issue43407@roundup.psfhosted.org>


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


----------
pull_requests: +23537
pull_request: https://github.com/python/cpython/pull/24769

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

From report at bugs.python.org  Fri Mar  5 20:24:08 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 06 Mar 2021 01:24:08 +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: <1614993848.56.0.788410734501.issue43366@roundup.psfhosted.org>


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

In any case, the underlying problem here is the fact that codeop is deciding to continue asking for input of not depending on the repr() of the syntax error exception itself, which is the major hack here.

Previously, it worked because for unclosed parens the parser was throwing different line numbers for the end of file as codeop keeps adding new lines, but now all these points to the same unclosed paren.

----------

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

From report at bugs.python.org  Fri Mar  5 20:34:34 2021
From: report at bugs.python.org (miss-islington)
Date: Sat, 06 Mar 2021 01:34:34 +0000
Subject: [issue43407] time.monotonic(): Docs imply comparing call N and call
 N+M is invalid for M>1
In-Reply-To: <1614896470.36.0.766208602401.issue43407@roundup.psfhosted.org>
Message-ID: <1614994474.24.0.380191151815.issue43407@roundup.psfhosted.org>


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


New changeset e12a9e2f62bea8ddc755e373f17adfbb2740b0b1 by Miss Islington (bot) in branch '3.8':
bpo-43407: Clarify comparisons of time.monotonic() et al results (GH-24757)
https://github.com/python/cpython/commit/e12a9e2f62bea8ddc755e373f17adfbb2740b0b1


----------

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

From report at bugs.python.org  Fri Mar  5 20:37:11 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 06 Mar 2021 01:37:11 +0000
Subject: [issue43413] tuple subclasses allow kwargs
Message-ID: <1614994631.23.0.248202692536.issue43413@roundup.psfhosted.org>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

While troubleshooting a strange problem (https://github.com/jaraco/keyring/issues/498) where a program worked on Python 3.7+ but failed on Python 3.6, I discovered a somewhat unintuitive behavior. On Python 3.7+, keyword arguments to tuple subclasses are allowed and ignored:

>>> class Foo(tuple): pass
>>> tuple(name='xyz')
TypeError: tuple() takes no keyword arguments
>>> Foo(name='xyz')
()

But on Python 3.6, the keyword parameter causes an error:

$ python3.6 -c "type('Foo', (tuple,), {})(name='xyz')"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: 'name' is an invalid keyword argument for this function

I checked out the What's new in Python 3.7 and I see this notice:

Functions bool(), float(), list() and tuple() no longer take keyword arguments. The first argument of int() can now be passed only as positional argument.

Hmm, but in my experience, tuple on Python 3.6 doesn't take keyword arguments either:

importlib_metadata main $ python3.6 -c "tuple(name='xyz')"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: 'name' is an invalid keyword argument for this function


So that change may be related, but I'm not sure where or how.

The main place my expectation is violated is in the subclass. Why should a subclass of tuple allow keyword arguments when the parent class does not? I'd expect that the subclass should reject keyword arguments as well.

Less importantly, the What's New doc implies that keyword arguments were accepted in Python 3.6; why aren't they?

----------
components: Interpreter Core
keywords: 3.7regression
messages: 388183
nosy: jaraco
priority: normal
severity: normal
status: open
title: tuple subclasses allow kwargs
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Mar  5 20:38:40 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 06 Mar 2021 01:38:40 +0000
Subject: [issue43413] tuple subclasses allow kwargs
In-Reply-To: <1614994631.23.0.248202692536.issue43413@roundup.psfhosted.org>
Message-ID: <1614994720.51.0.636759979708.issue43413@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

To be abundantly clear, the downstream issue was a coding error, but the coding error was masked on Python 3.7+ when the subclass didn't reject the invalid usage.

----------

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

From report at bugs.python.org  Fri Mar  5 20:48:41 2021
From: report at bugs.python.org (miss-islington)
Date: Sat, 06 Mar 2021 01:48:41 +0000
Subject: [issue43407] time.monotonic(): Docs imply comparing call N and call
 N+M is invalid for M>1
In-Reply-To: <1614896470.36.0.766208602401.issue43407@roundup.psfhosted.org>
Message-ID: <1614995321.51.0.290913494381.issue43407@roundup.psfhosted.org>


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


New changeset 65f3a0d20c8198443c5c6cb44410114fe8c4bf4e by Miss Islington (bot) in branch '3.9':
bpo-43407: Clarify comparisons of time.monotonic() et al results (GH-24757)
https://github.com/python/cpython/commit/65f3a0d20c8198443c5c6cb44410114fe8c4bf4e


----------

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

From report at bugs.python.org  Fri Mar  5 20:53:35 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 06 Mar 2021 01:53:35 +0000
Subject: [issue43407] time.monotonic(): Docs imply comparing call N and call
 N+M is invalid for M>1
In-Reply-To: <1614896470.36.0.766208602401.issue43407@roundup.psfhosted.org>
Message-ID: <1614995615.25.0.861346214614.issue43407@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.6, Python 3.7

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

From report at bugs.python.org  Fri Mar  5 20:56:53 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 06 Mar 2021 01:56:53 +0000
Subject: [issue43413] tuple subclasses allow kwargs
In-Reply-To: <1614994631.23.0.248202692536.issue43413@roundup.psfhosted.org>
Message-ID: <1614995813.26.0.411290578532.issue43413@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I see that changelog entry traces back to bpo-29695, but I don't believe it's relevant to this issue.

----------

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

From report at bugs.python.org  Fri Mar  5 20:58:09 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 06 Mar 2021 01:58:09 +0000
Subject: [issue43414] os.get_terminal_size() should use file descriptors in
 Windows
Message-ID: <1614995889.38.0.729191122852.issue43414@roundup.psfhosted.org>


New submission from Eryk Sun <eryksun at gmail.com>:

Currently os.get_terminal_size() is hard coded to use the process standard handles in Windows. The function, however, is intended for arbitrary file descriptors, so should not be limited as follows:

    >>> f = open('conout$', 'w')
    >>> os.get_terminal_size(f.fileno())
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    ValueError: bad file descriptor

This is a simple fix. Rewrite it to use _get_osfhandle(). For example:

#ifdef TERMSIZE_USE_CONIO
    {
        HANDLE handle;
        CONSOLE_SCREEN_BUFFER_INFO csbi;

        _Py_BEGIN_SUPPRESS_IPH
        handle = (HANDLE)_get_osfhandle(fd);
        _Py_END_SUPPRESS_IPH
        if (handle == INVALID_HANDLE_VALUE)
            return PyErr_SetFromErrno(PyExc_OSError);

        if (!GetConsoleScreenBufferInfo(handle, &csbi))
            return PyErr_SetFromWindowsErr(0);

        columns = csbi.srWindow.Right - csbi.srWindow.Left + 1;
        lines = csbi.srWindow.Bottom - csbi.srWindow.Top + 1;
    }
#endif /* TERMSIZE_USE_CONIO */

----------
components: Extension Modules, Windows
keywords: easy (C)
messages: 388187
nosy: eryksun, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: os.get_terminal_size() should use file descriptors in Windows
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Mar  5 21:08:20 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 06 Mar 2021 02:08:20 +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: <1614996500.53.0.112884177926.issue43366@roundup.psfhosted.org>


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

Add compile(..., mode='repl')?
"If mode is 'repl', compile returns None to indicate that the code is incomplete as is but might become valid if more lines (or maybe just more code) were added"

Deprecate _maybe_compile (and stop trying to patch it).

----------

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

From report at bugs.python.org  Fri Mar  5 21:11:42 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 06 Mar 2021 02:11:42 +0000
Subject: [issue43413] tuple subclasses allow kwargs
In-Reply-To: <1614994631.23.0.248202692536.issue43413@roundup.psfhosted.org>
Message-ID: <1614996702.28.0.210331819144.issue43413@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I suspect bpo-20186 is implicated.

----------

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

From report at bugs.python.org  Fri Mar  5 21:14:31 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 06 Mar 2021 02:14:31 +0000
Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23
 files
In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za>
Message-ID: <1614996871.34.0.751326643978.issue20186@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I suspect change in this issue led to issue43413.

----------
nosy: +jaraco

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

From report at bugs.python.org  Fri Mar  5 21:17:00 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 06 Mar 2021 02:17:00 +0000
Subject: [issue43413] tuple subclasses allow kwargs
In-Reply-To: <1614994631.23.0.248202692536.issue43413@roundup.psfhosted.org>
Message-ID: <1614997020.72.0.726229854618.issue43413@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

In particular, [this commit](https://github.com/python/cpython/commit/0b5615926a573c19c887a701a2f7047f4fd06de6).

----------

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

From report at bugs.python.org  Fri Mar  5 21:46:14 2021
From: report at bugs.python.org (Adrian)
Date: Sat, 06 Mar 2021 02:46:14 +0000
Subject: [issue43374] Apple refuses apps written in Python
In-Reply-To: <1614991889.47.0.940750587039.issue43374@roundup.psfhosted.org>
Message-ID: <5DFE50E7-844C-4778-8F0C-47413E4359CC@ag-projects.com>


Adrian <ag at ag-projects.com> added the comment:

Terry,

After opening issues on this and other mailing lists (PyObjc) Apple validated our app without a comment.  

Adrian

> On 5 Mar 2021, at 21:51, Terry J. Reedy <report at bugs.python.org> wrote:
> 
> 
> Terry J. Reedy <tjreedy at udel.edu> added the comment:
> 
> Adrian, when responding by email, please delete the copy of the email you are responding to, except maybe a line or two, as it is redundant when posted on the web page.

----------

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

From report at bugs.python.org  Fri Mar  5 21:46:24 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 06 Mar 2021 02:46:24 +0000
Subject: [issue43413] tuple subclasses allow kwargs
In-Reply-To: <1614994631.23.0.248202692536.issue43413@roundup.psfhosted.org>
Message-ID: <1614998784.26.0.039720579899.issue43413@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Fri Mar  5 22:24:59 2021
From: report at bugs.python.org (Ned Deily)
Date: Sat, 06 Mar 2021 03:24:59 +0000
Subject: [issue43374] Apple refuses apps written in Python
In-Reply-To: <1614708610.18.0.213124723322.issue43374@roundup.psfhosted.org>
Message-ID: <1615001099.87.0.192047070739.issue43374@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Fri Mar  5 22:29:32 2021
From: report at bugs.python.org (Andrei Kulakov)
Date: Sat, 06 Mar 2021 03:29:32 +0000
Subject: [issue43415] Typo
Message-ID: <1615001372.2.0.966613332718.issue43415@roundup.psfhosted.org>


New submission from Andrei Kulakov <andrei.avk at gmail.com>:

Typo (explicit|ly) in library/dataclasses.rst:139:

139:     If :meth:`__hash__` is not explicit defined, or if it is set to ``None``,

----------
assignee: docs at python
components: Documentation
messages: 388193
nosy: andrei.avk, docs at python
priority: normal
severity: normal
status: open
title: Typo
versions: Python 3.10

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

From report at bugs.python.org  Fri Mar  5 22:50:20 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 06 Mar 2021 03:50:20 +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: <1615002620.01.0.20585126487.issue43366@roundup.psfhosted.org>


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

> "If mode is 'repl', compile returns None to indicate that the code is incomplete as is but might become valid if more lines (or maybe just more code) were added"

That would be ideal, but my guess is that is not trivial because even if you can intercept the tokenizer when it fetches new lines from the source, you need to correctly propagate that information through several tokenized layers and the parser trying to backtrack.

If someone manages to do that, that would be the cleanest solution.

----------

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

From report at bugs.python.org  Fri Mar  5 22:54:54 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 06 Mar 2021 03:54:54 +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: <1615002894.75.0.39787624687.issue43366@roundup.psfhosted.org>


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


----------
nosy: +lys.nikolaou

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

From report at bugs.python.org  Fri Mar  5 22:57:46 2021
From: report at bugs.python.org (Mariatta)
Date: Sat, 06 Mar 2021 03:57:46 +0000
Subject: [issue43415] Typo
In-Reply-To: <1615001372.2.0.966613332718.issue43415@roundup.psfhosted.org>
Message-ID: <1615003066.04.0.272096633097.issue43415@roundup.psfhosted.org>


Change by Mariatta <mariatta at python.org>:


----------
keywords: +easy, newcomer friendly

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

From report at bugs.python.org  Sat Mar  6 00:42:14 2021
From: report at bugs.python.org (Nicholas Sim)
Date: Sat, 06 Mar 2021 05:42:14 +0000
Subject: [issue35134] Add a new Include/cpython/ subdirectory for the "CPython
 API" with implementation details
In-Reply-To: <1541076409.33.0.788709270274.issue35134@psf.upfronthosting.co.za>
Message-ID: <1615009334.8.0.352302284721.issue35134@roundup.psfhosted.org>


Change by Nicholas Sim <nsim at posteo.net>:


----------
pull_requests: +23538
pull_request: https://github.com/python/cpython/pull/24770

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

From report at bugs.python.org  Sat Mar  6 01:22:10 2021
From: report at bugs.python.org (Alexey Volkov)
Date: Sat, 06 Mar 2021 06:22:10 +0000
Subject: [issue35118] Add peek() or first() method in queue
In-Reply-To: <1540956018.19.0.788709270274.issue35118@psf.upfronthosting.co.za>
Message-ID: <1615011730.49.0.317510218534.issue35118@roundup.psfhosted.org>


Alexey Volkov <alexey.volkov at ark-kun.com> added the comment:

>For Queue, I'm not sure I've ever seen any use case for peek.  What do you have in mind?

I want to examine the first (oldest) element in queue and remove it if it's too old.

The queue should not be modified unless the oldest element is too old.

----------
nosy: +Ark-kun

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

From report at bugs.python.org  Sat Mar  6 03:44:25 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 06 Mar 2021 08:44:25 +0000
Subject: [issue43416] Add README files in Include/cpython and Include/internal
Message-ID: <1615020265.58.0.71326223935.issue43416@roundup.psfhosted.org>


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

I always hesitate in what subdirectory of Include/ to add a declaration of new private API. What is more "private"? It would be nice to add README files in these directories which describe what API should be declared here and what is the difference between Include/cpython and Include/internal.

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 388196
nosy: docs at python, serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: Add README files in Include/cpython and Include/internal
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Sat Mar  6 05:52:10 2021
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 06 Mar 2021 10:52:10 +0000
Subject: [issue42128] Structural Pattern Matching (PEP 634)
In-Reply-To: <1603466540.96.0.7677855399.issue42128@roundup.psfhosted.org>
Message-ID: <1615027930.34.0.237717708269.issue42128@roundup.psfhosted.org>


Change by Batuhan Taskaya <isidentical at gmail.com>:


----------
pull_requests: +23539
pull_request: https://github.com/python/cpython/pull/24771

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

From report at bugs.python.org  Sat Mar  6 05:57:53 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 06 Mar 2021 10:57:53 +0000
Subject: [issue43415] Typo
In-Reply-To: <1615001372.2.0.966613332718.issue43415@roundup.psfhosted.org>
Message-ID: <1615028273.09.0.066372902569.issue43415@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Sat Mar  6 06:55:57 2021
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 06 Mar 2021 11:55:57 +0000
Subject: [issue43417] ast.unparse: Simplify buffering logic
Message-ID: <1615031757.71.0.0216210718913.issue43417@roundup.psfhosted.org>


New submission from Batuhan Taskaya <isidentical at gmail.com>:

Currently, buffer is just an instance-level list that is used in various places to avoid directly writing stuff into the real source buffer, though the design is pretty complicated and hard to use.

There are various use cases (like omitting the empty space when unparsing argument-less lambdas, e.g: lambda : 2 + 2) we could've use this buffer system if it was offering a stackable version (like multiple levels of buffers).

What I think is we should probably do this with a proper context manager and in the context capture all writings into a list where we would return after the context is closed;

with self.buffered() as buffer:
    self._write_fstring_inner(node)
return self._write_str_avoiding_backslashes("".join(buffer))

----------
assignee: BTaskaya
components: Library (Lib)
messages: 388197
nosy: BTaskaya
priority: normal
severity: normal
status: open
title: ast.unparse: Simplify buffering logic
versions: Python 3.10

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

From report at bugs.python.org  Sat Mar  6 06:59:18 2021
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 06 Mar 2021 11:59:18 +0000
Subject: [issue43417] ast.unparse: Simplify buffering logic
In-Reply-To: <1615031757.71.0.0216210718913.issue43417@roundup.psfhosted.org>
Message-ID: <1615031958.06.0.186244941295.issue43417@roundup.psfhosted.org>


Change by Batuhan Taskaya <isidentical at gmail.com>:


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

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

From report at bugs.python.org  Sat Mar  6 07:24:04 2021
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 06 Mar 2021 12:24:04 +0000
Subject: [issue43391] The comments have invalid license information (broken
 Python 2.4 URL for Python 3)
In-Reply-To: <1614801590.99.0.0824232667755.issue43391@roundup.psfhosted.org>
Message-ID: <1615033444.3.0.222853329037.issue43391@roundup.psfhosted.org>


Change by Marc-Andre Lemburg <mal at egenix.com>:


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

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

From report at bugs.python.org  Sat Mar  6 08:33:26 2021
From: report at bugs.python.org (Hugo Chia)
Date: Sat, 06 Mar 2021 13:33:26 +0000
Subject: [issue43418] FTPLib module crashes when server returns byte message
 instead of string
Message-ID: <1615037606.06.0.879407636626.issue43418@roundup.psfhosted.org>


New submission from Hugo Chia <hugochiaxyz8 at gmail.com>:

https://github.com/cowrie/cowrie/issues/1394

https://github.com/cowrie/cowrie/pull/1396

Above are some of the links mentioning the issue with the FTPLib module. It happens when the FTP server returns a byte message instead of a string. Ftplib expects a string and does not account for receiving a byte message

----------
components: Library (Lib)
messages: 388198
nosy: hugochiaxyz8
priority: normal
severity: normal
status: open
title: FTPLib module crashes when server returns byte message instead of string
type: crash
versions: Python 3.7

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

From report at bugs.python.org  Sat Mar  6 09:09:53 2021
From: report at bugs.python.org (Lanfon)
Date: Sat, 06 Mar 2021 14:09:53 +0000
Subject: [issue43419] contextvars does not work properly in asyncio REPL.
Message-ID: <1615039793.26.0.615166791283.issue43419@roundup.psfhosted.org>


New submission from Lanfon <lanfon72 at gmail.com>:

Demonstration (via python -m asyncio):

asyncio REPL 3.9.0 (default, Oct 18 2020, 00:21:26) 
[Clang 11.0.0 (clang-1100.0.33.16)] on darwin
Use "await" directly instead of "asyncio.run()".
Type "help", "copyright", "credits" or "license" for more information.
>>> import asyncio
>>> from contextvars import ContextVar
>>> ctx = ContextVar('ctx')
>>> ctx.set(1)
<Token var=<ContextVar name='ctx' at 0x1021bbc70> at 0x1021bf800>
>>> ctx.get()
Traceback (most recent call last):
  File "/Users/lanfon/.pyenv/versions/3.9.0/lib/python3.9/concurrent/futures/_base.py", line 440, in result
    return self.__get_result()
  File "/Users/lanfon/.pyenv/versions/3.9.0/lib/python3.9/concurrent/futures/_base.py", line 389, in __get_result
    raise self._exception
  File "/Users/lanfon/.pyenv/versions/3.9.0/lib/python3.9/asyncio/__main__.py", line 34, in callback
    coro = func()
  File "<console>", line 1, in <module>
LookupError: <ContextVar name='ctx' at 0x1021bbc70>
>>> exit()


It also got problem inside the functions when the context is referenced in global scope.

----------
components: asyncio
messages: 388199
nosy: asvetlov, lanfon72, yselivanov
priority: normal
severity: normal
status: open
title: contextvars does not work properly in asyncio REPL.
type: behavior
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Mar  6 09:18:17 2021
From: report at bugs.python.org (Sergey B Kirpichev)
Date: Sat, 06 Mar 2021 14:18:17 +0000
Subject: [issue43420] Optimize rational arithmetics
Message-ID: <1615040297.73.0.541090358152.issue43420@roundup.psfhosted.org>


New submission from Sergey B Kirpichev <skirpichev at gmail.com>:

fractions.py uses naive algorithms for doing arithmetics.

It may worth implementing less trivial versions for addtion/substraction
and multiplication (e.g. Henrici algorithm and so on), described here:
https://www.eecis.udel.edu/~saunders/courses/822/98f/collins-notes/rnarith.ps
as e.g gmplib does: https://gmplib.org/repo/gmp/file/tip/mpq/aors.c

Some projects (e.g. SymPy here: https://github.com/sympy/sympy/pull/12656) reinvent
the stdlib's Fraction just to add such simple improvements.  With big denominators (~10**6)
this really does matter, my local benchmarks suggest the order of magnitude difference for
summation of several such numbers.

----------
components: Library (Lib)
messages: 388200
nosy: Sergey.Kirpichev
priority: normal
severity: normal
status: open
title: Optimize rational arithmetics
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Sat Mar  6 10:04:20 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 06 Mar 2021 15:04:20 +0000
Subject: [issue43421] os.device_encoding(fd) should support any console fd in
 Windows
Message-ID: <1615043060.58.0.743954048014.issue43421@roundup.psfhosted.org>


New submission from Eryk Sun <eryksun at gmail.com>:

In Windows, os.device_encoding() is hard coded to map file descriptor 0 and descriptors 1 and 2 respectively to the console's input and output code page if isatty(fd) is true. But isatty() is true for any character device, such as "NUL". Also any fd might be a console, by way of dup(), dup2() -- or open() with the device names "CON", "CONIN$", and "CONOUT$".

The correct device encoding of a console file is needed for use with os.read() and os.write(). It's also necessary for io.TextIOWrapper() if PYTHONLEGACYWINDOWSSTDIO is set.

_Py_device_encoding() in Python/fileutils.c should use _get_osfhandle() to get the OS handle, and, if it's a character-device file, determine the code page to return, if any, depending on whether it's an input or output console file. For example:

PyObject *
_Py_device_encoding(int fd)
{
#if defined(MS_WINDOWS)
    HANDLE handle;
    DWORD temp;
    UINT cp = 0;

    _Py_BEGIN_SUPPRESS_IPH
        handle = (HANDLE)_get_osfhandle(fd);
    _Py_END_SUPPRESS_IPH
    if (handle == INVALID_HANDLE_VALUE ||
            GetFileType(handle) != FILE_TYPE_CHAR)
        Py_RETURN_NONE;

    Py_BEGIN_ALLOW_THREADS
    /* GetConsoleMode requires a console handle. */
    if (!GetConsoleMode(handle, &temp)) {
        /* Assume access denied implies output. */
        if (GetLastError() == ERROR_ACCESS_DENIED)
            cp = GetConsoleOutputCP();
    } else {
        if (GetNumberOfConsoleInputEvents(handle, &temp)) {
            cp = GetConsoleCP();
        } else {
            cp = GetConsoleOutputCP();
        }
    }
    Py_END_ALLOW_THREADS

    if (cp == CP_UTF8) {
        return PyUnicode_FromString("UTF-8");
    } else if (cp != 0) {
        return PyUnicode_FromFormat("cp%u", (unsigned int)cp);
    } else {
        Py_RETURN_NONE;
    }
#else
    if (isatty(fd)) {
        return _Py_GetLocaleEncodingObject();
    } else {
        Py_RETURN_NONE;
    }
#endif  /* defined(MS_WINDOWS) */
}

----------
components: Extension Modules, IO, Interpreter Core, Windows
messages: 388201
nosy: eryksun, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: os.device_encoding(fd) should support any console fd in Windows
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Mar  6 10:06:01 2021
From: report at bugs.python.org (Lanfon)
Date: Sat, 06 Mar 2021 15:06:01 +0000
Subject: [issue43419] contextvars does not work properly in asyncio REPL.
In-Reply-To: <1615039793.26.0.615166791283.issue43419@roundup.psfhosted.org>
Message-ID: <1615043161.66.0.19841157788.issue43419@roundup.psfhosted.org>


Change by Lanfon <lanfon72 at gmail.com>:


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

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

From report at bugs.python.org  Sat Mar  6 10:08:04 2021
From: report at bugs.python.org (miss-islington)
Date: Sat, 06 Mar 2021 15:08:04 +0000
Subject: [issue43406] Possible race condition between signal catching and
 signal.signal
In-Reply-To: <1614893468.93.0.265748275948.issue43406@roundup.psfhosted.org>
Message-ID: <1615043284.45.0.538067696544.issue43406@roundup.psfhosted.org>


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


New changeset 4715be8a4384159e47fb09e5f3bd077734842655 by Antoine Pitrou in branch '3.8':
[3.8] bpo-43406: Fix possible race condition where ``PyErr_CheckSignals`` tries to execute a non-Python signal handler (GH-24756) (GH-24762)
https://github.com/python/cpython/commit/4715be8a4384159e47fb09e5f3bd077734842655


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43406>
_______________________________________

From report at bugs.python.org  Sat Mar  6 10:07:53 2021
From: report at bugs.python.org (miss-islington)
Date: Sat, 06 Mar 2021 15:07:53 +0000
Subject: [issue43406] Possible race condition between signal catching and
 signal.signal
In-Reply-To: <1614893468.93.0.265748275948.issue43406@roundup.psfhosted.org>
Message-ID: <1615043273.58.0.431822987603.issue43406@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1385f8355a036fd65aaf9c7e7ab48467ca922bcf by Miss Islington (bot) in branch '3.9':
[3.9] bpo-43406: Fix possible race condition where ``PyErr_CheckSignals`` tries to execute a non-Python signal handler (GH-24756) (GH-24761)
https://github.com/python/cpython/commit/1385f8355a036fd65aaf9c7e7ab48467ca922bcf


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43406>
_______________________________________

From report at bugs.python.org  Sat Mar  6 10:09:04 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 06 Mar 2021 15:09:04 +0000
Subject: [issue43406] Possible race condition between signal catching and
 signal.signal
In-Reply-To: <1614893468.93.0.265748275948.issue43406@roundup.psfhosted.org>
Message-ID: <1615043344.6.0.724113462089.issue43406@roundup.psfhosted.org>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43406>
_______________________________________

From report at bugs.python.org  Sat Mar  6 10:15:20 2021
From: report at bugs.python.org (Zveinn)
Date: Sat, 06 Mar 2021 15:15:20 +0000
Subject: [issue43332] Make http.client._tunnel send one byte string over the
 network
In-Reply-To: <1614370680.1.0.103129903648.issue43332@roundup.psfhosted.org>
Message-ID: <1615043720.89.0.288752281676.issue43332@roundup.psfhosted.org>


Zveinn <sveinn at zkynet.io> added the comment:

Hey! 

First of all, thank you for not shitting all over me <3 

I have never really used python and the only reason I found this is because I was developing a tool that accepted a LOT of CONNECT requests for python and I just happened to stumble upon this little nugget.

Regarding a PR or a local path, it would have been too much work for me since I'm already swamped and I don't know anything about python or it's ecosystem :S

Anyways, I leave this in your hands now. 

Regards, Zveinn

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43332>
_______________________________________

From report at bugs.python.org  Sat Mar  6 10:18:26 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 06 Mar 2021 15:18:26 +0000
Subject: [issue43422] Revert _decimal C API changes
Message-ID: <1615043906.44.0.566874098139.issue43422@roundup.psfhosted.org>


New submission from Antoine Pitrou <pitrou at free.fr>:

Stefan Krah (who doesn't have access rights here, and is the author of the C _decimal module) asked me to transmit me this request:
"""
The capsule API does not meet my testing standards, since I've focused
on the upstream mpdecimal in the last couple of months.

Additionally, I'd like to refine the API, perhaps together with the
Arrow community.
"""

The relevant diff is here:
https://github.com/python/cpython/compare/master...skrah:revert_decimal_capsule_api

I can turn it into a PR but first I'd like to gather reactions here.

----------
components: Extension Modules
messages: 388205
nosy: facundobatista, mark.dickinson, pitrou, rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Revert _decimal C API changes
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43422>
_______________________________________

From report at bugs.python.org  Sat Mar  6 10:20:39 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 06 Mar 2021 15:20:39 +0000
Subject: [issue41369] Update to libmpdec-2.5.1
In-Reply-To: <1595446041.62.0.150992911256.issue41369@roundup.psfhosted.org>
Message-ID: <1615044039.33.0.954003627532.issue41369@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

Stefan wrote me that the changes which complete this update are here:
https://github.com/python/cpython/compare/master...skrah:libmpdec-2.5.1

I can turn this diff into a PR but first I want to gather feedback here.  Mark, Serhiy, Raymond, what do you say?

----------
assignee: skrah -> 
nosy: +facundobatista, mark.dickinson, pitrou, rhettinger, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41369>
_______________________________________

From report at bugs.python.org  Sat Mar  6 10:24:04 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 06 Mar 2021 15:24:04 +0000
Subject: [issue43413] tuple subclasses allow kwargs
In-Reply-To: <1614994631.23.0.248202692536.issue43413@roundup.psfhosted.org>
Message-ID: <1615044244.58.0.163016843485.issue43413@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

> Hmm, but in my experience, tuple on Python 3.6 doesn't take keyword arguments either:

They do.

>>> tuple(sequence='abc')
('a', 'b', 'c')

>>> list(sequence='abc')
['a', 'b', 'c']
>>> int(x='123')
123
>>> bool(x='123')
True
>>> float(x='123')
123.0

It was changed in bpo-29695.

But accepting arbitrary keyword arguments is another issue.

Object creation in Python can be customized be implementing special methods __new__ and __init__. They both are called sequentially with arguments passed to the constructor. If object is mutable, it is enough to implement __init__. If the object contains immutable data which should be initialized at creation time, it needs __new__, and __init__ is not necessary. So the list class has __init__, but the tuple and int classes have __new__. Usually class implements only one of __new__ or __init__, and inherits the other one from parent classes.

Since positional and keyword arguments are passed to both __new__ and __init__, they should accept same arguments. If __new__ and __init__ are inherited from parent class, they cannot know about arguments supported in the other method. Therefore object's __new__ and __init__ accept and ignore all arguments (if the other method is overridden).

Implementations of __new__ for most builtin classes which accept only positional arguments accept and ignore also arbitrary keyword arguments in subclasses. It makes easier to implement a subclass with non-trivial __init__. You just add additional keyword arguments which will be ignored in __new__. It is long tradition. Example:

    if (type == &cycle_type && !_PyArg_NoKeywords("cycle()", kwds))
        return NULL;

bpo-20186 just used this idiom for tuple and several other classes. It is a feature which makes subclassing these classes easier. And with converting more classes to Argument Clinic it is now used in more and more classes.

Now, perhaps it would be more correct to test `type->tp_init == cycle_type.tp_init` or `type->tp_init != PyBaseObject_Type.tp_init` instead of `type == &cycle_type`. It will ignore keyword arguments only if __init__ is overridden. If __init__ is overridden, it is now responsible for validating arguments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43413>
_______________________________________

From report at bugs.python.org  Sat Mar  6 10:30:25 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 06 Mar 2021 15:30:25 +0000
Subject: [issue14841] os.get_terminal_size() should check stdin as a fallback
In-Reply-To: <1337275274.3.0.172049776796.issue14841@psf.upfronthosting.co.za>
Message-ID: <1615044625.54.0.359723652345.issue14841@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
components: +Extension Modules, Library (Lib)
versions: +Python 3.10, Python 3.9 -Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14841>
_______________________________________

From report at bugs.python.org  Sat Mar  6 10:34:24 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 06 Mar 2021 15:34:24 +0000
Subject: [issue30295] msvcrt SetErrorMode not documented
In-Reply-To: <1494159860.93.0.93225035242.issue30295@psf.upfronthosting.co.za>
Message-ID: <1615044864.25.0.0853121871847.issue30295@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
components: +Library (Lib)
type:  -> enhancement
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30295>
_______________________________________

From report at bugs.python.org  Sat Mar  6 10:57:14 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 06 Mar 2021 15:57:14 +0000
Subject: [issue43422] Revert _decimal C API changes
In-Reply-To: <1615043906.44.0.566874098139.issue43422@roundup.psfhosted.org>
Message-ID: <1615046234.2.0.159796932261.issue43422@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

+1 fron me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43422>
_______________________________________

From report at bugs.python.org  Sat Mar  6 11:21:56 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 06 Mar 2021 16:21:56 +0000
Subject: [issue16322] time.tzname on Python 3.3.0 for Windows is decoded by
 wrong encoding
In-Reply-To: <1351166210.69.0.0993824857313.issue16322@psf.upfronthosting.co.za>
Message-ID: <1615047716.51.0.891413941647.issue16322@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

The solution for bpo-36779 changed init_timezone() to get tzname directly from WinAPI GetTimeZoneInformation(). 

Unfortunately the implementer didn't think to also support time.tzset(), so the value may be stale with no way to refresh it, or possibly different from what time.strftime('%Z') returns, depending on when ucrt looks up the timezone. For example, start Python and import time. Then change the time zone and call time.strftime('%Z'). The value will be different from time.tzname.

----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> time.tzname returns empty string on Windows if default codepage is a Unicode codepage

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16322>
_______________________________________

From report at bugs.python.org  Sat Mar  6 12:20:03 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 06 Mar 2021 17:20:03 +0000
Subject: [issue43420] Optimize rational arithmetics
In-Reply-To: <1615040297.73.0.541090358152.issue43420@roundup.psfhosted.org>
Message-ID: <1615051203.41.0.531162510709.issue43420@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Here's some code to try out:

from math import gcd
from fractions import Fraction
import operator
import math

class Henrici(Fraction):
    'Reformulate _mul to reduce the size of intermediate products'

    # Original has 2 multiplications, 1 gcd calls, and 2 divisions
    # This one has 2 multiplications, 2 gcd calls, and 4 divisions  

    def _mul(a, b):
        a_n, a_d = a.numerator, a.denominator
        b_n, b_d = b.numerator, b.denominator
        d1 = math.gcd(a_n, b_d)
        a_n //= d1
        b_d //= d1
        d2 = math.gcd(b_n, a_d)
        b_n //= d2
        a_d //= d2
        result = Fraction(a_n * b_n, a_d * b_d, _normalize=False)
        assert math.gcd(a_n * b_n, a_d * b_d) == 1 and a_d * b_d >= 0
        return result

    __mul__, __rmul__ = Fraction._operator_fallbacks(_mul, operator.mul)

assert Henrici(10, 3) * Henrici(6, 5) == Henrici(4, 1)

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43420>
_______________________________________

From report at bugs.python.org  Sat Mar  6 12:47:09 2021
From: report at bugs.python.org (Thomas Grainger)
Date: Sat, 06 Mar 2021 17:47:09 +0000
Subject: [issue37771] No equivalent of `inspect.getcoroutinestate` for
 PyAsyncGenASend instances
In-Reply-To: <1565054430.97.0.58176402921.issue37771@roundup.psfhosted.org>
Message-ID: <1615052829.36.0.930898471097.issue37771@roundup.psfhosted.org>


Change by Thomas Grainger <tagrain at gmail.com>:


----------
nosy: +alex.gronholm, graingert

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37771>
_______________________________________

From report at bugs.python.org  Sat Mar  6 13:04:44 2021
From: report at bugs.python.org (Kamil Turek)
Date: Sat, 06 Mar 2021 18:04:44 +0000
Subject: [issue43245] Add keyword argument support to ChainMap.new_child()
In-Reply-To: <1613591324.63.0.830748384561.issue43245@roundup.psfhosted.org>
Message-ID: <1615053884.65.0.957859621359.issue43245@roundup.psfhosted.org>


Change by Kamil Turek <tazzu at live.com>:


----------
nosy: +kamilturek

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43245>
_______________________________________

From report at bugs.python.org  Sat Mar  6 13:52:42 2021
From: report at bugs.python.org (Chris Griffith)
Date: Sat, 06 Mar 2021 18:52:42 +0000
Subject: [issue43423] Subprocess IndexError possible in _communicate
Message-ID: <1615056762.46.0.090803448155.issue43423@roundup.psfhosted.org>


New submission from Chris Griffith <teckchris at gmail.com>:

It is possible to run into an IndexError in the subprocess module's _communicate function.

```
    return run(
  File "subprocess.py", line 491, in run
  File "subprocess.py", line 1024, in communicate
  File "subprocess.py", line 1418, in _communicate
IndexError: list index out of range
```

The lines in question are: 

```
            if stdout is not None:
                stdout = stdout[0]
            if stderr is not None:
                stderr = stderr[0]
```

I believe this is due to the fact there is no safety checking to make sure that self._stdout_buff and self._stderr_buff have any content in them after being set to empty lists. 

The fix I suggest is to change the checks from `if stdout is not None` to simply `if stdout` to make sure it is a populated list. 

Example fixed code: 

```
            if stdout:
                stdout = stdout[0]
            if stderr:
                stderr = stderr[0]
```

If a more stringent check is required, we could expand that out to check type and length, such as `isinstance(stdout, list) and len(stdout) > 0:` but that is more then necessary currently.

----------
components: Library (Lib)
messages: 388211
nosy: cdgriffith
priority: normal
severity: normal
status: open
title: Subprocess IndexError possible in _communicate
type: crash
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43423>
_______________________________________

From report at bugs.python.org  Sat Mar  6 13:57:39 2021
From: report at bugs.python.org (Chris Griffith)
Date: Sat, 06 Mar 2021 18:57:39 +0000
Subject: [issue43423] Subprocess IndexError possible in _communicate
In-Reply-To: <1615056762.46.0.090803448155.issue43423@roundup.psfhosted.org>
Message-ID: <1615057059.52.0.823999205543.issue43423@roundup.psfhosted.org>


Change by Chris Griffith <teckchris at gmail.com>:


----------
keywords: +patch
pull_requests: +23542
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24777

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43423>
_______________________________________

From report at bugs.python.org  Sat Mar  6 14:42:46 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 06 Mar 2021 19:42:46 +0000
Subject: [issue43420] Optimize rational arithmetics
In-Reply-To: <1615040297.73.0.541090358152.issue43420@roundup.psfhosted.org>
Message-ID: <1615059766.57.0.671298394728.issue43420@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/issue43420>
_______________________________________

From report at bugs.python.org  Sat Mar  6 15:00:34 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 06 Mar 2021 20:00:34 +0000
Subject: [issue43420] Optimize rational arithmetics
In-Reply-To: <1615040297.73.0.541090358152.issue43420@roundup.psfhosted.org>
Message-ID: <1615060834.29.0.273600518162.issue43420@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Note that Fraction arithmetic has a huge administrative overhead. The cost of the underlying multiplications and divisions won't dominate the total time until the numerators and denominators are very large.

For the proposed optimization, this implies that cost for the extra Python steps to implement the optimization will be negligible.  The benefits of the optimization are similarly attenuated.

-- Update to experimentation code: add guards for the relatively prime case. --

class Henrici(Fraction):
    'Reformulate _mul to reduce the size of intermediate products'
    def _mul(a, b):
        a_n, a_d = a.numerator, a.denominator
        b_n, b_d = b.numerator, b.denominator
        d1 = math.gcd(a_n, b_d)
        if d1 > 1:
            a_n //= d1
            b_d //= d1
        d2 = math.gcd(b_n, a_d)
        if d2 > 1:
            b_n //= d2
            a_d //= d2
        result = Fraction(a_n * b_n, a_d * b_d, _normalize=False)
        assert math.gcd(a_n * b_n, a_d * b_d) == 1 and a_d * b_d >= 0
        return result

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43420>
_______________________________________

From report at bugs.python.org  Sat Mar  6 15:36:26 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 06 Mar 2021 20:36:26 +0000
Subject: [issue43423] Subprocess IndexError possible in _communicate
In-Reply-To: <1615056762.46.0.090803448155.issue43423@roundup.psfhosted.org>
Message-ID: <1615062986.96.0.0734683142547.issue43423@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

The presumption I suppose is that these statements only execute if self.stdout_thread and/or self.stderr_thread completes successfully. I suppose that the read could fail or get canceled via CancelSynchronousIo(). Of course in that case you have a bigger problem than an IndexError.

On a related note, _communicate() needs significant changes in Windows. See bpo-43346 if you're interested.

----------
components: +Windows
nosy: +eryksun, paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43423>
_______________________________________

From report at bugs.python.org  Sat Mar  6 15:41:59 2021
From: report at bugs.python.org (Thomas Grainger)
Date: Sat, 06 Mar 2021 20:41:59 +0000
Subject: [issue43216] Removal of @asyncio.coroutine in Python 3.10
In-Reply-To: <1613234875.25.0.783359316655.issue43216@roundup.psfhosted.org>
Message-ID: <1615063319.74.0.207354036959.issue43216@roundup.psfhosted.org>


Change by Thomas Grainger <tagrain at gmail.com>:


----------
nosy: +graingert

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43216>
_______________________________________

From report at bugs.python.org  Sat Mar  6 15:45:30 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 06 Mar 2021 20:45:30 +0000
Subject: [issue43420] Optimize rational arithmetics
In-Reply-To: <1615040297.73.0.541090358152.issue43420@roundup.psfhosted.org>
Message-ID: <1615063530.12.0.0345111932149.issue43420@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The cost to the common case for small components is about 20%:

$ python3.10 -m timeit -r11 -s 'from fractions import Fraction as F' -s 'a=F(10,3)' -s 'b=F(6, 5)' 'a * b'
200000 loops, best of 11: 1.8 usec per loop

$ python3.10 -m timeit -r11 -s 'from patched import Fraction as F' -s 'a=F(10,3)' -s 'b=F(6, 5)' 'a * b'
100000 loops, best of 11: 2.14 usec per loop

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43420>
_______________________________________

From report at bugs.python.org  Sat Mar  6 15:58:13 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 06 Mar 2021 20:58:13 +0000
Subject: [issue43420] Optimize rational arithmetics
In-Reply-To: <1615040297.73.0.541090358152.issue43420@roundup.psfhosted.org>
Message-ID: <1615064293.26.0.502414893223.issue43420@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Without the guards the incremental cost drops to 10%.

$ python3.10 -m timeit -r11 -s 'from patched_noguards import Fraction as F' -s 'a=F(10,3)' -s 'b=F(6, 5)' 'a * b'
100000 loops, best of 11: 2.02 usec per loop

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43420>
_______________________________________

From report at bugs.python.org  Sat Mar  6 16:34:06 2021
From: report at bugs.python.org (Neil Schemenauer)
Date: Sat, 06 Mar 2021 21:34:06 +0000
Subject: [issue43372] ctypes: test_frozentable fails when make regen-frozen
In-Reply-To: <1614696034.15.0.923342699637.issue43372@roundup.psfhosted.org>
Message-ID: <1615066446.78.0.611334636324.issue43372@roundup.psfhosted.org>


Neil Schemenauer <nas-python at arctrix.com> added the comment:


New changeset 87ec26b812e9c4095c017dc60f246eda37b83ab2 by Neil Schemenauer in branch 'master':
bpo-43372: Use _freeze_importlib for regen-frozen. (GH-24759)
https://github.com/python/cpython/commit/87ec26b812e9c4095c017dc60f246eda37b83ab2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43372>
_______________________________________

From report at bugs.python.org  Sat Mar  6 16:34:06 2021
From: report at bugs.python.org (Neil Schemenauer)
Date: Sat, 06 Mar 2021 21:34:06 +0000
Subject: [issue42246] Implement PEP 626 -- Precise line numbers for debugging
In-Reply-To: <1604331162.26.0.596873070589.issue42246@roundup.psfhosted.org>
Message-ID: <1615066446.89.0.934277766779.issue42246@roundup.psfhosted.org>


Neil Schemenauer <nas-python at arctrix.com> added the comment:


New changeset 87ec26b812e9c4095c017dc60f246eda37b83ab2 by Neil Schemenauer in branch 'master':
bpo-43372: Use _freeze_importlib for regen-frozen. (GH-24759)
https://github.com/python/cpython/commit/87ec26b812e9c4095c017dc60f246eda37b83ab2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42246>
_______________________________________

From report at bugs.python.org  Sat Mar  6 16:34:34 2021
From: report at bugs.python.org (Neil Schemenauer)
Date: Sat, 06 Mar 2021 21:34:34 +0000
Subject: [issue43372] ctypes: test_frozentable fails when make regen-frozen
In-Reply-To: <1614696034.15.0.923342699637.issue43372@roundup.psfhosted.org>
Message-ID: <1615066474.69.0.744793417967.issue43372@roundup.psfhosted.org>


Change by Neil Schemenauer <nas-python at arctrix.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43372>
_______________________________________

From report at bugs.python.org  Sat Mar  6 19:35:59 2021
From: report at bugs.python.org (Zackery Spytz)
Date: Sun, 07 Mar 2021 00:35:59 +0000
Subject: [issue40982] copytree example in shutil
In-Reply-To: <1592212728.34.0.101904144419.issue40982@roundup.psfhosted.org>
Message-ID: <1615077359.89.0.671905467132.issue40982@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 3.0 -> 4.0
pull_requests: +23543
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24778

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40982>
_______________________________________

From report at bugs.python.org  Sat Mar  6 20:38:28 2021
From: report at bugs.python.org (Ilya Grigoriev)
Date: Sun, 07 Mar 2021 01:38:28 +0000
Subject: [issue43424] Document the `controller.name` field in `webbrowser`
 module
Message-ID: <1615081108.59.0.182832926789.issue43424@roundup.psfhosted.org>


New submission from Ilya Grigoriev <ilyagr at gmail.com>:

The object `webbrowser.get()` returns has, and had for a long time, a useful but undocumented field `name`. I wonder if it would be OK to document it as something like `a system-dependent name for the browser`. This would go here:

https://docs.python.org/3/library/webbrowser.html#browser-controller-objects

The reason I'd like this is so that I can write code like the following:

```python
# In Crostini Chrome OS Linux, the default browser is set to an
# intermediary called `garcon-url-handler`.
# It opens URLs in Chrome running outside the linux VM. This 
# browser does not have access to the Linux filesystem. Some references:
# https://chromium.googlesource.com/chromiumos/platform2/+/master/vm_tools/garcon/#opening-urls
# https://source.chromium.org/search?q=garcon-url-handler

if "garcon-url-handler" in webbrowser.get().name:
  webbrowser.open("http://external-url.com/docs.html")
else:
  webbrowser.open("file:///usr/share/doc/docs.html")
```

This would work correctly, even if the user has installed a browser native to the Linux VM and put it into their `BROWSER` environment variable. I don't know a better way to achieve the same effect.

Some references to where the `name` field was introduced:

https://bugs.python.org/issue754022

https://github.com/python/cpython/commit/e8f244305ef4f257f6999b69601f4316b31faa5e

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 388218
nosy: docs at python, ilyagr
priority: normal
severity: normal
status: open
title: Document the `controller.name` field in `webbrowser` module
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43424>
_______________________________________

From report at bugs.python.org  Sat Mar  6 22:09:48 2021
From: report at bugs.python.org (C.A.M. Gerlach)
Date: Sun, 07 Mar 2021 03:09:48 +0000
Subject: [issue29982] tempfile.TemporaryDirectory fails to delete itself
In-Reply-To: <1491330378.49.0.274398190766.issue29982@psf.upfronthosting.co.za>
Message-ID: <1615086588.6.0.447518742958.issue29982@roundup.psfhosted.org>


C.A.M. Gerlach <CAM.Gerlach at Gerlach.CAM> added the comment:

In addition to transient failures, this can also occur when, for example, files opened in the temporary directory (perhaps by library or application code not under direct control of the caller) haven't been properly cleaned up and their file handles don't get closed, resulting in permissions errors trying to delete them (particularly on platforms like Windows, that automatically lock files when opening them).

This case came up in e.g. [this recent PR](https://github.com/regebro/pyroma/pull/57) and rendered `tempfile.TemporaryDirectory` unusable for such use cases, forcing a reversion to the lower-level `tempfile.mkdtemp` without the cleaner, more robust and easier to interpret high-level interface that the former provides. Wrapping a `with` statement in a try-finally is syntactically ugly and semantically incongruous, and requires a second shutil.rmtree(..., ignore_errors=True)` call to clean up in a best-effort manner, while when manually calling `cleanup()` in a try-except, the finalizer still gets executed at a a non-deterministic later time when Python exits, raising an error.

Therefore, in the spirit of Guido's statements above in terms of providing a "best-effort" cleanup, I propose (and am willing to submit a PR to implement) adding an `ignore_errors` bool parameter (defaulting to False, of course, for backward compat--and should it be keyword only like `errors` to `TemporaryFile`?) to the `tempfile.TemporaryDirectory` constructor, which gets  passed to `shutil.rmtree` on cleanup. This would not only address both cases here, but also one of the two discussed by Anthony Sotitle on [BPO-25024](https://bugs.python.org/issue25024), in a cleaner and simpler fashion that would take advantage of existing `tempfile.TemporaryDirectory` functionality and behavior.

Would a PR be accepted on this? If so, any specific guidance on tests and whether to mention it in What's New, etc., would be appreciated. Thanks!

----------
nosy: +CAM-Gerlach

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29982>
_______________________________________

From report at bugs.python.org  Sat Mar  6 22:14:34 2021
From: report at bugs.python.org (C.A.M. Gerlach)
Date: Sun, 07 Mar 2021 03:14:34 +0000
Subject: [issue25024] Allow passing "delete=False" to TemporaryDirectory
In-Reply-To: <1441690580.39.0.270846340544.issue25024@psf.upfronthosting.co.za>
Message-ID: <1615086874.49.0.389437424129.issue25024@roundup.psfhosted.org>


C.A.M. Gerlach <CAM.Gerlach at Gerlach.CAM> added the comment:

To note, the proposal on [BPO-29982](https://bugs.python.org/issue29982) should hopefully address one of the two use-cases described by Anthony Sotittle, `ignore_errors=True`, in a cleaner fashion that takes advantage of the existing higher-level functionality rather than duplicating `mkdtemp`. Opinions and feedback welcome over there.

----------
nosy: +CAM-Gerlach

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25024>
_______________________________________

From report at bugs.python.org  Sat Mar  6 23:23:18 2021
From: report at bugs.python.org (Sergey B Kirpichev)
Date: Sun, 07 Mar 2021 04:23:18 +0000
Subject: [issue43420] Optimize rational arithmetics
In-Reply-To: <1615040297.73.0.541090358152.issue43420@roundup.psfhosted.org>
Message-ID: <1615090998.74.0.128389985738.issue43420@roundup.psfhosted.org>


Sergey B Kirpichev <skirpichev at gmail.com> added the comment:

I have similar timings (for a draft version of PR, see f.patch) as for the last comment, though the small-dens overhead seems to be bigger(~20%):
$ python3.10 -m timeit -r11 -s 'from fractions import Fraction as F' -s 'a=F(10,3)' -s 'b=F(6, 5)' 'a * b'
50000 loops, best of 11: 9.09 usec per loop
$ python3.10 -m timeit -r11 -s 'from patched import Fraction as F' -s 'a=F(10,3)' -s 'b=F(6, 5)' 'a * b'
20000 loops, best of 11: 11.2 usec per loop

On another hand, here are timings for bigger denominators:
$ python3.10 -m timeit -r11 -s 'from fractions import Fraction as F' -s 'import random' -s 'n = [random.randint(1, 1000000) for _ in range(1000)]' -s 'd = [random.randint(1, 1000000) for _ in range(1000)]' -s 'a=list(map(lambda x: F(*x), zip(n, d)))' 'sum(a)'
1 loop, best of 11: 257 msec per loop
$ ... from patched ...
10 loops, best of 11: 33.2 msec per loop

It's not so clear what "are very large" does mean, that could be defined here.  BTW, 10**6 denominators are (very!) small for mentioned above use case (CAS package).

----------
keywords: +patch
Added file: https://bugs.python.org/file49854/f.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43420>
_______________________________________

From report at bugs.python.org  Sat Mar  6 23:50:12 2021
From: report at bugs.python.org (Sergey B Kirpichev)
Date: Sun, 07 Mar 2021 04:50:12 +0000
Subject: [issue43420] Optimize rational arithmetics
In-Reply-To: <1615040297.73.0.541090358152.issue43420@roundup.psfhosted.org>
Message-ID: <1615092612.53.0.439440822323.issue43420@roundup.psfhosted.org>


Change by Sergey B Kirpichev <skirpichev at gmail.com>:


----------
pull_requests: +23544
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24779

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43420>
_______________________________________

From report at bugs.python.org  Sun Mar  7 00:07:09 2021
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 07 Mar 2021 05:07:09 +0000
Subject: [issue43425] test_peg_generator.test_c_parser emits
 DeprecationWarning due to distutils
Message-ID: <1615093629.58.0.305422387924.issue43425@roundup.psfhosted.org>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

distutils was deprecated for removal in Python 3.10. It is used in test_peg_generator.test_c_parser which emits a deprecation warning. It also seems to be used in test_support for missing_compiler_executable that will emit a deprecation warning.

./python -Wall -m test test_peg_generator test_c_parser
0:00:00 load avg: 0.02 Run tests sequentially
0:00:00 load avg: 0.02 [1/2] test_peg_generator
/root/cpython/Lib/test/test_peg_generator/test_c_parser.py:4: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives
  from distutils.tests.support import TempdirManager


Other places on grep : 

rg 'from distutils' | rg -v 'Lib/distutils|rst'   
Modules/_decimal/tests/formathelper.py:from distutils.spawn import find_executable
Doc/includes/setup.py:from distutils.core import setup, Extension
Doc/includes/test.py:from distutils.util import get_platform
setup.py:from distutils import log
setup.py:from distutils.command.build_ext import build_ext
setup.py:from distutils.command.build_scripts import build_scripts
setup.py:from distutils.command.install import install
setup.py:from distutils.command.install_lib import install_lib
setup.py:from distutils.core import Extension, setup
setup.py:from distutils.errors import CCompilerError, DistutilsError
setup.py:from distutils.spawn import find_executable
Lib/_osx_support.py:        from distutils import log
Lib/_osx_support.py:    Currently called from distutils.sysconfig
Lib/test/support/__init__.py:    from distutils import ccompiler, sysconfig, spawn, errors
Lib/test/test_importlib/test_windows.py:from distutils.util import get_platform
Lib/test/test_peg_generator/test_c_parser.py:from distutils.tests.support import TempdirManager
Tools/peg_generator/pegen/build.py:    from distutils.core import Distribution, Extension
Tools/peg_generator/pegen/build.py:    from distutils.command.clean import clean  # type: ignore
Tools/peg_generator/pegen/build.py:    from distutils.command.build_ext import build_ext  # type: ignore
Tools/peg_generator/pegen/build.py:    from distutils.tests.support import fixup_build_ext  # type: ignore
Tools/test2to3/setup.py:from distutils.core import setup
Tools/test2to3/setup.py:    from distutils.command.build_py import build_py_2to3 as build_py
Tools/test2to3/setup.py:    from distutils.command.build_py import build_py
Tools/test2to3/setup.py:    from distutils.command.build_scripts import build_scripts_2to3 as build_scripts
Tools/test2to3/setup.py:    from distutils.command.build_scripts import build_scripts
Tools/test2to3/test/runtests.py:    from distutils.util import copydir_run_2to3
Misc/HISTORY:- Issue #5394: removed > 2.3 syntax from distutils.msvc9compiler.

----------
components: Tests
messages: 388222
nosy: pablogsal, xtreak
priority: normal
severity: normal
status: open
title: test_peg_generator.test_c_parser emits DeprecationWarning due to distutils
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43425>
_______________________________________

From report at bugs.python.org  Sun Mar  7 00:11:06 2021
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 07 Mar 2021 05:11:06 +0000
Subject: [issue43426] test_importlib.test_windows emits deprecation warning
 over usage of distutils
Message-ID: <1615093866.16.0.242132753657.issue43426@roundup.psfhosted.org>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

test_windows uses distutil which emits a deprecation warning due to distutils being deprecated. sysconfig.get_platform and distutils.util.get_host_platform seem to be identical though distutils.util.get_platform has an extra if clause for nt systems. This is related to https://bugs.python.org/issue41282

./python -Wall -m test test_importlib.test_windows
0:00:00 load avg: 0.00 Run tests sequentially
0:00:00 load avg: 0.00 [1/1] test_importlib.test_windows
/root/cpython/Lib/test/test_importlib/test_windows.py:10: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives
  from distutils.util import get_platform
test_importlib.test_windows skipped -- No module named 'winreg'
test_importlib.test_windows skipped

== Tests result: SUCCESS ==

1 test skipped:
    test_importlib.test_windows

Total duration: 56 ms
Tests result: SUCCESS

----------
components: Tests, Windows
messages: 388223
nosy: paul.moore, steve.dower, tim.golden, xtreak, zach.ware
priority: normal
severity: normal
status: open
title: test_importlib.test_windows emits deprecation warning over usage of distutils
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43426>
_______________________________________

From report at bugs.python.org  Sun Mar  7 00:16:45 2021
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 07 Mar 2021 05:16:45 +0000
Subject: [issue41282] Deprecate and remove distutils
In-Reply-To: <1594542625.3.0.789939298104.issue41282@roundup.psfhosted.org>
Message-ID: <1615094204.99.0.860853802342.issue41282@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I have created below issues where deprecation warning is emitted due to distutils usage in tests. Probably there are other places that need an update to setuptools like setup.py used by make that emits deprecation warning during building cpython.

https://bugs.python.org/issue43426
https://bugs.python.org/issue43425

 rg '(from|import) distutils' | rg -v 'Lib/distutils|rst'
Modules/_decimal/tests/formathelper.py:from distutils.spawn import find_executable
Doc/includes/setup.py:from distutils.core import setup, Extension
Doc/includes/test.py:from distutils.util import get_platform
setup.py:from distutils import log
setup.py:from distutils.command.build_ext import build_ext
setup.py:from distutils.command.build_scripts import build_scripts
setup.py:from distutils.command.install import install
setup.py:from distutils.command.install_lib import install_lib
setup.py:from distutils.core import Extension, setup
setup.py:from distutils.errors import CCompilerError, DistutilsError
setup.py:from distutils.spawn import find_executable
Lib/_osx_support.py:        from distutils import log
Lib/_osx_support.py:    Currently called from distutils.sysconfig
Lib/test/support/__init__.py:    from distutils import ccompiler, sysconfig, spawn, errors
Lib/test/test_distutils.py:import distutils.tests
Lib/test/test_importlib/test_windows.py:from distutils.util import get_platform
Lib/test/test_peg_generator/test_c_parser.py:from distutils.tests.support import TempdirManager
Lib/test/test_sundry.py:            import distutils.bcppcompiler
Lib/test/test_sundry.py:            import distutils.ccompiler
Lib/test/test_sundry.py:            import distutils.cygwinccompiler
Lib/test/test_sundry.py:            import distutils.filelist
Lib/test/test_sundry.py:            import distutils.text_file
Lib/test/test_sundry.py:            import distutils.unixccompiler
Lib/test/test_sundry.py:            import distutils.command.bdist_dumb
Lib/test/test_sundry.py:                import distutils.command.bdist_msi
Lib/test/test_sundry.py:            import distutils.command.bdist
Lib/test/test_sundry.py:            import distutils.command.bdist_rpm
Lib/test/test_sundry.py:            import distutils.command.build_clib
Lib/test/test_sundry.py:            import distutils.command.build_ext
Lib/test/test_sundry.py:            import distutils.command.build
Lib/test/test_sundry.py:            import distutils.command.clean
Lib/test/test_sundry.py:            import distutils.command.config
Lib/test/test_sundry.py:            import distutils.command.install_data
Lib/test/test_sundry.py:            import distutils.command.install_egg_info
Lib/test/test_sundry.py:            import distutils.command.install_headers
Lib/test/test_sundry.py:            import distutils.command.install_lib
Lib/test/test_sundry.py:            import distutils.command.register
Lib/test/test_sundry.py:            import distutils.command.sdist
Lib/test/test_sundry.py:            import distutils.command.upload
Tools/peg_generator/pegen/build.py:    import distutils.log
Tools/peg_generator/pegen/build.py:    from distutils.core import Distribution, Extension
Tools/peg_generator/pegen/build.py:    from distutils.command.clean import clean  # type: ignore
Tools/peg_generator/pegen/build.py:    from distutils.command.build_ext import build_ext  # type: ignore
Tools/peg_generator/pegen/build.py:    from distutils.tests.support import fixup_build_ext  # type: ignore
Tools/c-analyzer/c_parser/preprocessor/common.py:import distutils.ccompiler
Tools/c-analyzer/c_parser/preprocessor/__init__.py:import distutils.ccompiler
Tools/test2to3/setup.py:from distutils.core import setup
Tools/test2to3/setup.py:    from distutils.command.build_py import build_py_2to3 as build_py
Tools/test2to3/setup.py:    from distutils.command.build_py import build_py
Tools/test2to3/setup.py:    from distutils.command.build_scripts import build_scripts_2to3 as build_scripts
Tools/test2to3/setup.py:    from distutils.command.build_scripts import build_scripts
Tools/test2to3/test/runtests.py:    from distutils.util import copydir_run_2to3
Misc/HISTORY:- Issue #5394: removed > 2.3 syntax from distutils.msvc9compiler.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41282>
_______________________________________

From report at bugs.python.org  Sun Mar  7 00:47:21 2021
From: report at bugs.python.org (Aaron Meurer)
Date: Sun, 07 Mar 2021 05:47:21 +0000
Subject: [issue43420] Optimize rational arithmetics
In-Reply-To: <1615040297.73.0.541090358152.issue43420@roundup.psfhosted.org>
Message-ID: <1615096041.94.0.677457982661.issue43420@roundup.psfhosted.org>


Change by Aaron Meurer <asmeurer at gmail.com>:


----------
nosy: +asmeurer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43420>
_______________________________________

From report at bugs.python.org  Sun Mar  7 01:12:41 2021
From: report at bugs.python.org (Inada Naoki)
Date: Sun, 07 Mar 2021 06:12:41 +0000
Subject: [issue43405] DeprecationWarnings in test_unicode
In-Reply-To: <1614889755.46.0.756872715083.issue43405@roundup.psfhosted.org>
Message-ID: <1615097561.91.0.765703434842.issue43405@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset 8aabfa8550692a76d8a96e138c48faf5a7b2752c by Zackery Spytz in branch 'master':
bpo-43405: Fix DeprecationWarnings in test_unicode (GH-24754)
https://github.com/python/cpython/commit/8aabfa8550692a76d8a96e138c48faf5a7b2752c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43405>
_______________________________________

From report at bugs.python.org  Sun Mar  7 01:13:11 2021
From: report at bugs.python.org (Inada Naoki)
Date: Sun, 07 Mar 2021 06:13:11 +0000
Subject: [issue43405] DeprecationWarnings in test_unicode
In-Reply-To: <1614889755.46.0.756872715083.issue43405@roundup.psfhosted.org>
Message-ID: <1615097591.88.0.440246532973.issue43405@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/issue43405>
_______________________________________

From report at bugs.python.org  Sun Mar  7 01:26:43 2021
From: report at bugs.python.org (Dennis Sweeney)
Date: Sun, 07 Mar 2021 06:26:43 +0000
Subject: [issue41361] Converting collections.deque methods to Argument Clinic
In-Reply-To: <1595345161.63.0.950006640514.issue41361@roundup.psfhosted.org>
Message-ID: <1615098403.17.0.797142496721.issue41361@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

If the argument clinic is too disruptive, would it be okay to inline the equivalent code like this?

diff --git a/Modules/_collectionsmodule.c b/Modules/_collectionsmodule.c
index 90bafb0ea8..d75388abc8 100644
--- a/Modules/_collectionsmodule.c
+++ b/Modules/_collectionsmodule.c
@@ -880,9 +880,19 @@ deque_rotate(dequeobject *deque, PyObject *const *args, Py_ssize_t nargs)
 {
     Py_ssize_t n=1;

-    if (!_PyArg_ParseStack(args, nargs, "|n:rotate", &n)) {
+    if (!_PyArg_CheckPositional("deque.rotate", nargs, 0, 1)) {
         return NULL;
     }
+    if (nargs) {
+        PyObject *index = _PyNumber_Index(args[0]);
+        if (index == NULL) {
+            return NULL;
+        }
+        n = PyLong_AsSsize_t(index);
+        if (n == -1 && PyErr_Occurred()) {
+            return NULL;
+        }
+    }

     if (!_deque_rotate(deque, n))
         Py_RETURN_NONE;

Benchmarks for this change:

    .\python.bat -m pyperf timeit -s "from collections import deque; d = deque(range(100))" "d.rotate()"
    Before: Mean +- std dev: 51.2 ns +- 0.9 ns
    After:  Mean +- std dev: 39.3 ns +- 0.3 ns

    .\python.bat -m pyperf timeit -s "from collections import deque; d = deque(range(100))" "d.rotate(-1)"
    Before: Mean +- std dev: 64.5 ns +- 0.3 ns
    After:  Mean +- std dev: 46.2 ns +- 0.3 ns

    .\python.bat -m pyperf timeit -s "from collections import deque; d = deque(range(100))" "d.rotate(1)"
    Before: Mean +- std dev: 64.4 ns +- 0.3 ns
    After:  Mean +- std dev: 45.7 ns +- 0.2 ns

Similar changes could apply to deque.insert() and deque.index().

----------
nosy: +Dennis Sweeney

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41361>
_______________________________________

From report at bugs.python.org  Sun Mar  7 01:55:58 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 07 Mar 2021 06:55:58 +0000
Subject: [issue43420] Optimize rational arithmetics
In-Reply-To: <1615040297.73.0.541090358152.issue43420@roundup.psfhosted.org>
Message-ID: <1615100158.57.0.589116111152.issue43420@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> 1 loop, best of 11: 257 msec per loop
> $ ... from patched ...
> 10 loops, best of 11: 33.2 msec per loop

Looks worth it :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43420>
_______________________________________

From report at bugs.python.org  Sun Mar  7 04:08:58 2021
From: report at bugs.python.org (miss-islington)
Date: Sun, 07 Mar 2021 09:08:58 +0000
Subject: [issue43319] A possible misleading expression in the Virtual
 Environment Tutorial
In-Reply-To: <1614242172.25.0.356452528592.issue43319@roundup.psfhosted.org>
Message-ID: <1615108138.24.0.527722717411.issue43319@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 8d00462850b32da4649c3403692ed5515e6a96d1 by cmhzc in branch 'master':
bpo-43319: Fixed the tutorial on venv about standard library (GH-24740)
https://github.com/python/cpython/commit/8d00462850b32da4649c3403692ed5515e6a96d1


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43319>
_______________________________________

From report at bugs.python.org  Sun Mar  7 04:44:41 2021
From: report at bugs.python.org (Sergey B Kirpichev)
Date: Sun, 07 Mar 2021 09:44:41 +0000
Subject: [issue21922] PyLong: use GMP
In-Reply-To: <1404562944.87.0.0403783440946.issue21922@psf.upfronthosting.co.za>
Message-ID: <1615110281.08.0.302036884964.issue21922@roundup.psfhosted.org>


Change by Sergey B Kirpichev <skirpichev at gmail.com>:


----------
nosy: +Sergey.Kirpichev

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21922>
_______________________________________

From report at bugs.python.org  Sun Mar  7 04:46:25 2021
From: report at bugs.python.org (Sergey B Kirpichev)
Date: Sun, 07 Mar 2021 09:46:25 +0000
Subject: [issue1814] Victor Stinner's GMP patch for longs
In-Reply-To: <1200157933.02.0.312333297821.issue1814@psf.upfronthosting.co.za>
Message-ID: <1615110385.43.0.735685197784.issue1814@roundup.psfhosted.org>


Change by Sergey B Kirpichev <skirpichev at gmail.com>:


----------
nosy: +Sergey.Kirpichev

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1814>
_______________________________________

From report at bugs.python.org  Sun Mar  7 04:54:03 2021
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Sun, 07 Mar 2021 09:54:03 +0000
Subject: [issue43372] ctypes: test_frozentable fails when make regen-frozen
In-Reply-To: <1614696034.15.0.923342699637.issue43372@roundup.psfhosted.org>
Message-ID: <1615110843.73.0.568526979571.issue43372@roundup.psfhosted.org>


Miro Hron?ok <miro at hroncok.cz> added the comment:

Thanks for the fixer!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43372>
_______________________________________

From report at bugs.python.org  Sun Mar  7 05:12:11 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 07 Mar 2021 10:12:11 +0000
Subject: [issue41369] Update to libmpdec-2.5.1
In-Reply-To: <1595446041.62.0.150992911256.issue41369@roundup.psfhosted.org>
Message-ID: <1615111931.91.0.578334905231.issue41369@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Sounds fine to me. If I'm understanding right, what we have in master right now is somewhere between libmpdec 2.5.0 and libmpdec 2.5.1; is that right? If so, it definitely makes sense to update to 2.5.1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41369>
_______________________________________

From report at bugs.python.org  Sun Mar  7 05:17:35 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 07 Mar 2021 10:17:35 +0000
Subject: [issue43422] Revert _decimal C API changes
In-Reply-To: <1615043906.44.0.566874098139.issue43422@roundup.psfhosted.org>
Message-ID: <1615112255.53.0.887417955037.issue43422@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

+1 for reverting these before 3.10. See also @mattip's comments on #41324, and #43060.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43422>
_______________________________________

From report at bugs.python.org  Sun Mar  7 05:54:57 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 07 Mar 2021 10:54:57 +0000
Subject: [issue43420] Optimize rational arithmetics
In-Reply-To: <1615040297.73.0.541090358152.issue43420@roundup.psfhosted.org>
Message-ID: <1615114497.75.0.316020771919.issue43420@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Personally, I'd prefer to keep the code simplicity, and the speed for small inputs here. Python's needs aren't the same as SymPy's needs or SAGE's needs, and not all of the fractions.Fraction use-cases involve summing lots of values with incompatible denominators.

> With big denominators (~10**6) this really does matter, my local
> benchmarks suggest the order of magnitude difference for
> summation of several such numbers.

Could you give some idea of the crossover point for a single addition? At roughly what size numerator/denominator do we start seeing a performance benefit?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43420>
_______________________________________

From report at bugs.python.org  Sun Mar  7 06:26:20 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 07 Mar 2021 11:26:20 +0000
Subject: [issue41324] Add a minimal decimal capsule API
In-Reply-To: <1594984713.74.0.721782226907.issue41324@roundup.psfhosted.org>
Message-ID: <1615116380.91.0.425903508108.issue41324@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

@mattip, see issue43422

----------
assignee: skrah -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41324>
_______________________________________

From report at bugs.python.org  Sun Mar  7 06:34:31 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 07 Mar 2021 11:34:31 +0000
Subject: [issue43060] Convert _decimal C API from pointer array to struct
In-Reply-To: <1611913613.83.0.451385849535.issue43060@roundup.psfhosted.org>
Message-ID: <1615116871.26.0.858487343069.issue43060@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Just a note that #43422 would make this moot.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43060>
_______________________________________

From report at bugs.python.org  Sun Mar  7 06:45:24 2021
From: report at bugs.python.org (Sergey B Kirpichev)
Date: Sun, 07 Mar 2021 11:45:24 +0000
Subject: [issue43420] Optimize rational arithmetics
In-Reply-To: <1615040297.73.0.541090358152.issue43420@roundup.psfhosted.org>
Message-ID: <1615117524.97.0.356782517322.issue43420@roundup.psfhosted.org>


Sergey B Kirpichev <skirpichev at gmail.com> added the comment:

> I'd prefer to keep the code simplicity

It's not going to be complicated so much and algorithms are well known,
but I see your point.

> and the speed for small inputs here

Speed loss is not so big, 10-20%.

> Python's needs aren't the same as SymPy's needs or SAGE's needs

So, for which needs it will serve?

Sorry, I can't suggest an application, which does use builtin
Fraction's (not sure if even SAGE uses them, as a fallback).  SymPy doesn't,
for sure (but it could - it's PythonRational class uses same optimizations,
except for g == 1 branches in _add/_sub, I think).

There is one exception I've found: stdlib's statistics module uses Fraction's
in the _sum() helper, exactly in a paradigm "sum a lot of values".

> not all of the fractions.Fraction use-cases involve summing lots of values with incompatible denominators.

No need for a lots of values (i.e. 1000): denominator of the sum will grow very fast, that
why modern CAS use modular GCD algorithms, for example.

> Could you give some idea of the crossover point for a single addition?

$ ./python -m timeit -r11 -s 'from fractions import Fraction as F' -s 'a=F(10,31011021112)' -s 'b=F(86,11011021115)' 'a + b'
20000 loops, best of 11: 12.4 usec per loop
$ ./python -m timeit -r11 -s 'from patched import Fraction as F' -s 'a=F(10,31011021112)' -s 'b=F(86,11011021115)' 'a + b'
20000 loops, best of 11: 12.5 usec per loop

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43420>
_______________________________________

From report at bugs.python.org  Sun Mar  7 07:16:36 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 07 Mar 2021 12:16:36 +0000
Subject: [issue43420] Optimize rational arithmetics
In-Reply-To: <1615040297.73.0.541090358152.issue43420@roundup.psfhosted.org>
Message-ID: <1615119396.33.0.0908367369226.issue43420@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> There is one exception I've found: stdlib's statistics module uses
> Fraction's in the _sum() helper, exactly in a paradigm "sum a lot
> of values".

That's an interesting example: it does indeed satisfy the "sum of a lot of values" part, but not the "incompatible denominators" part. :-) The typical use there is that those fractions have been converted from floats, and so all denominators will be a smallish power of two. So we don't encounter the same coefficient explosion problem that we do when summing fractions with unrelated denominators. I have many similar use-cases in my own code, where numerators and denominators don't tend to ever get beyond a few hundred digits, and usually not more than tens of digits.

Thanks for the timings! So assuming that wasn't a specially-chosen best case example, the crossover is somewhere around numerators and denominators of ten digits or so.

> It's not going to be complicated so much

For me, the big difference is that the current code is obviously correct at a glance, while the proposed code takes study and thought to make sure that no corner cases are missed.

Shrug. Put me down as -0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43420>
_______________________________________

From report at bugs.python.org  Sun Mar  7 07:36:19 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 07 Mar 2021 12:36:19 +0000
Subject: [issue10653] test_time test_strptime fails on windows
In-Reply-To: <1291820491.4.0.666293971337.issue10653@psf.upfronthosting.co.za>
Message-ID: <1615120579.02.0.698010366875.issue10653@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

Update since msg243660: 

Python 3.8+ now calls setlocale(LC_CTYPE, "") at startup in Windows, as it has always done in POSIX, so decoding the output of strftime("%Z") with PyUnicode_DecodeLocaleAndSize() works again since both agree on using the process active code page. 

In 3.7+, per bpo-36779, time.tzname is set when the module is first loaded by directly querying GetTimeZoneInformation(). time.tzset() is still not supported, despite the fact that it was always supported by ucrt, so this value can become stale relative to strftime("%Z").

Starting with Windows 10 v2004 (build 19041), ucrt uses an internal wide-character version of the time-zone name that gets returned by an internal __wide_tzname() call and used for "%Z" in wcsftime(). The wide-character value gets updated by _tzset() and kept in sync with _tzname.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10653>
_______________________________________

From report at bugs.python.org  Sun Mar  7 08:06:17 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 07 Mar 2021 13:06:17 +0000
Subject: [issue10653] test_time test_strptime fails on windows
In-Reply-To: <1291820491.4.0.666293971337.issue10653@psf.upfronthosting.co.za>
Message-ID: <1615122377.46.0.511695448962.issue10653@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> decoding the output of strftime("%Z") with PyUnicode_DecodeLocaleAndSize()
> works again since both agree on using the process active code page

At least it works as much as it ever did. It depends on the process active code page being compatible with the preferred UI language of the current process or thread. For example if the UI language is Japanese ('ja-JP') for the current user, but the process active code page is Latin 1252 (based on the system locale), then the result will be garbage. In that case, given the time-zone name is in Japanese, both LC_TIME and LC_CTYPE have to be changed to "ja-JP" in order to correctly encode (as tzname in ucrt), decode-encode (for strftime in ucrt) and finally decode again via PyUnicode_DecodeLocaleAndSize(). If Python switched back to using wcsftime() in Windows 10 2004+, then the current locale encoding would no longer be a problem for any UI language.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10653>
_______________________________________

From report at bugs.python.org  Sun Mar  7 08:57:41 2021
From: report at bugs.python.org (Kamil Turek)
Date: Sun, 07 Mar 2021 13:57:41 +0000
Subject: [issue43319] A possible misleading expression in the Virtual
 Environment Tutorial
In-Reply-To: <1614242172.25.0.356452528592.issue43319@roundup.psfhosted.org>
Message-ID: <1615125461.75.0.293900085696.issue43319@roundup.psfhosted.org>


Change by Kamil Turek <tazzu at live.com>:


----------
nosy: +kamilturek

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43319>
_______________________________________

From report at bugs.python.org  Sun Mar  7 08:58:52 2021
From: report at bugs.python.org (Kamil Turek)
Date: Sun, 07 Mar 2021 13:58:52 +0000
Subject: [issue43216] Removal of @asyncio.coroutine in Python 3.10
In-Reply-To: <1613234875.25.0.783359316655.issue43216@roundup.psfhosted.org>
Message-ID: <1615125532.7.0.68619467316.issue43216@roundup.psfhosted.org>


Change by Kamil Turek <tazzu at live.com>:


----------
nosy: +kamilturek

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43216>
_______________________________________

From report at bugs.python.org  Sun Mar  7 10:42:35 2021
From: report at bugs.python.org (Marcos M)
Date: Sun, 07 Mar 2021 15:42:35 +0000
Subject: [issue43427] Possible error on the descriptor howto guide
Message-ID: <1615131755.48.0.550524446603.issue43427@roundup.psfhosted.org>


New submission from Marcos M <marcosmodenesi at gmail.com>:

> To recap, functions have a __get__() method so that they can be converted to a method when accessed as attributes. The non-data descriptor transforms an obj.f(*args) call into f(obj, *args). Calling cls.f(*args) becomes f(*args).

I THINK it should say

cls.f(*args) becomes f(cls, *args)

as stated in the table that follows that paragraph.

----------
assignee: docs at python
components: Documentation
messages: 388239
nosy: docs at python, marcosmodenesi
priority: normal
severity: normal
status: open
title: Possible error on the descriptor howto guide
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43427>
_______________________________________

From report at bugs.python.org  Sun Mar  7 10:43:40 2021
From: report at bugs.python.org (Marcos M)
Date: Sun, 07 Mar 2021 15:43:40 +0000
Subject: [issue43427] Possible error on the descriptor howto guide
In-Reply-To: <1615131755.48.0.550524446603.issue43427@roundup.psfhosted.org>
Message-ID: <1615131820.66.0.904201696773.issue43427@roundup.psfhosted.org>


Marcos M <marcosmodenesi at gmail.com> added the comment:

Let me provide a link to ease finding this piece of documentation

https://docs.python.org/3/howto/descriptor.html#static-methods

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43427>
_______________________________________

From report at bugs.python.org  Sun Mar  7 11:09:30 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 07 Mar 2021 16:09:30 +0000
Subject: [issue8304] time.strftime() and Unicode characters on Windows
In-Reply-To: <1270307324.04.0.0348018847246.issue8304@psf.upfronthosting.co.za>
Message-ID: <1615133370.26.0.461926500359.issue8304@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

Update since msg255133:

Python 3.8+ now calls setlocale(LC_CTYPE, "") at startup in Windows, as 3.x has always done in POSIX. So decoding the output of C strftime("%Z") with PyUnicode_DecodeLocaleAndSize() 'works' again, since both default to the process code page. The latter is usually the system code page, unless overridden to UTF-8 in the application manifest.

But calling C strftime() as a workaround is still a fragile solution, since it requires that the process code page is able to encode the process or thread UI language. In general, the system code page, the current user locale, and current user preferred language are independent settings in Windows. 

Calling C strftime() also unnecessarily limits the format string to characters in the current LC_CTYPE locale encoding, which requires hacky workarounds.

Starting with Windows 10 v2004 (build 19041), ucrt uses an internal wide-character version of the time-zone name that gets returned by an internal __wide_tzname() call and used for "%Z" in wcsftime(). The wide-character value gets updated by _tzset() and kept in sync with _tzname.

If Python switched to using wcsftime() in Windows 10 2004+, then the current locale encoding would no longer be a problem for any UI language. 

Also, bpo-36779 switched to setting time.tzname by directly calling WinAPI GetTimeZineInformation(). time.tzset() should be implemented in order to keep the value of time.tzname in sync with time.strftime("%Z").

----------
components: +Extension Modules
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8304>
_______________________________________

From report at bugs.python.org  Sun Mar  7 11:17:37 2021
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 07 Mar 2021 16:17:37 +0000
Subject: [issue43427] Possible error on the descriptor howto guide
In-Reply-To: <1615131755.48.0.550524446603.issue43427@roundup.psfhosted.org>
Message-ID: <1615133857.35.0.743987373669.issue43427@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/issue43427>
_______________________________________

From report at bugs.python.org  Sun Mar  7 11:24:13 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 07 Mar 2021 16:24:13 +0000
Subject: [issue43425] test_peg_generator.test_c_parser emits
 DeprecationWarning due to distutils
In-Reply-To: <1615093629.58.0.305422387924.issue43425@roundup.psfhosted.org>
Message-ID: <1615134253.37.0.71339547559.issue43425@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

We just need to suppress the warning unless I am missing somey. Distutils will still be used internally by CPython.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43425>
_______________________________________

From report at bugs.python.org  Sun Mar  7 11:31:28 2021
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 07 Mar 2021 16:31:28 +0000
Subject: [issue43425] test_peg_generator.test_c_parser emits
 DeprecationWarning due to distutils
In-Reply-To: <1615093629.58.0.305422387924.issue43425@roundup.psfhosted.org>
Message-ID: <1615134688.88.0.262418822869.issue43425@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the clarification. As per issue41282 I thought disutils will be removed. The accepted PEP 632 states this scenario so I guess silencing the warning is good enough.

> The final dependency on distutils is CPython itself, which uses it to build native extension modules in the standard library (except on Windows). Because this is a CPython build-time dependency, it is possible to continue to use distutils for this specific case without it being part of the standard library.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43425>
_______________________________________

From report at bugs.python.org  Sun Mar  7 11:52:54 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 07 Mar 2021 16:52:54 +0000
Subject: [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1615135974.39.0.326776826201.issue22790@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

>> Why are __flags__, __basicsize__, __itemsize__, 
>>__dictoffset__, and __weakrefoffset__ interesting?
>
> I haven't said they are, but on the other hand I don't see 
> why consistency is a bad thing.

IMO, they're not interesting because they're not documented attributes in Python's data model. They don't exist in other implementations, such as PyPy. So I'd prefer to hide them and, as much as possible, discourage developers from thinking it's okay to use them. They may be interesting attributes while developing extension modules that define new types, but anyone working at that level surely doesn't need the help of dir() to know what attributes are available.

----------
components: +Interpreter Core -Documentation
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22790>
_______________________________________

From report at bugs.python.org  Sun Mar  7 12:03:35 2021
From: report at bugs.python.org (hai shi)
Date: Sun, 07 Mar 2021 17:03:35 +0000
Subject: [issue43422] Revert _decimal C API changes
In-Reply-To: <1615043906.44.0.566874098139.issue43422@roundup.psfhosted.org>
Message-ID: <1615136615.23.0.097735599062.issue43422@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

+1 from me. 3.10.0 final haven't been released, so no one will be affected.

----------
nosy: +shihai1991, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43422>
_______________________________________

From report at bugs.python.org  Sun Mar  7 13:05:34 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 07 Mar 2021 18:05:34 +0000
Subject: [issue29982] tempfile.TemporaryDirectory fails to delete itself
In-Reply-To: <1491330378.49.0.274398190766.issue29982@psf.upfronthosting.co.za>
Message-ID: <1615140334.19.0.28281043741.issue29982@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

SGTM

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29982>
_______________________________________

From report at bugs.python.org  Sun Mar  7 13:17:30 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 07 Mar 2021 18:17:30 +0000
Subject: [issue24800] exec docs should note that the no argument form in a
 local scope is really the two argument form
In-Reply-To: <1438803881.09.0.804532346481.issue24800@psf.upfronthosting.co.za>
Message-ID: <1615141050.03.0.433766085511.issue24800@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

So there are a couple things to clarify here. When the documentation says "if the optional parts are omitted, the code is executed in the current scope", I think it should explicitly state that this is equivalent to calling exec(object, globals(), locals()). This should help to disabuse the reader of any assumption that the compiled code will extend the nested scoping (i.e. lexical closures) of the calling context.

When it says that if "exec gets two separate objects as globals and locals, the code will be executed as if it were embedded in a class definition", I think this can be misleading. exec() compiles top-level code. It extends module-like execution, allowing globals and locals to differ and defaulting to the current scope. This sharply contrasts to code that's compiled for a `class` statement in the same context.

----------
type: behavior -> enhancement
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24800>
_______________________________________

From report at bugs.python.org  Sun Mar  7 14:08:04 2021
From: report at bugs.python.org (Mariusz Felisiak)
Date: Sun, 07 Mar 2021 19:08:04 +0000
Subject: [issue43216] Removal of @asyncio.coroutine in Python 3.10
In-Reply-To: <1613234875.25.0.783359316655.issue43216@roundup.psfhosted.org>
Message-ID: <1615144084.51.0.294035231644.issue43216@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/issue43216>
_______________________________________

From report at bugs.python.org  Sun Mar  7 14:27:44 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 07 Mar 2021 19:27:44 +0000
Subject: [issue43332] Make http.client._tunnel send one byte string over the
 network
In-Reply-To: <1614370680.1.0.103129903648.issue43332@roundup.psfhosted.org>
Message-ID: <1615145264.63.0.535897561921.issue43332@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
keywords: +patch
pull_requests: +23545
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/24780

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43332>
_______________________________________

From report at bugs.python.org  Sun Mar  7 14:30:31 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 07 Mar 2021 19:30:31 +0000
Subject: [issue43332] Make http.client._tunnel send one byte string over the
 network
In-Reply-To: <1614370680.1.0.103129903648.issue43332@roundup.psfhosted.org>
Message-ID: <1615145431.06.0.915593765243.issue43332@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43332>
_______________________________________

From report at bugs.python.org  Sun Mar  7 14:49:56 2021
From: report at bugs.python.org (Romain Vincent)
Date: Sun, 07 Mar 2021 19:49:56 +0000
Subject: [issue43379] Pasting multiple lines in the REPL is broken since 3.9
In-Reply-To: <1614721536.12.0.538890122544.issue43379@roundup.psfhosted.org>
Message-ID: <1615146596.4.0.937807341494.issue43379@roundup.psfhosted.org>


Romain Vincent <romain at rwigo.com> added the comment:

The lack of dots was something I noticed.

So from your questions (Ned Deily) I have been testing out several things and found a "wae"!

But first, to answer your questions:

1. both LF and CRLF and it didn't change anything.

2. Running "import readline;print(readline.__doc__)" prints
"... GNU readline", with python 3.7, 3.8 and 3.9.

3. I am using iTerm2, but the problem also happens on MacOS's native Terminal.app. Versions of python were installed with **homebrew**.


Maybe worth to mention: if I paste my code in a multi line string to execute with python -c, then it works properly.

e.g.

---

python3.9 -i -c 'a = 42
if a:
  print("hello world")
'
hello world
>>>

---

The example is different because I realized I had the same problem on python3.7 and python3.8 when the 2 first lines were at the same level of indentation (Note sure if this gives a hint as to what the problem is).



HOWEVER, if I use python versions directly downloaded from https://www.python.org/, then I don't have the problem at all!

Demonstration:

---
/Library/Frameworks/Python.framework/Versions/3.7/bin/python3.7
Python 3.7.2 (v3.7.2:9a3ffc0492, Dec 24 2018, 02:44:43) 
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import readline;print(readline.__doc__)
Importing this module enables command line editing using libedit readline.
>>> a = 42
>>> if a:
...   print("hello world")
... 
hello world
>>> 

---

Same for python3.9

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43379>
_______________________________________

From report at bugs.python.org  Sun Mar  7 17:34:24 2021
From: report at bugs.python.org (Aaron Meurer)
Date: Sun, 07 Mar 2021 22:34:24 +0000
Subject: [issue43420] Optimize rational arithmetics
In-Reply-To: <1615040297.73.0.541090358152.issue43420@roundup.psfhosted.org>
Message-ID: <1615156464.6.0.889237220078.issue43420@roundup.psfhosted.org>


Aaron Meurer <asmeurer at gmail.com> added the comment:

I'm surprised to hear that the "typical use-case" of Fraction is fractions converted from floats. Do you have evidence in the wild to support that? 

I would expect any application that uses fractions "generically" to run into the same sorts of problems SymPy does. The issue is that the sum or product of two unrelated fractions has a denominator that is ~ the product of the denominators of each term. So they tend to grow large, unless there is some structure in the terms that results in lots of cancellation. That's why real world numeric typically doesn't use exact arithmetic, but there are legitimate use-cases for it (computer algebra being one).

This actually also applies even if the denominators are powers of 2. That's why arbitrary precision floating point numbers like Decimal or mpmath.mpf limit the precision, or effectively, the power of 2 in the denominator. 

By the way, the "algorithm" here really isn't that complicated. I didn't even realize it had a name. The idea is that for a/b * c/d, if a/b and c/d are already in lowest terms, then the only cancellation that can happen is from a/d or from c/b. So instead of computing gcd(a*c, b*d), we only compute gcd(a, d) and gcd(c, b) and cancel them off the corresponding terms. It turns out to be faster to take two gcds of smaller numbers than one gcd of big ones. The algorithm for addition is a bit more complicated, at least to see that it is correct, but is still not that bad (the paper linked in the OP explains it clearly in one paragraph). It's far less complicated than, for example, Lehmer's gcd algorithm (which is implemented in math.gcd).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43420>
_______________________________________

From report at bugs.python.org  Sun Mar  7 17:41:26 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 07 Mar 2021 22:41:26 +0000
Subject: [issue43406] Possible race condition between signal catching and
 signal.signal
In-Reply-To: <1614893468.93.0.265748275948.issue43406@roundup.psfhosted.org>
Message-ID: <1615156886.76.0.385630736053.issue43406@roundup.psfhosted.org>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
pull_requests: +23546
pull_request: https://github.com/python/cpython/pull/24755

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43406>
_______________________________________

From report at bugs.python.org  Sun Mar  7 17:43:02 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 07 Mar 2021 22:43:02 +0000
Subject: [issue42382] No easy way to get the distribution which provided a
 importlib.metadata.EntryPoint
In-Reply-To: <1605596181.46.0.7808505308.issue42382@roundup.psfhosted.org>
Message-ID: <1615156982.8.0.816542737572.issue42382@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42382>
_______________________________________

From report at bugs.python.org  Sun Mar  7 17:47:18 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 07 Mar 2021 22:47:18 +0000
Subject: [issue42382] No easy way to get the distribution which provided a
 importlib.metadata.EntryPoint
In-Reply-To: <1605596181.46.0.7808505308.issue42382@roundup.psfhosted.org>
Message-ID: <1615157238.62.0.911133191853.issue42382@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42382>
_______________________________________

From report at bugs.python.org  Sun Mar  7 17:54:27 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 07 Mar 2021 22:54:27 +0000
Subject: [issue43428] Sync importlib_metadata enhancements through 3.7.
Message-ID: <1615157667.11.0.27235417477.issue43428@roundup.psfhosted.org>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

importlib metadata has added a few important [changes](https://importlib-metadata.readthedocs.io/en/latest/history.html#v3-7-0) since the last sync in issue42382 (importlib_metadata 3.3):

- Performance enhancements to distribution discovery.
- `entry_points` only returns unique distributions.
- Introduces new ``EntryPoints`` object for containing a set of entry points with convenience methods for selecting entry points by group or name.
- Added packages_distributions function to return a mapping of packages to the distributions that provide them.

----------
assignee: jaraco
components: Library (Lib)
messages: 388250
nosy: jaraco
priority: normal
severity: normal
status: open
title: Sync importlib_metadata enhancements through 3.7.
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43428>
_______________________________________

From report at bugs.python.org  Sun Mar  7 17:57:20 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 07 Mar 2021 22:57:20 +0000
Subject: [issue43379] Pasting multiple lines in the REPL is broken since 3.9
In-Reply-To: <1614721536.12.0.538890122544.issue43379@roundup.psfhosted.org>
Message-ID: <1615157840.96.0.807929822473.issue43379@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Thank you for retesting with the python.org installer.  Since this is Homebrew specific, please open an issue with them, with the updated debug information.

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43379>
_______________________________________

From report at bugs.python.org  Sun Mar  7 18:29:06 2021
From: report at bugs.python.org (Zackery Spytz)
Date: Sun, 07 Mar 2021 23:29:06 +0000
Subject: [issue43429] mmap.size() raises OSError on Unix for anonymous memory
Message-ID: <1615159746.88.0.364980606308.issue43429@roundup.psfhosted.org>


New submission from Zackery Spytz <zspytz at gmail.com>:

For anonymous memory, mmap.size() works without issue on Windows, but it raises OSError on Unix.

----------
components: Extension Modules
messages: 388252
nosy: ZackerySpytz
priority: normal
severity: normal
status: open
title: mmap.size() raises OSError on Unix for anonymous memory
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43429>
_______________________________________

From report at bugs.python.org  Sun Mar  7 18:33:14 2021
From: report at bugs.python.org (Zackery Spytz)
Date: Sun, 07 Mar 2021 23:33:14 +0000
Subject: [issue43429] mmap.size() raises OSError on Unix for anonymous memory
In-Reply-To: <1615159746.88.0.364980606308.issue43429@roundup.psfhosted.org>
Message-ID: <1615159994.67.0.615618840338.issue43429@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
pull_requests: +23547
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24781

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43429>
_______________________________________

From report at bugs.python.org  Sun Mar  7 18:37:37 2021
From: report at bugs.python.org (Daniele Varrazzo)
Date: Sun, 07 Mar 2021 23:37:37 +0000
Subject: [issue42600] Cancelling tasks waiting for asyncio.Conditions crashes
 w/ RuntimeError: Lock is not acquired.
In-Reply-To: <1607430956.17.0.934441920245.issue42600@roundup.psfhosted.org>
Message-ID: <1615160257.73.0.214968353147.issue42600@roundup.psfhosted.org>


Daniele Varrazzo <daniele.varrazzo at gmail.com> added the comment:

I have stumbled in this bug, or something similar, implementing psycopg3 async connection pool. A function such as the following fails but only in Python 3.6 (tested 3.6.12):

    async def wait(self, timeout: float) -> AsyncConnection:
        """Wait for a connection to be set and return it.
        Raise an exception if the wait times out or if fail() is called.
        """
        async with self._cond:
            if not (self.conn or self.error):
                try:
                    await asyncio.wait_for(self._cond.wait(), timeout)
                except asyncio.TimeoutError:
                    # HERE
                    self.error = PoolTimeout(
                        f"couldn't get a connection after {timeout} sec"
                    )

In python 3.6, printing self._cond.locked() in the HERE position gives False, even if it's inside the with block. Everything grinds to a halt afterwards.

However I don't have the same problem in other Python versions (3.7.10, 3.8.5 among the ones tested) so I'm not sure it is the same issue.

Is this a manifestation of the same bug or a different one? Is there any workaround or should I make the async pool just not supported on Python 3.6?

----------
nosy: +piro

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42600>
_______________________________________

From report at bugs.python.org  Sun Mar  7 18:44:45 2021
From: report at bugs.python.org (Ned Deily)
Date: Sun, 07 Mar 2021 23:44:45 +0000
Subject: [issue43379] Pasting multiple lines in the REPL is broken since 3.9
In-Reply-To: <1614721536.12.0.538890122544.issue43379@roundup.psfhosted.org>
Message-ID: <1615160685.85.0.212166345566.issue43379@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

It certainly could be an issue with using GNU readline vs libedit and Terry is correct that you should follow up with Homebrew. But I don't think you stated from which code editor application you were copying from; that could also make a difference. In any case, good luck!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43379>
_______________________________________

From report at bugs.python.org  Sun Mar  7 18:55:47 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 07 Mar 2021 23:55:47 +0000
Subject: [issue43428] Sync importlib_metadata enhancements through 3.7.
In-Reply-To: <1615157667.11.0.27235417477.issue43428@roundup.psfhosted.org>
Message-ID: <1615161347.68.0.752884842453.issue43428@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
keywords: +patch
pull_requests: +23548
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24782

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43428>
_______________________________________

From report at bugs.python.org  Sun Mar  7 19:58:27 2021
From: report at bugs.python.org (Suhail S.)
Date: Mon, 08 Mar 2021 00:58:27 +0000
Subject: [issue43430] Exception raised when attempting to create Enum via
 functional API
Message-ID: <1615165107.75.0.80264384575.issue43430@roundup.psfhosted.org>


New submission from Suhail S. <suhailsingh247 at gmail.com>:

It is possible to create custom Enum classes with a metaclass that is a subtype of EnumMeta. It is also possible to inherit from such an enumeration to create another enumeration. However, attempting to do so via the functional API raises an exception. See attached file that highlights minimal failing test case.

----------
components: Library (Lib)
files: test.py
messages: 388255
nosy: suhailsingh247
priority: normal
severity: normal
status: open
title: Exception raised when attempting to create Enum via functional API
type: crash
versions: Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49855/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43430>
_______________________________________

From report at bugs.python.org  Sun Mar  7 20:01:52 2021
From: report at bugs.python.org (Suhail S.)
Date: Mon, 08 Mar 2021 01:01:52 +0000
Subject: [issue43430] Exception raised when attempting to create Enum via
 functional API
In-Reply-To: <1615165107.75.0.80264384575.issue43430@roundup.psfhosted.org>
Message-ID: <1615165312.16.0.672667611123.issue43430@roundup.psfhosted.org>


Change by Suhail S. <suhailsingh247 at gmail.com>:


----------
nosy: +barry, eli.bendersky, ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43430>
_______________________________________

From report at bugs.python.org  Sun Mar  7 21:02:57 2021
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 08 Mar 2021 02:02:57 +0000
Subject: [issue43430] Exception raised when attempting to create Enum via
 functional API
In-Reply-To: <1615165107.75.0.80264384575.issue43430@roundup.psfhosted.org>
Message-ID: <1615168977.09.0.122189712537.issue43430@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
assignee:  -> ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43430>
_______________________________________

From report at bugs.python.org  Sun Mar  7 22:38:04 2021
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 08 Mar 2021 03:38:04 +0000
Subject: [issue43332] Make http.client._tunnel send one byte string over the
 network
In-Reply-To: <1614370680.1.0.103129903648.issue43332@roundup.psfhosted.org>
Message-ID: <1615174684.43.0.692235505128.issue43332@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
versions: +Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43332>
_______________________________________

From report at bugs.python.org  Sun Mar  7 22:44:58 2021
From: report at bugs.python.org (Sergey B Kirpichev)
Date: Mon, 08 Mar 2021 03:44:58 +0000
Subject: [issue43420] Optimize rational arithmetics
In-Reply-To: <1615156464.6.0.889237220078.issue43420@roundup.psfhosted.org>
Message-ID: <YEWdtWmzwpRMAgvI@note>


Sergey B Kirpichev <skirpichev at gmail.com> added the comment:

On Sun, Mar 07, 2021 at 10:34:24PM +0000, Aaron Meurer wrote:
> I'm surprised to hear that the "typical use-case" of Fraction
> is fractions converted from floats.

For statistics module - that may be true.  Unfortunately, no
(other) practical applications, using Fraction's, were proposed by
my reviewers so far.

> By the way, the "algorithm" here really isn't that
> complicated. I didn't even realize it had a name.

Rather "algorithms"; everything is there in the II-nd volume of
the Knuth, section 4.5 - Rational Arithmetic.  Probably, this
is even a better reference, since it explains gcd==1 case
for addition.  Both, however, reference the Henrici article.

> It's far less complicated than, for example, Lehmer's gcd
> algorithm (which is implemented in math.gcd).

Or Karatsuba multiplication.

BTW, low-denominators performance may be restored (at least
partially), using same approach (like KARATSUBA_CUTOFF - but
checking the maximal denominator).  I don't like this idea, but...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43420>
_______________________________________

From report at bugs.python.org  Sun Mar  7 23:04:28 2021
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 08 Mar 2021 04:04:28 +0000
Subject: [issue31466] No easy way to change float formatting when subclassing
 encoder.JSONEncoder
In-Reply-To: <1505382493.14.0.667053401798.issue31466@psf.upfronthosting.co.za>
Message-ID: <1615176268.79.0.0165860312157.issue31466@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/issue31466>
_______________________________________

From report at bugs.python.org  Mon Mar  8 00:41:46 2021
From: report at bugs.python.org (Jordan Macdonald)
Date: Mon, 08 Mar 2021 05:41:46 +0000
Subject: [issue43431] Subprocess timeout causes output to be returned as bytes
 in text mode
Message-ID: <1615182106.34.0.569482281722.issue43431@roundup.psfhosted.org>


New submission from Jordan Macdonald <macdjord at gmail.com>:

Passing the argument `text=True` to `subprocess.run()` is supposed to mean that any captured output of the called process is automatically decoded and retuned to the user as test instead of bytes.

However, if you give a timeout and that timeout expires, the raised `subprocess.TimeoutExpired` exception will have the captured output as as bytes even if text mode is enabled.

Test output:
bash-5.0$ python3 test_subprocess.py
Version and interpreter information: namespace(_multiarch='x86_64-linux-gnu', cache_tag='cpython-37', hexversion=50792432, name='cpython', version=sys.version_info(major=3, minor=7, micro=7, releaselevel='final', serial=0))
Completed STDOUT Type: <class 'str'>
Completed STDOUT Content: 'Start\nDone\n'
Timeout STDOUT Type: <class 'bytes'>
Timeout STDOUT Content: b'Start\n'

----------
components: Library (Lib)
files: test_subprocess.py
messages: 388257
nosy: macdjord
priority: normal
severity: normal
status: open
title: Subprocess timeout causes output to be returned as bytes in text mode
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file49856/test_subprocess.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43431>
_______________________________________

From report at bugs.python.org  Mon Mar  8 02:35:27 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 08 Mar 2021 07:35:27 +0000
Subject: [issue43332] Make http.client._tunnel send one byte string over the
 network
In-Reply-To: <1614370680.1.0.103129903648.issue43332@roundup.psfhosted.org>
Message-ID: <1615188927.57.0.1688103074.issue43332@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:


New changeset c25910a135c2245accadb324b40dd6453015e056 by Gregory P. Smith in branch 'master':
bpo-43332: Buffer proxy connection setup packets before sending. (GH-24780)
https://github.com/python/cpython/commit/c25910a135c2245accadb324b40dd6453015e056


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43332>
_______________________________________

From report at bugs.python.org  Mon Mar  8 02:37:14 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 08 Mar 2021 07:37:14 +0000
Subject: [issue43332] Make http.client._tunnel send one byte string over the
 network
In-Reply-To: <1614370680.1.0.103129903648.issue43332@roundup.psfhosted.org>
Message-ID: <1615189034.64.0.373284453134.issue43332@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: +23549
pull_request: https://github.com/python/cpython/pull/24783

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43332>
_______________________________________

From report at bugs.python.org  Mon Mar  8 02:59:56 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 08 Mar 2021 07:59:56 +0000
Subject: [issue43332] Make http.client._tunnel send one byte string over the
 network
In-Reply-To: <1614370680.1.0.103129903648.issue43332@roundup.psfhosted.org>
Message-ID: <1615190396.74.0.0604922956565.issue43332@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c6e7cf1ee09c88d35e6703c33a61eca7b9db54f3 by Miss Islington (bot) in branch '3.9':
bpo-43332: Buffer proxy connection setup packets before sending. (GH-24780)
https://github.com/python/cpython/commit/c6e7cf1ee09c88d35e6703c33a61eca7b9db54f3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43332>
_______________________________________

From report at bugs.python.org  Mon Mar  8 05:19:40 2021
From: report at bugs.python.org (Sergey B Kirpichev)
Date: Mon, 08 Mar 2021 10:19:40 +0000
Subject: [issue43420] Optimize rational arithmetics
In-Reply-To: <1615119396.33.0.0908367369226.issue43420@roundup.psfhosted.org>
Message-ID: <YEX6N4L1PXdyW61/@note>


Sergey B Kirpichev <skirpichev at gmail.com> added the comment:

On Sun, Mar 07, 2021 at 12:16:36PM +0000, Mark Dickinson wrote:
> but not the "incompatible denominators" part. :-) The typical use there is
> that those fractions have been converted from floats

But there is no limits to use Fraction's for input, e.g. there are
docstring examples for mean() and variance().  In that case (general one for
a summation) - common denominators is a very special situation.

> Thanks for the timings! So assuming that wasn't a specially-chosen best case example

No, but this will handle the first branch.

> > It's not going to be complicated so much
> For me, the big difference is that the current code is obviously correct

That may be fixed by keeping relevant references right in the code, not
in the commit message.  Python sources have many much more non-trivial
algorithms...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43420>
_______________________________________

From report at bugs.python.org  Mon Mar  8 06:16:38 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 08 Mar 2021 11:16:38 +0000
Subject: [issue43353] Document that logging.getLevelName() can return a
 numeric value.
In-Reply-To: <1614600000.66.0.180359096956.issue43353@roundup.psfhosted.org>
Message-ID: <1615202198.23.0.231853834673.issue43353@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset bbba28212ce0f58096a4043f32442c6e727b74fc by Mariusz Felisiak in branch 'master':
bpo-43353: Document that logging.getLevelName() accepts string representation of logging level. (GH-24693)
https://github.com/python/cpython/commit/bbba28212ce0f58096a4043f32442c6e727b74fc


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43353>
_______________________________________

From report at bugs.python.org  Mon Mar  8 07:05:40 2021
From: report at bugs.python.org (parsa mpsh)
Date: Mon, 08 Mar 2021 12:05:40 +0000
Subject: [issue43432] Add function `clear` to the `os` module
Message-ID: <1615205140.87.0.702709667317.issue43432@roundup.psfhosted.org>


New submission from parsa mpsh <parsampsh at gmail.com>:

I wanna add a new function named `clear` to the os module.
This function runs the `clear` command in the os.
but this function checks that is os windows, if yes, runs `cls`.
I'm working on my patch.

----------
components: Library (Lib)
messages: 388262
nosy: parsampsh
priority: normal
severity: normal
status: open
title: Add function `clear` to the `os` module
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43432>
_______________________________________

From report at bugs.python.org  Mon Mar  8 07:29:16 2021
From: report at bugs.python.org (OndrejPtak)
Date: Mon, 08 Mar 2021 12:29:16 +0000
Subject: [issue43433] xmlrpc.client ignores query in URI ("?action=xmlrpc2")
 from python-3.9
Message-ID: <1615206556.6.0.195752820504.issue43433@roundup.psfhosted.org>


New submission from OndrejPtak <ondrej.ptak at gmail.com>:

xmlrpc.client proxy behaviour changed and broke tools depending on URI containing query part.

Last working version: https://github.com/python/cpython/blob/3.8/Lib/xmlrpc/client.py#L1417

Changed behaviour here: https://github.com/python/cpython/blob/3.9/Lib/xmlrpc/client.py#L1424

Is this change intended? If so, what is recommended solution for xmlrpc client communicating with URI: http://example.com/path?var=foo ?

----------
messages: 388263
nosy: OndrejPtak
priority: normal
severity: normal
status: open
title: xmlrpc.client ignores query in URI ("?action=xmlrpc2") from python-3.9
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43433>
_______________________________________

From report at bugs.python.org  Mon Mar  8 07:29:34 2021
From: report at bugs.python.org (OndrejPtak)
Date: Mon, 08 Mar 2021 12:29:34 +0000
Subject: [issue43433] xmlrpc.client ignores query in URI ("?action=xmlrpc2")
 since python-3.9
In-Reply-To: <1615206556.6.0.195752820504.issue43433@roundup.psfhosted.org>
Message-ID: <1615206574.73.0.141683626835.issue43433@roundup.psfhosted.org>


Change by OndrejPtak <ondrej.ptak at gmail.com>:


----------
title: xmlrpc.client ignores query in URI ("?action=xmlrpc2") from python-3.9 -> xmlrpc.client ignores query in URI ("?action=xmlrpc2") since python-3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43433>
_______________________________________

From report at bugs.python.org  Mon Mar  8 07:53:59 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 08 Mar 2021 12:53:59 +0000
Subject: [issue43434] sqlite3.Connection(...) bypasses 'sqlite3.connect' audit
 hooks
Message-ID: <1615208039.92.0.863639207352.issue43434@roundup.psfhosted.org>


New submission from Erlend Egeberg Aasland <erlend.aasland at innova.no>:

The module level connect method is guarded by PySys_Audit(), but sqlite3.Connection.__init__() is not. It is possible to bypass the module level connect() method simply by creating a new sqlite3.Connection object directly.

Easily fixed by either moving the PySys_Audit() check to pysqlite_connection_init(), or by adding an extra check in pysqlite_connection_init().


>>> import sqlite3, sys
>>> def hook(s, e):
...     if s == 'sqlite3.connect':
...             raise PermissionError
... 
>>> sys.addaudithook(hook)
>>> sqlite3.connect(':memory:')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in hook
PermissionError
>>> sqlite3.Connection(':memory:')
<sqlite3.Connection object at 0x7f94b0157a80>

----------
components: Library (Lib)
files: audit.py
messages: 388264
nosy: berker.peksag, erlendaasland, steve.dower
priority: normal
severity: normal
status: open
title: sqlite3.Connection(...) bypasses 'sqlite3.connect' audit hooks
type: security
versions: Python 3.10, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49857/audit.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43434>
_______________________________________

From report at bugs.python.org  Mon Mar  8 07:54:11 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 08 Mar 2021 12:54:11 +0000
Subject: [issue43434] sqlite3.Connection(...) bypasses 'sqlite3.connect' audit
 hooks
In-Reply-To: <1615208039.92.0.863639207352.issue43434@roundup.psfhosted.org>
Message-ID: <1615208051.45.0.101484177656.issue43434@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


----------
keywords: +patch
Added file: https://bugs.python.org/file49858/patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43434>
_______________________________________

From report at bugs.python.org  Mon Mar  8 07:56:02 2021
From: report at bugs.python.org (parsa mpsh)
Date: Mon, 08 Mar 2021 12:56:02 +0000
Subject: [issue43432] Add function `clear` to the `os` module
In-Reply-To: <1615205140.87.0.702709667317.issue43432@roundup.psfhosted.org>
Message-ID: <1615208162.02.0.829402651274.issue43432@roundup.psfhosted.org>


Change by parsa mpsh <parsampsh at gmail.com>:


----------
keywords: +patch
pull_requests: +23550
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24784

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43432>
_______________________________________

From report at bugs.python.org  Mon Mar  8 07:58:06 2021
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 08 Mar 2021 12:58:06 +0000
Subject: [issue43431] Subprocess timeout causes output to be returned as bytes
 in text mode
In-Reply-To: <1615182106.34.0.569482281722.issue43431@roundup.psfhosted.org>
Message-ID: <1615208286.15.0.324104399783.issue43431@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

communicate() is incomplete, so decoding the output may fail. For example, say the encoding is UTF-8, and the last multibyte character sequence (2-4 bytes) is incomplete. Maybe communicate() should always set `stdout_bytes` and `stderr_bytes` attributes on the timeout exception, and, in text mode, try to decode the output as `stdout` and/or `stderr`. If decoding fails, set the decoded value to None.

In Windows, run() tries to complete communication, which is dysfunctional in cases. I created bpo-43346 to propose changing the design in Windows, in order to address 3 cases that can cause subprocess.run() to ignore the given timeout. The proposed change also sets an incomplete read of stdout and stderr as bytes objects, regardless of text mode, because I was simply matching what POSIX does in this case.

----------
nosy: +eryksun, giampaolo.rodola
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43431>
_______________________________________

From report at bugs.python.org  Mon Mar  8 08:39:53 2021
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 08 Mar 2021 13:39:53 +0000
Subject: [issue43432] Add function `clear` to the `os` module
In-Reply-To: <1615205140.87.0.702709667317.issue43432@roundup.psfhosted.org>
Message-ID: <1615210793.14.0.43905472709.issue43432@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

The idea of adding some kind of clear_screen() function in the os or shutil module was discussed extensively on python-ideas a few months ago:

https://mail.python.org/archives/list/python-ideas at python.org/thread/EWQ2BOL3WVZAU2V2MT3HLXN3AEBHANNZ
https://mail.python.org/archives/list/python-ideas at python.org/thread/N2G5MDPST6IMUQCK6LLAUOVIJIOOC2XJ

I would not want to clear the terminal scrollback buffer, in which case the implementation in Windows would need to use the console API and/or VT sequences instead of the CMD shell's CLS command.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43432>
_______________________________________

From report at bugs.python.org  Mon Mar  8 08:42:54 2021
From: report at bugs.python.org (confd0)
Date: Mon, 08 Mar 2021 13:42:54 +0000
Subject: [issue43285] ftplib use host from PASV response
In-Reply-To: <1613908174.7.0.0578051462677.issue43285@roundup.psfhosted.org>
Message-ID: <1615210974.6.0.688138488376.issue43285@roundup.psfhosted.org>


confd0 <ricexdream at gmail.com> added the comment:

Any response here? If you need more information let me know.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43285>
_______________________________________

From report at bugs.python.org  Mon Mar  8 10:31:33 2021
From: report at bugs.python.org (David Wood)
Date: Mon, 08 Mar 2021 15:31:33 +0000
Subject: [issue43435] Py_BuildValue("y#".... returns incomplete result
Message-ID: <1615217493.05.0.795009945001.issue43435@roundup.psfhosted.org>


New submission from David Wood <dwoodjunkmail at gmail.com>:

I have a c function to encrypt values which returns an array of bytes.  The function returns proper values outside of python.  When used as a python function, the result is incomplete usually 10-20% of the time.  If I add a sleep(1) call before returning from the function, my success rate goes to 100%.  While this works, it is unacceptable as it will create enormous latency in my application.

static PyObject *method_encrypt(PyObject *self, PyObject *args) {
	char *keyval, *str = NULL, output[512];
	Py_ssize_t count=0;
	PyObject *retval;

	if(!PyArg_ParseTuple(args, "ss", &str, &keyval)) {
		return NULL;
	}

	encryptBlowfishCfb(str, &count, output, keyval);

	retval = Py_BuildValue("y#", output, count);
	//sleep(1);
	return retval;
}

----------
components: C API
messages: 388268
nosy: dwoodjunkmail
priority: normal
severity: normal
status: open
title: Py_BuildValue("y#".... returns incomplete result
type: performance
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43435>
_______________________________________

From report at bugs.python.org  Mon Mar  8 10:37:40 2021
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 08 Mar 2021 15:37:40 +0000
Subject: [issue43435] Py_BuildValue("y#".... returns incomplete result
In-Reply-To: <1615217493.05.0.795009945001.issue43435@roundup.psfhosted.org>
Message-ID: <1615217860.19.0.788565792522.issue43435@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

What do you mean by "incomplete"? Does it return less data or invalid data? Could you please paste your implementation of encryptBlowfishCfb(), too?

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43435>
_______________________________________

From report at bugs.python.org  Mon Mar  8 11:00:00 2021
From: report at bugs.python.org (David Wood)
Date: Mon, 08 Mar 2021 16:00:00 +0000
Subject: [issue43435] Py_BuildValue("y#".... returns incomplete result
In-Reply-To: <1615217493.05.0.795009945001.issue43435@roundup.psfhosted.org>
Message-ID: <1615219200.65.0.760521127878.issue43435@roundup.psfhosted.org>


David Wood <dwoodjunkmail at gmail.com> added the comment:

I have not gone to the extent of comparing the direct output against what python gets, although it appears to be incomplete.  The following is my encrypt function which has been used successfully for many years in a separate c program, so I have high confidence in it.

char * encryptBlowfishCfb(const char * inStr, Py_ssize_t *count, char * output, char * encrkey) {
	MCRYPT td;
	char IV[10];
	int len, i;
	char block_buffer[512];
	time_t t;

	srand((unsigned) time(&t));
	strcpy(IV, "");
	for (i = 0 ; i < 8 ; i++ ) {
		IV[i] =  mset[(rand() % 62)];
	}
	td = mcrypt_module_open(MCRYPT_BLOWFISH, NULL, MCRYPT_CFB, NULL);
	mcrypt_generic_init(td, encrkey, strlen(encrkey), IV);
	memset(block_buffer, 0, sizeof(block_buffer));
	strcpy(block_buffer, inStr);
	i = strlen(inStr);
	mcrypt_generic(td, &block_buffer, i);
	block_buffer[i] = '\0';
	strcpy(&block_buffer[i], IV);
	mcrypt_generic_deinit(td);
	mcrypt_module_close(td);

	len = i + 8 + 1;
	memset(output, 0, 512);
	strncpy(output, block_buffer, len -1);
	*count = i + 8;

	return output;
}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43435>
_______________________________________

From report at bugs.python.org  Mon Mar  8 12:12:28 2021
From: report at bugs.python.org (Dan Snider)
Date: Mon, 08 Mar 2021 17:12:28 +0000
Subject: [issue43436] bounded _lru_cache_wrapprer behaves as if typed=True
 when it wasn't
Message-ID: <1615223548.2.0.417347822108.issue43436@roundup.psfhosted.org>


New submission from Dan Snider <mr.assume.away at gmail.com>:

Isn't the point of setting typed=True to make it so that e.g. True doesn't register as a hit when there is already a cache entry for 1.0? Assuming that is the case, although this report specifically targets 3.8 I found no indication that what I believe is the cause of this has been fixed in the interim.

def test():
    from functools import lru_cache
    class No1:
        __eq__ = 0 .__eq__
        __hash__ = 0 .__hash__
    class No2:
        __eq__ = (0,).__contains__
        def __hash__(self, /): return hash(0)
    @lru_cache(256, typed=False)
    def test(v): return [v]
    test(No1()), test(No1()), test(0.0), test(0)
    
    print(test.cache_info())
    @lru_cache(256, typed=False)
    def test(v): return [v]
    test(No2()), test(No2()), test(0.0), test(0)
    print(test.cache_info())


    CacheInfo(hits=0, misses=4, maxsize=256, currsize=4)
CacheInfo(hits=2, misses=2, maxsize=256, currsize=2)

----------
messages: 388271
nosy: bup
priority: normal
severity: normal
status: open
title: bounded _lru_cache_wrapprer behaves as if typed=True when it wasn't
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43436>
_______________________________________

From report at bugs.python.org  Mon Mar  8 12:25:33 2021
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 08 Mar 2021 17:25:33 +0000
Subject: [issue43436] bounded _lru_cache_wrapprer behaves as if typed=True
 when it wasn't
In-Reply-To: <1615223548.2.0.417347822108.issue43436@roundup.psfhosted.org>
Message-ID: <1615224333.3.0.0987787937793.issue43436@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/issue43436>
_______________________________________

From report at bugs.python.org  Mon Mar  8 12:30:10 2021
From: report at bugs.python.org (Jordan Macdonald)
Date: Mon, 08 Mar 2021 17:30:10 +0000
Subject: [issue43431] Subprocess timeout causes output to be returned as bytes
 in text mode
In-Reply-To: <1615182106.34.0.569482281722.issue43431@roundup.psfhosted.org>
Message-ID: <1615224610.17.0.225077111313.issue43431@roundup.psfhosted.org>


Jordan Macdonald <macdjord at gmail.com> added the comment:

Eryk Sun: Well, I think step 1 should be to update the documentation for Python 3.7 through 3.10 on `subprocess.run()` and `subprocess.TimeoutExpired` to clearly state that `TimeoutExpired.stdout` and `TimeoutExpired.stderr` will be in bytes format even if text mode is set.

If we went with the model of having `stdout_bytes` and attempting to decode into `stdout`, we'd want an option to ignore a trailing decoding error.

----------
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43431>
_______________________________________

From report at bugs.python.org  Mon Mar  8 12:47:04 2021
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 08 Mar 2021 17:47:04 +0000
Subject: [issue43435] Py_BuildValue("y#".... returns incomplete result
In-Reply-To: <1615217493.05.0.795009945001.issue43435@roundup.psfhosted.org>
Message-ID: <1615225624.78.0.196692982525.issue43435@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Does mcrypt_generic() output base64 or ASCII-only data? Since you are converting the output to bytes, I assume the output may contain any byte. In that case strcpy() is not safe. You have to use memcpy().

Fun fact: Nintendo had a similar bug many years ago, check out "trucha bug"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43435>
_______________________________________

From report at bugs.python.org  Mon Mar  8 13:01:52 2021
From: report at bugs.python.org (parsa mpsh)
Date: Mon, 08 Mar 2021 18:01:52 +0000
Subject: [issue43432] Add function `clear` to the `os` module
In-Reply-To: <1615205140.87.0.702709667317.issue43432@roundup.psfhosted.org>
Message-ID: <1615226512.08.0.864226253044.issue43432@roundup.psfhosted.org>


parsa mpsh <parsampsh at gmail.com> added the comment:

Well, some times we are writing a flexible Text ui program. we may use `clear` lot of times. This should be used when we haven't any valuable data on the screen. Also, who that uses this function, knows this will clear valuable data :). Sometimes also i use this command. but every time a should check that is this operation windows or not, to determine `clear` or `cls`. I think this is very helpful for making this easier.
The best feature of Python is its simplicity and power. More helper functions to make the code shorter and knowable, is a good thing for Python. Also about the Windows API instead of `cls`, i don't know more thing. But i think its not a big problem and `cls` works.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43432>
_______________________________________

From report at bugs.python.org  Mon Mar  8 13:12:38 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 08 Mar 2021 18:12:38 +0000
Subject: [issue43432] Add function `clear` to the `os` module
In-Reply-To: <1615205140.87.0.702709667317.issue43432@roundup.psfhosted.org>
Message-ID: <1615227158.7.0.620035122607.issue43432@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

If you write a flexible Text ui program, you should use functions provided by a text ui library which you use to clear the screen or a part of screen.

If you want to call an external command, use os.system(), os.popen() or more flexible subprocess module. But I do not think it will help with Text UI.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43432>
_______________________________________

From report at bugs.python.org  Mon Mar  8 13:17:00 2021
From: report at bugs.python.org (Jeff Moguillansky)
Date: Mon, 08 Mar 2021 18:17:00 +0000
Subject: [issue43437] venv activate bash script has wrong line endings on
 windows
Message-ID: <1615227420.16.0.158256767394.issue43437@roundup.psfhosted.org>


New submission from Jeff Moguillansky <jmoguill2 at gmail.com>:

when running python.exe -m venv on Windows,
It creates several activate scripts.
The activate bash script has the wrong line endings (it should be unix-style, not windows-style).
Bash scripts should always end with unix style line endings

----------
components: Windows
messages: 388276
nosy: jmoguill2, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: venv activate bash script has wrong line endings on windows
type: compile error
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43437>
_______________________________________

From report at bugs.python.org  Mon Mar  8 13:17:58 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2021 18:17:58 +0000
Subject: [issue8304] time.strftime() and Unicode characters on Windows
In-Reply-To: <1270307324.04.0.0348018847246.issue8304@psf.upfronthosting.co.za>
Message-ID: <1615227478.93.0.8939389578.issue8304@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

>  time.tzset() should be implemented

I'm not sure of what you mean. The function is implemented:

static PyObject *
time_tzset(PyObject *self, PyObject *unused)
{
    PyObject* m;

    m = PyImport_ImportModuleNoBlock("time");
    if (m == NULL) {
        return NULL;
    }

    tzset();

    /* Reset timezone, altzone, daylight and tzname */
    if (init_timezone(m) < 0) {
         return NULL;
    }
    Py_DECREF(m);
    if (PyErr_Occurred())
        return NULL;

    Py_RETURN_NONE;
}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8304>
_______________________________________

From report at bugs.python.org  Mon Mar  8 13:24:15 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2021 18:24:15 +0000
Subject: [issue43422] Revert _decimal C API changes
In-Reply-To: <1615043906.44.0.566874098139.issue43422@roundup.psfhosted.org>
Message-ID: <1615227855.96.0.325650172307.issue43422@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I have a concern about the current _decimal C API: bpo-43060. I'm fine with removing it in Python 3.10, and add it back fixed in Python 3.11 or later.

> I can turn it into a PR but first I'd like to gather reactions here.

Go ahead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43422>
_______________________________________

From report at bugs.python.org  Mon Mar  8 13:25:07 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2021 18:25:07 +0000
Subject: [issue10653] test_time test_strptime fails on windows
In-Reply-To: <1291820491.4.0.666293971337.issue10653@psf.upfronthosting.co.za>
Message-ID: <1615227907.18.0.590767685764.issue10653@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Eryk Sun: This issue is now closed. If you want to enhance the time module, please open a new issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10653>
_______________________________________

From report at bugs.python.org  Mon Mar  8 13:25:28 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2021 18:25:28 +0000
Subject: [issue36779] time.tzname returns empty string on Windows if default
 codepage is a Unicode codepage
In-Reply-To: <1556844322.34.0.979846087129.issue36779@roundup.psfhosted.org>
Message-ID: <1615227928.79.0.707937837938.issue36779@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36779>
_______________________________________

From report at bugs.python.org  Mon Mar  8 13:41:00 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2021 18:41:00 +0000
Subject: [issue43416] Add README files in Include/cpython and Include/internal
In-Reply-To: <1615020265.58.0.71326223935.issue43416@roundup.psfhosted.org>
Message-ID: <1615228860.98.0.384496840856.issue43416@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

* Include/internal/ with extern: C API which must not and can not be used outside CPython code base, only stdlib extensions built as built-in extensions can use it.

* Include/internal/ with PyAPI_FUNC/PyAPI_DATA: API which should be be used outside CPython, but exposed for specific use cases like debuggers and profilers. Structures are exposed for debuggers and profilers which don't want to execute code to avoid the risk of any unwanted side effect.

* Include/cpython/: Public C API excluded from the limited C API (Py_LIMITED_API macro) and the stable ABI (PEP 384).

* Include/: Public limited C API and the stable ABI (PEP 384).

In case of doubt, new C API must be added to the internal C API using extern.

I would suggest a public discussion before adding any new C API to Include/cpython/ or Include/

No new functions stealing references or returning borrowed references must be added to public C API (limited or not). A strong reference must be returned.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43416>
_______________________________________

From report at bugs.python.org  Mon Mar  8 13:49:24 2021
From: report at bugs.python.org (Kamil Turek)
Date: Mon, 08 Mar 2021 18:49:24 +0000
Subject: [issue43427] Possible error on the descriptor howto guide
In-Reply-To: <1615131755.48.0.550524446603.issue43427@roundup.psfhosted.org>
Message-ID: <1615229364.29.0.5763167686.issue43427@roundup.psfhosted.org>


Kamil Turek <tazzu at live.com> added the comment:

I think there isn't any error. Please look at the example provided in the guide:

class E:
    @staticmethod
    def f(x):
        print(x)

>>> E.f(3)
3

If it were as you say, method would receive two arguments - f(E, 3) - which is wrong.

----------
nosy: +kamilturek

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43427>
_______________________________________

From report at bugs.python.org  Mon Mar  8 13:54:23 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2021 18:54:23 +0000
Subject: [issue43359] Dead assignment in Py_UniversalNewlineFgets
In-Reply-To: <1614651387.39.0.0295195640102.issue43359@roundup.psfhosted.org>
Message-ID: <1615229663.81.0.572417199297.issue43359@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

>     c = 'x'; /* Shut up gcc warning */

IMHO this code is fine and should be kept. I hate fighting against stupid false alarms of compiler warnings. This code is harmless. It doesn't affect performances or anything.

I suggest to close this issue and its PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43359>
_______________________________________

From report at bugs.python.org  Mon Mar  8 13:56:42 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2021 18:56:42 +0000
Subject: [issue28356] [easy doc] Document os.rename() behavior on Windows when
 src and dst are on different filesystems
In-Reply-To: <1475588552.47.0.916118565333.issue28356@psf.upfronthosting.co.za>
Message-ID: <1615229802.9.0.570966145761.issue28356@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +easy, newcomer friendly
title: Windows: os.rename different in python 2.7.12 and python 3.5.2 -> [easy doc] Document os.rename() behavior on Windows when src and dst are on different filesystems

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28356>
_______________________________________

From report at bugs.python.org  Mon Mar  8 13:57:11 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2021 18:57:11 +0000
Subject: [issue28356] [easy doc] Document os.rename() behavior on Windows when
 src and dst are on different filesystems
In-Reply-To: <1475588552.47.0.916118565333.issue28356@psf.upfronthosting.co.za>
Message-ID: <1615229831.01.0.502943482833.issue28356@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

This issue is now a matter of *documenting* the Windows behavior. Is there any volunteer to propose a PR?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28356>
_______________________________________

From report at bugs.python.org  Mon Mar  8 14:02:42 2021
From: report at bugs.python.org (Kamil Turek)
Date: Mon, 08 Mar 2021 19:02:42 +0000
Subject: [issue43430] Exception raised when attempting to create Enum via
 functional API
In-Reply-To: <1615165107.75.0.80264384575.issue43430@roundup.psfhosted.org>
Message-ID: <1615230162.52.0.840801945162.issue43430@roundup.psfhosted.org>


Change by Kamil Turek <tazzu at live.com>:


----------
nosy: +kamilturek

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43430>
_______________________________________

From report at bugs.python.org  Mon Mar  8 14:02:53 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2021 19:02:53 +0000
Subject: [issue28712] Non-Windows mappings for a couple of Windows code pages
In-Reply-To: <1479274828.26.0.726447169651.issue28712@psf.upfronthosting.co.za>
Message-ID: <1615230173.29.0.391931901707.issue28712@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28712>
_______________________________________

From report at bugs.python.org  Mon Mar  8 14:08:52 2021
From: report at bugs.python.org (Alex Henrie)
Date: Mon, 08 Mar 2021 19:08:52 +0000
Subject: [issue43359] Dead assignment in Py_UniversalNewlineFgets
In-Reply-To: <1614651387.39.0.0295195640102.issue43359@roundup.psfhosted.org>
Message-ID: <1615230532.68.0.82598576014.issue43359@roundup.psfhosted.org>


Alex Henrie <alexhenrie24 at gmail.com> added the comment:

Hi Victor, just so we're all on the same page, removing the line does not trigger a compiler warning. The comment on this line is misleading.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43359>
_______________________________________

From report at bugs.python.org  Mon Mar  8 14:10:18 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 08 Mar 2021 19:10:18 +0000
Subject: [issue43436] bounded _lru_cache_wrapprer behaves as if typed=True
 when it wasn't
In-Reply-To: <1615223548.2.0.417347822108.issue43436@roundup.psfhosted.org>
Message-ID: <1615230618.4.0.490461310458.issue43436@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks for the report, but this isn't a bug.

Setting typed=True guarantees that types are treated as distinct entries.

Setting typed=False means that the implementation MAY ignore the type and only use equality, but it is not required to do so.   If it is convenient for the implementation, it may use type to save space.  Currently int and str are treated as distinct from other types that may be equal to them.

Likewise, the implementation is allowed to treat different argument patterns as distinct even if they are equal.  Currently, we treat pow(2, 5) as distinct from pow(base=2, exp=5) which is itself distinct from pow(exp=5, base=2).

----------
assignee:  -> rhettinger
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43436>
_______________________________________

From report at bugs.python.org  Mon Mar  8 14:14:50 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 08 Mar 2021 19:14:50 +0000
Subject: [issue43427] Possible error on the descriptor howto guide
In-Reply-To: <1615131755.48.0.550524446603.issue43427@roundup.psfhosted.org>
Message-ID: <1615230890.55.0.902666353986.issue43427@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: docs at python -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43427>
_______________________________________

From report at bugs.python.org  Mon Mar  8 14:17:29 2021
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 08 Mar 2021 19:17:29 +0000
Subject: [issue8304] time.strftime() and Unicode characters on Windows
In-Reply-To: <1270307324.04.0.0348018847246.issue8304@psf.upfronthosting.co.za>
Message-ID: <1615231049.09.0.0223769874616.issue8304@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> I'm not sure of what you mean. The function is implemented:

My comment was limited to Windows, for which time.tzset() has never been implemented. Since Python has its own implementation of time.tzname in Windows, it should also implement time.tzset() to allow refreshing the value. Actually, ucrt implements C _tzset(), so the implementation of time.tzset() in Windows also has to call C _tzset() to update _tzname (and also ucrt's new private __wide_tzname), in addition to calling GetTimeZoneInformation() to update its own time.tzname value. 

Another difference with Python's time.tzname and C strftime("%Z") is that  ucrt will use the TZ environment variable, but Python's implementation of time.tzname in Windows does not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8304>
_______________________________________

From report at bugs.python.org  Mon Mar  8 14:22:16 2021
From: report at bugs.python.org (=?utf-8?q?=C3=81lvaro_Justen?=)
Date: Mon, 08 Mar 2021 19:22:16 +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: <1615231336.97.0.15812245017.issue38119@roundup.psfhosted.org>


?lvaro Justen <alvarojusten at gmail.com> added the comment:

Based on changes at https://github.com/python/cpython/pull/15989 I've monkey-patched `multiprocessing.resource_tracker` so my current applications (running on Python 3.9.2) won't be affected. The code may be useful to others while the PR is not merged and we don't have a new release - you just need to call the `remove_shm_from_resource_tracker` function inside each Process target function.

----- >8 -----
from multiprocessing import resource_tracker


def remove_shm_from_resource_tracker():
    """Monkey-patch multiprocessing.resource_tracker so SharedMemory won't be tracked

    More details at: https://bugs.python.org/issue38119
    """

    def fix_register(name, rtype):
        if rtype == "shared_memory":
            return
        return resource_tracker._resource_tracker.register(self, name, rtype)
    resource_tracker.register = fix_register

    def fix_unregister(name, rtype):
        if rtype == "shared_memory":
            return
        return resource_tracker._resource_tracker.unregister(self, name, rtype)
    resource_tracker.unregister = fix_unregister

    if "shared_memory" in resource_tracker._CLEANUP_FUNCS:
        del resource_tracker._CLEANUP_FUNCS["shared_memory"]
----- 8< -----

There's a working example in attached file `mprt_monkeypatch.py` (if you comment the function calls on lines 28 and 37 the warnings will be shown).

----------
nosy: +turicas
Added file: https://bugs.python.org/file49859/mprt_monkeypatch.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38119>
_______________________________________

From report at bugs.python.org  Mon Mar  8 14:23:39 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2021 19:23:39 +0000
Subject: [issue19809] Doc: subprocess should warn uses on race conditions when
 multiple threads spawn child processes
In-Reply-To: <1385544646.44.0.340337636792.issue19809@psf.upfronthosting.co.za>
Message-ID: <1615231419.08.0.335468953095.issue19809@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> PEP 443

I guess that you mean the PEP 446 ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19809>
_______________________________________

From report at bugs.python.org  Mon Mar  8 14:28:19 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2021 19:28:19 +0000
Subject: [issue43271] AMD64 Windows10 3.x crash with Windows fatal exception:
 stack overflow
In-Reply-To: <1613766414.64.0.363657915419.issue43271@roundup.psfhosted.org>
Message-ID: <1615231699.19.0.851514157236.issue43271@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thanks for the fix David Bolen ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43271>
_______________________________________

From report at bugs.python.org  Mon Mar  8 14:36:37 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2021 19:36:37 +0000
Subject: [issue43233] test_os: test_copy_file_range_offset fails on FreeBSD
 CURRENT
In-Reply-To: <1613417170.64.0.402539389952.issue43233@roundup.psfhosted.org>
Message-ID: <1615232197.83.0.837495741716.issue43233@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

It was a FreeBSD kernel bug. Kubilay Kocak reported it to Rick Macklem who fixed the FreeBSD kernel:
https://github.com/freebsd/freebsd-src/commit/a5f9fe2bab789f49e8b53da3a62dbd34725e23ea

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43233>
_______________________________________

From report at bugs.python.org  Mon Mar  8 14:49:06 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2021 19:49:06 +0000
Subject: [issue43359] Dead assignment in Py_UniversalNewlineFgets
In-Reply-To: <1614651387.39.0.0295195640102.issue43359@roundup.psfhosted.org>
Message-ID: <1615232946.04.0.298616421993.issue43359@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Hi Victor, just so we're all on the same page, removing the line does not trigger a compiler warning. The comment on this line is misleading.

I wrote the opposite. IMO the line and its commment should be kept.

> Defect identified by scan-build <https://clang-analyzer.llvm.org/scan-build.html>

Just tell your tool that the line is there on purpose.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43359>
_______________________________________

From report at bugs.python.org  Mon Mar  8 14:50:50 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2021 19:50:50 +0000
Subject: [issue8036] raise ValueError for empty `path` in os.spawnv[e]
In-Reply-To: <1267477949.48.0.216202239381.issue8036@psf.upfronthosting.co.za>
Message-ID: <1615233050.89.0.423376099104.issue8036@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8036>
_______________________________________

From report at bugs.python.org  Mon Mar  8 14:51:26 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2021 19:51:26 +0000
Subject: [issue31447] proc communicate not exiting on python subprocess
 timeout using PIPES
In-Reply-To: <1505297487.8.0.0553413859223.issue31447@psf.upfronthosting.co.za>
Message-ID: <1615233086.2.0.796929780614.issue31447@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31447>
_______________________________________

From report at bugs.python.org  Mon Mar  8 14:52:06 2021
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 08 Mar 2021 19:52:06 +0000
Subject: [issue10653] test_time test_strptime fails on windows
In-Reply-To: <1291820491.4.0.666293971337.issue10653@psf.upfronthosting.co.za>
Message-ID: <1615233126.89.0.52993704795.issue10653@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> Eryk Sun: This issue is now closed. If you want to enhance 
> the time module, please open a new issue.

I was aware of that at the time, Victor. The problem can be worked on in a new issue, or in the older issue bpo-8304, which remains open. The two messages that I added are purely informative, to update my original comment in msg243660.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10653>
_______________________________________

From report at bugs.python.org  Mon Mar  8 14:53:07 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 08 Mar 2021 19:53:07 +0000
Subject: [issue43427] Possible error on the descriptor howto guide
In-Reply-To: <1615131755.48.0.550524446603.issue43427@roundup.psfhosted.org>
Message-ID: <1615233187.95.0.090666123532.issue43427@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I can see how that section intro is a bit confusing.  Am thinking it will be more clear if the heading "Static Methods" is to moved to just after the table showing the three variants.  Otherwise, it looks like the intro text is talking specifically about static methods.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43427>
_______________________________________

From report at bugs.python.org  Mon Mar  8 15:04:04 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2021 20:04:04 +0000
Subject: [issue37146] opcode cache for LOAD_GLOBAL emits false alarm in memory
 leak hunting
In-Reply-To: <1559594083.93.0.475089830437.issue37146@roundup.psfhosted.org>
Message-ID: <1615233844.91.0.784841582995.issue37146@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +23552
pull_request: https://github.com/python/cpython/pull/24786

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37146>
_______________________________________

From report at bugs.python.org  Mon Mar  8 15:06:09 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 08 Mar 2021 20:06:09 +0000
Subject: [issue14678] Update zipimport to support importlib.invalidate_caches()
In-Reply-To: <1335462110.31.0.00575372691618.issue14678@psf.upfronthosting.co.za>
Message-ID: <1615233969.31.0.26367835218.issue14678@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 3abf6f010243a91bf57cbf357dac33193f7b8407 by Desmond Cheong in branch 'master':
bpo-14678: Update zipimport to support importlib.invalidate_caches() (GH-24159)
https://github.com/python/cpython/commit/3abf6f010243a91bf57cbf357dac33193f7b8407


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14678>
_______________________________________

From report at bugs.python.org  Mon Mar  8 15:06:43 2021
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 08 Mar 2021 20:06:43 +0000
Subject: [issue14678] Update zipimport to support importlib.invalidate_caches()
In-Reply-To: <1335462110.31.0.00575372691618.issue14678@psf.upfronthosting.co.za>
Message-ID: <1615234003.3.0.201081229229.issue14678@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/issue14678>
_______________________________________

From report at bugs.python.org  Mon Mar  8 15:06:46 2021
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 08 Mar 2021 20:06:46 +0000
Subject: [issue14678] Update zipimport to support importlib.invalidate_caches()
In-Reply-To: <1335462110.31.0.00575372691618.issue14678@psf.upfronthosting.co.za>
Message-ID: <1615234006.62.0.602228032677.issue14678@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
versions: +Python 3.10 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14678>
_______________________________________

From report at bugs.python.org  Mon Mar  8 15:06:59 2021
From: report at bugs.python.org (T-VEy)
Date: Mon, 08 Mar 2021 20:06:59 +0000
Subject: [issue28356] [easy doc] Document os.rename() behavior on Windows when
 src and dst are on different filesystems
In-Reply-To: <1475588552.47.0.916118565333.issue28356@psf.upfronthosting.co.za>
Message-ID: <1615234019.31.0.241539425301.issue28356@roundup.psfhosted.org>


T-VEy <scienidlex at gmail.com> added the comment:

i have problem with python version 3.9.1

----------
nosy: +scienidlex
versions:  -Python 3.10, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28356>
_______________________________________

From report at bugs.python.org  Mon Mar  8 15:10:04 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2021 20:10:04 +0000
Subject: [issue13559] Use sendfile where possible in httplib
In-Reply-To: <1323377245.96.0.509517020675.issue13559@psf.upfronthosting.co.za>
Message-ID: <1615234204.9.0.42388249887.issue13559@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13559>
_______________________________________

From report at bugs.python.org  Mon Mar  8 15:11:27 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2021 20:11:27 +0000
Subject: [issue25585] Bad path leads to: ImportError: DLL load failed: %1 is
 not a valid Win32 application.
In-Reply-To: <1447004161.31.0.19011460804.issue25585@psf.upfronthosting.co.za>
Message-ID: <1615234287.27.0.971712613796.issue25585@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25585>
_______________________________________

From report at bugs.python.org  Mon Mar  8 15:12:01 2021
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 08 Mar 2021 20:12:01 +0000
Subject: [issue43437] venv activate bash script has wrong line endings on
 windows
In-Reply-To: <1615227420.16.0.158256767394.issue43437@roundup.psfhosted.org>
Message-ID: <1615234321.78.0.0490726134546.issue43437@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

venv copies the scripts in binary mode, but apparently the Unix "activate" script already has CRLF line endings when Python is installed in Windows. Probably the POSIX "Lib/venv/scripts/common/activate" script needs a line-ending exception in ".gitattributes":

https://github.com/python/cpython/blob/master/.gitattributes

----------
components: +Library (Lib)
nosy: +eryksun
versions: +Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43437>
_______________________________________

From report at bugs.python.org  Mon Mar  8 15:12:41 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2021 20:12:41 +0000
Subject: [issue28708] Low FD_SETSIZE limit on Windows
In-Reply-To: <1479250358.07.0.768722440644.issue28708@psf.upfronthosting.co.za>
Message-ID: <1615234361.63.0.555923038031.issue28708@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28708>
_______________________________________

From report at bugs.python.org  Mon Mar  8 15:13:15 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2021 20:13:15 +0000
Subject: [issue11361] [Windows] suggestion for os.kill(pid,
 CTRL_C_EVENT) in tests
In-Reply-To: <1298986221.06.0.20392871991.issue11361@psf.upfronthosting.co.za>
Message-ID: <1615234395.29.0.732708558202.issue11361@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner
title: suggestion for os.kill(pid,CTRL_C_EVENT) in tests -> [Windows] suggestion for os.kill(pid,CTRL_C_EVENT) in tests

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11361>
_______________________________________

From report at bugs.python.org  Mon Mar  8 15:13:44 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2021 20:13:44 +0000
Subject: [issue27496] unicodedata.name() doesn't have names for control
 characters
In-Reply-To: <1468329049.33.0.201400438769.issue27496@psf.upfronthosting.co.za>
Message-ID: <1615234424.31.0.235507020734.issue27496@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27496>
_______________________________________

From report at bugs.python.org  Mon Mar  8 15:14:38 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2021 20:14:38 +0000
Subject: [issue42962] Windows: SystemError during os.kill(...,
 signal.CTRL_C_EVENT)
In-Reply-To: <1611007954.59.0.488720921329.issue42962@roundup.psfhosted.org>
Message-ID: <1615234478.22.0.0204776224877.issue42962@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42962>
_______________________________________

From report at bugs.python.org  Mon Mar  8 15:18:47 2021
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 08 Mar 2021 20:18:47 +0000
Subject: [issue28356] [easy doc] Document os.rename() behavior on Windows when
 src and dst are on different filesystems
In-Reply-To: <1475588552.47.0.916118565333.issue28356@psf.upfronthosting.co.za>
Message-ID: <1615234727.49.0.348081809591.issue28356@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

T-VEy, this is a documentation-only issue for versions of Python that are under active development for bug fixes and enhancements -- 3.8, 3.9, and 3.10.

----------
versions: +Python 3.10, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28356>
_______________________________________

From report at bugs.python.org  Mon Mar  8 15:22:26 2021
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 08 Mar 2021 20:22:26 +0000
Subject: [issue19809] Doc: subprocess should warn uses on race conditions when
 multiple threads spawn child processes
In-Reply-To: <1385544646.44.0.340337636792.issue19809@psf.upfronthosting.co.za>
Message-ID: <1615234946.51.0.964602251461.issue19809@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

>> PEP 443
>
> I guess that you mean the PEP 446 ;-)

Yes, that's why I meant :$

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19809>
_______________________________________

From report at bugs.python.org  Mon Mar  8 15:26:14 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2021 20:26:14 +0000
Subject: [issue43438] [doc] sys.addaudithook() documentation should be more
 explicit on its limitations
Message-ID: <1615235174.36.0.713670774369.issue43438@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Recently, the PEP 578 audit hooks was used to build a Capture The Flag (CTF) security challenge, AntCTF x D^3CTF: https://d3ctf.io/

Multiple issues have been reported to the Python Security Response Team (PSRT) from this challenge. It seems like there was a misunderstanding on the intent of the PEP 578.

Building a sandbox using audit hooks is *explicitly* excluded from the PEP 578 design:
https://www.python.org/dev/peps/pep-0578/#why-not-a-sandbox

See also the PEP 551 for more details.

The problem is that these two PEPs are not well summarized in the Python documentation, especially in the sys.addaudithook() documentation:
https://docs.python.org/dev/library/sys.html#sys.addaudithook

The documentation should better describe limitations of audit hooks, and may also point to these two PEPs for more information (PEP 578 is already mentioned).

The bare minimum should be to explicitly say that it should not be used to build a sandbox. 

By design, audit events is a whack a mole game. Rather than starting from a short "allow list", it is based on a "deny list", so it cannot be safe or complete by design. Every "forgotten" audit event can be "abused" to take the control on the application. And that's perfectly *fine*. It should just be documented.

----------
assignee: docs at python
components: Documentation
messages: 388299
nosy: christian.heimes, docs at python, steve.dower, vstinner
priority: normal
severity: normal
status: open
title: [doc] sys.addaudithook() documentation should be more explicit on its limitations
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43438>
_______________________________________

From report at bugs.python.org  Mon Mar  8 15:32:28 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2021 20:32:28 +0000
Subject: [issue43439] [security] Add audit events on GC functions giving
 access to all Python objects
Message-ID: <1615235548.58.0.659993767767.issue43439@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

It is currently possible to discover the internal list of audit hooks using gc module functions, like gc.get_objects(), and so remove an audit hooks, whereas it is supposed to not be possible. The PEP 578 states: "Hooks cannot be removed or replaced."

Rather than attempting to fix this specific vulnerability, I suggest to add new audit events on the following gc functions:

* gc.get_objects()
* gc.get_referrers()
* gc.get_referents()

These functions are "dangerous" since they can expose Python objects in an inconsistent state. In the past, we add multiple bugs related to "internal" tuples which were not fully initialized (but already tracked by the GC). See bpo-15108 for an example.

Note: if someone wants to address the ability to remove an audit hook, the internal list can be modified to not be a Python object.

----------
components: Library (Lib)
messages: 388300
nosy: christian.heimes, pablogsal, steve.dower, vstinner
priority: normal
severity: normal
status: open
title: [security] Add audit events on GC functions giving access to all Python objects
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43439>
_______________________________________

From report at bugs.python.org  Mon Mar  8 15:32:43 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2021 20:32:43 +0000
Subject: [issue43438] [doc] sys.addaudithook() documentation should be more
 explicit on its limitations
In-Reply-To: <1615235174.36.0.713670774369.issue43438@roundup.psfhosted.org>
Message-ID: <1615235563.38.0.889331569664.issue43438@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

See also bpo-43439: [security] Add audit events on GC functions giving access to all Python objects.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43438>
_______________________________________

From report at bugs.python.org  Mon Mar  8 15:40:32 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 08 Mar 2021 20:40:32 +0000
Subject: [issue43439] [security] Add audit events on GC functions giving
 access to all Python objects
In-Reply-To: <1615235548.58.0.659993767767.issue43439@roundup.psfhosted.org>
Message-ID: <1615236032.47.0.308872424828.issue43439@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> Rather than attempting to fix this specific vulnerability, I suggest to add new audit events on the following gc functions:

Makes sense, I will prepare a PR today

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43439>
_______________________________________

From report at bugs.python.org  Mon Mar  8 15:56:52 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2021 20:56:52 +0000
Subject: [issue38033] Use After Free: PyObject_Free (valgrind)
In-Reply-To: <1567639624.78.0.948902616905.issue38033@roundup.psfhosted.org>
Message-ID: <1615237012.67.0.629523247076.issue38033@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

It sounds like the reporter didn't use Valgrind properly. See last comments. If Valgrind still reports issues when it's used properly, please reopen the issue (or open a new issue). I close the issue for now.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38033>
_______________________________________

From report at bugs.python.org  Mon Mar  8 16:06:56 2021
From: report at bugs.python.org (Steve Dower)
Date: Mon, 08 Mar 2021 21:06:56 +0000
Subject: [issue43438] [doc] sys.addaudithook() documentation should be more
 explicit on its limitations
In-Reply-To: <1615235174.36.0.713670774369.issue43438@roundup.psfhosted.org>
Message-ID: <1615237616.3.0.945746026966.issue43438@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

To clarify my position on this (as the PEP author):

* audit hooks added *after* initialization (including via the Python API) are not intended for security, but for logging/debugging, and so bypasses are not considered security issues
* audit hooks added *before* Python is initialized should not be able to be bypassed *without* prior events indicating that a bypass is going to occur. Ways of bypassing/removing them without prior indicators should be reported as security issues

And note that all compile()d, imported or exec()d code should have been collected, which means any security bypass has to happen without arbitrary code execution.

These hooks are only one tool necessary to create a more secured environment, not the whole thing. (And note that I said "more secured" not "secure", because it's only as secure as you make it. The relative descriptor is deliberate.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43438>
_______________________________________

From report at bugs.python.org  Mon Mar  8 16:24:12 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 08 Mar 2021 21:24:12 +0000
Subject: [issue43427] Possible error on the descriptor howto guide
In-Reply-To: <1615131755.48.0.550524446603.issue43427@roundup.psfhosted.org>
Message-ID: <1615238652.29.0.362714055268.issue43427@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
keywords: +patch
pull_requests: +23553
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24787

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43427>
_______________________________________

From report at bugs.python.org  Mon Mar  8 16:30:46 2021
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 08 Mar 2021 21:30:46 +0000
Subject: [issue43438] [doc] sys.addaudithook() documentation should be more
 explicit on its limitations
In-Reply-To: <1615235174.36.0.713670774369.issue43438@roundup.psfhosted.org>
Message-ID: <1615239046.36.0.944824330521.issue43438@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

I agree with both of you.

The documention should explicitly state that the audit hooks are for auditing. They are not designed to sandbox Python. When used correctly, they can help to capture and analyze an event post-mortem.

The documentation of sys.addaudithook() should also mention that hooks may not trigger under some conditions, e.g. very late in the interpreter shutdown phase.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43438>
_______________________________________

From report at bugs.python.org  Mon Mar  8 16:31:52 2021
From: report at bugs.python.org (David Wood)
Date: Mon, 08 Mar 2021 21:31:52 +0000
Subject: [issue43435] Py_BuildValue("y#".... returns incomplete result
In-Reply-To: <1615217493.05.0.795009945001.issue43435@roundup.psfhosted.org>
Message-ID: <1615239112.86.0.964670062322.issue43435@roundup.psfhosted.org>


David Wood <dwoodjunkmail at gmail.com> added the comment:

Christian -

Thank you for this.  I did as you suggested however, I still have the same problem.  As I pointed out in my original message, the problem does not exist if I insert a sleep(1) statement prior to returning from the function.  Additional to that, I previously had printf('.') statement in place of the sleep statement.  When I ran 10,000 iterations in python and printed my pass/fail totals, I still had a few hundred dots print which tells me that there has to be some sort of timing or buffer transfer issue between c and python.  Does that make sense?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43435>
_______________________________________

From report at bugs.python.org  Mon Mar  8 16:33:11 2021
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 08 Mar 2021 21:33:11 +0000
Subject: [issue43439] [security] Add audit events on GC functions giving
 access to all Python objects
In-Reply-To: <1615235548.58.0.659993767767.issue43439@roundup.psfhosted.org>
Message-ID: <1615239191.65.0.993558693632.issue43439@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

> Note: if someone wants to address the ability to remove an audit hook, the internal list can be modified to not be a Python object.

I wouldn't bother. There are other ways to modify data structures, e.g. poke into process memory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43439>
_______________________________________

From report at bugs.python.org  Mon Mar  8 16:43:56 2021
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 08 Mar 2021 21:43:56 +0000
Subject: [issue43435] Py_BuildValue("y#".... returns incomplete result
In-Reply-To: <1615217493.05.0.795009945001.issue43435@roundup.psfhosted.org>
Message-ID: <1615239836.5.0.908222113478.issue43435@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Py_BuildValue("y#", output, count) is equivalent to PyBytes_FromStringAndSize(output, count). The function returns a copy of the input string as a new bytes object. It's very unlikely that the code is broken. It's been around for ages and it's a core feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43435>
_______________________________________

From report at bugs.python.org  Mon Mar  8 16:48:46 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 08 Mar 2021 21:48:46 +0000
Subject: [issue43332] Make http.client._tunnel send one byte string over the
 network
In-Reply-To: <1614370680.1.0.103129903648.issue43332@roundup.psfhosted.org>
Message-ID: <1615240126.26.0.391332539856.issue43332@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

I only ported this back to 3.9 as it is a bit late in 3.8's release cycle for a pure performance fix of an issue that has been around for ages.

Thanks for raising the issue.  The main http code already did this, the tunnel proxy code path clearly hadn't gotten much love.

----------
resolution:  -> fixed
stage: patch review -> commit review
status: open -> closed
versions:  -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43332>
_______________________________________

From report at bugs.python.org  Mon Mar  8 16:52:40 2021
From: report at bugs.python.org (David Wood)
Date: Mon, 08 Mar 2021 21:52:40 +0000
Subject: [issue43435] Py_BuildValue("y#".... returns incomplete result
In-Reply-To: <1615217493.05.0.795009945001.issue43435@roundup.psfhosted.org>
Message-ID: <1615240360.77.0.0349105457129.issue43435@roundup.psfhosted.org>


David Wood <dwoodjunkmail at gmail.com> added the comment:

Still no bueno.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43435>
_______________________________________

From report at bugs.python.org  Mon Mar  8 16:56:41 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2021 21:56:41 +0000
Subject: [issue37146] opcode cache for LOAD_GLOBAL emits false alarm in memory
 leak hunting
In-Reply-To: <1559594083.93.0.475089830437.issue37146@roundup.psfhosted.org>
Message-ID: <1615240601.27.0.0965992921184.issue37146@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 9f672a52f55ce198d5689b5771948350028b4a3b by Victor Stinner in branch 'master':
bpo-37146: Move _PyEval_DeactivateOpCache() to the internal C API (GH-24786)
https://github.com/python/cpython/commit/9f672a52f55ce198d5689b5771948350028b4a3b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37146>
_______________________________________

From report at bugs.python.org  Mon Mar  8 16:58:20 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2021 21:58:20 +0000
Subject: [issue43382] github CI blocked by the Ubuntu CI with an SSL error
In-Reply-To: <1614745744.43.0.675662116863.issue43382@roundup.psfhosted.org>
Message-ID: <1615240700.75.0.271032033808.issue43382@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43382>
_______________________________________

From report at bugs.python.org  Mon Mar  8 17:02:34 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2021 22:02:34 +0000
Subject: [issue43321] PyArg_ParseTuple() false-returns SUCCESS though
 SystemError and missing data (when PY_SSIZE_T_CLEAN not #define'd)
In-Reply-To: <1614269125.06.0.289577576658.issue43321@roundup.psfhosted.org>
Message-ID: <1615240954.3.0.252839015401.issue43321@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thanks for fixing my bug ;-) (bpo-40943)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43321>
_______________________________________

From report at bugs.python.org  Mon Mar  8 17:05:09 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2021 22:05:09 +0000
Subject: [issue43438] [doc] sys.addaudithook() documentation should be more
 explicit on its limitations
In-Reply-To: <1615235174.36.0.713670774369.issue43438@roundup.psfhosted.org>
Message-ID: <1615241109.11.0.232305363076.issue43438@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Another example of recent Capture The Flag challenge which used audit hooks: https://bugs.python.org/issue42800#msg384143

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43438>
_______________________________________

From report at bugs.python.org  Mon Mar  8 17:06:50 2021
From: report at bugs.python.org (Kamil Turek)
Date: Mon, 08 Mar 2021 22:06:50 +0000
Subject: [issue43245] Add keyword argument support to ChainMap.new_child()
In-Reply-To: <1613591324.63.0.830748384561.issue43245@roundup.psfhosted.org>
Message-ID: <1615241210.55.0.146640147721.issue43245@roundup.psfhosted.org>


Change by Kamil Turek <tazzu at live.com>:


----------
keywords: +patch
pull_requests: +23554
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24788

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43245>
_______________________________________

From report at bugs.python.org  Mon Mar  8 17:11:38 2021
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 08 Mar 2021 22:11:38 +0000
Subject: [issue43415] Typo
In-Reply-To: <1615001372.2.0.966613332718.issue43415@roundup.psfhosted.org>
Message-ID: <1615241498.37.0.58358500478.issue43415@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: +23555
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24789

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43415>
_______________________________________

From report at bugs.python.org  Mon Mar  8 17:27:37 2021
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 08 Mar 2021 22:27:37 +0000
Subject: [issue43332] Make http.client._tunnel send one byte string over the
 network
In-Reply-To: <1614370680.1.0.103129903648.issue43332@roundup.psfhosted.org>
Message-ID: <1615242457.81.0.737447954596.issue43332@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
stage: commit review -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43332>
_______________________________________

From report at bugs.python.org  Mon Mar  8 17:50:51 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 08 Mar 2021 22:50:51 +0000
Subject: [issue43415] Typo
In-Reply-To: <1615001372.2.0.966613332718.issue43415@roundup.psfhosted.org>
Message-ID: <1615243851.25.0.672648331369.issue43415@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: +23557
pull_request: https://github.com/python/cpython/pull/24790

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43415>
_______________________________________

From report at bugs.python.org  Mon Mar  8 17:51:01 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 08 Mar 2021 22:51:01 +0000
Subject: [issue43415] Typo
In-Reply-To: <1615001372.2.0.966613332718.issue43415@roundup.psfhosted.org>
Message-ID: <1615243861.63.0.0598993720603.issue43415@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:


New changeset 0554044ddccdb7bf1fa4a8bc880e7a7b59f6479c by Guilherme Martins Crocetti in branch 'master':
bpo-43415: Fix typo on dataclasses.rst (#24789)
https://github.com/python/cpython/commit/0554044ddccdb7bf1fa4a8bc880e7a7b59f6479c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43415>
_______________________________________

From report at bugs.python.org  Mon Mar  8 17:50:57 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 08 Mar 2021 22:50:57 +0000
Subject: [issue43415] Typo
In-Reply-To: <1615001372.2.0.966613332718.issue43415@roundup.psfhosted.org>
Message-ID: <1615243857.87.0.550032059161.issue43415@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +23558
pull_request: https://github.com/python/cpython/pull/24791

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43415>
_______________________________________

From report at bugs.python.org  Mon Mar  8 17:52:01 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 08 Mar 2021 22:52:01 +0000
Subject: [issue43415] Typo in dataclasses documentation
In-Reply-To: <1615001372.2.0.966613332718.issue43415@roundup.psfhosted.org>
Message-ID: <1615243921.72.0.884502337811.issue43415@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
assignee: docs at python -> eric.smith
title: Typo -> Typo in dataclasses documentation

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43415>
_______________________________________

From report at bugs.python.org  Mon Mar  8 17:52:28 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 08 Mar 2021 22:52:28 +0000
Subject: [issue43422] Revert _decimal C API changes
In-Reply-To: <1615043906.44.0.566874098139.issue43422@roundup.psfhosted.org>
Message-ID: <1615243948.29.0.856654702485.issue43422@roundup.psfhosted.org>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
keywords: +patch
pull_requests: +23559
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24792

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43422>
_______________________________________

From report at bugs.python.org  Mon Mar  8 17:52:51 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 08 Mar 2021 22:52:51 +0000
Subject: [issue43415] Typo in dataclasses documentation
In-Reply-To: <1615001372.2.0.966613332718.issue43415@roundup.psfhosted.org>
Message-ID: <1615243971.73.0.0208066499731.issue43415@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:


New changeset fb3b0310305acdfad7c26705c2ee9a8712a43cf4 by Miss Islington (bot) in branch '3.9':
bpo-43415: Fix typo on dataclasses.rst (GH-24789) (GH-24790)
https://github.com/python/cpython/commit/fb3b0310305acdfad7c26705c2ee9a8712a43cf4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43415>
_______________________________________

From report at bugs.python.org  Mon Mar  8 17:53:31 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 08 Mar 2021 22:53:31 +0000
Subject: [issue43415] Typo in dataclasses documentation
In-Reply-To: <1615001372.2.0.966613332718.issue43415@roundup.psfhosted.org>
Message-ID: <1615244011.38.0.640033891192.issue43415@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:


New changeset 6d4273356764a3837c914b2aced7a668c534e0be by Miss Islington (bot) in branch '3.8':
bpo-43415: Fix typo on dataclasses.rst (GH-24789) (GH-24791)
https://github.com/python/cpython/commit/6d4273356764a3837c914b2aced7a668c534e0be


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43415>
_______________________________________

From report at bugs.python.org  Mon Mar  8 17:54:09 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 08 Mar 2021 22:54:09 +0000
Subject: [issue43415] Typo in dataclasses documentation
In-Reply-To: <1615001372.2.0.966613332718.issue43415@roundup.psfhosted.org>
Message-ID: <1615244049.67.0.844292094195.issue43415@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Thanks!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43415>
_______________________________________

From report at bugs.python.org  Mon Mar  8 18:04:18 2021
From: report at bugs.python.org (C.A.M. Gerlach)
Date: Mon, 08 Mar 2021 23:04:18 +0000
Subject: [issue29982] tempfile.TemporaryDirectory fails to delete itself
In-Reply-To: <1491330378.49.0.274398190766.issue29982@psf.upfronthosting.co.za>
Message-ID: <1615244658.64.0.57212090645.issue29982@roundup.psfhosted.org>


Change by C.A.M. Gerlach <CAM.Gerlach at Gerlach.CAM>:


----------
keywords: +patch
pull_requests: +23560
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24793

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29982>
_______________________________________

From report at bugs.python.org  Mon Mar  8 18:04:18 2021
From: report at bugs.python.org (C.A.M. Gerlach)
Date: Mon, 08 Mar 2021 23:04:18 +0000
Subject: [issue25024] Allow passing "delete=False" to TemporaryDirectory
In-Reply-To: <1441690580.39.0.270846340544.issue25024@psf.upfronthosting.co.za>
Message-ID: <1615244658.77.0.0478376000617.issue25024@roundup.psfhosted.org>


Change by C.A.M. Gerlach <CAM.Gerlach at Gerlach.CAM>:


----------
pull_requests: +23561
pull_request: https://github.com/python/cpython/pull/24793

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25024>
_______________________________________

From report at bugs.python.org  Mon Mar  8 18:06:16 2021
From: report at bugs.python.org (C.A.M. Gerlach)
Date: Mon, 08 Mar 2021 23:06:16 +0000
Subject: [issue29982] tempfile.TemporaryDirectory fails to delete itself
In-Reply-To: <1491330378.49.0.274398190766.issue29982@psf.upfronthosting.co.za>
Message-ID: <1615244776.4.0.551019550815.issue29982@roundup.psfhosted.org>


C.A.M. Gerlach <CAM.Gerlach at Gerlach.CAM> added the comment:

Thanks! Submitted as PR #24793 https://github.com/python/cpython/pull/24793

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29982>
_______________________________________

From report at bugs.python.org  Mon Mar  8 18:06:41 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 08 Mar 2021 23:06:41 +0000
Subject: [issue43439] [security] Add audit events on GC functions giving
 access to all Python objects
In-Reply-To: <1615235548.58.0.659993767767.issue43439@roundup.psfhosted.org>
Message-ID: <1615244801.44.0.415685887166.issue43439@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +23562
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24794

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43439>
_______________________________________

From report at bugs.python.org  Mon Mar  8 18:56:35 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2021 23:56:35 +0000
Subject: [issue33955] Implement PyOS_CheckStack on macOS using
 pthread_get_stack*_np
In-Reply-To: <1529925495.69.0.56676864532.issue33955@psf.upfronthosting.co.za>
Message-ID: <1615247795.51.0.249161437872.issue33955@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

See also https://www.python.org/dev/peps/pep-0651/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33955>
_______________________________________

From report at bugs.python.org  Mon Mar  8 19:01:53 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Mar 2021 00:01:53 +0000
Subject: [issue3329] API for setting the memory allocator used by Python
In-Reply-To: <1215632933.18.0.0332019532518.issue3329@psf.upfronthosting.co.za>
Message-ID: <1615248113.31.0.871241942618.issue3329@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +23563
pull_request: https://github.com/python/cpython/pull/24795

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3329>
_______________________________________

From report at bugs.python.org  Mon Mar  8 19:24:09 2021
From: report at bugs.python.org (Steve Dower)
Date: Tue, 09 Mar 2021 00:24:09 +0000
Subject: [issue43440] Enable rtree support in SQLite
Message-ID: <1615249448.96.0.887210184332.issue43440@roundup.psfhosted.org>


New submission from Steve Dower <steve.dower at python.org>:

I heard [1] that rtree support would be very useful in SQLite. We should see whether enabling it is safe/easy/cheap and then do it.

1: https://twitter.com/Jamieallencook/status/1368221499794976775?s=20

----------
components: Build, Library (Lib), Windows
messages: 388320
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Enable rtree support in SQLite
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43440>
_______________________________________

From report at bugs.python.org  Mon Mar  8 19:24:17 2021
From: report at bugs.python.org (Steve Dower)
Date: Tue, 09 Mar 2021 00:24:17 +0000
Subject: [issue43440] Enable rtree support in SQLite
In-Reply-To: <1615249448.96.0.887210184332.issue43440@roundup.psfhosted.org>
Message-ID: <1615249457.8.0.917360852091.issue43440@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
nosy: +ghaering

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43440>
_______________________________________

From report at bugs.python.org  Mon Mar  8 19:51:18 2021
From: report at bugs.python.org (Steve Dower)
Date: Tue, 09 Mar 2021 00:51:18 +0000
Subject: [issue43439] [security] Add audit events on GC functions giving
 access to all Python objects
In-Reply-To: <1615235548.58.0.659993767767.issue43439@roundup.psfhosted.org>
Message-ID: <1615251078.04.0.190736009566.issue43439@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Thanks, Pablo! Nice patch.

This can be backported, btw. New audit events are allowed to be added in minor releases (they just cannot be changed).

----------
versions: +Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43439>
_______________________________________

From report at bugs.python.org  Mon Mar  8 20:38:28 2021
From: report at bugs.python.org (T-VEy)
Date: Tue, 09 Mar 2021 01:38:28 +0000
Subject: [issue28356] [easy doc] Document os.rename() behavior on Windows when
 src and dst are on different filesystems
In-Reply-To: <1615234727.49.0.348081809591.issue28356@roundup.psfhosted.org>
Message-ID: <949281278.692658.1615253895603@mail.yahoo.com>


T-VEy <scienidlex at gmail.com> added the comment:

Eryk, can you please go on details on how are they using different strategies to fix bugs but still it's not enough for the time being?Because I know nothing about python and I recognized it in a minute of opening the files.I don't even have it installed on my pc.I don't even have python, not even version 2.7. 

  On Mon, Mar 8, 2021 at 23:48, Eryk Sun<report at bugs.python.org> wrote:   
Eryk Sun <eryksun at gmail.com> added the comment:

T-VEy, this is a documentation-only issue for versions of Python that are under active development for bug fixes and enhancements -- 3.8, 3.9, and 3.10.

----------
versions: +Python 3.10, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28356>
_______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28356>
_______________________________________

From report at bugs.python.org  Mon Mar  8 21:12:09 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 09 Mar 2021 02:12:09 +0000
Subject: [issue41361] Converting collections.deque methods to Argument Clinic
In-Reply-To: <1595345161.63.0.950006640514.issue41361@roundup.psfhosted.org>
Message-ID: <1615255929.03.0.400711651118.issue41361@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Go ahead with in-lining the argument handling for rotate().  The no argument form and the +1 and the -1 case are important enough to warrant the change.

Please skip index() and insert() which aren't essential methods.  Also, those methods aren't called with end-point specific arguments, so the argument processing time doesn't dominate and it isn't worth it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41361>
_______________________________________

From report at bugs.python.org  Mon Mar  8 21:30:54 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 09 Mar 2021 02:30:54 +0000
Subject: [issue35118] Add peek() or first() method in queue
In-Reply-To: <1540956018.19.0.788709270274.issue35118@psf.upfronthosting.co.za>
Message-ID: <1615257054.65.0.392549577642.issue35118@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> I want to examine the first (oldest) element in queue and 
> remove it if it's too old.

Why not just dismiss older queue entries during a normal get() operation?  Or just use a plain deque with access guarded by a lock.

FWIW, the standard library queue module doesn't have a straight-forward way to implement a peek() method.  The module guarantees that the underlying data structure is only accessed with _init, _qsize, _get, and _put.


That would be difficult to do atomically with a Queue object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35118>
_______________________________________

From report at bugs.python.org  Mon Mar  8 21:49:32 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 09 Mar 2021 02:49:32 +0000
Subject: [issue43198] Operations on sets more than hundred times less
 efficient with python3.9 than with previous versions
In-Reply-To: <1613002507.49.0.48232719319.issue43198@roundup.psfhosted.org>
Message-ID: <1615258172.49.0.306601490374.issue43198@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I've had misgivings about this and will revert the change for Python 3.10.  

Usually, it is safe for sets to implement whatever has been battle-tested with dicts, but sets should aspire to do better for alternating deletions and re-additions of the same element, even if that isn't a common case.

----------
nosy: +tim.peters
resolution: not a bug -> 
status: closed -> open
versions: +Python 3.10 -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43198>
_______________________________________

From report at bugs.python.org  Mon Mar  8 22:07:30 2021
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 09 Mar 2021 03:07:30 +0000
Subject: [issue43440] Enable rtree support in SQLite
In-Reply-To: <1615249448.96.0.887210184332.issue43440@roundup.psfhosted.org>
Message-ID: <1615259250.68.0.167442105374.issue43440@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
nosy: +berker.peksag, erlendaasland

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43440>
_______________________________________

From report at bugs.python.org  Mon Mar  8 22:54:44 2021
From: report at bugs.python.org (junyixie)
Date: Tue, 09 Mar 2021 03:54:44 +0000
Subject: [issue43441] mutilcorevm: global variable next_version_tag cause
 method cache bug
Message-ID: <1615262084.5.0.815014213556.issue43441@roundup.psfhosted.org>


New submission from junyixie <xie.junyi at outlook.com>:

type->tp_version_tag = next_version_tag++;
when sub interpreters parallel, next_version_tag++ is thread-unsafe. may cause different type has same tp_version_tag.

cause method cache bug in _PyType_Lookup
#define MCACHE_HASH_METHOD(type, name)                                  \
        MCACHE_HASH((type)->tp_version_tag,                     \
                    ((PyASCIIObject *)(name))->hash)

    if (MCACHE_CACHEABLE_NAME(name) &&
        _PyType_HasFeature(type, Py_TPFLAGS_VALID_VERSION_TAG)) {
        /* fast path */
        unsigned int h = MCACHE_HASH_METHOD(type, name);
        struct type_cache *cache = get_type_cache();
        struct type_cache_entry *entry = &cache->hashtable[h];
        if (entry->version == type->tp_version_tag && entry->name == name) {
#if MCACHE_STATS
            cache->hits++;
#endif
            return entry->value;
        }
    }



static int
assign_version_tag(struct type_cache *cache, PyTypeObject *type)
{
...
    type->tp_version_tag = next_version_tag++;
...
}

----------
components: Interpreter Core
messages: 388327
nosy: JunyiXie
priority: normal
severity: normal
status: open
title: mutilcorevm: global variable next_version_tag cause method cache bug
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43441>
_______________________________________

From report at bugs.python.org  Tue Mar  9 00:11:09 2021
From: report at bugs.python.org (Tim Peters)
Date: Tue, 09 Mar 2021 05:11:09 +0000
Subject: [issue43420] Optimize rational arithmetics
In-Reply-To: <1615040297.73.0.541090358152.issue43420@roundup.psfhosted.org>
Message-ID: <1615266669.06.0.0450552948441.issue43420@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

I agree with everyone ;-) That is, my _experience_ matches Mark's:  as a more-or-less "numeric expert", I use Fraction in cases where it's already fast enough. Python isn't a CAS, and, e.g., in pure Python I'm not doing things like computing or composing power series with rational coefficients (but routinely do such stuff in a CAS). It's usually just combinatorial probabilities in relatively simple settings, and small-scale computations where float precision would be fine except I don't want to bother doing error analysis first to ensure things like catastrophic cancellation can't occur.

On the other hand, the proposed changes are bog standard optimizations for implementations of rationals, and can pay off very handsomely at relatively modest argument sizes.

So I'm +0. I don't really mind the slowdown for small arguments because, as above, I just don't use Fraction for extensive computation. But the other side of that is that I won't profit much from optimizations either, and while the optimizations for * and / are close to self-evident, those for + and - are much subtler. Code obscurity imposes ongoing costs of its own.

WRT which, I added Python's Karatsuba implementation and regret doing so. I don't want to take it out now (it's already in ;-) ), but it added quite a pile of delicate code to what _was_ a much easier module to grasp. People who need fast multiplication are still far better off using gmpy2 anyway (or fiddling Decimal precision - Stefan Krah implemented "advanced" multiplication schemes for that module).

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43420>
_______________________________________

From report at bugs.python.org  Tue Mar  9 00:14:29 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Tue, 09 Mar 2021 05:14:29 +0000
Subject: [issue43440] Enable rtree support in SQLite
In-Reply-To: <1615249448.96.0.887210184332.issue43440@roundup.psfhosted.org>
Message-ID: <1615266869.94.0.27602859183.issue43440@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

Unless I?m mistaken, that?s enabled simply by compiling with SQLITE_ENABLE_RTREE defined.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43440>
_______________________________________

From report at bugs.python.org  Tue Mar  9 00:16:12 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Tue, 09 Mar 2021 05:16:12 +0000
Subject: [issue43440] Enable rtree support in SQLite
In-Reply-To: <1615249448.96.0.887210184332.issue43440@roundup.psfhosted.org>
Message-ID: <1615266972.48.0.149678295109.issue43440@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

I can put up a PR for it. I don?t see any reason not to enable it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43440>
_______________________________________

From report at bugs.python.org  Tue Mar  9 00:18:19 2021
From: report at bugs.python.org (Dennis Sweeney)
Date: Tue, 09 Mar 2021 05:18:19 +0000
Subject: [issue41361] Converting collections.deque methods to Argument Clinic
In-Reply-To: <1595345161.63.0.950006640514.issue41361@roundup.psfhosted.org>
Message-ID: <1615267099.37.0.835509712503.issue41361@roundup.psfhosted.org>


Change by Dennis Sweeney <sweeney.dennis650 at gmail.com>:


----------
pull_requests: +23564
pull_request: https://github.com/python/cpython/pull/24796

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41361>
_______________________________________

From report at bugs.python.org  Tue Mar  9 01:24:28 2021
From: report at bugs.python.org (junyixie)
Date: Tue, 09 Mar 2021 06:24:28 +0000
Subject: [issue43441] mutilcorevm: global variable next_version_tag cause
 method cache bug
In-Reply-To: <1615262084.5.0.815014213556.issue43441@roundup.psfhosted.org>
Message-ID: <1615271068.71.0.551794909377.issue43441@roundup.psfhosted.org>


junyixie <xie.junyi at outlook.com> added the comment:

when sub interpreter finalize. 
_PyType_ClearCache set next_version_tag = 0. 

Type shared between interpreters. 
another interpreter assign_version_tag "1" for a type, the type is first assign.

the dealloc interpreter had assign_version_tag  "1" for another type.

now, two different type has same version tag. it cause method cache wrong.


static unsigned int
_PyType_ClearCache(struct type_cache *cache)
{
#if MCACHE_STATS
    size_t total = cache->hits + cache->collisions + cache->misses;
    fprintf(stderr, "-- Method cache hits        = %zd (%d%%)\n",
            cache->hits, (int) (100.0 * cache->hits / total));
    fprintf(stderr, "-- Method cache true misses = %zd (%d%%)\n",
            cache->misses, (int) (100.0 * cache->misses / total));
    fprintf(stderr, "-- Method cache collisions  = %zd (%d%%)\n",
            cache->collisions, (int) (100.0 * cache->collisions / total));
    fprintf(stderr, "-- Method cache size        = %zd KiB\n",
            sizeof(cache->hashtable) / 1024);
#endif

    unsigned int cur_version_tag = next_version_tag - 1;
    next_version_tag = 0;
    type_cache_clear(cache, 0);

    return cur_version_tag;
}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43441>
_______________________________________

From report at bugs.python.org  Tue Mar  9 01:31:20 2021
From: report at bugs.python.org (junyixie)
Date: Tue, 09 Mar 2021 06:31:20 +0000
Subject: [issue43441] mutilcorevm: global variable next_version_tag cause
 method cache bug
In-Reply-To: <1615262084.5.0.815014213556.issue43441@roundup.psfhosted.org>
Message-ID: <1615271480.25.0.157485775061.issue43441@roundup.psfhosted.org>


junyixie <xie.junyi at outlook.com> added the comment:

fix:
only main interpreter fini, clear method cache. 

void
_PyType_Fini(PyInterpreterState *interp)
{
    if (_Py_IsMainInterpreter(interp)) {
        clear_slotdefs();
        _PyType_ClearCache(&interp->type_cache);
    }
}

when python4.0? type isolate, each interpreter dealloc should clear method cache.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43441>
_______________________________________

From report at bugs.python.org  Tue Mar  9 01:39:09 2021
From: report at bugs.python.org (junyixie)
Date: Tue, 09 Mar 2021 06:39:09 +0000
Subject: [issue43442] multicorevm: guarantee type multi sub interpreters safe
Message-ID: <1615271949.39.0.761711981619.issue43442@roundup.psfhosted.org>


New submission from junyixie <xie.junyi at outlook.com>:

in multi core cpython project. 
when use  multi sub interpreters, Type is not safe. Type shared by interpreters.
but isolate type may cause python abi/api change. python 4.0?

temporary solution:
1. add a type lock to guarantee type object safe in multi subinterpreters.
2. some thing like pycmethod object and descr in pytype, set their refcount to INT MAX.It is guaranteed that these objects will not be released. and not cause memory leaks, only one type exist in memory.

----------
messages: 388333
nosy: JunyiXie
priority: normal
severity: normal
status: open
title: multicorevm: guarantee type multi sub interpreters safe

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43442>
_______________________________________

From report at bugs.python.org  Tue Mar  9 03:45:04 2021
From: report at bugs.python.org (Rubin Simons)
Date: Tue, 09 Mar 2021 08:45:04 +0000
Subject: [issue33125] Windows 10 ARM64 platform support
In-Reply-To: <1521767011.97.0.467229070634.issue33125@psf.upfronthosting.co.za>
Message-ID: <1615279504.65.0.126137458551.issue33125@roundup.psfhosted.org>


Rubin Simons <rubin at xs4all.nl> added the comment:

Requesting that this issue be re-opened or re-evaluated; it would be pretty great if Python could provide Windows on ARM binaries for download. There's been a lot of traction on ARM in general and having Windows on ARM downloads available by default will also give the Python package ecosystem a better opportunity to get ready (although it's already impressively far ahead, take a look at https://cloudbase.it/python-on-windows-arm64/, 23 of 25 of the most popular packages already build out-of-the-box, and the remaining two, numpy and cffi have patches available).

----------
nosy: +rubin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33125>
_______________________________________

From report at bugs.python.org  Tue Mar  9 03:46:35 2021
From: report at bugs.python.org (Dominik Vilsmeier)
Date: Tue, 09 Mar 2021 08:46:35 +0000
Subject: [issue43443] Should shelve support dict union?
Message-ID: <1615279595.44.0.954464448046.issue43443@roundup.psfhosted.org>


New submission from Dominik Vilsmeier <dominik.vilsmeier1123 at gmail.com>:

The docs of shelve mention that

> Shelf objects support all methods supported by dictionaries. This eases the transition from dictionary based scripts to those requiring persistent storage.

However the `|=` operator is not implemented, preventing a seamless transition from `dict` to `shelve`. So should this be implemented for `Shelf` as well? `|` on the other hand doesn't make much sense.

Otherwise the docs could be updated.

----------
components: Library (Lib)
messages: 388335
nosy: Dominik V.
priority: normal
severity: normal
status: open
title: Should shelve support dict union?
type: behavior
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43443>
_______________________________________

From report at bugs.python.org  Tue Mar  9 04:11:01 2021
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 09 Mar 2021 09:11:01 +0000
Subject: [issue27820] Possible bug in smtplib when initial_response_ok=False
In-Reply-To: <1471739698.94.0.271523306415.issue27820@psf.upfronthosting.co.za>
Message-ID: <1615281061.28.0.0414371523231.issue27820@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Hello Pandu,

Thank you for this patch and the explanation. Does client blocking on repeated challenge from the server (using of while loop) look okay here? 
The conversation here indicates to me that it is fine. Is there any recommendation or implementation strategies to break the loop (on a malformed server)?

Thanks,
Senthil

----------
assignee:  -> orsenthil
nosy: +orsenthil
versions: +Python 3.10, Python 3.9 -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27820>
_______________________________________

From report at bugs.python.org  Tue Mar  9 04:26:02 2021
From: report at bugs.python.org (Thomas Grainger)
Date: Tue, 09 Mar 2021 09:26:02 +0000
Subject: [issue40720] accessing mmap of file that is overwritten causes bus
 error
In-Reply-To: <1590096773.09.0.253309734553.issue40720@roundup.psfhosted.org>
Message-ID: <1615281962.28.0.799547859995.issue40720@roundup.psfhosted.org>


Thomas Grainger <tagrain at gmail.com> added the comment:

I can confirm this happens on py3.5-3.10

```
import mmap
import pathlib
import tempfile


def main():
    with tempfile.TemporaryDirectory() as tmp:
        tmp_path = pathlib.Path(tmp)
        path = tmp_path / "eg"

        path.write_bytes(b"Hello, World!")

        with path.open("rb") as rf:
            mm = mmap.mmap(rf.fileno(), 0, mmap.MAP_SHARED, mmap.PROT_READ)
            path.write_bytes(b"")
            bytes(mm)

if __name__ == "__main__":
    main()
```

----------
nosy: +graingert
versions: +Python 3.10, Python 3.6, Python 3.7, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40720>
_______________________________________

From report at bugs.python.org  Tue Mar  9 04:49:39 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 09 Mar 2021 09:49:39 +0000
Subject: [issue43443] Should shelve support dict union?
In-Reply-To: <1615279595.44.0.954464448046.issue43443@roundup.psfhosted.org>
Message-ID: <1615283379.15.0.190346926309.issue43443@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The comment is outdated. Shelf objects also do not support methods copy and fromkey. Creating a new Shelve object without specifying a new underlying database object does not make much sense.

Maybe say that they implement the MutableMapping interface?

>>> sorted(set(dir(dict)) - set(dir(shelve.Shelf)))
['__ior__', '__or__', '__ror__', 'copy', 'fromkeys']
>>> sorted(set(dir(collections.abc.MutableMapping)) - set(dir(shelve.Shelf)))
[]

----------
nosy: +rhettinger, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43443>
_______________________________________

From report at bugs.python.org  Tue Mar  9 04:58:34 2021
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 09 Mar 2021 09:58:34 +0000
Subject: [issue40720] accessing mmap of file that is overwritten causes bus
 error
In-Reply-To: <1590096773.09.0.253309734553.issue40720@roundup.psfhosted.org>
Message-ID: <1615283914.16.0.22214508995.issue40720@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

What happens here is that the file is truncated, which (more or less) truncates the memory mapping. Accessing a memory mapping beyond the length of the file results in a SIGBUS signal.

I'm not sure if there is much Python can do about this other than shrinking the window for crashes like this by aggressively checking if the file size has changed (but even then a crash will happen if another proces truncates the file between the time the check is done and the memory is actually accessed).

---

Variant of the script that explicitly truncates the file:

def main():
    with tempfile.TemporaryDirectory() as tmp:
        tmp_path = pathlib.Path(tmp)
        path = tmp_path / "eg"

        path.write_bytes(b"Hello, World!")

        with path.open("r+b") as rf:
            mm = mmap.mmap(rf.fileno(), 0, mmap.MAP_SHARED, mmap.PROT_READ)
            rf.truncate(0)
            bytes(mm)

if __name__ == "__main__":
    main()

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40720>
_______________________________________

From report at bugs.python.org  Tue Mar  9 05:07:02 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Tue, 09 Mar 2021 10:07:02 +0000
Subject: [issue43440] Enable rtree support in SQLite
In-Reply-To: <1615249448.96.0.887210184332.issue43440@roundup.psfhosted.org>
Message-ID: <1615284422.4.0.729282452791.issue43440@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

Actually, the macOS build already builds with R*Tree support enabled, but it is missing from PCbuild/sqlite3.vcxproj. I'm not very familiar with the Windows build; does compile options set in setup.py propagate to the Windows build, or do we need to set it both places?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43440>
_______________________________________

From report at bugs.python.org  Tue Mar  9 05:12:27 2021
From: report at bugs.python.org (junyixie)
Date: Tue, 09 Mar 2021 10:12:27 +0000
Subject: [issue43441] mutilcorevm: global variable next_version_tag cause
 method cache bug
In-Reply-To: <1615262084.5.0.815014213556.issue43441@roundup.psfhosted.org>
Message-ID: <1615284747.5.0.420517471929.issue43441@roundup.psfhosted.org>


Change by junyixie <xie.junyi at outlook.com>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43441>
_______________________________________

From report at bugs.python.org  Tue Mar  9 05:17:22 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Tue, 09 Mar 2021 10:17:22 +0000
Subject: [issue43440] Enable rtree support in SQLite
In-Reply-To: <1615249448.96.0.887210184332.issue43440@roundup.psfhosted.org>
Message-ID: <1615285042.59.0.404073165538.issue43440@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

> does compile options set in setup.py propagate to the Windows build, or do we need to set it both places?

Seems like it doesn't; correct me if I'm wrong. PR coming up.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43440>
_______________________________________

From report at bugs.python.org  Tue Mar  9 05:21:34 2021
From: report at bugs.python.org (Dominik Vilsmeier)
Date: Tue, 09 Mar 2021 10:21:34 +0000
Subject: [issue43443] Should shelve support dict union?
In-Reply-To: <1615279595.44.0.954464448046.issue43443@roundup.psfhosted.org>
Message-ID: <1615285294.09.0.861410234529.issue43443@roundup.psfhosted.org>


Dominik Vilsmeier <dominik.vilsmeier1123 at gmail.com> added the comment:

Right, that seems like a good idea. But `__ior__` could be implemented nevertheless?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43443>
_______________________________________

From report at bugs.python.org  Tue Mar  9 05:29:33 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Tue, 09 Mar 2021 10:29:33 +0000
Subject: [issue43440] Enable rtree support in SQLite
In-Reply-To: <1615249448.96.0.887210184332.issue43440@roundup.psfhosted.org>
Message-ID: <1615285773.45.0.381314347624.issue43440@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

We should also consider adding support for R*Tree query callbacks using sqlite3_rtree_query_callback() for SQLite >= 3.8.5, and sqlite3_rtree_geometry_callback() for older versions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43440>
_______________________________________

From report at bugs.python.org  Tue Mar  9 05:30:05 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Tue, 09 Mar 2021 10:30:05 +0000
Subject: [issue43440] Enable rtree support in SQLite
In-Reply-To: <1615249448.96.0.887210184332.issue43440@roundup.psfhosted.org>
Message-ID: <1615285805.91.0.150470083892.issue43440@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


----------
keywords: +patch
pull_requests: +23565
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24797

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43440>
_______________________________________

From report at bugs.python.org  Tue Mar  9 05:34:19 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Tue, 09 Mar 2021 10:34:19 +0000
Subject: [issue43444] [sqlite3] Move MODULE_NAME def from setup.py to module.h
Message-ID: <1615286059.68.0.212415918598.issue43444@roundup.psfhosted.org>


New submission from Erlend Egeberg Aasland <erlend.aasland at innova.no>:

Berker, can we please move the MODULE_NAME define from setup.py to Modules/_sqlite/module.h? I'm tired of all the undeclared identifier warnings. No other module defines their MODULE_NAME in setup.py.

----------
components: Library (Lib)
messages: 388344
nosy: berker.peksag, erlendaasland
priority: normal
severity: normal
status: open
title: [sqlite3] Move MODULE_NAME def from setup.py to module.h
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43444>
_______________________________________

From report at bugs.python.org  Tue Mar  9 05:35:11 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Mar 2021 10:35:11 +0000
Subject: [issue43445] Add frozen modules to sys.stdlib_module_names
Message-ID: <1615286111.17.0.443084957575.issue43445@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

The sys.stdlib_module_names documentation says: "All module kinds are listed: pure Python, built-in, frozen and extension modules. Test modules are excluded."
https://docs.python.org/dev/library/sys.html#sys.stdlib_module_names

But I just noticed that frozen modules are not listed!

Attached PR fix this issue.

----------
components: Library (Lib)
messages: 388345
nosy: vstinner
priority: normal
severity: normal
status: open
title: Add frozen modules to sys.stdlib_module_names
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43445>
_______________________________________

From report at bugs.python.org  Tue Mar  9 05:39:27 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Mar 2021 10:39:27 +0000
Subject: [issue43445] Add frozen modules to sys.stdlib_module_names
In-Reply-To: <1615286111.17.0.443084957575.issue43445@roundup.psfhosted.org>
Message-ID: <1615286367.47.0.849498264771.issue43445@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +23566
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24798

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43445>
_______________________________________

From report at bugs.python.org  Tue Mar  9 05:40:33 2021
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 09 Mar 2021 10:40:33 +0000
Subject: [issue13559] Use sendfile where possible in httplib
In-Reply-To: <1323377245.96.0.509517020675.issue13559@psf.upfronthosting.co.za>
Message-ID: <1615286433.76.0.111293386761.issue13559@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

sendfile() only works for plain HTTP. For technical reasons it does not work for HTTPS (*). These days majority of services use HTTPS. Therefore the usefulness of sendfile() patch is minimal.

(*) It is possible to use sendfile() for TLS connections, but the feature requires a Kernel module that provides kTLS offloading feature, https://www.kernel.org/doc/html/latest/networking/tls-offload.html . In user space it requires OpenSSL 3.0.0 with kTLS support. 3.0.0 is currently under development.

----------
nosy: +christian.heimes
versions: +Python 3.10 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13559>
_______________________________________

From report at bugs.python.org  Tue Mar  9 05:41:58 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Mar 2021 10:41:58 +0000
Subject: [issue43372] ctypes: test_frozentable fails when make regen-frozen
In-Reply-To: <1614696034.15.0.923342699637.issue43372@roundup.psfhosted.org>
Message-ID: <1615286517.97.0.295629839002.issue43372@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

See also bpo-43445 "Add frozen modules to sys.stdlib_module_names".

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43372>
_______________________________________

From report at bugs.python.org  Tue Mar  9 05:46:13 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Tue, 09 Mar 2021 10:46:13 +0000
Subject: [issue43440] Enable rtree support in SQLite
In-Reply-To: <1615249448.96.0.887210184332.issue43440@roundup.psfhosted.org>
Message-ID: <1615286773.42.0.285757211237.issue43440@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

> does compile options set in setup.py propagate to the Windows build, or do we need to set it both places?

Er, forget it. setup.py is of course only used to build the sqlite3 module, not sqlite3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43440>
_______________________________________

From report at bugs.python.org  Tue Mar  9 05:50:25 2021
From: report at bugs.python.org (Eric Martin)
Date: Tue, 09 Mar 2021 10:50:25 +0000
Subject: [issue43198] Operations on sets more than hundred times less
 efficient with python3.9 than with previous versions
In-Reply-To: <1613002507.49.0.48232719319.issue43198@roundup.psfhosted.org>
Message-ID: <1615287025.4.0.475595421042.issue43198@roundup.psfhosted.org>


Eric Martin <eric.martin at unsw.edu.au> added the comment:

Thank you for letting us know, I am actually not surprised the issue would bugger you and you would change your mind... Thinking further about it and experimenting further, I thought it might not be such an edge case and there could be a significant cost in some applications. Many thanks Raymond for everything you give to the community!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43198>
_______________________________________

From report at bugs.python.org  Tue Mar  9 06:04:21 2021
From: report at bugs.python.org (=?utf-8?b?0KHQtdGA0LPQtdC5INCc?=)
Date: Tue, 09 Mar 2021 11:04:21 +0000
Subject: [issue43397] Incorrect conversion path case with german character
In-Reply-To: <1614850926.28.0.842904177967.issue43397@roundup.psfhosted.org>
Message-ID: <1615287861.82.0.581928563629.issue43397@roundup.psfhosted.org>


?????? ? <voramva at gmail.com> added the comment:

I've found the useful function

https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-charlowerw

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43397>
_______________________________________

From report at bugs.python.org  Tue Mar  9 06:17:08 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Mar 2021 11:17:08 +0000
Subject: [issue3329] API for setting the memory allocator used by Python
In-Reply-To: <1215632933.18.0.0332019532518.issue3329@psf.upfronthosting.co.za>
Message-ID: <1615288628.31.0.114805406634.issue3329@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 0d6bd1ca7c683137d52041194f3a2b02219f225a by Victor Stinner in branch 'master':
bpo-3329: Fix typo in PyObjectArenaAllocator doc (GH-24795)
https://github.com/python/cpython/commit/0d6bd1ca7c683137d52041194f3a2b02219f225a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3329>
_______________________________________

From report at bugs.python.org  Tue Mar  9 06:17:31 2021
From: report at bugs.python.org (miss-islington)
Date: Tue, 09 Mar 2021 11:17:31 +0000
Subject: [issue3329] API for setting the memory allocator used by Python
In-Reply-To: <1215632933.18.0.0332019532518.issue3329@psf.upfronthosting.co.za>
Message-ID: <1615288651.89.0.341477426082.issue3329@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 17.0 -> 18.0
pull_requests: +23567
pull_request: https://github.com/python/cpython/pull/24799

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3329>
_______________________________________

From report at bugs.python.org  Tue Mar  9 06:17:41 2021
From: report at bugs.python.org (miss-islington)
Date: Tue, 09 Mar 2021 11:17:41 +0000
Subject: [issue3329] API for setting the memory allocator used by Python
In-Reply-To: <1215632933.18.0.0332019532518.issue3329@psf.upfronthosting.co.za>
Message-ID: <1615288661.39.0.3563856976.issue3329@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +23568
pull_request: https://github.com/python/cpython/pull/24800

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3329>
_______________________________________

From report at bugs.python.org  Tue Mar  9 06:27:32 2021
From: report at bugs.python.org (miss-islington)
Date: Tue, 09 Mar 2021 11:27:32 +0000
Subject: [issue3329] API for setting the memory allocator used by Python
In-Reply-To: <1215632933.18.0.0332019532518.issue3329@psf.upfronthosting.co.za>
Message-ID: <1615289252.34.0.67742024644.issue3329@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 5ca02c4799c07dba5192f87f9f2378dc24097166 by Miss Islington (bot) in branch '3.8':
bpo-3329: Fix typo in PyObjectArenaAllocator doc (GH-24795)
https://github.com/python/cpython/commit/5ca02c4799c07dba5192f87f9f2378dc24097166


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3329>
_______________________________________

From report at bugs.python.org  Tue Mar  9 06:32:55 2021
From: report at bugs.python.org (Sergio Livi)
Date: Tue, 09 Mar 2021 11:32:55 +0000
Subject: [issue43446] Wrong character in footnote
Message-ID: <1615289575.44.0.162763918069.issue43446@roundup.psfhosted.org>


New submission from Sergio Livi <me at serl.it>:

Hello,

There seems to be a display error in the sqlite documentation:
https://docs.python.org/3.9/library/sqlite3.html#f1

The footnote says "To get loadable extension support, you must pass ?enable-loadable-sqlite-extensions to configure."
When actually the configure argument is --enable-etc. The double dash was substituted with a long dash (?), which breaks copy/paste for people. Here's an example: https://github.com/pyenv/pyenv/issues/1702.

----------
assignee: docs at python
components: Documentation
messages: 388353
nosy: docs at python, serl2
priority: normal
severity: normal
status: open
title: Wrong character in footnote
type: enhancement
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43446>
_______________________________________

From report at bugs.python.org  Tue Mar  9 06:34:24 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Mar 2021 11:34:24 +0000
Subject: [issue43447] Generate vectorcall code to parse arguments using
 Argument Clinic
Message-ID: <1615289664.02.0.198288195908.issue43447@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

To optimize the creation of objects, a lot of "tp_new" methods are defined twice: once in the legacy way (tp_new slot), once with the new VECTORCALL calling convention (tp_vectorcall slot). My concern is that the VECTORCALL implementation copy/paste most of the code just to parse arguments, whereas the specific code is just a few lines.

Example with the float type constructor:
--------------
static PyObject *
float_new(PyTypeObject *type, PyObject *args, PyObject *kwargs)
{
    PyObject *return_value = NULL;
    PyObject *x = NULL;

    if ((type == &PyFloat_Type) &&
        !_PyArg_NoKeywords("float", kwargs)) {
        goto exit;
    }
    if (!_PyArg_CheckPositional("float", PyTuple_GET_SIZE(args), 0, 1)) {
        goto exit;
    }
    if (PyTuple_GET_SIZE(args) < 1) {
        goto skip_optional;
    }
    x = PyTuple_GET_ITEM(args, 0);
skip_optional:
    return_value = float_new_impl(type, x);

exit:
    return return_value;
}

/*[clinic input]
@classmethod
float.__new__ as float_new
    x: object(c_default="NULL") = 0
    /

Convert a string or number to a floating point number, if possible.
[clinic start generated code]*/

static PyObject *
float_new_impl(PyTypeObject *type, PyObject *x)
/*[clinic end generated code: output=ccf1e8dc460ba6ba input=f43661b7de03e9d8]*/
{
    if (type != &PyFloat_Type) {
        if (x == NULL) {
            x = _PyLong_GetZero();
        }
        return float_subtype_new(type, x); /* Wimp out */
    }

    if (x == NULL) {
        return PyFloat_FromDouble(0.0);
    }
    /* If it's a string, but not a string subclass, use
       PyFloat_FromString. */
    if (PyUnicode_CheckExact(x))
        return PyFloat_FromString(x);
    return PyNumber_Float(x);
}

static PyObject *
float_vectorcall(PyObject *type, PyObject * const*args,
                 size_t nargsf, PyObject *kwnames)
{
    if (!_PyArg_NoKwnames("float", kwnames)) {
        return NULL;
    }

    Py_ssize_t nargs = PyVectorcall_NARGS(nargsf);
    if (!_PyArg_CheckPositional("float", nargs, 0, 1)) {
        return NULL;
    }

    PyObject *x = nargs >= 1 ? args[0] : NULL;
    return float_new_impl((PyTypeObject *)type, x);
}
--------------

Here the float_new() function (tp_new slot) is implemented with Argument Clinic: float_new() C code is generated from the [clinic input] DSL: good!

My concern is that float_vectorcall() code is hand written, it's boring to write and boring to maintain.

Would it be possible to add a new [clinic input] DSL for vectorcall? I expect something like that:
--------------
static PyObject *
float_vectorcall(PyObject *type, PyObject * const*args,
                 size_t nargsf, PyObject *kwnames)
{
    if (!_PyArg_NoKwnames("float", kwnames)) {
        return NULL;
    }

    Py_ssize_t nargs = PyVectorcall_NARGS(nargsf);
    if (!_PyArg_CheckPositional("float", nargs, 0, 1)) {
        return NULL;
    }

    PyObject *x = nargs >= 1 ? args[0] : NULL;
    return float_vectorcall_impl(type, x);
}

static PyObject *
float_vectorcall_impl(PyObject *type, PyObject *x)
{
    return float_new_impl((PyTypeObject *)type, x);
}
--------------
 
where float_vectorcall() C code would be generated, and float_vectorcall_impl() would be the only part written manually. float_vectorcall_impl() gets a clean API and its body is way simpler to write and to maintain!

----------
components: C API
messages: 388354
nosy: corona10, serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: Generate vectorcall code to parse arguments using Argument Clinic
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43447>
_______________________________________

From report at bugs.python.org  Tue Mar  9 06:34:40 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Mar 2021 11:34:40 +0000
Subject: [issue43287] Use PEP 590 vectorcall to speed up calls to filter()
In-Reply-To: <1613930363.0.0.0194789956004.issue43287@roundup.psfhosted.org>
Message-ID: <1615289680.72.0.309018409483.issue43287@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

See also bpo-43447: "Generate vectorcall code to parse arguments using Argument Clinic".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43287>
_______________________________________

From report at bugs.python.org  Tue Mar  9 06:39:48 2021
From: report at bugs.python.org (miss-islington)
Date: Tue, 09 Mar 2021 11:39:48 +0000
Subject: [issue3329] API for setting the memory allocator used by Python
In-Reply-To: <1215632933.18.0.0332019532518.issue3329@psf.upfronthosting.co.za>
Message-ID: <1615289988.74.0.903665311724.issue3329@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ea46c7bc503d1103d60c0ec7023bb52c5defa11d by Miss Islington (bot) in branch '3.9':
bpo-3329: Fix typo in PyObjectArenaAllocator doc (GH-24795)
https://github.com/python/cpython/commit/ea46c7bc503d1103d60c0ec7023bb52c5defa11d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3329>
_______________________________________

From report at bugs.python.org  Tue Mar  9 06:45:07 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Mar 2021 11:45:07 +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: <1615290307.25.0.796141336218.issue43311@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43311>
_______________________________________

From report at bugs.python.org  Tue Mar  9 06:48:15 2021
From: report at bugs.python.org (Martin Panter)
Date: Tue, 09 Mar 2021 11:48:15 +0000
Subject: [issue43375] memory leak in threading ?
In-Reply-To: <1614708658.89.0.572605723578.issue43375@roundup.psfhosted.org>
Message-ID: <1615290495.79.0.718892222678.issue43375@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

Sounds the same as Issue 37788, which is still open.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43375>
_______________________________________

From report at bugs.python.org  Tue Mar  9 06:51:40 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Mar 2021 11:51:40 +0000
Subject: [issue43075] ReDoS in urllib.request
In-Reply-To: <1611994306.46.0.333529770265.issue43075@roundup.psfhosted.org>
Message-ID: <1615290700.0.0.917436810357.issue43075@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I see that you attached a redos_python.py benchmark (which looks like a benchmark that I wrote recently ;-)) but you didn't give results. Can you please show that your fix is effective to avoid catastrophic performances?

Is this issue related to the CVE-2020-8492? Is it the same issue or is it different?
https://python-security.readthedocs.io/vuln/urllib-basic-auth-regex.html

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43075>
_______________________________________

From report at bugs.python.org  Tue Mar  9 07:07:23 2021
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 09 Mar 2021 12:07:23 +0000
Subject: [issue43229] freeze searches libpython3.9.so in /usr/lib instead
 /usr/lib/x86_64-linux-gnu
In-Reply-To: <1613399795.84.0.430887747566.issue43229@roundup.psfhosted.org>
Message-ID: <1615291643.01.0.713487425657.issue43229@roundup.psfhosted.org>


Matthias Klose <doko at debian.org> added the comment:

Please could you edit
/usr/lib/python3.9/_sysconfigdata__x86_64-linux-gnu.py
setting LIBDIR to /usr/lib/x86_64-linux-gnu
and see if that fixes the freeze issue?

that could also be fixed by configuring with --libdir=/usr/lib/x86_64-linux-gnu

but that also moves lib-dynload into the new libdir.

# Detailed destination directories
BINLIBDEST=     $(LIBDIR)/python$(VERSION)
LIBDEST=        $(SCRIPTDIR)/python$(VERSION)
DESTSHARED=     $(BINLIBDEST)/lib-dynload

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43229>
_______________________________________

From report at bugs.python.org  Tue Mar  9 07:21:44 2021
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 09 Mar 2021 12:21:44 +0000
Subject: [issue43312] Interface to select preferred "user" or "home" sysconfig
 scheme for an environment
In-Reply-To: <1614158800.84.0.101101658017.issue43312@roundup.psfhosted.org>
Message-ID: <1615292504.83.0.55278086964.issue43312@roundup.psfhosted.org>


Matthias Klose <doko at debian.org> added the comment:

see also https://github.com/pypa/pip/issues/9617

----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43312>
_______________________________________

From report at bugs.python.org  Tue Mar  9 07:41:48 2021
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 09 Mar 2021 12:41:48 +0000
Subject: [issue43312] Interface to select preferred "user" or "home" sysconfig
 scheme for an environment
In-Reply-To: <1614158800.84.0.101101658017.issue43312@roundup.psfhosted.org>
Message-ID: <1615293708.9.0.687615805205.issue43312@roundup.psfhosted.org>


Matthias Klose <doko at debian.org> added the comment:

The Debian/Ubuntu packages have a local patch for distutils/setuptools introducing an --install-layout option.  Maybe have the same for pip?

The intention with renaming/moving site-packages to /usr/lib/python3/dist-packages is to avoid users damaging their system installation, like

  sudo python3 setup.py install
  sudo pip install

overriding packages installed with the distro package manager. Just making this schema known, and making it the default would again allow pip acting on packages managed by the distro package manager.

Otoh, there are use cases, where you want to use the Python provided by the Linux distro and run into issues with the custom dist-packages.

 - Creating a venv using the system Python probably should use
   the versioned site-packages.

 - Building on top of a docker image for e.g. a Python App, you
   probably want to install into the dist-packages provided by
   the system Python.

So the problem to solve is

 - let a "sudo pip install" fail by default on the real system
 - let the same install succeed in a docker environment, or any
   other "image".
 - behave transparently on venv and virtualenv installations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43312>
_______________________________________

From report at bugs.python.org  Tue Mar  9 08:02:48 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 09 Mar 2021 13:02:48 +0000
Subject: [issue43375] memory leak in threading ?
In-Reply-To: <1614708658.89.0.572605723578.issue43375@roundup.psfhosted.org>
Message-ID: <1615294968.25.0.560578411993.issue43375@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks; I missed that one. I'll update the state of this one to mark it as a duplicate of #37788.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43375>
_______________________________________

From report at bugs.python.org  Tue Mar  9 08:03:03 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 09 Mar 2021 13:03:03 +0000
Subject: [issue43375] memory leak in threading ?
In-Reply-To: <1614708658.89.0.572605723578.issue43375@roundup.psfhosted.org>
Message-ID: <1615294983.02.0.464320212575.issue43375@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
resolution:  -> duplicate
superseder:  -> fix for bpo-36402 (threading._shutdown() race condition) causes reference leak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43375>
_______________________________________

From report at bugs.python.org  Tue Mar  9 08:03:16 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 09 Mar 2021 13:03:16 +0000
Subject: [issue37788] fix for bpo-36402 (threading._shutdown() race condition)
 causes reference leak
In-Reply-To: <1565194972.64.0.065323919799.issue37788@roundup.psfhosted.org>
Message-ID: <1615294996.47.0.705637913425.issue37788@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/issue37788>
_______________________________________

From report at bugs.python.org  Tue Mar  9 08:22:56 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Tue, 09 Mar 2021 13:22:56 +0000
Subject: [issue43444] [sqlite3] Move MODULE_NAME def from setup.py to module.h
In-Reply-To: <1615286059.68.0.212415918598.issue43444@roundup.psfhosted.org>
Message-ID: <1615296176.72.0.951368464279.issue43444@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


----------
keywords: +patch
pull_requests: +23569
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24801

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43444>
_______________________________________

From report at bugs.python.org  Tue Mar  9 08:59:05 2021
From: report at bugs.python.org (Christian Bachmaier)
Date: Tue, 09 Mar 2021 13:59:05 +0000
Subject: [issue43229] freeze searches libpython3.9.so in /usr/lib instead
 /usr/lib/x86_64-linux-gnu
In-Reply-To: <1613399795.84.0.430887747566.issue43229@roundup.psfhosted.org>
Message-ID: <1615298345.3.0.653638429607.issue43229@roundup.psfhosted.org>


Christian Bachmaier <chris at infosun.fim.uni-passau.de> added the comment:

As for some time now, first I have to manually fix https://bugs.python.org/issue40350 first, i.e., use the recommended workaround not None check for spec.loader in /usr/lib/python3.9/modulefinder.py.


Setting LIBDIR to /usr/lib/x86_64-linux-gnu in /usr/lib/python3.9/_sysconfigdata__x86_64-linux-gnu.py
setting seams to fixe the issue linking issue of libpython3.9.so .


However, then the missing PyInit_lazr problem (as indicated in my first posting) stays:

...ml__sax__handler.o M_xml__sax__saxutils.o M_xml__sax__xmlreader.o M_xmlrpc.o M_xmlrpc__client.o M_zipfile.o M_zipimport.o /usr/lib/x86_64-linux-gnu/libpython3.9.so -lexpat                       -L/usr/lib -lz                        -lexpat  -lcrypt -lpthread -ldl  -lutil -lm -lm  -o helloworld
/usr/bin/ld: config.o:(.data.rel+0x278): undefined reference to `PyInit_lazr'
collect2: error: ld returned 1 exit status
make: *** [Makefile:900: helloworld] Error 1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43229>
_______________________________________

From report at bugs.python.org  Tue Mar  9 09:27:50 2021
From: report at bugs.python.org (JIanqiu Tao)
Date: Tue, 09 Mar 2021 14:27:50 +0000
Subject: [issue43439] [security] Add audit events on GC functions giving
 access to all Python objects
In-Reply-To: <1615235548.58.0.659993767767.issue43439@roundup.psfhosted.org>
Message-ID: <1615300070.79.0.804402758406.issue43439@roundup.psfhosted.org>


Change by JIanqiu Tao <zkonge at outlook.com>:


----------
nosy: +zkonge

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43439>
_______________________________________

From report at bugs.python.org  Tue Mar  9 09:28:32 2021
From: report at bugs.python.org (JIanqiu Tao)
Date: Tue, 09 Mar 2021 14:28:32 +0000
Subject: [issue43438] [doc] sys.addaudithook() documentation should be more
 explicit on its limitations
In-Reply-To: <1615235174.36.0.713670774369.issue43438@roundup.psfhosted.org>
Message-ID: <1615300112.23.0.788018058265.issue43438@roundup.psfhosted.org>


Change by JIanqiu Tao <zkonge at outlook.com>:


----------
nosy: +zkonge

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43438>
_______________________________________

From report at bugs.python.org  Tue Mar  9 10:02:02 2021
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 09 Mar 2021 15:02:02 +0000
Subject: [issue42658] os.path.normcase() is inconsistent with Windows file
 system
In-Reply-To: <1608122666.52.0.137113409131.issue42658@roundup.psfhosted.org>
Message-ID: <1615302122.43.0.226885055235.issue42658@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
components: +Library (Lib), Unicode
nosy: +ezio.melotti, vstinner
versions: +Python 3.10, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42658>
_______________________________________

From report at bugs.python.org  Tue Mar  9 10:06:51 2021
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 09 Mar 2021 15:06:51 +0000
Subject: [issue43397] Incorrect conversion path case with german character
In-Reply-To: <1614850926.28.0.842904177967.issue43397@roundup.psfhosted.org>
Message-ID: <1615302411.5.0.742068556632.issue43397@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

ntpath.normcase() needs a platform-dependent implementation that calls LCMapStringEx() in Windows, in order to properly agree with case-insensitive Windows filesystems. See bpo-42658.

----------
nosy: +eryksun
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> os.path.normcase() is inconsistent with Windows file system

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43397>
_______________________________________

From report at bugs.python.org  Tue Mar  9 10:25:26 2021
From: report at bugs.python.org (Max Bolingbroke)
Date: Tue, 09 Mar 2021 15:25:26 +0000
Subject: [issue7856] cannot decode from or encode to big5 \xf9\xd8
In-Reply-To: <1265346469.79.0.269704961777.issue7856@psf.upfronthosting.co.za>
Message-ID: <1615303526.68.0.981384649795.issue7856@roundup.psfhosted.org>


Max Bolingbroke <batterseapower at hotmail.com> added the comment:

As of Python 3.7.9 this also affects \xf9\xd6 which should be \u7881 in Unicode. This character is the second character of ?? which is the name of the Taiwanese electronics manufacturer Acer.

You can work around the issue using big5hkscs just like with the original \xf9\xd8 problem.

It looks like the F9D6?F9FE characters all come from the Big5-ETen extension (https://en.wikipedia.org/wiki/Big5#ETEN_extensions, https://moztw.org/docs/big5/table/eten.txt) which is so popular that it is a defacto standard. Big5-2003 (mentioned in a comment below) seems to be an extension of Big5-ETen. For what it's worth, whatwg includes these mappings in their own big5 reference tables: https://encoding.spec.whatwg.org/big5.html. 

Unfortunately Big5 is still in common use in Taiwan. It's pretty funny that Python fails to decode Big5 documents containing the name of one of Taiwan's largest multinationals :-)

----------
nosy: +batterseapower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue7856>
_______________________________________

From report at bugs.python.org  Tue Mar  9 10:42:58 2021
From: report at bugs.python.org (Keepun)
Date: Tue, 09 Mar 2021 15:42:58 +0000
Subject: [issue43448] exec() ignores scope.
Message-ID: <1615304578.57.0.704046890189.issue43448@roundup.psfhosted.org>


New submission from Keepun <keepun at gmail.com>:

exec() ignores scope.

Code:
--------------------------
class ExecTest:
    def public(self):
        h=None
        exec("h='It is public'")
        print(h)
        self._private()
    def _private(self):
        h=None
        exec("h='It is private'", globals(), locals())
        print(h)

h = None
exec("h='It is global'")
print(h)

e=ExecTest()
e.public()

Result
--------------------------
It is global
None
None

--------------------------
Python 3.7.10 (default, Feb 26 2021, 13:06:18) [MSC v.1916 64 bit (AMD64)]
and
Python 3.8.5 (default, Jan 27 2021, 15:41:15) [GCC 9.3.0]

----------
components: Interpreter Core
messages: 388366
nosy: Keepun
priority: normal
severity: normal
status: open
title: exec() ignores scope.
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43448>
_______________________________________

From report at bugs.python.org  Tue Mar  9 10:52:34 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 09 Mar 2021 15:52:34 +0000
Subject: [issue43435] Py_BuildValue("y#".... returns incomplete result
In-Reply-To: <1615217493.05.0.795009945001.issue43435@roundup.psfhosted.org>
Message-ID: <1615305154.26.0.532389849208.issue43435@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

David:

If you could give us an example showing the inputs, the actual outputs, and how they differ from what you expect, that would be helpful. Otherwise it's a lot of guessing on our part.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43435>
_______________________________________

From report at bugs.python.org  Tue Mar  9 11:04:50 2021
From: report at bugs.python.org (Riccardo Schirone)
Date: Tue, 09 Mar 2021 16:04:50 +0000
Subject: [issue42967] [CVE-2021-23336] urllib.parse.parse_qsl(): Web cache
 poisoning - `; ` as a query args separator
In-Reply-To: <1611068809.96.0.58823274544.issue42967@roundup.psfhosted.org>
Message-ID: <1615305890.19.0.277214716604.issue42967@roundup.psfhosted.org>


Riccardo Schirone <rschiron at redhat.com> added the comment:

This CVE was reported against Python, however it does not seem to be Python's fault for supporting the `;` separator, which was a valid separator for older standards.

@AdamGold for this issue to become a real security problem, it seems that the proxy has to be configured to ignore certain parameters in the query. For NGINX and Varnish proxies mentioned in the article it seems that by default they use the entire request path, host included, and other things as cache key. For NGINX in particular I could find some snippets online to manipulate the query arguments and split them in arguments, so to remove the "utm_*" arguments, however this does not seem a standard(or at least default) behaviour, nor something easily supported.

I think that if that is the case and a user has to go out of his way to configure the (wrong) splitting of arguments in the proxy, it is not fair to blame python for accepting `;` as separator and assigning a CVE against it may cause confusion.

For distributions this is problematic as they have 2 choices:
1) "fix" python but with the risk of breaking user's programs/scripts relying on the previous API
2) keep older version/unpatched python so that user's programs still work, but with a python version "vulnerable" to this CVE.

None of these options is really ideal, especially if the problem is somewhere else.

@AdamGold Could you elaborate a bit more on how common it is and how much configuration is required for proxies to make `;` a problem in python?

----------
nosy: +rschiron

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42967>
_______________________________________

From report at bugs.python.org  Tue Mar  9 11:07:53 2021
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 09 Mar 2021 16:07:53 +0000
Subject: [issue43435] Py_BuildValue("y#".... returns incomplete result
In-Reply-To: <1615217493.05.0.795009945001.issue43435@roundup.psfhosted.org>
Message-ID: <1615306073.28.0.117397431002.issue43435@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

A sleep(1) call affects exactly one aspect of the program: the state of the PRNG rand(). You re-initialize the process globale RNG in every function call with srand((unsigned) time(&t)). time() has a granularity of one second.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43435>
_______________________________________

From report at bugs.python.org  Tue Mar  9 11:41:50 2021
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 09 Mar 2021 16:41:50 +0000
Subject: [issue43448] exec() ignores scope.
In-Reply-To: <1615304578.57.0.704046890189.issue43448@roundup.psfhosted.org>
Message-ID: <1615308110.83.0.490043712681.issue43448@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

exec(obj, globals(), locals()) is the same as exec(obj). Also, locals in a function scope are optimized, so the locals() dict is a snapshot. Modifying the snapshot dict doesn't modify the optimized local variables. At most I think this issue is a duplicate of bpo-24800, to clarify the implicit local scope and behavior.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43448>
_______________________________________

From report at bugs.python.org  Tue Mar  9 13:10:28 2021
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 09 Mar 2021 18:10:28 +0000
Subject: [issue12956] builds fail when installing to --prefix with space in
 path name
In-Reply-To: <1315757316.68.0.219297921497.issue12956@psf.upfronthosting.co.za>
Message-ID: <1615313428.63.0.0600161715978.issue12956@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
resolution:  -> wont fix
stage: needs patch -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12956>
_______________________________________

From report at bugs.python.org  Tue Mar  9 13:15:25 2021
From: report at bugs.python.org (Jamie Kirkpatrick)
Date: Tue, 09 Mar 2021 18:15:25 +0000
Subject: [issue43449] multiprocessing.Pool - crash in subprocess causes
 deadlock in parent
Message-ID: <1615313725.52.0.420809061492.issue43449@roundup.psfhosted.org>


New submission from Jamie Kirkpatrick <jkp at kirkconsulting.co.uk>:

When using multiprocessing.Pool.apply[_async] a crash in the subprocess that is assigned the work item results in a deadlock in the parent process.

The parent process remains blissfully unaware of the crash in the subprocess and waits for a result forever. The parent process treats this as normal since the thread running _maintain_pool handles dead processes and repopulates the pool with a replacement subprocess.

See the test-case attached. Its not clear how this case should be handled but it can be very hard to trace issues in an application where this condition arises since all information about the crashing subprocess is lost (even with debug logging for the multiprocessing module enabled).

----------
components: Library (Lib)
files: test.py
messages: 388371
nosy: jkp
priority: normal
severity: normal
status: open
title: multiprocessing.Pool - crash in subprocess causes deadlock in parent
type: behavior
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49860/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43449>
_______________________________________

From report at bugs.python.org  Tue Mar  9 13:22:51 2021
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 09 Mar 2021 18:22:51 +0000
Subject: [issue15097] Improving wording on the thread-safeness of import
In-Reply-To: <1339943036.28.0.366324520843.issue15097@psf.upfronthosting.co.za>
Message-ID: <1615314171.4.0.540414537385.issue15097@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
stage:  -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15097>
_______________________________________

From report at bugs.python.org  Tue Mar  9 14:02:51 2021
From: report at bugs.python.org (=?utf-8?q?M=C3=A1rcio_Mocellin?=)
Date: Tue, 09 Mar 2021 19:02:51 +0000
Subject: [issue43450] List amnesia
Message-ID: <1615316571.19.0.916785177436.issue43450@roundup.psfhosted.org>


New submission from M?rcio Mocellin <marciomocellin at gmail.com>:

In Python 3.6.8 (default, Apr 16 2020, 01:36:27) [GCC 8.3.1 20191121 (Red Hat 8.3.1-5)] on linux, when I materialize the list, it is shown and is deleted. Shouldn't the list persist in memory? Is this a bug or is it really?

```python
>>> vet_neg
['EH01', 'EH02', 'EH03']
Categories (3, object): ['EH01', 'EH02', 'EH03']
>>> cenarios
[0, 1]
>>> vet_neg_cenarios = itertools.product(vet_neg, cenarios, cenarios)
>>> vet_neg_cenarios
<itertools.product object at 0x7f6fa16a65e8>
>>> list(vet_neg_cenarios)
[('EH01', 0, 0), ('EH01', 0, 1), ('EH01', 1, 0), ('EH01', 1, 1), ('EH02', 0, 0), ('EH02', 0, 1), ('EH02', 1, 0), ('EH02', 1, 1), ('EH03', 0, 0), ('EH03', 0, 1), ('EH03', 1, 0), ('EH03', 1, 1)]
>>> list(vet_neg_cenarios)
[]
>>> 
```

----------
messages: 388372
nosy: marciomocellin
priority: normal
severity: normal
status: open
title: List amnesia
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43450>
_______________________________________

From report at bugs.python.org  Tue Mar  9 14:12:29 2021
From: report at bugs.python.org (David Wilson)
Date: Tue, 09 Mar 2021 19:12:29 +0000
Subject: [issue43451] pydoc terminal suboptimal rendering of complex
 annotations
Message-ID: <1615317149.57.0.837523610181.issue43451@roundup.psfhosted.org>


New submission from David Wilson <dw at botanicus.net>:

When viewing docs for classes that use annotations, pydoc's rendering of argument lists is regularly truncated at the terminal edge (if using `less -S`), or wrapped in a manner where quickly scanning the output is next to impossible.

My 'classic' example is 'pydoc aiohttp.client.ClientSession', where the __init__ argument list wraps to 24 lines.

The pull request attached to this issue works around the problem by formatting arguments one-per-line if the sum of the arguments would exceed a hard-coded width of 150 characters. It is more of an RFC than a suggested fix. It produces acceptable formatting, but I'm not sure where the correct fix should be made -- in the inspect module, or somehow in the pydoc module, or even what the correct fix shuld be.

I will include a before/after screenshot in the pull request

I will attach before/after screenshot

----------
components: Library (Lib)
messages: 388373
nosy: dw
priority: normal
severity: normal
status: open
title: pydoc terminal suboptimal rendering of complex annotations
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43451>
_______________________________________

From report at bugs.python.org  Tue Mar  9 14:13:03 2021
From: report at bugs.python.org (Neil Schemenauer)
Date: Tue, 09 Mar 2021 19:13:03 +0000
Subject: [issue43445] Add frozen modules to sys.stdlib_module_names
In-Reply-To: <1615286111.17.0.443084957575.issue43445@roundup.psfhosted.org>
Message-ID: <1615317183.77.0.170902990759.issue43445@roundup.psfhosted.org>


Neil Schemenauer <nas-python at arctrix.com> added the comment:

Not sure the proper place to discuss this but I wonder if putting this stdlib module names list in the executable is the best idea.  The list of available stdlib modules could change after compiling Python.  I understand you don't want to dynamically crawl the library path the build the list.  That's too slow.  However, is there a really strong reason to embed it in the Python executable?

Did you consider generating a .py module, containing the list.  E.g. "_stdlib_modules.py" inside the lib folder.  Then, you can have site.py or some similar startup logic import that module and assign it to sys.stdlib_module_names.

----------
nosy: +nascheme

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43445>
_______________________________________

From report at bugs.python.org  Tue Mar  9 14:16:59 2021
From: report at bugs.python.org (David Wilson)
Date: Tue, 09 Mar 2021 19:16:59 +0000
Subject: [issue43451] pydoc terminal suboptimal rendering of complex
 annotations
In-Reply-To: <1615317149.57.0.837523610181.issue43451@roundup.psfhosted.org>
Message-ID: <1615317419.06.0.818304854312.issue43451@roundup.psfhosted.org>


Change by David Wilson <dw at botanicus.net>:


----------
keywords: +patch
pull_requests: +23570
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24802

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43451>
_______________________________________

From report at bugs.python.org  Tue Mar  9 14:17:16 2021
From: report at bugs.python.org (Florian Bruhin)
Date: Tue, 09 Mar 2021 19:17:16 +0000
Subject: [issue43450] List amnesia
In-Reply-To: <1615316571.19.0.916785177436.issue43450@roundup.psfhosted.org>
Message-ID: <1615317436.75.0.0788031997256.issue43450@roundup.psfhosted.org>


Florian Bruhin <python.org at the-compiler.org> added the comment:

This is not a bug. itertools.product returns an iterator: https://docs.python.org/3/glossary.html#term-iterator

Quoting from there:

> [...] every iterator is also iterable and may be used in most places where other iterables are accepted. One notable exception is code which attempts multiple iteration passes. A container object (such as a list) produces a fresh new iterator each time you pass it to the iter() function or use it in a for loop. Attempting this with an iterator will just return the same exhausted iterator object used in the previous iteration pass, making it appear like an empty container.

----------
nosy: +The Compiler

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43450>
_______________________________________

From report at bugs.python.org  Tue Mar  9 14:20:31 2021
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 09 Mar 2021 19:20:31 +0000
Subject: [issue43450] List amnesia
In-Reply-To: <1615316571.19.0.916785177436.issue43450@roundup.psfhosted.org>
Message-ID: <1615317631.58.0.700891688759.issue43450@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Florian's answer is correct. Thanks!

----------
nosy: +christian.heimes
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43450>
_______________________________________

From report at bugs.python.org  Tue Mar  9 14:21:17 2021
From: report at bugs.python.org (Dino Viehland)
Date: Tue, 09 Mar 2021 19:21:17 +0000
Subject: [issue43452] Microoptimize PyType_Lookup for cache hits
Message-ID: <1615317677.24.0.232039554227.issue43452@roundup.psfhosted.org>


New submission from Dino Viehland <dinoviehland at gmail.com>:

The common case going through _PyType_Lookup is to have a cache hit.  There's some small tweaks which can make this a little cheaper:

1) the name field identity is used for a cache hit, and is kept alive by the cache.  So there's no need to read the hash code of the name - instead the address can be used as the hash.

2) There's no need to check if the name is cachable on the lookup either, it probably is, and if it is, it'll be in the cache.

3) If we clear the version tag when invalidating a type then we don't actually need to check for a valid version tag bit.

----------
components: Interpreter Core
messages: 388377
nosy: dino.viehland
priority: normal
severity: normal
status: open
title: Microoptimize PyType_Lookup for cache hits
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43452>
_______________________________________

From report at bugs.python.org  Tue Mar  9 14:22:28 2021
From: report at bugs.python.org (Dino Viehland)
Date: Tue, 09 Mar 2021 19:22:28 +0000
Subject: [issue43452] Microoptimize PyType_Lookup for cache hits
In-Reply-To: <1615317677.24.0.232039554227.issue43452@roundup.psfhosted.org>
Message-ID: <1615317748.87.0.50923455616.issue43452@roundup.psfhosted.org>


Change by Dino Viehland <dinoviehland at gmail.com>:


----------
keywords: +patch
pull_requests: +23572
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24804

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43452>
_______________________________________

From report at bugs.python.org  Tue Mar  9 14:54:31 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Mar 2021 19:54:31 +0000
Subject: [issue43445] Add frozen modules to sys.stdlib_module_names
In-Reply-To: <1615286111.17.0.443084957575.issue43445@roundup.psfhosted.org>
Message-ID: <1615319671.73.0.988585768632.issue43445@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Neil Schemenauer: "Not sure the proper place to discuss this but I wonder if putting this stdlib module names list in the executable is the best idea."

For the rationale behind sys.stdlib_module_names, please see the bpo-42955 where alternative were discussed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43445>
_______________________________________

From report at bugs.python.org  Tue Mar  9 14:58:26 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Mar 2021 19:58:26 +0000
Subject: [issue43445] Add frozen modules to sys.stdlib_module_names
In-Reply-To: <1615286111.17.0.443084957575.issue43445@roundup.psfhosted.org>
Message-ID: <1615319906.01.0.230572017373.issue43445@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> The list of available stdlib modules could change after compiling Python.

It's documented:
"[ sys.stdlib_module_names] is the same on all platforms. Modules which are not available on some platforms and modules disabled at Python build are also listed."
https://docs.python.org/dev/library/sys.html#sys.stdlib_module_names

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43445>
_______________________________________

From report at bugs.python.org  Tue Mar  9 15:26:41 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Mar 2021 20:26:41 +0000
Subject: [issue7856] cannot decode from or encode to big5 \xf9\xd8
In-Reply-To: <1265346469.79.0.269704961777.issue7856@psf.upfronthosting.co.za>
Message-ID: <1615321601.76.0.675570750662.issue7856@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> It looks like the F9D6?F9FE characters all come from the Big5-ETen extension

One option would be to add a new big5eten encoding to Python. Someone has to implement the code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue7856>
_______________________________________

From report at bugs.python.org  Tue Mar  9 15:27:35 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Mar 2021 20:27:35 +0000
Subject: [issue7856] Add Big5-ETen codec: Python big5 codec cannot decode
 \xf9\xd8 bytes (U+7881 expected)
In-Reply-To: <1265346469.79.0.269704961777.issue7856@psf.upfronthosting.co.za>
Message-ID: <1615321655.68.0.137714775217.issue7856@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: cannot decode from or encode to big5 \xf9\xd8 -> Add Big5-ETen codec: Python big5 codec cannot decode \xf9\xd8 bytes (U+7881 expected)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue7856>
_______________________________________

From report at bugs.python.org  Tue Mar  9 15:27:48 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Mar 2021 20:27:48 +0000
Subject: [issue42658] os.path.normcase() is inconsistent with Windows file
 system
In-Reply-To: <1608122666.52.0.137113409131.issue42658@roundup.psfhosted.org>
Message-ID: <1615321668.73.0.78139711673.issue42658@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42658>
_______________________________________

From report at bugs.python.org  Tue Mar  9 15:36:37 2021
From: report at bugs.python.org (Jamie Kirkpatrick)
Date: Tue, 09 Mar 2021 20:36:37 +0000
Subject: [issue43449] multiprocessing.Pool - crash in subprocess causes
 deadlock in parent
In-Reply-To: <1615313725.52.0.420809061492.issue43449@roundup.psfhosted.org>
Message-ID: <1615322197.61.0.547322675504.issue43449@roundup.psfhosted.org>


Jamie Kirkpatrick <jkp at kirkconsulting.co.uk> added the comment:

More reading around this issue and I stumbled on an existing issue which this is a dup of so it can be closed.

https://bugs.python.org/issue22393

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43449>
_______________________________________

From report at bugs.python.org  Tue Mar  9 15:55:35 2021
From: report at bugs.python.org (Kamil Turek)
Date: Tue, 09 Mar 2021 20:55:35 +0000
Subject: [issue43446] Wrong character in footnote
In-Reply-To: <1615289575.44.0.162763918069.issue43446@roundup.psfhosted.org>
Message-ID: <1615323335.13.0.369508350871.issue43446@roundup.psfhosted.org>


Kamil Turek <tazzu at live.com> added the comment:

That's right. Actually, the docs code contains two dashes but I think second of them is skipped in build process.

Might be good to wrap it as an inline markup.

----------
nosy: +kamilturek

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43446>
_______________________________________

From report at bugs.python.org  Tue Mar  9 15:59:50 2021
From: report at bugs.python.org (Steve Dower)
Date: Tue, 09 Mar 2021 20:59:50 +0000
Subject: [issue43440] Enable rtree support in SQLite
In-Reply-To: <1615249448.96.0.887210184332.issue43440@roundup.psfhosted.org>
Message-ID: <1615323590.4.0.907132403127.issue43440@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 31818e98d3b845d815e9caf2a3d330341bdc1b33 by Erlend Egeberg Aasland in branch 'master':
bpo-43440 : Enable SQLite R*Tree support for windows builds (GH-24797)
https://github.com/python/cpython/commit/31818e98d3b845d815e9caf2a3d330341bdc1b33


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43440>
_______________________________________

From report at bugs.python.org  Tue Mar  9 16:01:17 2021
From: report at bugs.python.org (Steve Dower)
Date: Tue, 09 Mar 2021 21:01:17 +0000
Subject: [issue43440] Enable rtree support in SQLite
In-Reply-To: <1615249448.96.0.887210184332.issue43440@roundup.psfhosted.org>
Message-ID: <1615323677.6.0.813639969758.issue43440@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Perfect, thanks!

Callbacks are a bigger ask, but I don't have any fundamental opposition to them. Probably worth opening a new issue, as it'll affect all platforms (I assume).

And yeah, the setup.py in the CPython repo doesn't impact any of the Windows build at all. It needs to go into PCbuild somewhere as well.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43440>
_______________________________________

From report at bugs.python.org  Tue Mar  9 16:01:19 2021
From: report at bugs.python.org (Kamil Turek)
Date: Tue, 09 Mar 2021 21:01:19 +0000
Subject: [issue43446] Wrong character in footnote
In-Reply-To: <1615289575.44.0.162763918069.issue43446@roundup.psfhosted.org>
Message-ID: <1615323679.18.0.0172577244256.issue43446@roundup.psfhosted.org>


Change by Kamil Turek <tazzu at live.com>:


----------
keywords: +patch
pull_requests: +23573
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24806

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43446>
_______________________________________

From report at bugs.python.org  Tue Mar  9 16:08:46 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Tue, 09 Mar 2021 21:08:46 +0000
Subject: [issue43440] Enable rtree support in SQLite
In-Reply-To: <1615249448.96.0.887210184332.issue43440@roundup.psfhosted.org>
Message-ID: <1615324126.47.0.157804962274.issue43440@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

Anytime :)

I'll create an issue for rtree callbacks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43440>
_______________________________________

From report at bugs.python.org  Tue Mar  9 16:13:45 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Mar 2021 21:13:45 +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: <1615324425.38.0.437567425581.issue43311@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> PyInterpreterState_New call and use PyThreadState *tstate = _PyThreadState_GET();

It is safe to call _PyThreadState_GET() before _PyGILState_Init().

_PyThreadState_GET() calls _Py_atomic_load_relaxed(&_PyRuntime.gilstate.tstate_current), it doesn't use autoTSSkey. Or did I miss something?

Are you building Python with --with-experimental-isolated-subinterpreters?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43311>
_______________________________________

From report at bugs.python.org  Tue Mar  9 16:16:26 2021
From: report at bugs.python.org (Henry Schreiner)
Date: Tue, 09 Mar 2021 21:16:26 +0000
Subject: [issue43453] docs: runtime_checkable example refers to changed
 behavior in 3.10
Message-ID: <1615324586.52.0.680787948676.issue43453@roundup.psfhosted.org>


New submission from Henry Schreiner <henryschreineriii at gmail.com>:

The documentation here: https://docs.python.org/3/library/typing.html#typing.runtime_checkable refers to "For example, builtins.complex implements __float__(), therefore it passes an issubclass() check against SupportsFloat. However, the complex.__float__ method exists only to raise a TypeError with a more informative message.".

However, that's not true in Python 3.10 anymore, those methods were thankfully removed. See https://docs.python.org/3.10/whatsnew/3.10.html#removed or https://bugs.python.org/issue41974 for the removal.

This documentation should either say "before Python 3.10, ...", or pick some other example that still is valid. Happy to make the change if I know what direction this should go.

----------
assignee: docs at python
components: Documentation
messages: 388387
nosy: Henry Schreiner, docs at python
priority: normal
severity: normal
status: open
title: docs: runtime_checkable example refers to changed behavior in 3.10
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43453>
_______________________________________

From report at bugs.python.org  Tue Mar  9 16:39:43 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 09 Mar 2021 21:39:43 +0000
Subject: [issue43443] Should shelve support dict union?
In-Reply-To: <1615279595.44.0.954464448046.issue43443@roundup.psfhosted.org>
Message-ID: <1615325983.45.0.759083838111.issue43443@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> Maybe say that they implement the MutableMapping interface?

Yes, that's a good idea (also add link to the MutableMapping docs).

> Right, that seems like a good idea. But `__ior__` could
> be implemented nevertheless?

Off-hand, I don't see why not.

Adding Brandt to the nosy list to see what he thinks.

----------
nosy: +brandtbucher

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43443>
_______________________________________

From report at bugs.python.org  Tue Mar  9 16:43:12 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 09 Mar 2021 21:43:12 +0000
Subject: [issue43443] Should shelve support dict union?
In-Reply-To: <1615279595.44.0.954464448046.issue43443@roundup.psfhosted.org>
Message-ID: <1615326192.91.0.836922229638.issue43443@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

One other thought.  While __ior__() could be used as a short-cut for update(), the related __or__() method is more problematic because it would need to create a new underlying DB.  So maybe this is a can worms that we should not open. It would be weird to have __ior__() but not __or__().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43443>
_______________________________________

From report at bugs.python.org  Tue Mar  9 16:52:59 2021
From: report at bugs.python.org (Felipe)
Date: Tue, 09 Mar 2021 21:52:59 +0000
Subject: [issue42914] pprint numbers with underscore
In-Reply-To: <1614265965.43.0.0491684200471.issue42914@roundup.psfhosted.org>
Message-ID: <CAJEr+DO4Zfh=00cppALciw340NZZABgvsxK8FvySkDT9hn-4Rw@mail.gmail.com>


Felipe <felipe.nospam.ochoa at gmail.com> added the comment:

All yours! I'm tied up so won't be able to submit the PR

On Thu, 25 Feb 2021 at 10:12, St?phane Blondon <report at bugs.python.org>
wrote:

>
> St?phane Blondon <stephane.blondon at gmail.com> added the comment:
>
> I add the same idea but later than you, so I'm interested by such feature.
>
> Felipe: do you want to add a pull request to this issue (with Serhiy
> Storchaka implementation because it's the simplest one)?
>
> If not, I plan to write it.
> I will write it too if there is no reply in one month.
>
> ----------
> nosy: +sblondon
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue42914>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42914>
_______________________________________

From report at bugs.python.org  Tue Mar  9 16:54:25 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Tue, 09 Mar 2021 21:54:25 +0000
Subject: [issue43454] [sqlite3] Add support for R*Tree callbacks
Message-ID: <1615326865.81.0.691983788342.issue43454@roundup.psfhosted.org>


New submission from Erlend Egeberg Aasland <erlend.aasland at innova.no>:

Ref. bpo-43440

Now that both Windows and macOS builds compile SQLite with R*Tree support, we should consider adding support for R*Tree callbacks.

SQLite has two API's:
- sqlite3_rtree_query_callback() for SQLite 3.8.5 and newer.
- sqlite3_rtree_geometry_callback() for SQLite pre 3.8.5.

I suggest using the new API only, because it is more flexible, and it is also the one recommended by SQLite.

See https://sqlite.org/rtree.html


Python API:
sqlite3.Connection.create_rtree_query_function()

Too long function name?

As for the callback spec, I'm not sure what's the most pythonic approach?
callback(coords, *params, **query_info):
  coords   # array of coordinates of node or entry to check
  *params  # parameters passed to the SQL function
  **query_info # the rest of the relevant sqlite3_rtree_query_info members
  return (visibility, score)

----------
components: Library (Lib)
messages: 388391
nosy: berker.peksag, erlendaasland
priority: normal
severity: normal
status: open
title: [sqlite3] Add support for R*Tree callbacks
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43454>
_______________________________________

From report at bugs.python.org  Tue Mar  9 16:56:46 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Tue, 09 Mar 2021 21:56:46 +0000
Subject: [issue43440] Enable rtree support in SQLite
In-Reply-To: <1615249448.96.0.887210184332.issue43440@roundup.psfhosted.org>
Message-ID: <1615327006.09.0.489312777473.issue43440@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

I've opened bpo-43454 for R*Tree callbacks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43440>
_______________________________________

From report at bugs.python.org  Tue Mar  9 18:05:56 2021
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 09 Mar 2021 23:05:56 +0000
Subject: [issue43455] pathlib mistakenly assumes os.getcwd() is a resolved
 path in Windows
Message-ID: <1615331156.25.0.626111621937.issue43455@roundup.psfhosted.org>


New submission from Eryk Sun <eryksun at gmail.com>:

pathlib._WindowsFlavour.resolve() mistakenly assume that os.getcwd() returns a resolved path in Windows:

    s = str(path)
    if not s:
        return os.getcwd()

I don't think this is a practical problem since `str(path)` should never be an empty string. But if there is a concern that the result is an empty string, the code should use `s = str(path) or '.'`, and resolve "." like any other relative path.

In POSIX the result of getcwd() "shall contain no components that are dot or dot-dot, or are symbolic links". In Windows, os.getcwd() calls WinAPI GetCurrentDirectoryW(), which returns a fully-qualified path that may contain symbolic components that would be resolved in a final path. This includes filesystem symlinks and bind mounts (junctions), as well as mapped and substitute drives (i.e. drives that resolve to a filesystem directory instead of a volume device).

----------
components: Library (Lib), Windows
messages: 388393
nosy: eryksun, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: pathlib mistakenly assumes os.getcwd() is a resolved path in Windows
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43455>
_______________________________________

From report at bugs.python.org  Tue Mar  9 18:07:12 2021
From: report at bugs.python.org (Tzu-ping Chung)
Date: Tue, 09 Mar 2021 23:07:12 +0000
Subject: [issue43455] pathlib mistakenly assumes os.getcwd() is a resolved
 path in Windows
In-Reply-To: <1615331156.25.0.626111621937.issue43455@roundup.psfhosted.org>
Message-ID: <1615331232.69.0.308362224542.issue43455@roundup.psfhosted.org>


Change by Tzu-ping Chung <uranusjr at gmail.com>:


----------
keywords: +patch
nosy: +uranusjr
nosy_count: 5.0 -> 6.0
pull_requests: +23574
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17716

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43455>
_______________________________________

From report at bugs.python.org  Tue Mar  9 18:09:20 2021
From: report at bugs.python.org (Brandt Bucher)
Date: Tue, 09 Mar 2021 23:09:20 +0000
Subject: [issue43443] Should shelve support dict union?
In-Reply-To: <1615279595.44.0.954464448046.issue43443@roundup.psfhosted.org>
Message-ID: <1615331360.51.0.211256267237.issue43443@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

+1 for the MutableMapping comment.

We purposely omitted shelve when determining what classes should grow the new operators. Guido's thoughts:

> I definitely think we should leave Shelf alone, it's a toy class from a different era.

(https://bugs.python.org/msg364196)

I personally have no experience with shelve, so I'd rather defer to the judgement of others here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43443>
_______________________________________

From report at bugs.python.org  Tue Mar  9 18:35:33 2021
From: report at bugs.python.org (Dominik Vilsmeier)
Date: Tue, 09 Mar 2021 23:35:33 +0000
Subject: [issue43443] Should shelve support dict union?
In-Reply-To: <1615279595.44.0.954464448046.issue43443@roundup.psfhosted.org>
Message-ID: <1615332933.16.0.0663750094067.issue43443@roundup.psfhosted.org>


Dominik Vilsmeier <dominik.vilsmeier1123 at gmail.com> added the comment:

It's true, having `__ior__` but not `__or__` would probably be weird. In the end it's just "nice to have", but I'm not even sure that this applies. Calling `db.update(...)` is still more explicit than `db |= ...`.  The docs mention that

> This eases the transition from dictionary based scripts to those requiring persistent storage.

For my use cases, however, I always knew right from the beginning that I want object persistence between different runs of a script (e.g. for data analysis, caching the expensive results), so it was always clear that I'm working with a Shelf object and not a dict (i.e. no expectations on the availability of `|=`).

Primarily, this issue was meant to point out the mismatch of docs/implementation and not to get `|=` implemented for `Shelf`. In the end, I think updating the docs is all that is needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43443>
_______________________________________

From report at bugs.python.org  Tue Mar  9 18:41:50 2021
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 09 Mar 2021 23:41:50 +0000
Subject: [issue43446] Wrong character in footnote
In-Reply-To: <1615289575.44.0.162763918069.issue43446@roundup.psfhosted.org>
Message-ID: <1615333310.76.0.683191143739.issue43446@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 62a03cd490f81c0fb01eaceb31aa8a4c7800ed0e by Kamil Turek in branch 'master':
bpo-43446: Fix markup in sqlite3 footnote (GH-24806)
https://github.com/python/cpython/commit/62a03cd490f81c0fb01eaceb31aa8a4c7800ed0e


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43446>
_______________________________________

From report at bugs.python.org  Tue Mar  9 18:42:17 2021
From: report at bugs.python.org (miss-islington)
Date: Tue, 09 Mar 2021 23:42:17 +0000
Subject: [issue43446] Wrong character in footnote
In-Reply-To: <1615289575.44.0.162763918069.issue43446@roundup.psfhosted.org>
Message-ID: <1615333337.88.0.394850126521.issue43446@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +23576
pull_request: https://github.com/python/cpython/pull/24809

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43446>
_______________________________________

From report at bugs.python.org  Tue Mar  9 18:42:10 2021
From: report at bugs.python.org (miss-islington)
Date: Tue, 09 Mar 2021 23:42:10 +0000
Subject: [issue43446] Wrong character in footnote
In-Reply-To: <1615289575.44.0.162763918069.issue43446@roundup.psfhosted.org>
Message-ID: <1615333330.36.0.718183023829.issue43446@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: +23575
pull_request: https://github.com/python/cpython/pull/24808

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43446>
_______________________________________

From report at bugs.python.org  Tue Mar  9 18:43:25 2021
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 09 Mar 2021 23:43:25 +0000
Subject: [issue43446] Wrong character in footnote
In-Reply-To: <1615289575.44.0.162763918069.issue43446@roundup.psfhosted.org>
Message-ID: <1615333405.67.0.545041632104.issue43446@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset da602560a4816c88dcf4d75b3e4eea56c8d3bbc2 by Miss Islington (bot) in branch '3.9':
bpo-43446: Fix markup in sqlite3 footnote (GH-24806)
https://github.com/python/cpython/commit/da602560a4816c88dcf4d75b3e4eea56c8d3bbc2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43446>
_______________________________________

From report at bugs.python.org  Tue Mar  9 18:43:45 2021
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 09 Mar 2021 23:43:45 +0000
Subject: [issue43446] Wrong character in footnote
In-Reply-To: <1615289575.44.0.162763918069.issue43446@roundup.psfhosted.org>
Message-ID: <1615333425.91.0.151096633466.issue43446@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset e89380765df8f0f02c90ad417e164d1597bd0b05 by Miss Islington (bot) in branch '3.8':
bpo-43446: Fix markup in sqlite3 footnote (GH-24806)
https://github.com/python/cpython/commit/e89380765df8f0f02c90ad417e164d1597bd0b05


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43446>
_______________________________________

From report at bugs.python.org  Tue Mar  9 18:44:41 2021
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 09 Mar 2021 23:44:41 +0000
Subject: [issue43446] Wrong character in footnote
In-Reply-To: <1615289575.44.0.162763918069.issue43446@roundup.psfhosted.org>
Message-ID: <1615333481.9.0.243477859416.issue43446@roundup.psfhosted.org>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43446>
_______________________________________

From report at bugs.python.org  Tue Mar  9 19:31:39 2021
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Wed, 10 Mar 2021 00:31:39 +0000
Subject: [issue42988] [security] Information disclosure via pydoc -p:
 /getfile?key=path allows to read arbitrary file on the filesystem
In-Reply-To: <1611231517.86.0.296188996897.issue42988@roundup.psfhosted.org>
Message-ID: <1615336299.11.0.620753349125.issue42988@roundup.psfhosted.org>


Miro Hron?ok <miro at hroncok.cz> added the comment:

Todd Cullum from Red Hat Security team:

"I don't have an account on Python's tracker, would you mind forwarding to upstream on my behalf that this is not only locally exploitable, but it can be exploited by actors on the adjacent network as well because https://github.com/python/cpython/commit/6a396c9807b1674a24e240731f18e20de97117a5 was introduced in Python 3.7.0 alpha 1. I just used the -n option and got to read some of my own files using my cell phone on the WiFi. It does require the port to be unblocked by firewall though."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42988>
_______________________________________

From report at bugs.python.org  Tue Mar  9 19:54:03 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 10 Mar 2021 00:54:03 +0000
Subject: [issue43439] [security] Add audit events on GC functions giving
 access to all Python objects
In-Reply-To: <1615235548.58.0.659993767767.issue43439@roundup.psfhosted.org>
Message-ID: <1615337643.78.0.992241286116.issue43439@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset b4f9089d4aa787c5b74134c98e5f0f11d9e63095 by Pablo Galindo in branch 'master':
bpo-43439: Add audit hooks for gc functions (GH-24794)
https://github.com/python/cpython/commit/b4f9089d4aa787c5b74134c98e5f0f11d9e63095


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43439>
_______________________________________

From report at bugs.python.org  Tue Mar  9 19:55:49 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 10 Mar 2021 00:55:49 +0000
Subject: [issue43439] [security] Add audit events on GC functions giving
 access to all Python objects
In-Reply-To: <1615235548.58.0.659993767767.issue43439@roundup.psfhosted.org>
Message-ID: <1615337749.87.0.9154415878.issue43439@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +23577
pull_request: https://github.com/python/cpython/pull/24810

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43439>
_______________________________________

From report at bugs.python.org  Tue Mar  9 19:56:35 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 10 Mar 2021 00:56:35 +0000
Subject: [issue43439] [security] Add audit events on GC functions giving
 access to all Python objects
In-Reply-To: <1615235548.58.0.659993767767.issue43439@roundup.psfhosted.org>
Message-ID: <1615337795.09.0.995366159534.issue43439@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +23578
pull_request: https://github.com/python/cpython/pull/24811

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43439>
_______________________________________

From report at bugs.python.org  Tue Mar  9 20:24:59 2021
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 10 Mar 2021 01:24:59 +0000
Subject: [issue43456] Remove _xxsubinterpreters from sys.stdlib_module_names
Message-ID: <1615339499.12.0.300459298792.issue43456@roundup.psfhosted.org>


New submission from Brett Cannon <brett at python.org>:

I noticed that _xxsubinterpreters is in sys.stdlib_module_names but none of the other `_xx` modules are included (nor is 'test'). Since _xxsubinterpreters is only meant for testing (ATM) I think it should probably be left out.

----------
components: Library (Lib)
messages: 388401
nosy: brett.cannon, vstinner
priority: normal
severity: normal
status: open
title: Remove _xxsubinterpreters from sys.stdlib_module_names
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43456>
_______________________________________

From report at bugs.python.org  Tue Mar  9 20:37:50 2021
From: report at bugs.python.org (David Wood)
Date: Wed, 10 Mar 2021 01:37:50 +0000
Subject: [issue43435] Py_BuildValue("y#".... returns incomplete result
In-Reply-To: <1615217493.05.0.795009945001.issue43435@roundup.psfhosted.org>
Message-ID: <1615340270.66.0.479187861213.issue43435@roundup.psfhosted.org>


David Wood <dwoodjunkmail at gmail.com> added the comment:

Attached are the basic files.  As you can see in the example test9.py, I am generating a random string, encrypting it, decrypting it, and comparing the decrypted result with the original value.

This is intended to run on linux and requires the mcrypt library (libmcrypt-dev on debian based distro).  I'm at a loss and any help is greatly appreciated.

----------
Added file: https://bugs.python.org/file49861/crypt.tar.gz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43435>
_______________________________________

From report at bugs.python.org  Tue Mar  9 20:39:46 2021
From: report at bugs.python.org (David Wood)
Date: Wed, 10 Mar 2021 01:39:46 +0000
Subject: [issue43435] Py_BuildValue("y#".... returns incomplete result
In-Reply-To: <1615217493.05.0.795009945001.issue43435@roundup.psfhosted.org>
Message-ID: <1615340386.69.0.555822539405.issue43435@roundup.psfhosted.org>


Change by David Wood <dwoodjunkmail at gmail.com>:


Added file: https://bugs.python.org/file49862/crypt.tar.gz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43435>
_______________________________________

From report at bugs.python.org  Tue Mar  9 20:47:48 2021
From: report at bugs.python.org (David Wood)
Date: Wed, 10 Mar 2021 01:47:48 +0000
Subject: [issue43435] Py_BuildValue("y#".... returns incomplete result
In-Reply-To: <1615217493.05.0.795009945001.issue43435@roundup.psfhosted.org>
Message-ID: <1615340868.18.0.891154659525.issue43435@roundup.psfhosted.org>


Change by David Wood <dwoodjunkmail at gmail.com>:


Removed file: https://bugs.python.org/file49862/crypt.tar.gz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43435>
_______________________________________

From report at bugs.python.org  Tue Mar  9 21:05:40 2021
From: report at bugs.python.org (nervecenter)
Date: Wed, 10 Mar 2021 02:05:40 +0000
Subject: [issue43457] Include simple file loading and saving functions in JSON
 standard library.
Message-ID: <1615341940.36.0.754743862961.issue43457@roundup.psfhosted.org>


New submission from nervecenter <nervecenter7 at gmail.com>:

Python has a "batteries included" approach to standard library construction. To that end, commonly used procedures are often included as functions; adding sugar to the language is often exchanged for adding sugar to libraries.

One of these common procedures in small-scale scripting tasks is loading a JSON file as simple data structures and saving simple data structures as a JSON file. This is normally handled using context managers, json.load(), and json.dump(). This is a bit cluttered and, I'd argue, not quite as Pythonic as the philosophy demands. I have a small file containing this code:

import json

def load_file(filename, *args, **kwargs):
    with open(filename, "r") as fp:
        data = json.load(fp, *args, **kwargs)
    return data

def save_file(data, filename, *args, **kwargs):
    with open(filename, "w") as fp:
        json.dump(data, fp, *args, **kwargs)

I'd say, toss these two functions into the json module. Those two functions contain the clutter. For all other users, loading and saving JSON files become one-line function calls. This is convenient and batteries-included.

----------
components: Library (Lib)
messages: 388403
nosy: nervecenter
priority: normal
severity: normal
status: open
title: Include simple file loading and saving functions in JSON standard library.
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43457>
_______________________________________

From report at bugs.python.org  Tue Mar  9 22:09:46 2021
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 10 Mar 2021 03:09:46 +0000
Subject: [issue43457] Include simple file loading and saving functions in JSON
 standard library.
In-Reply-To: <1615341940.36.0.754743862961.issue43457@roundup.psfhosted.org>
Message-ID: <1615345786.24.0.678917232523.issue43457@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

This idea is discussed several times. Last discussion thread is:
https://mail.python.org/archives/list/python-ideas at python.org/thread/YHO575YY4FQC3GBDF4SKOWIEAUSY3OQX/#YHO575YY4FQC3GBDF4SKOWIEAUSY3OQX

----------
nosy: +methane

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43457>
_______________________________________

From report at bugs.python.org  Tue Mar  9 22:18:55 2021
From: report at bugs.python.org (=?utf-8?b?0JHQvtGA0LjRgSDQktC10YDRhdC+0LLRgdC60LjQuQ==?=)
Date: Wed, 10 Mar 2021 03:18:55 +0000
Subject: [issue43044] Python 2.7 documentation links to 404 pages when the
 library was moved or renamed
In-Reply-To: <1611789996.46.0.13568536358.issue43044@roundup.psfhosted.org>
Message-ID: <1615346335.1.0.175057033648.issue43044@roundup.psfhosted.org>


????? ?????????? <boris.verk at gmail.com> added the comment:

This was fixed using redirects in nginx 

https://github.com/python/psf-salt/pull/201

----------
resolution: out of date -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43044>
_______________________________________

From report at bugs.python.org  Tue Mar  9 22:56:35 2021
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 10 Mar 2021 03:56:35 +0000
Subject: [issue43457] Include simple file loading and saving functions in JSON
 standard library.
In-Reply-To: <1615341940.36.0.754743862961.issue43457@roundup.psfhosted.org>
Message-ID: <1615348595.99.0.0249327212626.issue43457@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

I created a new vote for naming.
https://discuss.python.org/t/vote-new-function-for-reading-json-from-path/7603

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43457>
_______________________________________

From report at bugs.python.org  Wed Mar 10 00:08:31 2021
From: report at bugs.python.org (Marek M)
Date: Wed, 10 Mar 2021 05:08:31 +0000
Subject: [issue43458] Tutorial should mention about variable scope in
 try/except/finally
Message-ID: <1615352911.49.0.844400259332.issue43458@roundup.psfhosted.org>


New submission from Marek M <deekox at gmail.com>:

It can be helpful to mention that variables defined in try block are visible in except/finally block as well. I did not find this info in Python tutorial and for me (having C++ background) this is quite unexpected feature.

----------
assignee: docs at python
components: Documentation
messages: 388407
nosy: deekox, docs at python
priority: normal
severity: normal
status: open
title: Tutorial should mention about variable scope in try/except/finally
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43458>
_______________________________________

From report at bugs.python.org  Wed Mar 10 02:17:29 2021
From: report at bugs.python.org (Pandu E POLUAN)
Date: Wed, 10 Mar 2021 07:17:29 +0000
Subject: [issue27820] Possible bug in smtplib when initial_response_ok=False
In-Reply-To: <1471739698.94.0.271523306415.issue27820@psf.upfronthosting.co.za>
Message-ID: <1615360649.84.0.327005937239.issue27820@roundup.psfhosted.org>


Pandu E POLUAN <pepoluan at gmail.com> added the comment:

Hi Senthil,

You're right, it does need a guard. According to my knowledge there is no AUTH mechanism that will send more than 3 challenges; they should fail afterwards with 535 or similar. Servers that don't do that should be considered buggy/broken.

So I've pushed a commit to the GH PR that limits the challenge to 5 times, after which it will raise SMTPException. This will protect users of smtplib.SMTP from being trapped by a buggy/broken server.


Rgds,
--

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27820>
_______________________________________

From report at bugs.python.org  Wed Mar 10 02:17:38 2021
From: report at bugs.python.org (junyixie)
Date: Wed, 10 Mar 2021 07:17:38 +0000
Subject: [issue39511] [subinterpreters] Per-interpreter singletons (None, True,
 False, etc.)
In-Reply-To: <1580484815.27.0.407070570821.issue39511@roundup.psfhosted.org>
Message-ID: <1615360658.63.0.230225616191.issue39511@roundup.psfhosted.org>


junyixie <xie.junyi at outlook.com> added the comment:

> Which API should be used in C extensions to be "subinterpreter-safe"? ?> Currently, Py_None is a singleton shared by multiple interpreters. > > > Should suddenly all C extensions use a new Py_GetNone() function which > returns the per-interpreter singleton? If yes, that's basically what my > PR 18301 does:

>   #define Py_None Py_GetNone()

after read you [WIP] bpo-39511: Add Py_GetNone() and Py_GetNoneRef() functions #18301.

Actually, interp->none shared _Py_NoneStruct variable.

when two interperter modify interp->none refcount,will modify _Py_NoneStruct variable.

> the CPU cacheline of common singletons like None, True and False can quickly become a performance bottleneck.

even if add Py_INCREF(none);. 
In the scenario of parallel interpreter, will also have thread safety issues.
> PyStatus
> _Py_InitSingletons(PyThreadState *tstate)
> {
>     PyObject *none = &_Py_NoneStruct;
>     Py_INCREF(none);
>     tstate->interp->none = none;
>     return _PyStatus_OK();
> }

----------
nosy: +JunyiXie -Mark.Shannon, corona10, eric.snow, jeremy.kloth, jkloth, larry, maciej.szulik, nanjekyejoannah, ncoghlan, phsilva, rhettinger, shihai1991, steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39511>
_______________________________________

From report at bugs.python.org  Wed Mar 10 02:42:12 2021
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=)
Date: Wed, 10 Mar 2021 07:42:12 +0000
Subject: [issue43459] Race conditions when the same source file used to build
 mutliple extensions
Message-ID: <1615362132.43.0.297389622008.issue43459@roundup.psfhosted.org>


New submission from Micha? G?rny <mgorny at gentoo.org>:

There is a race condition in distutils' build_ext implementation.  When the same source file is used to build multiple extensions, distutils attempts to build it multiple times using the same output file, in parallel.  This means that the link editor can grab the file while another compiler instance is overwriting it.  The results vary from compile errors to cryptic dyld failures when attempting to load the module.

I've created a trivial reproducer that I've attached in a patch form.  For convenience, it's also available on my GitHub: https://github.com/mgorny/distutils-build_ext-race

The reproducer consists of two extension modules sharing the same file.  The race.sh script attempts to build the extension and then import it.  The process is repeated until something fails, e.g.:

+ python3.10 setup.py build_ext -i -j4
running build_ext
building 'bar' extension
creating build
building 'foo' extension
creating build/temp.linux-x86_64-3.10
creating build/temp.linux-x86_64-3.10
x86_64-pc-linux-gnu-gcc-10.2.0 -pthread -fPIC -I/usr/include/python3.10 -c bar.c -o build/temp.linux-x86_64-3.10/bar.o
x86_64-pc-linux-gnu-gcc-10.2.0 -pthread -fPIC -I/usr/include/python3.10 -c foo.c -o build/temp.linux-x86_64-3.10/foo.o
x86_64-pc-linux-gnu-gcc-10.2.0 -pthread -fPIC -I/usr/include/python3.10 -c shared.c -o build/temp.linux-x86_64-3.10/shared.o
x86_64-pc-linux-gnu-gcc-10.2.0 -pthread -fPIC -I/usr/include/python3.10 -c shared.c -o build/temp.linux-x86_64-3.10/shared.o
x86_64-pc-linux-gnu-gcc-10.2.0 -pthread -shared -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu build/temp.linux-x86_64-3.10/foo.o build/temp.linux-x86_64-3.10/shared.o -L/usr/lib64 -o /home/mgorny/git/distutils-build_ext-race/foo.cpython-310-x86_64-linux-gnu.so
x86_64-pc-linux-gnu-gcc-10.2.0 -pthread -shared -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu build/temp.linux-x86_64-3.10/bar.o build/temp.linux-x86_64-3.10/shared.o -L/usr/lib64 -o /home/mgorny/git/distutils-build_ext-race/bar.cpython-310-x86_64-linux-gnu.so
+ python3.10 -c 'import foo; import bar'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: /home/mgorny/git/distutils-build_ext-race/foo.cpython-310-x86_64-linux-gnu.so: undefined symbol: call_shared
+ echo 'Reproduced at iteration 256'
Reproduced at iteration 256
+ break

----------
components: Distutils
files: 0001-A-reproducer-for-distutils-build_ext-race-condition.patch
keywords: patch
messages: 388410
nosy: dstufft, eric.araujo, mgorny
priority: normal
severity: normal
status: open
title: Race conditions when the same source file used to build mutliple extensions
type: compile error
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49863/0001-A-reproducer-for-distutils-build_ext-race-condition.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43459>
_______________________________________

From report at bugs.python.org  Wed Mar 10 03:46:38 2021
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 10 Mar 2021 08:46:38 +0000
Subject: [issue43435] Py_BuildValue("y#".... returns incomplete result
In-Reply-To: <1615217493.05.0.795009945001.issue43435@roundup.psfhosted.org>
Message-ID: <1615365998.08.0.691635908386.issue43435@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Could you please give us an example for an incorrect output and corresponding correct output as bytes representation?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43435>
_______________________________________

From report at bugs.python.org  Wed Mar 10 03:50:47 2021
From: report at bugs.python.org (miss-islington)
Date: Wed, 10 Mar 2021 08:50:47 +0000
Subject: [issue43439] [security] Add audit events on GC functions giving
 access to all Python objects
In-Reply-To: <1615235548.58.0.659993767767.issue43439@roundup.psfhosted.org>
Message-ID: <1615366247.61.0.907065237817.issue43439@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a6d0182879d0bf275c4feb38b57f73236ab9c06c by Pablo Galindo in branch '3.8':
[3.8] bpo-43439: Add audit hooks for gc functions (GH-24794). (GH-24810)
https://github.com/python/cpython/commit/a6d0182879d0bf275c4feb38b57f73236ab9c06c


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43439>
_______________________________________

From report at bugs.python.org  Wed Mar 10 03:50:48 2021
From: report at bugs.python.org (miss-islington)
Date: Wed, 10 Mar 2021 08:50:48 +0000
Subject: [issue43439] [security] Add audit events on GC functions giving
 access to all Python objects
In-Reply-To: <1615235548.58.0.659993767767.issue43439@roundup.psfhosted.org>
Message-ID: <1615366247.61.0.907065237817.issue43439@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a6d0182879d0bf275c4feb38b57f73236ab9c06c by Pablo Galindo in branch '3.8':
[3.8] bpo-43439: Add audit hooks for gc functions (GH-24794). (GH-24810)
https://github.com/python/cpython/commit/a6d0182879d0bf275c4feb38b57f73236ab9c06c


----------
nosy: +miss-islington, miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43439>
_______________________________________

From report at bugs.python.org  Wed Mar 10 03:50:48 2021
From: report at bugs.python.org (miss-islington)
Date: Wed, 10 Mar 2021 08:50:48 +0000
Subject: [issue43439] [security] Add audit events on GC functions giving
 access to all Python objects
In-Reply-To: <1615235548.58.0.659993767767.issue43439@roundup.psfhosted.org>
Message-ID: <1615366248.12.0.65382367571.issue43439@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset f814675376318e0bf9e14fc62826a113cb4ca652 by Pablo Galindo in branch '3.9':
[3.9] bpo-43439: Add audit hooks for gc functions (GH-24794). (GH-24811)
https://github.com/python/cpython/commit/f814675376318e0bf9e14fc62826a113cb4ca652


----------
nosy: +miss-islington, miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43439>
_______________________________________

From report at bugs.python.org  Wed Mar 10 03:51:21 2021
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 10 Mar 2021 08:51:21 +0000
Subject: [issue43439] [security] Add audit events on GC functions giving
 access to all Python objects
In-Reply-To: <1615235548.58.0.659993767767.issue43439@roundup.psfhosted.org>
Message-ID: <1615366281.99.0.787814212584.issue43439@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Thanks, Pablo and Victor!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43439>
_______________________________________

From report at bugs.python.org  Wed Mar 10 03:53:47 2021
From: report at bugs.python.org (Sergey B Kirpichev)
Date: Wed, 10 Mar 2021 08:53:47 +0000
Subject: [issue43420] Optimize rational arithmetics
In-Reply-To: <1615266669.06.0.0450552948441.issue43420@roundup.psfhosted.org>
Message-ID: <YEiJFY961Ar3IRIs@note>


Sergey B Kirpichev <skirpichev at gmail.com> added the comment:

On Tue, Mar 09, 2021 at 05:11:09AM +0000, Tim Peters wrote:
> those for + and - are much subtler

In fact, these optimizations will payoff faster (wrt denominators
size), esp. due to gcd==1 branch.

Sorry for off-topic:

> WRT which, I added Python's Karatsuba implementation and regret doing so.
> I don't want to take it out now (it's already in ;-) ), but it added quite
> a pile of delicate code to what _was_ a much easier module to grasp.

(And was much more useless, even as a fallback.

But in the end - I agreed, you can't outperform professional bigint
implementations.  I think, you can _use_ them instead.)

> People who need fast multiplication are still far better off using gmpy2 anyway

(Another strange python "feature", IMHO.  Why the custom bigint
implementation, why not use the project, that run professionals in the
field?  Looking on the issue 21922 - it seems, that small ints
arithmetics can be almost as fast as for python ints.  Is the
memory handling - out-of-memory situation - the only severe problem?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43420>
_______________________________________

From report at bugs.python.org  Wed Mar 10 03:53:49 2021
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 10 Mar 2021 08:53:49 +0000
Subject: [issue43364] Windows: Make UTF-8 mode more accessible
In-Reply-To: <1614675827.66.0.411790166938.issue43364@roundup.psfhosted.org>
Message-ID: <1615366429.88.0.531343303707.issue43364@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +23579
pull_request: https://github.com/python/cpython/pull/24813

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43364>
_______________________________________

From report at bugs.python.org  Wed Mar 10 03:55:08 2021
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 10 Mar 2021 08:55:08 +0000
Subject: [issue43364] Windows: Make UTF-8 mode more accessible
In-Reply-To: <1614675827.66.0.411790166938.issue43364@roundup.psfhosted.org>
Message-ID: <1615366508.23.0.513485532274.issue43364@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

> Maybe as a global setting, the better thing to copy is the button at the end of installation that offers to change the long path policy?

I tried it but there is no enough space.
See GH-24813 and attached screenshot.

----------
Added file: https://bugs.python.org/file49864/utf8mode-screenshot1.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43364>
_______________________________________

From report at bugs.python.org  Wed Mar 10 04:46:07 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Mar 2021 09:46:07 +0000
Subject: [issue39511] [subinterpreters] Per-interpreter singletons (None, True,
 False, etc.)
In-Reply-To: <1580484815.27.0.407070570821.issue39511@roundup.psfhosted.org>
Message-ID: <1615369567.36.0.400382296766.issue39511@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Actually, interp->none shared _Py_NoneStruct variable.

My PR 18301 is a draft to check if we can solve the issue without breaking the C API compatibility. You're right that it doesn't solve the issue, it only checks the C API issue. IMO the PR 18301 proves that the "#define Py_None Py_GetNone()" trick works.

--

By the way, when I worked on a tagged pointer experiment:
https://github.com/vstinner/cpython/pull/6

I had to introduce Py_IS_NONE(op) function, since it was no longer possible to compare directly "op == Py_None".

static inline int Py_IS_NONE(PyObject *op) {
    return (op == &_Py_NoneStruct || op == _Py_TAGPTR_NONE);
}

But this is not needed to solve this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39511>
_______________________________________

From report at bugs.python.org  Wed Mar 10 05:14:36 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Mar 2021 10:14:36 +0000
Subject: [issue43445] Add frozen modules to sys.stdlib_module_names
In-Reply-To: <1615286111.17.0.443084957575.issue43445@roundup.psfhosted.org>
Message-ID: <1615371276.41.0.753317738401.issue43445@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 307745aa42196ad3fd97fee4a1ae6496bb895596 by Victor Stinner in branch 'master':
bpo-43445: Add frozen modules to sys.stdlib_module_names (GH-24798)
https://github.com/python/cpython/commit/307745aa42196ad3fd97fee4a1ae6496bb895596


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43445>
_______________________________________

From report at bugs.python.org  Wed Mar 10 05:16:44 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Mar 2021 10:16:44 +0000
Subject: [issue42955] Add sys.stdlib_module_names: list of stdlib module names
 (Python and extension modules)
In-Reply-To: <1610964514.06.0.696047252341.issue42955@roundup.psfhosted.org>
Message-ID: <1615371404.82.0.352730067266.issue42955@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I also created a thread on python-dev to discuss this new feature:
https://mail.python.org/archives/list/python-dev at python.org/thread/BTX7SH2CR66QCLER2EXAK2GOUAH2U4CL/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42955>
_______________________________________

From report at bugs.python.org  Wed Mar 10 05:17:25 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Mar 2021 10:17:25 +0000
Subject: [issue43445] Add frozen modules to sys.stdlib_module_names
In-Reply-To: <1615286111.17.0.443084957575.issue43445@roundup.psfhosted.org>
Message-ID: <1615371445.89.0.398262542225.issue43445@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Neal: you may also read the thread on python-dev:
https://mail.python.org/archives/list/python-dev at python.org/thread/BTX7SH2CR66QCLER2EXAK2GOUAH2U4CL/

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43445>
_______________________________________

From report at bugs.python.org  Wed Mar 10 05:32:27 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Mar 2021 10:32:27 +0000
Subject: [issue43456] Remove _xxsubinterpreters from sys.stdlib_module_names
In-Reply-To: <1615339499.12.0.300459298792.issue43456@roundup.psfhosted.org>
Message-ID: <1615372347.05.0.472965506859.issue43456@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +23580
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24814

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43456>
_______________________________________

From report at bugs.python.org  Wed Mar 10 05:33:09 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Mar 2021 10:33:09 +0000
Subject: [issue43456] Remove _xxsubinterpreters from sys.stdlib_module_names
In-Reply-To: <1615339499.12.0.300459298792.issue43456@roundup.psfhosted.org>
Message-ID: <1615372389.77.0.204689316726.issue43456@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> I noticed that _xxsubinterpreters is in sys.stdlib_module_names but none of the other `_xx` modules are included (nor is 'test'). Since _xxsubinterpreters is only meant for testing (ATM) I think it should probably be left out.

Oh right, I agree that _xxsubinterpreters is not really part of the stdlib, it's more designed to write unit tests. I wrote PR 24814 to remove it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43456>
_______________________________________

From report at bugs.python.org  Wed Mar 10 05:34:25 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Mar 2021 10:34:25 +0000
Subject: [issue43456] Remove _xxsubinterpreters from sys.stdlib_module_names
In-Reply-To: <1615339499.12.0.300459298792.issue43456@roundup.psfhosted.org>
Message-ID: <1615372465.14.0.513748890781.issue43456@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

With PR 24814, sys.stdlib_module_names contains 301 names:

__future__
_abc
_aix_support
_ast
_asyncio
_bisect
_blake2
_bootsubprocess
_bz2
_codecs
_codecs_cn
_codecs_hk
_codecs_iso2022
_codecs_jp
_codecs_kr
_codecs_tw
_collections
_collections_abc
_compat_pickle
_compression
_contextvars
_crypt
_csv
_ctypes
_curses
_curses_panel
_datetime
_dbm
_decimal
_elementtree
_frozen_importlib
_frozen_importlib_external
_functools
_gdbm
_hashlib
_heapq
_imp
_io
_json
_locale
_lsprof
_lzma
_markupbase
_md5
_msi
_multibytecodec
_multiprocessing
_opcode
_operator
_osx_support
_pickle
_posixshmem
_posixsubprocess
_py_abc
_pydecimal
_pyio
_queue
_random
_sha1
_sha256
_sha3
_sha512
_signal
_sitebuiltins
_socket
_sqlite3
_sre
_ssl
_stat
_statistics
_string
_strptime
_struct
_symtable
_thread
_threading_local
_tkinter
_tracemalloc
_uuid
_warnings
_weakref
_weakrefset
_winapi
_zoneinfo
abc
aifc
antigravity
argparse
array
ast
asynchat
asyncio
asyncore
atexit
audioop
base64
bdb
binascii
binhex
bisect
builtins
bz2
cProfile
calendar
cgi
cgitb
chunk
cmath
cmd
code
codecs
codeop
collections
colorsys
compileall
concurrent
configparser
contextlib
contextvars
copy
copyreg
crypt
csv
ctypes
curses
dataclasses
datetime
dbm
decimal
difflib
dis
distutils
doctest
email
encodings
ensurepip
enum
errno
faulthandler
fcntl
filecmp
fileinput
fnmatch
fractions
ftplib
functools
gc
genericpath
getopt
getpass
gettext
glob
graphlib
grp
gzip
hashlib
heapq
hmac
html
http
idlelib
imaplib
imghdr
imp
importlib
inspect
io
ipaddress
itertools
json
keyword
lib2to3
linecache
locale
logging
lzma
mailbox
mailcap
marshal
math
mimetypes
mmap
modulefinder
msilib
msvcrt
multiprocessing
netrc
nis
nntplib
nt
ntpath
nturl2path
numbers
opcode
operator
optparse
os
ossaudiodev
pathlib
pdb
pickle
pickletools
pipes
pkgutil
platform
plistlib
poplib
posix
posixpath
pprint
profile
pstats
pty
pwd
py_compile
pyclbr
pydoc
pydoc_data
pyexpat
queue
quopri
random
re
readline
reprlib
resource
rlcompleter
runpy
sched
secrets
select
selectors
shelve
shlex
shutil
signal
site
smtpd
smtplib
sndhdr
socket
socketserver
spwd
sqlite3
sre_compile
sre_constants
sre_parse
ssl
stat
statistics
string
stringprep
struct
subprocess
sunau
symtable
sys
sysconfig
syslog
tabnanny
tarfile
telnetlib
tempfile
termios
textwrap
this
threading
time
timeit
tkinter
token
tokenize
trace
traceback
tracemalloc
tty
turtle
turtledemo
types
typing
unicodedata
unittest
urllib
uu
uuid
venv
warnings
wave
weakref
webbrowser
winreg
winsound
wsgiref
xdrlib
xml
xmlrpc
zipapp
zipfile
zipimport
zlib
zoneinfo

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43456>
_______________________________________

From report at bugs.python.org  Wed Mar 10 05:50:28 2021
From: report at bugs.python.org (=?utf-8?q?Viktor_Pl=C3=A9zer?=)
Date: Wed, 10 Mar 2021 10:50:28 +0000
Subject: [issue37374] Minidom does not have to escape quote inside text
 segments
In-Reply-To: <1561235660.5.0.339736322709.issue37374@roundup.psfhosted.org>
Message-ID: <1615373428.35.0.287586419551.issue37374@roundup.psfhosted.org>


Viktor Pl?zer <viktorplezer at gmail.com> added the comment:

Almost 2 years later I only registered to agree with Daniel. This is extremely annoying.

Use case: I am generating XMLs for Apigee, where my conditions contain quotes and there's no need to escape them.

----------
nosy: +viplezer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37374>
_______________________________________

From report at bugs.python.org  Wed Mar 10 05:53:53 2021
From: report at bugs.python.org (=?utf-8?q?Viktor_Pl=C3=A9zer?=)
Date: Wed, 10 Mar 2021 10:53:53 +0000
Subject: [issue37374] Minidom does not have to escape quote inside text
 segments
In-Reply-To: <1561235660.5.0.339736322709.issue37374@roundup.psfhosted.org>
Message-ID: <1615373633.16.0.548275215829.issue37374@roundup.psfhosted.org>


Viktor Pl?zer <viktorplezer at gmail.com> added the comment:

Sorry, to agree with @mitar

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37374>
_______________________________________

From report at bugs.python.org  Wed Mar 10 06:09:55 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 10 Mar 2021 11:09:55 +0000
Subject: [issue43448] exec() ignores scope.
In-Reply-To: <1615304578.57.0.704046890189.issue43448@roundup.psfhosted.org>
Message-ID: <1615374595.19.0.432879114757.issue43448@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> At most I think this issue is a duplicate of bpo-24800

Agreed; closing here.

----------
nosy: +mark.dickinson
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> exec docs should note that the no argument form in a local scope is really the two argument form

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43448>
_______________________________________

From report at bugs.python.org  Wed Mar 10 06:10:26 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Mar 2021 11:10:26 +0000
Subject: [issue43456] Remove _xxsubinterpreters from sys.stdlib_module_names
In-Reply-To: <1615339499.12.0.300459298792.issue43456@roundup.psfhosted.org>
Message-ID: <1615374626.29.0.453137345384.issue43456@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset a9c03d7fb78ab79710f79190f0584a09d9fd1a61 by Victor Stinner in branch 'master':
bpo-43456: Remove _xxsubinterpreters from sys.stdlib_module_names (GH-24814)
https://github.com/python/cpython/commit/a9c03d7fb78ab79710f79190f0584a09d9fd1a61


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43456>
_______________________________________

From report at bugs.python.org  Wed Mar 10 06:10:36 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Mar 2021 11:10:36 +0000
Subject: [issue43456] Remove _xxsubinterpreters from sys.stdlib_module_names
In-Reply-To: <1615339499.12.0.300459298792.issue43456@roundup.psfhosted.org>
Message-ID: <1615374636.31.0.201251134568.issue43456@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/issue43456>
_______________________________________

From report at bugs.python.org  Wed Mar 10 06:30:36 2021
From: report at bugs.python.org (Douglas Raillard)
Date: Wed, 10 Mar 2021 11:30:36 +0000
Subject: [issue43460] Exception copy  error
Message-ID: <1615375836.74.0.101407862938.issue43460@roundup.psfhosted.org>


New submission from Douglas Raillard <douglas.raillard at arm.com>:

Instances of subclasses of BaseException created with keyword argument fail to copy properly as demonstrated by:

    import copy

    class E(BaseException):
        def __init__(self, x):
            self.x=x

    # works fine
    e = E(None)
    copy.copy(e)

    # raises
    e = E(x=None)
    copy.copy(e)

This seems to affect all Python versions I've tested (3.6 <= Python <= 3.9).

I've currently partially worked around the issue with a custom pickler that just restores __dict__, but:

 * "args" is not part of __dict__, and setting "args" key in __dict__ does not create a "working object" (i.e. the key is set, but is ignored for all intents and purposes except direct lookup in __dict__)

 * pickle is friendly: you can provide a custom pickler that chooses the reduce function for each single class.
   copy module is much less friendly: copyreg.pickle() only allow registering custom functions for specific classes. That means there is no way (that I know) to make copy.copy() select a custom reduce for a whole subclass tree.


One the root of the issue:

 * exception from the standard library prevent keyword arguments (maybe because of that issue ?), but there is no such restriction on user-defined classes.
 * the culprit is BaseException_reduce() (in Objects/exceptions.c) [1]

It seems that the current behavior is a consequence of the __dict__ being created lazily, I assume for speed and memory efficiency

There seems to be a few approaches that would solve the issue:

 * keyword arguments passed to the constructor could be fused with the positional arguments in BaseException_new (using the signature, but signature might be not be available for extension types I suppose)

 * keyword arguments could just be stored like "args" in a "kwargs" attribute in PyException_HEAD, so they are preserved and passed again to __new__ when the instance is restored upon copying/pickling.

 * the fact that keyword arguments were used could be saved as a bool in PyException_HEAD. When set, this flag would make BaseException_reduce() only use __dict__ and not "args". This would technically probably be a breaking change, but the only cases I can think of where this would be observable are a bit far fetched (if __new__ or __init__ have side effects beyond storing attributes in __dict__).

[1] https://github.com/python/cpython/blob/master/Objects/exceptions.c#L134

----------
messages: 388427
nosy: douglas-raillard-arm
priority: normal
severity: normal
status: open
title: Exception copy  error
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43460>
_______________________________________

From report at bugs.python.org  Wed Mar 10 06:47:51 2021
From: report at bugs.python.org (Douglas Raillard)
Date: Wed, 10 Mar 2021 11:47:51 +0000
Subject: [issue43460] Exception copy  error
In-Reply-To: <1615375836.74.0.101407862938.issue43460@roundup.psfhosted.org>
Message-ID: <1615376871.09.0.380975849727.issue43460@roundup.psfhosted.org>


Douglas Raillard <douglas.raillard at arm.com> added the comment:

The solution based on the signature is something along those lines:

    class E(BaseException):
        def __new__(cls, *args, **kwargs):
            """
            Fix exception copying.

            Turn all the keyword arguments into positional arguments, so that the
            :exc:`BaseException` machinery has all the parameters for a valid call
            to ``__new__``, instead of missing all the keyword arguments.
            """
            sig = inspect.signature(cls.__init__)
            bound_args = sig.bind_partial(*args, **kwargs)
            bound_args.apply_defaults()
            args = tuple(bound_args.arguments.values())
            return super().__new__(cls, *args)

        def __init__(self, x):
            self.x=x

But there are a many shortcomings to that approach:

 * What if super().__new__() consumes arguments before passing the rest to __init__() ? This fix is blind to that since it only cares about __init__ signature

 * What if inspect.signature() does not provide a signature (extension modules) ?

 * Defaults are "hardcoded" in the args, so the object will always be restored with the defaults of the time it was created. This is a breaking change, as currently the defaults used when restoring the instance are the current ones.

 * Also uses more memory for args (and for pickle files), since it contains all the defaults

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43460>
_______________________________________

From report at bugs.python.org  Wed Mar 10 07:01:35 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Mar 2021 12:01:35 +0000
Subject: [issue43406] Possible race condition between signal catching and
 signal.signal
In-Reply-To: <1614893468.93.0.265748275948.issue43406@roundup.psfhosted.org>
Message-ID: <1615377695.23.0.852989815897.issue43406@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The change added a new functional test. As I expected, it failed on "AMD64 Debian root". I expected it because the previously added functional test failed failed on "AMD64 Debian root", I reported the race condition in 2017 and it's still not fixed: bpo-30849.

The new functional test has two race conditions.

I reopen the issue.


== Race condition 1 ==

AMD64 Debian root 3.x:
https://buildbot.python.org/all/#/builders/345/builds/903

0:15:05 load avg: 2.58 [137/427/1] test_signal failed (env changed) (1 min 13 sec)
Warning -- Unraisable exception
Traceback (most recent call last):
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/threading.py", line 1067, in _wait_for_tstate_lock
    elif lock.acquire(block, timeout):
OSError: Signal 10 ignored due to race condition


== Race condition 2 ==

By the way, the test also fails when I stress my laptop:

$ ./python -m test --fail-env-changed test_signal -F -j40 -m test_stress_modifying_handlers -v
== CPython 3.10.0a6+ (heads/master:a9c03d7fb7, Mar 10 2021, 12:41:26) [GCC 10.2.1 20201125 (Red Hat 10.2.1-9)]
== Linux-5.10.15-200.fc33.x86_64-x86_64-with-glibc2.32 little-endian
== cwd: /home/vstinner/python/master/build/test_python_223315?
== CPU count: 8
== encodings: locale=UTF-8, FS=utf-8
0:00:00 load avg: 4.17 Run tests in parallel using 40 child processes
(...)
0:00:05 load avg: 7.52 [  5/1] test_signal failed
test_stress_modifying_handlers (test.test_signal.StressTest) ... FAIL

======================================================================
FAIL: test_stress_modifying_handlers (test.test_signal.StressTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/vstinner/python/master/Lib/test/test_signal.py", line 1297, in test_stress_modifying_handlers
    self.assertGreater(num_received_signals, 0)
AssertionError: 0 not greater than 0

----------------------------------------------------------------------

Ran 1 test in 0.039s

FAILED (failures=1)
test test_signal failed
(...)

----------
nosy: +vstinner
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43406>
_______________________________________

From report at bugs.python.org  Wed Mar 10 07:23:57 2021
From: report at bugs.python.org (Jonathan Frawley)
Date: Wed, 10 Mar 2021 12:23:57 +0000
Subject: [issue43461] Tottime column for cprofile output does not add up
Message-ID: <1615379037.48.0.966046679388.issue43461@roundup.psfhosted.org>


New submission from Jonathan Frawley <jonathanfrawley at gmail.com>:

I am using cprofile and PStats to try and figure out where bottlenecks are in a program. When I sum up all of the times in the "tottime" column, it only comes to 57% of the total runtime. Is this due to rounding of times or some other issue?

----------
messages: 388430
nosy: jonathanfrawley
priority: normal
severity: normal
status: open
title: Tottime column for cprofile output does not add up
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43461>
_______________________________________

From report at bugs.python.org  Wed Mar 10 07:25:03 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Mar 2021 12:25:03 +0000
Subject: [issue43406] Possible race condition between signal catching and
 signal.signal
In-Reply-To: <1614893468.93.0.265748275948.issue43406@roundup.psfhosted.org>
Message-ID: <1615379103.43.0.0133515474177.issue43406@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +23581
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/24815

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43406>
_______________________________________

From report at bugs.python.org  Wed Mar 10 07:28:28 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Mar 2021 12:28:28 +0000
Subject: [issue43406] Possible race condition between signal catching and
 signal.signal
In-Reply-To: <1614893468.93.0.265748275948.issue43406@roundup.psfhosted.org>
Message-ID: <1615379308.92.0.343178551183.issue43406@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> The new functional test has two race conditions.

I don't think that it's a bug in Python, but more race conditions in the test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43406>
_______________________________________

From report at bugs.python.org  Wed Mar 10 08:51:23 2021
From: report at bugs.python.org (Vincent)
Date: Wed, 10 Mar 2021 13:51:23 +0000
Subject: [issue43462] canvas.bbox returns None on 'hidden' items while coords
 doesn't
Message-ID: <1615384283.9.0.940431260638.issue43462@roundup.psfhosted.org>


New submission from Vincent <inquiry at intoreflection.co>:

canvas.bbox() should return a tuple containing values whether an item is hidden or not. canvax.coords() does return a tuple when an item is hidden.

Steps to reproduce:

```
  from tkinter import * 
  root = Tk()
  canvas = Canvas(root)
  id1 = canvas.create_line(10,5,20,5, tags='tunnel')
  id2 = canvas.create_line(10,8,20,8, tags='tunnel')
  canvas.bbox('tunnel')   # return a tupple
  canvas.itemconfig('tunnel', state='hidden')
  canvas.bbox('tunnel')   # return nothing not even None
```

I need bbox to return a tuple containing values. The consequences is that the code must make the items temporarily visible before it can invoke the bbox function. This turning on and off creates flashing items in my program.

Thanks in advance!

----------
components: Tkinter
messages: 388432
nosy: Vincent
priority: normal
severity: normal
status: open
title: canvas.bbox returns None on 'hidden' items while coords doesn't
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43462>
_______________________________________

From report at bugs.python.org  Wed Mar 10 08:51:48 2021
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 10 Mar 2021 13:51:48 +0000
Subject: [issue42967] [CVE-2021-23336] urllib.parse.parse_qsl(): Web cache
 poisoning - `; ` as a query args separator
In-Reply-To: <1611068809.96.0.58823274544.issue42967@roundup.psfhosted.org>
Message-ID: <1615384308.36.0.679815186598.issue42967@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

With the fix, parse_qs[l] doesn't handle bytes separators correctly.
There is an explicit type check for str/bytes:

    if not separator or (not isinstance(separator, (str, bytes))):
        raise ValueError("Separator must be of type string or bytes.")

but a bytes separator fails further down:

>>> import urllib.parse
>>> urllib.parse.parse_qs('a=1,b=2', separator=b',')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/pviktori/dev/cpython/Lib/urllib/parse.py", line 695, in parse_qs
    pairs = parse_qsl(qs, keep_blank_values, strict_parsing,
  File "/home/pviktori/dev/cpython/Lib/urllib/parse.py", line 748, in parse_qsl
    pairs = [s1 for s1 in qs.split(separator)]
TypeError: must be str or None, not bytes

----------
nosy: +petr.viktorin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42967>
_______________________________________

From report at bugs.python.org  Wed Mar 10 08:52:20 2021
From: report at bugs.python.org (Vincent)
Date: Wed, 10 Mar 2021 13:52:20 +0000
Subject: [issue43462] canvas.bbox returns None on 'hidden' items while coords
 doesn't
In-Reply-To: <1615384283.9.0.940431260638.issue43462@roundup.psfhosted.org>
Message-ID: <1615384340.03.0.184186414857.issue43462@roundup.psfhosted.org>


Change by Vincent <inquiry at intoreflection.co>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43462>
_______________________________________

From report at bugs.python.org  Wed Mar 10 08:56:13 2021
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 10 Mar 2021 13:56:13 +0000
Subject: [issue42967] [CVE-2021-23336] urllib.parse.parse_qsl(): Web cache
 poisoning - `; ` as a query args separator
In-Reply-To: <1611068809.96.0.58823274544.issue42967@roundup.psfhosted.org>
Message-ID: <1615384573.59.0.240465346152.issue42967@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Petr, thank you. Let's treat it as a new issue linked to this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42967>
_______________________________________

From report at bugs.python.org  Wed Mar 10 09:27:02 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Mar 2021 14:27:02 +0000
Subject: [issue43406] Possible race condition between signal catching and
 signal.signal
In-Reply-To: <1614893468.93.0.265748275948.issue43406@roundup.psfhosted.org>
Message-ID: <1615386422.75.0.0799422840482.issue43406@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 1fa17e8cc62775a2e34b158135ce8589f9394f03 by Victor Stinner in branch 'master':
bpo-43406: Fix test_signal.test_stress_modifying_handlers() (GH-24815)
https://github.com/python/cpython/commit/1fa17e8cc62775a2e34b158135ce8589f9394f03


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43406>
_______________________________________

From report at bugs.python.org  Wed Mar 10 09:28:09 2021
From: report at bugs.python.org (miss-islington)
Date: Wed, 10 Mar 2021 14:28:09 +0000
Subject: [issue43406] Possible race condition between signal catching and
 signal.signal
In-Reply-To: <1614893468.93.0.265748275948.issue43406@roundup.psfhosted.org>
Message-ID: <1615386489.33.0.79268508922.issue43406@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +23583
pull_request: https://github.com/python/cpython/pull/24817

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43406>
_______________________________________

From report at bugs.python.org  Wed Mar 10 09:28:03 2021
From: report at bugs.python.org (miss-islington)
Date: Wed, 10 Mar 2021 14:28:03 +0000
Subject: [issue43406] Possible race condition between signal catching and
 signal.signal
In-Reply-To: <1614893468.93.0.265748275948.issue43406@roundup.psfhosted.org>
Message-ID: <1615386483.4.0.852928116287.issue43406@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +23582
pull_request: https://github.com/python/cpython/pull/24816

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43406>
_______________________________________

From report at bugs.python.org  Wed Mar 10 09:30:05 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Mar 2021 14:30:05 +0000
Subject: [issue43406] Possible race condition between signal catching and
 signal.signal
In-Reply-To: <1614893468.93.0.265748275948.issue43406@roundup.psfhosted.org>
Message-ID: <1615386605.97.0.177787428887.issue43406@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/issue43406>
_______________________________________

From report at bugs.python.org  Wed Mar 10 09:38:41 2021
From: report at bugs.python.org (Florian Bruhin)
Date: Wed, 10 Mar 2021 14:38:41 +0000
Subject: [issue43463] typing.get_type_hints with TYPE_CHECKING imports /
 getting hints for single argument
Message-ID: <1615387121.09.0.336024174905.issue43463@roundup.psfhosted.org>


New submission from Florian Bruhin <python.org at the-compiler.org>:

Consider a file such as:

    # from __future__ import annotations
    from typing import TYPE_CHECKING, Union, get_type_hints

    if TYPE_CHECKING:
        import types

    def fun(a: 'types.SimpleNamespace', b: Union[int, str]):
        pass

    print(fun.__annotations__)
    print(get_type_hints(fun))

When running this, typing.get_type_hints fails (as you would expect):

    Traceback (most recent call last):
      File "/home/florian/tmp/x.py", line 11, in <module>
        print(get_type_hints(fun))
      File "/usr/lib/python3.9/typing.py", line 1449, in get_type_hints
        value = _eval_type(value, globalns, localns)
      File "/usr/lib/python3.9/typing.py", line 283, in _eval_type
        return t._evaluate(globalns, localns, recursive_guard)
      File "/usr/lib/python3.9/typing.py", line 539, in _evaluate
        eval(self.__forward_code__, globalns, localns),
      File "<string>", line 1, in <module>
    NameError: name 'types' is not defined

However, in my case I'm not actually interested in the type of 'a', I only need the type for 'b'. Before Python 3.10 (or the __future__ import), I can do so by getting it from __annotations__ directly.

With Python 3.10 (or the __future__ import), this doesn't seem to be possible anymore - I'd need to either evaluate the 'Union[int, str]' annotation manually (perhaps calling into private typing.py functions), or maybe work around the issue by passing some magical dict-like object as local/globals which ignores the NameError. Both of those seem suboptimal.

Thus, I'd like a way to either:

1) Ignore exceptions in get_type_hints and instead get something like a typing.Unresolvable['types.SimpleNamespace'] back
2) Have something like a typing.get_argument_type_hints(fun, 'b') instead, allowing me to get the arguments one by one rather than resolving the whole thing
3) Have a public API to resolve a string type annotation (i.e. the equivalent of `typing._eval_type`)

----------
components: Library (Lib)
messages: 388436
nosy: The Compiler, gvanrossum, levkivskyi
priority: normal
severity: normal
status: open
title: typing.get_type_hints with TYPE_CHECKING imports / getting hints for single argument
type: behavior
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43463>
_______________________________________

From report at bugs.python.org  Wed Mar 10 09:46:26 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 10 Mar 2021 14:46:26 +0000
Subject: [issue43463] typing.get_type_hints with TYPE_CHECKING imports /
 getting hints for single argument
In-Reply-To: <1615387121.09.0.336024174905.issue43463@roundup.psfhosted.org>
Message-ID: <1615387586.92.0.284913363806.issue43463@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43463>
_______________________________________

From report at bugs.python.org  Wed Mar 10 09:49:35 2021
From: report at bugs.python.org (miss-islington)
Date: Wed, 10 Mar 2021 14:49:35 +0000
Subject: [issue43406] Possible race condition between signal catching and
 signal.signal
In-Reply-To: <1614893468.93.0.265748275948.issue43406@roundup.psfhosted.org>
Message-ID: <1615387775.68.0.464659312463.issue43406@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ac5e23c540f5ec20fc390c72e097e0fdaf8b7ac9 by Miss Islington (bot) in branch '3.8':
bpo-43406: Fix test_signal.test_stress_modifying_handlers() (GH-24815)
https://github.com/python/cpython/commit/ac5e23c540f5ec20fc390c72e097e0fdaf8b7ac9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43406>
_______________________________________

From report at bugs.python.org  Wed Mar 10 09:52:42 2021
From: report at bugs.python.org (Ken Jin)
Date: Wed, 10 Mar 2021 14:52:42 +0000
Subject: [issue43463] typing.get_type_hints with TYPE_CHECKING imports /
 getting hints for single argument
In-Reply-To: <1615387121.09.0.336024174905.issue43463@roundup.psfhosted.org>
Message-ID: <1615387962.54.0.436103071498.issue43463@roundup.psfhosted.org>


Change by Ken Jin <kenjin4096 at gmail.com>:


----------
nosy: +kj

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43463>
_______________________________________

From report at bugs.python.org  Wed Mar 10 09:57:59 2021
From: report at bugs.python.org (Ken Jin)
Date: Wed, 10 Mar 2021 14:57:59 +0000
Subject: [issue42967] [CVE-2021-23336] urllib.parse.parse_qsl(): Web cache
 poisoning - `; ` as a query args separator
In-Reply-To: <1611068809.96.0.58823274544.issue42967@roundup.psfhosted.org>
Message-ID: <1615388279.03.0.103733310135.issue42967@roundup.psfhosted.org>


Change by Ken Jin <kenjin4096 at gmail.com>:


----------
pull_requests: +23584
pull_request: https://github.com/python/cpython/pull/24818

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42967>
_______________________________________

From report at bugs.python.org  Wed Mar 10 10:11:06 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Mar 2021 15:11:06 +0000
Subject: [issue43406] Possible race condition between signal catching and
 signal.signal
In-Reply-To: <1614893468.93.0.265748275948.issue43406@roundup.psfhosted.org>
Message-ID: <1615389066.05.0.358379497129.issue43406@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 531f2ebd60a662111c78107935d249d3d52f9a4f by Miss Islington (bot) in branch '3.9':
bpo-43406: Fix test_signal.test_stress_modifying_handlers() (GH-24815) (GH-24817)
https://github.com/python/cpython/commit/531f2ebd60a662111c78107935d249d3d52f9a4f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43406>
_______________________________________

From report at bugs.python.org  Wed Mar 10 10:55:54 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 10 Mar 2021 15:55:54 +0000
Subject: [issue43462] canvas.bbox returns None on 'hidden' items while coords
 doesn't
In-Reply-To: <1615384283.9.0.940431260638.issue43462@roundup.psfhosted.org>
Message-ID: <1615391754.39.0.912353079953.issue43462@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

What do you mean by "return nothing not even None"? Does it hang?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43462>
_______________________________________

From report at bugs.python.org  Wed Mar 10 10:57:50 2021
From: report at bugs.python.org (Riccardo Schirone)
Date: Wed, 10 Mar 2021 15:57:50 +0000
Subject: [issue42967] [CVE-2021-23336] urllib.parse.parse_qsl(): Web cache
 poisoning - `; ` as a query args separator
In-Reply-To: <1611068809.96.0.58823274544.issue42967@roundup.psfhosted.org>
Message-ID: <1615391870.5.0.927078641333.issue42967@roundup.psfhosted.org>


Riccardo Schirone <rschiron at redhat.com> added the comment:

> So far, we at openSUSE had to package at least SQLAlchemy, Twisted, yarl and furl. The author of the first one acknowledged use of semicolon as a bug. I don't think it was so bad.

Did you upstream fixes for those packages?

Asking because if this is considered a vulnerability in Python, it should be considered a vulnerability for every other tool/library that accept `;` as separator. For example, Twisted seems to have a parse_qs method in web/http.py file that splits by both `;` and `&`.

Again, I feel like we are blaming the wrong piece of the stack, unless proxies are usually ignoring some arguments (e.g. utm_*) as part of the cache key, by default or in a very easy way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42967>
_______________________________________

From report at bugs.python.org  Wed Mar 10 11:23:51 2021
From: report at bugs.python.org (junyixie)
Date: Wed, 10 Mar 2021 16:23:51 +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: <1615393431.31.0.243262866605.issue43311@roundup.psfhosted.org>


junyixie <xie.junyi at outlook.com> added the comment:

Yes, this is an issue under building Python with --with-experimental-isolated-subinterpreters

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43311>
_______________________________________

From report at bugs.python.org  Wed Mar 10 11:39:19 2021
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 10 Mar 2021 16:39:19 +0000
Subject: [issue43464] set intersections should short-circuit
Message-ID: <1615394359.7.0.616950024555.issue43464@roundup.psfhosted.org>


New submission from Josh Rosenberg <shadowranger+python at gmail.com>:

At present, set_intersection (the C name for set.intersection) optimizes for pairs of sets by iterating the smallest set and only adding entries found in the larger, meaning work is proportionate to the smallest input.

But when the other input isn't a set, it goes with a naive solution, iterating the entire non-set, and adding entries found in the set. This is fine when the intersection will end up smaller than the original set (there's no way to avoid exhausting the non-set when that's the case), but when the intersection ends up being the same size as the original, we could add a cheap length check and short-circuit at that point.

As is, {4}.intersection(range(10000)) takes close to 1000 times longer than {4}.intersection(range(10)) despite both of them reaching the point where the outcome will be {4} at the same time.

Since the length check for short-circuiting only needs to be performed when input set actually contains the value, the cost should be fairly low.

I figure this would be the worst case for the change:

{3, 4}.intersection((4,) * 10000)

where it performs the length check every time, and doesn't benefit from short-circuiting. But cases like:

{4}.intersection((4,) * 10000)

or

{4}.intersection(range(10000))

would finish much faster. A similar optimization to set_intersection_multi (to stop when the intermediate result is empty) would make cases like:

{4000}.intersection([1], range(10000), range(100000, 200000))

also finish dramatically quicker in the (I'd assume not uncommon case) where the intersection of many iterables is empty, and this could be known quite early on (the cost of this check would be even lower, since it would only be performed once per iterable, not per-value).

Only behavioral change this would cause is that errors resulting from processing items in an iterable that is no longer run to exhaustion due to short-circuiting wouldn't happen ({4}.intersection([4, []]) currently dies, but would succeed with short-circuiting; same foes for {4}.intersection([5], [[]]) if set_intersection_multi is optimized), and input iterators might be left only partially consumed. If that's acceptable, the required code changes are trivial.

----------
components: C API
keywords: easy (C)
messages: 388442
nosy: josh.r
priority: normal
severity: normal
status: open
title: set intersections should short-circuit
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43464>
_______________________________________

From report at bugs.python.org  Wed Mar 10 11:40:03 2021
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 10 Mar 2021 16:40:03 +0000
Subject: [issue43287] Use PEP 590 vectorcall to speed up calls to filter()
In-Reply-To: <1613930363.0.0.0194789956004.issue43287@roundup.psfhosted.org>
Message-ID: <1615394403.38.0.295755495213.issue43287@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:


New changeset 9a9c11ad41d7887f3d6440e0f0e8966156d959b5 by Dong-hee Na in branch 'master':
bpo-43287: Use PEP 590 vectorcall to speed up filter() (GH-24611)
https://github.com/python/cpython/commit/9a9c11ad41d7887f3d6440e0f0e8966156d959b5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43287>
_______________________________________

From report at bugs.python.org  Wed Mar 10 11:40:19 2021
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 10 Mar 2021 16:40:19 +0000
Subject: [issue43287] Use PEP 590 vectorcall to speed up calls to filter()
In-Reply-To: <1613930363.0.0.0194789956004.issue43287@roundup.psfhosted.org>
Message-ID: <1615394419.8.0.307485043768.issue43287@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43287>
_______________________________________

From report at bugs.python.org  Wed Mar 10 11:44:44 2021
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 10 Mar 2021 16:44:44 +0000
Subject: [issue43464] set intersections should short-circuit
In-Reply-To: <1615394359.7.0.616950024555.issue43464@roundup.psfhosted.org>
Message-ID: <1615394684.65.0.15920779246.issue43464@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/issue43464>
_______________________________________

From report at bugs.python.org  Wed Mar 10 11:49:26 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 10 Mar 2021 16:49:26 +0000
Subject: [issue43463] typing.get_type_hints with TYPE_CHECKING imports /
 getting hints for single argument
In-Reply-To: <1615387121.09.0.336024174905.issue43463@roundup.psfhosted.org>
Message-ID: <1615394966.02.0.00603418979561.issue43463@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Maybe return the original string?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43463>
_______________________________________

From report at bugs.python.org  Wed Mar 10 12:18:01 2021
From: report at bugs.python.org (Mariusz Felisiak)
Date: Wed, 10 Mar 2021 17:18:01 +0000
Subject: [issue43353] Document that logging.getLevelName() can return a
 numeric value.
In-Reply-To: <1614600000.66.0.180359096956.issue43353@roundup.psfhosted.org>
Message-ID: <1615396681.92.0.433902540633.issue43353@roundup.psfhosted.org>


Mariusz Felisiak <felisiak.mariusz at gmail.com> added the comment:

Do we want to backport this patch? If yes, I can prepare backports. If not, we can close the ticket.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43353>
_______________________________________

From report at bugs.python.org  Wed Mar 10 12:25:29 2021
From: report at bugs.python.org (Fred Drake)
Date: Wed, 10 Mar 2021 17:25:29 +0000
Subject: [issue43353] Document that logging.getLevelName() can return a
 numeric value.
In-Reply-To: <1614600000.66.0.180359096956.issue43353@roundup.psfhosted.org>
Message-ID: <1615397129.7.0.528776503021.issue43353@roundup.psfhosted.org>


Fred Drake <fdrake at gmail.com> added the comment:

Just noticed this fly by in the stream of emails... sorry for not commenting earlier.

The patch seems to describe "Level #" as "numeric", which I would not be inclined to do.  It includes the numeric value since there's no available name for it, but as a value, it's still textual.

I'm referring specifically to the change here:
https://github.com/python/cpython/commit/bbba28212ce0f58096a4043f32442c6e727b74fc#diff-1bf0ad6d121df3948853dafdd8e5406709fe0c3911b30e3cf2def41717455c98R121

Otherwise, I do believe this should be back-ported.

----------
nosy: +fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43353>
_______________________________________

From report at bugs.python.org  Wed Mar 10 12:40:30 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 10 Mar 2021 17:40:30 +0000
Subject: [issue42967] [CVE-2021-23336] urllib.parse.parse_qsl(): Web cache
 poisoning - `; ` as a query args separator
In-Reply-To: <1611068809.96.0.58823274544.issue42967@roundup.psfhosted.org>
Message-ID: <1615398030.4.0.938541500765.issue42967@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

Riccardo - FWIW I agree, the wrong part of the stack was blamed and a CVE was wrongly sought for against CPython on this one.

It's sewage under the bridge at this point. The API change has shipped in several different stable releases and thus is something virtually Python all code must now deal with.

Why was this a bad change to make?  Python's parse_qsl obeyed the prevailing HTML 4 standard at the time it was written:

https://www.w3.org/TR/html401/appendix/notes.html#ampersands-in-uris

'''
We recommend that HTTP server implementors, and in particular, CGI implementors support the use of ";" in place of "&"
'''

That turns out to have been bad advice in the standard. 15 years later the html5 standard quoted in Adam's snyk blog post links to its text on this which leaves no room for that interpretation.

In that light, the correct thing to do for this issue would be to:

* Make the default behavior change in 3.10 match the html5 standard [done].
* Document that it matches the html4 standard in 3.9 and earlier without changing their default behavior [oops, too late, not done].
* While adding the ability to allow applications to select the stricter behavior on those older versions.  [only sort of done, and somewhat too late now that the strict version has already shipped as stable]

Afterall, the existence of html5 didn't magically fix all of the html and web applications written in the two decades of web that came before it.  Ask any browser author...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42967>
_______________________________________

From report at bugs.python.org  Wed Mar 10 13:00:16 2021
From: report at bugs.python.org (Mariusz Felisiak)
Date: Wed, 10 Mar 2021 18:00:16 +0000
Subject: [issue43353] Document that logging.getLevelName() can return a
 numeric value.
In-Reply-To: <1614600000.66.0.180359096956.issue43353@roundup.psfhosted.org>
Message-ID: <1615399216.53.0.47454540652.issue43353@roundup.psfhosted.org>


Mariusz Felisiak <felisiak.mariusz at gmail.com> added the comment:

"numeric" doesn't refer to the "Level #" representation but to the fact that `getLevelName()` returns a numeric value when the corresponding name is passed, e.g.

>>> getLevelName('CRITICAL') 
50

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43353>
_______________________________________

From report at bugs.python.org  Wed Mar 10 13:04:55 2021
From: report at bugs.python.org (Fred Drake)
Date: Wed, 10 Mar 2021 18:04:55 +0000
Subject: [issue43353] Document that logging.getLevelName() can return a
 numeric value.
In-Reply-To: <1614600000.66.0.180359096956.issue43353@roundup.psfhosted.org>
Message-ID: <1615399495.79.0.769392593462.issue43353@roundup.psfhosted.org>


Fred Drake <fdrake at gmail.com> added the comment:

Mariusz: Good point.  IMO, an insane API behavior, but a legacy we must live with.

No further objections from me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43353>
_______________________________________

From report at bugs.python.org  Wed Mar 10 13:14:13 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Mar 2021 18:14:13 +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: <1615400053.87.0.95079870364.issue43311@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +23585
pull_request: https://github.com/python/cpython/pull/24819

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43311>
_______________________________________

From report at bugs.python.org  Wed Mar 10 13:46:41 2021
From: report at bugs.python.org (Vincent)
Date: Wed, 10 Mar 2021 18:46:41 +0000
Subject: [issue43462] canvas.bbox returns None on 'hidden' items while coords
 doesn't
In-Reply-To: <1615384283.9.0.940431260638.issue43462@roundup.psfhosted.org>
Message-ID: <1615402001.17.0.0828737712847.issue43462@roundup.psfhosted.org>


Vincent <inquiry at intoreflection.co> added the comment:

No, not hang. It returns a NoneType.

See this example:

>>> x = canvas.bbox('tunnel')
>>> type(x)
<class 'NoneType'>
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43462>
_______________________________________

From report at bugs.python.org  Wed Mar 10 13:49:22 2021
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Wed, 10 Mar 2021 18:49:22 +0000
Subject: [issue42988] [security] CVE-2021-3426: Information disclosure via
 pydoc -p: /getfile?key=path allows to read arbitrary file on the filesystem
In-Reply-To: <1611231517.86.0.296188996897.issue42988@roundup.psfhosted.org>
Message-ID: <1615402162.73.0.904607303579.issue42988@roundup.psfhosted.org>


Miro Hron?ok <miro at hroncok.cz> added the comment:

This is now CVE-2021-3426.

----------
title: [security] Information disclosure via pydoc -p: /getfile?key=path allows to read arbitrary file on the filesystem -> [security] CVE-2021-3426: Information disclosure via pydoc -p: /getfile?key=path allows to read arbitrary file on the filesystem

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42988>
_______________________________________

From report at bugs.python.org  Wed Mar 10 13:58:36 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Mar 2021 18:58:36 +0000
Subject: [issue42988] [security] CVE-2021-3426: Information disclosure via
 pydoc -p: /getfile?key=path allows to read arbitrary file on the filesystem
In-Reply-To: <1611231517.86.0.296188996897.issue42988@roundup.psfhosted.org>
Message-ID: <1615402716.67.0.477907564163.issue42988@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I created https://python-security.readthedocs.io/vuln/pydoc-getfile.html to track this vulnerability. The is no CVE section yet since the CVE is currently only *RESERVED*.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42988>
_______________________________________

From report at bugs.python.org  Wed Mar 10 14:00:59 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Mar 2021 19:00:59 +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: <1615402859.32.0.179843529388.issue43311@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 87f649a409da9d99682e78a55a83fc43225a8729 by Victor Stinner in branch 'master':
bpo-43311: Create GIL autoTSSkey ealier (GH-24819)
https://github.com/python/cpython/commit/87f649a409da9d99682e78a55a83fc43225a8729


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43311>
_______________________________________

From report at bugs.python.org  Wed Mar 10 14:01:44 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Mar 2021 19:01:44 +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: <1615402904.02.0.206137752201.issue43311@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thanks for your bug report junyixie, it should now be fixed. See bpo-40522 for the follow up.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43311>
_______________________________________

From report at bugs.python.org  Wed Mar 10 14:07:02 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Mar 2021 19:07:02 +0000
Subject: [issue42988] [security] CVE-2021-3426: Information disclosure via
 pydoc -p: /getfile?key=path allows to read arbitrary file on the filesystem
In-Reply-To: <1611231517.86.0.296188996897.issue42988@roundup.psfhosted.org>
Message-ID: <1615403222.52.0.0604828132146.issue42988@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Fedora downstream issue: https://bugzilla.redhat.com/show_bug.cgi?id=1937476

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42988>
_______________________________________

From report at bugs.python.org  Wed Mar 10 14:24:39 2021
From: report at bugs.python.org (Enji Cooper)
Date: Wed, 10 Mar 2021 19:24:39 +0000
Subject: [issue43465] ./configure --help describes what --with-ensurepip does
 poorly
Message-ID: <1615404279.31.0.681520070427.issue43465@roundup.psfhosted.org>


New submission from Enji Cooper <yaneurabeya at gmail.com>:

Many users are used to --without-* flags in autoconf disabling features (and optionally not installing them). --without-ensurepip (at face value to me) suggests it shouldn't be built/installed.

This comment in https://bugs.python.org/issue20417 by dstufft implies otherwise. From https://bugs.python.org/msg209537 :

> I don't see any reason not to install ensurepip in this situation. That flag controls whether or not ``python -m ensurepip`` will be executed during the install, but ensurepip itself will still be installed. It is not an optional module

This isn't what "./configure --help" implies though:

```
$ git log --oneline -n 1
87f649a409 (HEAD -> master, upstream/master, origin/master, origin/logging-config-dictconfig-support-more-sysloghandler-options, origin/HEAD, logging-config-dictconfig-support-more-sysloghandler-options) bpo-43311: Create GIL autoTSSkey ealier (GH-24819)
$ ./configure --help

...

  --with-ensurepip[=install|upgrade|no]
                          "install" or "upgrade" using bundled pip (default is
                          upgrade)
$
```

The wording should be clarified to note what the flag actually does instead of causing [valid] confusion to end-users which might make them think that the ensurepip module shouldn't be installed if --without-ensurepip is specified.

----------
components: Build
messages: 388456
nosy: ngie
priority: normal
severity: normal
status: open
title: ./configure --help describes what --with-ensurepip does poorly
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43465>
_______________________________________

From report at bugs.python.org  Wed Mar 10 14:29:47 2021
From: report at bugs.python.org (David Tucker)
Date: Wed, 10 Mar 2021 19:29:47 +0000
Subject: [issue43465] ./configure --help describes what --with-ensurepip does
 poorly
In-Reply-To: <1615404279.31.0.681520070427.issue43465@roundup.psfhosted.org>
Message-ID: <1615404587.74.0.947900889981.issue43465@roundup.psfhosted.org>


Change by David Tucker <david.tucker at dell.com>:


----------
nosy: +tucked

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43465>
_______________________________________

From report at bugs.python.org  Wed Mar 10 15:14:54 2021
From: report at bugs.python.org (Martin Panter)
Date: Wed, 10 Mar 2021 20:14:54 +0000
Subject: [issue43292] xml.ElementTree iterparse filehandle left open
In-Reply-To: <1613967089.4.0.392869817438.issue43292@roundup.psfhosted.org>
Message-ID: <1615407294.91.0.907618415862.issue43292@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

Perhaps this can be handled with Issue 25707, which is open for adding an API to close the file, similar to how "os.scandir" iterator implements a context manager and "close" method.

----------
nosy: +martin.panter
superseder:  -> Add the close method for ElementTree.iterparse() object

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43292>
_______________________________________

From report at bugs.python.org  Wed Mar 10 15:15:23 2021
From: report at bugs.python.org (Martin Panter)
Date: Wed, 10 Mar 2021 20:15:23 +0000
Subject: [issue43292] xml.ElementTree iterparse filehandle left open
In-Reply-To: <1613967089.4.0.392869817438.issue43292@roundup.psfhosted.org>
Message-ID: <1615407323.41.0.305459771675.issue43292@roundup.psfhosted.org>


Change by Martin Panter <vadmium+py at gmail.com>:


----------
type: security -> resource usage

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43292>
_______________________________________

From report at bugs.python.org  Wed Mar 10 15:59:31 2021
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 10 Mar 2021 20:59:31 +0000
Subject: [issue43456] Remove _xxsubinterpreters from sys.stdlib_module_names
In-Reply-To: <1615339499.12.0.300459298792.issue43456@roundup.psfhosted.org>
Message-ID: <1615409971.42.0.757971805756.issue43456@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Thanks, Victor! And I will independently say that my use of sys.stdlib_module_names suggests the list seems accurate(and is useful)!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43456>
_______________________________________

From report at bugs.python.org  Wed Mar 10 16:03:08 2021
From: report at bugs.python.org (David Wood)
Date: Wed, 10 Mar 2021 21:03:08 +0000
Subject: [issue43435] Py_BuildValue("y#".... returns incomplete result
In-Reply-To: <1615217493.05.0.795009945001.issue43435@roundup.psfhosted.org>
Message-ID: <1615410188.28.0.797689746976.issue43435@roundup.psfhosted.org>


David Wood <dwoodjunkmail at gmail.com> added the comment:

Christian/Eric -

Thank you both so much for taking time on this.  Christian had pointed out the use of memcpy vs strncpy.  It turns out that while strncpy is designed to copy a specific number of chars, it turns out that it stops on null.  I did make the change Christian suggested however, it turns out that strncpy was also used in the decrypt function which was also subject to the same problem.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43435>
_______________________________________

From report at bugs.python.org  Wed Mar 10 16:02:42 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Mar 2021 21:02:42 +0000
Subject: [issue43456] Remove _xxsubinterpreters from sys.stdlib_module_names
In-Reply-To: <1615339499.12.0.300459298792.issue43456@roundup.psfhosted.org>
Message-ID: <1615410162.0.0.293934444098.issue43456@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Thanks, Victor! And I will independently say that my use of sys.stdlib_module_names suggests the list seems accurate(and is useful)!

Well, it helps to define "what is the stdlib?" ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43456>
_______________________________________

From report at bugs.python.org  Wed Mar 10 16:08:19 2021
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 10 Mar 2021 21:08:19 +0000
Subject: [issue43435] Py_BuildValue("y#".... returns incomplete result
In-Reply-To: <1615217493.05.0.795009945001.issue43435@roundup.psfhosted.org>
Message-ID: <1615410499.1.0.00396801974533.issue43435@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Don't feel bad about it. Nintendo made a very similar mistake. The trucha bug made it trivial to bypass DRM of Wii games.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43435>
_______________________________________

From report at bugs.python.org  Wed Mar 10 16:59:01 2021
From: report at bugs.python.org (Frank)
Date: Wed, 10 Mar 2021 21:59:01 +0000
Subject: [issue43438] [doc] sys.addaudithook() documentation should be more
 explicit on its limitations
In-Reply-To: <1615235174.36.0.713670774369.issue43438@roundup.psfhosted.org>
Message-ID: <1615413541.96.0.606167746393.issue43438@roundup.psfhosted.org>


Frank <frankli0324 at hotmail.com> added the comment:

PEP 551 is confusing. It looked suggesting that it's a "security tool" that "detects, identifies and analyzes misuse of Python" to me (and apparently many others).

examples shown in the PEP includes WannaCrypt, APTs, all of which involves the good old remote code execution, which is basically a sandboxed environment it self, at least in some way.

also, the challenges provided the contestants with a "background story" that enables an attacker to execute arbitrary code doesn't mean that one HAVE to gain code execution to achieve the goal of bypassing the aevents. in this case, one only have to find the list object which contains the audit hooks registered, and clear it(or replace it). this clearly breaks the promise made in PEP 578 (Hooks cannot be removed or replaced). THIS SHOULD BE FIXED.

ALSO(again), the software is not always doing what it's designed to do. maybe, I mean maybe, developers should make changes according to what users are doing. I don't know, really.

----------
nosy: +frankli

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43438>
_______________________________________

From report at bugs.python.org  Wed Mar 10 18:14:03 2021
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 10 Mar 2021 23:14:03 +0000
Subject: [issue43466] ssl/hashlib: Add configure option to set or auto-detect
 rpath to OpenSSL libs
Message-ID: <1615418043.46.0.229114131093.issue43466@roundup.psfhosted.org>


New submission from Christian Heimes <lists at cheimes.de>:

Python's configure script has the option --with-openssl. It sets a path to a custom OpenSSL installation. Internally it provides OPENSSL_INCLUDES, OPENSSL_LIBS, and OPENSSL_LDFLAGS. The setup.py script turns the variables into include_dirs, library_dirs, and libraries arguments for _ssl and _hashlib extension modules.

However neither --with-openssl nor setup.py sets a custom runtime library path (rpath). This makes it confusing and hard for users to use a custom OpenSSL installation. They need to know that a) they have to take care of rpath on the first place, and b) how to set an rpath at compile or runtime. Without an rpath, the dynamic linker either fails to locate libssl/libcrypto or load system-provided shared libraries. Ticket bpo-34028 contains examples of user issues.

I propose to include a new option to make it easier for users to use a custom build of OpenSSL:

--with-openssl-rpath=<DIR|auto|no>

no (default): don't set an rpath
auto: auto-detect rpath from OPENSSL_LDFLAGS (--with-openssl or pkg-config)
DIR: set a custom rpath

The option will only affect the rpath of _ssl and _hashlib modules. The default value "no" is fully backwards compatible with 3.9 and earlier.

----------
assignee: christian.heimes
components: Installation, SSL
messages: 388463
nosy: barry, christian.heimes, gregory.p.smith, pablogsal
priority: normal
severity: normal
stage: patch review
status: open
title: ssl/hashlib: Add configure option to set or auto-detect rpath to OpenSSL libs
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43466>
_______________________________________

From report at bugs.python.org  Wed Mar 10 18:16:21 2021
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 10 Mar 2021 23:16:21 +0000
Subject: [issue43466] ssl/hashlib: Add configure option to set or auto-detect
 rpath to OpenSSL libs
In-Reply-To: <1615418043.46.0.229114131093.issue43466@roundup.psfhosted.org>
Message-ID: <1615418181.93.0.0746294522496.issue43466@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
keywords: +patch
pull_requests: +23586
pull_request: https://github.com/python/cpython/pull/24820

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43466>
_______________________________________

From report at bugs.python.org  Wed Mar 10 18:31:00 2021
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 10 Mar 2021 23:31:00 +0000
Subject: [issue38671] pathlib.Path.resolve(strict=False) returns relative path
 on Windows if the entry does not exist
In-Reply-To: <1572774931.11.0.993470333259.issue38671@roundup.psfhosted.org>
Message-ID: <1615419060.24.0.870865737362.issue38671@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
type:  -> behavior
versions: +Python 3.10, Python 3.9 -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38671>
_______________________________________

From report at bugs.python.org  Wed Mar 10 18:34:21 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 10 Mar 2021 23:34:21 +0000
Subject: [issue43466] ssl/hashlib: Add configure option to set or auto-detect
 rpath to OpenSSL libs
In-Reply-To: <1615418043.46.0.229114131093.issue43466@roundup.psfhosted.org>
Message-ID: <1615419261.03.0.967571017588.issue43466@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I have a suggestion (I am ok with also doing both). We should add also a flag that allows to statically compile openssl into the extension modules (if the .a are available) so there will be no shared object dependency. This allows us to have artifacts that are more self contained (regarding OpenSSL), partially eliminating the problem.

We could also go a step ahead and also hide the OpenSSL symbols from the dynamic table, so they don't collide if another shared object is already loaded in the future.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43466>
_______________________________________

From report at bugs.python.org  Wed Mar 10 18:42:15 2021
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 10 Mar 2021 23:42:15 +0000
Subject: [issue43466] ssl/hashlib: Add configure option to set or auto-detect
 rpath to OpenSSL libs
In-Reply-To: <1615418043.46.0.229114131093.issue43466@roundup.psfhosted.org>
Message-ID: <1615419735.99.0.728752198341.issue43466@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

$ tar -xzf openssl-1.1.1j.tar.gz
$ pushd openssl-1.1.1j
$ ./config \
    --prefix=/home/heimes/dev/python/custom-openssl \
    --openssldir=\
        $(find /etc/ -name openssl.cnf -quit -printf "%h" 2>/dev/null)
$ make
$ make install_sw
$ popd

$ pushd cpython
$ ./configure \
    --with-openssl=/home/heimes/dev/python/custom-openssl \
    --with-openssl-rpath=auto
$ make
$ ldd build/lib.linux-x86_64-3.10/_ssl.cpython-310-x86_64-linux-gnu.so 
        linux-vdso.so.1 (0x00007ffde07bc000)
        libssl.so.1.1 => /home/heimes/dev/python/custom-openssl/lib/libssl.so.1.1 (0x00007f937493a000)
        libcrypto.so.1.1 => /home/heimes/dev/python/custom-openssl/lib/libcrypto.so.1.1 (0x00007f937465a000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f9374608000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f937443d000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f9374436000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f93749ff000)
$ ./python
>>> import ssl
>>> ssl.OPENSSL_VERSION
'OpenSSL 1.1.1j  16 Feb 2021'
>>> import urllib.request
>>> r = urllib.request.urlopen("https://www.python.org")
                                   ^^^ No cert validation error!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43466>
_______________________________________

From report at bugs.python.org  Wed Mar 10 18:50:18 2021
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 10 Mar 2021 23:50:18 +0000
Subject: [issue43466] ssl/hashlib: Add configure option to set or auto-detect
 rpath to OpenSSL libs
In-Reply-To: <1615418043.46.0.229114131093.issue43466@roundup.psfhosted.org>
Message-ID: <1615420218.22.0.762013592975.issue43466@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

I would rather not support static linking.

OpenSSL uses dynamic linking by default. Static linking is problematic for dynamic engine support. This is going to become an even bigger issue with OSSL providers in OpenSSL 3.0.0. I don't know yet how well OpenSSL 3.0.0 will support static linking.

Our macOS and Windows builds are now dynamically linked, too. At least Windows builds used to be statically linked.

Dynamic linked OpenSSL has a major benefit: It allows users to update OpenSSL without re-compiling Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43466>
_______________________________________

From report at bugs.python.org  Wed Mar 10 18:55:53 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 10 Mar 2021 23:55:53 +0000
Subject: [issue43466] ssl/hashlib: Add configure option to set or auto-detect
 rpath to OpenSSL libs
In-Reply-To: <1615418043.46.0.229114131093.issue43466@roundup.psfhosted.org>
Message-ID: <1615420553.37.0.557366247649.issue43466@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> OpenSSL uses dynamic linking by default.

As long as OpenSSL provide a .a file (they do) you can always static link. That is a decision of how you integrate the library.

>  Static linking is problematic for dynamic engine support.

Not sure I follow. What's the problem here? The advantage of static linking here will be to not have a dependency on the shared object, which can be quite beneficial.


> Dynamic linked OpenSSL has a major benefit: It allows users to update OpenSSL without re-compiling Python.

Yeah, I agree. That's what should always be the default. But there are still advantages regarding static linking.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43466>
_______________________________________

From report at bugs.python.org  Wed Mar 10 18:56:46 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 10 Mar 2021 23:56:46 +0000
Subject: [issue43466] ssl/hashlib: Add configure option to set or auto-detect
 rpath to OpenSSL libs
In-Reply-To: <1615418043.46.0.229114131093.issue43466@roundup.psfhosted.org>
Message-ID: <1615420606.65.0.204538788071.issue43466@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Note that I am not proposing to statically link the extensions into the core, I am proposing to statically link openssl into the extensions, so the symbols are in the text segment of the extension.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43466>
_______________________________________

From report at bugs.python.org  Wed Mar 10 18:57:39 2021
From: report at bugs.python.org (David E. Franco G.)
Date: Wed, 10 Mar 2021 23:57:39 +0000
Subject: [issue43467] IDLE: horizontal scrollbar
Message-ID: <1615420659.08.0.218297544111.issue43467@roundup.psfhosted.org>


New submission from David E. Franco G. <david.elsensei3 at gmail.com>:

I noticed that the horizontal scroll bar is missing, I think it was present in previous version, regardless it would be nice if its be present.

Thanks.

----------
assignee: terry.reedy
components: IDLE
files: no scroll bar.PNG
messages: 388469
nosy: David E. Franco G., terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: horizontal scrollbar
type: enhancement
versions: Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49865/no scroll bar.PNG

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43467>
_______________________________________

From report at bugs.python.org  Wed Mar 10 19:07:10 2021
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 11 Mar 2021 00:07:10 +0000
Subject: [issue43466] ssl/hashlib: Add configure option to set or auto-detect
 rpath to OpenSSL libs
In-Reply-To: <1615418043.46.0.229114131093.issue43466@roundup.psfhosted.org>
Message-ID: <1615421230.62.0.934706311609.issue43466@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

> Not sure I follow. What's the problem here? The advantage of static linking here will be to not have a dependency on the shared object, which can be quite beneficial.

The problem is that some features are not baked into the .a files. They are always provided as shared libraries. This included OpenSSL engine extensions such as AFALG engine or external engines like p11-kit, OpenSC, or others. OpenSSL 3.0.0 moves some features into external OSSL provider libraries, for example legacy crypto algorithms. I have not figured out how much functionality we woud loose without engines and external OSSL providers. https://www.openssl.org/docs/manmaster/man3/OSSL_PROVIDER.html
# 3.0.0 alpha build:
$ find -name '*.so'
./engines-3/padlock.so
./engines-3/capi.so
./engines-3/afalg.so
./ossl-modules/fips.so
./ossl-modules/legacy.so
./libssl.so
./libcrypto.so

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43466>
_______________________________________

From report at bugs.python.org  Wed Mar 10 19:15:03 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 11 Mar 2021 00:15:03 +0000
Subject: [issue43466] ssl/hashlib: Add configure option to set or auto-detect
 rpath to OpenSSL libs
In-Reply-To: <1615418043.46.0.229114131093.issue43466@roundup.psfhosted.org>
Message-ID: <1615421703.11.0.572821647647.issue43466@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> The problem is that some features are not baked into the .a files. 

Oh, I see. So when using modern versions of openssl what shared objects do we expect to be in the NEEDED section? Right now, I see this in python3.8 in Ubuntu with OpenSSL 1.1.1:

? ldd /usr/lib/python3.8/lib-dynload/_ssl.cpython-38-x86_64-linux-gnu.so
        linux-vdso.so.1 (0x00007ffcf71ef000)
        libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007fe8782b6000)
        libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007fe877deb000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe877bcc000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe8777db000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe8775d7000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fe87876e000)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43466>
_______________________________________

From report at bugs.python.org  Wed Mar 10 19:36:32 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Thu, 11 Mar 2021 00:36:32 +0000
Subject: [issue43454] [sqlite3] Add support for R*Tree callbacks
In-Reply-To: <1615326865.81.0.691983788342.issue43454@roundup.psfhosted.org>
Message-ID: <1615422992.66.0.374481802919.issue43454@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

FYI, PoC patch attached. Lacks tests and some #ifdefs. Let me know if I should create a PR out of it.

----------
keywords: +patch
Added file: https://bugs.python.org/file49866/patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43454>
_______________________________________

From report at bugs.python.org  Wed Mar 10 19:37:47 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Thu, 11 Mar 2021 00:37:47 +0000
Subject: [issue43454] [sqlite3] Add support for R*Tree callbacks
In-Reply-To: <1615326865.81.0.691983788342.issue43454@roundup.psfhosted.org>
Message-ID: <1615423067.58.0.456123619821.issue43454@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

Test run output (see attached test file):

$ ./python.exe test_rtree.py
ARGS: ((-80.77490234375, -80.77469635009766, 35.377593994140625, 35.377803802490234), (45.3, 22.9, 5.0))
KWARGS: {'num_queued': [0, 1], 'context': None, 'level': 0, 'max_level': 1, 'rowid': 1, 'parent_score': 0.0, 'parent_visibility': 1}
ARGS: ((-81.0, -79.5999984741211, 35.0, 36.20000076293945), (45.3, 22.9, 5.0))
KWARGS: {'num_queued': [1, 1], 'context': ['stuff'], 'level': 0, 'max_level': 1, 'rowid': 2, 'parent_score': 0.0, 'parent_visibility': 1}

----------
Added file: https://bugs.python.org/file49867/test_rtree.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43454>
_______________________________________

From report at bugs.python.org  Wed Mar 10 21:27:09 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 11 Mar 2021 02:27:09 +0000
Subject: [issue43467] IDLE: horizontal scrollbar
In-Reply-To: <1615420659.08.0.218297544111.issue43467@roundup.psfhosted.org>
Message-ID: <1615429629.54.0.996214047437.issue43467@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

FWIW, I think IDLE is better-off without a horizontal scroll bar.

For teaching purposes, it's valuable to a screen that focuses on content and is devoid of clutter.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43467>
_______________________________________

From report at bugs.python.org  Wed Mar 10 21:49:58 2021
From: report at bugs.python.org (David E. Franco G.)
Date: Thu, 11 Mar 2021 02:49:58 +0000
Subject: [issue43467] IDLE: horizontal scrollbar
In-Reply-To: <1615420659.08.0.218297544111.issue43467@roundup.psfhosted.org>
Message-ID: <1615430998.23.0.315941860617.issue43467@roundup.psfhosted.org>


David E. Franco G. <david.elsensei3 at gmail.com> added the comment:

How is that clutter?
Even the most basic text editor (window notepad) have it, and knowing that yours or whoever code you are looking at extend horizontally beyond the size of your current windows size is a relevant information.

----------
Added file: https://bugs.python.org/file49868/scroll bar notepd.PNG

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43467>
_______________________________________

From report at bugs.python.org  Wed Mar 10 22:16:07 2021
From: report at bugs.python.org (Saiyang Gou)
Date: Thu, 11 Mar 2021 03:16:07 +0000
Subject: [issue43438] [doc] sys.addaudithook() documentation should be more
 explicit on its limitations
In-Reply-To: <1615235174.36.0.713670774369.issue43438@roundup.psfhosted.org>
Message-ID: <1615432567.4.0.527761650737.issue43438@roundup.psfhosted.org>


Saiyang Gou <gousaiyang223 at gmail.com> added the comment:

We understand that audit hooks should not be used to build a sandbox with Python. It is natural for audit hooks to appear in CTF challenges though, as many CTF challenges intentionally try to use a wrong way to secure a system (and let players prove it wrong).

With that being said, audit hooks should still be robust, even for logging purposes. We are no trying to prevent all kinds of malicious behaviors, but we want to detect them *as much as possible*. If audit hooks can be easily removed while triggering very few seemingly non-sensitive audit events (in this CTF challenge, only "import gc" is triggered, which probably looks "no so suspicious"), this allows attackers to hide details of further malicious behavior without being audited, which violated the motivation of audit hooks (to increase security transparency).

The recent gc patch introduced new events which will make the attack in that CTF challenge look more suspicious. But probably it is still better to harden the current data structure used to store per interpreter audit hooks. If an attacker happens to gain a reference to the list holding the hooks (although I'm not sure how that will still be possible without using `gc`), they can easily remove the hooks at the Python language level. Probably a Python tuple is already better than a Python list to store the hooks, since tuples are immutable at the language level. Although that means we should build new a tuple each time a new hook is added.

If the hook itself is fragile (e.g. a hook written in Python which relies on global variables), it is a user fault. But if the hook function itself is good, it shouldn't be too easy to remove. Any successful attempts to remove the hook must have already "pwned" the Python interpreter (i.e. gained arbitrary memory read/write or native code execution ability), either by using ctypes, by open('/proc/self/mem'), by crafting bytecode (which triggers code.__new__) or importing modules written in native code. (Overwriting hook.__code__ triggers object.__setattr__.)

----------
nosy: +gousaiyang

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43438>
_______________________________________

From report at bugs.python.org  Wed Mar 10 22:55:58 2021
From: report at bugs.python.org (Tim Peters)
Date: Thu, 11 Mar 2021 03:55:58 +0000
Subject: [issue43420] Optimize rational arithmetics
In-Reply-To: <1615040297.73.0.541090358152.issue43420@roundup.psfhosted.org>
Message-ID: <1615434958.5.0.97897632356.issue43420@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Issue 21922 lists several concerns, and best I know they all still apply. As a practical matter, I expect the vast bulk of core Python developers would reject a change that sped large int basic arithmetic by a factor of a billion if it slowed down basic arithmetic on native machine-size ints by even half a percent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43420>
_______________________________________

From report at bugs.python.org  Thu Mar 11 01:21:28 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 11 Mar 2021 06:21:28 +0000
Subject: [issue43467] IDLE: horizontal scrollbar
In-Reply-To: <1615420659.08.0.218297544111.issue43467@roundup.psfhosted.org>
Message-ID: <1615443688.88.0.292102178793.issue43467@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This has been debated for 15 years see #1207613.  The current patch, which only displays a scrollbar when needed, 'works', but in a way that is not visually acceptable.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Idle Editor: Bottom Scroll Bar

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43467>
_______________________________________

From report at bugs.python.org  Thu Mar 11 01:23:00 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 11 Mar 2021 06:23:00 +0000
Subject: [issue1207613] Idle Editor: Bottom Scroll Bar
Message-ID: <1615443780.65.0.319569513478.issue1207613@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Request in #43467 closed as duplicate of this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1207613>
_______________________________________

From report at bugs.python.org  Thu Mar 11 01:34:07 2021
From: report at bugs.python.org (=?utf-8?q?Lum=C3=ADr_Balhar?=)
Date: Thu, 11 Mar 2021 06:34:07 +0000
Subject: [issue42988] [security] CVE-2021-3426: Information disclosure via
 pydoc -p: /getfile?key=path allows to read arbitrary file on the filesystem
In-Reply-To: <1611231517.86.0.296188996897.issue42988@roundup.psfhosted.org>
Message-ID: <1615444447.59.0.263651975267.issue42988@roundup.psfhosted.org>


Change by Lum?r Balhar <frenzy.madness at gmail.com>:


----------
nosy: +frenzy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42988>
_______________________________________

From report at bugs.python.org  Thu Mar 11 01:37:47 2021
From: report at bugs.python.org (Antti Haapala)
Date: Thu, 11 Mar 2021 06:37:47 +0000
Subject: [issue43468] functools.cached_property locking is plain wrong.
Message-ID: <1615444667.91.0.948817723419.issue43468@roundup.psfhosted.org>


New submission from Antti Haapala <antti at haapala.name>:

The locking on functools.cached_property (https://github.com/python/cpython/blob/87f649a409da9d99682e78a55a83fc43225a8729/Lib/functools.py#L934) as it was written is completely undesirable for I/O bound values, parallel processing. Instead of protecting the calculation of cached property to the same instance in two threads, it completely blocks parallel calculations of cached values to *distinct instances* of the same class. 

Here's the code of __get__ in cached_property:

    def __get__(self, instance, owner=None):
        if instance is None:
            return self
        if self.attrname is None:
            raise TypeError(
                "Cannot use cached_property instance without calling __set_name__ on it.")
        try:
            cache = instance.__dict__
        except AttributeError:  # not all objects have __dict__ (e.g. class defines slots)
            msg = (
                f"No '__dict__' attribute on {type(instance).__name__!r} "
                f"instance to cache {self.attrname!r} property."
            )
            raise TypeError(msg) from None
        val = cache.get(self.attrname, _NOT_FOUND)
        if val is _NOT_FOUND:
            with self.lock:
                # check if another thread filled cache while we awaited lock
                val = cache.get(self.attrname, _NOT_FOUND)
                if val is _NOT_FOUND:
                    val = self.func(instance)
                    try:
                        cache[self.attrname] = val
                    except TypeError:
                        msg = (
                            f"The '__dict__' attribute on {type(instance).__name__!r} instance "
                            f"does not support item assignment for caching {self.attrname!r} property."
                        )
                        raise TypeError(msg) from None
        return val


I noticed this because I was recommending that Pyramid web framework deprecate its much simpler [`reify`](https://docs.pylonsproject.org/projects/pyramid/en/latest/_modules/pyramid/decorator.html#reify) decorator in favour of using `cached_property`, and then noticed why it won't do.


Here is the test case for cached_property:

from functools import cached_property
from threading import Thread
from random import randint
import time



class Spam:
    @cached_property
    def ham(self):
        print(f'Calculating amount of ham in {self}')
        time.sleep(10)
        return randint(0, 100)


def bacon():
    spam = Spam()
    print(f'The amount of ham in {spam} is {spam.ham}')


start = time.time()
threads = []
for _ in range(3):
    t = Thread(target=bacon)
    threads.append(t)
    t.start()

for t in threads:
    t.join()

print(f'Total running time was {time.time() - start}')


Calculating amount of ham in <__main__.Spam object at 0x7fa50bcaa220>
The amount of ham in <__main__.Spam object at 0x7fa50bcaa220> is 97
Calculating amount of ham in <__main__.Spam object at 0x7fa50bcaa4f0>
The amount of ham in <__main__.Spam object at 0x7fa50bcaa4f0> is 8
Calculating amount of ham in <__main__.Spam object at 0x7fa50bcaa7c0>
The amount of ham in <__main__.Spam object at 0x7fa50bcaa7c0> is 53
Total running time was 30.02147102355957


The runtime is 30 seconds; for `pyramid.decorator.reify` the runtime would be 10 seconds:

Calculating amount of ham in <__main__.Spam object at 0x7fc4d8272430>
Calculating amount of ham in <__main__.Spam object at 0x7fc4d82726d0>
Calculating amount of ham in <__main__.Spam object at 0x7fc4d8272970>
The amount of ham in <__main__.Spam object at 0x7fc4d82726d0> is 94
The amount of ham in <__main__.Spam object at 0x7fc4d8272970> is 29
The amount of ham in <__main__.Spam object at 0x7fc4d8272430> is 93
Total running time was 10.010624170303345

`reify` in Pyramid is used heavily to add properties to incoming HTTP request objects - using `functools.cached_property` instead would mean that each independent request thread blocks others because most of them would always get the value for the same lazy property using the the same descriptor instance and locking the same lock.

----------
components: Library (Lib)
messages: 388480
nosy: ztane
priority: normal
severity: normal
status: open
title: functools.cached_property locking is plain wrong.
type: resource usage
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43468>
_______________________________________

From report at bugs.python.org  Thu Mar 11 01:59:10 2021
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 11 Mar 2021 06:59:10 +0000
Subject: [issue43468] functools.cached_property locking is plain wrong.
In-Reply-To: <1615444667.91.0.948817723419.issue43468@roundup.psfhosted.org>
Message-ID: <1615445950.69.0.978715277353.issue43468@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/issue43468>
_______________________________________

From report at bugs.python.org  Thu Mar 11 02:17:30 2021
From: report at bugs.python.org (Xinmeng Xia)
Date: Thu, 11 Mar 2021 07:17:30 +0000
Subject: [issue43469] Python 3.6 fails to run on MacOS (Big Sur 11.2.3)
Message-ID: <1615447050.11.0.0564734952656.issue43469@roundup.psfhosted.org>


New submission from Xinmeng Xia <xiaxm at smail.nju.edu.cn>:

Python 3.6 can work well on old version of MacOS. When I upgrade MacOS to the latest version Big Sur 11.2.3. Python 3.6 fails to start and crashes. Python 3.7, 3.8, 3.9 can perform well on the new version MacOS Big Sur 11.2.3. The crash information attached as follows:

Crash information
==============================================================
>>python3.6
dyld: Library not loaded: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
  Referenced from: /Library/Frameworks/Python.framework/Versions/3.6/Resources/Python.app/Contents/MacOS/Python
  Reason: image not found
Abort trap: 6
==============================================================

----------
components: macOS
messages: 388481
nosy: ned.deily, ronaldoussoren, xxm
priority: normal
severity: normal
status: open
title: Python 3.6 fails to run on MacOS (Big Sur 11.2.3)
type: crash
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43469>
_______________________________________

From report at bugs.python.org  Thu Mar 11 02:18:38 2021
From: report at bugs.python.org (Xinmeng Xia)
Date: Thu, 11 Mar 2021 07:18:38 +0000
Subject: [issue43470] Installation of Python 3.6.13 fails on MacOS Big Sur
 11.2.3
Message-ID: <1615447118.51.0.748339501359.issue43470@roundup.psfhosted.org>


New submission from Xinmeng Xia <xiaxm at smail.nju.edu.cn>:

Installation of latest Python 3.6.13 fails on MacOS Big Sur 11.2.3. The source code is downloaded from python.org. Then we try to install it by commands "./configure;sudo make;sudo make install". However the installation  crashes.

The installation succeeds on Ubuntu.

Crash information:
==========================================================
>>./configure
>>sudo make
gcc -c -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall    -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Wstrict-prototypes   -I. -I./Include    -DPy_BUILD_CORE -o Programs/python.o ./Programs/python.c
.....
t -Wno-unused-parameter -Wno-missing-field-initializers -Wstrict-prototypes   -I. -I./Include    -DPy_BUILD_CORE  -c ./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c:8210:15: error: implicit declaration of function 'sendfile' is invalid in C99
      [-Werror,-Wimplicit-function-declaration]
        ret = sendfile(in, out, offset, &sbytes, &sf, flags);
              ^
./Modules/posixmodule.c:10432:5: warning: code will never be executed [-Wunreachable-code]
    Py_FatalError("abort() called from Python code didn't abort!");
    ^~~~~~~~~~~~~
1 warning and 1 error generated.
make: *** [Modules/posixmodule.o] Error 1
============================================================

----------
components: Installation
messages: 388482
nosy: xxm
priority: normal
severity: normal
status: open
title: Installation of Python 3.6.13 fails on MacOS Big Sur 11.2.3
type: crash
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43470>
_______________________________________

From report at bugs.python.org  Thu Mar 11 02:20:37 2021
From: report at bugs.python.org (Xinmeng Xia)
Date: Thu, 11 Mar 2021 07:20:37 +0000
Subject: [issue43471] Fails to import bz2 on Ubuntu
Message-ID: <1615447237.87.0.642854040325.issue43471@roundup.psfhosted.org>


New submission from Xinmeng Xia <xiaxm at smail.nju.edu.cn>:

Module bz2 fails to be imported on Ubuntu due to lack of '_bz2'.  We try "import bz2" on Mac, it can work well.

Errors on Ubuntu
==========================================
>>import bz2
Traceback (most recent call last):
      File "/home/xxm/Desktop/apifuzz/doc/genDoc.py", line 97, in <module>
           exec(compile(mstr,'','exec'))
      File "", line 1, in <module>
           File "/home/xxm/Desktop/apifuzz/Python-3.9.2/Lib/bz2.py", line 18, in <module>
                from _bz2 import BZ2Compressor, BZ2Decompressor
ModuleNotFoundError: No module named '_bz2'
===========================================

Python version: 3.9.2
Python installation: (1). download source code from python.org, (2). run command "./configure; sudo make; sudo make install.

We install the same Python 3.9.2 in a same way on Mac and Ubuntu.

----------
components: Library (Lib)
messages: 388483
nosy: xxm
priority: normal
severity: normal
status: open
title: Fails to import bz2 on Ubuntu
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43471>
_______________________________________

From report at bugs.python.org  Thu Mar 11 02:36:23 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 11 Mar 2021 07:36:23 +0000
Subject: [issue43471] Fails to import bz2 on Ubuntu
In-Reply-To: <1615447237.87.0.642854040325.issue43471@roundup.psfhosted.org>
Message-ID: <1615448183.73.0.395551555638.issue43471@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

You're probably missing needed dependencies. For example, see https://stackoverflow.com/questions/12806122/missing-python-bz2-module

If you look at the output of make, you should be able to see that _bz2 wasn't built.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43471>
_______________________________________

From report at bugs.python.org  Thu Mar 11 03:21:25 2021
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 11 Mar 2021 08:21:25 +0000
Subject: [issue43452] Microoptimize PyType_Lookup for cache hits
In-Reply-To: <1615317677.24.0.232039554227.issue43452@roundup.psfhosted.org>
Message-ID: <1615450885.45.0.410634257109.issue43452@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

$ ./python -m pyperf compare_to -G --min-speed=3 master.json pytype.json
Slower (1):
- unpack_sequence: 62.2 ns +- 0.6 ns -> 66.1 ns +- 0.9 ns: 1.06x slower

Faster (29):
- nbody: 182 ms +- 1 ms -> 152 ms +- 2 ms: 1.19x faster
- regex_effbot: 4.00 ms +- 0.05 ms -> 3.45 ms +- 0.08 ms: 1.16x faster
- spectral_norm: 178 ms +- 1 ms -> 158 ms +- 2 ms: 1.13x faster
- crypto_pyaes: 140 ms +- 1 ms -> 125 ms +- 1 ms: 1.12x faster
- dulwich_log: 88.0 ms +- 11.8 ms -> 80.1 ms +- 0.5 ms: 1.10x faster
- scimark_fft: 522 ms +- 4 ms -> 477 ms +- 14 ms: 1.09x faster
- mako: 18.2 ms +- 0.1 ms -> 16.7 ms +- 0.1 ms: 1.09x faster
- raytrace: 542 ms +- 4 ms -> 497 ms +- 3 ms: 1.09x faster
- regex_dna: 251 ms +- 1 ms -> 230 ms +- 1 ms: 1.09x faster
- regex_v8: 29.6 ms +- 0.2 ms -> 27.2 ms +- 0.1 ms: 1.09x faster
- pidigits: 227 ms +- 0 ms -> 210 ms +- 0 ms: 1.08x faster
- fannkuch: 564 ms +- 7 ms -> 525 ms +- 4 ms: 1.08x faster
- telco: 7.70 ms +- 0.12 ms -> 7.17 ms +- 0.18 ms: 1.07x faster
- float: 130 ms +- 1 ms -> 122 ms +- 1 ms: 1.07x faster
- unpickle_pure_python: 350 us +- 4 us -> 327 us +- 3 us: 1.07x faster
- scimark_sparse_mat_mult: 6.86 ms +- 0.08 ms -> 6.47 ms +- 0.07 ms: 1.06x faster
- chaos: 122 ms +- 1 ms -> 115 ms +- 1 ms: 1.06x faster
- nqueens: 113 ms +- 1 ms -> 107 ms +- 1 ms: 1.06x faster
- json_dumps: 15.4 ms +- 0.1 ms -> 14.7 ms +- 0.1 ms: 1.05x faster
- pickle_pure_python: 505 us +- 6 us -> 480 us +- 5 us: 1.05x faster
- logging_simple: 9.88 us +- 0.17 us -> 9.40 us +- 0.18 us: 1.05x faster
- deltablue: 8.19 ms +- 0.13 ms -> 7.79 ms +- 0.15 ms: 1.05x faster
- scimark_lu: 190 ms +- 3 ms -> 182 ms +- 5 ms: 1.05x faster
- scimark_monte_carlo: 125 ms +- 2 ms -> 120 ms +- 2 ms: 1.05x faster
- pickle: 11.3 us +- 0.2 us -> 10.8 us +- 0.1 us: 1.05x faster
- logging_silent: 189 ns +- 4 ns -> 182 ns +- 4 ns: 1.04x faster
- pickle_dict: 31.7 us +- 0.2 us -> 30.5 us +- 0.1 us: 1.04x faster
- django_template: 51.6 ms +- 0.7 ms -> 49.8 ms +- 0.6 ms: 1.04x faster
- pyflate: 755 ms +- 7 ms -> 730 ms +- 7 ms: 1.03x faster

Benchmark hidden because not significant (30): 2to3, chameleon, genshi_text, genshi_xml, go, hexiom, json_loads, logging_format, meteor_contest, pathlib, pickle_list, python_startup, python_startup_no_site, regex_compile, richards, scimark_sor, sqlalchemy_declarative, sqlalchemy_imperative, sqlite_synth, sympy_expand, sympy_integrate, sympy_sum, sympy_str, tornado_http, unpickle, unpickle_list, xml_etree_parse, xml_etree_iterparse, xml_etree_generate, xml_etree_process

Geometric mean: 1.04x faster

----------
nosy: +methane

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43452>
_______________________________________

From report at bugs.python.org  Thu Mar 11 03:24:52 2021
From: report at bugs.python.org (Petr Viktorin)
Date: Thu, 11 Mar 2021 08:24:52 +0000
Subject: [issue42967] [CVE-2021-23336] urllib.parse.parse_qsl(): Web cache
 poisoning - `; ` as a query args separator
In-Reply-To: <1611068809.96.0.58823274544.issue42967@roundup.psfhosted.org>
Message-ID: <1615451092.4.0.673221600037.issue42967@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

There's another part of the new implementation that looks a bit fishy: the `separator` argument now allows multi-character strings, so you can parse 'a=1<SPLIT>b=2' with separator='<SPLIT>'.
Was this intentional?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42967>
_______________________________________

From report at bugs.python.org  Thu Mar 11 03:42:56 2021
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 11 Mar 2021 08:42:56 +0000
Subject: [issue43466] ssl/hashlib: Add configure option to set or auto-detect
 rpath to OpenSSL libs
In-Reply-To: <1615418043.46.0.229114131093.issue43466@roundup.psfhosted.org>
Message-ID: <1615452176.38.0.705522872461.issue43466@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

It's very much the same for OpenSSL 3.0.0: libssl.so and libcrypto.so.

$ ldd build/lib.linux-x86_64-3.10/_ssl.cpython-310-x86_64-linux-gnu.so 
        linux-vdso.so.1 (0x00007ffffa3cc000)
        libssl.so.3 => /home/heimes/dev/python/multissl/openssl/3.0.0-alpha12/lib/libssl.so.3 (0x00007f1ab0b66000)
        libcrypto.so.3 => /home/heimes/dev/python/multissl/openssl/3.0.0-alpha12/lib/libcrypto.so.3 (0x00007f1ab06b1000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f1ab065f000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f1ab0494000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f1ab048d000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f1ab0c55000)


The external engines and OSSL providers are external plugins. They are very much akin to Python's extension modules. OpenSSL loads them with dlopen(), dlsym()s an init function and finally calls the init function. It uses either RTLD_NOW or RTLD_NOW | RTLD_GLOBAL dlopen() flags.

The engines and OSSL providers depend on libcrypto.so. AFAIK this won't play will with static linking.

$ ldd ../multissl/openssl/3.0.0-alpha12/lib/engines-3/afalg.so 
        linux-vdso.so.1 (0x00007fffa417d000)
        libcrypto.so.3 => /home/heimes/dev/python/multissl/openssl/3.0.0-alpha12/lib/libcrypto.so.3 (0x00007fbcb3c75000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fbcb3c3e000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fbcb3c1c000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fbcb3a51000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fbcb4133000)

$ ldd ../multissl/openssl/3.0.0-alpha12/lib/ossl-modules/legacy.so 
        linux-vdso.so.1 (0x00007ffd3ccc0000)
        libcrypto.so.3 => /home/heimes/dev/python/multissl/openssl/3.0.0-alpha12/lib/libcrypto.so.3 (0x00007f5524f36000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f5524eff000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f5524edd000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f5524d12000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f5525419000)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43466>
_______________________________________

From report at bugs.python.org  Thu Mar 11 04:13:43 2021
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 11 Mar 2021 09:13:43 +0000
Subject: [issue43470] Installation of Python 3.6.13 fails on MacOS Big Sur
 11.2.3
In-Reply-To: <1615447118.51.0.748339501359.issue43470@roundup.psfhosted.org>
Message-ID: <1615454023.83.0.167001412123.issue43470@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
components: +macOS
nosy: +ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43470>
_______________________________________

From report at bugs.python.org  Thu Mar 11 04:19:51 2021
From: report at bugs.python.org (=?utf-8?q?Ram=C3=B3n_Fraterman?=)
Date: Thu, 11 Mar 2021 09:19:51 +0000
Subject: [issue42991] support for splitting multichannel audio fragments in
 audioop module
In-Reply-To: <1611258214.16.0.1675342268.issue42991@roundup.psfhosted.org>
Message-ID: <1615454391.97.0.197713105686.issue42991@roundup.psfhosted.org>


Ram?n Fraterman <ramonfraterman at gmail.com> added the comment:

Could someone please have a look at my PR?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42991>
_______________________________________

From report at bugs.python.org  Thu Mar 11 04:31:02 2021
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 11 Mar 2021 09:31:02 +0000
Subject: [issue43472] [security][subinterpreters] Add auditing hooks to
 subinterpreter module
Message-ID: <1615455062.58.0.468186541544.issue43472@roundup.psfhosted.org>


New submission from Christian Heimes <lists at cheimes.de>:

The subinterpreters module does not emit any audit events yet. It's possible to create a subinterpreter and run arbitrary code through run_string().

We should also improve documentation of sys.addaudithook() and explain what 'current interpreter' actually means. I guess most users don't realize the consequences for subinterpreters.

$ ./python auditsub.py
('os.system', (b'echo main interpreter',))
main interpreter
you got pwned
[heimes at seneca cpython]$ cat au
auditsub.py     autom4te.cache/ 
[heimes at seneca cpython]$ cat auditsub.py 
import sys
import _xxsubinterpreters

def hook(*args):
    print(args)

sys.addaudithook(hook)

import os
os.system('echo main interpreter')

sub = _xxsubinterpreters.create()
_xxsubinterpreters.run_string(sub, "import os; os.system('echo you got pwned')", None)

$ ./python auditsub.py 
('os.system', (b'echo main interpreter',))
main interpreter
you got pwned

----------
components: Interpreter Core, Subinterpreters
messages: 388489
nosy: christian.heimes, eric.snow, steve.dower
priority: normal
severity: normal
status: open
title: [security][subinterpreters] Add auditing hooks to subinterpreter module
type: security
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43472>
_______________________________________

From report at bugs.python.org  Thu Mar 11 04:31:26 2021
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 11 Mar 2021 09:31:26 +0000
Subject: [issue43438] [doc] sys.addaudithook() documentation should be more
 explicit on its limitations
In-Reply-To: <1615235174.36.0.713670774369.issue43438@roundup.psfhosted.org>
Message-ID: <1615455086.83.0.658258801325.issue43438@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Python's dynamic nature makes it hard to implement and reason about audit hooks written in Python. sys.addaudithook() is really only design for testing, debugging, and playing around with auditing. You absolutely have to write a custom interpreter if you want to take auditing serious.

Please also keep in mind that sys.addaudithook() does **not** add a global hook. The function adds a per-interpreter hook. It just looks global to most people because a process typically has just one interpreter. I have filed bpo-43472 to track the issue.

$ cat auditsub.py 
import sys
import _xxsubinterpreters

def hook(*args):
    print(args)

sys.addaudithook(hook)

import os
os.system('echo main interpreter')

sub = _xxsubinterpreters.create()
_xxsubinterpreters.run_string(sub, "import os; os.system('echo you got pwned')", None)

$ ./python auditsub.py 
('os.system', (b'echo main interpreter',))
main interpreter
you got pwned

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43438>
_______________________________________

From report at bugs.python.org  Thu Mar 11 04:37:51 2021
From: report at bugs.python.org (Hubert Bonnisseur-De-La-Bathe)
Date: Thu, 11 Mar 2021 09:37:51 +0000
Subject: [issue43473] Junks in difflib
Message-ID: <1615455471.04.0.613792585483.issue43473@roundup.psfhosted.org>


New submission from Hubert Bonnisseur-De-La-Bathe <hubertbdlb at gmail.com>:

Reading first at the documentation of difflib, I thought that the use of junks would have produced the result 

s = SequenceMatcher(lambda x : x == " ", "abcd efgh", "abcdefgh")
s.get_matching_blocks()
>>> [Match(a=0, b=0, size=8)]

At a second lecture, it is clear that such evaluation will return in fact two matches of length 4.

Would it be nicer to have get_matching_block return the length 8 match ? 

Don't know if it's in the spirit of the lib, I'm just asking.

----------
assignee: docs at python
components: Documentation
messages: 388491
nosy: docs at python, hubertbdlb
priority: normal
severity: normal
status: open
title: Junks in difflib
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43473>
_______________________________________

From report at bugs.python.org  Thu Mar 11 04:44:53 2021
From: report at bugs.python.org (junyixie)
Date: Thu, 11 Mar 2021 09:44:53 +0000
Subject: [issue40521] [subinterpreters] Make free lists and unicode caches
 per-interpreter
In-Reply-To: <1588693682.5.0.219755904926.issue40521@roundup.psfhosted.org>
Message-ID: <1615455893.26.0.964521602088.issue40521@roundup.psfhosted.org>


junyixie <xie.junyi at outlook.com> added the comment:

Should Make dtoa bigint free list per-interpreter.

static Bigint *bigint_freelist[Kmax+1]; -> _is { Bigint *bigint_freelist[Kmax+1]; }

----------
message_count: 43.0 -> 44.0
nosy: +JunyiXie
nosy_count: 5.0 -> 6.0
pull_requests: +23587
pull_request: https://github.com/python/cpython/pull/24821

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40521>
_______________________________________

From report at bugs.python.org  Thu Mar 11 04:46:00 2021
From: report at bugs.python.org (junyixie)
Date: Thu, 11 Mar 2021 09:46:00 +0000
Subject: [issue40521] [subinterpreters] Make free lists and unicode caches
 per-interpreter
In-Reply-To: <1588693682.5.0.219755904926.issue40521@roundup.psfhosted.org>
Message-ID: <1615455960.72.0.952380359733.issue40521@roundup.psfhosted.org>


junyixie <xie.junyi at outlook.com> added the comment:

https://github.com/python/cpython/pull/24821/commits/9d7681dbd273b5025fd9b19d1be0a1f978a0b12e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40521>
_______________________________________

From report at bugs.python.org  Thu Mar 11 05:10:02 2021
From: report at bugs.python.org (Hasan)
Date: Thu, 11 Mar 2021 10:10:02 +0000
Subject: [issue43334] venv does not install libpython
In-Reply-To: <1614379216.7.0.137032053148.issue43334@roundup.psfhosted.org>
Message-ID: <1615457402.43.0.534525886776.issue43334@roundup.psfhosted.org>


Hasan <hasan.aliyev.555 at gmail.com> added the comment:

Can you please provide more information about this behavior?

----------
nosy: +AliyevH

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43334>
_______________________________________

From report at bugs.python.org  Thu Mar 11 05:11:20 2021
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 11 Mar 2021 10:11:20 +0000
Subject: [issue43473] Junks in difflib
In-Reply-To: <1615455471.04.0.613792585483.issue43473@roundup.psfhosted.org>
Message-ID: <1615457480.24.0.20258088572.issue43473@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43473>
_______________________________________

From report at bugs.python.org  Thu Mar 11 05:14:11 2021
From: report at bugs.python.org (junyixie)
Date: Thu, 11 Mar 2021 10:14:11 +0000
Subject: [issue43441] [Subinterpreters]: global variable next_version_tag
 cause method cache bug
In-Reply-To: <1615262084.5.0.815014213556.issue43441@roundup.psfhosted.org>
Message-ID: <1615457651.58.0.931631332399.issue43441@roundup.psfhosted.org>


Change by junyixie <xie.junyi at outlook.com>:


----------
components: +Subinterpreters -Interpreter Core
title: mutilcorevm: global variable next_version_tag cause method cache bug -> [Subinterpreters]: global variable next_version_tag cause method cache bug

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43441>
_______________________________________

From report at bugs.python.org  Thu Mar 11 05:17:21 2021
From: report at bugs.python.org (junyixie)
Date: Thu, 11 Mar 2021 10:17:21 +0000
Subject: [issue43441] [Subinterpreters]: global variable next_version_tag
 cause method cache bug
In-Reply-To: <1615262084.5.0.815014213556.issue43441@roundup.psfhosted.org>
Message-ID: <1615457841.95.0.99609776085.issue43441@roundup.psfhosted.org>


Change by junyixie <xie.junyi at outlook.com>:


----------
keywords: +patch
pull_requests: +23588
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24822

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43441>
_______________________________________

From report at bugs.python.org  Thu Mar 11 05:18:11 2021
From: report at bugs.python.org (junyixie)
Date: Thu, 11 Mar 2021 10:18:11 +0000
Subject: [issue43441] [Subinterpreters]: global variable next_version_tag
 cause method cache bug
In-Reply-To: <1615262084.5.0.815014213556.issue43441@roundup.psfhosted.org>
Message-ID: <1615457891.96.0.27568052644.issue43441@roundup.psfhosted.org>


junyixie <xie.junyi at outlook.com> added the comment:

This is a simple fix.
https://github.com/python/cpython/pull/24822/commits/e61ce1dd28a48534ee497aaacb4439193bedfd42

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43441>
_______________________________________

From report at bugs.python.org  Thu Mar 11 05:21:18 2021
From: report at bugs.python.org (junyixie)
Date: Thu, 11 Mar 2021 10:21:18 +0000
Subject: [issue43441] [Subinterpreters]: global variable next_version_tag
 cause method cache bug
In-Reply-To: <1615262084.5.0.815014213556.issue43441@roundup.psfhosted.org>
Message-ID: <1615458078.29.0.980982206562.issue43441@roundup.psfhosted.org>


junyixie <xie.junyi at outlook.com> added the comment:

under building Python with --with-experimental-isolated-subinterpreters

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43441>
_______________________________________

From report at bugs.python.org  Thu Mar 11 06:09:22 2021
From: report at bugs.python.org (Sergei Lebedev)
Date: Thu, 11 Mar 2021 11:09:22 +0000
Subject: [issue5857] Return namedtuples from tokenize token generator
In-Reply-To: <1240864016.41.0.600109014145.issue5857@psf.upfronthosting.co.za>
Message-ID: <1615460962.64.0.933358977087.issue5857@roundup.psfhosted.org>


Sergei Lebedev <sergei.a.lebedev at gmail.com> added the comment:

> I strongly prefer that there not be inner named tuples. 

Hi Raymond, do you still strongly prefer (row, col) to remain unnamed? If so, could you comment on what makes you prefer that apart from (row, col) being more common than (col, row)? 

Are there any performance implications/runtime costs associated with making it (row, col) a namedtuple?

----------
nosy: +superbobry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5857>
_______________________________________

From report at bugs.python.org  Thu Mar 11 06:09:59 2021
From: report at bugs.python.org (grumblor)
Date: Thu, 11 Mar 2021 11:09:59 +0000
Subject: [issue43474] http.server.BaseHTTPRequestHandler  end_header() fails
Message-ID: <1615460999.3.0.75730553286.issue43474@roundup.psfhosted.org>


New submission from grumblor <gitgrumblor at gmail.com>:

Python Version 3.8
http.server version 0.6
This is current install in new xubuntu 20.04 LTS, no idea if this is fixed in other version but appears to be present on github 
https://github.com/python/cpython/blob/3.9/Lib/http/server.py
at line 525

http.server.BaseHTTPRequestHandler end_headers() can reference _header_buffer array before it is assigned.

Should this be updated to something like the following? This fixes the problem of end_headers() failing for me:


    def end_headers(self):
        if not hasattr(self, '_headers_buffer'):
            self._headers_buffer = []
        """Send the blank line ending the MIME headers."""
        if self.request_version != 'HTTP/0.9':
            self._headers_buffer.append(b"\r\n")
            self.flush_headers()


This is my first issue, apologies for any mistakes I might have made.

----------
components: Library (Lib)
messages: 388498
nosy: grumblor
priority: normal
severity: normal
status: open
title: http.server.BaseHTTPRequestHandler  end_header() fails
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43474>
_______________________________________

From report at bugs.python.org  Thu Mar 11 06:29:18 2021
From: report at bugs.python.org (Antti Haapala)
Date: Thu, 11 Mar 2021 11:29:18 +0000
Subject: [issue43468] functools.cached_property locking is plain wrong.
In-Reply-To: <1615444667.91.0.948817723419.issue43468@roundup.psfhosted.org>
Message-ID: <1615462158.09.0.214591203069.issue43468@roundup.psfhosted.org>


Antti Haapala <antti at haapala.name> added the comment:

Django was going to replace their cached_property by the standard library one https://code.djangoproject.com/ticket/30949

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43468>
_______________________________________

From report at bugs.python.org  Thu Mar 11 06:31:51 2021
From: report at bugs.python.org (grumblor)
Date: Thu, 11 Mar 2021 11:31:51 +0000
Subject: [issue43474] http.server.BaseHTTPRequestHandler  end_header() fails
In-Reply-To: <1615460999.3.0.75730553286.issue43474@roundup.psfhosted.org>
Message-ID: <1615462311.9.0.496133482292.issue43474@roundup.psfhosted.org>


grumblor <gitgrumblor at gmail.com> added the comment:

perhaps simply returning the method if _headers_buffer isn't defined is better since there is probably nothing to flush.

    def end_headers(self):
        if not hasattr(self, '_headers_buffer'):
            return 1 
        """Send the blank line ending the MIME headers."""
        if self.request_version != 'HTTP/0.9':
            self._headers_buffer.append(b"\r\n")
            self.flush_headers()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43474>
_______________________________________

From report at bugs.python.org  Thu Mar 11 06:33:05 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 11 Mar 2021 11:33:05 +0000
Subject: [issue43466] ssl/hashlib: Add configure option to set or auto-detect
 rpath to OpenSSL libs
In-Reply-To: <1615418043.46.0.229114131093.issue43466@roundup.psfhosted.org>
Message-ID: <1615462385.36.0.369967983879.issue43466@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> AFAIK this won't play will with static linking.

It should not be any problem as long as we expose the SSL symbols in the dynamic table of the extension (this happens by default). The only nuisance would be that users will still need those shared objects around so they can be dlopened by the extension.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43466>
_______________________________________

From report at bugs.python.org  Thu Mar 11 06:53:00 2021
From: report at bugs.python.org (E. Paine)
Date: Thu, 11 Mar 2021 11:53:00 +0000
Subject: [issue43462] canvas.bbox returns None on 'hidden' items while coords
 doesn't
In-Reply-To: <1615384283.9.0.940431260638.issue43462@roundup.psfhosted.org>
Message-ID: <1615463580.86.0.696499666427.issue43462@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

This can be easily reproduced in Wish (8.6.11):

% pack [canvas .c]
% .c create rectangle 10 10 90 90
1
% .c bbox 1
9 9 91 91
% .c create rectangle 20 20 80 80 -state hidden
2
% .c bbox 2
%

I doubt this is a bug because the docs (https://www.tcl.tk/man/tcl8.6/TkCmd/canvas.htm#M36) say:

> if the matching items have empty bounding boxes (i.e. they have nothing to display) then an empty string is returned

----------
nosy: +epaine

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43462>
_______________________________________

From report at bugs.python.org  Thu Mar 11 07:01:19 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 11 Mar 2021 12:01:19 +0000
Subject: [issue37193] Memory leak while running TCP/UDPServer with
 socketserver.ThreadingMixIn
In-Reply-To: <1559908419.41.0.390422965351.issue37193@roundup.psfhosted.org>
Message-ID: <1615464079.36.0.280109559392.issue37193@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thank you for fixing the regression Jason R. Coombs ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37193>
_______________________________________

From report at bugs.python.org  Thu Mar 11 08:27:38 2021
From: report at bugs.python.org (David Wood)
Date: Thu, 11 Mar 2021 13:27:38 +0000
Subject: [issue43435] Py_BuildValue("y#".... returns incomplete result
In-Reply-To: <1615217493.05.0.795009945001.issue43435@roundup.psfhosted.org>
Message-ID: <1615469258.91.0.0808928435709.issue43435@roundup.psfhosted.org>


Change by David Wood <dwoodjunkmail at gmail.com>:


Removed file: https://bugs.python.org/file49861/crypt.tar.gz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43435>
_______________________________________

From report at bugs.python.org  Thu Mar 11 08:28:22 2021
From: report at bugs.python.org (Vincent)
Date: Thu, 11 Mar 2021 13:28:22 +0000
Subject: [issue43462] canvas.bbox returns None on 'hidden' items while coords
 doesn't
In-Reply-To: <1615384283.9.0.940431260638.issue43462@roundup.psfhosted.org>
Message-ID: <1615469302.24.0.262498266893.issue43462@roundup.psfhosted.org>


Vincent <inquiry at intoreflection.co> added the comment:

Thank you for your comments. Yes, I would doubt that, too. You would expect to get a bounding box regardless what state the canvas item are in. The only way to fix this (and I'm open to suggestions), is to create a (custom) function that calculate every object belonging to a specific tag and add/subtract the coordinates - this is cumbersome.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43462>
_______________________________________

From report at bugs.python.org  Thu Mar 11 08:34:23 2021
From: report at bugs.python.org (Vincent)
Date: Thu, 11 Mar 2021 13:34:23 +0000
Subject: [issue43462] canvas.bbox returns None on 'hidden' items while coords
 doesn't
In-Reply-To: <1615384283.9.0.940431260638.issue43462@roundup.psfhosted.org>
Message-ID: <1615469663.89.0.452907615313.issue43462@roundup.psfhosted.org>


Vincent <inquiry at intoreflection.co> added the comment:

... calculate the coordinates using the canvas.coords function

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43462>
_______________________________________

From report at bugs.python.org  Thu Mar 11 09:16:50 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 11 Mar 2021 14:16:50 +0000
Subject: [issue43452] Microoptimize PyType_Lookup for cache hits
In-Reply-To: <1615317677.24.0.232039554227.issue43452@roundup.psfhosted.org>
Message-ID: <1615472210.73.0.848549275852.issue43452@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Geometric mean: 1.04x faster

Hey, it's good to see my new pyperf feature being used :-D IMO it helps to more easily compare a large set of benchmarks.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43452>
_______________________________________

From report at bugs.python.org  Thu Mar 11 09:29:14 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Thu, 11 Mar 2021 14:29:14 +0000
Subject: [issue43454] [sqlite3] Add support for R*Tree callbacks
In-Reply-To: <1615326865.81.0.691983788342.issue43454@roundup.psfhosted.org>
Message-ID: <1615472954.93.0.867905440507.issue43454@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

Unfortunately, there's no way to detect R*Tree support in sqlite3.h. We could run a script that dumps the compile options, and generate a config.h file from that:

$ for L in $(sqlite3 ":memory:" "pragma compile_options"); do echo #define SQLITE_$L >> config.h; done
$ cat config.h
#define SQLITE_COMPILER=clang-12.0.0
#define SQLITE_ENABLE_DBSTAT_VTAB
#define SQLITE_ENABLE_FTS4
#define SQLITE_ENABLE_FTS5
#define SQLITE_ENABLE_GEOPOLY
#define SQLITE_ENABLE_JSON1
#define SQLITE_ENABLE_RTREE
#define SQLITE_ENABLE_STMTVTAB
#define SQLITE_THREADSAFE=1


For Windows and macOS builds, we've already got the SQLite library compile options, so we can just reuse them in CFLAGS when we're building the sqlite3 module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43454>
_______________________________________

From report at bugs.python.org  Thu Mar 11 09:55:33 2021
From: report at bugs.python.org (Cong Ma)
Date: Thu, 11 Mar 2021 14:55:33 +0000
Subject: [issue43475] Worst-case behaviour of hash collision with float NaN
Message-ID: <1615474533.28.0.166606930148.issue43475@roundup.psfhosted.org>


New submission from Cong Ma <m.cong at protonmail.ch>:

Summary: CPython hash all NaN values to 0. This guarantees worst-case behaviour for dict if numerous existing keys are NaN. I think by hashing NaN using the generic object (or "pointer") hash instead, the worst-case situation can be alleviated without changing the semantics of either dict or float. However, this also requires changes to how complex and Decimal objects hash, and moreover incompatible change to sys.hash_info. I would like to hear how Python developers think about this matter.

--------

Currently CPython uses the hard-coded macro constant 0 (_PyHASH_NAN, defined in Include/pyhash.h) for the hash value of all floating point NaNs. The value is part of the sys.hashinfo API and is re-used by complex and Decimal in computing its hash in accordance with Python builtin-type documentation. [0]

(The doc [0] specifically says that "[a]ll hashable nans have the same hash value.")

This is normally not a great concern, except for the worst case performance. The problem is that, since they hash to the same value and they're guaranteed to compare unequal to any compatible numeric value -- not even to themselves, this means they're guaranteed to collide.

For this reason I'd like to question whether it is a good idea to have all hashable NaNs with the same hash value.

There has been some discussions about this over the Web for some time (see [1]). In [1] the demo Python script times the insertion of k distinct NaN keys (as different objects) into a freshly created dict. Since the keys are distinct and are guaranteed to collide with each other (if any), the run time of a single lookup/insertion is roughly linear to the existing number of NaN keys. I've recreated the same script using with a more modern Python (attached).

I'd suggest a fix for this worst-case behaviour: instead of returning the hash value 0 for all NaNs, use the generic object (pointer) hash for these objects. As a PoC (also in the attached script), it roughly means

```
class myfloat(float):
    def __hash__(self):
        if self != self:  # i.e., math.isnan(self)
            return object.__hash__(self)
        return super().__hash__(self)
```

This will
- keep the current behaviour of dict intact;
- keep the invariant `a == b implies hash(a) == hash(b)` intact, where applicable;
- uphold all the other rules for Python numeric objects listed in [0];
- make hash collisions no more likely than with object() instances (dict lookup time is amortized constant w.r.t. existing number of NaN keys).

However, it will
- not keep the current rule "All hashable nans have the same hash value";
- not be compatible with the current sys.hash_info API (requires the removal of the "nan" attribute from there and documenting the change);
- require congruent modifications in complex and Decimal too.

Additionally, I don't think this will affect module-level NaN "constants" such as math.nan and how they behave. The "NaN constant" has never been a problem to begin with. It's only the *distinct* NaN objects that may cause the worst-case behaviour.

--------

Just for the record I'd also like to clear some outdated info or misconception about NaN keys in Python dicts. It's not true that NaN keys, once inserted, cannot be retrieved (e.g., as claimed in [1][2]). In Python, they can be, if you keep the original key *object* around by keeping a reference to it (or obtaining a new one from the dict by iterating over it). This, I think, is because Python dict compares for object identity before rich-comparing for equality in `lookdict()` in Objects/dictobject.c, so this works for `d = dict()`:

```
f = float("nan")
d[f] = "value"
v = d[f]
```

but this fails with `KeyError`, as it should:

```
d[float("nan")] = "value"
v = d[float("nan")]
```

In this regard the NaN float object behaves exactly like the object() instance as keys -- except for the collisions. That's why I think at least for floats the "object" hash is likely to work. The solution using PRNG [1] (implemented with the Go language) is not necessary for CPython because the live objects are already distinct.

--------

Links:

[0] https://docs.python.org/3/library/stdtypes.html#hashing-of-numeric-types
[1] https://research.swtch.com/randhash
[2] https://readafterwrite.wordpress.com/2017/03/23/how-to-hash-floating-point-numbers/

----------
components: Interpreter Core, Library (Lib)
files: nan_key.py
messages: 388508
nosy: congma
priority: normal
severity: normal
status: open
title: Worst-case behaviour of hash collision with float NaN
type: performance
Added file: https://bugs.python.org/file49869/nan_key.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43475>
_______________________________________

From report at bugs.python.org  Thu Mar 11 10:15:20 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 11 Mar 2021 15:15:20 +0000
Subject: =?utf-8?q?=5Bissue43181=5D_Python_macros_don=E2=80=99t_shield_arguments?=
In-Reply-To: <1612908350.59.0.954965139249.issue43181@roundup.psfhosted.org>
Message-ID: <1615475720.29.0.101959025381.issue43181@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Yet... the first argument is still unshielded, passed to a macro that expects one single macro argument.

Are you talking about the current code in the master branch or the 3.9 branch? If you are talking about the _PyObject_CAST(ob) call, would you mind to elaborate how it is an issue? The code in master LGTM.

> That?s not a regression, it wasn?t shielded in 3.8 either, but why not just parenthesise each macro argument that denotes an expression (as opposed to e.g. name)?

In the master branch, Include/ and its subdirectories contains 158 .h files for a total of 20K lines of C code. It's not easy to check all files. If you spotted bugs, would you mind to give examples, or a way to automatically detect bugs?

As I wrote previously, I dislike macros. If someone is changed, I would prefer to convert the function into a static inline function which doesn't have macros pitfalls.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43181>
_______________________________________

From report at bugs.python.org  Thu Mar 11 10:52:52 2021
From: report at bugs.python.org (Piotr Dobrogost)
Date: Thu, 11 Mar 2021 15:52:52 +0000
Subject: [issue43312] Interface to select preferred "user" or "home" sysconfig
 scheme for an environment
In-Reply-To: <1614158800.84.0.101101658017.issue43312@roundup.psfhosted.org>
Message-ID: <1615477972.17.0.790587816412.issue43312@roundup.psfhosted.org>


Change by Piotr Dobrogost <bugs.python.org at p.dobrogost.net>:


----------
nosy: +piotr.dobrogost

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43312>
_______________________________________

From report at bugs.python.org  Thu Mar 11 10:56:35 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 11 Mar 2021 15:56:35 +0000
Subject: [issue43475] Worst-case behaviour of hash collision with float NaN
In-Reply-To: <1615474533.28.0.166606930148.issue43475@roundup.psfhosted.org>
Message-ID: <1615478195.19.0.631922517333.issue43475@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/issue43475>
_______________________________________

From report at bugs.python.org  Thu Mar 11 10:58:57 2021
From: report at bugs.python.org (Nathaniel Manista)
Date: Thu, 11 Mar 2021 15:58:57 +0000
Subject: [issue17519] unittest should not try to run abstract classes
In-Reply-To: <1363951466.19.0.505441528041.issue17519@psf.upfronthosting.co.za>
Message-ID: <1615478337.4.0.428763329507.issue17519@roundup.psfhosted.org>


Nathaniel Manista <nathaniel at google.com> added the comment:

In the years since this was considered and declined, I wonder if the facts have changed sufficiently to make it now worth doing?

I often find myself writing TestCases for interfaces, and those define test_* methods that call the interface under test, but of course my TestCase needs to be abstract because I'm only testing an interface and not a concrete implementation of that interface. It's also the case when I'm writing this kind of test that I wish to use a type-checker, and if I can have my abstract TestCase inherit from unittest.TestCase, that will satisfy my type-checker's questions about why I believe my TestCase has all kinds of assert* methods defined that it doesn't otherwise see.

I currently have the impression that if this is cheap enough to do, it may be worth doing just for the ergonomics alone? It mightn't make anything impossible become possible to do, but I forecast that it would make something difficult to do much more straightforward to do.

(I remain a fan of the all-powerful load_tests protocol, but... often it's nice to escape all the responsibility that comes with use of it.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17519>
_______________________________________

From report at bugs.python.org  Thu Mar 11 12:35:41 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 11 Mar 2021 17:35:41 +0000
Subject: [issue43475] Worst-case behaviour of hash collision with float NaN
In-Reply-To: <1615474533.28.0.166606930148.issue43475@roundup.psfhosted.org>
Message-ID: <1615484141.6.0.148822517575.issue43475@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Sigh. When I'm undisputed ruler of the multiverse, I'm going to make "NaN == NaN" return True, IEEE 754 be damned. NaN != NaN is fine(ish) at the level of numerics; the problems start when the consequences of that choice leak into the other parts of the language that care about equality. NaNs just shouldn't be considered "special enough to break the rules" (where the rules here are that the equivalence relation being used as the basis of equality for a general container should actually *be* an equivalence relation - reflexive, symmetric, and transitive).

Anyway, more constructively ...

I agree with the analysis, and the proposed solution seems sound: if we're going to change this, then using the object hash seems like a workable solution. The question is whether we actually do need to change this.

I'm not too worried about backwards compatibility here: if we change this, we're bound to break *someone's* code somewhere, but it's hard to imagine that there's *that* much code out there that makes useful use of the property that hash(nan) == 0. The most likely source of breakage I can think of is in test code that checks that 3rd-party float-like things (NumPy's float64, or gmpy2 floats, or ...) behave like Python's floats.

@Cong Ma: do you have any examples of cases where this has proved, or is likely to prove, a problem in real-world code, or is this purely theoretical at this point?

I'm finding it hard to imagine cases where a developer *intentionally* has a dictionary with several NaN values as keys. (Even a single NaN as a key seems a stretch; general floats as dictionary keys are rare in real-world code that I've encountered.) But it's somewhat easier to imagine situations where one could run into this accidentally. Here's one such:

>>> import collections, numpy as np
>>> x = np.full(100000, np.nan)
>>> c = collections.Counter(x)

That took around 4 minutes of non-ctrl-C-interruptible time on my laptop. (I was actually expecting it not to "work" as a bad example: I was expecting that NaNs realised from a NumPy array would all be the same NaN object, but that's not what happens.) For comparison, this appears instant:

>>> x = np.random.rand(100000)
>>> c = collections.Counter(x)

And it's not a stretch to imagine having a NumPy array representing a masked binary 1024x1024-pixel image (float values of NaN, 0.0 and 1.0) and using Counter to find out how many 0s and 1s there were.

On the other hand, we've lived with the current behaviour for some decades now without it apparently ever being a real issue.

On balance, I'm +1 for fixing this. It seems like a failure mode that would be rarely encountered, but it's quite unpleasant when it *is* encountered.

----------
nosy: +rhettinger, tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43475>
_______________________________________

From report at bugs.python.org  Thu Mar 11 12:57:11 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 11 Mar 2021 17:57:11 +0000
Subject: [issue43475] Worst-case behaviour of hash collision with float NaN
In-Reply-To: <1615474533.28.0.166606930148.issue43475@roundup.psfhosted.org>
Message-ID: <1615485431.44.0.527639271694.issue43475@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hmm. On second thoughts, the proposed solution wouldn't actually *help* with the situation I gave: the elements (lazily) realised from the NumPy array are highly likely to all end up with the same address in RAM. :-(

>>> x = np.full(10, np.nan)
>>> for v in x:
...     print(id(v))
...     del v
... 
4601757008
4601757008
4601757008
4601757008
4601757008
4601757008
4601757008
4601757008
4601757008
4601757008

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43475>
_______________________________________

From report at bugs.python.org  Thu Mar 11 12:58:01 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 11 Mar 2021 17:58:01 +0000
Subject: [issue43475] Worst-case behaviour of hash collision with float NaN
In-Reply-To: <1615474533.28.0.166606930148.issue43475@roundup.psfhosted.org>
Message-ID: <1615485481.69.0.327828148363.issue43475@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

On third thoughts, of course it *would* help, because the Counter is keeping references to the realised NaN values. I think I'll go away now and come back when my brain is working.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43475>
_______________________________________

From report at bugs.python.org  Thu Mar 11 13:57:41 2021
From: report at bugs.python.org (Cong Ma)
Date: Thu, 11 Mar 2021 18:57:41 +0000
Subject: [issue43475] Worst-case behaviour of hash collision with float NaN
In-Reply-To: <1615474533.28.0.166606930148.issue43475@roundup.psfhosted.org>
Message-ID: <1615489061.92.0.390808874253.issue43475@roundup.psfhosted.org>


Cong Ma <m.cong at protonmail.ch> added the comment:

Thank you @mark.dickinson for the detailed analysis.

In addition to your hypothetical usage examples, I am also trying to understand the implications for user code.

If judging by the issues people open on GitHub like this: https://github.com/pandas-dev/pandas/issues/28363 yes apparently people do run into the "NaN as key" problem every now and then, I guess. (I'm not familiar enough with the poster's real problem in the Pandas setting to comment about that one, but it seems to suggest people do run into "real world" problems that shares some common features with this one). There's also StackOverflow threads like this (https://stackoverflow.com/a/17062985) where people discuss hashing a data table that explicitly use NaN for missing values. The reason seems to be that "[e]mpirical evidence suggests that hashing is an effective strategy for dimensionality reduction and practical nonparametric estimation." (https://arxiv.org/pdf/0902.2206.pdf).

I cannot imagine whether the proposed change would make life easier for people who really want NaN keys to begin with. However I think it might reduce the exposure to worst-case performances in dict (and maybe set/frozenset), while not hurting Python's own self-consistency.

Maybe there's one thing to consider about future compatibility though... because the proposed fix depends on the current behaviour that floats (and by extension, built-in float-like objects such as Decimal and complex) are not cached, unlike small ints and interned Unicode objects. So when you explicitly construct a NaN by calling float(), you always get a new Python object. Is this guaranteed now on different platforms with different compilers? I'm trying to parse the magic in Include/pymath.h about the definition of macro `Py_NAN`, where it seems to me that for certain configs it could be a `static const union` translation-unit-level constant. Does this affect the code that actually builds a Python object from an underlying NaN? (I apologize if this is a bad question). But if it doesn't and we're guaranteed to really have Python NaN-objects that don't alias if explicitly constructed, is this something unlikely to change in the future?

I also wonder if there's security implication for servers that process user-submitted input, maybe running a float() constructor on some string list, checking exceptions but silently succeeding with "nan": arguably this is not going to be as common an concern as the string-key collision DoS now foiled by hash randomization, but I'm not entirely sure.

On "theoretical interest".. yes theoretical interests can also be "real world" if one teaches CS theory in real world using Python, see https://bugs.python.org/issue43198#msg386849

So yes, I admit we're in an obscure corner of Python here. It's a tricky, maybe-theoretical, but seemingly annoying but easy-to-fix issue..

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43475>
_______________________________________

From report at bugs.python.org  Thu Mar 11 14:01:14 2021
From: report at bugs.python.org (Ned Deily)
Date: Thu, 11 Mar 2021 19:01:14 +0000
Subject: [issue43470] Installation of Python 3.6.13 fails on MacOS Big Sur
 11.2.3
In-Reply-To: <1615447118.51.0.748339501359.issue43470@roundup.psfhosted.org>
Message-ID: <1615489274.78.0.926917378736.issue43470@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

I'm sorry you ran into this but, unfortunately, the binaries from Python.org macOS installers prior to 3.7 do not work on macOS 11 Big Sur. Since Python 3.6 and 3.7 are in the security-fix-only phase of the life cycles, we do not provide support on them for new OS versions and providing new binary installers.  Please see the detailed response to Issue43470 for more information.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Installation of Python 3.6.13 fails on MacOS Big Sur 11.2.3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43470>
_______________________________________

From report at bugs.python.org  Thu Mar 11 14:02:24 2021
From: report at bugs.python.org (Ned Deily)
Date: Thu, 11 Mar 2021 19:02:24 +0000
Subject: [issue43469] Python 3.6 fails to run on MacOS (Big Sur 11.2.3)
In-Reply-To: <1615447050.11.0.0564734952656.issue43469@roundup.psfhosted.org>
Message-ID: <1615489344.25.0.322321492649.issue43469@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

I'm sorry you ran into this but, unfortunately, the binaries from Python.org macOS installers prior to 3.7 do not work on macOS 11 Big Sur. Since Python 3.6 and 3.7 are in the security-fix-only phase of the life cycles, we do not provide support on them for new OS versions and providing new binary installers.  Please see the detailed response to Issue43470 for more information.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Older Python builds are missing a required file on Big Sur

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43469>
_______________________________________

From report at bugs.python.org  Thu Mar 11 14:04:17 2021
From: report at bugs.python.org (Ned Deily)
Date: Thu, 11 Mar 2021 19:04:17 +0000
Subject: [issue43470] Installation of Python 3.6.13 fails on MacOS Big Sur
 11.2.3
In-Reply-To: <1615447118.51.0.748339501359.issue43470@roundup.psfhosted.org>
Message-ID: <1615489457.4.0.779693299194.issue43470@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
superseder: Installation of Python 3.6.13 fails on MacOS Big Sur 11.2.3 -> Older Python builds are missing a required file on Big Sur

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43470>
_______________________________________

From report at bugs.python.org  Thu Mar 11 14:04:31 2021
From: report at bugs.python.org (Ned Deily)
Date: Thu, 11 Mar 2021 19:04:31 +0000
Subject: [issue43470] Installation of Python 3.6.13 fails on MacOS Big Sur
 11.2.3
In-Reply-To: <1615447118.51.0.748339501359.issue43470@roundup.psfhosted.org>
Message-ID: <1615489471.58.0.404647715365.issue43470@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
Removed message: https://bugs.python.org/msg388515

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43470>
_______________________________________

From report at bugs.python.org  Thu Mar 11 14:10:29 2021
From: report at bugs.python.org (Saiyang Gou)
Date: Thu, 11 Mar 2021 19:10:29 +0000
Subject: [issue43438] [doc] sys.addaudithook() documentation should be more
 explicit on its limitations
In-Reply-To: <1615235174.36.0.713670774369.issue43438@roundup.psfhosted.org>
Message-ID: <1615489829.21.0.611360303751.issue43438@roundup.psfhosted.org>


Saiyang Gou <gousaiyang223 at gmail.com> added the comment:

> Please also keep in mind that sys.addaudithook() does **not** add a global hook. The function adds a per-interpreter hook.

Yes, I'm aware of this. And this should be better documented. When I was playing around with audit hooks and reading the source code, I see hooks written in Python (added via sys.addaudithook) are per-interpreter (stored in a Python list object as part of per-interpreter state) while hooks written in C (added via PySys_AddAuditHook) are global (stored in a C linked list). C hooks are more robust. The Python hooks are not inherited in a child process created via multiprocessing when the start method is "spawn" or "forkserver" (not "fork") since they are per-interpreter. I'm not sure whether we should audit the creation of new processes/threads via multiprocessing/threading modules (and also creation of sub-interpreters when PEP 554 gets accepted).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43438>
_______________________________________

From report at bugs.python.org  Thu Mar 11 14:13:35 2021
From: report at bugs.python.org (Ned Deily)
Date: Thu, 11 Mar 2021 19:13:35 +0000
Subject: [issue43470] Installation of Python 3.6.13 fails on MacOS Big Sur
 11.2.3
In-Reply-To: <1615447118.51.0.748339501359.issue43470@roundup.psfhosted.org>
Message-ID: <1615490015.01.0.513878652373.issue43470@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

[Updated response] I'm sorry you ran into this but, unfortunately, Python 3.6 is in its security-fix-only phase of its life cycles and, as such, we do not provide support on them for new OS versions.  Please see the detailed response to Issue43393 for more information. While the particular error you ran into is easily worked around, the resulting Python will still not execute correctly on macOS 11 Big Sur as there are a number of other run-time issues that would need to be fixed. At the moment, only Python 3.9.2 is fully supported on Big Sur.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43470>
_______________________________________

From report at bugs.python.org  Thu Mar 11 14:28:24 2021
From: report at bugs.python.org (Cong Ma)
Date: Thu, 11 Mar 2021 19:28:24 +0000
Subject: [issue43475] Worst-case behaviour of hash collision with float NaN
In-Reply-To: <1615474533.28.0.166606930148.issue43475@roundup.psfhosted.org>
Message-ID: <1615490904.56.0.0582175162071.issue43475@roundup.psfhosted.org>


Cong Ma <m.cong at protonmail.ch> added the comment:

Sorry, please ignore my rambling about "float() returning aliased object" -- in that case the problem with hashing doesn't arise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43475>
_______________________________________

From report at bugs.python.org  Thu Mar 11 14:43:49 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 11 Mar 2021 19:43:49 +0000
Subject: [issue43423] Subprocess IndexError possible in _communicate
In-Reply-To: <1615056762.46.0.090803448155.issue43423@roundup.psfhosted.org>
Message-ID: <1615491829.84.0.850821764828.issue43423@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:


New changeset b4fc44bb2d209182390b4f9fdf074a46b0165a2f by Chris Griffith in branch 'master':
bpo-43423 Fix IndexError in subprocess _communicate function (GH-24777)
https://github.com/python/cpython/commit/b4fc44bb2d209182390b4f9fdf074a46b0165a2f


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43423>
_______________________________________

From report at bugs.python.org  Thu Mar 11 14:44:21 2021
From: report at bugs.python.org (miss-islington)
Date: Thu, 11 Mar 2021 19:44:21 +0000
Subject: [issue43423] Subprocess IndexError possible in _communicate
In-Reply-To: <1615056762.46.0.090803448155.issue43423@roundup.psfhosted.org>
Message-ID: <1615491861.78.0.538314390077.issue43423@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: +23589
pull_request: https://github.com/python/cpython/pull/24824

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43423>
_______________________________________

From report at bugs.python.org  Thu Mar 11 14:51:50 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 11 Mar 2021 19:51:50 +0000
Subject: [issue43423] Subprocess IndexError possible in _communicate
In-Reply-To: <1615056762.46.0.090803448155.issue43423@roundup.psfhosted.org>
Message-ID: <1615492310.94.0.810662866718.issue43423@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

The bug is fixed, Thanks Chris!  There was a refactoring noted as being nice in my comments on the primary main branch PR that would be nice to have.  But isn't critical.  If you want to make a PR for that, just reuse this bpo-43423 issue number on the PR and assign it to me.

The backports to 3.9 an 3.8 are approved and should automerge after CI finishes.

----------
resolution:  -> fixed
stage: patch review -> commit review
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43423>
_______________________________________

From report at bugs.python.org  Thu Mar 11 14:54:31 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 11 Mar 2021 19:54:31 +0000
Subject: [issue43475] Worst-case behaviour of hash collision with float NaN
In-Reply-To: <1615474533.28.0.166606930148.issue43475@roundup.psfhosted.org>
Message-ID: <1615492471.08.0.952153924.issue43475@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I also wonder if there's security implication for servers that process user-submitted input

Yes, the "malicious actor" scenario is another one to consider. But unlike the string hashing attack, I'm not seeing a realistic way for the nan hash collisions to be used in attacks, and I'm content not to worry about that until someone gives an actual proof of concept. Many of Python's hash functions are fairly predictable (by design!) and there are already lots of other ways to deliberately construct lots of hash collisions with non-string non-float values.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43475>
_______________________________________

From report at bugs.python.org  Thu Mar 11 15:35:46 2021
From: report at bugs.python.org (Mariusz Felisiak)
Date: Thu, 11 Mar 2021 20:35:46 +0000
Subject: [issue43353] Document that logging.getLevelName() can return a
 numeric value.
In-Reply-To: <1614600000.66.0.180359096956.issue43353@roundup.psfhosted.org>
Message-ID: <1615494946.51.0.839344350472.issue43353@roundup.psfhosted.org>


Change by Mariusz Felisiak <felisiak.mariusz at gmail.com>:


----------
pull_requests: +23590
pull_request: https://github.com/python/cpython/pull/24825

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43353>
_______________________________________

From report at bugs.python.org  Thu Mar 11 15:36:55 2021
From: report at bugs.python.org (Mariusz Felisiak)
Date: Thu, 11 Mar 2021 20:36:55 +0000
Subject: [issue43353] Document that logging.getLevelName() can return a
 numeric value.
In-Reply-To: <1614600000.66.0.180359096956.issue43353@roundup.psfhosted.org>
Message-ID: <1615495015.95.0.0473920094579.issue43353@roundup.psfhosted.org>


Change by Mariusz Felisiak <felisiak.mariusz at gmail.com>:


----------
pull_requests: +23591
pull_request: https://github.com/python/cpython/pull/24826

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43353>
_______________________________________

From report at bugs.python.org  Thu Mar 11 15:38:02 2021
From: report at bugs.python.org (Mariusz Felisiak)
Date: Thu, 11 Mar 2021 20:38:02 +0000
Subject: [issue43353] Document that logging.getLevelName() can return a
 numeric value.
In-Reply-To: <1614600000.66.0.180359096956.issue43353@roundup.psfhosted.org>
Message-ID: <1615495082.78.0.0183731870919.issue43353@roundup.psfhosted.org>


Mariusz Felisiak <felisiak.mariusz at gmail.com> added the comment:

I've prepared PRs with backports.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43353>
_______________________________________

From report at bugs.python.org  Thu Mar 11 15:38:57 2021
From: report at bugs.python.org (Andre Roberge)
Date: Thu, 11 Mar 2021 20:38:57 +0000
Subject: [issue43476] Enabling access to showsyntaxerror for IDLE's shell
Message-ID: <1615495137.57.0.647569220862.issue43476@roundup.psfhosted.org>


New submission from Andre Roberge <andre.roberge at gmail.com>:

As a result of https://bugs.python.org/issue43008, IDLE now supports custom exception hook for almost all cases except for code entered in the interactive shell that result in SyntaxError. It would be useful for some applications if a way to replace the error handling currently done by IDLE for this particular case was made available to user code.

I consider this to be in the "would be nice to have" category, but in no means a high priority item.

----------
assignee: terry.reedy
components: IDLE
messages: 388524
nosy: aroberge, terry.reedy
priority: normal
severity: normal
status: open
title: Enabling access to showsyntaxerror for IDLE's shell
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43476>
_______________________________________

From report at bugs.python.org  Thu Mar 11 17:18:03 2021
From: report at bugs.python.org (Eric Snow)
Date: Thu, 11 Mar 2021 22:18:03 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1615501083.03.0.641429314682.issue40255@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow
nosy_count: 15.0 -> 16.0
pull_requests: +23592
pull_request: https://github.com/python/cpython/pull/24828

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Thu Mar 11 17:25:37 2021
From: report at bugs.python.org (Eric Snow)
Date: Thu, 11 Mar 2021 22:25:37 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1615501537.39.0.695480330936.issue40255@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

FYI, I've just put up a similar PR [1] to Eddie's, with a focus on object immortality rather than immutability.  However, if Py_IMMORTAL_CONST_REFCOUNTS is defined then it should have the behavior Eddie is after.

[1] https://github.com/python/cpython/pull/24828

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Thu Mar 11 17:27:34 2021
From: report at bugs.python.org (Eric Snow)
Date: Thu, 11 Mar 2021 22:27:34 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1615501654.91.0.657254918471.issue40255@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Note that my PR does make the builtin types immortal (at least those initialized in _PyTypes_Init()).  However, I did not make the singletons or other candidate objects immortal in the PR.  That can be done separately.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Thu Mar 11 17:36:01 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 11 Mar 2021 22:36:01 +0000
Subject: [issue43356] PyErr_SetInterrupt should have an equivalent that takes
 a signal number
In-Reply-To: <1614621328.26.0.486134499262.issue43356@roundup.psfhosted.org>
Message-ID: <1615502161.11.0.26642859097.issue43356@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:


New changeset ba251c2ae6654bfc8abd9d886b219698ad34ac3c by Antoine Pitrou in branch 'master':
bpo-43356: Allow passing a signal number to interrupt_main() (GH-24755)
https://github.com/python/cpython/commit/ba251c2ae6654bfc8abd9d886b219698ad34ac3c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43356>
_______________________________________

From report at bugs.python.org  Thu Mar 11 17:36:13 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 11 Mar 2021 22:36:13 +0000
Subject: [issue43356] PyErr_SetInterrupt should have an equivalent that takes
 a signal number
In-Reply-To: <1614621328.26.0.486134499262.issue43356@roundup.psfhosted.org>
Message-ID: <1615502173.34.0.500348198367.issue43356@roundup.psfhosted.org>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43356>
_______________________________________

From report at bugs.python.org  Thu Mar 11 17:56:35 2021
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 11 Mar 2021 22:56:35 +0000
Subject: [issue43132] Incorrect handling of PyObject_RichCompareBool() in the
 _zoneinfo module
In-Reply-To: <1612482481.94.0.955863254817.issue43132@roundup.psfhosted.org>
Message-ID: <1615503395.07.0.273031020247.issue43132@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
pull_requests: +23593
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/24829

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43132>
_______________________________________

From report at bugs.python.org  Thu Mar 11 18:08:36 2021
From: report at bugs.python.org (Saiyang Gou)
Date: Thu, 11 Mar 2021 23:08:36 +0000
Subject: [issue43439] [security] Add audit events on GC functions giving
 access to all Python objects
In-Reply-To: <1615235548.58.0.659993767767.issue43439@roundup.psfhosted.org>
Message-ID: <1615504116.26.0.696327096348.issue43439@roundup.psfhosted.org>


Saiyang Gou <gousaiyang223 at gmail.com> added the comment:

There is a minor issue here. For gc.get_referrers and gc.get_referents, probably the format code for PySys_Audit should be "(O)" instead of "O". Typically the tuple `args` passed to the hook functions are fixed-length as described in the audit events table. Here `objs` itself is a tuple (containing variable-length arguments) and directly passed to the audit hook with being wrapped by another layer of tuple. If the hook function is to receive a variable-length tuple, probably the documentation should be updated to mention this.

----------
nosy: +gousaiyang

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43439>
_______________________________________

From report at bugs.python.org  Thu Mar 11 18:11:11 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Thu, 11 Mar 2021 23:11:11 +0000
Subject: [issue43267] [sqlite3] Redundant type checks in
 pysqlite_statement_bind_parameter()
In-Reply-To: <1613731536.26.0.545379664561.issue43267@roundup.psfhosted.org>
Message-ID: <1615504271.25.0.919911528026.issue43267@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

$ python -m pyperf compare_to -G  main.json patched.json
Faster (1):
- bind: 63.6 us +- 1.2 us -> 61.8 us +- 0.9 us: 1.03x faster

$ git diff --shortstat master
 1 file changed, 41 insertions(+), 74 deletions(-)

----------
keywords: +patch
Added file: https://bugs.python.org/file49870/patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43267>
_______________________________________

From report at bugs.python.org  Thu Mar 11 19:00:27 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 12 Mar 2021 00:00:27 +0000
Subject: [issue43471] Fails to import bz2 on Ubuntu
In-Reply-To: <1615447237.87.0.642854040325.issue43471@roundup.psfhosted.org>
Message-ID: <1615507227.9.0.0809137623744.issue43471@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43471>
_______________________________________

From report at bugs.python.org  Thu Mar 11 19:40:38 2021
From: report at bugs.python.org (Thomas)
Date: Fri, 12 Mar 2021 00:40:38 +0000
Subject: [issue43477] from x import * behavior inconsistent between module
 types.
Message-ID: <1615509638.08.0.549124406797.issue43477@roundup.psfhosted.org>


New submission from Thomas <kaori.hinata at gmail.com>:

I'm looking for clarification as to how `from x import *` should operate when importing file/directory-based modules versus when importing a sub-module from within a directory-based module.

While looking into a somewhat related issue with pylint, I noticed that `from x import *` appears to behave inconsistently when called from within a directory-based module on a sub-module. Whereas normally `from x import *` intentionally does not cause `x` to be added to the current namespace, when called within a directory-based module to import from a sub-module (so, `from .y import *` in an `__init__.py`, for example), the sub-module (let's say, `y`) *does* end up getting added to the importing namespace. From what I can tell, this should not be happening. If this oddity has been documented somewhere, I may have just missed it, so please let me know if it has been.

This inconsistency is actually setting off pylint (and confusing its AST handling code) when you use the full path to reference any member of the `asyncio.subprocess` submodule (for example, `asyncio.subprocess.Process`) because, according to `asyncio`'s `__init__.py` file, no explicit import of the `subprocess` sub-module ever occurs, and yet you can draw the entire path all the way to it, and its members. I've attached a generic example of the different behaviors (tested with Python 3.9) using simple modules, including a demonstration of the sub-module import.

Thomas

----------
components: Interpreter Core
files: example.txz
messages: 388530
nosy: kaorihinata
priority: normal
severity: normal
status: open
title: from x import * behavior inconsistent between module types.
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file49871/example.txz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43477>
_______________________________________

From report at bugs.python.org  Thu Mar 11 20:30:02 2021
From: report at bugs.python.org (miss-islington)
Date: Fri, 12 Mar 2021 01:30:02 +0000
Subject: [issue43423] Subprocess IndexError possible in _communicate
In-Reply-To: <1615056762.46.0.090803448155.issue43423@roundup.psfhosted.org>
Message-ID: <1615512602.67.0.5979922191.issue43423@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +23594
pull_request: https://github.com/python/cpython/pull/24823

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43423>
_______________________________________

From report at bugs.python.org  Thu Mar 11 20:32:03 2021
From: report at bugs.python.org (miss-islington)
Date: Fri, 12 Mar 2021 01:32:03 +0000
Subject: [issue43423] Subprocess IndexError possible in _communicate
In-Reply-To: <1615056762.46.0.090803448155.issue43423@roundup.psfhosted.org>
Message-ID: <1615512723.03.0.850262195498.issue43423@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +23595
pull_request: https://github.com/python/cpython/pull/24830

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43423>
_______________________________________

From report at bugs.python.org  Thu Mar 11 20:32:11 2021
From: report at bugs.python.org (miss-islington)
Date: Fri, 12 Mar 2021 01:32:11 +0000
Subject: [issue43423] Subprocess IndexError possible in _communicate
In-Reply-To: <1615056762.46.0.090803448155.issue43423@roundup.psfhosted.org>
Message-ID: <1615512731.37.0.839297710121.issue43423@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +23596
pull_request: https://github.com/python/cpython/pull/24831

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43423>
_______________________________________

From report at bugs.python.org  Thu Mar 11 20:53:00 2021
From: report at bugs.python.org (miss-islington)
Date: Fri, 12 Mar 2021 01:53:00 +0000
Subject: [issue43423] Subprocess IndexError possible in _communicate
In-Reply-To: <1615056762.46.0.090803448155.issue43423@roundup.psfhosted.org>
Message-ID: <1615513980.37.0.0392557408984.issue43423@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1a5001c606b55226c03fa1046aa8f5e1db2fa67d by Miss Islington (bot) in branch '3.8':
bpo-43423 Fix IndexError in subprocess _communicate function (GH-24777)
https://github.com/python/cpython/commit/1a5001c606b55226c03fa1046aa8f5e1db2fa67d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43423>
_______________________________________

From report at bugs.python.org  Thu Mar 11 20:53:43 2021
From: report at bugs.python.org (Matthew Suozzo)
Date: Fri, 12 Mar 2021 01:53:43 +0000
Subject: [issue43478] Disallow Mock spec arguments from being Mocks
Message-ID: <1615514023.14.0.0477922265442.issue43478@roundup.psfhosted.org>


New submission from Matthew Suozzo <msuozzo at google.com>:

An unfortunately common pattern over large codebases of Python tests is for spec'd Mock instances to be provided with Mock objects as their specs. This gives the false sense that a spec constraint is being applied when, in fact, nothing will be disallowed.

The two most frequently observed occurrences of this anti-pattern are as follows:

* Re-patching an existing autospec.

  def setUp(self):
    mock.patch.object(mod, 'Klass', autospec=True).start()
    self.addCleanup(mock.patch.stopall)

  @mock.patch.object(mod, 'Klass', autospec=True)  # :(
  def testFoo(self, mock_klass):
    # mod.Klass has no effective spec.

* Deriving an autospec Mock from an already-mocked object

  def setUp(self):
    mock.patch.object(mod, 'Klass').start()
    ...
    mock_klass = mock.create_autospec(mod.Klass)  # :(
    # mock_klass has no effective spec

This is fairly easy to detect using _is_instance_mock at patch time however it can break existing tests.

I have a patch ready and it seems like this error case is not frequent enough that it would be disruptive to address.

Another option would be add it as a warning for a version e.g. 3.10 and then potentially make it a breaking change in 3.11. However considering this is a test-only change with a fairly clear path to fix it, that might be overly cautious.

----------
components: Tests
messages: 388532
nosy: msuozzo
priority: normal
severity: normal
status: open
title: Disallow Mock spec arguments from being Mocks
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43478>
_______________________________________

From report at bugs.python.org  Thu Mar 11 20:56:49 2021
From: report at bugs.python.org (miss-islington)
Date: Fri, 12 Mar 2021 01:56:49 +0000
Subject: [issue43423] Subprocess IndexError possible in _communicate
In-Reply-To: <1615056762.46.0.090803448155.issue43423@roundup.psfhosted.org>
Message-ID: <1615514209.61.0.972962898814.issue43423@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ad83fde75463dad2df878ff264f52436eb48bc6b by Miss Islington (bot) in branch '3.9':
bpo-43423 Fix IndexError in subprocess _communicate function (GH-24777)
https://github.com/python/cpython/commit/ad83fde75463dad2df878ff264f52436eb48bc6b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43423>
_______________________________________

From report at bugs.python.org  Thu Mar 11 21:11:01 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 12 Mar 2021 02:11:01 +0000
Subject: [issue2528] Change os.access to check ACLs under Windows
In-Reply-To: <1207059558.9.0.891835325783.issue2528@psf.upfronthosting.co.za>
Message-ID: <1615515061.68.0.389377640512.issue2528@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

With increasing use of os.access() in shutil and tempfile, it would be nice to have a real implementation of os.access() for Windows. 

Instead of manually evaluating the security of the file/directory, as issue2528.2.patch attempts to do, I'd rather just open the file with the desired access (e.g. GENERIC_READ, GENERIC_WRITE, GENERIC_EXECUTE). An open-based check supports checking for sharing violations, filesystem policy (e.g. FILE_READ_ATTRIBUTES granted by the parent directory), non-filesystem devices, and access policy implemented by filter drivers in the device stack. 

The code to open the file/directory can be factored out and generalized from the stat() implementation. The common open function can implement the flags AT_SYMLINK_NOFOLLOW and AT_EACCESS (without which it should temporarily revert to the process access token). Also, when a directory is opened with GENERIC_WRITE access, it can re-try the open with FILE_DELETE_CHILD access, which POSIX includes in write access for a directory.

An S_OK flag could also be supported to ignore a sharing violation in Windows. [MS-FSA] section 2.1.5.1.2 (Open of an Existing File) specifies that access sharing is checked after the readonly attribute and file security access check. So if an open fails with a sharing violation, the caller knows that access was otherwise granted.

----------
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2528>
_______________________________________

From report at bugs.python.org  Thu Mar 11 21:14:47 2021
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 12 Mar 2021 02:14:47 +0000
Subject: [issue43478] Disallow Mock spec arguments from being Mocks
In-Reply-To: <1615514023.14.0.0477922265442.issue43478@roundup.psfhosted.org>
Message-ID: <1615515287.88.0.24918363875.issue43478@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/issue43478>
_______________________________________

From report at bugs.python.org  Thu Mar 11 22:56:06 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 12 Mar 2021 03:56:06 +0000
Subject: [issue25481] PermissionError in subprocess.check_output() when an
 inaccessible directory on the path
In-Reply-To: <1445848797.06.0.600636578696.issue25481@psf.upfronthosting.co.za>
Message-ID: <1615521366.83.0.871201539729.issue25481@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> So, two interesting questions: does this in fact match the behavior of 
> os._execvpe, and does it match the behavior of the shell? 

I think it's fine. child_exec() tries all paths. It saves the first error that's not ENOENT or ENOTDIR. The saved error gets reported back, else ENOENT or ENOTDIR. This is the same as os._execvpe:

    for dir in path_list:
        fullname = path.join(dir, file)
        try:
            exec_func(fullname, *argrest)
        except (FileNotFoundError, NotADirectoryError) as e:
            last_exc = e
        except OSError as e:
            last_exc = e
            if saved_exc is None:
                saved_exc = e
    if saved_exc is not None:
        raise saved_exc
    raise last_exc

Perhaps the rule for PATH search errors should be documented for os.execvp[e] and subprocess.

I think it matches the shell, except, AFAIK, the shell doesn't distinguish ENOENT and ENOTDIR errors. For example, where "/noexec" is a directory that has no execute access:

    $ /bin/sh -c spam
    /bin/sh: 1: spam: not found

    $ PATH=/noexec:$PATH /bin/sh -c spam
    /bin/sh: 1: spam: Permission denied

----------
assignee:  -> docs at python
components: +Documentation, Library (Lib)
nosy: +docs at python
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25481>
_______________________________________

From report at bugs.python.org  Fri Mar 12 03:46:35 2021
From: report at bugs.python.org (miss-islington)
Date: Fri, 12 Mar 2021 08:46:35 +0000
Subject: [issue43353] Document that logging.getLevelName() can return a
 numeric value.
In-Reply-To: <1614600000.66.0.180359096956.issue43353@roundup.psfhosted.org>
Message-ID: <1615538795.36.0.164476286978.issue43353@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 4d7f11e05731f67fd2c07ec2972c6cb9861d52be by Mariusz Felisiak in branch '3.9':
[3.9] bpo-43353: Document that logging.getLevelName() accepts string representation of logging level. (GH-24693) (GH-24826)
https://github.com/python/cpython/commit/4d7f11e05731f67fd2c07ec2972c6cb9861d52be


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43353>
_______________________________________

From report at bugs.python.org  Fri Mar 12 05:21:36 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 12 Mar 2021 10:21:36 +0000
Subject: [issue43471] Fails to import bz2 on Ubuntu
In-Reply-To: <1615447237.87.0.642854040325.issue43471@roundup.psfhosted.org>
Message-ID: <1615544496.74.0.514668151918.issue43471@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

You are likely did not have headers for bz2 library installed. Read thoughtfully the output of ./configure and make.

See also https://devguide.python.org/setup/#install-dependencies .

----------
nosy: +serhiy.storchaka
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43471>
_______________________________________

From report at bugs.python.org  Fri Mar 12 05:48:33 2021
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Fri, 12 Mar 2021 10:48:33 +0000
Subject: [issue43479] Remove a duplicate comment and assignment in http.client
Message-ID: <1615546113.27.0.0553252720004.issue43479@roundup.psfhosted.org>


New submission from G?ry <gery.ogam at gmail.com>:

Remove a duplicate comment and assignment following the usage of a name already assigned in the http.client standard library.

----------
components: Library (Lib)
messages: 388538
nosy: maggyero
priority: normal
pull_requests: 23597
severity: normal
status: open
title: Remove a duplicate comment and assignment in http.client
type: enhancement
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43479>
_______________________________________

From report at bugs.python.org  Fri Mar 12 05:53:11 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 12 Mar 2021 10:53:11 +0000
Subject: [issue43439] [security] Add audit events on GC functions giving
 access to all Python objects
In-Reply-To: <1615235548.58.0.659993767767.issue43439@roundup.psfhosted.org>
Message-ID: <1615546391.23.0.197625196967.issue43439@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Steve, do you think that makes sense? If so, I will create a batch of PRs to correct it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43439>
_______________________________________

From report at bugs.python.org  Fri Mar 12 10:49:24 2021
From: report at bugs.python.org (Patrick Reader)
Date: Fri, 12 Mar 2021 15:49:24 +0000
Subject: [issue43480] Add .path method/property to tempfile.* for a
 pathlib.Path
Message-ID: <1615564164.94.0.724086636584.issue43480@roundup.psfhosted.org>


New submission from Patrick Reader <pxeger at protonmail.com>:

It would be nice to have a `.path` method or property on `tempfile.NamedTemporaryFile`, `tempfile.TemporaryDirectory` which produces a `pathlib.Path` of their `.name` attribute, so one can use the modern interface directly.

I think a method would be more appropriate than a property because you're explicitly allocating a new object (unless you use `@functools.cached_property` or similar to have a shared object between successive calls)

I can do a PR.

----------
components: Library (Lib)
messages: 388540
nosy: pxeger
priority: normal
severity: normal
status: open
title: Add .path method/property to tempfile.* for a pathlib.Path
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43480>
_______________________________________

From report at bugs.python.org  Fri Mar 12 12:09:18 2021
From: report at bugs.python.org (junyixie)
Date: Fri, 12 Mar 2021 17:09:18 +0000
Subject: [issue40601] [C API] Hide static types from the limited C API
In-Reply-To: <1589235805.82.0.0888479979707.issue40601@roundup.psfhosted.org>
Message-ID: <1615568958.2.0.827893076212.issue40601@roundup.psfhosted.org>


junyixie <xie.junyi at outlook.com> added the comment:

It seems that there is no continued progress for move static type in heap.This will make it impossible to continue to achieve sub interpreters parallel. Are there any plans to try other solutions to the problem?

In my project, i try to slove this problem, It can work, we verify on millions of devices.

1. In typeobject.c add lock to ensure that some functions that modification type are thread-safe
2. and make the PyCFunction and descri object of the Type will never be released. ?Frequently used when load method/attributed, locking affects performance?

Can this change be submitted to cpython?

----------
nosy: +JunyiXie

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40601>
_______________________________________

From report at bugs.python.org  Fri Mar 12 12:34:56 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 12 Mar 2021 17:34:56 +0000
Subject: [issue31427] Add an answer to the Windows FAQ about installing the
 Universal C Runtime
In-Reply-To: <1505217628.46.0.613932244118.issue31427@psf.upfronthosting.co.za>
Message-ID: <1615570496.08.0.960182732678.issue31427@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
title: Proposed addition to Windows FAQ -> Add an answer to the Windows FAQ about installing the Universal C Runtime
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31427>
_______________________________________

From report at bugs.python.org  Fri Mar 12 12:38:28 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 12 Mar 2021 17:38:28 +0000
Subject: [issue21518] Expose RegUnLoadKey in winreg
In-Reply-To: <1400346760.52.0.0203244636304.issue21518@psf.upfronthosting.co.za>
Message-ID: <1615570708.33.0.139324670585.issue21518@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

I added an updated implementation of windows_helper.py to the dependency bpo-22080.

----------
components: +Windows
nosy: +paul.moore
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21518>
_______________________________________

From report at bugs.python.org  Fri Mar 12 12:42:44 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 12 Mar 2021 17:42:44 +0000
Subject: [issue24052] sys.exit(code) returns "success" to the OS for some
 nonzero values of code
In-Reply-To: <1429889353.58.0.941477823236.issue24052@psf.upfronthosting.co.za>
Message-ID: <1615570964.19.0.288478808226.issue24052@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24052>
_______________________________________

From report at bugs.python.org  Fri Mar 12 12:53:42 2021
From: report at bugs.python.org (Mariusz Felisiak)
Date: Fri, 12 Mar 2021 17:53:42 +0000
Subject: [issue20408] memoryview() constructor documentation error
In-Reply-To: <1390823591.54.0.904712473888.issue20408@psf.upfronthosting.co.za>
Message-ID: <1615571622.78.0.14680431273.issue20408@roundup.psfhosted.org>


Change by Mariusz Felisiak <felisiak.mariusz at gmail.com>:


----------
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20408>
_______________________________________

From report at bugs.python.org  Fri Mar 12 12:55:38 2021
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 12 Mar 2021 17:55:38 +0000
Subject: [issue20408] memoryview() constructor documentation error
In-Reply-To: <1390823591.54.0.904712473888.issue20408@psf.upfronthosting.co.za>
Message-ID: <1615571738.63.0.00578050640154.issue20408@roundup.psfhosted.org>


Change by Larry Hastings <larry at hastings.org>:


----------
nosy:  -larry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20408>
_______________________________________

From report at bugs.python.org  Fri Mar 12 13:00:18 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 12 Mar 2021 18:00:18 +0000
Subject: [issue25741] Usual Installation Directory
In-Reply-To: <1448616244.63.0.310461564489.issue25741@psf.upfronthosting.co.za>
Message-ID: <1615572018.58.0.95460897111.issue25741@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

I'm closing this issue as out of date. The tutorial now refers to the py command and also the python3.9 command from the app distribution. The patch's addition of "followed by Enter" after "Control-Z" is still needed, but it's not related to this issue.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25741>
_______________________________________

From report at bugs.python.org  Fri Mar 12 13:43:40 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 12 Mar 2021 18:43:40 +0000
Subject: [issue26882] The Python process stops responding immediately after
 starting
In-Reply-To: <1461917521.83.0.656374171868.issue26882@psf.upfronthosting.co.za>
Message-ID: <1615574620.97.0.346815695615.issue26882@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

Hanging on a synchronous console file during startup shouldn't be an issue in 3.6+, since io._WindowsConsoleIO doesn't support seeking, but it could still be an issue with legacy mode, which uses io.FileIO. I'm marking this as a duplicate of bpo-34780, which has more information. It's basically the same problem that seeking should only be supported for files opened for physical disks, volumes, and regular data files in mounted filesystems -- for which its meaningful, useful, and not vulnerable to hanging indefinitely if the file is blocked on a synchronous I/O request (e.g. a read request from a pipe or console input, which might never complete).

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> [Windows] Hang on startup if stdin refers to a pipe with an outstanding concurrent operation on Windows

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26882>
_______________________________________

From report at bugs.python.org  Fri Mar 12 13:46:27 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 12 Mar 2021 18:46:27 +0000
Subject: [issue40601] [C API] Hide static types from the limited C API
In-Reply-To: <1589235805.82.0.0888479979707.issue40601@roundup.psfhosted.org>
Message-ID: <1615574787.17.0.966070051003.issue40601@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The Steering Council asked for a PEP to explain why static types should be converted to heap types.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40601>
_______________________________________

From report at bugs.python.org  Fri Mar 12 13:46:37 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 12 Mar 2021 18:46:37 +0000
Subject: [issue40601] [C API] Hide static types from the limited C API
In-Reply-To: <1589235805.82.0.0888479979707.issue40601@roundup.psfhosted.org>
Message-ID: <1615574797.58.0.629901689912.issue40601@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I plan to write such PEP soon.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40601>
_______________________________________

From report at bugs.python.org  Fri Mar 12 14:40:47 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Mar 2021 19:40:47 +0000
Subject: [issue43198] One operation on sets < 1/100th as efficient in 3.9 than
 before
In-Reply-To: <1613002507.49.0.48232719319.issue43198@roundup.psfhosted.org>
Message-ID: <1615578047.49.0.459026335669.issue43198@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: Operations on sets more than hundred times less efficient with python3.9 than with previous versions -> One operation on sets < 1/100th as efficient in 3.9 than before

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43198>
_______________________________________

From report at bugs.python.org  Fri Mar 12 14:47:11 2021
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Mar 2021 19:47:11 +0000
Subject: [issue43458] Tutorial should mention about variable scope in
 try/except/finally
In-Reply-To: <1615352911.49.0.844400259332.issue43458@roundup.psfhosted.org>
Message-ID: <1615578431.34.0.601877355405.issue43458@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> added the comment:

The only blocks that create scopes are modules, class and functions.
if, try, with, for, while, etc are blocks but not new scopes.

For the tutorial it could be nice to have an explicit mention and example of this.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43458>
_______________________________________

From report at bugs.python.org  Fri Mar 12 15:02:29 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 12 Mar 2021 20:02:29 +0000
Subject: [issue34780] [Windows] Hang on startup if stdin refers to a pipe with
 an outstanding concurrent operation on Windows
In-Reply-To: <1537732835.69.0.956365154283.issue34780@psf.upfronthosting.co.za>
Message-ID: <1615579349.07.0.0711650342898.issue34780@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

Console input handles pose the same risk of hanging indefinitely when io.FileIO is used in legacy standard I/O mode (i.e. PYTHONLEGACYWINDOWSSTDIO).

Seeking could simply be disallowed on all files that aren't FILE_TYPE_DISK. For example, change portable_lseek() in Modules/_io/fileio.c to check the file type:

    if (GetFileType((HANDLE)_get_osfhandle(fd)) != FILE_TYPE_DISK) {
        errno = ESPIPE;
        res = -1;
    } else {
        res = _lseeki64(fd, pos, whence);
    }

----------
versions: +Python 3.10 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34780>
_______________________________________

From report at bugs.python.org  Fri Mar 12 15:40:47 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 12 Mar 2021 20:40:47 +0000
Subject: [issue40540] inconstent stdin buffering/seeking behaviour
In-Reply-To: <1588804378.46.0.584037601686.issue40540@roundup.psfhosted.org>
Message-ID: <1615581647.68.0.812499306097.issue40540@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> seekable() returns True on pipe objects in Windows

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40540>
_______________________________________

From report at bugs.python.org  Fri Mar 12 15:42:28 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 12 Mar 2021 20:42:28 +0000
Subject: [issue34780] [Windows] Hang on startup if stdin refers to a pipe with
 an outstanding concurrent operation on Windows
In-Reply-To: <1537732835.69.0.956365154283.issue34780@psf.upfronthosting.co.za>
Message-ID: <1615581748.65.0.954427410561.issue34780@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

If non-disk files are made non-seekable in Windows, this will also resolve bpo-42602.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34780>
_______________________________________

From report at bugs.python.org  Fri Mar 12 15:48:22 2021
From: report at bugs.python.org (Saiyang Gou)
Date: Fri, 12 Mar 2021 20:48:22 +0000
Subject: [issue43439] [security] Add audit events on GC functions giving
 access to all Python objects
In-Reply-To: <1615235548.58.0.659993767767.issue43439@roundup.psfhosted.org>
Message-ID: <1615582102.02.0.844290944949.issue43439@roundup.psfhosted.org>


Saiyang Gou <gousaiyang223 at gmail.com> added the comment:

In addition to the consistency with existing audit hook signatures, there may also be another benefit of wrapping it with a tuple of length 1. If gc.get_referrers or gc.get_referents happens to gain a new keyword-only argument in the future, we may need to add the new argument to the hook args. Extending the `(objs,)` tuple to `(objs, new_kwarg)` is a bit more elegant than appending the `new_kwarg` to the end of the `objs` tuple itself (considering a hook function which tries to be compatible with both the old and the new signature).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43439>
_______________________________________

From report at bugs.python.org  Fri Mar 12 15:49:24 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 12 Mar 2021 20:49:24 +0000
Subject: [issue11429] ctypes is highly eclectic in its raw-memory support
In-Reply-To: <1299484141.33.0.394671210882.issue11429@psf.upfronthosting.co.za>
Message-ID: <1615582164.37.0.655850337736.issue11429@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11429>
_______________________________________

From report at bugs.python.org  Fri Mar 12 16:05:18 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 12 Mar 2021 21:05:18 +0000
Subject: [issue29844] Windows Python installers not installing DLL to
 System32/SysWOW64
In-Reply-To: <1489831433.22.0.028475249754.issue29844@psf.upfronthosting.co.za>
Message-ID: <1615583118.28.0.283050421145.issue29844@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

"Tools/msi/README.txt" still references "%SystemRoot%\System32" and "%SystemRoot%\SysWOW64" as the location of "python3[x].dll" for all-users installs. The containing paragraph can be removed. Move the lines for ".\python3x.dll" and ".\python3.dll" unconditionally into the installation directory listing. Maybe also add ".\vcruntime140[_1].dll" to the listing.

----------
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29844>
_______________________________________

From report at bugs.python.org  Fri Mar 12 16:09:58 2021
From: report at bugs.python.org (Anup Parikh)
Date: Fri, 12 Mar 2021 21:09:58 +0000
Subject: [issue43334] venv does not install libpython
In-Reply-To: <1614379216.7.0.137032053148.issue43334@roundup.psfhosted.org>
Message-ID: <1615583398.74.0.466417106007.issue43334@roundup.psfhosted.org>


Anup Parikh <anuppari at gmail.com> added the comment:

A typical python installation includes libpython libraries that C extensions can link to. Creating virtual environments with venv normally creates a replica of a python installation directory, including all the built in python modules. However, it doesn't seem to copy over the libpython libraries, so C extensions built with a venv activated can't seem to find the libpython (.so, .a, .dll) file to link against.

For example, compare the installation directory of python with the venv directory. The libpython .so/.a/.dll files are missing in the venv

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43334>
_______________________________________

From report at bugs.python.org  Fri Mar 12 16:11:30 2021
From: report at bugs.python.org (Anup Parikh)
Date: Fri, 12 Mar 2021 21:11:30 +0000
Subject: [issue43334] venv does not install libpython
In-Reply-To: <1614379216.7.0.137032053148.issue43334@roundup.psfhosted.org>
Message-ID: <1615583490.51.0.18812642883.issue43334@roundup.psfhosted.org>


Anup Parikh <anuppari at gmail.com> added the comment:

Also, at least on windows, the C-API header files are also missing from the venv

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43334>
_______________________________________

From report at bugs.python.org  Fri Mar 12 16:11:34 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 12 Mar 2021 21:11:34 +0000
Subject: [issue22781] ctypes: Differing results between Python and C.
In-Reply-To: <1414862185.49.0.654024451078.issue22781@psf.upfronthosting.co.za>
Message-ID: <1615583494.22.0.53342807721.issue22781@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22781>
_______________________________________

From report at bugs.python.org  Fri Mar 12 16:11:59 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 12 Mar 2021 21:11:59 +0000
Subject: [issue15453] ctype with packed bitfields does not match native
 compiler
In-Reply-To: <1343287497.79.0.127552089432.issue15453@psf.upfronthosting.co.za>
Message-ID: <1615583519.99.0.412727072189.issue15453@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Ctypes Packing Bitfields Incorrectly - Linux

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15453>
_______________________________________

From report at bugs.python.org  Fri Mar 12 16:21:25 2021
From: report at bugs.python.org (Adrian Freund)
Date: Fri, 12 Mar 2021 21:21:25 +0000
Subject: [issue42128] Structural Pattern Matching (PEP 634)
In-Reply-To: <1603466540.96.0.7677855399.issue42128@roundup.psfhosted.org>
Message-ID: <1615584085.29.0.741353599987.issue42128@roundup.psfhosted.org>


Adrian Freund <git at freundtech.com> added the comment:

For the last few days I've been working with pattern matching and it's ast for a bit, while trying to add support for it to mypy.

During this I noticed an inconsistency in the ast:

ast.MatchAs has an attribute name which is of type identifier (in C) and type str (in python).

This seams really inconsistent with the rest of the ast, where identifiers are always wrapped in a ast.Name object. The only other exception to this is ast.Attribute.

Judging from Grammar/python.gram this seems deliberate:

as_pattern[expr_ty]:
    | pattern=or_pattern 'as' target=capture_pattern {
        _Py_MatchAs(pattern, target->v.Name.id, EXTRA) }

Could someone shed some light on why MatchAs directly references an identifier instead of an ast.Name?

----------
nosy: +freundTech

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42128>
_______________________________________

From report at bugs.python.org  Fri Mar 12 16:24:09 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 12 Mar 2021 21:24:09 +0000
Subject: [issue29657] os.symlink: FileExistsError shows wrong message
In-Reply-To: <1488099144.41.0.738429373533.issue29657@psf.upfronthosting.co.za>
Message-ID: <1615584249.58.0.76335123097.issue29657@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
components: +Extension Modules, Interpreter Core -Library (Lib)
stage: patch review -> 
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29657>
_______________________________________

From report at bugs.python.org  Fri Mar 12 16:30:32 2021
From: report at bugs.python.org (Batuhan Taskaya)
Date: Fri, 12 Mar 2021 21:30:32 +0000
Subject: [issue42128] Structural Pattern Matching (PEP 634)
In-Reply-To: <1603466540.96.0.7677855399.issue42128@roundup.psfhosted.org>
Message-ID: <1615584632.85.0.852512197446.issue42128@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:

> This seams really inconsistent with the rest of the ast, where identifiers are always wrapped in a ast.Name object. The only other exception to this is ast.Attribute.

import ... as <identifier>
from ... import ... as <identifier>
try:
   ...
except ... as <identifier>:
   ...

global <identifier>
nonlocal <identifier>
x(<identifier>=...)

All <identifier>s above are represented as strings. If <identifier> is guaranteed to be a single name, then it makes sense to just use an identifier instead of wrapping it with Name(). The reason that other stuff like "with ... as <expr>" uses <expr> instead of <identifier> is that you can use extended assignment targets (such as unpacking a tuple) over there. 

This rule applies to all other stuff, except for NamedExprs. Which I believe it is because the restriction might lift in the future, but now they are limited to only keep Name()s. 

I don't personally know why Brandt choosed to use identifier, though I'm a +1 on the current approach.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42128>
_______________________________________

From report at bugs.python.org  Fri Mar 12 16:31:19 2021
From: report at bugs.python.org (Florian Bruhin)
Date: Fri, 12 Mar 2021 21:31:19 +0000
Subject: [issue43463] typing.get_type_hints with TYPE_CHECKING imports /
 getting hints for single argument
In-Reply-To: <1615387121.09.0.336024174905.issue43463@roundup.psfhosted.org>
Message-ID: <1615584679.6.0.785204537683.issue43463@roundup.psfhosted.org>


Florian Bruhin <python.org at the-compiler.org> added the comment:

I suppose returning the string unchanged would work as well. However, "Errors should never pass silently." :)

Perhaps that with a ignore_nameerror=True or switch or so would work?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43463>
_______________________________________

From report at bugs.python.org  Fri Mar 12 16:34:20 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 12 Mar 2021 21:34:20 +0000
Subject: [issue29256] Windows select() errors out when given no fds to select
 on, which breaks SelectSelector
In-Reply-To: <1484264538.85.0.902649207203.issue29256@psf.upfronthosting.co.za>
Message-ID: <1615584860.82.0.898441663274.issue29256@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29256>
_______________________________________

From report at bugs.python.org  Fri Mar 12 16:40:42 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 12 Mar 2021 21:40:42 +0000
Subject: [issue34780] [Windows] Hang on startup if stdin refers to a pipe with
 an outstanding concurrent operation on Windows
In-Reply-To: <1537732835.69.0.956365154283.issue34780@psf.upfronthosting.co.za>
Message-ID: <1615585242.55.0.186145367366.issue34780@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34780>
_______________________________________

From report at bugs.python.org  Fri Mar 12 16:41:22 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 12 Mar 2021 21:41:22 +0000
Subject: [issue29256] Windows select() errors out when given no fds to select
 on, which breaks SelectSelector
In-Reply-To: <1484264538.85.0.902649207203.issue29256@psf.upfronthosting.co.za>
Message-ID: <1615585282.1.0.303718327508.issue29256@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29256>
_______________________________________

From report at bugs.python.org  Fri Mar 12 16:44:37 2021
From: report at bugs.python.org (Chris Morton)
Date: Fri, 12 Mar 2021 21:44:37 +0000
Subject: [issue43481] PyEval_EvalCode() namespace issue not observed in Python
 2.7.
Message-ID: <1615585477.01.0.106665214672.issue43481@roundup.psfhosted.org>


New submission from Chris Morton <chrisgmorton at yahoo.com>:

Compiling (Window 10, MSVS 16):

#include <Python.h>

int main(int argc, char* argv[])
{
    const char* code = "c=[1,2,3,4]\nd={'list': [c[i] for i in range(len(c))]}\nprint(d)\n";

    Py_Initialize();

    PyObject* pycode = Py_CompileString(code, "", Py_file_input );   
    PyObject* main_module = PyImport_AddModule("__main__");
    PyObject* global_dict = PyModule_GetDict(main_module);
    PyObject* local_dict = PyDict_New();
    
    PyEval_EvalCode(pycode, global_dict, local_dict);  // (PyCodeObject*) pycode in Python 2.7
    
    Py_Finalize();

    return 0;

and executing yields:

Traceback (most recent call last):
  File "", line 2, in <module>
  File "", line 2, in <listcomp>
NameError: name 'c' is not defined

While not particularly clever python code, it is not clear why the reference c is not in scope having previously been defined. Replacing the clumsy list comprehension using range() with c[:] or [ci for ci in c] produces the expected result:

{'list': [1, 2, 3, 4]}

This issue is not observed with Python 2.7 (.18).

----------
components: C API
messages: 388557
nosy: chrisgmorton
priority: normal
severity: normal
status: open
title: PyEval_EvalCode() namespace issue not observed in Python 2.7.
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43481>
_______________________________________

From report at bugs.python.org  Fri Mar 12 17:09:47 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Mar 2021 22:09:47 +0000
Subject: [issue43411] wm_manage fails with ttk.Frame
In-Reply-To: <1614972319.75.0.638524894464.issue43411@roundup.psfhosted.org>
Message-ID: <1615586987.94.0.404785764017.issue43411@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

You are confusing the widget path component, an arbitrary string of chars other than the separator '.', with the English word 'frame', which is also a tk command.  In tk docs, 'a *frame*' is a widget (tk window) created with the 'frame' command.

By default, tk gives each widget(window) a unique but meaningless string of digits as its path component.  A user can override this by giving an explicit name option on creation.  

A few years ago, tkinter started always overriding the tk default with a  readable name.  Serhiy and I agreed on using a '!' prefix since it was unlikely though not impossible to be used by tkinter users.  We must have agreed on not specifically flagging ttk widgets in the path component, as opposed to the widget name (see below).  A numerical suffix is added to duplicates.  The system is not perfect, but overall we prefer it to the tk digit sequences, in spite of the following possible confusion.

>>> c = ttk.Combobox(r, name='!frame')
>>> c
<tkinter.ttk.Combobox object .!frame>
>>> c.widgetName
'ttk::combobox'
>>> c.master.wm_manage(c)
...
_tkinter.TclError: window ".!frame" is not manageable: must be a frame, labelframe or toplevel

For debugging in 'python -i' or IDLE 'run module' mode, one can followup by checking the passed-in widget's widgetName if it is not otherwise obvious.

If you want tk or its tk wm_manage doc at https://www.tcl.tk/man/tcl8.6/TkCmd/wm.htm#M53 changed, you have to ask the tcl.tk people.  Extremely unlikely I suspect.  I presume that there are technical reasons why a ttk Frame is not a drop-in replacement for a tk Frame in this context.  And since a *ttk::frame* is clearly different from a *frame*, the doc is clear enough.  For all other commands, the window can only be a *toplevel*, so the exception for wm manage is an extension to frame and labelframe, rather than a restriction.

Our 3-paragraph doc for the corresponding Wm class does not discuss the individual methods but implicitly defers to the tkinter.__init__ code and the tk doc.

Our ttk doc does not discuss the ttk widgets that are essentially copies of tk widgets except the mostly documented differences.  So there is not  a good place to say anything and I am dubious that we should.

So I think we should close as 'not a bug' unless Serhiy disagrees.

----------
nosy: +serhiy.storchaka, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43411>
_______________________________________

From report at bugs.python.org  Fri Mar 12 17:11:40 2021
From: report at bugs.python.org (Chris Morton)
Date: Fri, 12 Mar 2021 22:11:40 +0000
Subject: [issue43482] PyAddPendingCall Function Never Called in 3.8,
 works in 3.6
Message-ID: <1615587100.2.0.130476300444.issue43482@roundup.psfhosted.org>


New submission from Chris Morton <chrisgmorton at yahoo.com>:

Building code on Mac OSX or Linux Ubuntu 16.04

#include <Python.h>
#include <thread>
#include <chrono>
#include <iostream>

// MacOSX build:
// g++ stop.cpp -I <prod root dir>/include/pythonX.X -L <prod root dir>/lib -lpythonX.X -o stop
// Linuxe requires addtional linkage:
// -lpthread

void RunPythonScript()
{
    PyRun_SimpleString("# import sys \n"
                       "import time \n"
                       "# sys.setcheckinterval(-1) \n"
                       "while True: \n"
                       "    print('Running!') \n"
                       "    time.sleep(1) \n"
                       );

    std::cout << "Terminating Python Interpreter." << std::endl;
}

int Stop(void *)
{
    std::cout << "We threw an exception." <<std::endl;    
    PyErr_SetInterrupt();
    PyErr_SetString(PyExc_RuntimeError, "Stop Python Execution.");
    return -1;

}

int main (int argc, char *argv[])
{

    Py_Initialize(); // The Python Interpreter must be created in the main thread.
    
    std::thread th(&RunPythonScript);    // Now execute our python scipt in a thread.

    std::cout << "Python has started!" << std::endl;    
    std::this_thread::sleep_for(std::chrono::seconds(5));
    
    std::cout << "Asking Python to exit." << std::endl;

    PyGILState_STATE state = PyGILState_Ensure();    
    int r = Py_AddPendingCall(&Stop, NULL); // inject our Stop routine
    std::cout << r <<std::endl;
    PyGILState_Release(state);
    
    th.join(); // Wait for the thread to catch up. 

    Py_Finalize();

    std::cout << "Exiting Main Function." << std::endl;
    
    std::this_thread::sleep_for(std::chrono::seconds(2));
    
return 0;
}

Linking against 3.6 and executing leads to the successful interruption of Python code execution:

Python has started!
Running!
Running!
Running!
Running!
Running!
Asking Python to exit.
0
We threw an exception.
Traceback (most recent call last):
  File "<string>", line 6, in <module>
RuntimeError: Stop Python Execution.
Terminating Python Interpreter.
Exiting Main Function.

The Stop function is never called with the same code linked against Python 3.8.

----------
components: C API
messages: 388559
nosy: chrisgmorton
priority: normal
severity: normal
status: open
title: PyAddPendingCall Function Never Called in 3.8, works in 3.6
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43482>
_______________________________________

From report at bugs.python.org  Fri Mar 12 17:12:53 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Mar 2021 22:12:53 +0000
Subject: [issue43412] object.h -Wcast-qual warning
In-Reply-To: <1614982361.61.0.858230879301.issue43412@roundup.psfhosted.org>
Message-ID: <1615587173.2.0.936883503686.issue43412@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Victor, the apparent 3.10 regression is from your commit.

----------
nosy: +terry.reedy, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43412>
_______________________________________

From report at bugs.python.org  Fri Mar 12 17:22:28 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Mar 2021 22:22:28 +0000
Subject: [issue43418] FTPLib module crashes when server returns byte message
 instead of string
In-Reply-To: <1615037606.06.0.879407636626.issue43418@roundup.psfhosted.org>
Message-ID: <1615587748.79.0.958065396225.issue43418@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

3.7 only gets security fixes.  Please verify that this is an issue with 3.10, or at least 3.9, and give a reproducible test case.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43418>
_______________________________________

From report at bugs.python.org  Fri Mar 12 17:53:49 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Mar 2021 22:53:49 +0000
Subject: [issue43418] FTPLib error when server returns byte message instead of
 string
In-Reply-To: <1615037606.06.0.879407636626.issue43418@roundup.psfhosted.org>
Message-ID: <1615589629.95.0.308223956158.issue43418@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

An exception exit is not a 'crash' for this tracker.  The latter is an indefinite hang or a no-exception stackoverflow or the Windows equivalent error box (or worse).  The linked issue appears to show an exception exit.

----------
title: FTPLib module crashes when server returns byte message instead of string -> FTPLib error when server returns byte message instead of string
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43418>
_______________________________________

From report at bugs.python.org  Fri Mar 12 18:03:09 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Mar 2021 23:03:09 +0000
Subject: [issue43420] Optimize rational arithmetics
In-Reply-To: <1615040297.73.0.541090358152.issue43420@roundup.psfhosted.org>
Message-ID: <1615590189.19.0.841083213067.issue43420@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

A possible resolution to this issue might be augmenting https://docs.python.org/3/library/fractions.html#module-fractions
with a short paragraph or section on alternative implementations noting that there is a tradeoff between speed and complexity (and assured correctness).  If sympy has faster rationals, list that, and any other python-accessible alternative we have confidence in.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43420>
_______________________________________

From report at bugs.python.org  Fri Mar 12 18:13:50 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 12 Mar 2021 23:13:50 +0000
Subject: [issue15244] Support for opening files with FILE_SHARE_DELETE on
 Windows
In-Reply-To: <1341342894.98.0.559958462018.issue15244@psf.upfronthosting.co.za>
Message-ID: <1615590830.57.0.818754035299.issue15244@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

Deleting a file in Windows 10 has been updated to try a POSIX-style delete. For a POSIX delete, the filesystem unlinks the file even it's open, whereas a classic delete only unlinks a 'deleted' file when it's closed. The filesystem has to support it. NTFS does, which is the most important because the system drive is NTFS. This makes supporting FILE_SHARE_DELETE a more attractive option. 

That said, there are sill significant limits. Memory-mapped files can't be deleted (renamed, yes, but not removed). Also, most programs don't share delete access on their opens, which means they can't open a file that's currently open with delete access (e.g. NamedTemporaryFile), and their open files can't be deleted.

----------
components: +IO, Windows -Library (Lib)
nosy: +paul.moore
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15244>
_______________________________________

From report at bugs.python.org  Fri Mar 12 18:16:06 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 12 Mar 2021 23:16:06 +0000
Subject: [issue27827] pathlib is_reserved fails for some reserved paths on
 Windows
In-Reply-To: <1471858428.08.0.847859442583.issue27827@psf.upfronthosting.co.za>
Message-ID: <1615590966.52.0.619766141208.issue27827@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
stage: needs patch -> 
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27827>
_______________________________________

From report at bugs.python.org  Fri Mar 12 18:19:22 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Mar 2021 23:19:22 +0000
Subject: [issue43422] Revert _decimal C API changes
In-Reply-To: <1615043906.44.0.566874098139.issue43422@roundup.psfhosted.org>
Message-ID: <1615591162.29.0.673639196377.issue43422@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

skrah is still a bpo user with an CLA-signed account linked to his github account.  So he can post here and, I believe, open a PR as a contributor.  But if, under the current circumstances, he feels more comfortable using Antoine as a go between, then I thank Antoine for doing so.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43422>
_______________________________________

From report at bugs.python.org  Fri Mar 12 18:23:24 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 12 Mar 2021 23:23:24 +0000
Subject: [issue37612] os.link(..., follow_symlinks=True) broken on Linux
In-Reply-To: <1563404695.9.0.284402565462.issue37612@roundup.psfhosted.org>
Message-ID: <1615591404.52.0.0757539506559.issue37612@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
components: +Extension Modules -Library (Lib)
versions: +Python 3.10 -Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37612>
_______________________________________

From report at bugs.python.org  Fri Mar 12 18:25:54 2021
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 12 Mar 2021 23:25:54 +0000
Subject: [issue27820] Possible bug in smtplib when initial_response_ok=False
In-Reply-To: <1471739698.94.0.271523306415.issue27820@psf.upfronthosting.co.za>
Message-ID: <1615591554.87.0.90071896619.issue27820@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:


New changeset 7591d9455eb37525c832da3d65e1a7b3e6dbf613 by Pandu E POLUAN in branch 'master':
bpo-27820: Fix AUTH LOGIN logic in smtplib.SMTP (GH-24118)
https://github.com/python/cpython/commit/7591d9455eb37525c832da3d65e1a7b3e6dbf613


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27820>
_______________________________________

From report at bugs.python.org  Fri Mar 12 18:26:14 2021
From: report at bugs.python.org (miss-islington)
Date: Fri, 12 Mar 2021 23:26:14 +0000
Subject: [issue27820] Possible bug in smtplib when initial_response_ok=False
In-Reply-To: <1471739698.94.0.271523306415.issue27820@psf.upfronthosting.co.za>
Message-ID: <1615591574.28.0.689026117726.issue27820@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: +23598
pull_request: https://github.com/python/cpython/pull/24832

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27820>
_______________________________________

From report at bugs.python.org  Fri Mar 12 18:38:07 2021
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 12 Mar 2021 23:38:07 +0000
Subject: [issue27820] Possible bug in smtplib when initial_response_ok=False
In-Reply-To: <1471739698.94.0.271523306415.issue27820@psf.upfronthosting.co.za>
Message-ID: <1615592287.36.0.397684195625.issue27820@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
pull_requests: +23599
pull_request: https://github.com/python/cpython/pull/24833

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27820>
_______________________________________

From report at bugs.python.org  Fri Mar 12 18:43:03 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 12 Mar 2021 23:43:03 +0000
Subject: [issue35883] Change invalid unicode characters to replacement
 characters in argv
In-Reply-To: <1549040138.25.0.646545491344.issue35883@roundup.psfhosted.org>
Message-ID: <1615592583.0.0.418525709329.issue35883@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
components: +Unicode
nosy: +ezio.melotti, vstinner
versions:  -Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35883>
_______________________________________

From report at bugs.python.org  Fri Mar 12 18:48:31 2021
From: report at bugs.python.org (Adrian Freund)
Date: Fri, 12 Mar 2021 23:48:31 +0000
Subject: [issue42128] Structural Pattern Matching (PEP 634)
In-Reply-To: <1603466540.96.0.7677855399.issue42128@roundup.psfhosted.org>
Message-ID: <1615592911.47.0.0279476252523.issue42128@roundup.psfhosted.org>


Adrian Freund <git at freundtech.com> added the comment:

Thanks for the response. Looks like I overlooked the imports, global, nonlocal, ... because I only searched for usages of identifier, but they use lists of identifiers.

In that case I agree that it isn't inconsistent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42128>
_______________________________________

From report at bugs.python.org  Fri Mar 12 18:50:11 2021
From: report at bugs.python.org (Steve Dower)
Date: Fri, 12 Mar 2021 23:50:11 +0000
Subject: [issue43439] [security] Add audit events on GC functions giving
 access to all Python objects
In-Reply-To: <1615235548.58.0.659993767767.issue43439@roundup.psfhosted.org>
Message-ID: <1615593011.7.0.503490563142.issue43439@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Passing a tuple as "O" just means it gets passed as-is, without wrapping it again. And yeah, I thought that was right here, but it's not. I didn't realise it's a varargs argument. So yeah, it should be wrapped again so that only a single argument is being passed to the hooks.

Alternatively, raising one event for each object would also be valid. These functions behave identically for "f(a, b)" and "f(a) + f(b)", so raising the event for each object before traversing it would simplify hooks (but have more of a performance impact... which I suspect is totally irrelevant here anyway, so I'd be +1.1 on this approach vs. +1 on passing the args as a single argument).

If new arguments are added later, we need to add new events. Defining event schemas as "arbitrary arguments that may change is the future" is totally against the intended design.

----------
resolution: fixed -> 
stage: resolved -> needs patch
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43439>
_______________________________________

From report at bugs.python.org  Fri Mar 12 18:55:44 2021
From: report at bugs.python.org (Steve Dower)
Date: Fri, 12 Mar 2021 23:55:44 +0000
Subject: [issue43438] [doc] sys.addaudithook() documentation should be more
 explicit on its limitations
In-Reply-To: <1615235174.36.0.713670774369.issue43438@roundup.psfhosted.org>
Message-ID: <1615593344.02.0.483248792999.issue43438@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

If someone offers a patch for replacing the list of per-interpreter hooks with something not easily discoverable via gc, I'm sure we'd take it. It's all internal, so just hiding it from the list of bases should be fine (there should never be more than one reference), but turning it into a new form of dynamically expanding array/list would also work, providing whoever reviews it doesn't think it's adding too much complexity/instability.

But file that as a separate issue, please. It's somewhat debatable, while fixing the docs _needs_ to happen. (And I will get to it eventually if nobody else does, but I'm just as happy to review someone else's contribution. And MUCH happier to review a contribution than to argue about it on the tracker :) )

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43438>
_______________________________________

From report at bugs.python.org  Fri Mar 12 18:55:59 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 12 Mar 2021 23:55:59 +0000
Subject: [issue27886] Docs: the difference between rename and replace is not
 obvious
In-Reply-To: <1472411232.42.0.47360960084.issue27886@psf.upfronthosting.co.za>
Message-ID: <1615593359.22.0.933297169264.issue27886@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
Removed message: https://bugs.python.org/msg273845

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27886>
_______________________________________

From report at bugs.python.org  Fri Mar 12 19:14:05 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 13 Mar 2021 00:14:05 +0000
Subject: [issue27886] Docs: the difference between Path.rename() and
 Path.replace() is not obvious
In-Reply-To: <1472411232.42.0.47360960084.issue27886@psf.upfronthosting.co.za>
Message-ID: <1615594445.87.0.913061860683.issue27886@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

The pathlib documentation of Path.rename() says "[o]n Unix, if target exists and is a file, it will be replaced silently if the user has permission". This leaves the behavior on Windows in question. The reader has to scroll down to the correspondence table to link to the documentation of os.rename() and presume that Path.rename() also raises FileExistsError for this case. The Path.rename() docs should just state upfront that "[o]n Windows, if target exists, FileExistsError will be raised".

----------
components: +Library (Lib)
title: Docs: the difference between rename and replace is not obvious -> Docs: the difference between Path.rename() and Path.replace() is not obvious
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27886>
_______________________________________

From report at bugs.python.org  Fri Mar 12 19:15:33 2021
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 13 Mar 2021 00:15:33 +0000
Subject: [issue27820] Possible bug in smtplib when initial_response_ok=False
In-Reply-To: <1471739698.94.0.271523306415.issue27820@psf.upfronthosting.co.za>
Message-ID: <1615594533.27.0.0143942632529.issue27820@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:


New changeset 32717b982d3347e30ae53eb434e2a32e0d03d51e by Miss Islington (bot) in branch '3.9':
bpo-27820: Fix AUTH LOGIN logic in smtplib.SMTP (GH-24118) (#24832)
https://github.com/python/cpython/commit/32717b982d3347e30ae53eb434e2a32e0d03d51e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27820>
_______________________________________

From report at bugs.python.org  Fri Mar 12 19:39:55 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 13 Mar 2021 00:39:55 +0000
Subject: [issue43425] test_peg_generator.test_c_parser emits
 DeprecationWarning due to distutils
In-Reply-To: <1615093629.58.0.305422387924.issue43425@roundup.psfhosted.org>
Message-ID: <1615595995.85.0.941785278769.issue43425@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Steve, PEP 632 lacks a reference to the SC acceptance thereof.  Could you add one?
https://mail.python.org/archives/list/python-dev at python.org/thread/TXU6TVOMBLQU3SV57DMMOA5Y2E67AW7P/
And can you verify my interpretation below?

The warning is correct as to removal.  PEP 632 says, perhaps a bit tersely, that when the 3.11 branch is established for 3.11.0b1 and master/main becomes the 3.12.0a development branch, disutils/* be no longer be installed as part of the stdlib (ie, in /Lib).  At that point, 'import disutils' will cease working in installed CPython, outside of a cpython repository.  Although this could be worked around by catching the import error and skipping disutils-dependent tests, the dependency should better be removed, if possible, before 3.12.0a.

The PEP gives no timetable for doing so, and anticipates separate PRs like this.

It further says that when "the CPython build process no longer depends on distutils being in the standard library, the entire Lib/distutils directory and Lib/test/test_distutils.py file will be removed from the repository."  Leaving it deprecated but present was rejected.

Part of the extensive discussion at https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134/128 was about possibly putting parts of disutiles under /Tools and replacing 'import disutils' with a reference to <python dir>/Tools/distutiles/whatever.  If this is done for tests, the access and use has to be conditional.  Our Windows installer only installs 4 or 21 Tools subdirectories thought appropriate for uses and others may include less, and maybe omit Tools altogether.

Karthikeyan posted the opening of this and another issue 5 days ago on #41281, with no comment so far.

----------
nosy: +steve.dower, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43425>
_______________________________________

From report at bugs.python.org  Fri Mar 12 19:51:00 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 13 Mar 2021 00:51:00 +0000
Subject: [issue43439] [security] Add audit events on GC functions giving
 access to all Python objects
In-Reply-To: <1615235548.58.0.659993767767.issue43439@roundup.psfhosted.org>
Message-ID: <1615596660.76.0.313968088623.issue43439@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I think I prefer to raise a single event, because it match more closely the actual call, is a bit faster and more straighfoward. I will create a PR soon

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43439>
_______________________________________

From report at bugs.python.org  Fri Mar 12 19:52:40 2021
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 13 Mar 2021 00:52:40 +0000
Subject: [issue42967] [CVE-2021-23336] urllib.parse.parse_qsl(): Web cache
 poisoning - `; ` as a query args separator
In-Reply-To: <1611068809.96.0.58823274544.issue42967@roundup.psfhosted.org>
Message-ID: <1615596760.95.0.590812021984.issue42967@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Petr, 

On 

> the `separator` argument now allows multi-character strings, so you can parse 'a=1<SPLIT>b=2' with separator='<SPLIT>'. Was this intentional?

No, this was not intentional. The separator arg was just coice, for  compatibility, if some wanted to use `;` like the some URLs that were shared as use case. We didn't restrict about what was allowed or length of the separator.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42967>
_______________________________________

From report at bugs.python.org  Fri Mar 12 19:53:22 2021
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 13 Mar 2021 00:53:22 +0000
Subject: [issue27820] Possible bug in smtplib when initial_response_ok=False
In-Reply-To: <1471739698.94.0.271523306415.issue27820@psf.upfronthosting.co.za>
Message-ID: <1615596802.52.0.63869121671.issue27820@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:


New changeset 8cadc2c9cacfa1710cb5ca28a70f7782cacf09aa by Senthil Kumaran in branch '3.8':
[3.8] bpo-27820: Fix AUTH LOGIN logic in smtplib.SMTP (GH-24118) (#24833)
https://github.com/python/cpython/commit/8cadc2c9cacfa1710cb5ca28a70f7782cacf09aa


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27820>
_______________________________________

From report at bugs.python.org  Fri Mar 12 19:53:52 2021
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 13 Mar 2021 00:53:52 +0000
Subject: [issue27820] Possible bug in smtplib when initial_response_ok=False
In-Reply-To: <1471739698.94.0.271523306415.issue27820@psf.upfronthosting.co.za>
Message-ID: <1615596832.07.0.0533384153072.issue27820@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27820>
_______________________________________

From report at bugs.python.org  Fri Mar 12 19:57:00 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 13 Mar 2021 00:57:00 +0000
Subject: [issue43461] Tottime column for cprofile output does not add up
In-Reply-To: <1615379037.48.0.966046679388.issue43461@roundup.psfhosted.org>
Message-ID: <1615597020.5.0.19594087719.issue43461@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

An actual example might help get an answer.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43461>
_______________________________________

From report at bugs.python.org  Fri Mar 12 19:58:09 2021
From: report at bugs.python.org (Martin Cooper)
Date: Sat, 13 Mar 2021 00:58:09 +0000
Subject: [issue43411] wm_manage fails with ttk.Frame
In-Reply-To: <1614972319.75.0.638524894464.issue43411@roundup.psfhosted.org>
Message-ID: <1615597089.68.0.233889817331.issue43411@roundup.psfhosted.org>


Martin Cooper <mfncooper at gmail.com> added the comment:

I think you are confusing the perspective of the implementor with that of the typical developer _using_ the toolkit without reading through its source code.

In my tkinter applications, I pretty much always use ttk widgets where they are available. This is largely because of the consistent background colour (on a Mac, at least). In the case of Frame specifically, a regular Frame has a white background that doesn't go well with ttk widgets, while a ttk.Frame has a grey background. So naturally, when I started trying to implement a pop-out window, I was using ttk.Frame everywhere.

Then, when I started getting the error cited above, telling me that ".!frame" was not a frame, I was more than a little perplexed. Because in my view, I *had* a frame. I don't really care what the widget's unique name is, contrary to your suggestion that I'm confused by it. If I had given my ttk.Frame the name "garply", and the error was '".garply" is not manageable: must be a frame, labelframe or toplevel', I would have looked back at my code, and seen that, yep, garply was indeed a ttk.Frame, so what's the problem?

It took me a long time to figure out that only a tkinter Frame, and not a ttk Frame, will work with wm_manage() (disregarding labelframe and toplevel in this context). Because as a regular developer using the library, it simply wasn't at all clear that using a ttk.Frame is fundamentally different under the covers, and isn't actually considered to be a frame for the purposes of wm_manage(). Who'd have thought? Seriously. Regular developers naturally assume that ttk components are a kind of specialised version of their non-ttk counterparts, albeit with different options and style support, rather than a parallel world. You noted that "Our ttk doc does not discuss the ttk widgets that are essentially copies of tk widgets  except the mostly documented differences". I think it *would* be worthwhile to say something about the fact that these are parallel components, and not derivatives, because, as this issue clearly illustrates, it can be important to understand this.

I even read through the tkinter and ttk source code to try to understand what was going on. The doc string for wm_manage() would have been a good place to say something, but there's nothing. I do understand that that is outside of ttk per se, but still, the two are not so separate that a comment couldn't help explain the constraint, and it really is important to the use of this method to understand that a ttk Frame is not a Frame.

It's unfortunate that the readable names used in the path aren't different for tkinter and ttk widgets, especially given how different they are. That would have helped. I realise, though, that changing it now is likely not a viable option.

In the end it was a hunch, perhaps born out of desperation and a lack of anything else to try, that led me to discover that a ttk Frame is not a Frame. I wasted a lot of time on this. I filed this issue in the hope that some documentation might be added so that others like myself don't also have to waste their time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43411>
_______________________________________

From report at bugs.python.org  Fri Mar 12 20:03:46 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 13 Mar 2021 01:03:46 +0000
Subject: [issue43463] typing.get_type_hints with TYPE_CHECKING imports /
 getting hints for single argument
In-Reply-To: <1615584679.6.0.785204537683.issue43463@roundup.psfhosted.org>
Message-ID: <CAP7+vJL_WD_jgauhdi7+ZxdUcXsTwD-_2s6q3JiRYT_5wrg53g@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

If we add a new flag to ignore errors it's difficult to write code that
works in 3.9 as well. And given the use case I have doubts that "Errors
should never pass silently" is really the right Zen line to focus on. I'd
rather go for "Simple is better than complex" or "practicality beats
purity".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43463>
_______________________________________

From report at bugs.python.org  Fri Mar 12 20:12:22 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 13 Mar 2021 01:12:22 +0000
Subject: [issue43475] Worst-case behaviour of hash collision with float NaN
In-Reply-To: <1615474533.28.0.166606930148.issue43475@roundup.psfhosted.org>
Message-ID: <1615597942.58.0.554760005106.issue43475@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Idea:  We could make this problem go away by making NaN a singleton.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43475>
_______________________________________

From report at bugs.python.org  Fri Mar 12 20:13:05 2021
From: report at bugs.python.org (Brandt Bucher)
Date: Sat, 13 Mar 2021 01:13:05 +0000
Subject: [issue42128] Structural Pattern Matching (PEP 634)
In-Reply-To: <1603466540.96.0.7677855399.issue42128@roundup.psfhosted.org>
Message-ID: <1615597985.89.0.490566804956.issue42128@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

Not a much thought went into that decision, honestly.

The main reason I chose an identifier there was because "as" always stores a simple name, so allowing it to potentially be other contexts or expressions (which are illegal) just seemed to create complexity. I saw we used simple identifiers in many similar places and just went with it.

(As a related note, if mapping patterns had their own AST nodes, I would probably choose to represent "**rest" as an optional identifier, rather than a keyless value or optional Name.)

If it causes problems for clients of the AST, it's easy to change. But I sort of like it a bit better how it is now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42128>
_______________________________________

From report at bugs.python.org  Fri Mar 12 20:14:33 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 13 Mar 2021 01:14:33 +0000
Subject: [issue43462] canvas.bbox returns None on 'hidden' items while coords
 doesn't
In-Reply-To: <1615384283.9.0.940431260638.issue43462@roundup.psfhosted.org>
Message-ID: <1615598073.41.0.991861063188.issue43462@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

(You don't use coords('tunnel') above because it only reports on the 'first' tagged object.)

tkinter widget methods are generally thin wrappers around tk functions that translate between python objects and tk strings.

I believe that this should be closed as '3rd party' or 'not a bug'.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43462>
_______________________________________

From report at bugs.python.org  Fri Mar 12 20:35:52 2021
From: report at bugs.python.org (Larry Trammell)
Date: Sat, 13 Mar 2021 01:35:52 +0000
Subject: [issue43483] Loss of content in simple (but oversize) SAX parsing
Message-ID: <1615599352.35.0.560655392831.issue43483@roundup.psfhosted.org>


New submission from Larry Trammell <ridgerat at nwi.net>:

== The Problem ==

I have observed a "loss of data" problem using the Python SAX parser, when processing an oversize but very simple machine-generated xhtml file. The file represents a single N x 11 data table.  W3C "tidy" reports no xml errors.  The table is constructed in an entirely plausible manner, using table, tr, and td tags to define the table structure, and p tags to bracket content, which consists of small chunks of quoted text.  There is nothing pathological, no extraneous whitespace characters, no empty data fields. 

Everything works perfectly in small test cases.  But when a very large number of rows are present, a few characters of content strings are occasionally lost. I have observed 2 or 6 characters dropped.  But here's the strange part.  The pathological behavior disappears (or moves to another location) when one or more non-significant whitespace characters are inserted at an arbitrary location early in the file... e.g. an extra linefeed before the first tr tag. 

== Context ==

I have observed identical behavior on desktop systems using an Intel Xeon E5-1607 or a Core-2 processor, running 32-bit or 64-bit Linux operating systems, variously using Python 3.8.5, 3.8, 3.7.3, and 3.5.1.

== Observing the Problem == 

Sorry that the test data is so bulky (even at 0.5% of original size), but bulk appears to be a necessary condition to observe the problem. Run the following command line.  

python3  EnchXMLTest.py  EnchTestData.html 

The test script invokes the SAX parser and generates messages on stdout. Using the original test data as provided, the test should run correctly to completion.  Now modify the test data file, deleting the extraneous comment line (there is only one) found near the top of the file.  Repeat the test run, and this time look for missing content characters in parsed content fields of the last record.  
 
== Any guesses? ==

Beyond "user is oblivious," possibly something abnormal can occur at seams between large blocks of buffered text.  The presence or absence of an extra character early in the data stream results in a corresponding shift in content location at the end of the buffer.  Other clues: is it relevant that the problem appears in a string field that contains slash characters?

----------
components: XML
files: EnchSAXTest.zip
messages: 388582
nosy: ridgerat1611
priority: normal
severity: normal
status: open
title: Loss of content in simple (but oversize) SAX parsing
type: behavior
versions: Python 3.7, Python 3.8
Added file: https://bugs.python.org/file49872/EnchSAXTest.zip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43483>
_______________________________________

From report at bugs.python.org  Fri Mar 12 20:47:14 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 13 Mar 2021 01:47:14 +0000
Subject: [issue42128] Structural Pattern Matching (PEP 634)
In-Reply-To: <1615597985.89.0.490566804956.issue42128@roundup.psfhosted.org>
Message-ID: <CAP7+vJ+k=i1JNsan2fj+krMRNE5xvO6By3GVZ4yLK7QX62xFvQ@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

This does point out that the ast structure is a liability, and we won't be
able to easily change it, since mypy and IIRC many linters use the ast
module. So I think that maybe we need to think more carefully about what
the *proper* ast structure is, rather than what was most convenient for the
initial implementation. (Brandt, I know you are reluctant to change this,
and I don't blame you, but nevertheless I think we should at least think
about this some more so we're not stuck with a sub-optimal "default"
solution. We've already won the war. Let's not lose the battle. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42128>
_______________________________________

From report at bugs.python.org  Fri Mar 12 21:05:58 2021
From: report at bugs.python.org (Brandt Bucher)
Date: Sat, 13 Mar 2021 02:05:58 +0000
Subject: [issue42128] Structural Pattern Matching (PEP 634)
In-Reply-To: <1603466540.96.0.7677855399.issue42128@roundup.psfhosted.org>
Message-ID: <1615601158.18.0.206132719774.issue42128@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

Yup, I agree we should explore this area further. See my comment here on Adrian?s mypy PR:

https://github.com/python/mypy/pull/10191#issuecomment-797841945

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42128>
_______________________________________

From report at bugs.python.org  Fri Mar 12 22:30:12 2021
From: report at bugs.python.org (mike bayer)
Date: Sat, 13 Mar 2021 03:30:12 +0000
Subject: [issue43484] we can create valid datetime objects that become invalid
 if the timezone is changed
Message-ID: <1615606212.76.0.00672395304579.issue43484@roundup.psfhosted.org>


New submission from mike bayer <mike_mp at zzzcomputing.com>:

So I'm pretty sure this is "not a bug" but it's a bit of a problem and I have a user suggesting the "security vulnerability" bell on this one, and to be honest I don't even know what any library would do to "prevent" this.

Basically, the datetime() object limits based on a numerical year of MINYEAR, rather than limiting based on an actual logical date.    

So I can create an "impossible" date as follows:


d = datetime.strptime("Mon Jan  1 00:00:00 0001 +01:00", "%c %z")

or like this:

d = datetime(year=1, month=1, day=1, tzinfo=timezone(timedelta(hours=1)))

and....you can see where this is going - it can't be converted to a timezone that pushes the year to zero:

>>> from datetime import datetime, timezone, timedelta
>>> d = datetime(year=1, month=1, day=1, tzinfo=timezone(timedelta(hours=1)))
>>> d.astimezone(timezone.utc)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: date value out of range

this because, after all, astimezone() is just subraction or addition and if it overflows past the artificial boundary, well you're out of luck.

Why's this a security problem?   ish?    because PostgreSQL has a data type "TIMESTAMP WITH TIMEZONE" and if you take said date and INSERT it into your database, then SELECT it back using any Python DBAPI that returns datetime() objects like psycopg2, if your server is in a timezone with zero or negative offset compared to the given date, you get an error.  So the mischievous user can create that datetime for some reason and now they've broken your website which can't SELECT that table anymore without crashing.

So, suppose you maintain the database library that helps people send data in and out of psycopg2.    We have, the end user's application, we have the database abstraction library, we have the psycopg2 driver, we have Python's datetime() object with MIN_YEAR, and finally we have PostgreSQL with the TIMEZONE WITH TIMESTAMP datatype that I've never liked.

Of those five roles, whose bug is this?    I'd like to say it's the end user for letting untrusted input that can put unusual timezones and timestamps in their system.   But at the same time it's a little weird Python is letting me create this date that lacks the ability to convert into UTC.     thanks for reading!

----------
components: Library (Lib)
messages: 388585
nosy: zzzeek
priority: normal
severity: normal
status: open
title: we can create valid datetime objects that become invalid if the timezone is changed
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43484>
_______________________________________

From report at bugs.python.org  Fri Mar 12 22:33:52 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 13 Mar 2021 03:33:52 +0000
Subject: [issue26362] Approved API for creating a temporary file path
In-Reply-To: <1455502271.6.0.558905453707.issue26362@psf.upfronthosting.co.za>
Message-ID: <1615606432.01.0.0640651162433.issue26362@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> The proposal in this issue is to have a public standard library API,
> which I'm calling ?tempfile.makepath?,

It's a few years later, and tempfile.mktemp() still exists and works without raising a deprecation warning. Of course it's still marked as deprecated in the docs. Does anyone still want this tempfile.makepath() function? Or can this issue be closed?

----------
type: behavior -> enhancement
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26362>
_______________________________________

From report at bugs.python.org  Fri Mar 12 22:39:25 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 13 Mar 2021 03:39:25 +0000
Subject: [issue29688] Add support for Path.absolute()
In-Reply-To: <1488389848.79.0.700814097868.issue29688@psf.upfronthosting.co.za>
Message-ID: <1615606765.02.0.928579769887.issue29688@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
assignee:  -> docs at python
components: +Library (Lib)
type:  -> enhancement
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29688>
_______________________________________

From report at bugs.python.org  Fri Mar 12 22:48:45 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 13 Mar 2021 03:48:45 +0000
Subject: [issue18017] ctypes.PyDLL documentation
In-Reply-To: <1369010319.69.0.913023030404.issue18017@psf.upfronthosting.co.za>
Message-ID: <1615607325.45.0.810630710932.issue18017@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

I think the documentation of ctypes.PyDLL and ctypes.pythonapi is good enough as is.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18017>
_______________________________________

From report at bugs.python.org  Fri Mar 12 22:51:25 2021
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 13 Mar 2021 03:51:25 +0000
Subject: [issue43484] we can create valid datetime objects that become invalid
 if the timezone is changed
In-Reply-To: <1615606212.76.0.00672395304579.issue43484@roundup.psfhosted.org>
Message-ID: <1615607485.2.0.788599045701.issue43484@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
nosy: +belopolsky, lemburg, p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43484>
_______________________________________

From report at bugs.python.org  Fri Mar 12 22:53:49 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 13 Mar 2021 03:53:49 +0000
Subject: [issue30435] Documentation either unclear or incorrect on comparisons
 between bytes and strings in Python 3
In-Reply-To: <1495495979.22.0.902310404899.issue30435@psf.upfronthosting.co.za>
Message-ID: <1615607629.49.0.426843523923.issue30435@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
type: behavior -> enhancement
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30435>
_______________________________________

From report at bugs.python.org  Fri Mar 12 23:00:45 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 13 Mar 2021 04:00:45 +0000
Subject: [issue43477] from x import * behavior inconsistent between module
 types.
In-Reply-To: <1615509638.08.0.549124406797.issue43477@roundup.psfhosted.org>
Message-ID: <1615608045.02.0.684592954239.issue43477@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +brett.cannon, eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43477>
_______________________________________

From report at bugs.python.org  Fri Mar 12 23:03:54 2021
From: report at bugs.python.org (=?utf-8?q?Kadir_SEL=C3=87UK?=)
Date: Sat, 13 Mar 2021 04:03:54 +0000
Subject: [issue43485] devturks
Message-ID: <1615608234.17.0.36625339556.issue43485@roundup.psfhosted.org>


Change by Kadir SEL?UK <post.kadirselcuk 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), Regular Expressions, SSL, Subinterpreters, Tests, Tkinter, Unicode, Windows, XML, asyncio, ctypes, email
hgrepos: 399
nosy: Alex.Willmer, asvetlov, barry, docs at python, dstufft, eric.araujo, ezio.melotti, koobs, larry, mrabarnett, paul.moore, post.kadirselcuk, r.david.murray, steve.dower, terry.reedy, tim.golden, vstinner, yselivanov, zach.ware
priority: normal
severity: normal
status: open
title: devturks
type: resource usage
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43485>
_______________________________________

From report at bugs.python.org  Fri Mar 12 23:06:16 2021
From: report at bugs.python.org (=?utf-8?q?Kadir_SEL=C3=87UK?=)
Date: Sat, 13 Mar 2021 04:06:16 +0000
Subject: [issue43485] devturks
Message-ID: <1615608376.47.0.45903392252.issue43485@roundup.psfhosted.org>


Change by Kadir SEL?UK <post.kadirselcuk at gmail.com>:


----------
resolution:  -> works for me

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43485>
_______________________________________

From report at bugs.python.org  Fri Mar 12 23:06:26 2021
From: report at bugs.python.org (=?utf-8?q?Kadir_SEL=C3=87UK?=)
Date: Sat, 13 Mar 2021 04:06:26 +0000
Subject: [issue43485] devturks
Message-ID: <1615608386.31.0.556717773249.issue43485@roundup.psfhosted.org>


Change by Kadir SEL?UK <post.kadirselcuk at gmail.com>:


----------
hgrepos: +400

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43485>
_______________________________________

From report at bugs.python.org  Fri Mar 12 23:08:21 2021
From: report at bugs.python.org (Ben Finney)
Date: Sat, 13 Mar 2021 04:08:21 +0000
Subject: [issue26362] Approved API for creating a temporary file path
In-Reply-To: <1455502271.6.0.558905453707.issue26362@psf.upfronthosting.co.za>
Message-ID: <1615608501.09.0.0264176826569.issue26362@roundup.psfhosted.org>


Ben Finney <ben+python at benfinney.id.au> added the comment:

> tempfile.mktemp() still exists and works without raising a deprecation warning. Of course it's still marked as deprecated in the docs.

Right. So, the issue is not resolved: Functionality to create a temporary file path is maintained in the standard library (good) but the public API for it is unsupported.

> Does anyone still want this tempfile.makepath() function?

That's a proposed name. But yes, a supported function in the `tempfile` standard library module, which does what's described in this issue.

> Or can this issue be closed?

The issue remains unresolved. Unless you can point us to something new which resolves this?

So no, while unresolved, this bug report should not be closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26362>
_______________________________________

From report at bugs.python.org  Fri Mar 12 23:08:26 2021
From: report at bugs.python.org (=?utf-8?q?Kadir_SEL=C3=87UK?=)
Date: Sat, 13 Mar 2021 04:08:26 +0000
Subject: [issue19217] Calling assertEquals for moderately long list takes too
 long
In-Reply-To: <1381410286.72.0.514206486634.issue19217@psf.upfronthosting.co.za>
Message-ID: <1615608506.01.0.461342044564.issue19217@roundup.psfhosted.org>


Change by Kadir SEL?UK <post.kadirselcuk at gmail.com>:


----------
hgrepos: +401

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19217>
_______________________________________

From report at bugs.python.org  Fri Mar 12 23:12:17 2021
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 13 Mar 2021 04:12:17 +0000
Subject: [issue43485] Spam
Message-ID: <1615608737.57.0.0394026249749.issue43485@roundup.psfhosted.org>


New submission from Zachary Ware <zachary.ware at gmail.com>:

You appear to be just creating spam, so I've removed your ability to make any changes to bugs.python.org.  If you feel this was done in error, please bring it up on discuss.python.org.

----------
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), Regular Expressions, SSL, Subinterpreters, Tests, Tkinter, Unicode, Windows, XML, asyncio, ctypes, email
nosy:  -Alex.Willmer, asvetlov, barry, docs at python, dstufft, eric.araujo, ezio.melotti, koobs, larry, mrabarnett, paul.moore, r.david.murray, steve.dower, terry.reedy, tim.golden, vstinner, yselivanov
resolution: works for me -> not a bug
stage:  -> resolved
status: open -> closed
title: devturks -> Spam
type: resource usage -> 
versions:  -Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43485>
_______________________________________

From report at bugs.python.org  Fri Mar 12 23:12:30 2021
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 13 Mar 2021 04:12:30 +0000
Subject: [issue43485] Spam
In-Reply-To: <1615608737.57.0.0394026249749.issue43485@roundup.psfhosted.org>
Message-ID: <1615608750.91.0.233733752395.issue43485@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
hgrepos:  -399

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43485>
_______________________________________

From report at bugs.python.org  Fri Mar 12 23:12:35 2021
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 13 Mar 2021 04:12:35 +0000
Subject: [issue43485] Spam
In-Reply-To: <1615608737.57.0.0394026249749.issue43485@roundup.psfhosted.org>
Message-ID: <1615608755.54.0.538078171323.issue43485@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
hgrepos:  -400

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43485>
_______________________________________

From report at bugs.python.org  Fri Mar 12 23:13:15 2021
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 13 Mar 2021 04:13:15 +0000
Subject: [issue19217] Calling assertEquals for moderately long list takes too
 long
In-Reply-To: <1381410286.72.0.514206486634.issue19217@psf.upfronthosting.co.za>
Message-ID: <1615608795.83.0.603967420391.issue19217@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
hgrepos:  -401

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19217>
_______________________________________

From report at bugs.python.org  Fri Mar 12 23:15:27 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 13 Mar 2021 04:15:27 +0000
Subject: [issue34840] dlopen() error with no error message from dlerror()
In-Reply-To: <1538203086.61.0.545547206417.issue34840@psf.upfronthosting.co.za>
Message-ID: <1615608927.51.0.686301490885.issue34840@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34840>
_______________________________________

From report at bugs.python.org  Fri Mar 12 23:19:33 2021
From: report at bugs.python.org (Tim Peters)
Date: Sat, 13 Mar 2021 04:19:33 +0000
Subject: [issue43420] Optimize rational arithmetics
In-Reply-To: <1615040297.73.0.541090358152.issue43420@roundup.psfhosted.org>
Message-ID: <1615609173.35.0.540714620235.issue43420@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Terry, we could do that, but the opposition here isn't strong, and is pretty baffling anyway ;-) : the suggested changes are utterly ordinary for implementations of rationals, require very little code, are not delicate, and are actually straightforward to see are correct (although unfamiliarity can be an initial barrier - e.g., if you don't already know that after

     g = gcd(a, b)
     a1 = a // g
     b1 = b // g

it's necessarily true that a1 and b1 are coprime, a key reason for way the transformation is correct will be lost on you - but it's also very easy to prove that claim once you're told that it is a key here). The OP is right that "we" (at least Mark, and Raymond, and I) have routinely checked in far subtler optimizations in various areas.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43420>
_______________________________________

From report at bugs.python.org  Fri Mar 12 23:27:22 2021
From: report at bugs.python.org (Sergey B Kirpichev)
Date: Sat, 13 Mar 2021 04:27:22 +0000
Subject: [issue43420] Optimize rational arithmetics
In-Reply-To: <1615040297.73.0.541090358152.issue43420@roundup.psfhosted.org>
Message-ID: <1615609642.98.0.945927791866.issue43420@roundup.psfhosted.org>


Sergey B Kirpichev <skirpichev at gmail.com> added the comment:

> a short paragraph or section on alternative implementations

There are no alternative implementations.  SymPy's PythonRational (AFAIR, this class not in the default namespace) is an internal fallback solution, for case when no gmpy2 is available.

Maybe we should list gmpy2 everywhere people expect fast bigint/rationals (i.e. int docs, math module, Fraction and so on), so they will not not be disappointed...

> complexity (and assured correctness)

Much more complex (IMHO) code was accepted (there were examples for C, but the limit_denominator() method - an example for Python code, from the same module!).

In fact, it pretty obvious that output fractions are equal to the middle-school versions.  Non-trivial part may be why they are normalized.  I hope, now this covered by comments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43420>
_______________________________________

From report at bugs.python.org  Fri Mar 12 23:47:59 2021
From: report at bugs.python.org (junyixie)
Date: Sat, 13 Mar 2021 04:47:59 +0000
Subject: [issue23835] configparser does not convert defaults to strings
In-Reply-To: <1427862188.44.0.00358189102447.issue23835@psf.upfronthosting.co.za>
Message-ID: <1615610879.79.0.298847329536.issue23835@roundup.psfhosted.org>


Change by junyixie <xie.junyi at outlook.com>:


----------
nosy: +JunyiXie
nosy_count: 7.0 -> 8.0
pull_requests: +23600
pull_request: https://github.com/python/cpython/pull/24821

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23835>
_______________________________________

From report at bugs.python.org  Fri Mar 12 23:58:17 2021
From: report at bugs.python.org (Antti Haapala)
Date: Sat, 13 Mar 2021 04:58:17 +0000
Subject: [issue43468] functools.cached_property locking is plain wrong.
In-Reply-To: <1615444667.91.0.948817723419.issue43468@roundup.psfhosted.org>
Message-ID: <1615611497.75.0.331695093175.issue43468@roundup.psfhosted.org>


Antti Haapala <antti at haapala.name> added the comment:

I've been giving thought to implementing the locking on the instance or per instance instead, and there are bad and worse ideas like inserting per (instance, descriptor) into the instance `__dict__`, guarded by the per-descriptor lock; using a per-descriptor `WeakKeyDictionary` to map the instance to locks (which would of course not work - is there any way to map unhashable instances weakly?)

So far best ideas that I have heard from others or discovered myself are along the lines of "remove locking altogether" (breaks compatibility); "add `thread_unsafe` keyword argument" with documentation saying that this is what you want to use if you're actually running threads; "implement Java-style object monitors and synchronized methods in CPython and use those instead"; or "create yet another method".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43468>
_______________________________________

From report at bugs.python.org  Sat Mar 13 00:18:04 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 13 Mar 2021 05:18:04 +0000
Subject: [issue43439] [security] Add audit events on GC functions giving
 access to all Python objects
In-Reply-To: <1615235548.58.0.659993767767.issue43439@roundup.psfhosted.org>
Message-ID: <1615612684.06.0.930019495342.issue43439@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +23601
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/24836

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43439>
_______________________________________

From report at bugs.python.org  Sat Mar 13 00:48:41 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 13 Mar 2021 05:48:41 +0000
Subject: [issue26362] Approved API for creating a temporary file path
In-Reply-To: <1455502271.6.0.558905453707.issue26362@psf.upfronthosting.co.za>
Message-ID: <1615614521.03.0.416481464601.issue26362@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> So no, while unresolved, this bug report should not be closed.

The implied question was whether you or the core devs on the nosy list, upon further consideration, wanted to resolve the issue by rejecting the request, but it had simply been forgotten about for 4 years.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26362>
_______________________________________

From report at bugs.python.org  Sat Mar 13 01:00:14 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 13 Mar 2021 06:00:14 +0000
Subject: [issue36880] Returning None from a callback with restype py_object
 decrements None's refcount too much
In-Reply-To: <1557527941.1.0.208797159552.issue36880@roundup.psfhosted.org>
Message-ID: <1615615214.03.0.271949929668.issue36880@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
versions: +Python 3.10, Python 3.9 -Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36880>
_______________________________________

From report at bugs.python.org  Sat Mar 13 02:06:28 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 13 Mar 2021 07:06:28 +0000
Subject: [issue23633] Improve py launcher help, index, and doc
In-Reply-To: <1426026714.29.0.122233634927.issue23633@psf.upfronthosting.co.za>
Message-ID: <1615619188.2.0.482979048867.issue23633@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

The current help text attempts to explain point 2, in terms of an active virtual environment, shebangs, the PY_PYTHON[2|3] environment variables, and the py.ini [defaults]. It's a lot to say succinctly in a few lines of text. A shortened URL that links to the docs would be helpful.

The -0[p] listing uses an asterisk to highlight the version that `py` runs without a version specified in the command line or if a script has no shebang.

For point 3, referencing CSIDL_LOCAL_APPDATA in the documentation is not useful for people who aren't familiar with the Windows shell API. The help text from py.exe uses "%LOCALAPPDATA%\py.ini", which is more useful at the command line. It also explains how to locate py.ini in the launcher directory by using `where py`. However, a lot of people use PowerShell nowadays, in which case it has to be `where.exe py` or `gcm py | select source`.

----------
assignee:  -> docs at python
components: +Documentation, Windows
nosy: +docs at python, paul.moore, tim.golden, zach.ware
type: behavior -> enhancement
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23633>
_______________________________________

From report at bugs.python.org  Sat Mar 13 02:08:03 2021
From: report at bugs.python.org (Inada Naoki)
Date: Sat, 13 Mar 2021 07:08:03 +0000
Subject: [issue43214] site: Potential UnicodeDecodeError when handling pth file
In-Reply-To: <1613206406.27.0.848192620201.issue43214@roundup.psfhosted.org>
Message-ID: <1615619283.56.0.839330146584.issue43214@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
superseder:  -> Use io.open_code for .pth files

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43214>
_______________________________________

From report at bugs.python.org  Sat Mar 13 02:09:35 2021
From: report at bugs.python.org (Inada Naoki)
Date: Sat, 13 Mar 2021 07:09:35 +0000
Subject: [issue43214] site: Potential UnicodeDecodeError when handling pth file
In-Reply-To: <1613206406.27.0.848192620201.issue43214@roundup.psfhosted.org>
Message-ID: <1615619375.88.0.574017899315.issue43214@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
keywords: +patch
pull_requests: +23602
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24837

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43214>
_______________________________________

From report at bugs.python.org  Sat Mar 13 02:27:23 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 13 Mar 2021 07:27:23 +0000
Subject: [issue43473] Junks in difflib
In-Reply-To: <1615455471.04.0.613792585483.issue43473@roundup.psfhosted.org>
Message-ID: <1615620443.48.0.742325053575.issue43473@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Currently return tuple (i, j, n), means that a[i:i+n] == b[j:j+n], where both matching blocks are the same length.
https://docs.python.org/3/library/difflib.html#difflib.SequenceMatcher.get_matching_blocks

This would not be the case if a has an ignored space and b does not. Changing the current definition would break existing code and would require quadruples to return two different lengths.  This would require either a new parameter for the function to select the behavior or a new function with a new name.

Either option would require justification by actual use cases.  I cannot see what they might be.  An way to have junk chars completely ignored is to strip them from both strings before calling SequenceMatcher.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43473>
_______________________________________

From report at bugs.python.org  Sat Mar 13 02:35:36 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 13 Mar 2021 07:35:36 +0000
Subject: [issue43411] wm_manage fails with ttk.Frame
In-Reply-To: <1614972319.75.0.638524894464.issue43411@roundup.psfhosted.org>
Message-ID: <1615620936.37.0.131989645316.issue43411@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

As an IDLE maintainer, I am a tkinter user also and that is my involvement in tkinter changes.  One of my projects for IDLE has been to switch to ttk widgets, including ttk.Frame, wherever possible, for the reasons you gave.

It is known the tkinter docs we control are quite inadequate, and dependent on outside docs that we do not control.  That is why the tkinter doc starts with 7 references for tkinter and 5 for tcl/tk.  I am sorry that you fell into one of the gaps.  But no one has yet volunteered to rewrite the tkinter/ttk docs to be complete, correct, and not dependent on outside resources.  Until then, I do not see a good place to put the note you request.  What would you say, and more important, where?

wm_manage is an anomaly for at least two reasons.  The tk docs define the wm call sequences as "'wm' <subcommand> atoplevel <maybe subcommand args>".  This translates to tkinters calls "atoplevel.wm_subcommand(subcommand_args)", where 'atoplevel' is the self arg for the call.  The tk doc contradicts itself by saying that for wm_manage, atoplevel can instead be a *frame* or *labelframe* (** indicates italics in the tk docs).  For tkinter, this translate to aframe.wm_manage(), but this is impossible since Frames do not subclass the Wm class, nor are they given this one method.  It also turns out that atoplevel.wm_manage() does not work either.

Instead, one must call atoplevel.wm_manage(toplevel_frame_or_labelframe).  This would roughly be equivalent, in tk, to "'wm' 'manage' atoplevel toplevel_frame_or_labelframe". 

Another anomaly is that wm_manage is not really needed, at least not for frames.  On can create a toplevel and pack a frame of any type that fills the toplevel.  (Yes, a bit more work.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43411>
_______________________________________

From report at bugs.python.org  Sat Mar 13 03:07:38 2021
From: report at bugs.python.org (Vincent)
Date: Sat, 13 Mar 2021 08:07:38 +0000
Subject: [issue43462] canvas.bbox returns None on 'hidden' items while coords
 doesn't
In-Reply-To: <1615384283.9.0.940431260638.issue43462@roundup.psfhosted.org>
Message-ID: <1615622858.76.0.699541570681.issue43462@roundup.psfhosted.org>


Vincent <inquiry at intoreflection.co> added the comment:

HI Terry, yes, that's completely true. But what I meant is I have to invoke coords on every item belonging to a tag and then perform some calculations to get the boundary box of all the items belonging to the item. 

Let's close this issue and I will knock on the door of the developers of Tk.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43462>
_______________________________________

From report at bugs.python.org  Sat Mar 13 04:05:49 2021
From: report at bugs.python.org (Vincent)
Date: Sat, 13 Mar 2021 09:05:49 +0000
Subject: [issue43462] canvas.bbox returns None on 'hidden' items while coords
 doesn't
In-Reply-To: <1615384283.9.0.940431260638.issue43462@roundup.psfhosted.org>
Message-ID: <1615626349.38.0.141471778364.issue43462@roundup.psfhosted.org>


Change by Vincent <inquiry at intoreflection.co>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43462>
_______________________________________

From report at bugs.python.org  Sat Mar 13 04:45:31 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 13 Mar 2021 09:45:31 +0000
Subject: [issue43086] Excess data in not handled properly in
 binascii.a2b_base64()
In-Reply-To: <1612116712.99.0.535653486799.issue43086@roundup.psfhosted.org>
Message-ID: <1615628731.7.0.121698528768.issue43086@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43086>
_______________________________________

From report at bugs.python.org  Sat Mar 13 04:48:27 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 13 Mar 2021 09:48:27 +0000
Subject: [issue42322] Spectre mitigations in CPython interpreter
In-Reply-To: <1605093551.24.0.524478744349.issue42322@roundup.psfhosted.org>
Message-ID: <1615628907.84.0.593673219605.issue42322@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

Compiling everything (your entire OS and libraries and CPython itself) with compiler mitigations is recommended.  I agree, there is nothing specific we need to do within CPython itself.

----------
nosy: +gregory.p.smith
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42322>
_______________________________________

From report at bugs.python.org  Sat Mar 13 05:02:02 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 13 Mar 2021 10:02:02 +0000
Subject: [issue40763] zipfile.extractall is safe by now
In-Reply-To: <1590391095.61.0.387813168658.issue40763@roundup.psfhosted.org>
Message-ID: <1615629722.69.0.464353613863.issue40763@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

amaajemyfren is correct (and thanks for the pointers to the original issue and discussion).  The warning remains out of caution.

----------
nosy: +gregory.p.smith
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40763>
_______________________________________

From report at bugs.python.org  Sat Mar 13 05:03:31 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 13 Mar 2021 10:03:31 +0000
Subject: [issue33136] Harden ssl module against CVE-2018-8970
In-Reply-To: <1521969562.74.0.467229070634.issue33136@psf.upfronthosting.co.za>
Message-ID: <1615629811.79.0.486828906614.issue33136@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

yes, this was fixed.

----------
nosy: +gregory.p.smith
resolution:  -> fixed
stage: patch review -> commit review
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33136>
_______________________________________

From report at bugs.python.org  Sat Mar 13 05:18:28 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 13 Mar 2021 10:18:28 +0000
Subject: [issue43357] Python memory cleaning
In-Reply-To: <1614632983.21.0.75211891492.issue43357@roundup.psfhosted.org>
Message-ID: <1615630708.88.0.542581510211.issue43357@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

CPython itself doesn't have guaranteed way to do this kind of thing.  There is no tracking of which types clear memory let alone which API calls may make copies of data in places within their C that are not explicitly cleared afterwards.  We do not have a plan to implement this.

For data that MUST NOT remain in memory in any form anywhere as soon as code is done with it, the best thing to do is isolate all code inputting, processing, and clearing that within the confines of a lower level extension module or a short lived subprocess.

----------
nosy: +gregory.p.smith
resolution:  -> rejected
stage:  -> resolved
status: open -> closed
type: security -> enhancement
versions: +Python 3.10 -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43357>
_______________________________________

From report at bugs.python.org  Sat Mar 13 05:30:43 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 13 Mar 2021 10:30:43 +0000
Subject: [issue43285] ftplib use host from PASV response
In-Reply-To: <1613908174.7.0.0578051462677.issue43285@roundup.psfhosted.org>
Message-ID: <1615631443.48.0.378232895151.issue43285@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

Indeed, the `host` on that line there should just be ignored with the IP address of the original data connection used in its place.

Your https://hackerone.com/reports/1040166 link provides plenty of information and likes to prior art mitigations other ftp clients including Firefox and Chrome well over a decade ago.

----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith
stage:  -> needs patch
versions: +Python 3.10, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43285>
_______________________________________

From report at bugs.python.org  Sat Mar 13 05:34:54 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 13 Mar 2021 10:34:54 +0000
Subject: [issue43475] Worst-case behaviour of hash collision with float NaN
In-Reply-To: <1615474533.28.0.166606930148.issue43475@roundup.psfhosted.org>
Message-ID: <1615631694.79.0.4819001945.issue43475@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> We could make this problem go away by making NaN a singleton.

That could work, though we'd annoy anyone who cared about preserving NaN payloads and signs in Python. I don't know if such people exist. Currently the sign is accessible through things like math.copysign, and the payload through struct manipulations (though on most platforms we still don't see the full range of NaNs: signalling NaNs are quietly silenced on my machine).

We'd also want to do some performance checks: the obvious way to do this would be to have an "is_nan" check in PyFloat_FromDouble. I'd *guess* that a typical CPU would do a reasonable job of branch prediction on that check so that it had minimal impact in normal use, but only timings will tell for sure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43475>
_______________________________________

From report at bugs.python.org  Sat Mar 13 06:16:35 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 13 Mar 2021 11:16:35 +0000
Subject: [issue43475] Worst-case behaviour of hash collision with float NaN
In-Reply-To: <1615474533.28.0.166606930148.issue43475@roundup.psfhosted.org>
Message-ID: <1615634195.18.0.654477369594.issue43475@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> signalling NaNs are quietly silenced on my machine

I just tested this assertion, and it appears that I was lying: this doesn't seem to be true. I'm almost *sure* it used to be true, and I'm not sure what changed, and when. (FWIW: Python 3.9.2 from macPorts on macOS 10.14.6 + Intel hardware. Earlier versions of Python on the same machine give similar results to those below, so it's not a core Python change.)

Here's an attempt to create an snan Python float:

Python 3.9.2 (default, Feb 28 2021, 13:47:30) 
[Clang 10.0.1 (clang-1001.0.46.4)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> snan_bits = 0x7ff0000000123456
>>> snan = struct.unpack("<d", struct.pack("<Q", snan_bits))[0]
>>> snan
nan

Converting back shows that the attempt was successful: the payload, including the signalling bit (bit 51, counting with the lsb as bit 0), was preserved:

>>> hex(struct.unpack("<Q", struct.pack("<d", snan))[0])
'0x7ff0000000123456'

As expected, doing any arithmetic on the value converts the signalling nan to the corresponding quiet nan (so that the leading 16 bits become 0x7ff8 instead of 0x7ff0), but preserves the rest of the payload.

>>> hex(struct.unpack("<Q", struct.pack("<d", 0.0 + snan))[0])
'0x7ff8000000123456'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43475>
_______________________________________

From report at bugs.python.org  Sat Mar 13 06:23:46 2021
From: report at bugs.python.org (Cong Ma)
Date: Sat, 13 Mar 2021 11:23:46 +0000
Subject: [issue43475] Worst-case behaviour of hash collision with float NaN
In-Reply-To: <1615474533.28.0.166606930148.issue43475@roundup.psfhosted.org>
Message-ID: <1615634626.91.0.579820943044.issue43475@roundup.psfhosted.org>


Cong Ma <m.cong at protonmail.ch> added the comment:

> Idea:  We could make this problem go away by making NaN a singleton.

Apart from the fact that NaN is not a specific value/object (as pointed out in the previous message by @mark.dickinson), currently each builtin singleton (None, True, False, etc.) in Python satisfies the following predicate:

`if s is a singleton, then s == s`

This is also satisfied by "flyweight" objects such as small ints.

It feels natural and unsurprising to have this, if not officially promised. Requiring NaN to be a singleton would violate this implicit understanding about singletons, and cause another surprise on top of the other surprises with NaNs (or with rich comparison in general).

Performance-wise, I think the current behaviour (returning _PyHASH_NAN == 0) is already nested inside two layers of conditionals in `_Py_HashDouble()` in Python/pyhash.c:

```
    if (!Py_IS_FINITE(v)) {
        if (Py_IS_INFINITY(v))
            return v > 0 ? _PyHASH_INF : -_PyHASH_INF;
        else
            return _PyHASH_NAN;
    }
```
(v is the underlying C `double`, field `ob_fval` of `PyFloatObject`).

I don't feel performance would be hurt by rewriting `float_hash()` in Objects/floatobject.c to the effect of

```
    if (!Py_IS_NAN(v->ob_fval)) {
        return _Py_HashDouble(v->ob_fval)
    }
    else {
        return _Py_HashPointer(v);
    }
```
and simplify the conditionals in `_Py_HashDouble()`. But of course, only real benchmarking could tell. (Also, other float-like types would have to be adjusted, too).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43475>
_______________________________________

From report at bugs.python.org  Sat Mar 13 06:27:21 2021
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 13 Mar 2021 11:27:21 +0000
Subject: [issue37788] fix for bpo-36402 (threading._shutdown() race condition)
 causes reference leak
In-Reply-To: <1565194972.64.0.065323919799.issue37788@roundup.psfhosted.org>
Message-ID: <1615634841.23.0.99024900251.issue37788@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

bpo-37193 has been fixed.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37788>
_______________________________________

From report at bugs.python.org  Sat Mar 13 06:29:39 2021
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 13 Mar 2021 11:29:39 +0000
Subject: [issue43412] object.h -Wcast-qual warning
In-Reply-To: <1614982361.61.0.858230879301.issue43412@roundup.psfhosted.org>
Message-ID: <1615634979.59.0.796107148744.issue43412@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> object.h contains an inline function that causes a -Wcast-qual warning from gcc.

Which function? Can you please provide the warning?

Do you want to propose a fix?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43412>
_______________________________________

From report at bugs.python.org  Sat Mar 13 06:29:59 2021
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 13 Mar 2021 11:29:59 +0000
Subject: [issue27827] pathlib is_reserved fails for some reserved paths on
 Windows
In-Reply-To: <1471858428.08.0.847859442583.issue27827@psf.upfronthosting.co.za>
Message-ID: <1615634999.57.0.709238330877.issue27827@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27827>
_______________________________________

From report at bugs.python.org  Sat Mar 13 06:32:56 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 13 Mar 2021 11:32:56 +0000
Subject: [issue43475] Worst-case behaviour of hash collision with float NaN
In-Reply-To: <1615474533.28.0.166606930148.issue43475@roundup.psfhosted.org>
Message-ID: <1615635176.32.0.567967560189.issue43475@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

@Cong Ma: Yes, I'm not worried about performance for the change you're proposing (though as you say, we should benchmark anyway). The performance thoughts were motivated by the idea of making NaN a singleton: adding a check to PyFloat_FromDouble would mean that almost every operation that produced a float would have to pass through that check.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43475>
_______________________________________

From report at bugs.python.org  Sat Mar 13 06:54:48 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 13 Mar 2021 11:54:48 +0000
Subject: [issue43285] ftplib use host from PASV response
In-Reply-To: <1613908174.7.0.0578051462677.issue43285@roundup.psfhosted.org>
Message-ID: <1615636488.76.0.207792496458.issue43285@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
keywords: +patch
pull_requests: +23603
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/24838

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43285>
_______________________________________

From report at bugs.python.org  Sat Mar 13 07:00:29 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 13 Mar 2021 12:00:29 +0000
Subject: [issue37788] fix for bpo-36402 (threading._shutdown() race condition)
 causes reference leak
In-Reply-To: <1565194972.64.0.065323919799.issue37788@roundup.psfhosted.org>
Message-ID: <1615636829.19.0.0644864260427.issue37788@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

@Victor: How does the fix for #37193 solve this issue? I think I'm missing something.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37788>
_______________________________________

From report at bugs.python.org  Sat Mar 13 07:03:41 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 13 Mar 2021 12:03:41 +0000
Subject: [issue43285] ftplib use host from PASV response
In-Reply-To: <1613908174.7.0.0578051462677.issue43285@roundup.psfhosted.org>
Message-ID: <1615637021.54.0.568553859139.issue43285@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

I'm not interested in chasing down a CVE for this myself.  If anyone wants to jump through the hoops to obtain one, the text used for curl in the hackerone link is likely a good guide.

My PR includes a way for people to opt-out of the secure behavior (why would anyone ever want that?) by setting the use_untrusted_server_pasv_ipv4_addr attribute to True on their ftplib.FTP instance.  Setting that attribute on a server lacking this fix is a no-op, making it safe to add to code running on any version.

This is an embarrassingly old widespread common issue in a large number of ftp clients.  Even the 1998 IPv6 RFC https://tools.ietf.org/html/rfc2428 indirectly acknowledges its existence by disallowing the new EPSV command that replaces PASV from returning anything other than the port number while leaving fields for the other values present but empty...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43285>
_______________________________________

From report at bugs.python.org  Sat Mar 13 07:04:37 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 13 Mar 2021 12:04:37 +0000
Subject: [issue43285] ftplib should not use the host from the PASV response
In-Reply-To: <1613908174.7.0.0578051462677.issue43285@roundup.psfhosted.org>
Message-ID: <1615637077.91.0.0448761493342.issue43285@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
title: ftplib use host from PASV response -> ftplib should not use the host from the PASV response

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43285>
_______________________________________

From report at bugs.python.org  Sat Mar 13 07:13:34 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 13 Mar 2021 12:13:34 +0000
Subject: [issue37788] fix for bpo-36402 (threading._shutdown() race condition)
 causes reference leak
In-Reply-To: <1565194972.64.0.065323919799.issue37788@roundup.psfhosted.org>
Message-ID: <1615637614.88.0.524379977662.issue37788@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Re-opening; I believe this issue is still valid.

Here's output on a debug build on current master (commit 7591d9455eb37525c832da3d65e1a7b3e6dbf613) on my machine:

lovelace:cpython mdickinson$ ./python.exe
Python 3.10.0a6+ (remotes/upstream/master:7591d9455e, Mar 13 2021, 12:04:31) [Clang 11.0.0 (clang-1100.0.33.17)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys, threading, time
>>> for _ in range(10):
...     threading.Thread().start()
...     time.sleep(0.1)
...     print(sys.gettotalrefcount())
... 
109901
109905
109907
109909
109911
109913
109915
109917
109919
109921

----------
resolution: fixed -> 
stage: resolved -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37788>
_______________________________________

From report at bugs.python.org  Sat Mar 13 07:22:26 2021
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 13 Mar 2021 12:22:26 +0000
Subject: [issue43479] Remove a duplicate comment and assignment in http.client
In-Reply-To: <1615546113.27.0.0553252720004.issue43479@roundup.psfhosted.org>
Message-ID: <1615638146.41.0.669967561495.issue43479@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
assignee:  -> orsenthil
nosy: +orsenthil
versions:  -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43479>
_______________________________________

From report at bugs.python.org  Sat Mar 13 07:23:33 2021
From: report at bugs.python.org (miss-islington)
Date: Sat, 13 Mar 2021 12:23:33 +0000
Subject: [issue43479] Remove a duplicate comment and assignment in http.client
In-Reply-To: <1615546113.27.0.0553252720004.issue43479@roundup.psfhosted.org>
Message-ID: <1615638213.62.0.994980984484.issue43479@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
keywords: +patch
nosy: +miss-islington
nosy_count: 2.0 -> 3.0
pull_requests: +23604
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24839

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43479>
_______________________________________

From report at bugs.python.org  Sat Mar 13 07:23:44 2021
From: report at bugs.python.org (miss-islington)
Date: Sat, 13 Mar 2021 12:23:44 +0000
Subject: [issue43479] Remove a duplicate comment and assignment in http.client
In-Reply-To: <1615546113.27.0.0553252720004.issue43479@roundup.psfhosted.org>
Message-ID: <1615638224.92.0.265211753014.issue43479@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +23605
pull_request: https://github.com/python/cpython/pull/24840

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43479>
_______________________________________

From report at bugs.python.org  Sat Mar 13 08:08:07 2021
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 13 Mar 2021 13:08:07 +0000
Subject: [issue35883] Change invalid unicode characters to replacement
 characters in argv
In-Reply-To: <1549040138.25.0.646545491344.issue35883@roundup.psfhosted.org>
Message-ID: <1615640887.85.0.868998402071.issue35883@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +23606
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24843

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35883>
_______________________________________

From report at bugs.python.org  Sat Mar 13 08:10:43 2021
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 13 Mar 2021 13:10:43 +0000
Subject: [issue35883] Change invalid unicode characters to replacement
 characters in argv
In-Reply-To: <1549040138.25.0.646545491344.issue35883@roundup.psfhosted.org>
Message-ID: <1615641043.98.0.951511177985.issue35883@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I wrote PR 24843 to fix this issue. With this fix, os.fsencode(sys.argv[1]) returns the original byte sequence as expected.

--

I dislike the replace error handler since it loses information. The PEP 383 surrogateescape error handler exists to prevent losing information.

The root issue is that Py_DecodeLocale() creates wide characters outside Python Unicode valid range: [U+0000; U+10ffff].

On Linux, Py_DecodeLocale() usually calls mbstowcs() of the C library. The problem is that the the glibc UTF-8 decoder doesn't respect the RFC 3629, it doesn't reject characters outside [U+0000; U+10ffff] range. The following issue requests to change the glibc UTF-8 codec to respect the RFC 3629, but it's open since 2006:
https://sourceware.org/bugzilla/show_bug.cgi?id=2373

Even if the glibc changes, Python should behave the same on old glibc version.

My PEP modifies Py_DecodeLocale() to check if there are characters outside [U+0000; U+10ffff] range and use the surrogateescape error handler in that case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35883>
_______________________________________

From report at bugs.python.org  Sat Mar 13 08:14:45 2021
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 13 Mar 2021 13:14:45 +0000
Subject: [issue43479] Remove a duplicate comment and assignment in http.client
In-Reply-To: <1615546113.27.0.0553252720004.issue43479@roundup.psfhosted.org>
Message-ID: <1615641285.98.0.45254636382.issue43479@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43479>
_______________________________________

From report at bugs.python.org  Sat Mar 13 08:15:20 2021
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 13 Mar 2021 13:15:20 +0000
Subject: [issue35883] Change invalid unicode characters to replacement
 characters in argv
In-Reply-To: <1549040138.25.0.646545491344.issue35883@roundup.psfhosted.org>
Message-ID: <1615641320.82.0.621650967312.issue35883@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> https://bugs.python.org/issue25631 "Segmentation fault with invalid Unicode command-line arguments in embedded Python" (actually 'fixed' since it now abort()s)

This issue is different: it is about the Py_Main() function called explicitly when Python is embedded in an application. Python fails if the command line contains a *wide character* outside the [U+0000; U+10ffff] range.

This issue is about Python on Linux in which case Py_BytesMain() is used to decode *bytes* from the command line.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35883>
_______________________________________

From report at bugs.python.org  Sat Mar 13 08:16:01 2021
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 13 Mar 2021 13:16:01 +0000
Subject: [issue35883] Python startup fails with a fatal error if a command
 line argument contains an invalid Unicode character
In-Reply-To: <1549040138.25.0.646545491344.issue35883@roundup.psfhosted.org>
Message-ID: <1615641361.61.0.328838940648.issue35883@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: Change invalid unicode characters to replacement characters in argv -> Python startup fails with a fatal error if a command line argument contains an invalid Unicode character

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35883>
_______________________________________

From report at bugs.python.org  Sat Mar 13 08:19:29 2021
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 13 Mar 2021 13:19:29 +0000
Subject: [issue35883] Python startup fails with a fatal error if a command
 line argument contains an invalid Unicode character
In-Reply-To: <1549040138.25.0.646545491344.issue35883@roundup.psfhosted.org>
Message-ID: <1615641569.4.0.36167470291.issue35883@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> This shouldn't be an issue in 3.7, at least not with the default UTF-8 mode configuration. With this mode, Py_DecodeLocale calls _Py_DecodeUTF8Ex using the surrogateescape error handler [1].

Right, enabling explicitly the Python UTF-8 Mode works around the issue:
https://docs.python.org/dev/library/os.html#python-utf-8-mode


$ python3.10 -c 'import sys; print(ascii(sys.argv))' $'\U7fffbeba'
Fatal Python error: init_interp_main: failed to update the Python config
Python runtime state: core initialized
ValueError: character U+7fffbeba is not in range [U+0000; U+10ffff]

Current thread 0x00007effa1891740 (most recent call first):
<no Python frame>


$ python3.10 -X utf8 -c 'import sys; print(ascii(sys.argv))' $'\U7fffbeba'
['-c', '\udcfd\udcbf\udcbf\udcbb\udcba\udcba']

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35883>
_______________________________________

From report at bugs.python.org  Sat Mar 13 08:19:46 2021
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 13 Mar 2021 13:19:46 +0000
Subject: [issue43479] Remove a duplicate comment and assignment in http.client
In-Reply-To: <1615546113.27.0.0553252720004.issue43479@roundup.psfhosted.org>
Message-ID: <1615641586.41.0.471522829484.issue43479@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
stage: resolved -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43479>
_______________________________________

From report at bugs.python.org  Sat Mar 13 08:19:53 2021
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 13 Mar 2021 13:19:53 +0000
Subject: [issue43479] Remove a duplicate comment and assignment in http.client
In-Reply-To: <1615546113.27.0.0553252720004.issue43479@roundup.psfhosted.org>
Message-ID: <1615641593.69.0.113607740497.issue43479@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
stage:  -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43479>
_______________________________________

From report at bugs.python.org  Sat Mar 13 08:20:10 2021
From: report at bugs.python.org (Adam)
Date: Sat, 13 Mar 2021 13:20:10 +0000
Subject: [issue43486] Python 3.9 installer not updating ARP table
Message-ID: <1615641610.33.0.0630077237897.issue43486@roundup.psfhosted.org>


New submission from Adam <me at cookadam.co.uk>:

1. Install 3.9.0 using the following command line options: 

python-3.9.0.exe /quiet InstallAllUsers=1

2. Install 3.9.2 using the following command line options: 

python-3.9.2.exe /quiet InstallAllUsers=1

3. Observe that 3.9.2 successfully installed, however the ARP table does not reflect the latest version (see first screenshot in the attachment) it still shows 3.9.0 as installed.

4. Uninstall 3.9.2 using the following command line options:

python-3.9.2.exe /uninstall /silent

5. Observe that Python 3.9.0 is still listed as installed in the ARP table. Looking in the registry, all Python installed products are removed except for Python Launcher. Maybe it is by design to leave Python Launcher on the system, maybe not, but I think keeping the ARP table tidy would reduce confusion for users. See second screenshot in the attachment.

----------
components: Installation
files: 1.jpg
messages: 388615
nosy: codaamok
priority: normal
severity: normal
status: open
title: Python 3.9 installer not updating ARP table
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file49873/1.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43486>
_______________________________________

From report at bugs.python.org  Sat Mar 13 08:22:06 2021
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 13 Mar 2021 13:22:06 +0000
Subject: [issue35883] Python startup fails with a fatal error if a command
 line argument contains an invalid Unicode character
In-Reply-To: <1549040138.25.0.646545491344.issue35883@roundup.psfhosted.org>
Message-ID: <1615641726.88.0.951938719375.issue35883@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Right, enabling explicitly the Python UTF-8 Mode works around the issue

When the Python UTF-8 Mode is used, on macOS or on Android, Python uses its own UTF-8 decoder which respects the RFC 3629: it rejects characters outside [U+0000; U+10ffff].

Otherwise, Python relies on the libc mbstowcs() decoder which may or may not create characters outside the [U+0000; U+10ffff] range. I understand that this issue is mostly about the UTF-8 encoding, I don't think that other encodings can produce characters greater than U+10ffff code point.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35883>
_______________________________________

From report at bugs.python.org  Sat Mar 13 08:23:31 2021
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 13 Mar 2021 13:23:31 +0000
Subject: [issue23835] configparser does not convert defaults to strings
In-Reply-To: <1427862188.44.0.00358189102447.issue23835@psf.upfronthosting.co.za>
Message-ID: <1615641811.8.0.017646915227.issue23835@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests:  -23600

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23835>
_______________________________________

From report at bugs.python.org  Sat Mar 13 08:25:31 2021
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 13 Mar 2021 13:25:31 +0000
Subject: [issue40521] [subinterpreters] Make free lists and unicode caches
 per-interpreter
In-Reply-To: <1588693682.5.0.219755904926.issue40521@roundup.psfhosted.org>
Message-ID: <1615641931.34.0.946286542396.issue40521@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 5bd1059184b154d339f1bd53d23c98b5bcf14c8c by junyixie in branch 'master':
bpo-40521: Make dtoa bigint free list per-interpreter (GH-24821)
https://github.com/python/cpython/commit/5bd1059184b154d339f1bd53d23c98b5bcf14c8c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40521>
_______________________________________

From report at bugs.python.org  Sat Mar 13 08:34:43 2021
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 13 Mar 2021 13:34:43 +0000
Subject: [issue37788] fix for bpo-36402 (threading._shutdown() race condition)
 causes reference leak
In-Reply-To: <1565194972.64.0.065323919799.issue37788@roundup.psfhosted.org>
Message-ID: <1615642483.51.0.83074697179.issue37788@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Oh, I'm confused. This issue is about the threading module, whereas bpo-37193 is unrelated: it's about the socketserver module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37788>
_______________________________________

From report at bugs.python.org  Sat Mar 13 08:38:43 2021
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 13 Mar 2021 13:38:43 +0000
Subject: [issue43441] [Subinterpreters]: global variable next_version_tag
 cause method cache bug
In-Reply-To: <1615262084.5.0.815014213556.issue43441@roundup.psfhosted.org>
Message-ID: <1615642723.3.0.114291653989.issue43441@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 75048c8a38005845f10f8cb1dd33a31e0052cae0 by junyixie in branch 'master':
bpo-43441: Fix _PyType_ClearCache() for subinterpreters (GH-24822)
https://github.com/python/cpython/commit/75048c8a38005845f10f8cb1dd33a31e0052cae0


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43441>
_______________________________________

From report at bugs.python.org  Sat Mar 13 08:39:17 2021
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 13 Mar 2021 13:39:17 +0000
Subject: [issue43441] [Subinterpreters]: global variable next_version_tag
 cause method cache bug
In-Reply-To: <1615262084.5.0.815014213556.issue43441@roundup.psfhosted.org>
Message-ID: <1615642757.95.0.74794111597.issue43441@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/issue43441>
_______________________________________

From report at bugs.python.org  Sat Mar 13 09:33:30 2021
From: report at bugs.python.org (Nicholas Smith)
Date: Sat, 13 Mar 2021 14:33:30 +0000
Subject: [issue30491] Add a lightweight mechanism for detecting un-awaited
 coroutine objects
In-Reply-To: <1495867380.86.0.533205071954.issue30491@psf.upfronthosting.co.za>
Message-ID: <1615646010.0.0.831597333692.issue30491@roundup.psfhosted.org>


Change by Nicholas Smith <nzsmith at gmail.com>:


----------
nosy: +nzsmith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30491>
_______________________________________

From report at bugs.python.org  Sat Mar 13 10:01:10 2021
From: report at bugs.python.org (Adam)
Date: Sat, 13 Mar 2021 15:01:10 +0000
Subject: [issue43486] Python 3.9 installer not updating ARP table
In-Reply-To: <1615641610.33.0.0630077237897.issue43486@roundup.psfhosted.org>
Message-ID: <1615647670.13.0.732016692377.issue43486@roundup.psfhosted.org>


Adam <me at cookadam.co.uk> added the comment:

The 64 installer doesn't even show up in the ARP table, only Python Launcher.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43486>
_______________________________________

From report at bugs.python.org  Sat Mar 13 10:04:10 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 13 Mar 2021 15:04:10 +0000
Subject: [issue30491] Add a lightweight mechanism for detecting un-awaited
 coroutine objects
In-Reply-To: <1495867380.86.0.533205071954.issue30491@psf.upfronthosting.co.za>
Message-ID: <1615647850.27.0.786473969691.issue30491@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The most common error is missing keyword "await" in function call. "f()" instead of "await f()".

There is a way to detect this error at runtime with minimal false positive and with minimal overhead. We can add a new opcode which checks if the value on the top of the stack is awaitable and raise warning/error in that case, and add it after every functional call whose result is ignored in asynchronous functions. It could even be merged with POP_TOP to reduce overhead.

    CALL_FUNCTION ...
    WARN_IF_AWAITABLE_AND_POP_TOP

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30491>
_______________________________________

From report at bugs.python.org  Sat Mar 13 10:25:16 2021
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 13 Mar 2021 15:25:16 +0000
Subject: [issue43486] Python 3.9 installer not updating ARP table
In-Reply-To: <1615641610.33.0.0630077237897.issue43486@roundup.psfhosted.org>
Message-ID: <1615649116.51.0.832761220124.issue43486@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43486>
_______________________________________

From report at bugs.python.org  Sat Mar 13 10:31:31 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 13 Mar 2021 15:31:31 +0000
Subject: [issue43411] wm_manage fails with ttk.Frame
In-Reply-To: <1614972319.75.0.638524894464.issue43411@roundup.psfhosted.org>
Message-ID: <1615649491.97.0.842677792251.issue43411@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Minor correction: Tk does not generate names as digit sequences. Its syntax requires a name to be always specified. Past versions of Tkinter generated names as digit sequences, now it generates more readable and informative names.

If we ever add documentation for wm_manage it would be nice to mention explicitly that it does not work with corresponding ttk widgets.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
priority: normal -> low
type: behavior -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43411>
_______________________________________

From report at bugs.python.org  Sat Mar 13 10:34:03 2021
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 13 Mar 2021 15:34:03 +0000
Subject: [issue43444] [sqlite3] Move MODULE_NAME def from setup.py to module.h
In-Reply-To: <1615286059.68.0.212415918598.issue43444@roundup.psfhosted.org>
Message-ID: <1615649643.16.0.328706468964.issue43444@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Thank you!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43444>
_______________________________________

From report at bugs.python.org  Sat Mar 13 10:33:46 2021
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 13 Mar 2021 15:33:46 +0000
Subject: [issue43444] [sqlite3] Move MODULE_NAME def from setup.py to module.h
In-Reply-To: <1615286059.68.0.212415918598.issue43444@roundup.psfhosted.org>
Message-ID: <1615649626.92.0.469434522822.issue43444@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 2256a2876b5214a5a7492bf78bd86cf8beb690bf by Erlend Egeberg Aasland in branch 'master':
bpo-43444: Move sqlite3 MODULE_NAME from setup.py to module.h (GH-24801)
https://github.com/python/cpython/commit/2256a2876b5214a5a7492bf78bd86cf8beb690bf


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43444>
_______________________________________

From report at bugs.python.org  Sat Mar 13 10:35:07 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 13 Mar 2021 15:35:07 +0000
Subject: [issue30491] Add a lightweight mechanism for detecting un-awaited
 coroutine objects
In-Reply-To: <1495867380.86.0.533205071954.issue30491@psf.upfronthosting.co.za>
Message-ID: <1615649707.56.0.753394083928.issue30491@roundup.psfhosted.org>


Guido van Rossum <gvanrossum at gmail.com> added the comment:

Serhiy, that?s brilliant! Let?s do it.

----------
nosy: +Guido.van.Rossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30491>
_______________________________________

From report at bugs.python.org  Sat Mar 13 10:56:17 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 13 Mar 2021 15:56:17 +0000
Subject: [issue26362] Approved API for creating a temporary file path
In-Reply-To: <1455502271.6.0.558905453707.issue26362@psf.upfronthosting.co.za>
Message-ID: <1615650977.06.0.472239842409.issue26362@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This function would increase security risks. Even if it will be documented as "This function is only purposed to generate file paths which looks similar to paths of temporary files generated by other functions in this module, but should not be used for any access to filesystem", it would be used to generate file paths and opening files with these paths by users which do not read documentation and do not know the right way (because they do not read documentation).

It has flaws which require to deprecate it from start.

If you want to shoot in your foot, just use private generator function tempfile._get_candidate_names(). But it should not be encouraged.

I am for closing this issue by rejecting the proposition.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26362>
_______________________________________

From report at bugs.python.org  Sat Mar 13 11:14:46 2021
From: report at bugs.python.org (Bart Broere)
Date: Sat, 13 Mar 2021 16:14:46 +0000
Subject: [issue43487] Rename __unicode__ methods to __str__ in 2to3 conversion
Message-ID: <1615652086.71.0.102921679786.issue43487@roundup.psfhosted.org>


New submission from Bart Broere <mail at bartbroere.eu>:

While porting a (Django) code base recently, using 2to3, I missed the conversion from __unicode__ to __str__. I have created my own 2to3 fixer, which might be useful for other people.

If it's not useful enough to be included in lib2to3, or has side effects that I did not foresee, please let me know :-)

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 388627
nosy: bartbroere
priority: normal
severity: normal
status: open
title: Rename __unicode__ methods to __str__ in 2to3 conversion
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43487>
_______________________________________

From report at bugs.python.org  Sat Mar 13 11:16:14 2021
From: report at bugs.python.org (Bart Broere)
Date: Sat, 13 Mar 2021 16:16:14 +0000
Subject: [issue43487] Rename __unicode__ methods to __str__ in 2to3 conversion
In-Reply-To: <1615652086.71.0.102921679786.issue43487@roundup.psfhosted.org>
Message-ID: <1615652174.3.0.973670891619.issue43487@roundup.psfhosted.org>


Change by Bart Broere <mail at bartbroere.eu>:


----------
keywords: +patch
pull_requests: +23607
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24844

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43487>
_______________________________________

From report at bugs.python.org  Sat Mar 13 11:21:43 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 13 Mar 2021 16:21:43 +0000
Subject: [issue43267] [sqlite3] Redundant type checks in
 pysqlite_statement_bind_parameter()
In-Reply-To: <1613731536.26.0.545379664561.issue43267@roundup.psfhosted.org>
Message-ID: <1615652503.44.0.640989141758.issue43267@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I would not add such "optimization", but it is up to Berker to keep or remove it. Please create a PR for review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43267>
_______________________________________

From report at bugs.python.org  Sat Mar 13 11:31:59 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 13 Mar 2021 16:31:59 +0000
Subject: [issue43428] Sync importlib_metadata enhancements through 3.7.
In-Reply-To: <1615157667.11.0.27235417477.issue43428@roundup.psfhosted.org>
Message-ID: <1615653119.48.0.85193696758.issue43428@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:


New changeset f917efccf8d5aa2b8315d2a832a520339e668187 by Jason R. Coombs in branch 'master':
bpo-43428: Sync with importlib_metadata 3.7. (GH-24782)
https://github.com/python/cpython/commit/f917efccf8d5aa2b8315d2a832a520339e668187


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43428>
_______________________________________

From report at bugs.python.org  Sat Mar 13 13:14:22 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 13 Mar 2021 18:14:22 +0000
Subject: [issue25117] Windows installer: precompiling stdlib fails with
 missing DLL errors
In-Reply-To: <1442294819.71.0.839651529049.issue25117@psf.upfronthosting.co.za>
Message-ID: <1615659262.97.0.161136333539.issue25117@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

Maybe it's worth adding a recommendation in the docs to reboot and try to repair an installation that fails in the final stage due to ucrt not being fully installed yet, i.e. missing api-ms-win-crt-*.dll. Or maybe this case can be detected and display a message box to that end.

----------
type:  -> behavior
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25117>
_______________________________________

From report at bugs.python.org  Sat Mar 13 13:18:11 2021
From: report at bugs.python.org (Ehsonjon Gadoev)
Date: Sat, 13 Mar 2021 18:18:11 +0000
Subject: [issue43488] Added new methods to vectors.py
Message-ID: <1615659491.16.0.390257567336.issue43488@roundup.psfhosted.org>


New submission from Ehsonjon Gadoev <ehsonjonazimi05 at gmail.com>:

What's new in Vector (vector.py)

1) Added multiplay (Vector and Vector)
2) Added division (Vector and Vector) and (Vector and scalar)
3) Added FloorDiv (Vector and Vector) and (Vector and scalar)
4) Added __mod__ (Vector and Vector) and (Vector and scalar)

This new methods is very useful!
[It is beta version! By the way we will fix bugs]

----------
components: Demos and Tools
hgrepos: 402
messages: 388631
nosy: Ehsonjon Gadoev
priority: normal
pull_requests: 23608
severity: normal
status: open
title: Added new methods to vectors.py
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43488>
_______________________________________

From report at bugs.python.org  Sat Mar 13 13:20:37 2021
From: report at bugs.python.org (mattip)
Date: Sat, 13 Mar 2021 18:20:37 +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: <1615659637.44.0.797566357466.issue42752@roundup.psfhosted.org>


mattip <matti.picus at gmail.com> added the comment:

@crazycasta could you turn your patches into a PR? I am not sure how to get some eyes on this, but certainly the test is useful to prove the problem still exits

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42752>
_______________________________________

From report at bugs.python.org  Sat Mar 13 13:49:44 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 13 Mar 2021 18:49:44 +0000
Subject: [issue25166] Windows AllUsers installation places uninstaller in user
 profile
In-Reply-To: <1442575090.58.0.314641407957.issue25166@psf.upfronthosting.co.za>
Message-ID: <1615661384.03.0.0565757142359.issue25166@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
versions: +Python 3.10, Python 3.9 -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25166>
_______________________________________

From report at bugs.python.org  Sat Mar 13 13:58:35 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 13 Mar 2021 18:58:35 +0000
Subject: [issue28344] Python 3.5.2 installer hangs when run in session 0
In-Reply-To: <1475475284.89.0.546394834548.issue28344@psf.upfronthosting.co.za>
Message-ID: <1615661915.92.0.535662529167.issue28344@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

I tested installing 3.10 in session 0 for the current user, as a user with the batch logon right. The installation succeeded. If you're running as SYSTEM, then installing for the current user doesn't see reasonable to me. I won't test that case. 

I tested installing 3.10 in session 0 as SYSTEM, with the option InstallAllUsers=1. The installation succeeded. There's a caveat (bpo-25166) that the installer registers the uninstall record only for the current user. The SYSTEM account uses the default profile, so the uninstall record is stored under "HKU\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Uninstall". In this case, to uninstall you have to run the installer as SYSTEM with the /uninstall option.

----------
resolution:  -> works for me
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28344>
_______________________________________

From report at bugs.python.org  Sat Mar 13 14:04:43 2021
From: report at bugs.python.org (Kamil Turek)
Date: Sat, 13 Mar 2021 19:04:43 +0000
Subject: [issue43010] @functools.wraps and abc.abstractmethod interoperability
In-Reply-To: <1611411971.69.0.738980453065.issue43010@roundup.psfhosted.org>
Message-ID: <1615662283.92.0.304095152507.issue43010@roundup.psfhosted.org>


Change by Kamil Turek <tazzu at live.com>:


----------
nosy: +kamilturek

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43010>
_______________________________________

From report at bugs.python.org  Sat Mar 13 14:09:46 2021
From: report at bugs.python.org (Kamil Turek)
Date: Sat, 13 Mar 2021 19:09:46 +0000
Subject: [issue15373] copy.copy() does not properly copy os.environment
In-Reply-To: <1342454937.95.0.386630033182.issue15373@psf.upfronthosting.co.za>
Message-ID: <1615662586.17.0.554315193851.issue15373@roundup.psfhosted.org>


Change by Kamil Turek <tazzu at live.com>:


----------
nosy: +kamilturek

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15373>
_______________________________________

From report at bugs.python.org  Sat Mar 13 14:20:26 2021
From: report at bugs.python.org (Kamil Turek)
Date: Sat, 13 Mar 2021 19:20:26 +0000
Subject: [issue31956] Add start and stop parameters to the array.index()
In-Reply-To: <1509966827.68.0.213398074469.issue31956@psf.upfronthosting.co.za>
Message-ID: <1615663226.09.0.517437066771.issue31956@roundup.psfhosted.org>


Change by Kamil Turek <tazzu at live.com>:


----------
nosy: +kamilturek

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31956>
_______________________________________

From report at bugs.python.org  Sat Mar 13 14:20:35 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 13 Mar 2021 19:20:35 +0000
Subject: [issue29124] Freeze fails to compile on windows
In-Reply-To: <1483206665.88.0.0421614971405.issue29124@psf.upfronthosting.co.za>
Message-ID: <1615663235.64.0.671625682136.issue29124@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29124>
_______________________________________

From report at bugs.python.org  Sat Mar 13 14:33:26 2021
From: report at bugs.python.org (Ehsonjon Gadoev)
Date: Sat, 13 Mar 2021 19:33:26 +0000
Subject: [issue43488] Added new methods to vector.py
In-Reply-To: <1615659491.16.0.390257567336.issue43488@roundup.psfhosted.org>
Message-ID: <1615664006.7.0.0677443488965.issue43488@roundup.psfhosted.org>


Change by Ehsonjon Gadoev <ehsonjonazimi05 at gmail.com>:


----------
title: Added new methods to vectors.py -> Added new methods to vector.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43488>
_______________________________________

From report at bugs.python.org  Sat Mar 13 14:38:13 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 13 Mar 2021 19:38:13 +0000
Subject: [issue29586] Cannot run pip in fresh install of py 3.5.3
In-Reply-To: <1487328483.09.0.366256272135.issue29586@psf.upfronthosting.co.za>
Message-ID: <1615664293.36.0.273832351536.issue29586@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

This issue is similar to bpo-25117 in terms of the installer failing to run Python for post-installation tasks. The complication in this case is that a subsequent repair doesn't install pip.

----------
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29586>
_______________________________________

From report at bugs.python.org  Sat Mar 13 15:48:24 2021
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 13 Mar 2021 20:48:24 +0000
Subject: [issue33159] Implement PEP 473
In-Reply-To: <1522179164.75.0.467229070634.issue33159@psf.upfronthosting.co.za>
Message-ID: <1615668504.97.0.185073864016.issue33159@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> added the comment:

The PEP has been rejected, so there is no big plan to add structured data to all exceptions, but you can open specific tickets and/or python-ideas discussions to add attributes to specific exceptions.

So I think this ticket should be closed, and a new one created to add NameError.name.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33159>
_______________________________________

From report at bugs.python.org  Sat Mar 13 15:58:30 2021
From: report at bugs.python.org (skreft)
Date: Sat, 13 Mar 2021 20:58:30 +0000
Subject: [issue33159] Implement PEP 473
In-Reply-To: <1522179164.75.0.467229070634.issue33159@psf.upfronthosting.co.za>
Message-ID: <1615669110.72.0.95880968854.issue33159@roundup.psfhosted.org>


Change by skreft <skreft at gmail.com>:


----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33159>
_______________________________________

From report at bugs.python.org  Sat Mar 13 16:13:55 2021
From: report at bugs.python.org (Hamza Avvan)
Date: Sat, 13 Mar 2021 21:13:55 +0000
Subject: [issue43223] [security] http.server: Open Redirection if the URL path
 starts with //
In-Reply-To: <1613302956.91.0.878390782912.issue43223@roundup.psfhosted.org>
Message-ID: <1615670035.3.0.835607170973.issue43223@roundup.psfhosted.org>


Change by Hamza Avvan <hamzaavvaan at gmail.com>:


----------
keywords: +patch
pull_requests: +23609
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24848

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43223>
_______________________________________

From report at bugs.python.org  Sat Mar 13 16:16:56 2021
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 13 Mar 2021 21:16:56 +0000
Subject: [issue31956] Add start and stop parameters to the array.index()
In-Reply-To: <1509966827.68.0.213398074469.issue31956@psf.upfronthosting.co.za>
Message-ID: <1615670216.43.0.480560644887.issue31956@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31956>
_______________________________________

From report at bugs.python.org  Sat Mar 13 16:25:40 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 13 Mar 2021 21:25:40 +0000
Subject: [issue43488] Added new methods to vector.py
In-Reply-To: <1615659491.16.0.390257567336.issue43488@roundup.psfhosted.org>
Message-ID: <1615670740.12.0.341014673271.issue43488@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I don't think this should be added.  The whole point of vector.py was to be a simple educational demo of a Python class its special methods work.  It was not intended to grow more features or ever be used in production.  

Also, vector-to-vector multiplication, division, and floordiv would only make sense for an elementwise array class.  This class focuses on standard vector operations.  If anything, what is missing is a method for a dot product.

Thank you for submitting a PR, but it is going to be declined from the reasons listed about.

----------
assignee:  -> rhettinger
nosy: +rhettinger
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43488>
_______________________________________

From report at bugs.python.org  Sat Mar 13 16:46:41 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 13 Mar 2021 21:46:41 +0000
Subject: [issue43427] Possible error on the descriptor howto guide
In-Reply-To: <1615131755.48.0.550524446603.issue43427@roundup.psfhosted.org>
Message-ID: <1615672001.14.0.428475378466.issue43427@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset f00e82f8b87c96ff76d6f768fa7a29cbd86eec6a by Raymond Hettinger in branch 'master':
bpo-43427:  Separte the method overview from the static method specifics. (GH-24787)
https://github.com/python/cpython/commit/f00e82f8b87c96ff76d6f768fa7a29cbd86eec6a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43427>
_______________________________________

From report at bugs.python.org  Sat Mar 13 16:46:44 2021
From: report at bugs.python.org (miss-islington)
Date: Sat, 13 Mar 2021 21:46:44 +0000
Subject: [issue43427] Possible error on the descriptor howto guide
In-Reply-To: <1615131755.48.0.550524446603.issue43427@roundup.psfhosted.org>
Message-ID: <1615672004.27.0.627506717829.issue43427@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: +23610
pull_request: https://github.com/python/cpython/pull/24849

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43427>
_______________________________________

From report at bugs.python.org  Sat Mar 13 17:05:16 2021
From: report at bugs.python.org (Anthony Sottile)
Date: Sat, 13 Mar 2021 22:05:16 +0000
Subject: [issue8978] "tarfile.ReadError: file could not be opened
 successfully" if compiled without zlib
In-Reply-To: <1276292933.37.0.137444086026.issue8978@psf.upfronthosting.co.za>
Message-ID: <1615673116.59.0.132258210031.issue8978@roundup.psfhosted.org>


Change by Anthony Sottile <asottile at umich.edu>:


----------
nosy: +Anthony Sottile
nosy_count: 7.0 -> 8.0
pull_requests: +23611
pull_request: https://github.com/python/cpython/pull/24850

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8978>
_______________________________________

From report at bugs.python.org  Sat Mar 13 17:21:53 2021
From: report at bugs.python.org (Matthew Hughes)
Date: Sat, 13 Mar 2021 22:21:53 +0000
Subject: [issue43322] Inconsistent '#include' notation in extensions tutorial
 doc
In-Reply-To: <1614269934.51.0.264833374893.issue43322@roundup.psfhosted.org>
Message-ID: <1615674113.6.0.731905650609.issue43322@roundup.psfhosted.org>


Change by Matthew Hughes <matthewhughes934 at gmail.com>:


----------
keywords: +patch
pull_requests: +23612
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24851

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43322>
_______________________________________

From report at bugs.python.org  Sat Mar 13 17:29:18 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 13 Mar 2021 22:29:18 +0000
Subject: [issue27749] multiprocessing Manager error: send() called for a
 closed connection
In-Reply-To: <1471028370.6.0.516756873542.issue27749@psf.upfronthosting.co.za>
Message-ID: <1615674558.09.0.772856520044.issue27749@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
title: multprocessing errors on Windows: WriteFile() argument 1 must be int, not None; OSError: handle is closed -> multiprocessing Manager error:  send() called for a closed connection
type: crash -> behavior
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.5, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27749>
_______________________________________

From report at bugs.python.org  Sat Mar 13 18:46:39 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 13 Mar 2021 23:46:39 +0000
Subject: [issue43199] FAQ about goto lacks answer
In-Reply-To: <1613036693.06.0.0717598867229.issue43199@roundup.psfhosted.org>
Message-ID: <1615679199.19.0.662038647181.issue43199@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
keywords: +patch
nosy: +terry.reedy
nosy_count: 2.0 -> 3.0
pull_requests: +23613
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24852

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43199>
_______________________________________

From report at bugs.python.org  Sat Mar 13 18:49:17 2021
From: report at bugs.python.org (Larry Trammell)
Date: Sat, 13 Mar 2021 23:49:17 +0000
Subject: [issue43483] Loss of content in simple (but oversize) SAX parsing
In-Reply-To: <1615599352.35.0.560655392831.issue43483@roundup.psfhosted.org>
Message-ID: <1615679357.96.0.422940065812.issue43483@roundup.psfhosted.org>


Larry Trammell <ridgerat at nwi.net> added the comment:

Not a bug, strictly speaking... more like user abuse.

The parsers (expat as well as SAX) must be able to return content text as a sequence of pieces when necessary. For example, as a text sequence interrupted by grouping or styling tags (like <span> or <i>).  Or, extensive text blocks might need to be subdivided for efficient processing.  Users would expect hazards like these and be wary.  But how many users would suspect that a quoted string of length 8 characters would be returned in multiple pieces?  Or that an entity notation would be split down the middle?  Virtually all existing tutorial examples showing content extraction are WRONG -- because the ONLY content that can be trusted must be filtered through some kind of aggregator object.  How many users will know this instinctively?  

It would be very useful for the parser systems to provide some kind of support for text aggregation function.  A guarantee that "small contiguous" text items will not be chopped might also be helpful.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43483>
_______________________________________

From report at bugs.python.org  Sat Mar 13 18:58:50 2021
From: report at bugs.python.org (Facundo Batista)
Date: Sat, 13 Mar 2021 23:58:50 +0000
Subject: [issue24260] TabError behavior doesn't match documentation
In-Reply-To: <1432244751.77.0.187754601995.issue24260@psf.upfronthosting.co.za>
Message-ID: <1615679930.54.0.270529745805.issue24260@roundup.psfhosted.org>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Found this after seeing (once again) somebody asking for help in Python Argentina after having a file mixing tabs and spaces.

This tends to catch new people.

I'm +1 to just raise an error if the file mixes tabs and spaces for indentation. I've never seen a real usage case where it was not an accident, even if the mix was in different blocks, so it actually worked "fine" (and even in those cases, then the user copies lines around, and the program starts to behave weirdly).

----------
nosy: +facundobatista

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24260>
_______________________________________

From report at bugs.python.org  Sat Mar 13 19:48:30 2021
From: report at bugs.python.org (Dennis Sweeney)
Date: Sun, 14 Mar 2021 00:48:30 +0000
Subject: [issue43010] @functools.wraps and abc.abstractmethod interoperability
In-Reply-To: <1611411971.69.0.738980453065.issue43010@roundup.psfhosted.org>
Message-ID: <1615682910.96.0.512881559829.issue43010@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

I don't think changing @wraps is what you want. Even if you manually set `wrapper.__isabstractmethod__ = False`, you won't reach `print('f is called!')`, since f() is overridden by the child. And if you do that, the ABC wouldn't have any abstract methods, since the name A.f points to the function defined at `def wrapper()`.

If I understand correctly, you want to modify the behavior of a method while also having it be abstract. These two goals are sort of in tension with one another, since defining f as abstract means your implementation won't be used, yet you want to specify part of the implementation. One solution would be to modify the subclass's methods to do what you want when the subclass is created.


from abc import ABC, abstractmethod
from functools import wraps

class A(ABC):
    @abstractmethod
    def f(self):
        pass

    def __init_subclass__(cls, **class_kwargs):
        old_f = cls.f
        @wraps(old_f)
        def wrapper(*args, **kwargs):
            print("f is called!")
            old_f(*args, **kwargs)
        cls.f = wrapper
        super().__init_subclass__()

class B(A):
    def f(self):
        print('f!')

class C(A):
    pass

B().f()
# f is called!
# f!

C()
# TypeError: Can't instantiate abstract class C with abstract method f

----------
nosy: +Dennis Sweeney

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43010>
_______________________________________

From report at bugs.python.org  Sat Mar 13 19:51:28 2021
From: report at bugs.python.org (Dennis Sweeney)
Date: Sun, 14 Mar 2021 00:51:28 +0000
Subject: [issue43010] @functools.wraps and abc.abstractmethod interoperability
In-Reply-To: <1611411971.69.0.738980453065.issue43010@roundup.psfhosted.org>
Message-ID: <1615683088.87.0.706508289108.issue43010@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

> the ABC wouldn't have any abstract methods,

I was wrong about this since the @abstractmethod decorator adds 'f' to the __abstractmethods__ set of the ABC, but the rest of my comment stands.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43010>
_______________________________________

From report at bugs.python.org  Sat Mar 13 19:56:59 2021
From: report at bugs.python.org (Adrian LeDeaux)
Date: Sun, 14 Mar 2021 00:56:59 +0000
Subject: [issue43489] Can't install, nothing to install
Message-ID: <1615683419.81.0.261055415418.issue43489@roundup.psfhosted.org>


New submission from Adrian LeDeaux <aledeaux at gmail.com>:

Python 2.7 won't install. I get the error "there is nothing to install" or something to that effect. I am using MacOS High Sierra 10.13.6. I tried both installer downloads. None worked. And I got the same error every time. Anyone have any ideas on what is going on?

----------
messages: 388642
nosy: aledeaux
priority: normal
severity: normal
status: open
title: Can't install, nothing to install

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43489>
_______________________________________

From report at bugs.python.org  Sat Mar 13 20:18:14 2021
From: report at bugs.python.org (Adrian LeDeaux)
Date: Sun, 14 Mar 2021 01:18:14 +0000
Subject: [issue43490] IDLE freezes at random
Message-ID: <1615684694.01.0.00673865405837.issue43490@roundup.psfhosted.org>


New submission from Adrian LeDeaux <aledeaux at gmail.com>:

My IDLE shell keeps freezing when using the turtle module. I am using MacOS High Sierra 13.10.6. It says it is fine, but I can't get the window open. I have to restart the shell entirely. I can't type or do anything. I have to do the [command]+[Q] shortcut and then open the app again. Any ideas?

----------
messages: 388643
nosy: aledeaux
priority: normal
severity: normal
status: open
title: IDLE freezes at random
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43490>
_______________________________________

From report at bugs.python.org  Sat Mar 13 20:44:50 2021
From: report at bugs.python.org (Adrian LeDeaux)
Date: Sun, 14 Mar 2021 01:44:50 +0000
Subject: [issue43490] IDLE freezes at random
In-Reply-To: <1615684694.01.0.00673865405837.issue43490@roundup.psfhosted.org>
Message-ID: <1615686290.14.0.278283325968.issue43490@roundup.psfhosted.org>


Adrian LeDeaux <aledeaux at gmail.com> added the comment:

Only when using the turtle module does it happen.

----------
type:  -> behavior
versions:  -Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43490>
_______________________________________

From report at bugs.python.org  Sat Mar 13 20:57:43 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 14 Mar 2021 01:57:43 +0000
Subject: [issue42988] [security] CVE-2021-3426: Information disclosure via
 pydoc -p: /getfile?key=path allows to read arbitrary file on the filesystem
In-Reply-To: <1611231517.86.0.296188996897.issue42988@roundup.psfhosted.org>
Message-ID: <1615687063.32.0.757634019232.issue42988@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

FWIW, I don't think we should even have a server feature in pydoc...

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42988>
_______________________________________

From report at bugs.python.org  Sat Mar 13 21:05:39 2021
From: report at bugs.python.org (Thomas)
Date: Sun, 14 Mar 2021 02:05:39 +0000
Subject: [issue43477] from x import * behavior inconsistent between module
 types.
In-Reply-To: <1615509638.08.0.549124406797.issue43477@roundup.psfhosted.org>
Message-ID: <1615687539.48.0.707442248689.issue43477@roundup.psfhosted.org>


Thomas <kaori.hinata at gmail.com> added the comment:

I've spent a bit of time building (and rebuilding) Python 3.9 with a modified `Lib/importlib/_bootstrap.py`/regenerated `importlib.h` to give me some extra logging, and believe the answer I was looking for is `_find_and_load_unlocked`. `_find_and_load_unlocked` appears to load the module in question, and always attach it to the parent regardless of the contents of `fromlist` (`_find_and_load_unlocked` isn't even aware of `fromlist`.) The only real condition seems to be "is there a parent/are we in a package?". `Lib/importlib/_bootstrap.py` is pretty sparsely documented so it's not immediately obvious whether or not some other piece of `importlib` depends on this behavior. If the author is known, then they may be able to give some insight into why the decision was made, and what the best solution would be?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43477>
_______________________________________

From report at bugs.python.org  Sat Mar 13 21:22:03 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 14 Mar 2021 02:22:03 +0000
Subject: [issue41200] Add pickle.loads fuzz test
In-Reply-To: <1593773289.43.0.165410950375.issue41200@roundup.psfhosted.org>
Message-ID: <1615688523.96.0.519725470341.issue41200@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41200>
_______________________________________

From report at bugs.python.org  Sat Mar 13 21:25:00 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 14 Mar 2021 02:25:00 +0000
Subject: [issue35278] [security] directory traversal in tempfile prefix
In-Reply-To: <1542631563.19.0.788709270274.issue35278@psf.upfronthosting.co.za>
Message-ID: <1615688700.06.0.656024910903.issue35278@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
versions: +Python 3.10, Python 3.6, Python 3.7, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35278>
_______________________________________

From report at bugs.python.org  Sat Mar 13 21:31:44 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 14 Mar 2021 02:31:44 +0000
Subject: [issue43427] Possible error on the descriptor howto guide
In-Reply-To: <1615131755.48.0.550524446603.issue43427@roundup.psfhosted.org>
Message-ID: <1615689104.76.0.555322916497.issue43427@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 45d9c8cda3db7da9fe209bd215ec9a120265ee65 by Miss Islington (bot) in branch '3.9':
bpo-43427:  Separte the method overview from the static method specifics. (GH-24787) (GH-24849)
https://github.com/python/cpython/commit/45d9c8cda3db7da9fe209bd215ec9a120265ee65


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43427>
_______________________________________

From report at bugs.python.org  Sat Mar 13 21:32:10 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 14 Mar 2021 02:32:10 +0000
Subject: [issue43427] Possible error on the descriptor howto guide
In-Reply-To: <1615131755.48.0.550524446603.issue43427@roundup.psfhosted.org>
Message-ID: <1615689130.82.0.317664126574.issue43427@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43427>
_______________________________________

From report at bugs.python.org  Sat Mar 13 21:33:42 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 14 Mar 2021 02:33:42 +0000
Subject: [issue43490] IDLE freezes at random
In-Reply-To: <1615684694.01.0.00673865405837.issue43490@roundup.psfhosted.org>
Message-ID: <1615689222.61.0.358986720247.issue43490@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Are on an Intel processor or Apple Silicon?

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43490>
_______________________________________

From report at bugs.python.org  Sat Mar 13 21:35:09 2021
From: report at bugs.python.org (Adrian LeDeaux)
Date: Sun, 14 Mar 2021 02:35:09 +0000
Subject: [issue43490] IDLE freezes at random
In-Reply-To: <1615684694.01.0.00673865405837.issue43490@roundup.psfhosted.org>
Message-ID: <1615689309.11.0.488034130068.issue43490@roundup.psfhosted.org>


Adrian LeDeaux <aledeaux at gmail.com> added the comment:

My processor is Intel core 2 duo.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43490>
_______________________________________

From report at bugs.python.org  Sat Mar 13 21:49:17 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 14 Mar 2021 02:49:17 +0000
Subject: [issue43477] from x import * behavior inconsistent between module
 types.
In-Reply-To: <1615509638.08.0.549124406797.issue43477@roundup.psfhosted.org>
Message-ID: <1615690157.93.0.0300845112772.issue43477@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

"git blame" will help you identify the authors. It looks there are 5 people involved: Brett, Antoine, Nick, Eric Snow, and Dino.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43477>
_______________________________________

From report at bugs.python.org  Sat Mar 13 22:04:54 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 14 Mar 2021 03:04:54 +0000
Subject: [issue43439] [security] Add audit events on GC functions giving
 access to all Python objects
In-Reply-To: <1615235548.58.0.659993767767.issue43439@roundup.psfhosted.org>
Message-ID: <1615691094.95.0.498715703311.issue43439@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 9c376bc1c4c8bcddb0bc4196b79ec8c75da494a8 by Pablo Galindo in branch 'master':
bpo-43439: Wrapt the tuple in the audit events for the gc module (GH-24836)
https://github.com/python/cpython/commit/9c376bc1c4c8bcddb0bc4196b79ec8c75da494a8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43439>
_______________________________________

From report at bugs.python.org  Sat Mar 13 22:15:50 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 14 Mar 2021 03:15:50 +0000
Subject: [issue43245] Add keyword argument support to ChainMap.new_child()
In-Reply-To: <1613591324.63.0.830748384561.issue43245@roundup.psfhosted.org>
Message-ID: <1615691750.21.0.556769795548.issue43245@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 9923df96413a0b480a34ec1d537b66ca0eeb0fdc by Kamil Turek in branch 'master':
bpo-43245: Add keyword argument support to ChainMap.new_child() (GH-24788)
https://github.com/python/cpython/commit/9923df96413a0b480a34ec1d537b66ca0eeb0fdc


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43245>
_______________________________________

From report at bugs.python.org  Sat Mar 13 22:16:08 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 14 Mar 2021 03:16:08 +0000
Subject: [issue43245] Add keyword argument support to ChainMap.new_child()
In-Reply-To: <1613591324.63.0.830748384561.issue43245@roundup.psfhosted.org>
Message-ID: <1615691768.55.0.860863504446.issue43245@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/issue43245>
_______________________________________

From report at bugs.python.org  Sat Mar 13 22:38:25 2021
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 14 Mar 2021 03:38:25 +0000
Subject: [issue43489] Can't install, nothing to install
In-Reply-To: <1615683419.81.0.261055415418.issue43489@roundup.psfhosted.org>
Message-ID: <1615693105.09.0.0276917605296.issue43489@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Please don't ask us to guess what you are doing.

Where are you getting "both installer downloads" from? What installers are they?

How are you running the installers?

What is the actual error message please, not "something to that effect". If necessary, take a screen shot, although copying and pasting the text might be better.

Also, Python 2.7 is no longer supported -- we are unlikely to fix any problems even if you report them in sufficient detail. Can you not use version 3.9 instead?

You might consider asking for help on a community forum such as the Python-List mailing list, the Python Discuss, or Reddit's r/python. But they will ask you to provide better information too, and will likely also tell you to install a newer version.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43489>
_______________________________________

From report at bugs.python.org  Sat Mar 13 22:38:55 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 14 Mar 2021 03:38:55 +0000
Subject: [issue43410] Parser does not handle correctly some errors when parsin
 from stdin
In-Reply-To: <1614964955.39.0.913568985121.issue43410@roundup.psfhosted.org>
Message-ID: <1615693135.13.0.367799970407.issue43410@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset cd8dcbc851fcc312722cdb5544c2f25cf46b3f8a by Pablo Galindo in branch 'master':
bpo-43410: Fix crash in the parser when producing syntax errors when reading from stdin (GH-24763)
https://github.com/python/cpython/commit/cd8dcbc851fcc312722cdb5544c2f25cf46b3f8a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43410>
_______________________________________

From report at bugs.python.org  Sat Mar 13 22:39:08 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 14 Mar 2021 03:39:08 +0000
Subject: [issue43410] Parser does not handle correctly some errors when parsin
 from stdin
In-Reply-To: <1614964955.39.0.913568985121.issue43410@roundup.psfhosted.org>
Message-ID: <1615693148.65.0.362707757418.issue43410@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43410>
_______________________________________

From report at bugs.python.org  Sat Mar 13 22:46:43 2021
From: report at bugs.python.org (Adrian LeDeaux)
Date: Sun, 14 Mar 2021 03:46:43 +0000
Subject: [issue43489] Can't install, nothing to install
In-Reply-To: <1615683419.81.0.261055415418.issue43489@roundup.psfhosted.org>
Message-ID: <1615693603.48.0.157559768457.issue43489@roundup.psfhosted.org>


Adrian LeDeaux <aledeaux at gmail.com> added the comment:

First, I am not asking for guesses. I am getting the installers from the www.python.org website, and I am running them with the MacOS installer app. The format is .mpkg

----------
Added file: https://bugs.python.org/file49874/Screen Shot 2021-03-13 at 8.45.18 PM.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43489>
_______________________________________

From report at bugs.python.org  Sat Mar 13 23:04:25 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 14 Mar 2021 04:04:25 +0000
Subject: [issue43439] [security] Add audit events on GC functions giving
 access to all Python objects
In-Reply-To: <1615235548.58.0.659993767767.issue43439@roundup.psfhosted.org>
Message-ID: <1615694665.22.0.239347080959.issue43439@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +23614
pull_request: https://github.com/python/cpython/pull/24854

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43439>
_______________________________________

From report at bugs.python.org  Sat Mar 13 23:05:10 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 14 Mar 2021 04:05:10 +0000
Subject: [issue43439] [security] Add audit events on GC functions giving
 access to all Python objects
In-Reply-To: <1615235548.58.0.659993767767.issue43439@roundup.psfhosted.org>
Message-ID: <1615694710.71.0.366574350113.issue43439@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +23615
pull_request: https://github.com/python/cpython/pull/24855

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43439>
_______________________________________

From report at bugs.python.org  Sat Mar 13 23:30:46 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 14 Mar 2021 04:30:46 +0000
Subject: [issue43439] [security] Add audit events on GC functions giving
 access to all Python objects
In-Reply-To: <1615235548.58.0.659993767767.issue43439@roundup.psfhosted.org>
Message-ID: <1615696246.26.0.440713564606.issue43439@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 1e7a47ab86d5d6a5103e67ba71389f6daa18ea2d by Pablo Galindo in branch '3.8':
[3.8] bpo-43439: Wrapt the tuple in the audit events for the gc module (GH-24836) (GH24854)
https://github.com/python/cpython/commit/1e7a47ab86d5d6a5103e67ba71389f6daa18ea2d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43439>
_______________________________________

From report at bugs.python.org  Sat Mar 13 23:31:02 2021
From: report at bugs.python.org (Ned Deily)
Date: Sun, 14 Mar 2021 04:31:02 +0000
Subject: [issue43489] Can't install, nothing to install
In-Reply-To: <1615683419.81.0.261055415418.issue43489@roundup.psfhosted.org>
Message-ID: <1615696262.86.0.342474342643.issue43489@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Python 2.7.x reached end-of-life in early 2000 so it is no longer supported in any way.  That said, since you say the file extension is .mpkg and based on the behavior you describe, it sounds like you are trying to install a very old version of Python 2.7.  The last release of 2.7 was 2.7.18. The installer for macOS there should install and run on macOS 10.13.6.

https://www.python.org/downloads/release/python-2718/

----------
nosy: +ned.deily
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43489>
_______________________________________

From report at bugs.python.org  Sat Mar 13 23:31:33 2021
From: report at bugs.python.org (Thomas)
Date: Sun, 14 Mar 2021 04:31:33 +0000
Subject: [issue43477] from x import * behavior inconsistent between module
 types.
In-Reply-To: <1615509638.08.0.549124406797.issue43477@roundup.psfhosted.org>
Message-ID: <1615696293.52.0.967420199486.issue43477@roundup.psfhosted.org>


Thomas <kaori.hinata at gmail.com> added the comment:

Ahh, I always forget about blame.

Though the form was different, the initial commit of `importlib` (authored by Brett, so the nosy list seems fine for the moment) behaved the same way, and had an additional comment noting that the section in question was included to maintain backwards compatibility. I checked with Python 2.x and can confirm that this was how Python 2.x behaved as well (so I assume that's what the comment was for.)

I've tested simply commenting out that section (as, at a glance, I don't believe it will have any effect on explicit imports), and for the few scripts I tested with the backtraces were actually pretty clear: a lot of places in the standard library are accidentally relying on this quirk. collections doesn't import abc, importlib doesn't import machinery, concurrent doesn't import futures, etc, etc.

The easy, temporary fix would be to just add the necessary imports, then worry about `importlib`'s innards when the time comes to cross that bridge. That said, I know of only a few of the modules which will need imports added (the ones above, essentially), so I can't really say what the full scale of the work will be.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43477>
_______________________________________

From report at bugs.python.org  Sat Mar 13 23:32:11 2021
From: report at bugs.python.org (Ned Deily)
Date: Sun, 14 Mar 2021 04:32:11 +0000
Subject: [issue43489] Can't install, nothing to install
In-Reply-To: <1615683419.81.0.261055415418.issue43489@roundup.psfhosted.org>
Message-ID: <1615696331.88.0.228833275826.issue43489@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

er, make that early 2020 :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43489>
_______________________________________

From report at bugs.python.org  Sat Mar 13 23:32:53 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 14 Mar 2021 04:32:53 +0000
Subject: [issue43439] [security] Add audit events on GC functions giving
 access to all Python objects
In-Reply-To: <1615235548.58.0.659993767767.issue43439@roundup.psfhosted.org>
Message-ID: <1615696373.04.0.928236431251.issue43439@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/issue43439>
_______________________________________

From report at bugs.python.org  Sat Mar 13 23:33:44 2021
From: report at bugs.python.org (Adrian LeDeaux)
Date: Sun, 14 Mar 2021 04:33:44 +0000
Subject: [issue43489] Can't install, nothing to install
In-Reply-To: <1615683419.81.0.261055415418.issue43489@roundup.psfhosted.org>
Message-ID: <1615696424.09.0.460394596699.issue43489@roundup.psfhosted.org>


Adrian LeDeaux <aledeaux at gmail.com> added the comment:

The main reason I am trying to install this is because I want to use pygame. Is pygame compatible with version 2.7.28?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43489>
_______________________________________

From report at bugs.python.org  Sat Mar 13 23:37:18 2021
From: report at bugs.python.org (Ned Deily)
Date: Sun, 14 Mar 2021 04:37:18 +0000
Subject: [issue43490] IDLE freezes at random
In-Reply-To: <1615684694.01.0.00673865405837.issue43490@roundup.psfhosted.org>
Message-ID: <1615696638.48.0.939481586592.issue43490@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

What version of Python are you running? And from where did you get it?  Based on your other recent issue, it sounds like you may be trying to use an old version of Python 2.7, which is now retired.  If possible, try using a current supported version, like Python 3.9.2.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43490>
_______________________________________

From report at bugs.python.org  Sat Mar 13 23:41:28 2021
From: report at bugs.python.org (Ned Deily)
Date: Sun, 14 Mar 2021 04:41:28 +0000
Subject: [issue43334] venv does not install libpython
In-Reply-To: <1614379216.7.0.137032053148.issue43334@roundup.psfhosted.org>
Message-ID: <1615696888.87.0.212663294491.issue43334@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/issue43334>
_______________________________________

From report at bugs.python.org  Sun Mar 14 00:28:40 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 14 Mar 2021 05:28:40 +0000
Subject: [issue43439] [security] Add audit events on GC functions giving
 access to all Python objects
In-Reply-To: <1615235548.58.0.659993767767.issue43439@roundup.psfhosted.org>
Message-ID: <1615699720.85.0.222861698736.issue43439@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset e6bf1e1001a6844a36f2f90f58ab12b9e09e3887 by Pablo Galindo in branch '3.9':
[3.9] bpo-43439: Wrapt the tuple in the audit events for the gc module (GH-24836) (GH-24855)
https://github.com/python/cpython/commit/e6bf1e1001a6844a36f2f90f58ab12b9e09e3887


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43439>
_______________________________________

From report at bugs.python.org  Sun Mar 14 00:32:42 2021
From: report at bugs.python.org (Ned Deily)
Date: Sun, 14 Mar 2021 05:32:42 +0000
Subject: [issue43489] Can't install, nothing to install
In-Reply-To: <1615683419.81.0.261055415418.issue43489@roundup.psfhosted.org>
Message-ID: <1615699962.9.0.729383712789.issue43489@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

You?d have to check with the Pygame project. But a quick look at the PyPI entry for Pygame seems to indicate that they provide pip-installable binaries for all current versions of Python 3.

https://pypi.org/project/pygame/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43489>
_______________________________________

From report at bugs.python.org  Sun Mar 14 01:38:53 2021
From: report at bugs.python.org (Martin Panter)
Date: Sun, 14 Mar 2021 06:38:53 +0000
Subject: [issue34915] LWPCookieJar.save() creates *.lwp file in 644 mode
In-Reply-To: <1538834336.96.0.545547206417.issue34915@psf.upfronthosting.co.za>
Message-ID: <1615703933.96.0.192527925012.issue34915@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

I don't have a strong opinion, but it does seem a sensible change that matches the high-level nature of the "cookiejar" module, with low risk of users relying on the current file permissions. On the other hand, the "curl" command seems to use the default mode when creating a cookies file (in Netscape a.k.a. Mozilla format):

$ curl --cookie-jar cookies https://www.google.com/
[. . .]
$ ls -l cookies
-rw-r--r-- 1 vadmium vadmium 418 Mar 14 17:12 cookies

The MozillaCookieJar class also seems to use the default file mode. I suppose it should be changed as well as the LWP class.

----------
components:  -SSL

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34915>
_______________________________________

From report at bugs.python.org  Sun Mar 14 04:50:54 2021
From: report at bugs.python.org (yeting li)
Date: Sun, 14 Mar 2021 08:50:54 +0000
Subject: [issue43075] ReDoS in urllib.request
In-Reply-To: <1611994306.46.0.333529770265.issue43075@roundup.psfhosted.org>
Message-ID: <1615711854.11.0.172523061339.issue43075@roundup.psfhosted.org>


yeting li <liyt at ios.ac.cn> added the comment:

Sorry for the delay. I analyzed the performance of the current version '(?:^|,)[ \t]*([^ \t]+)[ \t]+' and the fixed version '(?:^|,)[ \t]*([^ \t,]+)[ \t]+'. I ran the following HTTP header ten times:

header = '' + ',' * (10 ** 5)

The current version takes about 139.178s-140.946s, while the repaired version takes about 0.006s.

You can analyze them with the code below.

    from time import perf_counter
    for _ in range(0, 10):
        BEGIN = perf_counter()
        header = repeat_10_5_simple
        headers = Headers(header)
        handler.http_error_auth_reqed("WWW-Authenticate", host, req, Headers(header))
        DURATION = perf_counter() - BEGIN
        print(f"took {DURATION} seconds!") 

For CVE-2020-8492, it is the backtracking performance caused by some ambiguity during the matching, and this issue is caused by the regex engine constantly moves the matching regex across the malicious string that does not have a match for the regex.

Because the locations of the vulnerabilities are the same, so I refer to your code. Thanks for the code ;-)!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43075>
_______________________________________

From report at bugs.python.org  Sun Mar 14 06:02:12 2021
From: report at bugs.python.org (Kamil Turek)
Date: Sun, 14 Mar 2021 10:02:12 +0000
Subject: [issue29657] os.symlink: FileExistsError shows wrong message
In-Reply-To: <1488099144.41.0.738429373533.issue29657@psf.upfronthosting.co.za>
Message-ID: <1615716132.78.0.831457831877.issue29657@roundup.psfhosted.org>


Change by Kamil Turek <kamil.turek at hotmail.com>:


----------
nosy: +kamilturek

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29657>
_______________________________________

From report at bugs.python.org  Sun Mar 14 06:03:25 2021
From: report at bugs.python.org (Alex Hall)
Date: Sun, 14 Mar 2021 10:03:25 +0000
Subject: [issue39316] settrace skips lines when chaining methods without
 arguments
In-Reply-To: <1578863624.84.0.650995733403.issue39316@roundup.psfhosted.org>
Message-ID: <1615716205.51.0.614820149493.issue39316@roundup.psfhosted.org>


Change by Alex Hall <alex.mojaki at gmail.com>:


----------
nosy: +Mark.Shannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39316>
_______________________________________

From report at bugs.python.org  Sun Mar 14 06:04:57 2021
From: report at bugs.python.org (Alex Hall)
Date: Sun, 14 Mar 2021 10:04:57 +0000
Subject: [issue39316] settrace skips lines when chaining methods without
 arguments
In-Reply-To: <1578863624.84.0.650995733403.issue39316@roundup.psfhosted.org>
Message-ID: <1615716297.84.0.587184626141.issue39316@roundup.psfhosted.org>


Alex Hall <alex.mojaki at gmail.com> added the comment:

I just came across https://www.python.org/dev/peps/pep-0626/, seems like this would need to be fixed to satisfy the PEP, but on the latest CPython it's not:

```
?  ~ python3.10 ~/Downloads/trace_skipping_lines_bug.py
14 slug = "doing_the_thing"
15 print(slug
16       .replace("_", " ")
15 print(slug
19       .replace("a", "b")
15 print(slug
21       .replace("The ", "the "))
15 print(slug
doing the thing
?  ~ python3.10 --version                              
Python 3.10.0a6+
?  ~ python3.10          
Python 3.10.0a6+ (heads/master:cd8dcbc, Mar 14 2021, 11:58:23) [GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 
```

----------
type:  -> behavior
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39316>
_______________________________________

From report at bugs.python.org  Sun Mar 14 07:54:06 2021
From: report at bugs.python.org (miss-islington)
Date: Sun, 14 Mar 2021 11:54:06 +0000
Subject: [issue39943] Meta: Clean up various issues in C internals
In-Reply-To: <1583983387.49.0.277830283994.issue39943@roundup.psfhosted.org>
Message-ID: <1615722846.44.0.0198222365092.issue39943@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: +23616
pull_request: https://github.com/python/cpython/pull/24856

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39943>
_______________________________________

From report at bugs.python.org  Sun Mar 14 08:17:39 2021
From: report at bugs.python.org (miss-islington)
Date: Sun, 14 Mar 2021 12:17:39 +0000
Subject: [issue39943] Meta: Clean up various issues in C internals
In-Reply-To: <1583983387.49.0.277830283994.issue39943@roundup.psfhosted.org>
Message-ID: <1615724259.41.0.303455641764.issue39943@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset cf8d6ef9629dc1bffadfcec251a2ffe30d5addaa by Miss Islington (bot) in branch '3.9':
bpo-39943: Fix MSVC warnings in sre extension (GH-20508)
https://github.com/python/cpython/commit/cf8d6ef9629dc1bffadfcec251a2ffe30d5addaa


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39943>
_______________________________________

From report at bugs.python.org  Sun Mar 14 08:34:49 2021
From: report at bugs.python.org (junyixie)
Date: Sun, 14 Mar 2021 12:34:49 +0000
Subject: [issue43313] feature: support pymalloc for subinterpreters. each
 subinterpreter has pymalloc_state
In-Reply-To: <1614159809.71.0.199865657429.issue43313@roundup.psfhosted.org>
Message-ID: <1615725289.79.0.732596509969.issue43313@roundup.psfhosted.org>


junyixie <xie.junyi at outlook.com> added the comment:

Made two changes:
1. support pymalloc for subinterpreters. each subinterpreter has pymalloc_state

2. _copy_raw_string api alloc memory use PyMem_RawFree and PyMem_RawMalloc.

I extend _xxsubinterpretermodule.c to support call any function in sub interpreter. 
when i need return result from sub interpreter call. 

1. i need create item->name in shared item. will use pymem_xxx api to manage memory. when with_pymalloc macro defined, it will create memory and bound to interpreter(iterp1) pymalloc state.

2. after switch interpreter state, now in iterp2 state, get return value from shareditem, and i need free shared item. but item->name memory managed by interp1 pymalloc state. if i want to free them, i need switch to interpreter state 1.  it's complicated. to implementation it, we need save interpid in shared item.

so i think, in _sharednsitem_init _copy_raw_string, need malloc by PyMem_RawAPI. easy to management.

```
static int
_sharednsitem_init(struct _sharednsitem *item, PyObject *key, PyObject *value)
{
    item->name = _copy_raw_string(key);
```

```
_sharedns *result_shread = _sharedns_new(1);


#ifdef EXPERIMENTAL_ISOLATED_SUBINTERPRETERS
    // Switch to interpreter.
    PyThreadState *new_tstate = PyInterpreterState_ThreadHead(interp);
    PyThreadState *save1 = PyEval_SaveThread();

    (void)PyThreadState_Swap(new_tstate);
#else
    // Switch to interpreter.
    PyThreadState *save_tstate = NULL;
    if (interp != PyInterpreterState_Get()) {
        // XXX Using the "head" thread isn't strictly correct.
        PyThreadState *tstate = PyInterpreterState_ThreadHead(interp);
        // XXX Possible GILState issues?
        save_tstate = PyThreadState_Swap(tstate);
    }
#endif
    
    PyObject *module = PyImport_ImportModule(PyUnicode_AsUTF8(module_name));
    PyObject *function = PyObject_GetAttr(module, function_name);
    
    result = PyObject_Call(function, args, kwargs);

    if (result == NULL) {
        // exception handler
        ...
    }

    if (result && _sharednsitem_init(&result_shread->items[0], PyUnicode_FromString("result"), result) != 0) {
        PyErr_Format(RunFailedError, "interp_call_function result convert to shared failed");
        return NULL;;
    }
#ifdef EXPERIMENTAL_ISOLATED_SUBINTERPRETERS
    // Switch back.
    PyEval_RestoreThread(save1);
#else
    // Switch back.
    if (save_tstate != NULL) {
        PyThreadState_Swap(save_tstate);
    }
#endif
    // ...

    if (result) {
        result = _PyCrossInterpreterData_NewObject(&result_shread->items[0].data);
        _sharedns_free(result_shread);
    }
```

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43313>
_______________________________________

From report at bugs.python.org  Sun Mar 14 08:35:27 2021
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=)
Date: Sun, 14 Mar 2021 12:35:27 +0000
Subject: [issue18232] running a suite with no tests is not an error
In-Reply-To: <1371411159.89.0.919313216558.issue18232@psf.upfronthosting.co.za>
Message-ID: <1615725327.55.0.383126369251.issue18232@roundup.psfhosted.org>


Micha? G?rny <mgorny at gentoo.org> added the comment:

I'm not convinced we need something that complex here but I think it would make sense to make 'unittest discover' fail when it doesn't discover a single test.  As packagers, we've been bitten more than once by packages whose tests suddenly stopped being discovered, and it would be really helpful if we were able to catch this automatically without having to resort to hacks.

----------
nosy: +mgorny

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18232>
_______________________________________

From report at bugs.python.org  Sun Mar 14 08:35:30 2021
From: report at bugs.python.org (junyixie)
Date: Sun, 14 Mar 2021 12:35:30 +0000
Subject: [issue43313] feature: support pymalloc for subinterpreters. each
 subinterpreter has pymalloc_state
In-Reply-To: <1614159809.71.0.199865657429.issue43313@roundup.psfhosted.org>
Message-ID: <1615725330.01.0.0417759477365.issue43313@roundup.psfhosted.org>


junyixie <xie.junyi at outlook.com> added the comment:

github pr

----------
keywords: +patch
message_count: 2.0 -> 3.0
pull_requests: +23617
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24857

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43313>
_______________________________________

From report at bugs.python.org  Sun Mar 14 08:35:40 2021
From: report at bugs.python.org (junyixie)
Date: Sun, 14 Mar 2021 12:35:40 +0000
Subject: [issue43313] feature: support pymalloc for subinterpreters. each
 subinterpreter has pymalloc_state
In-Reply-To: <1614159809.71.0.199865657429.issue43313@roundup.psfhosted.org>
Message-ID: <1615725340.82.0.164323693807.issue43313@roundup.psfhosted.org>


junyixie <xie.junyi at outlook.com> added the comment:

https://github.com/python/cpython/pull/24857

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43313>
_______________________________________

From report at bugs.python.org  Sun Mar 14 08:54:39 2021
From: report at bugs.python.org (parsa mpsh)
Date: Sun, 14 Mar 2021 12:54:39 +0000
Subject: [issue43491] Windows filepath bug
Message-ID: <1615726479.05.0.699625181333.issue43491@roundup.psfhosted.org>


New submission from parsa mpsh <parsampsh at gmail.com>:

I was testing my program in github workflow and i detected a bug. i was opening a file in windows:

```
f = open(os.path.dirname(__FILE__) + '/some/file.txt')
```

means the file path will be `C:\some\path/some/file.txt`.

but i received OSError. why? because in the above path, we have both `/` and `\`.

I think this bug should be fixed by converting all of `/`s to `\` in file paths automatic.

----------
components: Windows
messages: 388672
nosy: parsampsh, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows filepath bug
type: behavior
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43491>
_______________________________________

From report at bugs.python.org  Sun Mar 14 08:55:28 2021
From: report at bugs.python.org (parsa mpsh)
Date: Sun, 14 Mar 2021 12:55:28 +0000
Subject: [issue43491] Windows filepath bug
In-Reply-To: <1615726479.05.0.699625181333.issue43491@roundup.psfhosted.org>
Message-ID: <1615726528.28.0.666904683189.issue43491@roundup.psfhosted.org>


parsa mpsh <parsampsh at gmail.com> added the comment:

Update: i only tested this bug in `3.6` and `3.7` i'm not sure about newer versions. but i think this bug also is in them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43491>
_______________________________________

From report at bugs.python.org  Sun Mar 14 08:56:55 2021
From: report at bugs.python.org (parsa mpsh)
Date: Sun, 14 Mar 2021 12:56:55 +0000
Subject: [issue43491] Windows filepath bug
In-Reply-To: <1615726479.05.0.699625181333.issue43491@roundup.psfhosted.org>
Message-ID: <1615726615.41.0.359871219436.issue43491@roundup.psfhosted.org>


parsa mpsh <parsampsh at gmail.com> added the comment:

I think this bug should be fixed by converting all of `/`s to `\` in file paths automatic **When os is windows**.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43491>
_______________________________________

From report at bugs.python.org  Sun Mar 14 09:10:46 2021
From: report at bugs.python.org (parsa mpsh)
Date: Sun, 14 Mar 2021 13:10:46 +0000
Subject: [issue43491] Windows filepath bug
In-Reply-To: <1615726479.05.0.699625181333.issue43491@roundup.psfhosted.org>
Message-ID: <1615727446.34.0.609591861347.issue43491@roundup.psfhosted.org>


Change by parsa mpsh <parsampsh at gmail.com>:


----------
components: +IO

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43491>
_______________________________________

From report at bugs.python.org  Sun Mar 14 09:28:27 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 14 Mar 2021 13:28:27 +0000
Subject: [issue43491] Windows filepath bug
In-Reply-To: <1615726479.05.0.699625181333.issue43491@roundup.psfhosted.org>
Message-ID: <1615728507.23.0.900958727751.issue43491@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

"C:\some\path/some/file.txt" is a valid file path. The Windows file API normalizes most paths, except for verbatim paths that start with exactly "\\?\". Path normalization includes replacing forward slashes with backslashes.

If you provide the complete traceback, I may be able to help diagnose the problem, but not here. Please ask for help on https://discuss.python.org/c/users or https://mail.python.org/mailman/listinfo/python-list.

----------
nosy: +eryksun
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43491>
_______________________________________

From report at bugs.python.org  Sun Mar 14 11:24:52 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 14 Mar 2021 15:24:52 +0000
Subject: [issue43428] Sync importlib_metadata enhancements through 3.7.
In-Reply-To: <1615157667.11.0.27235417477.issue43428@roundup.psfhosted.org>
Message-ID: <1615735492.99.0.716164894679.issue43428@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
pull_requests: +23618
pull_request: https://github.com/python/cpython/pull/24858

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43428>
_______________________________________

From report at bugs.python.org  Sun Mar 14 12:02:59 2021
From: report at bugs.python.org (parsa mpsh)
Date: Sun, 14 Mar 2021 16:02:59 +0000
Subject: [issue43491] Windows filepath bug
In-Reply-To: <1615726479.05.0.699625181333.issue43491@roundup.psfhosted.org>
Message-ID: <1615737778.99.0.777212881103.issue43491@roundup.psfhosted.org>


parsa mpsh <parsampsh at gmail.com> added the comment:

Yes. i checked it more. looks problem was from other thing, not the path.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43491>
_______________________________________

From report at bugs.python.org  Sun Mar 14 12:48:19 2021
From: report at bugs.python.org (Mark Shannon)
Date: Sun, 14 Mar 2021 16:48:19 +0000
Subject: [issue39316] settrace skips lines when chaining methods without
 arguments
In-Reply-To: <1578863624.84.0.650995733403.issue39316@roundup.psfhosted.org>
Message-ID: <1615740499.31.0.127652590609.issue39316@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
keywords: +patch
pull_requests: +23619
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24859

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39316>
_______________________________________

From report at bugs.python.org  Sun Mar 14 13:16:55 2021
From: report at bugs.python.org (Adrian LeDeaux)
Date: Sun, 14 Mar 2021 17:16:55 +0000
Subject: [issue43489] Can't install, nothing to install
In-Reply-To: <1615683419.81.0.261055415418.issue43489@roundup.psfhosted.org>
Message-ID: <1615742215.68.0.776672991343.issue43489@roundup.psfhosted.org>


Adrian LeDeaux <aledeaux at gmail.com> added the comment:

Alright! Thanks for the help! I will try that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43489>
_______________________________________

From report at bugs.python.org  Sun Mar 14 13:26:40 2021
From: report at bugs.python.org (Irit Katriel)
Date: Sun, 14 Mar 2021 17:26:40 +0000
Subject: [issue31472] "Emulating callable objects" documentation misleading
In-Reply-To: <1505409903.44.0.981302539758.issue31472@psf.upfronthosting.co.za>
Message-ID: <1615742800.16.0.502656045374.issue31472@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
keywords: +easy
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31472>
_______________________________________

From report at bugs.python.org  Sun Mar 14 13:34:29 2021
From: report at bugs.python.org (Irit Katriel)
Date: Sun, 14 Mar 2021 17:34:29 +0000
Subject: [issue34538] Remove encouragement to author a base class for all
 Exception subclasses in a module
In-Reply-To: <1535488851.13.0.56676864532.issue34538@psf.upfronthosting.co.za>
Message-ID: <1615743269.29.0.518220832904.issue34538@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
keywords: +easy
versions: +Python 3.10, Python 3.9 -Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34538>
_______________________________________

From report at bugs.python.org  Sun Mar 14 13:46:13 2021
From: report at bugs.python.org (Irit Katriel)
Date: Sun, 14 Mar 2021 17:46:13 +0000
Subject: [issue18767] csv documentation does not note default quote constant
In-Reply-To: <1376706253.43.0.482794872786.issue18767@psf.upfronthosting.co.za>
Message-ID: <1615743973.62.0.296242540173.issue18767@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
components: +Library (Lib)
keywords: +easy
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18767>
_______________________________________

From report at bugs.python.org  Sun Mar 14 13:52:30 2021
From: report at bugs.python.org (Irit Katriel)
Date: Sun, 14 Mar 2021 17:52:30 +0000
Subject: [issue19359] reversed() does not work with weakref.proxy of sequences
In-Reply-To: <1382511608.51.0.706468574715.issue19359@psf.upfronthosting.co.za>
Message-ID: <1615744350.55.0.450122578848.issue19359@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

On 3.10 the reversed_proxy_failure.py script fails with

Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython/tmp.py", line 18, in <module>
    reversed(weakref.proxy(foo))  # TypeError
AttributeError: 'Foo' object has no attribute '__reversed__'

----------
nosy: +iritkatriel
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19359>
_______________________________________

From report at bugs.python.org  Sun Mar 14 14:01:47 2021
From: report at bugs.python.org (Mark Shannon)
Date: Sun, 14 Mar 2021 18:01:47 +0000
Subject: [issue39316] settrace skips lines when chaining methods without
 arguments
In-Reply-To: <1578863624.84.0.650995733403.issue39316@roundup.psfhosted.org>
Message-ID: <1615744907.44.0.5397128809.issue39316@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset d48848c83e0f3e41b65c8f741f3fb6dbce5b9c29 by Mark Shannon in branch 'master':
bpo-39316: Make sure that attribute accesses and stores, including method calls, conform to PEP 626. (GH-24859)
https://github.com/python/cpython/commit/d48848c83e0f3e41b65c8f741f3fb6dbce5b9c29


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39316>
_______________________________________

From report at bugs.python.org  Sun Mar 14 14:03:35 2021
From: report at bugs.python.org (Kamil Turek)
Date: Sun, 14 Mar 2021 18:03:35 +0000
Subject: [issue18232] running a suite with no tests is not an error
In-Reply-To: <1371411159.89.0.919313216558.issue18232@psf.upfronthosting.co.za>
Message-ID: <1615745015.62.0.907734202496.issue18232@roundup.psfhosted.org>


Change by Kamil Turek <kamil.turek at hotmail.com>:


----------
nosy: +kamilturek

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18232>
_______________________________________

From report at bugs.python.org  Sun Mar 14 14:04:39 2021
From: report at bugs.python.org (Kamil Turek)
Date: Sun, 14 Mar 2021 18:04:39 +0000
Subject: [issue31472] "Emulating callable objects" documentation misleading
In-Reply-To: <1505409903.44.0.981302539758.issue31472@psf.upfronthosting.co.za>
Message-ID: <1615745079.57.0.616643901675.issue31472@roundup.psfhosted.org>


Change by Kamil Turek <kamil.turek at hotmail.com>:


----------
nosy: +kamilturek

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31472>
_______________________________________

From report at bugs.python.org  Sun Mar 14 14:06:35 2021
From: report at bugs.python.org (Mark Shannon)
Date: Sun, 14 Mar 2021 18:06:35 +0000
Subject: [issue42246] Implement PEP 626 -- Precise line numbers for debugging
In-Reply-To: <1604331162.26.0.596873070589.issue42246@roundup.psfhosted.org>
Message-ID: <1615745195.38.0.920736152203.issue42246@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
pull_requests: +23620
pull_request: https://github.com/python/cpython/pull/24860

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42246>
_______________________________________

From report at bugs.python.org  Sun Mar 14 14:07:04 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 14 Mar 2021 18:07:04 +0000
Subject: [issue29982] tempfile.TemporaryDirectory fails to delete itself
In-Reply-To: <1491330378.49.0.274398190766.issue29982@psf.upfronthosting.co.za>
Message-ID: <1615745224.55.0.538674140057.issue29982@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset bd2fa3c416ffe6107b500a2180fa1764645c0a61 by CAM Gerlach in branch 'master':
bpo-29982: Add "ignore_cleanup_errors" param to tempfile.TemporaryDirectory() (GH-24793)
https://github.com/python/cpython/commit/bd2fa3c416ffe6107b500a2180fa1764645c0a61


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29982>
_______________________________________

From report at bugs.python.org  Sun Mar 14 14:11:24 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 14 Mar 2021 18:11:24 +0000
Subject: [issue29982] tempfile.TemporaryDirectory fails to delete itself
In-Reply-To: <1491330378.49.0.274398190766.issue29982@psf.upfronthosting.co.za>
Message-ID: <1615745484.18.0.221726367548.issue29982@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/issue29982>
_______________________________________

From report at bugs.python.org  Sun Mar 14 14:13:25 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 14 Mar 2021 18:13:25 +0000
Subject: [issue43422] Revert _decimal C API changes
In-Reply-To: <1615043906.44.0.566874098139.issue43422@roundup.psfhosted.org>
Message-ID: <1615745605.83.0.544939483277.issue43422@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

Terry, the list of roles in https://bugs.python.org/user11089 is empty, which I take it to mean that Stefan doesn't have any access rights on this issue tracker (except to read issues).  Other users all seem to have the "User" role.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43422>
_______________________________________

From report at bugs.python.org  Sun Mar 14 15:21:59 2021
From: report at bugs.python.org (Irit Katriel)
Date: Sun, 14 Mar 2021 19:21:59 +0000
Subject: [issue1283110] Give __len__() advice for "don't know"
Message-ID: <1615749719.61.0.598928060159.issue1283110@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
keywords: +easy
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.7, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1283110>
_______________________________________

From report at bugs.python.org  Sun Mar 14 15:36:02 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 14 Mar 2021 19:36:02 +0000
Subject: [issue18232] running a suite with no tests is not an error
In-Reply-To: <1371411159.89.0.919313216558.issue18232@psf.upfronthosting.co.za>
Message-ID: <1615750562.84.0.312200382307.issue18232@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

With more experience, I agree that 0/0 tests passing should not be a pass.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18232>
_______________________________________

From report at bugs.python.org  Sun Mar 14 16:01:46 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 14 Mar 2021 20:01:46 +0000
Subject: [issue43422] Revert _decimal C API changes
In-Reply-To: <1615043906.44.0.566874098139.issue43422@roundup.psfhosted.org>
Message-ID: <1615752106.82.0.315054114714.issue43422@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

OK.  I see no structural difference between his page and yours, https://bugs.python.org/user2040.  No 'Roles' field, no 'User' entry, on either page, nor on mine.  So you must be an admin who sees extra info.  In any case, the last part of my comment stands.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43422>
_______________________________________

From report at bugs.python.org  Sun Mar 14 16:03:55 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 14 Mar 2021 20:03:55 +0000
Subject: [issue43422] Revert _decimal C API changes
In-Reply-To: <1615043906.44.0.566874098139.issue43422@roundup.psfhosted.org>
Message-ID: <1615752235.57.0.921303916296.issue43422@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

FWIW, I have the roles "User,Developer,Coordinator" according to my user page.
You (Terry) have the roles "User,Developer".
Perhaps the "Coordinator" role explains I see things you don't see (it's a better explanation than believing I am a psychic :-D).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43422>
_______________________________________

From report at bugs.python.org  Sun Mar 14 16:12:12 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Sun, 14 Mar 2021 20:12:12 +0000
Subject: [issue43492] Upgrade to SQLite 3.35.0 in macOS and Windows
Message-ID: <1615752732.27.0.278073347477.issue43492@roundup.psfhosted.org>


New submission from Erlend Egeberg Aasland <erlend.aasland at innova.no>:

SQLite 3.35.0 was released a couple of days ago: https://www.sqlite.org/releaselog/3_35_0.html

Suggesting to hold off for a week or two, to see if a bug-fix release happens.

----------
components: Windows, macOS
messages: 388685
nosy: erlendaasland, ned.deily, paul.moore, ronaldoussoren, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Upgrade to SQLite 3.35.0 in macOS and Windows
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43492>
_______________________________________

From report at bugs.python.org  Sun Mar 14 16:13:17 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Sun, 14 Mar 2021 20:13:17 +0000
Subject: [issue42686] include built-in Math functions in SQLite to 3.35.0 of
 march 2021
In-Reply-To: <1608391961.58.0.717857253057.issue42686@roundup.psfhosted.org>
Message-ID: <1615752797.7.0.186394301084.issue42686@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

See bpo-43492 for upgrading the macOS & Windows installers to SQLite 3.35.0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42686>
_______________________________________

From report at bugs.python.org  Sun Mar 14 16:46:29 2021
From: report at bugs.python.org (Mike Glover)
Date: Sun, 14 Mar 2021 20:46:29 +0000
Subject: [issue43493] EmailMessage mis-folding headers of a certain length
Message-ID: <1615754789.09.0.690251462615.issue43493@roundup.psfhosted.org>


New submission from Mike Glover <mglover at pobox.com>:

The attached file demonstrates the incorrect folding behavior I'm seeing.  Header lines of a certain total length get folded after the colon following the header name, which is not valid RFC.  Slightly longer or shorter lines are folded correctly.

Interestingly, the test file produces correct output on 3.5.2

$ python --version
Python 3.8.5

$ sudo apt install python3
...
python3 is already the newest version (3.8.2-0ubuntu2).

(yes, that difference has me scratching my head)

And yes, I realize this is not the latest release of the 3.8 branch, but it *is* the latest available through apt on Ubuntu 20.04 LTS, and a search of the issue tracker and the release notes for all of 3.8.* turned up nothing applicable.

----------
components: email
files: header_misfolding.py
messages: 388687
nosy: barry, mglover, r.david.murray
priority: normal
severity: normal
status: open
title: EmailMessage mis-folding headers of a certain length
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file49875/header_misfolding.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43493>
_______________________________________

From report at bugs.python.org  Sun Mar 14 16:56:45 2021
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 14 Mar 2021 20:56:45 +0000
Subject: [issue43494] Minor changes to Objects/lnotab_notes.txt
Message-ID: <1615755405.52.0.84657941654.issue43494@roundup.psfhosted.org>


New submission from Skip Montanaro <skip.montanaro at gmail.com>:

For the VM work I'm doing I need to adapt to Mark's new line number table format. (I stalled for several months, hence this rather late report.) As I was reading Objects/lnotab_notes.txt I noticed a couple typos, fixed those and threw in a couple other minor edits. A PR is incoming.

----------
assignee: Mark.Shannon
messages: 388688
nosy: Mark.Shannon, skip.montanaro
priority: low
severity: normal
status: open
title: Minor changes to Objects/lnotab_notes.txt
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43494>
_______________________________________

From report at bugs.python.org  Sun Mar 14 16:57:50 2021
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 14 Mar 2021 20:57:50 +0000
Subject: [issue43494] Minor changes to Objects/lnotab_notes.txt
In-Reply-To: <1615755405.52.0.84657941654.issue43494@roundup.psfhosted.org>
Message-ID: <1615755470.01.0.95224513109.issue43494@roundup.psfhosted.org>


Change by Skip Montanaro <skip.montanaro at gmail.com>:


----------
keywords: +patch
pull_requests: +23621
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24861

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43494>
_______________________________________

From report at bugs.python.org  Sun Mar 14 16:59:56 2021
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 14 Mar 2021 20:59:56 +0000
Subject: [issue43494] Minor changes to Objects/lnotab_notes.txt
In-Reply-To: <1615755405.52.0.84657941654.issue43494@roundup.psfhosted.org>
Message-ID: <1615755596.29.0.91577072887.issue43494@roundup.psfhosted.org>


Skip Montanaro <skip.montanaro at gmail.com> added the comment:

When I submitted the PR one check failed with this error:

No news entry in Misc/NEWS.d/next/ or "skip news" label found

I'd be surprised if this was important enough for a news entry, and I'm pretty sure I can't add a "skip news" label.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43494>
_______________________________________

From report at bugs.python.org  Sun Mar 14 18:03:56 2021
From: report at bugs.python.org (Irit Katriel)
Date: Sun, 14 Mar 2021 22:03:56 +0000
Subject: [issue32822] finally block doesn't re-raise exception if return
 statement exists inside
In-Reply-To: <1518387497.4.0.467229070634.issue32822@psf.upfronthosting.co.za>
Message-ID: <1615759436.3.0.553656150848.issue32822@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

The doc has a lot more detail now: https://docs.python.org/3.10/tutorial/errors.html#defining-clean-up-actions

but this point is still not mentioned.

----------
keywords: +easy
nosy: +iritkatriel
versions: +Python 3.10, Python 3.9 -Python 2.7, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32822>
_______________________________________

From report at bugs.python.org  Sun Mar 14 18:12:17 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 14 Mar 2021 22:12:17 +0000
Subject: [issue43199] FAQ about goto lacks answer
In-Reply-To: <1613036693.06.0.0717598867229.issue43199@roundup.psfhosted.org>
Message-ID: <1615759937.08.0.902354966383.issue43199@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 5e29021a5eb10baa9147fd977cab82fa3f652bf0 by Terry Jan Reedy in branch 'master':
bpo-43199: Briefly explain why no goto (GH-24852)
https://github.com/python/cpython/commit/5e29021a5eb10baa9147fd977cab82fa3f652bf0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43199>
_______________________________________

From report at bugs.python.org  Sun Mar 14 18:12:47 2021
From: report at bugs.python.org (miss-islington)
Date: Sun, 14 Mar 2021 22:12:47 +0000
Subject: [issue43199] FAQ about goto lacks answer
In-Reply-To: <1613036693.06.0.0717598867229.issue43199@roundup.psfhosted.org>
Message-ID: <1615759967.45.0.683010493439.issue43199@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: +23622
pull_request: https://github.com/python/cpython/pull/24862

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43199>
_______________________________________

From report at bugs.python.org  Sun Mar 14 18:12:57 2021
From: report at bugs.python.org (miss-islington)
Date: Sun, 14 Mar 2021 22:12:57 +0000
Subject: [issue43199] FAQ about goto lacks answer
In-Reply-To: <1613036693.06.0.0717598867229.issue43199@roundup.psfhosted.org>
Message-ID: <1615759977.9.0.0290730772107.issue43199@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +23623
pull_request: https://github.com/python/cpython/pull/24863

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43199>
_______________________________________

From report at bugs.python.org  Sun Mar 14 18:23:19 2021
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Blondon?=)
Date: Sun, 14 Mar 2021 22:23:19 +0000
Subject: [issue42914] pprint numbers with underscore
In-Reply-To: <1610493681.29.0.683565759752.issue42914@roundup.psfhosted.org>
Message-ID: <1615760599.76.0.67291745692.issue42914@roundup.psfhosted.org>


Change by St?phane Blondon <stephane.blondon at gmail.com>:


----------
keywords: +patch
pull_requests: +23624
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24864

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42914>
_______________________________________

From report at bugs.python.org  Sun Mar 14 18:42:53 2021
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Blondon?=)
Date: Sun, 14 Mar 2021 22:42:53 +0000
Subject: [issue42914] pprint numbers with underscore
In-Reply-To: <1610493681.29.0.683565759752.issue42914@roundup.psfhosted.org>
Message-ID: <1615761773.47.0.408491956373.issue42914@roundup.psfhosted.org>


St?phane Blondon <stephane.blondon at gmail.com> added the comment:

Thank you Felipe for the news! :)
I have committed a PR about this issue.

Two remarks:
- I changed the proposed implementation from 'format(integer, '_d')' to '{:_d}.format(integer)' because the first way raised an exception. (The `format` function was not defined.)
- I thought about adding the same behavior for float too but I didn't add it because the '_f' type uses a precision of 6 digits after the decimal point for float. So it's possible some precision would be lost with the pprint() call. It could mislead users more than helping them with the readability of the '_'. A precision value can be added but I'm not sure it's a good idea. based on [1]

As requested, there is a new parameter to disable this new behavior ('underscore_numbers').


1: https://docs.python.org/3/library/string.html#format-specification-mini-language

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42914>
_______________________________________

From report at bugs.python.org  Sun Mar 14 19:02:32 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 14 Mar 2021 23:02:32 +0000
Subject: [issue1283110] Give __len__() advice for "don't know"
Message-ID: <1615762952.54.0.911357550455.issue1283110@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Looking at the patch years later, I'm thinking that this isn't needed or helpful.  Not needed because users haven't reported any misunderstandings in the interim.  Not helpful because the text looks forbidding and impenetrable, too much for a simple method like __len__().

I recommend closing this as out-of-date.  As Benjamin noted, the advent of __length_hint__ has mostly made this issue go away.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1283110>
_______________________________________

From report at bugs.python.org  Sun Mar 14 19:33:27 2021
From: report at bugs.python.org (Paul Weiss)
Date: Sun, 14 Mar 2021 23:33:27 +0000
Subject: [issue27929] asyncio.AbstractEventLoop.sock_connect broken for
 AF_BLUETOOTH
In-Reply-To: <1472738395.77.0.643111482192.issue27929@psf.upfronthosting.co.za>
Message-ID: <1615764807.91.0.614193007972.issue27929@roundup.psfhosted.org>


Change by Paul Weiss <paulniklasweiss at gmail.com>:


----------
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27929>
_______________________________________

From report at bugs.python.org  Sun Mar 14 19:37:00 2021
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 14 Mar 2021 23:37:00 +0000
Subject: [issue27929] asyncio.AbstractEventLoop.sock_connect broken for
 AF_BLUETOOTH
In-Reply-To: <1472738395.77.0.643111482192.issue27929@psf.upfronthosting.co.za>
Message-ID: <1615765020.78.0.231125564697.issue27929@roundup.psfhosted.org>


Change by Larry Hastings <larry at hastings.org>:


----------
nosy:  -larry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27929>
_______________________________________

From report at bugs.python.org  Sun Mar 14 20:27:13 2021
From: report at bugs.python.org (Steve Stagg)
Date: Mon, 15 Mar 2021 00:27:13 +0000
Subject: [issue37820] Unnecessary URL scheme exists to allow 'URL: reading
 file in urllib
In-Reply-To: <1565522189.95.0.525978892849.issue37820@roundup.psfhosted.org>
Message-ID: <1615768033.51.0.211405925844.issue37820@roundup.psfhosted.org>


Steve Stagg <stestagg at gmail.com> added the comment:

This appears to have been fixed in python 3:

rx.py:
import urllib.request
print(urllib.request.urlopen('URL:/etc/passwd').read()[:30])

$> python rx.py 
Traceback (most recent call last):
  File "rx.py", line 2, in <module>
    print(urllib.request.urlopen('URL:/etc/passwd').read()[:30])
  File "/usr/lib/python3.9/urllib/request.py", line 214, in urlopen
    return opener.open(url, data, timeout)
  File "/usr/lib/python3.9/urllib/request.py", line 501, in open
    req = Request(fullurl, data)
  File "/usr/lib/python3.9/urllib/request.py", line 320, in __init__
    self.full_url = url
  File "/usr/lib/python3.9/urllib/request.py", line 346, in full_url
    self._parse()
  File "/usr/lib/python3.9/urllib/request.py", line 375, in _parse
    raise ValueError("unknown url type: %r" % self.full_url)
ValueError: unknown url type: '/etc/passwd'

----------
nosy: +stestagg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37820>
_______________________________________

From report at bugs.python.org  Sun Mar 14 20:32:22 2021
From: report at bugs.python.org (Thomas Anderson)
Date: Mon, 15 Mar 2021 00:32:22 +0000
Subject: [issue43495] Missing frame block push in
 compiler_async_comprehension_generator()
Message-ID: <1615768342.52.0.844768701599.issue43495@roundup.psfhosted.org>


New submission from Thomas Anderson <tomkpz at gmail.com>:

The runtime pushes a frame block in SETUP_FINALLY, so the compiler needs to account for that, otherwise the runtime block stack may overflow.

----------
components: Interpreter Core
messages: 388696
nosy: tomkpz
priority: normal
severity: normal
status: open
title: Missing frame block push in compiler_async_comprehension_generator()
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43495>
_______________________________________

From report at bugs.python.org  Sun Mar 14 20:35:31 2021
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 15 Mar 2021 00:35:31 +0000
Subject: [issue43495] Missing frame block push in
 compiler_async_comprehension_generator()
In-Reply-To: <1615768342.52.0.844768701599.issue43495@roundup.psfhosted.org>
Message-ID: <1615768531.52.0.694821710379.issue43495@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: +23626
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24865

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43495>
_______________________________________

From report at bugs.python.org  Sun Mar 14 20:56:32 2021
From: report at bugs.python.org (Thomas Anderson)
Date: Mon, 15 Mar 2021 00:56:32 +0000
Subject: [issue42917] Block stack size for frame objects should be dynamically
 sizable
In-Reply-To: <1610502849.77.0.30833881241.issue42917@roundup.psfhosted.org>
Message-ID: <1615769792.4.0.21824041669.issue42917@roundup.psfhosted.org>


Thomas Anderson <tomkpz at gmail.com> added the comment:

IIRC, some transpilers for functional languages create deeply nested code.  In particular for things like haskell's do notation.

Anyway, when I wrote the PR, it was initially to reduce the frame size.  Then once I had dynamic block stack sizing working, I realized there was no longer a need to keep the limit of 20 blocks.  It was just compile.c that had the artificial limit, so I removed it.  I can add the limit back in the PR, but I'm not sure what benefit that would give.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42917>
_______________________________________

From report at bugs.python.org  Sun Mar 14 21:08:05 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 15 Mar 2021 01:08:05 +0000
Subject: [issue27929] asyncio.AbstractEventLoop.sock_connect broken for
 AF_BLUETOOTH
In-Reply-To: <1472738395.77.0.643111482192.issue27929@psf.upfronthosting.co.za>
Message-ID: <1615770485.42.0.397888552758.issue27929@roundup.psfhosted.org>


Change by Guido van Rossum <gvanrossum at gmail.com>:


----------
nosy:  -gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27929>
_______________________________________

From report at bugs.python.org  Sun Mar 14 21:26:20 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 15 Mar 2021 01:26:20 +0000
Subject: [issue42917] Block stack size for frame objects should be dynamically
 sizable
In-Reply-To: <1610502849.77.0.30833881241.issue42917@roundup.psfhosted.org>
Message-ID: <1615771580.89.0.179612732673.issue42917@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

I don't see what putting the limit back in this PR would give, but I do question that we need more block nesting, and this PR causes a lot of code churn (including a new API to create frames). It would be more convincing if you could actually point to a code generator that would benefit, rather than hand-waving "code generators might use it."

I'm also not sure that we'll see measurable benefits in terms of memory access locality. Have you tried to benchmark this? Even a micro-benchmark aiming to show there is *some* effect would be helpful.

At the same time I'm intrigued by Serhiy's idea, which could well reduce the size of the bytecode and the cost of instruction decoding by avoiding all dynamic block stack manipulation.

There are also other ideas floating about for improving memory locality related to the frame stack, e.g. putting the stack frames in an array instead of a linked list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42917>
_______________________________________

From report at bugs.python.org  Sun Mar 14 21:40:29 2021
From: report at bugs.python.org (Jacob Walls)
Date: Mon, 15 Mar 2021 01:40:29 +0000
Subject: [issue43496] Save As dialog in IDLE doesn't accept keyboard shortcuts
 on MacOS
Message-ID: <1615772429.67.0.84187114429.issue43496@roundup.psfhosted.org>


New submission from Jacob Walls <jacobtylerwalls at gmail.com>:

Cmd-A to select all or Cmd-Z to undo, etc., have no effect when typing in the "Save As:" or "Tags:" fields of the native Save As... dialog on MacOS. Cmd-R, curiously, opens a Finder window.

IDLE dialogs such as Search behave as expected (Cmd-A selects all).

Python 3.9.2
macOS 10.15.7 (and 10.13.6)

Pardon me if my search for existing tickets came up short.

----------
assignee: terry.reedy
components: IDLE, macOS
messages: 388699
nosy: jacobtylerwalls, ned.deily, ronaldoussoren, terry.reedy
priority: normal
severity: normal
status: open
title: Save As dialog in IDLE doesn't accept keyboard shortcuts on MacOS
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43496>
_______________________________________

From report at bugs.python.org  Sun Mar 14 22:09:29 2021
From: report at bugs.python.org (DMI-1407)
Date: Mon, 15 Mar 2021 02:09:29 +0000
Subject: [issue32592] Drop support of Windows Vista and 7 in Python 3.9
In-Reply-To: <1516268238.05.0.467229070634.issue32592@psf.upfronthosting.co.za>
Message-ID: <1615774169.86.0.635955894843.issue32592@roundup.psfhosted.org>


DMI-1407 <dmi-1407 at live.de> added the comment:

Is a Windows Version dropped on "normal" end of life or when the extended support ends?
Windows 7 extended support ends in 2023 (april i think).
Source: https://docs.microsoft.com/en-us/troubleshoot/windows-client/windows-7-eos-faq/windows-7-extended-security-updates-faq#what-are-the-coverage-dates-for-the-three-windows-7-esu-skus

As far as i understood it, Windows 7 gets unsupported from Python 3.9 because of code removal?
So wouldnt it be better to keep the code until the extended support of Windows 7 ends?

----------
nosy: +DMI-1407

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32592>
_______________________________________

From report at bugs.python.org  Sun Mar 14 22:20:58 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 15 Mar 2021 02:20:58 +0000
Subject: [issue43428] Sync importlib_metadata enhancements through 3.7.
In-Reply-To: <1615157667.11.0.27235417477.issue43428@roundup.psfhosted.org>
Message-ID: <1615774858.89.0.855022812195.issue43428@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:


New changeset 35d5068928ab5485e5f28b60b1e33062bc2c46cc by Jason R. Coombs in branch 'master':
bpo-43428: Improve documentation for importlib.metadata changes. (GH-24858)
https://github.com/python/cpython/commit/35d5068928ab5485e5f28b60b1e33062bc2c46cc


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43428>
_______________________________________

From report at bugs.python.org  Sun Mar 14 22:53:09 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 15 Mar 2021 02:53:09 +0000
Subject: [issue43475] Worst-case behaviour of hash collision with float NaN
In-Reply-To: <1615474533.28.0.166606930148.issue43475@roundup.psfhosted.org>
Message-ID: <1615776789.21.0.172680059332.issue43475@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> The performance thoughts were motivated by the idea of
> making NaN a singleton: adding a check to 
> PyFloat_FromDouble would mean that almost every operation
> that produced a float would have to pass through that check.

It may suffice to move the check upstream from PyFloat_FromDouble so that float('NaN') alway produces identically the same object as math.nan.

That would handle the common cases where NaN is used for missing values or is generated from string conversions.  We don't need a bullet-proof solution, just mitigation of harm.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43475>
_______________________________________

From report at bugs.python.org  Sun Mar 14 22:59:00 2021
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 15 Mar 2021 02:59:00 +0000
Subject: [issue32592] Drop support of Windows Vista and 7 in Python 3.9
In-Reply-To: <1516268238.05.0.467229070634.issue32592@psf.upfronthosting.co.za>
Message-ID: <1615777140.23.0.337364404899.issue32592@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

PEP 11 says that "[a] new feature release X.Y.0 will support all Windows releases whose extended support phase is not yet expired". There was no such thing as Extended Security Updates (ESU) when that provision was accepted. As defined by PEP 11, extended support for Windows 7 ended on 2020-01-14. 

> So wouldnt it be better to keep the code until the extended support of
> Windows 7 ends?

IMO, Windows 7 is either supported or it's not. If it's not, then workarounds and fallback code for Windows 7 should be removed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32592>
_______________________________________

From report at bugs.python.org  Sun Mar 14 23:28:04 2021
From: report at bugs.python.org (Chris Morton)
Date: Mon, 15 Mar 2021 03:28:04 +0000
Subject: [issue43482] Py_AddPendingCall Function Never Called in 3.8,
 works in 3.6
In-Reply-To: <1615587100.2.0.130476300444.issue43482@roundup.psfhosted.org>
Message-ID: <1615778884.94.0.100482198507.issue43482@roundup.psfhosted.org>


Chris Morton <chrisgmorton at yahoo.com> added the comment:

I should add that Py_AddPendingCall returns 0 in both cases.

----------
title: PyAddPendingCall Function Never Called in 3.8, works in 3.6 -> Py_AddPendingCall Function Never Called in 3.8, works in 3.6
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43482>
_______________________________________

From report at bugs.python.org  Sun Mar 14 23:29:17 2021
From: report at bugs.python.org (Chris Morton)
Date: Mon, 15 Mar 2021 03:29:17 +0000
Subject: [issue43482] Py_AddPendingCall Inserted Function Never Called in 3.8, 
 works in 3.6
In-Reply-To: <1615587100.2.0.130476300444.issue43482@roundup.psfhosted.org>
Message-ID: <1615778957.72.0.929670974954.issue43482@roundup.psfhosted.org>


Change by Chris Morton <chrisgmorton at yahoo.com>:


----------
title: Py_AddPendingCall Function Never Called in 3.8, works in 3.6 -> Py_AddPendingCall Inserted Function Never Called in 3.8, works in 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43482>
_______________________________________

From report at bugs.python.org  Sun Mar 14 23:58:11 2021
From: report at bugs.python.org (C.A.M. Gerlach)
Date: Mon, 15 Mar 2021 03:58:11 +0000
Subject: [issue32592] Drop support of Windows Vista and 7 in Python 3.9
In-Reply-To: <1516268238.05.0.467229070634.issue32592@psf.upfronthosting.co.za>
Message-ID: <1615780691.99.0.151622674269.issue32592@roundup.psfhosted.org>


C.A.M. Gerlach <CAM.Gerlach at Gerlach.CAM> added the comment:

Sorry I never got around to this, I was planning on it and then life and COVID intervened. I can give it another look now to get it in before the 3.10 feature freeze (since I at least documented in detail what each change should be, so it should be relatively straightforward) unless someone else would rather take it.

> PEP 11 says that "[a] new feature release X.Y.0 will support all Windows releases whose extended support phase is not yet expired". There was no such thing as Extended Security Updates (ESU) when that provision was accepted. As defined by PEP 11, extended support for Windows 7 ended on 2020-01-14. 

Yeah, "Extended Support" has a very specific, defined meaning [1] in Microsoft standard terminology (and other vendors as well), as the support phase after "Mainstream Support" but before the product end of life, where security updates and potentially limited bugfixes are still offered to all customers and the product is still considered supported, but new features and phone support is not. This ended 2020-01-24.

[1] https://docs.microsoft.com/en-us/lifecycle/policies/fixed

ESU [2] is a specialized, paid program available to high volume enterprise customers as a "last resort option" that pay big $$$ to continue receiving critical security updates for a limited time. This fulfills neither the letter nor the spirit of the policy defined in PEP 11; if such vendors need support for bleeding-edge Python versions for some reason, it certainly should be well within their means to fund someone to do so.

[2] https://docs.microsoft.com/en-us/lifecycle/faq/extended-security-updates

----------
versions: +Python 3.10 -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32592>
_______________________________________

From report at bugs.python.org  Mon Mar 15 00:21:44 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 15 Mar 2021 04:21:44 +0000
Subject: [issue43199] FAQ about goto lacks answer
In-Reply-To: <1613036693.06.0.0717598867229.issue43199@roundup.psfhosted.org>
Message-ID: <1615782104.46.0.347026635816.issue43199@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c3f03333c3a9c7aa213a463c5928d33fd4049060 by Miss Islington (bot) in branch '3.9':
bpo-43199: Briefly explain why no goto (GH-24852)
https://github.com/python/cpython/commit/c3f03333c3a9c7aa213a463c5928d33fd4049060


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43199>
_______________________________________

From report at bugs.python.org  Mon Mar 15 00:21:56 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 15 Mar 2021 04:21:56 +0000
Subject: [issue43199] FAQ about goto lacks answer
In-Reply-To: <1613036693.06.0.0717598867229.issue43199@roundup.psfhosted.org>
Message-ID: <1615782116.67.0.881519399298.issue43199@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 59f2741c4a1a53d4122d2cb512337f4b88619de9 by Miss Islington (bot) in branch '3.8':
bpo-43199: Briefly explain why no goto (GH-24852)
https://github.com/python/cpython/commit/59f2741c4a1a53d4122d2cb512337f4b88619de9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43199>
_______________________________________

From report at bugs.python.org  Mon Mar 15 00:22:31 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 15 Mar 2021 04:22:31 +0000
Subject: [issue43199] FAQ about goto lacks answer
In-Reply-To: <1613036693.06.0.0717598867229.issue43199@roundup.psfhosted.org>
Message-ID: <1615782151.68.0.394375184957.issue43199@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43199>
_______________________________________

From report at bugs.python.org  Mon Mar 15 01:26:59 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 15 Mar 2021 05:26:59 +0000
Subject: [issue43496] Save As dialog in IDLE doesn't accept keyboard shortcuts
 on MacOS
In-Reply-To: <1615772429.67.0.84187114429.issue43496@roundup.psfhosted.org>
Message-ID: <1615786019.6.0.589159603253.issue43496@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The menu items and Windows shortcuts work on Windows 10.  Several shortcuts and some menu items do not work on macOS.  The latter is true for the undo and clipboard  items at the top of the Edit menu.  The shortcuts do cause 'Edit' to flash, indicating that the shortcut was recognized and suggesting that the corresponding event handler was called.

If so, this is not obviously an IDLE issue.  IDLE calls tkinter.filedialog.SaveAs.  IDLE does nothing with its key bindings and I do not believe it could.  Tkinter calls tk_getSaveFile.  https://www.tcl.tk/man/tcl8.6/TkCmd/getOpenFile.htm.  So this might instead be a tkinter or tcl/tk issue.

To decide, someone should write a short IDLE-free tkinter program that calls the tkinter SaveAs function.  If that fails, a wish tk program could be tested.

----------
assignee: terry.reedy -> 
components: +Tkinter
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43496>
_______________________________________

From report at bugs.python.org  Mon Mar 15 02:14:35 2021
From: report at bugs.python.org (Alfred Perlstein)
Date: Mon, 15 Mar 2021 06:14:35 +0000
Subject: [issue35753] Importing call from unittest.mock directly causes
 ValueError
In-Reply-To: <1547669844.88.0.953853980523.issue35753@roundup.psfhosted.org>
Message-ID: <1615788875.74.0.454403480703.issue35753@roundup.psfhosted.org>


Alfred Perlstein <alfred at freebsd.org> added the comment:

I have a patch here that fixes this: https://github.com/python/cpython/pull/22981

It simply swallows the unwrap exception making doctest immune to such buggy objects.

Can someone help it get reviewed please?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35753>
_______________________________________

From report at bugs.python.org  Mon Mar 15 03:31:25 2021
From: report at bugs.python.org (Greg Darke)
Date: Mon, 15 Mar 2021 07:31:25 +0000
Subject: [issue43497] SyntaxWarning for "assertion is always true,
 perhaps remove parentheses?" does not work with constants
Message-ID: <1615793485.02.0.990067169214.issue43497@roundup.psfhosted.org>


New submission from Greg Darke <darke at google.com>:

The following block of code does not produce a SyntaxWarning in python 3.7 and above (it does produce a warning in python 3.6 and below):

```
assert(False, 'msg')
```

If the tuple is not a constant (for example `(x, 'msg')`), then a warning is still produced.

----------
components: Interpreter Core
messages: 388711
nosy: darke2
priority: normal
severity: normal
status: open
title: SyntaxWarning for "assertion is always true, perhaps remove parentheses?" does not work with constants
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/issue43497>
_______________________________________

From report at bugs.python.org  Mon Mar 15 03:48:12 2021
From: report at bugs.python.org (Greg Darke)
Date: Mon, 15 Mar 2021 07:48:12 +0000
Subject: [issue43497] SyntaxWarning for "assertion is always true,
 perhaps remove parentheses?" does not work with constants
In-Reply-To: <1615793485.02.0.990067169214.issue43497@roundup.psfhosted.org>
Message-ID: <1615794492.19.0.671875327616.issue43497@roundup.psfhosted.org>


Change by Greg Darke <darke at google.com>:


----------
keywords: +patch
pull_requests: +23629
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24867

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43497>
_______________________________________

From report at bugs.python.org  Mon Mar 15 04:08:02 2021
From: report at bugs.python.org (4-launchpad-kalvdans-no-ip-org)
Date: Mon, 15 Mar 2021 08:08:02 +0000
Subject: [issue25625] "chdir" Contex manager for pathlib
In-Reply-To: <1447523143.32.0.921942004004.issue25625@psf.upfronthosting.co.za>
Message-ID: <1615795682.96.0.133478249949.issue25625@roundup.psfhosted.org>


Change by 4-launchpad-kalvdans-no-ip-org <launchpad at kalvdans.no-ip.org>:


----------
nosy: +4-launchpad-kalvdans-no-ip-org

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25625>
_______________________________________

From report at bugs.python.org  Mon Mar 15 04:23:36 2021
From: report at bugs.python.org (Jakub Kulik)
Date: Mon, 15 Mar 2021 08:23:36 +0000
Subject: [issue43498] "dictionary changed size during iteration" error in
 _ExecutorManagerThread
Message-ID: <1615796616.26.0.51182574064.issue43498@roundup.psfhosted.org>


New submission from Jakub Kulik <kulikjak at gmail.com>:

Recently several of our Python 3.9 builds froze during `make install` with the following trace in logs:

Listing .../components/python/python39/build/prototype/sparc/usr/lib/python3.9/lib2to3/tests/data/fixers/myfixes...
Exception in thread Thread-1:
Traceback (most recent call last):
  File ".../components/python/python39/build/prototype/sparc/usr/lib/python3.9/threading.py", line 954, in _bootstrap_inner
    self.run()
  File ".../components/python/python39/build/prototype/sparc/usr/lib/python3.9/concurrent/futures/process.py", line 317, in run
    result_item, is_broken, cause = self.wait_result_broken_or_wakeup()
  File ".../components/python/python39/build/prototype/sparc/usr/lib/python3.9/concurrent/futures/process.py", line 376, in wait_result_broken_or_wakeup
    worker_sentinels = [p.sentinel for p in self.processes.values()]
  File ".../components/python/python39/build/prototype/sparc/usr/lib/python3.9/concurrent/futures/process.py", line 376, in <listcomp>
    worker_sentinels = [p.sentinel for p in self.processes.values()]
RuntimeError: dictionary changed size during iteration

After this, the build freezes and never ends (most likely waiting for the broken thread).

We see this only in Python 3.9 (3.7 doesn't seem to be affected, and we don't deliver other versions) and only when doing full builds of the entire Userland, meaning that this might be related to big utilization of the build machine? That said, it only happened three or four times, so this might be just a coincidence.

Simple fix seems to be this (PR shortly):

--- Python-3.9.1/Lib/concurrent/futures/process.py
+++ Python-3.9.1/Lib/concurrent/futures/process.py
@@ -373,7 +373,7 @@ class _ExecutorManagerThread(threading.T
         assert not self.thread_wakeup._closed
         wakeup_reader = self.thread_wakeup._reader
         readers = [result_reader, wakeup_reader]
-        worker_sentinels = [p.sentinel for p in self.processes.values()]
+        worker_sentinels = [p.sentinel for p in self.processes.copy().values()]
         ready = mp.connection.wait(readers + worker_sentinels)
 
         cause = None


This is on Oracle Solaris and on both SPARC and Intel machines.

----------
components: Installation, asyncio
messages: 388712
nosy: asvetlov, kulikjak, yselivanov
priority: normal
severity: normal
status: open
title: "dictionary changed size during iteration" error in _ExecutorManagerThread
type: crash
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43498>
_______________________________________

From report at bugs.python.org  Mon Mar 15 04:26:34 2021
From: report at bugs.python.org (Jakub Kulik)
Date: Mon, 15 Mar 2021 08:26:34 +0000
Subject: [issue43498] "dictionary changed size during iteration" error in
 _ExecutorManagerThread
In-Reply-To: <1615796616.26.0.51182574064.issue43498@roundup.psfhosted.org>
Message-ID: <1615796794.91.0.386121836529.issue43498@roundup.psfhosted.org>


Change by Jakub Kulik <kulikjak at gmail.com>:


----------
keywords: +patch
pull_requests: +23630
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24868

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43498>
_______________________________________

From report at bugs.python.org  Mon Mar 15 04:29:16 2021
From: report at bugs.python.org (Zackery Spytz)
Date: Mon, 15 Mar 2021 08:29:16 +0000
Subject: [issue24498] Should ptags and eptags be removed from repo?
In-Reply-To: <1435155990.35.0.688744790399.issue24498@psf.upfronthosting.co.za>
Message-ID: <1615796956.66.0.162040295307.issue24498@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 1.0 -> 2.0
pull_requests: +23631
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/24869

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24498>
_______________________________________

From report at bugs.python.org  Mon Mar 15 04:52:53 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 15 Mar 2021 08:52:53 +0000
Subject: [issue43483] Loss of content in simple (but oversize) SAX parsing
In-Reply-To: <1615599352.35.0.560655392831.issue43483@roundup.psfhosted.org>
Message-ID: <1615798373.01.0.186281363504.issue43483@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Perhaps you could open a documentation bug? I think specific examples of where the documentation is wrong, and how it could be improved, would be helpful.

Thanks!

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43483>
_______________________________________

From report at bugs.python.org  Mon Mar 15 05:00:06 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 15 Mar 2021 09:00:06 +0000
Subject: =?utf-8?q?=5Bissue43181=5D_Python_macros_don=E2=80=99t_shield_arguments?=
In-Reply-To: <1612908350.59.0.954965139249.issue43181@roundup.psfhosted.org>
Message-ID: <1615798806.33.0.970873009443.issue43181@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

> As I wrote previously, I dislike macros. If someone is changed, I would prefer to convert the function into a static inline function which doesn't have macros pitfalls.

Should we create a meta issue for this? Most macros are trivial, and can safely be converted, given that they're not used as l-values. Converting one header file at the time would make it easy to review, and it would be possible to make good progress in a few months time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43181>
_______________________________________

From report at bugs.python.org  Mon Mar 15 05:23:58 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 15 Mar 2021 09:23:58 +0000
Subject: [issue42917] Block stack size for frame objects should be dynamically
 sizable
In-Reply-To: <1610502849.77.0.30833881241.issue42917@roundup.psfhosted.org>
Message-ID: <1615800238.14.0.33746068239.issue42917@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

> There are also other ideas floating about for improving memory locality related to the frame stack, e.g. putting the stack frames in an array instead of a linked list.

Would it work with generators and coroutines?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42917>
_______________________________________

From report at bugs.python.org  Mon Mar 15 05:28:16 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 15 Mar 2021 09:28:16 +0000
Subject: [issue43497] SyntaxWarning for "assertion is always true,
 perhaps remove parentheses?" does not work with constants
In-Reply-To: <1615793485.02.0.990067169214.issue43497@roundup.psfhosted.org>
Message-ID: <1615800496.67.0.627355812795.issue43497@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

What is the use case for assert with a constant?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43497>
_______________________________________

From report at bugs.python.org  Mon Mar 15 05:36:44 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 15 Mar 2021 09:36:44 +0000
Subject: [issue43475] Worst-case behaviour of hash collision with float NaN
In-Reply-To: <1615474533.28.0.166606930148.issue43475@roundup.psfhosted.org>
Message-ID: <1615801004.45.0.424142836627.issue43475@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

What about Decimal NaN? Even if make float NaN a singleton, there will be other NaNs.

And making float('nan') returning a singleton, but 1e1000 * 0 returning different NaN would cause large confusion.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43475>
_______________________________________

From report at bugs.python.org  Mon Mar 15 05:44:18 2021
From: report at bugs.python.org (Greg Darke)
Date: Mon, 15 Mar 2021 09:44:18 +0000
Subject: [issue43497] SyntaxWarning for "assertion is always true,
 perhaps remove parentheses?" does not work with constants
In-Reply-To: <1615793485.02.0.990067169214.issue43497@roundup.psfhosted.org>
Message-ID: <1615801458.27.0.268060242648.issue43497@roundup.psfhosted.org>


Greg Darke <darke at google.com> added the comment:

I would argue that there is none (especially if it is tuple/something that is always true) -- thus why I would assume that Python would provide a warning.

This bug comes from a discussion I was having with someone earlier today where they mentioned that it would be nice if the linter complained about the following::

  assert 'not reachable'

That code is incorrect (the assertion will never fire, due to the string evaluating to True). We remembered that python did complain about tuples, and tried to see what the warning looked like using a trivial example::

  assert(False, 'msg')

We noticed that this code did not produce a warning on python3.8, but did produce a warning on python2.7.

After much digging we found that the following did work on python3.8::

  assert(False, str())

This allowed us to deduce that something special was happening with constants (well, it also required us to look at the disassembly of the ops codes for the above two statements).

Going back to your original question, I have used `assert False` in code to "test" if a piece of code was being reached. I have also used it for things similar to the piece of code that started all of this::

  if some_expression:
    # ...
  elif some_other_expression:
    #...
  else:
    assert False, 'This code is unreachable'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43497>
_______________________________________

From report at bugs.python.org  Mon Mar 15 05:53:10 2021
From: report at bugs.python.org (E. Paine)
Date: Mon, 15 Mar 2021 09:53:10 +0000
Subject: [issue43496] Save As dialog in IDLE doesn't accept keyboard shortcuts
 on MacOS
In-Reply-To: <1615772429.67.0.84187114429.issue43496@roundup.psfhosted.org>
Message-ID: <1615801990.44.0.653815793612.issue43496@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

This is reproducible using tkinter in Python 3.9.2 installed using both the regular Intel and Universal2 installers. It is also reproducible in Wish 8.6.10. (tested on MacOS 11.2.1)

----------
components:  -IDLE
nosy: +epaine

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43496>
_______________________________________

From report at bugs.python.org  Mon Mar 15 05:58:09 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 15 Mar 2021 09:58:09 +0000
Subject: [issue1103350] send/recv SEGMENT_SIZE should be used more in
 socketmodule
Message-ID: <1615802289.17.0.527831223746.issue1103350@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

FYI, the SEGMENT_SIZE define was removed by af01f668173d4061893148b54a0f01b91c7716c2 (bpo-16136).

----------
nosy: +erlendaasland

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1103350>
_______________________________________

From report at bugs.python.org  Mon Mar 15 05:57:59 2021
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 15 Mar 2021 09:57:59 +0000
Subject: [issue43334] venv does not install libpython
In-Reply-To: <1614379216.7.0.137032053148.issue43334@roundup.psfhosted.org>
Message-ID: <1615802279.17.0.293159393549.issue43334@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

This is not a bug - venvs are primarily *run*-time (as opposed to development-time) environments, into which you install pre-built Python packages (including ones with C extensions). Can you give a specific example where creating a venv and installing packages into it leads to a problem due to libpython.XXX being unavailable, with a series of steps to reproduce? If not, this issue will need to be closed.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43334>
_______________________________________

From report at bugs.python.org  Mon Mar 15 06:00:34 2021
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 15 Mar 2021 10:00:34 +0000
Subject: [issue37820] Unnecessary URL scheme exists to allow 'URL: reading
 file in urllib
In-Reply-To: <1565522189.95.0.525978892849.issue37820@roundup.psfhosted.org>
Message-ID: <1615802434.04.0.482823254594.issue37820@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

It's a Python 2-only problem. Python 2 no longer receives security fixes. Please update to a supported version of Python or report the issue with your vendor.

----------
nosy: +christian.heimes
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37820>
_______________________________________

From report at bugs.python.org  Mon Mar 15 06:01:11 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 15 Mar 2021 10:01:11 +0000
Subject: [issue43497] SyntaxWarning for "assertion is always true,
 perhaps remove parentheses?" does not work with constants
In-Reply-To: <1615793485.02.0.990067169214.issue43497@roundup.psfhosted.org>
Message-ID: <1615802471.46.0.285422047552.issue43497@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

In such case I prefer to write

    assert not 'reachable'

It is shorter than writing False.

If I want to keep an exception even with -O, I write

    raise AssertionError

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43497>
_______________________________________

From report at bugs.python.org  Mon Mar 15 06:03:34 2021
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 15 Mar 2021 10:03:34 +0000
Subject: [issue43334] venv does not install libpython
In-Reply-To: <1614379216.7.0.137032053148.issue43334@roundup.psfhosted.org>
Message-ID: <1615802614.09.0.424206524668.issue43334@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

I agree with Vinay. venvs don't contain copies of libpython or header files by design. setuptools will pcik them up from the main installation.

If you have any issues with compiling C extensions, please report them with setuptools at https://github.com/pypa/setuptools/

----------
nosy: +christian.heimes
resolution:  -> not a bug
stage:  -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43334>
_______________________________________

From report at bugs.python.org  Mon Mar 15 06:25:45 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 15 Mar 2021 10:25:45 +0000
Subject: [issue12777] Inconsistent use of VOLUME_NAME_* with
 GetFinalPathNameByHandle
In-Reply-To: <1313677947.11.0.030758892383.issue12777@psf.upfronthosting.co.za>
Message-ID: <1615803945.95.0.953290309853.issue12777@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

This seems to have been fixed in 2018 in bpo-33016 by GH-6010.

----------
nosy: +erlendaasland

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12777>
_______________________________________

From report at bugs.python.org  Mon Mar 15 06:27:08 2021
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Mon, 15 Mar 2021 10:27:08 +0000
Subject: [issue37820] Unnecessary URL scheme exists to allow 'URL: reading
 file in urllib
In-Reply-To: <1565522189.95.0.525978892849.issue37820@roundup.psfhosted.org>
Message-ID: <1615804028.11.0.539591384192.issue37820@roundup.psfhosted.org>


Change by Miro Hron?ok <miro at hroncok.cz>:


----------
nosy: +hroncok
nosy_count: 3.0 -> 4.0
pull_requests: +23632
pull_request: https://github.com/python/cpython/pull/24870

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37820>
_______________________________________

From report at bugs.python.org  Mon Mar 15 06:54:55 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 15 Mar 2021 10:54:55 +0000
Subject: [issue15698] PEP 3121, 384 Refactoring applied to pyexpat module
In-Reply-To: <1345146901.0.0.136939773234.issue15698@psf.upfronthosting.co.za>
Message-ID: <1615805695.31.0.967054411036.issue15698@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

Fixed by GH-22222.

----------
nosy: +erlendaasland, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15698>
_______________________________________

From report at bugs.python.org  Mon Mar 15 07:22:23 2021
From: report at bugs.python.org (Anton Khirnov)
Date: Mon, 15 Mar 2021 11:22:23 +0000
Subject: [issue39100] email.policy.SMTP throws AttributeError on invalid header
In-Reply-To: <1576783934.54.0.946649596481.issue39100@roundup.psfhosted.org>
Message-ID: <1615807343.92.0.104878918636.issue39100@roundup.psfhosted.org>


Change by Anton Khirnov <anton at khirnov.net>:


----------
keywords: +patch
pull_requests: +23633
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24872

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39100>
_______________________________________

From report at bugs.python.org  Mon Mar 15 08:01:40 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Mar 2021 12:01:40 +0000
Subject: =?utf-8?q?=5Bissue43181=5D_Python_macros_don=E2=80=99t_shield_arguments?=
In-Reply-To: <1612908350.59.0.954965139249.issue43181@roundup.psfhosted.org>
Message-ID: <1615809700.52.0.42039563997.issue43181@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

If possible, I would prefer to only replace macros with static inline functions if the changes avoids clear macro pitfalls. It's not because macros have pitfalls that we must replace them all blindly.

Also, this issue is closed. At this point, I'm not convinced that it's worth it to fix PyObject_TypeCheck() in Python 3.8 and 3.9, so I leave the issue closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43181>
_______________________________________

From report at bugs.python.org  Mon Mar 15 08:02:06 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Mar 2021 12:02:06 +0000
Subject: [issue27929] asyncio.AbstractEventLoop.sock_connect broken for
 AF_BLUETOOTH
In-Reply-To: <1472738395.77.0.643111482192.issue27929@psf.upfronthosting.co.za>
Message-ID: <1615809726.79.0.469698402241.issue27929@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27929>
_______________________________________

From report at bugs.python.org  Mon Mar 15 08:02:46 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Mar 2021 12:02:46 +0000
Subject: [issue15698] PEP 3121, 384 Refactoring applied to pyexpat module
In-Reply-To: <1345146901.0.0.136939773234.issue15698@psf.upfronthosting.co.za>
Message-ID: <1615809766.73.0.120986505065.issue15698@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Py_Finalize() doesn't clear all Python objects at exit

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15698>
_______________________________________

From report at bugs.python.org  Mon Mar 15 08:03:25 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Mar 2021 12:03:25 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1615809805.86.0.122456197168.issue1635741@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I marked bpo-15698 "PEP 3121, 384 Refactoring applied to pyexpat module" as a duplicate of this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Mon Mar 15 08:04:22 2021
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Mon, 15 Mar 2021 12:04:22 +0000
Subject: [issue37741] importlib.metadata docs not showing up in the module
 index
In-Reply-To: <1564685225.86.0.948746560612.issue37741@roundup.psfhosted.org>
Message-ID: <1615809862.92.0.782919661453.issue37741@roundup.psfhosted.org>


Miro Hron?ok <miro at hroncok.cz> added the comment:

The docs at https://docs.python.org/3/library/importlib.metadata.html also don't list the API at all, it is just a tutorial, not a reference. I see the code has docstrings, but they are missing from the docs. E.g. PackageNotFoundError is not documented at all.

----------
nosy: +hroncok

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37741>
_______________________________________

From report at bugs.python.org  Mon Mar 15 08:07:33 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 15 Mar 2021 12:07:33 +0000
Subject: =?utf-8?q?=5Bissue43181=5D_Python_macros_don=E2=80=99t_shield_arguments?=
In-Reply-To: <1612908350.59.0.954965139249.issue43181@roundup.psfhosted.org>
Message-ID: <1615810053.31.0.474799523888.issue43181@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

> If possible, I would prefer to only replace macros with static inline functions if the changes avoids clear macro pitfalls.

Yes, of course. Should I create a meta issue for this, or do you prefer raising one issue pr. fix?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43181>
_______________________________________

From report at bugs.python.org  Mon Mar 15 08:12:03 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 15 Mar 2021 12:12:03 +0000
Subject: [issue43499] Compiler warnings in building Python 3.9 on Windows
Message-ID: <1615810323.65.0.00918597187884.issue43499@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Currently building Python 3.9 on Windows produce many compiler warnings. 3.8 and master are clean.

* Warnings in the _sre module caused by the bug in MSVC (complains about automatic conversion of "void **" to "const void *"). Fixed by backporting PR20508.

* Warnings in many files related to using legacy C API (e.g. PyUnicode_AsUnicode) in Windows specific code.

* ..\Objects\exceptions.c(2313): warning C4098: 'MemoryError_dealloc': 'void' function returning a value

* ..\Objects\frameobject.c(400): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data

The last two may be hidden bugs.

----------
components: Extension Modules, Interpreter Core
messages: 388731
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Compiler warnings in building Python 3.9 on Windows
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43499>
_______________________________________

From report at bugs.python.org  Mon Mar 15 08:14:13 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 15 Mar 2021 12:14:13 +0000
Subject: [issue43499] Compiler warnings in building Python 3.9 on Windows
In-Reply-To: <1615810323.65.0.00918597187884.issue43499@roundup.psfhosted.org>
Message-ID: <1615810453.63.0.97563854144.issue43499@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +23634
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24873

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43499>
_______________________________________

From report at bugs.python.org  Mon Mar 15 08:30:48 2021
From: report at bugs.python.org (wyz23x2)
Date: Mon, 15 Mar 2021 12:30:48 +0000
Subject: [issue43500] Add filtercase() into fnmatch
Message-ID: <1615811448.09.0.46189738482.issue43500@roundup.psfhosted.org>


New submission from wyz23x2 <wyz23x2 at 163.com>:

The fnmatch module has a filter() function:
> Construct a list from those elements of the iterable names that match pattern.
> It is the same as [n for n in names if fnmatch(n, pattern)], but implemented more efficiently.
However, since there is the fnmatchcase() function, we should have filtercase() too.

----------
components: Library (Lib)
messages: 388732
nosy: wyz23x2
priority: normal
severity: normal
status: open
title: Add filtercase() into fnmatch
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43500>
_______________________________________

From report at bugs.python.org  Mon Mar 15 08:31:17 2021
From: report at bugs.python.org (wyz23x2)
Date: Mon, 15 Mar 2021 12:31:17 +0000
Subject: [issue43500] Add filtercase() into fnmatch
In-Reply-To: <1615811448.09.0.46189738482.issue43500@roundup.psfhosted.org>
Message-ID: <1615811477.15.0.0174049261457.issue43500@roundup.psfhosted.org>


Change by wyz23x2 <wyz23x2 at 163.com>:


----------
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43500>
_______________________________________

From report at bugs.python.org  Mon Mar 15 08:51:31 2021
From: report at bugs.python.org (Hamza Avvan)
Date: Mon, 15 Mar 2021 12:51:31 +0000
Subject: [issue43223] [security] http.server: Open Redirection if the URL path
 starts with //
In-Reply-To: <1613302956.91.0.878390782912.issue43223@roundup.psfhosted.org>
Message-ID: <1615812691.38.0.591527598959.issue43223@roundup.psfhosted.org>


Change by Hamza Avvan <hamzaavvaan at gmail.com>:


----------
hgrepos: +404

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43223>
_______________________________________

From report at bugs.python.org  Mon Mar 15 08:52:56 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Mar 2021 12:52:56 +0000
Subject: =?utf-8?q?=5Bissue43181=5D_Python_macros_don=E2=80=99t_shield_arguments?=
In-Reply-To: <1612908350.59.0.954965139249.issue43181@roundup.psfhosted.org>
Message-ID: <1615812776.12.0.231373941633.issue43181@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

You can create a single issue, and later we will see if it's needed to split it into sub-issues.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43181>
_______________________________________

From report at bugs.python.org  Mon Mar 15 09:03:16 2021
From: report at bugs.python.org (junyixie)
Date: Mon, 15 Mar 2021 13:03:16 +0000
Subject: [issue43313] feature: support pymalloc for subinterpreters. each
 subinterpreter has pymalloc_state
In-Reply-To: <1614159809.71.0.199865657429.issue43313@roundup.psfhosted.org>
Message-ID: <1615813396.21.0.613149904978.issue43313@roundup.psfhosted.org>


junyixie <xie.junyi at outlook.com> added the comment:

There is a problem:
if we bound pymalloc state with a interpreter.
malloc pointer in interpreterA and free pointer is usual.

it's cause a problem. 
when we use PyObject_Free, 
1. we look up address in pymalloc pool.
2. if not find, current code will call PyMem_RawFree(p) to free. it will cause crash.(address is pymalloc_alloc from another interpreter)

I think it has two way to slove this problem:
1. free/alloc memory in one interpreter. Frequent switch interpreter affects performance
2. when free memory address, find this address in all interpreter pymalloc pool. and free it.(but it need add lock to pymalloc)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43313>
_______________________________________

From report at bugs.python.org  Mon Mar 15 09:04:20 2021
From: report at bugs.python.org (junyixie)
Date: Mon, 15 Mar 2021 13:04:20 +0000
Subject: [issue43313] feature: support pymalloc for subinterpreters. each
 subinterpreter has pymalloc_state
In-Reply-To: <1614159809.71.0.199865657429.issue43313@roundup.psfhosted.org>
Message-ID: <1615813460.91.0.0522499332382.issue43313@roundup.psfhosted.org>


junyixie <xie.junyi at outlook.com> added the comment:

> malloc pointer in interpreterA and free pointer is usual.

malloc pointer in interpreterA and free pointer in interpreterB is usual.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43313>
_______________________________________

From report at bugs.python.org  Mon Mar 15 09:06:43 2021
From: report at bugs.python.org (junyixie)
Date: Mon, 15 Mar 2021 13:06:43 +0000
Subject: [issue43313] feature: support pymalloc for subinterpreters. each
 subinterpreter has pymalloc_state
In-Reply-To: <1614159809.71.0.199865657429.issue43313@roundup.psfhosted.org>
Message-ID: <1615813603.03.0.597041476973.issue43313@roundup.psfhosted.org>


junyixie <xie.junyi at outlook.com> added the comment:

by the way, 
There is no operation to destroy the memory pool in the cpython code. Repeated creation of the pymalloc pool will cause memory leaks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43313>
_______________________________________

From report at bugs.python.org  Mon Mar 15 09:09:24 2021
From: report at bugs.python.org (junyixie)
Date: Mon, 15 Mar 2021 13:09:24 +0000
Subject: [issue43313] feature: support pymalloc for subinterpreters. each
 subinterpreter has pymalloc_state
In-Reply-To: <1614159809.71.0.199865657429.issue43313@roundup.psfhosted.org>
Message-ID: <1615813764.98.0.816351715889.issue43313@roundup.psfhosted.org>


junyixie <xie.junyi at outlook.com> added the comment:

> 2. when free memory address, find this address in all interpreter pymalloc pool. and free it.(but it need add lock to pymalloc)

when finalize_interp_delete, we need keep interpreter pymalloc pool in linked list.It will be used when search memory in pymalloc pools.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43313>
_______________________________________

From report at bugs.python.org  Mon Mar 15 09:11:05 2021
From: report at bugs.python.org (Anton Khirnov)
Date: Mon, 15 Mar 2021 13:11:05 +0000
Subject: [issue43501] email._header_value_parse throws AttributeError on
 display name ending with dot
Message-ID: <1615813865.05.0.348558302999.issue43501@roundup.psfhosted.org>


New submission from Anton Khirnov <anton at khirnov.net>:

On parsing an email where the display name in an address ends on a dot immediately followed by angle-addr, accessing the resulting mailbox display_name throws
/usr/lib/python3.9/email/_header_value_parser.py in value(self)
    589             if self[0].token_type=='cfws' or self[0][0].token_type=='cfws':
    590                 pre = ' '
--> 591             if self[-1].token_type=='cfws' or self[-1][-1].token_type=='cfws':
    592                 post = ' '
    593             return pre+quote_string(self.display_name)+post

AttributeError: 'str' object has no attribute 'token_type'

The problem is that self[-1] is the terminal DOT.

An example of the problematic header is:
From: foobar.<baz at spam>

----------
components: email
messages: 388738
nosy: barry, elenril, r.david.murray
priority: normal
severity: normal
status: open
title: email._header_value_parse throws AttributeError on display name ending with dot
type: behavior
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43501>
_______________________________________

From report at bugs.python.org  Mon Mar 15 09:29:39 2021
From: report at bugs.python.org (Anton Khirnov)
Date: Mon, 15 Mar 2021 13:29:39 +0000
Subject: [issue43501] email._header_value_parse throws AttributeError on
 display name ending with dot
In-Reply-To: <1615813865.05.0.348558302999.issue43501@roundup.psfhosted.org>
Message-ID: <1615814979.3.0.382512632522.issue43501@roundup.psfhosted.org>


Change by Anton Khirnov <anton at khirnov.net>:


----------
keywords: +patch
pull_requests: +23636
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24874

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43501>
_______________________________________

From report at bugs.python.org  Mon Mar 15 09:54:44 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 15 Mar 2021 13:54:44 +0000
Subject: [issue43502] [C-API] Convert obvious unsafe macros to static inline
 functions
Message-ID: <1615816484.12.0.00251754107838.issue43502@roundup.psfhosted.org>


New submission from Erlend Egeberg Aasland <erlend.aasland at innova.no>:

Convert macros to static inline functions if...:
- the macro contains a clear pitfall (for example "duplication of side effects")
- the fix is trivial
- the macro is not used as an l-value (for example Py_TYPE())


See also:
- https://gcc.gnu.org/onlinedocs/cpp/Macro-Pitfalls.html
- bpo-43181
- bpo-39573
- bpo-40170

----------
components: C API
messages: 388739
nosy: corona10, erlendaasland, vstinner
priority: normal
severity: normal
status: open
title: [C-API] Convert obvious unsafe macros to static inline functions
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43502>
_______________________________________

From report at bugs.python.org  Mon Mar 15 10:12:30 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Mar 2021 14:12:30 +0000
Subject: [issue43502] [C-API] Convert obvious unsafe macros to static inline
 functions
In-Reply-To: <1615816484.12.0.00251754107838.issue43502@roundup.psfhosted.org>
Message-ID: <1615817550.47.0.575241129661.issue43502@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

For me, one of the my worst issue is when a macro evalutes an argument twice.

Example:
---
#include <stdio.h>

#define DOUBLE(value) ((value) + (value))

int main()
{
    int x = 1;
    // expanded to: ((++x) + (++x))
    int y = DOUBLE(++x);
    printf("x=%i y=%i\n", x, y);
    return 0;
}
---

Surprising output:
---
$ gcc x.c -o x; ./x
x=3 y=6
---

Expected output:
---
x=2 y=4
---

Fixed code using a static inline function:
---
#include <stdio.h>

static inline int DOUBLE(int value) {
    return value + value;
}

int main()
{
    int x = 1;
    // expanded to: DOUBLE(++x)
    int y = DOUBLE(++x);
    printf("x=%i y=%i\n", x, y);
    return 0;
}
---

Output:
---
$ gcc x.c -o x; ./x
x=2 y=4
---

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43502>
_______________________________________

From report at bugs.python.org  Mon Mar 15 10:17:22 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Mar 2021 14:17:22 +0000
Subject: [issue43502] [C-API] Convert obvious unsafe macros to static inline
 functions
In-Reply-To: <1615816484.12.0.00251754107838.issue43502@roundup.psfhosted.org>
Message-ID: <1615817842.46.0.746018255087.issue43502@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I would add that we should pay attention to:

* not introducing a backward incompatible C API change by mistake
* not introducing new compiler warnings.

A common source of warning is that macros have no type for their arguments or return value, whereas static inline functions are strictly types. A common pattern in the Python header file is to use _PyObject_CAST() or _PyObject_CONST_CAST(). Example:

#define _PyObject_CAST(op) ((PyObject*)(op))
#define _PyObject_CAST_CONST(op) ((const PyObject*)(op))

static inline void _Py_INCREF(PyObject *op) { (...) }
#define Py_INCREF(op) _Py_INCREF(_PyObject_CAST(op))

For macros of the *internal* C API, it's ok to becom more strict about types. For example, in the *public* C API, I replaced:

#define PyObject_INIT(op, typeobj) \
    ( Py_TYPE(op) = (typeobj), _Py_NewReference((PyObject *)(op)), (op) )

with:

PyAPI_FUNC(PyObject *) PyObject_Init(PyObject *, PyTypeObject *);
#define PyObject_INIT(op, typeobj) PyObject_Init(_PyObject_CAST(op), (typeobj))

But for the internal C API, I added:

static inline void _PyObject_Init(PyObject *op, PyTypeObject *typeobj) { ... }

which doesn't cast its arguments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43502>
_______________________________________

From report at bugs.python.org  Mon Mar 15 10:28:00 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 15 Mar 2021 14:28:00 +0000
Subject: [issue43502] [C-API] Convert obvious unsafe macros to static inline
 functions
In-Reply-To: <1615816484.12.0.00251754107838.issue43502@roundup.psfhosted.org>
Message-ID: <1615818480.13.0.641101899095.issue43502@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

Should we try to split all macros like that, if possible?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43502>
_______________________________________

From report at bugs.python.org  Mon Mar 15 10:36:23 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 15 Mar 2021 14:36:23 +0000
Subject: [issue43502] [C-API] Convert obvious unsafe macros to static inline
 functions
In-Reply-To: <1615816484.12.0.00251754107838.issue43502@roundup.psfhosted.org>
Message-ID: <1615818983.58.0.474926776631.issue43502@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


----------
keywords: +patch
pull_requests: +23637
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24875

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43502>
_______________________________________

From report at bugs.python.org  Mon Mar 15 10:37:55 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Mar 2021 14:37:55 +0000
Subject: [issue43313] feature: support pymalloc for subinterpreters. each
 subinterpreter has pymalloc_state
In-Reply-To: <1614159809.71.0.199865657429.issue43313@roundup.psfhosted.org>
Message-ID: <1615819075.0.0.624798167433.issue43313@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I'm not sure that it's needed to have a "per interpreter" allocator. The needed feature is to be able to call PyMem_Malloc() in parallel in different threads. If I understood correctly, the glibc malloc has a per-thread fast allocator (no locking) and then falls back to a slow allocator (locking) if the fast allocator failed. Maybe pymalloc could have per-thread memory arenas.

When I implemented the PEP 587, I spend a significant amount of time to avoid using pymalloc before Py_Initialize() is called: only use PyMem_RawMalloc() before Py_Initialize().

But I'm not 100% sure that pymalloc is not used before Py_Initialize() nor *after* Py_Finalize(). For example, we should check if a daemon thread can call PyMem_Malloc() after Py_Finalize(), even if they are supposed to exit as soon as they try to acquire the GIL, even the GIL must be held to use pymalloc (to use PyMem_Malloc and PyObject_Malloc):
https://docs.python.org/dev/c-api/memory.html#memory-interface

See also bpo-37448:
"Add radix tree implementation for obmalloc address_in_range()"
https://github.com/python/cpython/pull/14474

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43313>
_______________________________________

From report at bugs.python.org  Mon Mar 15 10:38:25 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Mar 2021 14:38:25 +0000
Subject: [issue37448] obmalloc: radix tree for tracking arena address ranges
In-Reply-To: <1561849702.35.0.724599328196.issue37448@roundup.psfhosted.org>
Message-ID: <1615819105.12.0.893514895294.issue37448@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

See also bpo-43313: "feature: support pymalloc for subinterpreters. each subinterpreter has pymalloc_state".

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37448>
_______________________________________

From report at bugs.python.org  Mon Mar 15 10:38:30 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Mar 2021 14:38:30 +0000
Subject: [issue43313] feature: support pymalloc for subinterpreters. each
 subinterpreter has pymalloc_state
In-Reply-To: <1614159809.71.0.199865657429.issue43313@roundup.psfhosted.org>
Message-ID: <1615819110.12.0.718639205775.issue43313@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +methane, nascheme

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43313>
_______________________________________

From report at bugs.python.org  Mon Mar 15 10:39:50 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Mar 2021 14:39:50 +0000
Subject: [issue43313] feature: support pymalloc for subinterpreters. each
 subinterpreter has pymalloc_state
In-Reply-To: <1614159809.71.0.199865657429.issue43313@roundup.psfhosted.org>
Message-ID: <1615819190.33.0.71943860278.issue43313@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The current workaround is to disable pymalloc when Python is built with EXPERIMENTAL_ISOLATED_SUBINTERPRETERS:

_PyPreConfig_InitCompatConfig(PyPreConfig *config):

#ifdef EXPERIMENTAL_ISOLATED_SUBINTERPRETERS
    /* bpo-40512: pymalloc is not compatible with subinterpreters,
       force usage of libc malloc() which is thread-safe. */
#ifdef Py_DEBUG
    config->allocator = PYMEM_ALLOCATOR_MALLOC_DEBUG;
#else
    config->allocator = PYMEM_ALLOCATOR_MALLOC;
#endif
#else
    ...
#endif

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43313>
_______________________________________

From report at bugs.python.org  Mon Mar 15 10:40:14 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Mar 2021 14:40:14 +0000
Subject: [issue40512] [subinterpreters] Meta issue: per-interpreter GIL
In-Reply-To: <1588683075.13.0.0239787407564.issue40512@roundup.psfhosted.org>
Message-ID: <1615819214.65.0.715303214738.issue40512@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> * Add a lock to pymalloc, or disable pymalloc when subinterpreters are used: https://github.com/ericsnowcurrently/multi-core-python/issues/30

See bpo-43313: "feature: support pymalloc for subinterpreters. each subinterpreter has pymalloc_state".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40512>
_______________________________________

From report at bugs.python.org  Mon Mar 15 10:51:39 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 15 Mar 2021 14:51:39 +0000
Subject: [issue42917] Block stack size for frame objects should be dynamically
 sizable
In-Reply-To: <1615800238.14.0.33746068239.issue42917@roundup.psfhosted.org>
Message-ID: <CAP7+vJK9NmXB_RPt6jG0d=fASMgP6UXJcpqVquMszLO0yq5riw@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

Yes, if we keep the top of the stack and the current frame in separate
variables.--
--Guido (mobile)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42917>
_______________________________________

From report at bugs.python.org  Mon Mar 15 11:49:57 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 15 Mar 2021 15:49:57 +0000
Subject: [issue43475] Worst-case behaviour of hash collision with float NaN
In-Reply-To: <1615474533.28.0.166606930148.issue43475@roundup.psfhosted.org>
Message-ID: <1615823397.8.0.285621613387.issue43475@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> And making float('nan') returning a singleton, 
> but 1e1000 * 0 returning different NaN would cause large confusion.

Not really, it would be just be an implementation detail, no different than int and strings being sometimes unique and sometimes not.  Historically, immutable objects are allowed to be reused when it is convenient for the implementation.

> What about Decimal NaN?

Decimal isn't used as much, so the need is less pressing, but we can do whatever is allowed by the spec.  Presumably, that would be easier than with floats because we control all possible ways to construct Decimals.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43475>
_______________________________________

From report at bugs.python.org  Mon Mar 15 12:28:51 2021
From: report at bugs.python.org (Florian Bruhin)
Date: Mon, 15 Mar 2021 16:28:51 +0000
Subject: [issue43463] typing.get_type_hints with TYPE_CHECKING imports /
 getting hints for single argument
In-Reply-To: <1615387121.09.0.336024174905.issue43463@roundup.psfhosted.org>
Message-ID: <1615825731.56.0.917900395923.issue43463@roundup.psfhosted.org>


Florian Bruhin <python.org at the-compiler.org> added the comment:

Fair points.

As an aside, I'm also wondering how inspect.Parameter.annotation should interact with the changes in Python 3.10? That used to be the canonical way (as far as I'm aware) of getting a single argument's type annotation (other than getting it from __annotations__ manually), but with PEP 563 now would always return a (probably not very useful?) string.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43463>
_______________________________________

From report at bugs.python.org  Mon Mar 15 13:05:23 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 15 Mar 2021 17:05:23 +0000
Subject: [issue43463] typing.get_type_hints with TYPE_CHECKING imports /
 getting hints for single argument
In-Reply-To: <1615825731.56.0.917900395923.issue43463@roundup.psfhosted.org>
Message-ID: <CAP7+vJ++Ms=2N9J=AuaqAMS5rObH=rYgk5f+2WHGbbgvXWW1Gg@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

Please open a separate issue for that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43463>
_______________________________________

From report at bugs.python.org  Mon Mar 15 13:28:53 2021
From: report at bugs.python.org (Ken Jin)
Date: Mon, 15 Mar 2021 17:28:53 +0000
Subject: [issue43463] typing.get_type_hints with TYPE_CHECKING imports /
 getting hints for single argument
In-Reply-To: <1615387121.09.0.336024174905.issue43463@roundup.psfhosted.org>
Message-ID: <1615829333.49.0.966713819377.issue43463@roundup.psfhosted.org>


Ken Jin <kenjin4096 at gmail.com> added the comment:

@Florian,

IIUC inspect.signature auto-resolves string annotations to typing.ForwardRef internally from 3.10 onwards. It's mentioned in the what's new for PEP 563 https://docs.python.org/3.10/whatsnew/3.10.html#pep-563-postponed-evaluation-of-annotations-becomes-default

If it fails, it will just give the string. So the only place where inspect.signature might start giving you different output is if you previously defined a function like so:

def foo(a: 'MyType'): ...

And you expected inspect.signature.paramters to be ``[<Parameter "a: 'MyType'">]`` (the string). However if MyType is in globals()/locals(), you'll instead get ``[<Parameter "a: MyType">]`` in 3.10.

FWIW someone already reported that in Issue43355.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43463>
_______________________________________

From report at bugs.python.org  Mon Mar 15 13:31:50 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 15 Mar 2021 17:31:50 +0000
Subject: [issue43496] macOS tkinter Save As doesn't accept keyboard shortcuts
In-Reply-To: <1615772429.67.0.84187114429.issue43496@roundup.psfhosted.org>
Message-ID: <1615829510.67.0.647566356091.issue43496@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Thank you, EP, for being 'someone'.  I should remember that you are the one who can current do these tests.  I presume the reproducible 'this' is the non-response to cmd-A, cmd-Z, and so on.  So closing as 3rd party, tcl/tk, issue.

I comfirmed that Jacob's expectation is reasonable in that the keys do work in the macOS save-as dialog opened from Safari (and I presume in other Apple-supplied apps).

The tk doc https://www.tcl.tk/man/tcl8.6/TkCmd/getOpenFile.htm says merely "pop up a dialog box for the user to select a file to open or save." Some details are system-specific.  The only promise about user interaction is that one can enter a new name when saving and either confirm or cancel.

The tkinter doc https://docs.python.org/3.10/library/dialog.html#module-tkinter.filedialog adds "native look-and-feel", but this is an interpretation of the intention of the tk function and is completely dependent on them.  Any failure of the 'feel' part should be reported to tk.  (The IDLE doc merely says "with a Save As dialog".)

The IDLE Edit menu only applies to its editable text windows.  Their menus are grayed out for modal dialogs.  Tkinter dialog entry boxes come with selection and clipboard hot keys, but not undo keys.

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed
title: Save As dialog in IDLE doesn't accept keyboard shortcuts on MacOS -> macOS tkinter Save As doesn't accept keyboard shortcuts

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43496>
_______________________________________

From report at bugs.python.org  Mon Mar 15 13:37:14 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 15 Mar 2021 17:37:14 +0000
Subject: [issue43478] Disallow Mock spec arguments from being Mocks
In-Reply-To: <1615514023.14.0.0477922265442.issue43478@roundup.psfhosted.org>
Message-ID: <1615829834.87.0.425487213588.issue43478@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/issue43478>
_______________________________________

From report at bugs.python.org  Mon Mar 15 13:39:05 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 15 Mar 2021 17:39:05 +0000
Subject: [issue43478] Disallow Mock spec arguments from being Mocks
In-Reply-To: <1615514023.14.0.0477922265442.issue43478@roundup.psfhosted.org>
Message-ID: <1615829945.53.0.748194124129.issue43478@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

Lets go ahead and try making this a breaking change in 3.10.  If users report it causes a bunch of problems during the beta -that they don't want to address so soon- (they are all likely bugs in test suites...) we can soften it to a warning for a cycle.  My hope is that we won't need to do that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43478>
_______________________________________

From report at bugs.python.org  Mon Mar 15 13:39:20 2021
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 15 Mar 2021 17:39:20 +0000
Subject: [issue12777] Inconsistent use of VOLUME_NAME_* with
 GetFinalPathNameByHandle
In-Reply-To: <1313677947.11.0.030758892383.issue12777@psf.upfronthosting.co.za>
Message-ID: <1615829960.41.0.929071091771.issue12777@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

bpo-33016 fixed the problem with the inconsistent dwFlags argument passed to GetFinalPathNameByHandleW().

We do need the ability to get the NT name in order to implement samefile() and sameopenfile() reliably in all cases -- i.e. when the volume serial number and/or file ID are 0 because the filesystem doesn't support them. A new issue needs to be opened to extend nt._getfinalpathname() to support passing either a file descriptor or a name and to add a parameter for the flags that defaults to 0.

> VOLUME_NAME_NT was more general purpose

The most broadly supported flags value is `VOLUME_NAME_NT | FILE_NAME_OPENED` -- e.g. "\Device\HarddiskVolume2\Windows\Temp\FILENA~1.TXT". 

For general use, the preferred form is `VOLUME_NAME_DOS | FILE_NAME_NORMALIZED` (dwFlags=0), which is the canonical DOS path with long component names -- e.g. "\\?\C:\Windows\Temp\filename_long.txt". This requires a volume device that supports the mountpoint manager; a registered or auto-assigned DOS drive-letter name; and a filesystem that supports normalizing names in the opened path.

GetFinalPathNameByHandleW() has special handling for the Multiple UNC Provider (MUP) device at the root of UNC paths (i.e. \\server\share -> \\?\UNC\server\share -> \Device\Mup\server\share). For the DOS 'volume' name, it returns the "\\?\UNC" form.

Caveats

Substitute drives and mapped drives are never present in the final DOS path. They resolve to a filesystem directory, not to a volume device, and they're usually defined locally in a logon session. Such drives are not final, globally accessible paths.

A file/directory in a filesystem is required, such as a filesystem mounted on a volume device, the named-pipe filesystem implemented on \Device\NamedPipe, or the mailslot filesystem implemented on \Device\Mailslot. Non-filesystem devices are not supported, such as \\?\CON (i.e. \Device\ConDrv\Console) and \\?\NUL (i.e. \Device\Null).

> That's slightly off-topic, but is it enough to strip the leading
> '\\?\' (and replace 'UNC' with '\')

The \\?\ path prefix, which signifies an extended path (i.e. a verbatim local-device path), should not be removed without testing that it results in an equivalent, accessible path. An extended path may be required in order to access DOS paths that are longer than MAX_PATH. Also, the last path component of the final path may be a reserved DOS device name, or end with trailing dots and/or spaces, which is inaccessible without using an extended path.

----------
nosy: +eryksun
resolution:  -> out of date
stage:  -> resolved
status: open -> closed
superseder:  -> nt._getfinalpathname may use uninitialized memory

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12777>
_______________________________________

From report at bugs.python.org  Mon Mar 15 13:44:54 2021
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 15 Mar 2021 17:44:54 +0000
Subject: [issue43478] Disallow Mock spec arguments from being Mocks
In-Reply-To: <1615514023.14.0.0477922265442.issue43478@roundup.psfhosted.org>
Message-ID: <1615830294.75.0.0893131356468.issue43478@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +cjw296, lisroach, mariocj89, michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43478>
_______________________________________

From report at bugs.python.org  Mon Mar 15 13:49:02 2021
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 15 Mar 2021 17:49:02 +0000
Subject: [issue43478] Disallow Mock spec arguments from being Mocks
In-Reply-To: <1615514023.14.0.0477922265442.issue43478@roundup.psfhosted.org>
Message-ID: <1615830542.18.0.468432256577.issue43478@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

For a simple experiment raising an exception I can see two tests failing in test suite that have the pattern of having an autospec which is a mock object.

diff --git a/Lib/unittest/mock.py b/Lib/unittest/mock.py
index 720f682efb..d33c7899a1 100644
--- a/Lib/unittest/mock.py
+++ b/Lib/unittest/mock.py
@@ -2612,6 +2612,9 @@ def create_autospec(spec, spec_set=False, instance=False, _parent=None,
         # interpreted as a list of strings
         spec = type(spec)
 
+    if _is_instance_mock(spec):
+        1 / 0
+        
     is_type = isinstance(spec, type)
     is_async_func = _is_async_func(spec)
     _kwargs = {'spec': spec}


./python -m unittest Lib.unittest.test.testmock
....................................................................................................................................................E..............................................................................................................................................................E...........................................................................................................................................................................................
======================================================================
ERROR: test_bool_not_called_when_passing_spec_arg (unittest.test.testmock.testmock.MockTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/root/cpython/Lib/unittest/test/testmock/testmock.py", line 2180, in test_bool_not_called_when_passing_spec_arg
    with unittest.mock.patch.object(obj, 'obj_with_bool_func', autospec=True): pass
  File "/root/cpython/Lib/unittest/mock.py", line 1503, in __enter__
    new = create_autospec(autospec, spec_set=spec_set,
  File "/root/cpython/Lib/unittest/mock.py", line 2616, in create_autospec
    1 / 0
ZeroDivisionError: division by zero

======================================================================
ERROR: test_create_autospec_awaitable_class (unittest.test.testmock.testasync.AsyncAutospecTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/root/cpython/Lib/unittest/test/testmock/testasync.py", line 204, in test_create_autospec_awaitable_class
    self.assertIsInstance(create_autospec(awaitable_mock), AsyncMock)
  File "/root/cpython/Lib/unittest/mock.py", line 2616, in create_autospec
    1 / 0
ZeroDivisionError: division by zero

----------------------------------------------------------------------
Ran 495 tests in 2.039s

FAILED (errors=2)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43478>
_______________________________________

From report at bugs.python.org  Mon Mar 15 14:29:53 2021
From: report at bugs.python.org (Florian Bruhin)
Date: Mon, 15 Mar 2021 18:29:53 +0000
Subject: [issue43463] typing.get_type_hints with TYPE_CHECKING imports /
 getting hints for single argument
In-Reply-To: <1615387121.09.0.336024174905.issue43463@roundup.psfhosted.org>
Message-ID: <1615832993.8.0.0417125720427.issue43463@roundup.psfhosted.org>


Florian Bruhin <python.org at the-compiler.org> added the comment:

Ah, I wasn't aware of that, thanks for the pointer! So what inspect does internally is:

    def _get_type_hints(func, **kwargs):
        try:
            return typing.get_type_hints(func, **kwargs)
        except Exception:
            # First, try to use the get_type_hints to resolve
            # annotations. But for keeping the behavior intact
            # if there was a problem with that (like the namespace
            # can't resolve some annotation) continue to use
            # string annotations
            return func.__annotations__

Which means there's even some "prior art" there already falling back to a string when the annotation couldn't be resolved. Doing so in typing.get_type_hints on a per-argument basis would thus also make inspect more consistent:

Right now,

    print(repr(inspect.signature(fun).parameters['b'].annotation))

in my example returns a string, but when changing the annotation for `a`, the returned annotation for `b` is now magically a `typing.Union` object.

(I personally would indeed expect inspect to resolve those annotations, but yeah, let's keep that in issue43355.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43463>
_______________________________________

From report at bugs.python.org  Mon Mar 15 14:32:00 2021
From: report at bugs.python.org (Florian Bruhin)
Date: Mon, 15 Mar 2021 18:32:00 +0000
Subject: [issue43355] __future__.annotations breaks inspect.signature()
In-Reply-To: <1614614520.28.0.353733927276.issue43355@roundup.psfhosted.org>
Message-ID: <1615833120.24.0.166958697169.issue43355@roundup.psfhosted.org>


Change by Florian Bruhin <python.org at the-compiler.org>:


----------
nosy: +The Compiler

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43355>
_______________________________________

From report at bugs.python.org  Mon Mar 15 14:39:38 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 15 Mar 2021 18:39:38 +0000
Subject: [issue43285] ftplib should not use the host from the PASV response
In-Reply-To: <1613908174.7.0.0578051462677.issue43285@roundup.psfhosted.org>
Message-ID: <1615833578.41.0.71786160242.issue43285@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:


New changeset 0ab152c6b5d95caa2dc1a30fa96e10258b5f188e by Gregory P. Smith in branch 'master':
bpo-43285 Make ftplib not trust the PASV response. (GH-24838)
https://github.com/python/cpython/commit/0ab152c6b5d95caa2dc1a30fa96e10258b5f188e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43285>
_______________________________________

From report at bugs.python.org  Mon Mar 15 14:39:41 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 15 Mar 2021 18:39:41 +0000
Subject: [issue43285] ftplib should not use the host from the PASV response
In-Reply-To: <1613908174.7.0.0578051462677.issue43285@roundup.psfhosted.org>
Message-ID: <1615833581.86.0.15061522627.issue43285@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: +23638
pull_request: https://github.com/python/cpython/pull/24880

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43285>
_______________________________________

From report at bugs.python.org  Mon Mar 15 14:47:49 2021
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 15 Mar 2021 18:47:49 +0000
Subject: [issue43371] Mock.assert_has_calls works strange
In-Reply-To: <1614695494.31.0.773020245058.issue43371@roundup.psfhosted.org>
Message-ID: <1615834069.96.0.927602443204.issue43371@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

https://docs.python.org/3/library/unittest.mock.html#unittest.mock.Mock.assert_has_calls

> If any_order is false then the calls must be sequential. There can be extra calls before or after the specified calls.

One way to check that the calls appear in order even with extra calls in between since any_order=False expects the calls to be sequential is to use mock_calls which is a list and use index method. It's not very elegant.

>>> from unittest.mock import Mock, call
>>> m = Mock()
>>> m(1)
<Mock name='mock()' id='139845749964176'>
>>> m(2)
<Mock name='mock()' id='139845749964176'>
>>> m(3)
<Mock name='mock()' id='139845749964176'> 
>>> m.mock_calls.index(call(1))
0
>>> m.mock_calls.index(call(3))
2

> - Mock.assert_has_only_calls that always raise an error when mock has calls other than expected(not regarding any_order).

This sounds like a stricter version of assert_has_calls to ensure expected is matched without order with mock_calls and len(expected) == len(mock_calls)

I am not keen on changing behavior of assert_has_calls with any additional flags for compatibility but any additional helper should go in python 3.10 only. So I have updated the version.

----------
components: +Library (Lib) -Tests
nosy: +cjw296, lisroach, mariocj89, michael.foord
versions: +Python 3.10 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43371>
_______________________________________

From report at bugs.python.org  Mon Mar 15 14:49:54 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 15 Mar 2021 18:49:54 +0000
Subject: [issue43285] ftplib should not use the host from the PASV response
In-Reply-To: <1613908174.7.0.0578051462677.issue43285@roundup.psfhosted.org>
Message-ID: <1615834194.07.0.783677632068.issue43285@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
pull_requests: +23639
pull_request: https://github.com/python/cpython/pull/24881

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43285>
_______________________________________

From report at bugs.python.org  Mon Mar 15 14:52:27 2021
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 15 Mar 2021 18:52:27 +0000
Subject: [issue43498] "dictionary changed size during iteration" error in
 _ExecutorManagerThread
In-Reply-To: <1615796616.26.0.51182574064.issue43498@roundup.psfhosted.org>
Message-ID: <1615834347.63.0.0747361717955.issue43498@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +bquinlan, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43498>
_______________________________________

From report at bugs.python.org  Mon Mar 15 14:53:43 2021
From: report at bugs.python.org (Eric Snow)
Date: Mon, 15 Mar 2021 18:53:43 +0000
Subject: [issue43503] [subinterpreters] PyObject statics exposed in the
 limited API break isolation.
Message-ID: <1615834423.72.0.113211272847.issue43503@roundup.psfhosted.org>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

In the limited C-API we expose the following static PyObject variables:

* 5 singletons
* ~70 exception types
* ~70 other types

Since they are part of the limited API, they have a direct effect on the stable ABI.

The problem is that these objects should not be shared between interpreters.  There are a number of possible solutions for isolating the objects, but the big constraint is that the solution cannot break the stable ABI.

----------
components: C API
messages: 388759
nosy: eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: [subinterpreters] PyObject statics exposed in the limited API break isolation.
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43503>
_______________________________________

From report at bugs.python.org  Mon Mar 15 14:55:32 2021
From: report at bugs.python.org (Eric Snow)
Date: Mon, 15 Mar 2021 18:55:32 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1615834532.79.0.381383234518.issue40255@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

While the eventual solution may overlap, my interests are divergent enough from those here that I've created a separate issue: bpo-43503.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Mon Mar 15 14:57:58 2021
From: report at bugs.python.org (Socob)
Date: Mon, 15 Mar 2021 18:57:58 +0000
Subject: [issue11339] annotation for class being defined
In-Reply-To: <1298751820.01.0.369994267539.issue11339@psf.upfronthosting.co.za>
Message-ID: <1615834678.07.0.951561882907.issue11339@roundup.psfhosted.org>


Change by Socob <206a8535 at opayq.com>:


----------
nosy: +Socob

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11339>
_______________________________________

From report at bugs.python.org  Mon Mar 15 15:02:53 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 15 Mar 2021 19:02:53 +0000
Subject: [issue43285] ftplib should not use the host from the PASV response
In-Reply-To: <1613908174.7.0.0578051462677.issue43285@roundup.psfhosted.org>
Message-ID: <1615834973.43.0.513128399606.issue43285@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 7dcb4baa4f0fde3aef5122a8e9f6a41853ec9335 by Miss Islington (bot) in branch '3.9':
bpo-43285 Make ftplib not trust the PASV response. (GH-24838)
https://github.com/python/cpython/commit/7dcb4baa4f0fde3aef5122a8e9f6a41853ec9335


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43285>
_______________________________________

From report at bugs.python.org  Mon Mar 15 15:04:56 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 15 Mar 2021 19:04:56 +0000
Subject: [issue43285] ftplib should not use the host from the PASV response
In-Reply-To: <1613908174.7.0.0578051462677.issue43285@roundup.psfhosted.org>
Message-ID: <1615835096.15.0.199654123463.issue43285@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:


New changeset 664d1d16274b47eea6ec92572e1ebf3939a6fa0c by Gregory P. Smith in branch '3.8':
[3.8] bpo-43285 Make ftplib not trust the PASV response. (GH-24838) (GH-24881)
https://github.com/python/cpython/commit/664d1d16274b47eea6ec92572e1ebf3939a6fa0c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43285>
_______________________________________

From report at bugs.python.org  Mon Mar 15 15:05:03 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 15 Mar 2021 19:05:03 +0000
Subject: [issue43285] ftplib should not use the host from the PASV response
In-Reply-To: <1613908174.7.0.0578051462677.issue43285@roundup.psfhosted.org>
Message-ID: <1615835103.44.0.738211610519.issue43285@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +23640
pull_request: https://github.com/python/cpython/pull/24882

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43285>
_______________________________________

From report at bugs.python.org  Mon Mar 15 15:05:35 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 15 Mar 2021 19:05:35 +0000
Subject: [issue43285] ftplib should not use the host from the PASV response
In-Reply-To: <1613908174.7.0.0578051462677.issue43285@roundup.psfhosted.org>
Message-ID: <1615835135.72.0.26201513347.issue43285@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +23641
pull_request: https://github.com/python/cpython/pull/24883

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43285>
_______________________________________

From report at bugs.python.org  Mon Mar 15 15:08:47 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 15 Mar 2021 19:08:47 +0000
Subject: [issue43285] ftplib should not use the host from the PASV response
In-Reply-To: <1613908174.7.0.0578051462677.issue43285@roundup.psfhosted.org>
Message-ID: <1615835327.1.0.30370456221.issue43285@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

3.7 and 3.6 backport PRs created and assigned to release manager Ned for merging.

----------
nosy: +ned.deily
resolution:  -> fixed
stage: patch review -> commit review
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43285>
_______________________________________

From report at bugs.python.org  Mon Mar 15 15:24:57 2021
From: report at bugs.python.org (Eric Snow)
Date: Mon, 15 Mar 2021 19:24:57 +0000
Subject: [issue43503] [subinterpreters] PyObject statics exposed in the
 limited API break isolation.
In-Reply-To: <1615834423.72.0.113211272847.issue43503@roundup.psfhosted.org>
Message-ID: <1615836297.66.0.651699436604.issue43503@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Here are some solutions that I've considered:

1. immutable objects
   a. make the objects truly immutable/const
      * not trivial, if possible
   b. make the objects effectively immutable
      * (see GH-24828) use a really high refcount to make races irrelevant
2. per-interpreter objects
   a. replace them with macros that do a per-interpreter lookup
   b. replace them with simple placeholders and do a per-interpreter lookup internally
   c. replace them with PyObject placeholders and do a per-interpreter lookup internally

As far as I'm aware, only (1b) and (2c) are realistic and won't break the stable ABI (i.e. preserve layout).

(FWIW, I think that even with (1b) we would still have per-interpreter objects.)

-- Regarding (1a) --

See see GH-24828 for an example implementation.  This includes storing some state for the objects in PyInterpreterState and doing a lookup internally.

pros:
* relatively straightforward to implement
* overlaps with other interests (see bpo-40255)
* makes the objects shareable between interpreters (making them more efficient)

cons:
* we have to ensure the objects stay immutable (a tractable problem if the solution is constrained to only the limited API objects)

-- Regarding (2c) --

This involves adding an API to get the per-interpreter object for a given identity value (flag, global, etc.) and then mapping the limited API objects to the corresponding per-interpreter ones.

pros:
* avoids a one-off solution
* extensions can stop using the variables directly (in favor of the new lookup API)

cons:
* effectively couples the C-API to the design (as long as the objects are in the limited API)
* many touches all over the C-API
* any future changes/additions in the C-API must deal with the objects

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43503>
_______________________________________

From report at bugs.python.org  Mon Mar 15 15:28:35 2021
From: report at bugs.python.org (Eric Snow)
Date: Mon, 15 Mar 2021 19:28:35 +0000
Subject: [issue43503] [subinterpreters] PyObject statics exposed in the
 limited API break isolation.
In-Reply-To: <1615834423.72.0.113211272847.issue43503@roundup.psfhosted.org>
Message-ID: <1615836515.08.0.743303243286.issue43503@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

If the stable ABI weren't an issue then we would probably:

* deprecate using the objects directly
* do something like (2a) in the meantime

It may make sense to do that for "#ifndef Py_LIMITED_API", regardless of how we handle the limited API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43503>
_______________________________________

From report at bugs.python.org  Mon Mar 15 15:29:56 2021
From: report at bugs.python.org (Chris Withers)
Date: Mon, 15 Mar 2021 19:29:56 +0000
Subject: [issue43478] Disallow Mock spec arguments from being Mocks
In-Reply-To: <1615514023.14.0.0477922265442.issue43478@roundup.psfhosted.org>
Message-ID: <1615836596.35.0.520367909166.issue43478@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:

I agree that this should raise an exception.
Can the two failing tests in mock's own suite be easily fixed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43478>
_______________________________________

From report at bugs.python.org  Mon Mar 15 15:31:14 2021
From: report at bugs.python.org (Eric Snow)
Date: Mon, 15 Mar 2021 19:31:14 +0000
Subject: [issue43503] [subinterpreters] PyObject statics exposed in the
 limited API break isolation.
In-Reply-To: <1615834423.72.0.113211272847.issue43503@roundup.psfhosted.org>
Message-ID: <1615836674.35.0.0481644038124.issue43503@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +Mark.Shannon, nascheme, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43503>
_______________________________________

From report at bugs.python.org  Mon Mar 15 15:31:52 2021
From: report at bugs.python.org (Eric Snow)
Date: Mon, 15 Mar 2021 19:31:52 +0000
Subject: [issue43503] [subinterpreters] PyObject statics exposed in the
 limited API break isolation.
In-Reply-To: <1615834423.72.0.113211272847.issue43503@roundup.psfhosted.org>
Message-ID: <1615836712.45.0.330151791709.issue43503@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
keywords: +patch
pull_requests: +23642
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/24828

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43503>
_______________________________________

From report at bugs.python.org  Mon Mar 15 15:34:18 2021
From: report at bugs.python.org (Eric Snow)
Date: Mon, 15 Mar 2021 19:34:18 +0000
Subject: [issue43503] [subinterpreters] PyObject statics exposed in the
 limited API break isolation.
In-Reply-To: <1615834423.72.0.113211272847.issue43503@roundup.psfhosted.org>
Message-ID: <1615836858.1.0.973557493593.issue43503@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
components: +Extension Modules, Interpreter Core, Subinterpreters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43503>
_______________________________________

From report at bugs.python.org  Mon Mar 15 15:34:36 2021
From: report at bugs.python.org (Matthew Suozzo)
Date: Mon, 15 Mar 2021 19:34:36 +0000
Subject: [issue43478] Disallow Mock spec arguments from being Mocks
In-Reply-To: <1615514023.14.0.0477922265442.issue43478@roundup.psfhosted.org>
Message-ID: <1615836876.36.0.999271513167.issue43478@roundup.psfhosted.org>


Matthew Suozzo <msuozzo at google.com> added the comment:

I've fixed a bunch of these in our internal repo so I'd be happy to add that to a patch implementing raising exceptions for these cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43478>
_______________________________________

From report at bugs.python.org  Mon Mar 15 15:38:04 2021
From: report at bugs.python.org (Ned Deily)
Date: Mon, 15 Mar 2021 19:38:04 +0000
Subject: [issue43285] ftplib should not use the host from the PASV response
In-Reply-To: <1613908174.7.0.0578051462677.issue43285@roundup.psfhosted.org>
Message-ID: <1615837084.01.0.402788057684.issue43285@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

@gps, What about ftplib doc changes and What's new entries for this change in behavior?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43285>
_______________________________________

From report at bugs.python.org  Mon Mar 15 15:38:57 2021
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 15 Mar 2021 19:38:57 +0000
Subject: [issue43478] Disallow Mock spec arguments from being Mocks
In-Reply-To: <1615514023.14.0.0477922265442.issue43478@roundup.psfhosted.org>
Message-ID: <1615837137.08.0.854285989283.issue43478@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

The tests can be fixed. The change to raise exception can be merged to gather feedback during alpha/beta and see if there are any valid usecases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43478>
_______________________________________

From report at bugs.python.org  Mon Mar 15 15:46:43 2021
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 15 Mar 2021 19:46:43 +0000
Subject: [issue11339] annotation for class being defined
In-Reply-To: <1298751820.01.0.369994267539.issue11339@psf.upfronthosting.co.za>
Message-ID: <1615837603.69.0.57205893338.issue11339@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Is this issue resolved with PEP 563 and the behavior becoming default in Python 3.10? https://www.python.org/dev/peps/pep-0563/#forward-references

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11339>
_______________________________________

From report at bugs.python.org  Mon Mar 15 15:52:58 2021
From: report at bugs.python.org (doublex)
Date: Mon, 15 Mar 2021 19:52:58 +0000
Subject: [issue41567] multiprocessing.Pool from concurrent threads failure on
 3.9.0rc1
In-Reply-To: <1597664250.53.0.724586569237.issue41567@roundup.psfhosted.org>
Message-ID: <1615837978.77.0.403121171558.issue41567@roundup.psfhosted.org>


doublex <doppelbauer at gmx.net> added the comment:

Example code (fails):


import os, concurrent.futures

def parallel_callback( arg ):
    return os.getpid()

def parallel( *args ):
    def thread_callback( param ):
        with concurrent.futures.ProcessPoolExecutor(max_workers=1) as executor:
            future = executor.submit( parallel_callback, param )
            pid = future.result()
            print( 'pid:', pid )
            return pid
    with concurrent.futures.ThreadPoolExecutor(max_workers=len(args)) as executor:
        future = executor.map( thread_callback, args )
        results = list(future)
    print( 'DONE' )

parallel( 1, 2, 3 )

----------
nosy: +doublex

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41567>
_______________________________________

From report at bugs.python.org  Mon Mar 15 15:53:14 2021
From: report at bugs.python.org (Brandt Bucher)
Date: Mon, 15 Mar 2021 19:53:14 +0000
Subject: [issue42128] Structural Pattern Matching (PEP 634)
In-Reply-To: <1603466540.96.0.7677855399.issue42128@roundup.psfhosted.org>
Message-ID: <1615837994.87.0.142011828793.issue42128@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

@BTaskaya, do you have any interest in helping me iterate on new AST nodes?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42128>
_______________________________________

From report at bugs.python.org  Mon Mar 15 15:54:31 2021
From: report at bugs.python.org (Kamil Turek)
Date: Mon, 15 Mar 2021 19:54:31 +0000
Subject: [issue11339] annotation for class being defined
In-Reply-To: <1298751820.01.0.369994267539.issue11339@psf.upfronthosting.co.za>
Message-ID: <1615838071.26.0.948676839606.issue11339@roundup.psfhosted.org>


Change by Kamil Turek <kamil.turek at hotmail.com>:


----------
nosy: +kamilturek

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11339>
_______________________________________

From report at bugs.python.org  Mon Mar 15 15:56:57 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 15 Mar 2021 19:56:57 +0000
Subject: [issue43503] [subinterpreters] PyObject statics exposed in the
 limited API break isolation.
In-Reply-To: <1615834423.72.0.113211272847.issue43503@roundup.psfhosted.org>
Message-ID: <1615838217.58.0.893834166596.issue43503@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

I can never remember what "Py_LIMITED_API" stands for. If it's not defined, does that mean we have the *unlimited* API? Is that a superset or a subset of the limited API?

Regarding 1a *and* 1b, I think it would help to list the specific reasons exceptions and other types are not entirely immutable. Is it just __subclasses__ or is there other state (apart from the refcount) that's mutable and visible to the end user? (Or even if it's visible to C API users.)

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43503>
_______________________________________

From report at bugs.python.org  Mon Mar 15 16:01:50 2021
From: report at bugs.python.org (Steve Dower)
Date: Mon, 15 Mar 2021 20:01:50 +0000
Subject: [issue43486] Python 3.9 installer not updating ARP table
In-Reply-To: <1615641610.33.0.0630077237897.issue43486@roundup.psfhosted.org>
Message-ID: <1615838510.31.0.747386590038.issue43486@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Leaving the launcher behind is deliberate. Otherwise you might install/uninstall 3.10 alpha and lose the launcher completely.

I can't trivially reproduce the ARP issue, so we'll need some more information.

If possible, can you grab the install logs from %TEMP% and attach them here in a zip file?

Also, any information about any restrictive administrator policies or anti-virus tools running on your machine might be relevant.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43486>
_______________________________________

From report at bugs.python.org  Mon Mar 15 16:05:56 2021
From: report at bugs.python.org (Kamil Turek)
Date: Mon, 15 Mar 2021 20:05:56 +0000
Subject: [issue43500] Add filtercase() into fnmatch
In-Reply-To: <1615811448.09.0.46189738482.issue43500@roundup.psfhosted.org>
Message-ID: <1615838756.02.0.904799592538.issue43500@roundup.psfhosted.org>


Change by Kamil Turek <kamil.turek at hotmail.com>:


----------
nosy: +kamilturek

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43500>
_______________________________________

From report at bugs.python.org  Mon Mar 15 16:13:00 2021
From: report at bugs.python.org (Batuhan Taskaya)
Date: Mon, 15 Mar 2021 20:13:00 +0000
Subject: [issue42128] Structural Pattern Matching (PEP 634)
In-Reply-To: <1603466540.96.0.7677855399.issue42128@roundup.psfhosted.org>
Message-ID: <1615839180.53.0.284649185703.issue42128@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:

> @BTaskaya, do you have any interest in helping me iterate on new AST nodes?

Sure!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42128>
_______________________________________

From report at bugs.python.org  Mon Mar 15 17:01:39 2021
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 15 Mar 2021 21:01:39 +0000
Subject: [issue17620] Python interactive console doesn't use sys.stdin for
 input
In-Reply-To: <1364921954.86.0.527255608282.issue17620@psf.upfronthosting.co.za>
Message-ID: <1615842099.38.0.238226604697.issue17620@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17620>
_______________________________________

From report at bugs.python.org  Mon Mar 15 17:02:22 2021
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 15 Mar 2021 21:02:22 +0000
Subject: [issue24829] Use interactive input even if stdout is redirected
In-Reply-To: <1439045336.84.0.292650421837.issue24829@psf.upfronthosting.co.za>
Message-ID: <1615842142.45.0.34599585558.issue24829@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
dependencies: +Python interactive console doesn't use sys.stdin for input
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24829>
_______________________________________

From report at bugs.python.org  Mon Mar 15 17:02:44 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 15 Mar 2021 21:02:44 +0000
Subject: [issue43416] Add README files in Include/cpython and Include/internal
In-Reply-To: <1615020265.58.0.71326223935.issue43416@roundup.psfhosted.org>
Message-ID: <1615842164.89.0.561577855964.issue43416@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


----------
keywords: +patch
nosy: +erlendaasland
nosy_count: 3.0 -> 4.0
pull_requests: +23643
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24884

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43416>
_______________________________________

From report at bugs.python.org  Mon Mar 15 17:02:50 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 15 Mar 2021 21:02:50 +0000
Subject: [issue35134] Add a new Include/cpython/ subdirectory for the "CPython
 API" with implementation details
In-Reply-To: <1541076409.33.0.788709270274.issue35134@psf.upfronthosting.co.za>
Message-ID: <1615842170.91.0.751959216302.issue35134@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


----------
nosy: +erlendaasland
nosy_count: 7.0 -> 8.0
pull_requests: +23644
pull_request: https://github.com/python/cpython/pull/24884

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35134>
_______________________________________

From report at bugs.python.org  Mon Mar 15 17:26:30 2021
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 15 Mar 2021 21:26:30 +0000
Subject: [issue29805] Support moving across filesystems in pathlib.Path,
 as shutil.move() does
In-Reply-To: <1489439024.83.0.354569832809.issue29805@psf.upfronthosting.co.za>
Message-ID: <1615843590.93.0.804212780085.issue29805@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
components:  -Windows
title: Pathlib.replace cannot move file to a different drive on Windows if filename different -> Support moving across filesystems in pathlib.Path, as shutil.move() does
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29805>
_______________________________________

From report at bugs.python.org  Mon Mar 15 17:37:04 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 15 Mar 2021 21:37:04 +0000
Subject: [issue43492] Upgrade to SQLite 3.35.1 in macOS and Windows
In-Reply-To: <1615752732.27.0.278073347477.issue43492@roundup.psfhosted.org>
Message-ID: <1615844224.73.0.747284036456.issue43492@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

Bug-fix release 3.35.1 is out bco. https://sqlite.org/src/info/1c24a659e6d7f3a1

----------
title: Upgrade to SQLite 3.35.0 in macOS and Windows -> Upgrade to SQLite 3.35.1 in macOS and Windows

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43492>
_______________________________________

From report at bugs.python.org  Mon Mar 15 17:56:22 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 15 Mar 2021 21:56:22 +0000
Subject: [issue43285] ftplib should not use the host from the PASV response
In-Reply-To: <1613908174.7.0.0578051462677.issue43285@roundup.psfhosted.org>
Message-ID: <1615845382.39.0.0320891050085.issue43285@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

A What's New entry is a good idea.  I'll make one and add it to those backport PRs.  (reopened to remind me of that)

ftplib docs... I don't actually want to document the attribute that people can set for the old behavior beyond the notes in NEWS or What's New.  It is something I anticipate nobody in the world ever actually setting so I'd rather not imply that anyone even should by giving it more prominent doc space.

Other things that have fixed this repeated bug in their program that supports ftp over the years have not added an opt-out as far as I could tell in my quick searching.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43285>
_______________________________________

From report at bugs.python.org  Mon Mar 15 18:14:22 2021
From: report at bugs.python.org (Steve Dower)
Date: Mon, 15 Mar 2021 22:14:22 +0000
Subject: [issue29586] Cannot run pip in fresh install of py 3.5.3
In-Reply-To: <1487328483.09.0.366256272135.issue29586@psf.upfronthosting.co.za>
Message-ID: <1615846462.91.0.986378561835.issue29586@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

This was caused by the UCRT not installing properly. These days, the UCRT is installed app-local for Win 8.1, and is already present on Win 10, so it can't happen anymore.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29586>
_______________________________________

From report at bugs.python.org  Mon Mar 15 18:16:48 2021
From: report at bugs.python.org (Steve Dower)
Date: Mon, 15 Mar 2021 22:16:48 +0000
Subject: [issue25117] Windows installer: precompiling stdlib fails with
 missing DLL errors
In-Reply-To: <1442294819.71.0.839651529049.issue25117@psf.upfronthosting.co.za>
Message-ID: <1615846608.33.0.312723148614.issue25117@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

The UCRT can no longer fail to install - we do an app-local install on Win 8.1, and it's already present on Win 10.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25117>
_______________________________________

From report at bugs.python.org  Mon Mar 15 18:23:30 2021
From: report at bugs.python.org (Steve Dower)
Date: Mon, 15 Mar 2021 22:23:30 +0000
Subject: [issue43425] test_peg_generator.test_c_parser emits
 DeprecationWarning due to distutils
In-Reply-To: <1615093629.58.0.305422387924.issue43425@roundup.psfhosted.org>
Message-ID: <1615847010.12.0.478028766306.issue43425@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

The link appears to be in the Resolution header of PEP 632?

But yes, your analysis is correct. If/when we move distutils elsewhere, we'll probably have to update all of these sections.

Ideally we'd have a helper function to do the initial "import distutils",  handle failure (because it's not in Tools), and suppress the warning. But I don't know that there's anywhere we could put it reliably anyway, so probably just need to suppress the warnings directly and we'll handle failures if/when we move it into Tools.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43425>
_______________________________________

From report at bugs.python.org  Mon Mar 15 18:26:17 2021
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 15 Mar 2021 22:26:17 +0000
Subject: [issue27346] Implement os.readv() / os.writev() in Windows port
In-Reply-To: <1466242793.09.0.103237179238.issue27346@psf.upfronthosting.co.za>
Message-ID: <1615847177.21.0.0950680863366.issue27346@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

The need for asynchronous I/O (i.e. FILE_FLAG_OVERLAPPED) with ReadFileScatter() and WriteFileGather() makes them a poor fit for POSIX os.readv() and os.writev(), since we can't open the file with open() or os.open(). Python's socket module opens sockets in asynchronous mode, but ReadFileScatter() and WriteFileGather() don't support sockets, and there are socket-specific alternatives (e.g. WSASend with multiple buffers). If these Windows API functions are supported at all, I expect it will be in _winapi or _overlapped, and only if needed by the standard library.

I'm changing the status of this enhancement request to pending, awaiting feedback from ???? and the core developers.

----------
status: open -> pending
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27346>
_______________________________________

From report at bugs.python.org  Mon Mar 15 18:41:35 2021
From: report at bugs.python.org (Eric Snow)
Date: Mon, 15 Mar 2021 22:41:35 +0000
Subject: [issue39511] [subinterpreters] Per-interpreter singletons (None, True,
 False, etc.)
In-Reply-To: <1580484815.27.0.407070570821.issue39511@roundup.psfhosted.org>
Message-ID: <1615848095.54.0.418951171789.issue39511@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow
nosy_count: 2.0 -> 3.0
pull_requests: +23645
pull_request: https://github.com/python/cpython/pull/24828

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39511>
_______________________________________

From report at bugs.python.org  Mon Mar 15 18:43:31 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Mar 2021 22:43:31 +0000
Subject: [issue43503] [subinterpreters] PyObject statics exposed in the
 limited API break isolation.
In-Reply-To: <1615834423.72.0.113211272847.issue43503@roundup.psfhosted.org>
Message-ID: <1615848211.27.0.405354605267.issue43503@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> * 5 singletons

This issue is discussed in bpo-39511 "[subinterpreters] Per-interpreter singletons (None, True, False, etc.)".

> Since they are part of the limited API, they have a direct effect on the stable ABI.

This issue is discussed in bpo-40601: "[C API] Hide static types from the limited C API".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43503>
_______________________________________

From report at bugs.python.org  Mon Mar 15 18:44:27 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Mar 2021 22:44:27 +0000
Subject: [issue43503] [subinterpreters] PyObject statics exposed in the
 limited API break isolation.
In-Reply-To: <1615834423.72.0.113211272847.issue43503@roundup.psfhosted.org>
Message-ID: <1615848267.55.0.193037635759.issue43503@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> I can never remember what "Py_LIMITED_API" stands for.

Include/README file is being written, have a look ;-)
https://github.com/python/cpython/pull/24884/files

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43503>
_______________________________________

From report at bugs.python.org  Mon Mar 15 18:46:49 2021
From: report at bugs.python.org (Brandt Bucher)
Date: Mon, 15 Mar 2021 22:46:49 +0000
Subject: [issue42128] Structural Pattern Matching (PEP 634)
In-Reply-To: <1603466540.96.0.7677855399.issue42128@roundup.psfhosted.org>
Message-ID: <1615848409.08.0.623429020692.issue42128@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

Cool. Today or tomorrow I'll create an issue in Guido's patma repo and we can move our discussion there. I'll also create a branch and add you to my fork.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42128>
_______________________________________

From report at bugs.python.org  Mon Mar 15 18:50:18 2021
From: report at bugs.python.org (Brandt Bucher)
Date: Mon, 15 Mar 2021 22:50:18 +0000
Subject: [issue42128] Structural Pattern Matching (PEP 634)
In-Reply-To: <1603466540.96.0.7677855399.issue42128@roundup.psfhosted.org>
Message-ID: <1615848618.4.0.871418126148.issue42128@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

Also, given that pattern matching is now shipped and documented, perhaps this issue should be closed? At this point I think dedicated issues are probably better for any new bugs/enhancements/etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42128>
_______________________________________

From report at bugs.python.org  Mon Mar 15 18:50:56 2021
From: report at bugs.python.org (Julien Palard)
Date: Mon, 15 Mar 2021 22:50:56 +0000
Subject: [issue41933] Wording of s * n in Common Sequence Operations is not
 optimal
In-Reply-To: <1601828421.16.0.497838866676.issue41933@roundup.psfhosted.org>
Message-ID: <1615848656.92.0.680413951608.issue41933@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:


New changeset 0269ce87c9347542c54a653dd78b9f60bb9fa822 by Chavdar Yotov in branch 'master':
bpo-41933: Clarify wording for s * n in Common Sequence Operations (GH-22570)
https://github.com/python/cpython/commit/0269ce87c9347542c54a653dd78b9f60bb9fa822


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41933>
_______________________________________

From report at bugs.python.org  Mon Mar 15 18:51:22 2021
From: report at bugs.python.org (Julien Palard)
Date: Mon, 15 Mar 2021 22:51:22 +0000
Subject: [issue41933] Wording of s * n in Common Sequence Operations is not
 optimal
In-Reply-To: <1601828421.16.0.497838866676.issue41933@roundup.psfhosted.org>
Message-ID: <1615848682.07.0.608946013454.issue41933@roundup.psfhosted.org>


Change by Julien Palard <julien+python at palard.fr>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41933>
_______________________________________

From report at bugs.python.org  Mon Mar 15 19:06:20 2021
From: report at bugs.python.org (Julien Palard)
Date: Mon, 15 Mar 2021 23:06:20 +0000
Subject: [issue43504] effbot.org down
Message-ID: <1615849580.97.0.243341860557.issue43504@roundup.psfhosted.org>


New submission from Julien Palard <julien+python at palard.fr>:

effbot.org is down, it's currently displaying:

> effbot.org on hiatus
>
> effbot.org is taking a break. We?ll be back, in some form or another.

But docs.python.org have a few links pointing to it, `git grep effbot` finds 11 of them in the Doc/.

I think they should be manually reviewed one by one, checking on web archive [1] if they still contain relevant information.

For example:

    Doc/library/xml.etree.elementtree.rst:See http://effbot.org/zone/element-index.htm for tutorials and links to other

The given links give Python 2 examples, so I think it's OK just to remove it.

[1]: https://web.archive.org/web/20200315142708/http://effbot.org/

----------
messages: 388787
nosy: mdk
priority: normal
severity: normal
status: open
title: effbot.org down

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43504>
_______________________________________

From report at bugs.python.org  Mon Mar 15 19:09:44 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 15 Mar 2021 23:09:44 +0000
Subject: [issue43505] [sqlite3] Explicitly initialise and shut down sqlite3
Message-ID: <1615849784.81.0.125050267571.issue43505@roundup.psfhosted.org>


New submission from Erlend Egeberg Aasland <erlend.aasland at innova.no>:

We should explicitly initialise (and shut down) the SQLite library in the sqlite3 module. This may be required in future releases:

Quoting from the SQLite docs:
"For maximum portability, it is recommended that applications always invoke sqlite3_initialize() directly prior to using any other SQLite interface. Future releases of SQLite may require this. In other words, the behavior exhibited when SQLite is compiled with SQLITE_OMIT_AUTOINIT might become the default behavior in some future release of SQLite."

Ref.
- https://sqlite.org/c3ref/initialize.html
- https://sqlite.org/compile.html#omit_autoinit

----------
components: Library (Lib)
messages: 388788
nosy: berker.peksag, erlendaasland, serhiy.storchaka
priority: normal
severity: normal
status: open
title: [sqlite3] Explicitly initialise and shut down sqlite3
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43505>
_______________________________________

From report at bugs.python.org  Mon Mar 15 19:24:08 2021
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 15 Mar 2021 23:24:08 +0000
Subject: [issue43477] from x import * behavior inconsistent between module
 types.
In-Reply-To: <1615509638.08.0.549124406797.issue43477@roundup.psfhosted.org>
Message-ID: <1615850648.77.0.907856577739.issue43477@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Sorry, I'm having a hard time following what you've written and I unfortunately don't have time to examine your (I assume) .tar.xz file. When you say "directory-based-module", do you mean a package (e.g. `__init__.py` in a directory)? It's important to be clear because not all imports come from a file system, and so a package versus a module has important distinctions.

Could you write out what you're seeing and what you're expecting? E.g.
```
# pkg/__init__.py
from pkg.submodule import *  # Expecting `submodule_attr`, getting ...
```

```
# pkg/submodule.py
submodule_attr = 0
```

I will also say you really shouldn't be using `import *`. It primarily exists to make it easier to work in the REPL, and otherwise is rather archaic and has very odd import semantics.

As for how Python 2 did things, that (luckly) doesn't matter anymore. :) To show that this is a change in semantics you would need to check Python 3 versions to see where it shifted. If this changed in 3.9 then turning it back may work. But if it's more like 3.4 then I'm afraid these are now the semantics and the risk of code breakage is possibly too high.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43477>
_______________________________________

From report at bugs.python.org  Mon Mar 15 19:28:53 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 15 Mar 2021 23:28:53 +0000
Subject: [issue42128] Structural Pattern Matching (PEP 634)
In-Reply-To: <1603466540.96.0.7677855399.issue42128@roundup.psfhosted.org>
Message-ID: <1615850933.32.0.939869208464.issue42128@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Yeah, feel free to close this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42128>
_______________________________________

From report at bugs.python.org  Mon Mar 15 20:05:55 2021
From: report at bugs.python.org (Anthony Sottile)
Date: Tue, 16 Mar 2021 00:05:55 +0000
Subject: [issue8978] "tarfile.ReadError: file could not be opened
 successfully" if compiled without zlib
In-Reply-To: <1276292933.37.0.137444086026.issue8978@psf.upfronthosting.co.za>
Message-ID: <1615853155.44.0.9594825444.issue8978@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

I took a stab at improving the error message (see the linked PR)

$ ./python -c 'import tarfile; tarfile.open("Lib/test/testtar.tar.xz")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/asottile/workspace/cpython/Lib/tarfile.py", line 1620, in open
    raise ReadError(f"file could not be opened successfully:\n{error_msgs}")
tarfile.ReadError: file could not be opened successfully:
- method gz: ReadError('not a gzip file')
- method bz2: CompressionError('bz2 module is not available')
- method xz: CompressionError('lzma module is not available')
- method tar: ReadError('truncated header')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8978>
_______________________________________

From report at bugs.python.org  Mon Mar 15 20:12:30 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 16 Mar 2021 00:12:30 +0000
Subject: [issue43428] Sync importlib_metadata enhancements through 3.7.
In-Reply-To: <1615157667.11.0.27235417477.issue43428@roundup.psfhosted.org>
Message-ID: <1615853550.66.0.737167321756.issue43428@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43428>
_______________________________________

From report at bugs.python.org  Mon Mar 15 20:27:18 2021
From: report at bugs.python.org (Brandt Bucher)
Date: Tue, 16 Mar 2021 00:27:18 +0000
Subject: [issue42128] Structural Pattern Matching (PEP 634)
In-Reply-To: <1603466540.96.0.7677855399.issue42128@roundup.psfhosted.org>
Message-ID: <1615854438.71.0.616294373868.issue42128@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

Actually, I didn't see that there are still 2 open linked PRs. I'll wait until those are merged.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42128>
_______________________________________

From report at bugs.python.org  Mon Mar 15 20:28:36 2021
From: report at bugs.python.org (Thomas J. Gallen)
Date: Tue, 16 Mar 2021 00:28:36 +0000
Subject: [issue43477] from x import * behavior inconsistent between module
 types.
In-Reply-To: <1615509638.08.0.549124406797.issue43477@roundup.psfhosted.org>
Message-ID: <1615854516.51.0.702957261797.issue43477@roundup.psfhosted.org>


Thomas J. Gallen <kaori.hinata at gmail.com> added the comment:

Yes, a package. There isn't actually that much in the txz. Most of the files are ostensibly empty.

As an example, let's say we have the following files:

test.py
test_module/__init__.py
test_module/test_submodule.py

test.py contains:
```python
import test_module
print(test_module.test_submodule)
```

test_module/__init__.py
```python
from .test_submodule import *
```

test_module/test_submodule.py is completely empty.

Assuming `from x import *` acts like it does elsewhere, `dir()` before and after the import (in `test_module/__init__.py`) should return the same result (as there's nothing to import, and I haven't made an explicit import of module itself.) In this case, `test_module.test_submodule` is being added to the parent class anyway. That's what I was referring to above regarding `_find_and_load_unlocked`.

I was looking into this, not because I want to use it (I don't), but because the *standard library* is using it in multiple places, and not performing explicit imports. In my case, this results in a slightly more complicated series of events where pylint thinks that attempting to access any member of `asyncio.subprocess` (for example, `Process`) isn't possible because `subprocess` hasn't actually been imported into `asyncio`'s module namespace. I have an issue open for that with PyCQA/pylint already.

Based on the documentation, and how `*` imports behave most of the time, pylint would appear to be correct in that `subprocess` has not been imported into `asyncio`'s module namespace, and as such should not be accessible. Above is a generic example of that behavior. I would assume that `test.py` should fail with an AttributeError, but in this case it does not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43477>
_______________________________________

From report at bugs.python.org  Mon Mar 15 20:41:28 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 16 Mar 2021 00:41:28 +0000
Subject: [issue43080] pprint for dataclass instances
In-Reply-To: <1612052078.12.0.741479641556.issue43080@roundup.psfhosted.org>
Message-ID: <1615855288.64.0.754417101387.issue43080@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I'm leaning toward accepting this on the condition that it only be invoked for dataclasses where __repr__ was the version generated by @dataclass. And also that it use the same fields that the generated __repr__ would use (basically skipping repr=False fields). Under those conditions, I don't see the harm.

The reason I'm leaning toward acceptance is that we've talked about a better pprint for ages, and yet there's no activity that I can tell toward developing a replacement in the stdlib. pprint was a motivating example for PEP 443 (singledispatch), and that was accepted 8 years ago. I don't think we should have to wait forever to get better pprint for dataclasses.

But I'm still not 100% decided, and I can be reasoned with!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43080>
_______________________________________

From report at bugs.python.org  Mon Mar 15 21:26:34 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 16 Mar 2021 01:26:34 +0000
Subject: [issue43080] pprint for dataclass instances
In-Reply-To: <1612052078.12.0.741479641556.issue43080@roundup.psfhosted.org>
Message-ID: <1615857994.49.0.780700469456.issue43080@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

FWIW, we've not had a feature request for this ever, nor has there been a request for pprint to support attrs, nor any other hand-rolled class that implements methods similar to those generated by dataclasses.  AFAICT, this tracker issue wasn't motivated by a known use case; rather, it was "my PR was accepted for SimpleNamespace and thought dataclasses could be the next."

In the absence of known use cases and user requests, I think we should let it be.  Put me down for a -0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43080>
_______________________________________

From report at bugs.python.org  Mon Mar 15 21:50:21 2021
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 16 Mar 2021 01:50:21 +0000
Subject: [issue30555] _io._WindowsConsoleIO breaks in the face of fd
 redirection
In-Reply-To: <1496422613.2.0.0803212432553.issue30555@psf.upfronthosting.co.za>
Message-ID: <1615859421.62.0.213018300689.issue30555@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

PR 1927 is a definite improvement. By using _get_osfhandle() instead of caching the handle value, it guarantees that access to the original console file can be saved and restored via `fd_save = dup(fd)` and `dup2(fd_save, fd)`. It also allows duping a new open of CON, CONIN$, or CONOUT$, or even a new screen buffer from CreateConsoleScreenBuffer(), to the existing fileno(), and the _WindowsConsoleIO() instance will march along none the wiser.

----------
stage:  -> patch review
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30555>
_______________________________________

From report at bugs.python.org  Mon Mar 15 22:15:06 2021
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 16 Mar 2021 02:15:06 +0000
Subject: [issue31665] Edit "Setting [windows] environmental variables"
In-Reply-To: <1506972366.59.0.213398074469.issue31665@psf.upfronthosting.co.za>
Message-ID: <1615860906.04.0.74798888424.issue31665@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31665>
_______________________________________

From report at bugs.python.org  Mon Mar 15 22:16:36 2021
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Tue, 16 Mar 2021 02:16:36 +0000
Subject: [issue27346] Implement os.readv() / os.writev() in Windows port
In-Reply-To: <1466242793.09.0.103237179238.issue27346@psf.upfronthosting.co.za>
Message-ID: <1615860996.23.0.130683986229.issue27346@roundup.psfhosted.org>


???? ????????? <socketpair at gmail.com> added the comment:

I'm not interested in Windows platform anymore.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27346>
_______________________________________

From report at bugs.python.org  Mon Mar 15 22:25:42 2021
From: report at bugs.python.org (Thomas J. Gallen)
Date: Tue, 16 Mar 2021 02:25:42 +0000
Subject: [issue43477] from x import * behavior inconsistent between module
 types.
In-Reply-To: <1615509638.08.0.549124406797.issue43477@roundup.psfhosted.org>
Message-ID: <1615861542.97.0.270103055565.issue43477@roundup.psfhosted.org>


Thomas J. Gallen <kaori.hinata at gmail.com> added the comment:

parent module* rather. Just saw that typo.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43477>
_______________________________________

From report at bugs.python.org  Mon Mar 15 22:27:08 2021
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 16 Mar 2021 02:27:08 +0000
Subject: [issue32434] pathlib.WindowsPath.reslove(strict=False) returns
 absoulte path only if at least one component exists
In-Reply-To: <1514405616.88.0.213398074469.issue32434@psf.upfronthosting.co.za>
Message-ID: <1615861628.39.0.946879116378.issue32434@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

bpo-38671 has PR 17716 pending approval, which addresses the problem in msg309102 by ensuring that a non-strict resolve begins by getting the absolute path via nt._getfullpathname().

----------
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> pathlib.Path.resolve(strict=False) returns relative path on Windows if the entry does not exist

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32434>
_______________________________________

From report at bugs.python.org  Mon Mar 15 22:28:13 2021
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 16 Mar 2021 02:28:13 +0000
Subject: [issue27346] Implement os.readv() / os.writev() in Windows port
In-Reply-To: <1466242793.09.0.103237179238.issue27346@psf.upfronthosting.co.za>
Message-ID: <1615861693.28.0.666096063609.issue27346@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27346>
_______________________________________

From report at bugs.python.org  Mon Mar 15 22:38:55 2021
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 16 Mar 2021 02:38:55 +0000
Subject: [issue43506] PEP 624: Update document for removal schedule
Message-ID: <1615862335.75.0.933917943771.issue43506@roundup.psfhosted.org>


New submission from Inada Naoki <songofacandy at gmail.com>:

They are documented as "will be removed in 4.0" now.

----------
components: C API
messages: 388800
nosy: methane
priority: normal
severity: normal
status: open
title: PEP 624: Update document for removal schedule
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43506>
_______________________________________

From report at bugs.python.org  Mon Mar 15 22:42:02 2021
From: report at bugs.python.org (Larry Trammell)
Date: Tue, 16 Mar 2021 02:42:02 +0000
Subject: [issue43483] Loss of content in simple (but oversize) SAX parsing
In-Reply-To: <1615599352.35.0.560655392831.issue43483@roundup.psfhosted.org>
Message-ID: <1615862522.61.0.603664347473.issue43483@roundup.psfhosted.org>


Larry Trammell <ridgerat at nwi.net> added the comment:

I can't find any real errors in documentation.  There are subtle design and implementation decisions that result in unexpected rare side effects.  After processing hundreds of thousands of lines one way, why would the parser suddenly decide to process the next line differently?  Well, because it can, and it happens to be convenient.  And that can catch users off-guard.

I'm considering whether posting an "enhancement" issue would be more appropriate... maybe there is a way to make the parser systems work more nearly the way people currently expect, without breaking things.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43483>
_______________________________________

From report at bugs.python.org  Mon Mar 15 22:56:47 2021
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 16 Mar 2021 02:56:47 +0000
Subject: [issue43506] PEP 624: Update document for removal schedule
In-Reply-To: <1615862335.75.0.933917943771.issue43506@roundup.psfhosted.org>
Message-ID: <1615863407.6.0.753513279433.issue43506@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
keywords: +patch
pull_requests: +23646
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24885

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43506>
_______________________________________

From report at bugs.python.org  Mon Mar 15 23:08:01 2021
From: report at bugs.python.org (Xinmeng Xia)
Date: Tue, 16 Mar 2021 03:08:01 +0000
Subject: [issue43507] Variables in locals scope fails to be printed.
Message-ID: <1615864081.29.0.727460269138.issue43507@roundup.psfhosted.org>


New submission from Xinmeng Xia <xiaxm at smail.nju.edu.cn>:

The following code 1 calls function 'compile' and 'exec' and execute a statement "s=1". Then we print the value of 's'.  This code can perform well on Python 3.9.2 and output the expected result. However, we pack the whole code into a function (code 2).  The execution fails. 


code 1:
===================
mstr = "s=1"
exec(compile(mstr,'','exec'))
print(s)
===================
output: 1


code2:
===================
def foo():
     mstr = "s=1"
     exec(compile(mstr,'','exec'))
     print(s)
foo()
===================
output: 
Traceback (most recent call last):
    File "/home/xxm/Desktop/apifuzz/doc/genDoc.py", line 37, in <module>
            foo()
    File "/home/xxm/Desktop/apifuzz/doc/genDoc.py", line 35, in foo
            print(s)
NameError: name 's' is not defined

By the way, we print locals().  's' exists in the local scope. It should not fail.
>>print(locals()?
{'mstr': 's=1', 's': 1}

----------
components: Interpreter Core
messages: 388802
nosy: xxm
priority: normal
severity: normal
status: open
title: Variables in locals scope fails to be printed.
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43507>
_______________________________________

From report at bugs.python.org  Mon Mar 15 23:09:30 2021
From: report at bugs.python.org (Xinmeng Xia)
Date: Tue, 16 Mar 2021 03:09:30 +0000
Subject: [issue43508] Miscompilation information for tarfile.open() when given
 too many arguments
Message-ID: <1615864170.77.0.811664842161.issue43508@roundup.psfhosted.org>


New submission from Xinmeng Xia <xiaxm at smail.nju.edu.cn>:

In following example, we only give 10 arguments to 
tarfile.open(). The error message shows "11 arguments were given".    We give it 5 arguments and the error message shows "6 were given". This is not correct.

==========================================================
>>> tarfile.open(*[None]*10)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: open() takes from 1 to 5 positional arguments but 11 were given
>>> tarfile.open(1,2,3,4,5)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: open() takes from 1 to 5 positional arguments but 6 were given
==========================================================

Expected Output? 
For 10 given arguments. the error message is "open() takes from 1 to 5 positional arguments but 10 were given" 

Python: 3.9.2
System: ubuntu 16.04

----------
components: Library (Lib)
messages: 388803
nosy: xxm
priority: normal
severity: normal
status: open
title: Miscompilation information for tarfile.open() when given too many arguments
type: compile error
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43508>
_______________________________________

From report at bugs.python.org  Mon Mar 15 23:10:32 2021
From: report at bugs.python.org (Xinmeng Xia)
Date: Tue, 16 Mar 2021 03:10:32 +0000
Subject: [issue43509] CFunctionType object should be hashable in Python
Message-ID: <1615864232.13.0.0243161103861.issue43509@roundup.psfhosted.org>


New submission from Xinmeng Xia <xiaxm at smail.nju.edu.cn>:

See the following examples, ctypes.resize is a built-in function and it's hashable.   ctypes.memset is a C function (CFunctionType object) and it's ?unhashable?.  However,  ctypes.resize and  ctypes.memset are both immutable. They should act the same in Python. It should not report unhashable type error when ctypes.memset  calls  __hash__(). 

-----------------------------------------------
>>> import ctypes
>>> ctypes.resize
<built-in function resize>
>>> ctypes.resize.__hash__()
146309

>>> ctypes.memset
<CFunctionType object at 0x7fab55961400>
>>> ctypes.memset.__hash__()
Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
TypeError: unhashable type
-----------------------------------------------

Python version: 3.9.2
system: Ubuntu
Expected output: 
ctypes.memset is hashable.

----------
components: Interpreter Core
messages: 388804
nosy: xxm
priority: normal
severity: normal
status: open
title: CFunctionType object should be hashable in Python
type: compile error
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43509>
_______________________________________

From report at bugs.python.org  Mon Mar 15 23:15:14 2021
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 16 Mar 2021 03:15:14 +0000
Subject: [issue33603] Subprocess Thread handles grow with each call and aren't
 released [Windows]
In-Reply-To: <1527001161.43.0.682650639539.issue33603@psf.upfronthosting.co.za>
Message-ID: <1615864514.05.0.593095166692.issue33603@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33603>
_______________________________________

From report at bugs.python.org  Mon Mar 15 23:46:03 2021
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 16 Mar 2021 03:46:03 +0000
Subject: [issue33780] [subprocess] Better Unicode support for shell=True on
 Windows
In-Reply-To: <1528279313.05.0.592728768989.issue33780@psf.upfronthosting.co.za>
Message-ID: <1615866363.31.0.737633177378.issue33780@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

The complexity of mixing standard I/O from the shell and external programs is a limitation of the Windows command line. Each program could choose to use the system (or process) ANSI or OEM code page, the console session's input or output code page, UTF-8, or UTF-16. There's no uniform way to enforce one, consistent choice. So I'm closing this issue as a third party limitation that cannot be addressed in general. The problem has to be handled on a case by case basis.

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33780>
_______________________________________

From report at bugs.python.org  Tue Mar 16 00:02:34 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 16 Mar 2021 04:02:34 +0000
Subject: [issue41361] Converting collections.deque methods to Argument Clinic
In-Reply-To: <1595345161.63.0.950006640514.issue41361@roundup.psfhosted.org>
Message-ID: <1615867354.49.0.870328556025.issue41361@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 448801da96c70699e2ca0798efdfe86d45f37f06 by Dennis Sweeney in branch 'master':
bpo-41361: Optimized argument parsing for deque_rotate (GH-24796)
https://github.com/python/cpython/commit/448801da96c70699e2ca0798efdfe86d45f37f06


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41361>
_______________________________________

From report at bugs.python.org  Tue Mar 16 00:02:37 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 16 Mar 2021 04:02:37 +0000
Subject: [issue43285] ftplib should not use the host from the PASV response
In-Reply-To: <1613908174.7.0.0578051462677.issue43285@roundup.psfhosted.org>
Message-ID: <1615867357.69.0.466869324778.issue43285@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
pull_requests: +23647
stage: commit review -> patch review
pull_request: https://github.com/python/cpython/pull/24886

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43285>
_______________________________________

From report at bugs.python.org  Tue Mar 16 00:02:51 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 16 Mar 2021 04:02:51 +0000
Subject: [issue43285] ftplib should not use the host from the PASV response
In-Reply-To: <1613908174.7.0.0578051462677.issue43285@roundup.psfhosted.org>
Message-ID: <1615867371.44.0.914857117407.issue43285@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
pull_requests: +23648
pull_request: https://github.com/python/cpython/pull/24887

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43285>
_______________________________________

From report at bugs.python.org  Tue Mar 16 00:02:51 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 16 Mar 2021 04:02:51 +0000
Subject: [issue41361] Converting collections.deque methods to Argument Clinic
In-Reply-To: <1595345161.63.0.950006640514.issue41361@roundup.psfhosted.org>
Message-ID: <1615867371.14.0.143986382467.issue41361@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks for the PR :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41361>
_______________________________________

From report at bugs.python.org  Tue Mar 16 00:03:04 2021
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 16 Mar 2021 04:03:04 +0000
Subject: [issue36646] os.listdir() got permission error in Python3.6 but it's
 fine in Python2.7
In-Reply-To: <1555462000.28.0.955431957524.issue36646@roundup.psfhosted.org>
Message-ID: <1615867384.69.0.195799069089.issue36646@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

I'm certain this is a third-party problem -- something like AppLocker or an anti-malware program that's limiting filesystem access. It's not a bug in Python, which simply uses FindFirstFileW() and FindNextFileW() in the normal way.

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36646>
_______________________________________

From report at bugs.python.org  Tue Mar 16 00:11:11 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 16 Mar 2021 04:11:11 +0000
Subject: [issue43285] ftplib should not use the host from the PASV response
In-Reply-To: <1613908174.7.0.0578051462677.issue43285@roundup.psfhosted.org>
Message-ID: <1615867871.6.0.989693528838.issue43285@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
pull_requests: +23649
pull_request: https://github.com/python/cpython/pull/24888

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43285>
_______________________________________

From report at bugs.python.org  Tue Mar 16 00:13:37 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 16 Mar 2021 04:13:37 +0000
Subject: [issue43285] ftplib should not use the host from the PASV response
In-Reply-To: <1613908174.7.0.0578051462677.issue43285@roundup.psfhosted.org>
Message-ID: <1615868017.43.0.729355466712.issue43285@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
pull_requests: +23650
pull_request: https://github.com/python/cpython/pull/24889

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43285>
_______________________________________

From report at bugs.python.org  Tue Mar 16 00:19:49 2021
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 16 Mar 2021 04:19:49 +0000
Subject: [issue43510] PEP 597: Implemente encoding="locale" option and
 EncodingWarning
Message-ID: <1615868389.17.0.260147645451.issue43510@roundup.psfhosted.org>


New submission from Inada Naoki <songofacandy at gmail.com>:

PEP 597 is accepted.

----------
components: IO
messages: 388809
nosy: methane
priority: normal
severity: normal
status: open
title: PEP 597: Implemente encoding="locale" option and EncodingWarning
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43510>
_______________________________________

From report at bugs.python.org  Tue Mar 16 00:23:19 2021
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 16 Mar 2021 04:23:19 +0000
Subject: [issue41123] Remove Py_UNICODE APIs except PEP 623
In-Reply-To: <1593143601.8.0.862502731431.issue41123@roundup.psfhosted.org>
Message-ID: <1615868599.29.0.488664955056.issue41123@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/issue41123>
_______________________________________

From report at bugs.python.org  Tue Mar 16 00:24:36 2021
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 16 Mar 2021 04:24:36 +0000
Subject: [issue43506] PEP 624: Update document for removal schedule
In-Reply-To: <1615862335.75.0.933917943771.issue43506@roundup.psfhosted.org>
Message-ID: <1615868676.82.0.24631875279.issue43506@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset 1330338583d183250186a8123b99d2283e945b4f by Inada Naoki in branch 'master':
bpo-43506: Doc: Update removal schedule for Py_UNICODE encoder APIs (GH-24885)
https://github.com/python/cpython/commit/1330338583d183250186a8123b99d2283e945b4f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43506>
_______________________________________

From report at bugs.python.org  Tue Mar 16 00:24:44 2021
From: report at bugs.python.org (miss-islington)
Date: Tue, 16 Mar 2021 04:24:44 +0000
Subject: [issue43506] PEP 624: Update document for removal schedule
In-Reply-To: <1615862335.75.0.933917943771.issue43506@roundup.psfhosted.org>
Message-ID: <1615868684.22.0.878664767786.issue43506@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +23652
pull_request: https://github.com/python/cpython/pull/24891

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43506>
_______________________________________

From report at bugs.python.org  Tue Mar 16 00:24:38 2021
From: report at bugs.python.org (miss-islington)
Date: Tue, 16 Mar 2021 04:24:38 +0000
Subject: [issue43506] PEP 624: Update document for removal schedule
In-Reply-To: <1615862335.75.0.933917943771.issue43506@roundup.psfhosted.org>
Message-ID: <1615868678.51.0.802751413564.issue43506@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: +23651
pull_request: https://github.com/python/cpython/pull/24890

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43506>
_______________________________________

From report at bugs.python.org  Tue Mar 16 00:25:21 2021
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 16 Mar 2021 04:25:21 +0000
Subject: [issue43510] PEP 597: Implemente encoding="locale" option and
 EncodingWarning
In-Reply-To: <1615868389.17.0.260147645451.issue43510@roundup.psfhosted.org>
Message-ID: <1615868721.28.0.697854219687.issue43510@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
keywords: +patch
pull_requests: +23653
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19481

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43510>
_______________________________________

From report at bugs.python.org  Tue Mar 16 00:31:38 2021
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 16 Mar 2021 04:31:38 +0000
Subject: [issue36213] subprocess.check_output() fails with OSError: [WinError
 87] when current directory name is too long
In-Reply-To: <1551883036.38.0.267750986311.issue36213@roundup.psfhosted.org>
Message-ID: <1615869098.85.0.249442685632.issue36213@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

As discussed in msg337357, the Windows API does not support setting the current working directory to a path that starts with \\?\ or \\.\. It's dysfunctional in many cases. Anyway, using a \\?\ path does not remove the length limit on the working directory, which is a hard limit in a process that does not support long DOS paths. I assume this is why CreateProcessW() hasn't been extended to support long paths in lpCurrentDirectory. 

The only behavior that can be addressed here is what to do when CreateProcessW() fails with ERROR_INVALID_PARAMETER (87) if the working directory of the current process is a long path. Maybe subprocess should emit a warning for this error if the working directory is a long path, at least to hint to a developer that this could be the reason for the error. Otherwise the error is difficult to understand if you don't already know what to look for.

----------
components: +Library (Lib)
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36213>
_______________________________________

From report at bugs.python.org  Tue Mar 16 00:38:06 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 16 Mar 2021 04:38:06 +0000
Subject: [issue43285] ftplib should not use the host from the PASV response
In-Reply-To: <1613908174.7.0.0578051462677.issue43285@roundup.psfhosted.org>
Message-ID: <1615869486.03.0.781422882376.issue43285@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:


New changeset d0312cece9ce89d783687ff6dddaae6495e19fcf by Gregory P. Smith in branch '3.9':
[3.9] bpo-43285: Add a What's New entry for 3.9.3. (GH-24888)
https://github.com/python/cpython/commit/d0312cece9ce89d783687ff6dddaae6495e19fcf


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43285>
_______________________________________

From report at bugs.python.org  Tue Mar 16 00:38:31 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 16 Mar 2021 04:38:31 +0000
Subject: [issue43285] ftplib should not use the host from the PASV response
In-Reply-To: <1613908174.7.0.0578051462677.issue43285@roundup.psfhosted.org>
Message-ID: <1615869511.87.0.729606860903.issue43285@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:


New changeset 9eda0dfff2884bf9272f37d4151ef2335f55066f by Gregory P. Smith in branch '3.8':
[3.8] bpo-43285: Whats New entry for 3.8.9. (GH-24889)
https://github.com/python/cpython/commit/9eda0dfff2884bf9272f37d4151ef2335f55066f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43285>
_______________________________________

From report at bugs.python.org  Tue Mar 16 00:39:07 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 16 Mar 2021 04:39:07 +0000
Subject: [issue43285] ftplib should not use the host from the PASV response
In-Reply-To: <1613908174.7.0.0578051462677.issue43285@roundup.psfhosted.org>
Message-ID: <1615869547.72.0.802462543268.issue43285@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

3.7 and 3.6 PRs updated to include a What's New entry.

----------
assignee: gregory.p.smith -> ned.deily
priority: normal -> release blocker
versions:  -Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43285>
_______________________________________

From report at bugs.python.org  Tue Mar 16 00:39:03 2021
From: report at bugs.python.org (OrbitalHorizons)
Date: Tue, 16 Mar 2021 04:39:03 +0000
Subject: [issue43284] Inability to fetch build 20H2
In-Reply-To: <1613904146.72.0.850542213327.issue43284@roundup.psfhosted.org>
Message-ID: <1615869543.55.0.516703147214.issue43284@roundup.psfhosted.org>


OrbitalHorizons <moserm1103 at gmail.com> added the comment:

Platform seems to have been fixed as all pre release builds were fetched as intended shortly after the post was created here, however Windows 10 Version 10.0.19042 is still unable to be displayed by the Python platform module in my Python 3.8.8 system.

----------
title: Wrong windows build post version 2004 -> Inability to fetch build 20H2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43284>
_______________________________________

From report at bugs.python.org  Tue Mar 16 00:48:20 2021
From: report at bugs.python.org (miss-islington)
Date: Tue, 16 Mar 2021 04:48:20 +0000
Subject: [issue43506] PEP 624: Update document for removal schedule
In-Reply-To: <1615862335.75.0.933917943771.issue43506@roundup.psfhosted.org>
Message-ID: <1615870100.85.0.19442655824.issue43506@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a838e477a009bae4549f10bfd3396b8d5678415d by Miss Islington (bot) in branch '3.9':
bpo-43506: Doc: Update removal schedule for Py_UNICODE encoder APIs (GH-24885)
https://github.com/python/cpython/commit/a838e477a009bae4549f10bfd3396b8d5678415d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43506>
_______________________________________

From report at bugs.python.org  Tue Mar 16 01:04:10 2021
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 16 Mar 2021 05:04:10 +0000
Subject: [issue34187] Issues with lazy fd support in _WindowsConsoleIO
 fileno() and close()
In-Reply-To: <1532250349.34.0.56676864532.issue34187@psf.upfronthosting.co.za>
Message-ID: <1615871050.63.0.321756802965.issue34187@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

The issues brought up here are addressed in a more direct, comprehensive, and productive way in PR 1927 for bpo-30555.

----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> _io._WindowsConsoleIO breaks in the face of fd redirection

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34187>
_______________________________________

From report at bugs.python.org  Tue Mar 16 01:10:03 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 16 Mar 2021 05:10:03 +0000
Subject: [issue43483] Loss of content in simple (but oversize) SAX parsing
In-Reply-To: <1615599352.35.0.560655392831.issue43483@roundup.psfhosted.org>
Message-ID: <1615871403.8.0.647221210896.issue43483@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I think we could document where a "quoted string of length 8 characters would be returned in multiple pieces" occurs. Which API is that?

If we change that, and if we call it an enhancement instead of a bug fix, then it can't be backported. It would be worth doing both: document the behavior for old releases, and change the behavior for new releases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43483>
_______________________________________

From report at bugs.python.org  Tue Mar 16 01:24:32 2021
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 16 Mar 2021 05:24:32 +0000
Subject: [issue43506] PEP 624: Update document for removal schedule
In-Reply-To: <1615862335.75.0.933917943771.issue43506@roundup.psfhosted.org>
Message-ID: <1615872272.84.0.30233437805.issue43506@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset dc8558ef302f1b14b45c21abd7451e4fb56b4604 by Miss Islington (bot) in branch '3.8':
bpo-43506: Doc: Update removal schedule for Py_UNICODE encoder APIs (GH-24885)
https://github.com/python/cpython/commit/dc8558ef302f1b14b45c21abd7451e4fb56b4604


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43506>
_______________________________________

From report at bugs.python.org  Tue Mar 16 01:26:26 2021
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 16 Mar 2021 05:26:26 +0000
Subject: [issue43506] PEP 624: Update document for removal schedule
In-Reply-To: <1615862335.75.0.933917943771.issue43506@roundup.psfhosted.org>
Message-ID: <1615872386.69.0.975899680124.issue43506@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/issue43506>
_______________________________________

From report at bugs.python.org  Tue Mar 16 01:27:43 2021
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 16 Mar 2021 05:27:43 +0000
Subject: [issue42578] Add tip when encountering UnicodeDecode/EncodeError in
 open()
In-Reply-To: <1607181755.9.0.464136103954.issue42578@roundup.psfhosted.org>
Message-ID: <1615872463.2.0.83636176718.issue42578@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

PEP 597 is accepted. May I close this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42578>
_______________________________________

From report at bugs.python.org  Tue Mar 16 02:03:50 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 16 Mar 2021 06:03:50 +0000
Subject: [issue43499] Compiler warnings in building Python 3.9 on Windows
In-Reply-To: <1615810323.65.0.00918597187884.issue43499@roundup.psfhosted.org>
Message-ID: <1615874630.31.0.891891189008.issue43499@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 651fc30af7ac6138764106b87632cabca56a98bb by Serhiy Storchaka in branch '3.9':
bpo-43499: Silence compiler warnings about using legacy C API on Windows (GH-24873)
https://github.com/python/cpython/commit/651fc30af7ac6138764106b87632cabca56a98bb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43499>
_______________________________________

From report at bugs.python.org  Tue Mar 16 02:13:14 2021
From: report at bugs.python.org (Thomas Wamm)
Date: Tue, 16 Mar 2021 06:13:14 +0000
Subject: [issue43511] Tk 8.6.11 slow on M1 Mac Mini MacOS Python 3.9.2 native
 ARM version
Message-ID: <1615875194.4.0.35991043769.issue43511@roundup.psfhosted.org>


New submission from Thomas Wamm <thomaswamm at gmail.com>:

Comparing performance of a Tkinter graphics program with Python 3.9.2 on an M1 Mac Mini, I find it to be slower than earlier versions, and much slower than the same program running on other computers such as a Raspberry Pi 3B (Python 3.7.3).

Initial investigation suggests the slow down is because of Tk 8.6.11.
The same program on Windows 10 on Intel i5-8250U is at least 10x faster, contrary to expectations.

Has anyone noticed similar?

The program is simple & portable, downloadable from: 
https://github.com/ThomasWamm/TerraLunar.git
All it does is 2-D orbital mechanics simulation, to teach me Python.

----------
components: Tkinter
messages: 388822
nosy: thomaswamm
priority: normal
severity: normal
status: open
title: Tk 8.6.11 slow on M1 Mac Mini MacOS Python 3.9.2 native ARM version
type: performance
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43511>
_______________________________________

From report at bugs.python.org  Tue Mar 16 04:33:07 2021
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 16 Mar 2021 08:33:07 +0000
Subject: [issue43466] ssl/hashlib: Add configure option to set or auto-detect
 rpath to OpenSSL libs
In-Reply-To: <1615418043.46.0.229114131093.issue43466@roundup.psfhosted.org>
Message-ID: <1615883587.5.0.0813619044643.issue43466@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Pablo,
in cc12888f9b4b69247f342fe1304984c3eb3d9647 you have regenerated configure with autoconf 2.71. The version is brand new and was released just 6 weeks ago. All my Linux machines have autoconf 2.69 from 2012 (!). Apparently 2.70 had some issues.

Would you mind if I regenerate configure with 2.69 and we stick with stable version for a little bit longer?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43466>
_______________________________________

From report at bugs.python.org  Tue Mar 16 04:39:13 2021
From: report at bugs.python.org (Alexey Volkov)
Date: Tue, 16 Mar 2021 08:39:13 +0000
Subject: [issue35118] Add peek() or first() method in queue
In-Reply-To: <1540956018.19.0.788709270274.issue35118@psf.upfronthosting.co.za>
Message-ID: <1615883953.06.0.510016352548.issue35118@roundup.psfhosted.org>


Alexey Volkov <alexey.volkov at ark-kun.com> added the comment:

>Why not just dismiss older queue entries during a normal get() operation?  Or just use a plain deque with access guarded by a lock.

You do not know whether the item needs to be removed until you see it. And to see it you need to get it. And if you get it, you cannot push it back to the start of the queue.

>FWIW, the standard library queue module doesn't have a straight-forward way to implement a peek() method.

I currently use `q.deque[0]`

>Or just use a plain deque with access guarded by a lock.

I can. But technically the same applies to almost any queue usage.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35118>
_______________________________________

From report at bugs.python.org  Tue Mar 16 04:43:48 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 16 Mar 2021 08:43:48 +0000
Subject: [issue43507] Variables in locals scope fails to be printed.
In-Reply-To: <1615864081.29.0.727460269138.issue43507@roundup.psfhosted.org>
Message-ID: <1615884228.24.0.580404337228.issue43507@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I think this is essentially a duplicate of #24800. (Short version, the behaviour is by design, and documented, but there may be scope for clarifying or improving the documentation.)

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43507>
_______________________________________

From report at bugs.python.org  Tue Mar 16 05:48:10 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 16 Mar 2021 09:48:10 +0000
Subject: [issue43466] ssl/hashlib: Add configure option to set or auto-detect
 rpath to OpenSSL libs
In-Reply-To: <1615418043.46.0.229114131093.issue43466@roundup.psfhosted.org>
Message-ID: <1615888090.87.0.297214895776.issue43466@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> Would you mind if I regenerate configure with 2.69 and we stick with stable version for a little bit longer?

Please, go ahead. I need to remember then to use a docker container or something like that for the release then.

What's the problem that you are experiencing?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43466>
_______________________________________

From report at bugs.python.org  Tue Mar 16 06:02:24 2021
From: report at bugs.python.org (Paul)
Date: Tue, 16 Mar 2021 10:02:24 +0000
Subject: [issue43512] Bug in isinstance(instance,
 cls) with cls being a protocol? (PEP 544)
Message-ID: <1615888944.07.0.094574416265.issue43512@roundup.psfhosted.org>


New submission from Paul <paul.dest at web.de>:

The section "Subtyping relationships with other types" of PEP 544 states:

"A concrete type X is a subtype of protocol P if and only if X implements all protocol members of P with compatible types. In other words, subtyping with respect to a protocol is always structural."

This requirement is violated by the current implementation of CPython (version 3.9.2):

```
from typing import Protocol


class P(Protocol):
    pm: str  # no default value, but still a protocol member


class C(P):
    # inherits P but does NOT implement pm, since P did not provide a default value
    pass

    
assert isinstance(C(), P)  # violates the PEP 544 requirement cited above

C().pm  # raises: AttributeError: 'C' object has no attribute 'pm'
```

----------
components: Library (Lib)
messages: 388827
nosy: paul-dest
priority: normal
severity: normal
status: open
title: Bug in isinstance(instance, cls) with cls being a protocol? (PEP 544)
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43512>
_______________________________________

From report at bugs.python.org  Tue Mar 16 06:09:47 2021
From: report at bugs.python.org (Lewis Gaul)
Date: Tue, 16 Mar 2021 10:09:47 +0000
Subject: [issue43080] pprint for dataclass instances
In-Reply-To: <1612052078.12.0.741479641556.issue43080@roundup.psfhosted.org>
Message-ID: <1615889387.69.0.597737493394.issue43080@roundup.psfhosted.org>


Lewis Gaul <lewis.gaul at gmail.com> added the comment:

> FWIW, we've not had a feature request for this ever, nor has there been a request for pprint to support attrs, nor any other hand-rolled class that implements methods similar to those generated by dataclasses.

I wouldn't expect core Python to support a 3rd party lib like attrs, but I fail to see what's so different between dataclasses, SimpleNamespace and namedtuple - all of these may be used for storing/modelling [nested] data, which then may be printed.

> AFAICT, this tracker issue wasn't motivated by a known use case; rather, it was "my PR was accepted for SimpleNamespace and thought dataclasses could be the next."

This issue is entirely motivated by a real-world example - I'm currently maintaining a private fork of the pprint module with support for dataclasses added. I'm assuming the reason this hasn't come up before is that dataclasses are relatively new (and plenty of users will still be on older versions of Python).

I was not the author of the issue that added support for SimpleNamespace, I just saw it and used it as an example of precedent.

> At some point, we need a modern redesign alternative to pprint.

I'm on board with this, but as Eric said there aren't currently any signs of this being worked on. In absence of a redesign, dataclass support seems like a natural extension to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43080>
_______________________________________

From report at bugs.python.org  Tue Mar 16 06:15:11 2021
From: report at bugs.python.org (Tomas Orsava)
Date: Tue, 16 Mar 2021 10:15:11 +0000
Subject: [issue43433] xmlrpc.client ignores query in URI ("?action=xmlrpc2")
 since python-3.9
In-Reply-To: <1615206556.6.0.195752820504.issue43433@roundup.psfhosted.org>
Message-ID: <1615889711.65.0.049674056992.issue43433@roundup.psfhosted.org>


Change by Tomas Orsava <tomas.n at orsava.cz>:


----------
components: +XML

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43433>
_______________________________________

From report at bugs.python.org  Tue Mar 16 06:23:05 2021
From: report at bugs.python.org (Thomas Wamm)
Date: Tue, 16 Mar 2021 10:23:05 +0000
Subject: [issue43511] Tk 8.6.11 slow on M1 Mac Mini MacOS Python 3.9.2 native
 ARM version
In-Reply-To: <1615875194.4.0.35991043769.issue43511@roundup.psfhosted.org>
Message-ID: <1615890185.25.0.202340004179.issue43511@roundup.psfhosted.org>


Thomas Wamm <thomaswamm at gmail.com> added the comment:

An easy demo of the performance problem is to compare the execution speed of the single command: 

>>> help('modules')

in a python3 shell in a terminal window (it's real fast), 
vs. inside the IDLE3 shell (it's terribly slow).

I understand that IDLE3 uses the tkinter.py/Tcl/Tk toolset for windowing. There's something slowing it down on the M1 Mac Mini (MacOS 11.2.3), making it run much slower than on a Wintel PC or Linux Raspberry Pi.

I don't know if the problem occurs with any Python versions other than 3.9.2 on MacOS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43511>
_______________________________________

From report at bugs.python.org  Tue Mar 16 06:26:02 2021
From: report at bugs.python.org (Tomas Orsava)
Date: Tue, 16 Mar 2021 10:26:02 +0000
Subject: [issue43433] xmlrpc.client ignores query in URI ("?action=xmlrpc2")
 since python-3.9
In-Reply-To: <1615206556.6.0.195752820504.issue43433@roundup.psfhosted.org>
Message-ID: <1615890362.59.0.564374153696.issue43433@roundup.psfhosted.org>


Change by Tomas Orsava <tomas.n at orsava.cz>:


----------
nosy: +eli.bendersky, scoder

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43433>
_______________________________________

From report at bugs.python.org  Tue Mar 16 06:27:25 2021
From: report at bugs.python.org (E. Paine)
Date: Tue, 16 Mar 2021 10:27:25 +0000
Subject: [issue43511] Tk 8.6.11 slow on M1 Mac Mini MacOS Python 3.9.2 native
 ARM version
In-Reply-To: <1615875194.4.0.35991043769.issue43511@roundup.psfhosted.org>
Message-ID: <1615890445.88.0.0146109424535.issue43511@roundup.psfhosted.org>


Change by E. Paine <paineelisha at gmail.com>:


----------
components: +macOS
nosy: +epaine, ned.deily, ronaldoussoren
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43511>
_______________________________________

From report at bugs.python.org  Tue Mar 16 06:37:38 2021
From: report at bugs.python.org (OndrejPtak)
Date: Tue, 16 Mar 2021 10:37:38 +0000
Subject: [issue43433] xmlrpc.client ignores query in URI ("?action=xmlrpc2")
 since python-3.9
In-Reply-To: <1615206556.6.0.195752820504.issue43433@roundup.psfhosted.org>
Message-ID: <1615891058.03.0.0493305891435.issue43433@roundup.psfhosted.org>


OndrejPtak <ondrej.ptak at gmail.com> added the comment:

Reproducer:
* create ServerProxy with UPI containing query part, e.g. http://example.com?foo=bar
* communicate

Old behavior:
-------------
send: b'POST /?foo=bar HTTP/1.1\r\nHost: example.com\r\nAccept-Encoding: gzip\r\nContent-Type: text/xml\r\nUser-Agent: Python-xmlrpc/3.8\r\nContent-Length: 197\r\n\r\n'
send: b"<?xml version='1.0'?>\n<methodCall>\n<methodName>getRecentChanges</methodName>\n<params>\n<param>\n<value><dateTime.iso8601>20210301T00:00:00</dateTime.iso8601></value>\n</param>\n</params>\n</methodCall>\n"

New behaviour:
--------------
send: b'POST / HTTP/1.1\r\nHost: example.com\r\nAccept-Encoding: gzip\r\nContent-Type: text/xml\r\nUser-Agent: Python-xmlrpc/3.9\r\nContent-Length: 197\r\n\r\n'
send: b"<?xml version='1.0'?>\n<methodCall>\n<methodName>getRecentChanges</methodName>\n<params>\n<param>\n<value><dateTime.iso8601>20210301T00:00:00</dateTime.iso8601></value>\n</param>\n</params>\n</methodCall>\n"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43433>
_______________________________________

From report at bugs.python.org  Tue Mar 16 06:41:20 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 16 Mar 2021 10:41:20 +0000
Subject: [issue43507] Variables in locals scope fails to be printed.
In-Reply-To: <1615864081.29.0.727460269138.issue43507@roundup.psfhosted.org>
Message-ID: <1615891280.15.0.24572285707.issue43507@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> exec docs should note that the no argument form in a local scope is really the two argument form

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43507>
_______________________________________

From report at bugs.python.org  Tue Mar 16 06:45:57 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Mar 2021 10:45:57 +0000
Subject: [issue43466] ssl/hashlib: Add configure option to set or auto-detect
 rpath to OpenSSL libs
In-Reply-To: <1615418043.46.0.229114131093.issue43466@roundup.psfhosted.org>
Message-ID: <1615891557.96.0.875228223054.issue43466@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Should the rpath be set on OpenSSL, on the Python ssl module, or on the Python executable?

> no (default): don't set an rpath

If most users get it wrong, why not using "auto: auto-detect rpath from OPENSSL_LDFLAGS (--with-openssl or pkg-config)" by default?

The Fedora packaging disallows the usage of rpath.

All I need about rpath is that it can be dangerous in some cases, but I forgot about the details. For example, on Fedora, if OpenSSL is installed in the regular /usr/lib64/libssl.so directory, rpath must not be used. Otherwise, it can lead to crash, bugs or vulnerabilities.

Fedora, Python and rpath:

* https://pagure.io/packaging-committee/issue/886
* https://bugs.python.org/issue36659#msg340731

Tell me if you need more details about the issues when rpath is misued. But I need to ask my colleagues, I forgot the details.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43466>
_______________________________________

From report at bugs.python.org  Tue Mar 16 06:48:05 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Mar 2021 10:48:05 +0000
Subject: [issue36213] subprocess.check_output() fails with OSError: [WinError
 87] when current directory name is too long
In-Reply-To: <1551883036.38.0.267750986311.issue36213@roundup.psfhosted.org>
Message-ID: <1615891685.19.0.179357574516.issue36213@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36213>
_______________________________________

From report at bugs.python.org  Tue Mar 16 06:58:22 2021
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 16 Mar 2021 10:58:22 +0000
Subject: [issue43466] ssl/hashlib: Add configure option to set or auto-detect
 rpath to OpenSSL libs
In-Reply-To: <1615418043.46.0.229114131093.issue43466@roundup.psfhosted.org>
Message-ID: <1615892302.49.0.277919397466.issue43466@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

It's a compromise.

The default settings for --with-openssl-rpath=no (--without-openssl-rpath) is backwards compatible with previous Python versions. The default behavor stays the same.

I don't want to set an rpath *unless* the user specifies that they want an rpath. I lack time and resources to verify that OPENSSL_LDFLAGS and OpenSSL's pkg-config files don't include any -L flags on all Linux, BSD, and macOS distributions. The new flag will make it more obvious to users that they may want an rpath, too.

$ ./configure --help
...
  --with-openssl=DIR      override root of the OpenSSL directory to DIR
  --with-openssl-rpath=[DIR|auto|no]
                          Set runtime library directory (rpath) for OpenSSL
                          libraries, no (default): don't set rpath, auto:
                          auto-detect rpath from --with-openssl and
                          pkg-config, DIR: set an explicit rpath
...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43466>
_______________________________________

From report at bugs.python.org  Tue Mar 16 07:00:13 2021
From: report at bugs.python.org (Steve Dower)
Date: Tue, 16 Mar 2021 11:00:13 +0000
Subject: [issue43284] Inability to fetch build 20H2
In-Reply-To: <1613904146.72.0.850542213327.issue43284@roundup.psfhosted.org>
Message-ID: <1615892413.5.0.932014991114.issue43284@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Nothing has changed in platform, and all current releases return the same version number for me (which matches the original report).

As I said, we need to find a versioned DLL that _always_ rebuilds to extract the version number from, because that's the most reliable way I know of to avoid the compatibility shims.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43284>
_______________________________________

From report at bugs.python.org  Tue Mar 16 07:05:17 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Mar 2021 11:05:17 +0000
Subject: [issue43466] ssl/hashlib: Add configure option to set or auto-detect
 rpath to OpenSSL libs
In-Reply-To: <1615418043.46.0.229114131093.issue43466@roundup.psfhosted.org>
Message-ID: <1615892717.74.0.564159180384.issue43466@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> The default settings for --with-openssl-rpath=no (--without-openssl-rpath) is backwards compatible with previous Python versions. The default behavor stays the same.

Ok. That makes sense.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43466>
_______________________________________

From report at bugs.python.org  Tue Mar 16 07:14:48 2021
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 16 Mar 2021 11:14:48 +0000
Subject: [issue43497] SyntaxWarning for "assertion is always true,
 perhaps remove parentheses?" does not work with constants
In-Reply-To: <1615793485.02.0.990067169214.issue43497@roundup.psfhosted.org>
Message-ID: <1615893288.78.0.473386847887.issue43497@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset a8ef4572a6b28bcfc0b10b34fa4204954b9dd761 by tsukasa-au in branch 'master':
bpo-43497: Emit SyntaxWarnings for assertions with tuple constants. (GH-24867)
https://github.com/python/cpython/commit/a8ef4572a6b28bcfc0b10b34fa4204954b9dd761


----------
nosy: +Mark.Shannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43497>
_______________________________________

From report at bugs.python.org  Tue Mar 16 07:16:51 2021
From: report at bugs.python.org (Ned Batchelder)
Date: Tue, 16 Mar 2021 11:16:51 +0000
Subject: [issue42246] Implement PEP 626 -- Precise line numbers for debugging
In-Reply-To: <1604331162.26.0.596873070589.issue42246@roundup.psfhosted.org>
Message-ID: <1615893411.61.0.544327809.issue42246@roundup.psfhosted.org>


Ned Batchelder <ned at nedbatchelder.com> added the comment:

Is there a reason PEP 626 isn't yet mentioned in https://docs.python.org/3.10/whatsnew/3.10.html ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42246>
_______________________________________

From report at bugs.python.org  Tue Mar 16 07:31:32 2021
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 16 Mar 2021 11:31:32 +0000
Subject: [issue42246] Implement PEP 626 -- Precise line numbers for debugging
In-Reply-To: <1604331162.26.0.596873070589.issue42246@roundup.psfhosted.org>
Message-ID: <1615894292.02.0.7741692512.issue42246@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

No. We should add it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42246>
_______________________________________

From report at bugs.python.org  Tue Mar 16 07:43:46 2021
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 16 Mar 2021 11:43:46 +0000
Subject: [issue42246] Implement PEP 626 -- Precise line numbers for debugging
In-Reply-To: <1604331162.26.0.596873070589.issue42246@roundup.psfhosted.org>
Message-ID: <1615895026.99.0.247008066401.issue42246@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
pull_requests: +23654
pull_request: https://github.com/python/cpython/pull/24892

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42246>
_______________________________________

From report at bugs.python.org  Tue Mar 16 07:59:14 2021
From: report at bugs.python.org (wyz23x2)
Date: Tue, 16 Mar 2021 11:59:14 +0000
Subject: [issue41730] Show deprecation warnings for tkinter.tix
In-Reply-To: <1599364490.99.0.633496777395.issue41730@roundup.psfhosted.org>
Message-ID: <1615895954.44.0.219344639828.issue41730@roundup.psfhosted.org>


wyz23x2 <wyz23x2 at 163.com> added the comment:

Um, is this going on?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41730>
_______________________________________

From report at bugs.python.org  Tue Mar 16 08:24:03 2021
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=)
Date: Tue, 16 Mar 2021 12:24:03 +0000
Subject: [issue18232] running a suite with no tests is not an error
In-Reply-To: <1371411159.89.0.919313216558.issue18232@psf.upfronthosting.co.za>
Message-ID: <1615897443.74.0.68936712932.issue18232@roundup.psfhosted.org>


Change by Micha? G?rny <mgorny at gentoo.org>:


----------
keywords: +patch
pull_requests: +23655
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24893

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18232>
_______________________________________

From report at bugs.python.org  Tue Mar 16 08:25:51 2021
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=)
Date: Tue, 16 Mar 2021 12:25:51 +0000
Subject: [issue18232] running a suite with no tests is not an error
In-Reply-To: <1371411159.89.0.919313216558.issue18232@psf.upfronthosting.co.za>
Message-ID: <1615897551.55.0.663462339865.issue18232@roundup.psfhosted.org>


Change by Micha? G?rny <mgorny at gentoo.org>:


----------
versions: +Python 3.10 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18232>
_______________________________________

From report at bugs.python.org  Tue Mar 16 09:27:02 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Tue, 16 Mar 2021 13:27:02 +0000
Subject: [issue43502] [C-API] Convert obvious unsafe macros to static inline
 functions
In-Reply-To: <1615816484.12.0.00251754107838.issue43502@roundup.psfhosted.org>
Message-ID: <1615901222.99.0.19892659122.issue43502@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

Under Include/, including subdirectories, there are 88 macros that reuse arguments.

----------
Added file: https://bugs.python.org/file49876/macros-that-reuse-args.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43502>
_______________________________________

From report at bugs.python.org  Tue Mar 16 09:29:44 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Tue, 16 Mar 2021 13:29:44 +0000
Subject: [issue43502] [C-API] Convert obvious unsafe macros to static inline
 functions
In-Reply-To: <1615816484.12.0.00251754107838.issue43502@roundup.psfhosted.org>
Message-ID: <1615901384.96.0.356242551187.issue43502@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


Removed file: https://bugs.python.org/file49876/macros-that-reuse-args.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43502>
_______________________________________

From report at bugs.python.org  Tue Mar 16 09:29:38 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Tue, 16 Mar 2021 13:29:38 +0000
Subject: [issue43502] [C-API] Convert obvious unsafe macros to static inline
 functions
In-Reply-To: <1615816484.12.0.00251754107838.issue43502@roundup.psfhosted.org>
Message-ID: <1615901378.49.0.313374255549.issue43502@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


Added file: https://bugs.python.org/file49877/macros-that-reuse-args.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43502>
_______________________________________

From report at bugs.python.org  Tue Mar 16 09:57:10 2021
From: report at bugs.python.org (ThiefMaster)
Date: Tue, 16 Mar 2021 13:57:10 +0000
Subject: [issue43513] venv: recreate symlinks on --upgrade
Message-ID: <1615903030.34.0.439862030712.issue43513@roundup.psfhosted.org>


New submission from ThiefMaster <adrian at planetcoding.net>:

When using `python -m venv --upgrade someenv`, it rewrites `pyvenv.cfg` with the current python version but leaves the python symlinks untouched (https://github.com/python/cpython/blob/a8ef4572a6b28bcfc0b10b34fa4204954b9dd761/Lib/venv/__init__.py#L248)

This is of course fine when the original location of the Python interpreter is something like `/usr/bin/python3.9`, but when using pyenv it's a path containing the full version such as `/home/USER/.pyenv/versions/3.9.2/bin/python`, which makes in-place updates of minor Python versions harder than needed (manual update of the symlink needed).

IfF you agree that this change makes sense, I wouldn't mind sending a PR for this...

----------
components: Library (Lib)
messages: 388840
nosy: ThiefMaster
priority: normal
severity: normal
status: open
title: venv: recreate symlinks on --upgrade
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43513>
_______________________________________

From report at bugs.python.org  Tue Mar 16 10:41:07 2021
From: report at bugs.python.org (Frank Ueberschar)
Date: Tue, 16 Mar 2021 14:41:07 +0000
Subject: [issue43514] Disallow fork in a subinterpreter affects
 multiprocessing plugin
Message-ID: <1615905667.88.0.462528885021.issue43514@roundup.psfhosted.org>


New submission from Frank Ueberschar <fueb at gmx.net>:

Related to this issue https://bugs.python.org/issue34651, our Bareos libcloud plugin cannot be run with Python > 3.7. We are using subprocesses in a C-subinterpreter environment. 

Is there a way to circumvent rewriting our code completely?

----------
components: C API
messages: 388841
nosy: franku
priority: normal
severity: normal
status: open
title: Disallow fork in a subinterpreter affects multiprocessing plugin
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43514>
_______________________________________

From report at bugs.python.org  Tue Mar 16 10:47:35 2021
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 16 Mar 2021 14:47:35 +0000
Subject: [issue43514] Disallow fork in a subinterpreter affects
 multiprocessing plugin
In-Reply-To: <1615905667.88.0.462528885021.issue43514@roundup.psfhosted.org>
Message-ID: <1615906055.19.0.689158054555.issue43514@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Could you please post the error message and either post a minimal example or give us a link to your code?

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43514>
_______________________________________

From report at bugs.python.org  Tue Mar 16 10:49:19 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Mar 2021 14:49:19 +0000
Subject: [issue32596] Lazy import concurrent.futures.process and thread
In-Reply-To: <1516359250.47.0.467229070634.issue32596@psf.upfronthosting.co.za>
Message-ID: <1615906159.71.0.457776689896.issue32596@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't think this was a good idea. Making some imports implicitly lazy introduces unpredictability in stdlib imports. Here is an example bug report:
https://issues.apache.org/jira/browse/ARROW-11983

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32596>
_______________________________________

From report at bugs.python.org  Tue Mar 16 10:58:40 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Mar 2021 14:58:40 +0000
Subject: [issue43515] Lazy import in concurrent.futures produces partial
 import errors
Message-ID: <1615906720.22.0.921219635478.issue43515@roundup.psfhosted.org>


New submission from Antoine Pitrou <pitrou at free.fr>:

Here is a reproducer script:
https://gist.github.com/pitrou/a73fa2cfce2557e0dd435353b9976972

With Python 3.6 it works fine.

----------
components: Library (Lib)
messages: 388844
nosy: methane, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Lazy import in concurrent.futures produces partial import errors
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43515>
_______________________________________

From report at bugs.python.org  Tue Mar 16 11:18:47 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Mar 2021 15:18:47 +0000
Subject: [issue43515] Lazy import in concurrent.futures produces partial
 import errors
In-Reply-To: <1615906720.22.0.921219635478.issue43515@roundup.psfhosted.org>
Message-ID: <1615907927.91.0.440473529296.issue43515@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

Bisecting actually points to issue35943.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43515>
_______________________________________

From report at bugs.python.org  Tue Mar 16 11:19:01 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Mar 2021 15:19:01 +0000
Subject: [issue43515] Lazy import in concurrent.futures produces partial
 import errors
In-Reply-To: <1615906720.22.0.921219635478.issue43515@roundup.psfhosted.org>
Message-ID: <1615907941.47.0.999953123314.issue43515@roundup.psfhosted.org>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
versions:  -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43515>
_______________________________________

From report at bugs.python.org  Tue Mar 16 11:22:29 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Mar 2021 15:22:29 +0000
Subject: [issue35943] PyImport_GetModule() can return partially-initialized
 module
In-Reply-To: <1549646017.22.0.395154635441.issue35943@roundup.psfhosted.org>
Message-ID: <1615908149.28.0.0325109095928.issue35943@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

Note the conjunction of this change + issue32596 produces import fragility:
https://bugs.python.org/issue43515

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35943>
_______________________________________

From report at bugs.python.org  Tue Mar 16 11:27:34 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Mar 2021 15:27:34 +0000
Subject: [issue35943] PyImport_GetModule() can return partially-initialized
 module
In-Reply-To: <1549646017.22.0.395154635441.issue35943@roundup.psfhosted.org>
Message-ID: <1615908454.5.0.421602892662.issue35943@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, going through other open issues including on third-party projects, I think these changes should unfortunately be reverted.  The regressions produced are far from trivial and most developers seem at a loss how to fix them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35943>
_______________________________________

From report at bugs.python.org  Tue Mar 16 11:38:45 2021
From: report at bugs.python.org (Eric Snow)
Date: Tue, 16 Mar 2021 15:38:45 +0000
Subject: [issue43503] [subinterpreters] PyObject statics exposed in the
 limited API break isolation.
In-Reply-To: <1615834423.72.0.113211272847.issue43503@roundup.psfhosted.org>
Message-ID: <1615909125.76.0.457697834307.issue43503@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

One simple solution is to explicitly state that the limited API does not support subinterpreters.  This is already implied by the fact that the multi-phase init API (PEP 489) requires subinterpreter support but is not part of the limited API.

If we establish this constraint then the problem I originally described here goes away (and we can close this issue).

(Note: I'm pretty sure this is something someone suggested to me at some point, rather than my own idea.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43503>
_______________________________________

From report at bugs.python.org  Tue Mar 16 11:43:20 2021
From: report at bugs.python.org (miss-islington)
Date: Tue, 16 Mar 2021 15:43:20 +0000
Subject: [issue41654] Segfault when raising MemoryError
In-Reply-To: <1598609759.16.0.336877665683.issue41654@roundup.psfhosted.org>
Message-ID: <1615909400.27.0.335029856506.issue41654@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: +23656
pull_request: https://github.com/python/cpython/pull/24894

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41654>
_______________________________________

From report at bugs.python.org  Tue Mar 16 11:43:44 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Mar 2021 15:43:44 +0000
Subject: [issue35943] PyImport_GetModule() can return partially-initialized
 module
In-Reply-To: <1549646017.22.0.395154635441.issue35943@roundup.psfhosted.org>
Message-ID: <1615909424.99.0.18229519609.issue35943@roundup.psfhosted.org>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
resolution: fixed -> 
stage: resolved -> needs patch
status: closed -> open
versions: +Python 3.10, Python 3.9 -Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35943>
_______________________________________

From report at bugs.python.org  Tue Mar 16 11:44:10 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Mar 2021 15:44:10 +0000
Subject: [issue35943] PyImport_GetModule() can return partially-initialized
 module
In-Reply-To: <1549646017.22.0.395154635441.issue35943@roundup.psfhosted.org>
Message-ID: <1615909450.02.0.683450931599.issue35943@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

After analysis, it may not need reversal.  There is a simple logic error it seems.  Will check.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35943>
_______________________________________

From report at bugs.python.org  Tue Mar 16 11:50:02 2021
From: report at bugs.python.org (Yann Enoti)
Date: Tue, 16 Mar 2021 15:50:02 +0000
Subject: [issue43516] python on raspberry pi
Message-ID: <1615909802.06.0.398723617988.issue43516@roundup.psfhosted.org>


New submission from Yann Enoti <gyenoti at gmail.com>:

Any idea why this doesnt work ?


import socket

HOST = "192.168.2.114"
PORT = 8000 #initiate port no above 1024

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
print('Socket created')

#try:
s.bind((HOST, PORT))  #bind host address and port together#
#except socket.error as e:
    #print('Bind failed.')
    
s.listen(10)  #configure how many clients the server can listen to simultaneously

print("Socket is Listening")
 
#conn, addr = s.accept()    #accept new connection
#print("connection from:" + str(addr))
    

while True:
    conn, addr = s.accept()    #accept new connection
    print("connection from:" + str(addr))
    
    data = conn.recv(1024).decode()  #receive data stream
    
    #if not data: #if data is not received break
           # break
    print("from Android App:" + str(data))
    data = input ('from Python Server:')
    conn.send(data.encode())  #send data to client
    conn.close()  #close the connection

----------
components: Build
messages: 388850
nosy: gyenoti
priority: normal
severity: normal
status: open
title: python on raspberry pi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43516>
_______________________________________

From report at bugs.python.org  Tue Mar 16 11:50:49 2021
From: report at bugs.python.org (Ammar Askar)
Date: Tue, 16 Mar 2021 15:50:49 +0000
Subject: [issue43499] Compiler warnings in building Python 3.9 on Windows
In-Reply-To: <1615810323.65.0.00918597187884.issue43499@roundup.psfhosted.org>
Message-ID: <1615909849.65.0.393527876932.issue43499@roundup.psfhosted.org>


Change by Ammar Askar <ammar at ammaraskar.com>:


----------
nosy: +ammar2
nosy_count: 1.0 -> 2.0
pull_requests: +23657
pull_request: https://github.com/python/cpython/pull/20628

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43499>
_______________________________________

From report at bugs.python.org  Tue Mar 16 11:53:44 2021
From: report at bugs.python.org (Ammar Askar)
Date: Tue, 16 Mar 2021 15:53:44 +0000
Subject: [issue43499] Compiler warnings in building Python 3.9 on Windows
In-Reply-To: <1615810323.65.0.00918597187884.issue43499@roundup.psfhosted.org>
Message-ID: <1615910024.36.0.136842739576.issue43499@roundup.psfhosted.org>


Change by Ammar Askar <ammar at ammaraskar.com>:


----------
pull_requests: +23658
pull_request: https://github.com/python/cpython/pull/20508

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43499>
_______________________________________

From report at bugs.python.org  Tue Mar 16 11:55:08 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Mar 2021 15:55:08 +0000
Subject: [issue43499] Compiler warnings in building Python 3.9 on Windows
In-Reply-To: <1615810323.65.0.00918597187884.issue43499@roundup.psfhosted.org>
Message-ID: <1615910108.23.0.463916120893.issue43499@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +vstinner
nosy_count: 2.0 -> 3.0
pull_requests: +23659
pull_request: https://github.com/python/cpython/pull/22387

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43499>
_______________________________________

From report at bugs.python.org  Tue Mar 16 12:01:31 2021
From: report at bugs.python.org (Ken Jin)
Date: Tue, 16 Mar 2021 16:01:31 +0000
Subject: [issue43512] Bug in isinstance(instance,
 cls) with cls being a protocol? (PEP 544)
In-Reply-To: <1615888944.07.0.094574416265.issue43512@roundup.psfhosted.org>
Message-ID: <1615910491.5.0.449377581696.issue43512@roundup.psfhosted.org>


Ken Jin <kenjin4096 at gmail.com> added the comment:

Apologies if I misunderstood something, but doesn't PEP 544 also state in its "Rationale", "Non-goals" subsection that

"""
At runtime, protocol classes will be simple ABCs. There is no intent to provide sophisticated runtime instance and class checks against protocol classes. This would be difficult and error-prone and will contradict the logic of PEP 484.
"""

https://www.python.org/dev/peps/pep-0544/#non-goals

Which means that the Python runtime isn't supposed to check that, instead it's the static type checker's responsibility?

----------
nosy: +gvanrossum, kj, levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43512>
_______________________________________

From report at bugs.python.org  Tue Mar 16 12:07:50 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Mar 2021 16:07:50 +0000
Subject: [issue43517] Fix false positives in circular import detection with
 from-imports
Message-ID: <1615910870.21.0.167533445549.issue43517@roundup.psfhosted.org>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
assignee: pitrou
components: Library (Lib)
nosy: pitrou
priority: deferred blocker
severity: normal
stage: needs patch
status: open
title: Fix false positives in circular import detection with from-imports
type: behavior
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43517>
_______________________________________

From report at bugs.python.org  Tue Mar 16 12:09:59 2021
From: report at bugs.python.org (Chris Morton)
Date: Tue, 16 Mar 2021 16:09:59 +0000
Subject: [issue43481] PyEval_EvalCode() namespace issue not observed in Python
 2.7.
In-Reply-To: <1615585477.01.0.106665214672.issue43481@roundup.psfhosted.org>
Message-ID: <1615910999.65.0.933457755521.issue43481@roundup.psfhosted.org>


Chris Morton <chrisgmorton at yahoo.com> added the comment:

Root cause appears to be indexing c with [] operator. Replacing len(c) with 4 produces the same error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43481>
_______________________________________

From report at bugs.python.org  Tue Mar 16 12:10:20 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 16 Mar 2021 16:10:20 +0000
Subject: [issue43516] python on raspberry pi
In-Reply-To: <1615909802.06.0.398723617988.issue43516@roundup.psfhosted.org>
Message-ID: <1615911020.18.0.885851984732.issue43516@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

You?ve not told us the behavior you see or the behavior you expect, so we can?t tell if this is a bug in python. 

But it?s in all likelihood not a bug. If you want to get help with your code, I suggest asking on the python-list mailing list or maybe Stackoverflow. This bug tracker is not a support forum. 

https://mail.python.org/mailman/listinfo/python-list

----------
nosy: +eric.smith
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43516>
_______________________________________

From report at bugs.python.org  Tue Mar 16 12:11:03 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Mar 2021 16:11:03 +0000
Subject: [issue43517] Fix false positives in circular import detection with
 from-imports
Message-ID: <1615911063.74.0.357076415367.issue43517@roundup.psfhosted.org>


New submission from Antoine Pitrou <pitrou at free.fr>:

This seems to be caused by a logic error in the patch for issue35943.

It has been causing multiple issues for multi-threaded and multi-process systems written in Python:
* issue41567
* issue43515
* https://github.com/dask/distributed/issues/4168

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43517>
_______________________________________

From report at bugs.python.org  Tue Mar 16 12:14:45 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 16 Mar 2021 16:14:45 +0000
Subject: [issue43499] Compiler warnings in building Python 3.9 on Windows
In-Reply-To: <1615810323.65.0.00918597187884.issue43499@roundup.psfhosted.org>
Message-ID: <1615911285.17.0.987994877797.issue43499@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Ammar Askar, do you mind to backport PR 20628 to 3.9? It is the only warning left, and it seems there is a potential bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43499>
_______________________________________

From report at bugs.python.org  Tue Mar 16 12:15:12 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Mar 2021 16:15:12 +0000
Subject: [issue43517] Fix false positives in circular import detection with
 from-imports
In-Reply-To: <1615911063.74.0.357076415367.issue43517@roundup.psfhosted.org>
Message-ID: <1615911312.28.0.0991482886167.issue43517@roundup.psfhosted.org>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
keywords: +patch
pull_requests: +23660
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/24895

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43517>
_______________________________________

From report at bugs.python.org  Tue Mar 16 12:15:34 2021
From: report at bugs.python.org (Ammar Askar)
Date: Tue, 16 Mar 2021 16:15:34 +0000
Subject: [issue43499] Compiler warnings in building Python 3.9 on Windows
In-Reply-To: <1615810323.65.0.00918597187884.issue43499@roundup.psfhosted.org>
Message-ID: <1615911334.35.0.884564477551.issue43499@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Sure thing, I'll work on the backport.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43499>
_______________________________________

From report at bugs.python.org  Tue Mar 16 12:16:54 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Mar 2021 16:16:54 +0000
Subject: [issue41567] multiprocessing.Pool from concurrent threads failure on
 3.9.0rc1
In-Reply-To: <1597664250.53.0.724586569237.issue41567@roundup.psfhosted.org>
Message-ID: <1615911414.9.0.306448193332.issue41567@roundup.psfhosted.org>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Fix false positives in circular import detection with from-imports

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41567>
_______________________________________

From report at bugs.python.org  Tue Mar 16 12:17:16 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Mar 2021 16:17:16 +0000
Subject: [issue43515] Lazy import in concurrent.futures produces partial
 import errors
In-Reply-To: <1615906720.22.0.921219635478.issue43515@roundup.psfhosted.org>
Message-ID: <1615911436.76.0.13431066567.issue43515@roundup.psfhosted.org>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> Fix false positives in circular import detection with from-imports

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43515>
_______________________________________

From report at bugs.python.org  Tue Mar 16 12:17:49 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Mar 2021 16:17:49 +0000
Subject: [issue35943] PyImport_GetModule() can return partially-initialized
 module
In-Reply-To: <1549646017.22.0.395154635441.issue35943@roundup.psfhosted.org>
Message-ID: <1615911469.86.0.687150228098.issue35943@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

Created a new issue + fix in issue43517.

----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35943>
_______________________________________

From report at bugs.python.org  Tue Mar 16 12:17:45 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 16 Mar 2021 16:17:45 +0000
Subject: [issue43517] Fix false positives in circular import detection with
 from-imports
In-Reply-To: <1615911063.74.0.357076415367.issue43517@roundup.psfhosted.org>
Message-ID: <1615911465.56.0.605638172765.issue43517@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +brett.cannon, eric.snow, nanjekyejoannah, ncoghlan, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43517>
_______________________________________

From report at bugs.python.org  Tue Mar 16 12:20:43 2021
From: report at bugs.python.org (annesylvie)
Date: Tue, 16 Mar 2021 16:20:43 +0000
Subject: [issue43518] textwrap.shorten does not always respect word boundaries
Message-ID: <1615911643.42.0.876166879751.issue43518@roundup.psfhosted.org>


Change by annesylvie <annesylviedeutsch at gmail.com>:


----------
components: Library (Lib)
nosy: annesylvie
priority: normal
severity: normal
status: open
title: textwrap.shorten does not always respect word boundaries
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43518>
_______________________________________

From report at bugs.python.org  Tue Mar 16 12:24:25 2021
From: report at bugs.python.org (annesylvie)
Date: Tue, 16 Mar 2021 16:24:25 +0000
Subject: [issue43518] textwrap.shorten does not always respect word boundaries
Message-ID: <1615911865.24.0.216349409983.issue43518@roundup.psfhosted.org>


New submission from annesylvie <annesylviedeutsch at gmail.com>:

The `shorten` function from the `textwrap` module does not always break strings at the correct location.

`shorten("hello world!", width=7, placeholder="")`
 returns
`'hello'`
as expected, but
`shorten("hello world!!!!!!", width=7, placeholder="")`
returns
`'hello w'`
which is incorrect. The error seems to appear when two or more exclamation marks (in this specific example) are added.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43518>
_______________________________________

From report at bugs.python.org  Tue Mar 16 12:26:29 2021
From: report at bugs.python.org (Ammar Askar)
Date: Tue, 16 Mar 2021 16:26:29 +0000
Subject: [issue43499] Compiler warnings in building Python 3.9 on Windows
In-Reply-To: <1615810323.65.0.00918597187884.issue43499@roundup.psfhosted.org>
Message-ID: <1615911989.8.0.974100344299.issue43499@roundup.psfhosted.org>


Change by Ammar Askar <ammar at ammaraskar.com>:


----------
pull_requests: +23661
pull_request: https://github.com/python/cpython/pull/24896

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43499>
_______________________________________

From report at bugs.python.org  Tue Mar 16 12:42:55 2021
From: report at bugs.python.org (Eric Snow)
Date: Tue, 16 Mar 2021 16:42:55 +0000
Subject: [issue43503] [subinterpreters] PyObject statics exposed in the
 limited API break isolation.
In-Reply-To: <1615834423.72.0.113211272847.issue43503@roundup.psfhosted.org>
Message-ID: <1615912975.26.0.402794306958.issue43503@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

FYI, I posted to capi-sig about this:

https://mail.python.org/archives/list/capi-sig at python.org/thread/INLCGPMTYFLRTWQL7RB4MUQZ37JAFRAU/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43503>
_______________________________________

From report at bugs.python.org  Tue Mar 16 13:06:36 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 16 Mar 2021 17:06:36 +0000
Subject: [issue43512] Bug in isinstance(instance,
 cls) with cls being a protocol? (PEP 544)
In-Reply-To: <1615888944.07.0.094574416265.issue43512@roundup.psfhosted.org>
Message-ID: <1615914396.67.0.843116875709.issue43512@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Yeah, the runtime isinstance() checking is not required to give the right answer. Also, I believe one of the rules is "if you inherit from a protocol you are deemed to implement it". For methods, abstract methods can (but needn't) be used to indicate mandatory features. For attributes, there is no guarantee.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43512>
_______________________________________

From report at bugs.python.org  Tue Mar 16 13:12:48 2021
From: report at bugs.python.org (mattip)
Date: Tue, 16 Mar 2021 17:12:48 +0000
Subject: [issue43503] [subinterpreters] PyObject statics exposed in the
 limited API break isolation.
In-Reply-To: <1615834423.72.0.113211272847.issue43503@roundup.psfhosted.org>
Message-ID: <1615914768.56.0.414309354076.issue43503@roundup.psfhosted.org>


mattip <matti.picus at gmail.com> added the comment:

I am confused. How can widening the usable number of functions (i.e. using the whole C-API rather than the limited API) help c-extension modules be usable in subinterpreters? Aren't the same singletons, exception types, and other types exposed in the full C-API?

----------
nosy: +mattip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43503>
_______________________________________

From report at bugs.python.org  Tue Mar 16 13:20:30 2021
From: report at bugs.python.org (David Elmakias)
Date: Tue, 16 Mar 2021 17:20:30 +0000
Subject: [issue43519] access python private variable
Message-ID: <1615915230.85.0.466298087541.issue43519@roundup.psfhosted.org>


New submission from David Elmakias <marko9387 at gmail.com>:

It might be my lack of knowledge in python, however I find this behavior a bit strange.

By declaring a private variable in a class, python creates an attribute with the name '_<ClassName>__<PrivateVariableName>'.
Both are located on a different location in memory.

I found that by assigning data to the created variable with the exact name/notation '_<ClassName>__<PrivateVariableName>' I changed the private variable data.

----------
components: Build
files: access_class_private_variable.py
messages: 388862
nosy: AluminumPirate
priority: normal
severity: normal
status: open
title: access python private variable
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file49878/access_class_private_variable.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43519>
_______________________________________

From report at bugs.python.org  Tue Mar 16 13:36:50 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Mar 2021 17:36:50 +0000
Subject: [issue41654] Segfault when raising MemoryError
In-Reply-To: <1598609759.16.0.336877665683.issue41654@roundup.psfhosted.org>
Message-ID: <1615916210.85.0.66857108972.issue41654@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 1f0cde678406749524d11e852a16bf243cef5c5f by Miss Islington (bot) in branch '3.9':
bpo-41654: Fix compiler warning in MemoryError_dealloc() (GH-22387) (GH-24894)
https://github.com/python/cpython/commit/1f0cde678406749524d11e852a16bf243cef5c5f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41654>
_______________________________________

From report at bugs.python.org  Tue Mar 16 13:45:04 2021
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 16 Mar 2021 17:45:04 +0000
Subject: [issue43519] access python private variable
In-Reply-To: <1615915230.85.0.466298087541.issue43519@roundup.psfhosted.org>
Message-ID: <1615916704.13.0.553853846352.issue43519@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

This is not a bug, it is working as intended.

Python does not really support "private" attributes, except by convention. Names that begin with a single leading underscore are no different than any other name to the interpreter, but the reader is expected to not touch it.

Double-underscore names are no different, except that they have their names mangled so that subclasses can have their own version of the attribute that doesn't clash with that of the parent class.

Most people find that the double-underscore attributes are not worth the trouble. However you may like to read this:

https://www.python.org/dev/peps/pep-0008/#id49


By the way, attributes and variables in Python don't have fixed memory addresses. Whatever you did to make you think that:

"Both are located on a different location in memory."

you have misinterpreted what you are seeing.

There is no language feature to get the memory address of any object or variable in Python, except perhaps as an accident of implementation. And some interpreters include compacting garbage collectors that can move objects around memory.

----------
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43519>
_______________________________________

From report at bugs.python.org  Tue Mar 16 14:09:04 2021
From: report at bugs.python.org (Carl Anderson)
Date: Tue, 16 Mar 2021 18:09:04 +0000
Subject: [issue43520] Fraction only handles regular slashes ("/") and fails
 with other similar slashes
Message-ID: <1615918144.03.0.939769511159.issue43520@roundup.psfhosted.org>


New submission from Carl Anderson <carl.anderson at ww.com>:

Fraction works with a regular slash:

>>> from fractions import Fraction
>>> Fraction("1/2")
Fraction(1, 2)

but there are other similar slashes such as (0x2044) in which it throws an error:

>>> Fraction("0?2")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/anaconda3/lib/python3.7/fractions.py", line 138, in __new__
    numerator)
ValueError: Invalid literal for Fraction: '0?2'


This seems to come from the (?:/(?P<denom>\d+))? section of the regex _RATIONAL_FORMAT in fractions.py

----------
components: Library (Lib)
messages: 388865
nosy: weightwatchers-carlanderson
priority: normal
severity: normal
status: open
title: Fraction only handles regular slashes ("/") and fails with other similar slashes
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43520>
_______________________________________

From report at bugs.python.org  Tue Mar 16 14:50:29 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 16 Mar 2021 18:50:29 +0000
Subject: [issue43520] Fraction only handles regular slashes ("/") and fails
 with other similar slashes
In-Reply-To: <1615918144.03.0.939769511159.issue43520@roundup.psfhosted.org>
Message-ID: <1615920629.69.0.967129102416.issue43520@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

There's a bigger issue here about what characters should be accepted in numeric literals. The Unicode minus sign (U+2212) "?" is also not currently accepted for Fractions or any other built-in numeric type.

> but there are other similar slashes such as (0x2044) in which it throws an error

Do you have a proposal for the set of slashes that should be accepted, or a non-arbitrary rule for determining that set?  U+2044 (FRACTION SLASH), U+2215 (DIVISION SLASH) and U+FF0F (FULLWIDTH SOLIDUS) all seem like potential candidates. Are there others?

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43520>
_______________________________________

From report at bugs.python.org  Tue Mar 16 14:54:43 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 16 Mar 2021 18:54:43 +0000
Subject: [issue43520] Fraction only handles regular slashes ("/") and fails
 with other similar slashes
In-Reply-To: <1615918144.03.0.939769511159.issue43520@roundup.psfhosted.org>
Message-ID: <1615920883.97.0.00531890123635.issue43520@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Seems worth noting that Unicode fractions like ? produce a FRACTION SLASH character when normalized:

>>> unicodedata.normalize('NFKC', '?')
'2?3'
>>> list(map(unicodedata.name, unicodedata.normalize('NFKC', '?')))
['DIGIT TWO', 'FRACTION SLASH', 'DIGIT THREE']

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43520>
_______________________________________

From report at bugs.python.org  Tue Mar 16 14:56:12 2021
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 16 Mar 2021 18:56:12 +0000
Subject: [issue43284] Inability to fetch build 20H2
In-Reply-To: <1613904146.72.0.850542213327.issue43284@roundup.psfhosted.org>
Message-ID: <1615920972.41.0.518435560569.issue43284@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

Note that the following recommendation for getting the system version was removed in late 2019 [1][2]:

    To obtain the full version number for the operating system,
    call the GetFileVersionInfo function on one of the system
    DLLs, such as Kernel32.dll, then call VerQueryValue to obtain
    the \\StringFileInfo\\\\ProductVersion subblock of the file 
    version information.

The first commit added advice to check the "CurrentBuildNumber" registry value in Windows 10 1909+, but an engineer decided to just remove the paragraph. Apparently the developers do not want to guarantee that the version information on any particular system DLL can be used to get the system version. Apparently they also do not want to officially sanction using the "CurrentMajorVersionNumber", "CurrentMinorVersionNumber", and  "CurrentBuildNumber" values in the registry.

---

[1] https://github.com/MicrosoftDocs/win32/pull/143
[2] https://docs.microsoft.com/en-us/windows/win32/sysinfo/getting-the-system-version

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43284>
_______________________________________

From report at bugs.python.org  Tue Mar 16 15:04:47 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 16 Mar 2021 19:04:47 +0000
Subject: [issue43520] Fraction only handles regular slashes ("/") and fails
 with other similar slashes
In-Reply-To: <1615918144.03.0.939769511159.issue43520@roundup.psfhosted.org>
Message-ID: <1615921487.84.0.901717143228.issue43520@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Related: #6632

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43520>
_______________________________________

From report at bugs.python.org  Tue Mar 16 15:25:49 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Tue, 16 Mar 2021 19:25:49 +0000
Subject: [issue43502] [C-API] Convert obvious unsafe macros to static inline
 functions
In-Reply-To: <1615816484.12.0.00251754107838.issue43502@roundup.psfhosted.org>
Message-ID: <1615922749.26.0.986651149983.issue43502@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

PyUnicode_WRITE, PyUnicode_READ, and PyUnicode_READ_CHAR all reuse their arguments, and there's a lot of occurrences (58 AFAICS) where they are called with the increment operator applied to the index argument. For example:

Objects/unicodeobject.c:            PyUnicode_WRITE(kind, data, pos++, ch);
Modules/_io/textio.c:               c = PyUnicode_READ(kind, in_str, i++);
Objects/stringlib/unicode_format.h: c = PyUnicode_READ_CHAR(self->str.str, self->index++);


Would a single PR for all three of them be acceptable, Victor?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43502>
_______________________________________

From report at bugs.python.org  Tue Mar 16 15:28:28 2021
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 16 Mar 2021 19:28:28 +0000
Subject: [issue43503] [subinterpreters] PyObject statics exposed in the
 limited API break isolation.
In-Reply-To: <1615834423.72.0.113211272847.issue43503@roundup.psfhosted.org>
Message-ID: <1615922908.35.0.547603443565.issue43503@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

There seems to be much confusion here. Maybe on my side?

PEP 489 is *very much* part of the limited API.

----------
nosy: +petr.viktorin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43503>
_______________________________________

From report at bugs.python.org  Tue Mar 16 15:39:06 2021
From: report at bugs.python.org (Kodiologist)
Date: Tue, 16 Mar 2021 19:39:06 +0000
Subject: [issue43521] Allow `ast.unparse` to handle NaNs and empty sets
Message-ID: <1615923546.68.0.291337558212.issue43521@roundup.psfhosted.org>


New submission from Kodiologist <nonce0010lep at arfer.net>:

`ast.unparse` throws an error on an empty set, and it produces `nan` for NaN, which isn't a legal Python literal.

PR to follow shortly.

----------
messages: 388872
nosy: Kodiologist
priority: normal
severity: normal
status: open
title: Allow `ast.unparse` to handle NaNs and empty sets
type: enhancement
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43521>
_______________________________________

From report at bugs.python.org  Tue Mar 16 15:41:11 2021
From: report at bugs.python.org (Kodiologist)
Date: Tue, 16 Mar 2021 19:41:11 +0000
Subject: [issue43521] Allow `ast.unparse` to handle NaNs and empty sets
In-Reply-To: <1615923546.68.0.291337558212.issue43521@roundup.psfhosted.org>
Message-ID: <1615923671.73.0.859290604361.issue43521@roundup.psfhosted.org>


Change by Kodiologist <nonce0010lep at arfer.net>:


----------
keywords: +patch
pull_requests: +23662
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24897

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43521>
_______________________________________

From report at bugs.python.org  Tue Mar 16 15:47:59 2021
From: report at bugs.python.org (Batuhan Taskaya)
Date: Tue, 16 Mar 2021 19:47:59 +0000
Subject: [issue43521] Allow `ast.unparse` to handle NaNs and empty sets
In-Reply-To: <1615923546.68.0.291337558212.issue43521@roundup.psfhosted.org>
Message-ID: <1615924079.82.0.0811715685586.issue43521@roundup.psfhosted.org>


Change by Batuhan Taskaya <isidentical at gmail.com>:


----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43521>
_______________________________________

From report at bugs.python.org  Tue Mar 16 15:51:34 2021
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 16 Mar 2021 19:51:34 +0000
Subject: [issue43477] from x import * behavior inconsistent between module
 types.
In-Reply-To: <1615509638.08.0.549124406797.issue43477@roundup.psfhosted.org>
Message-ID: <1615924294.93.0.623381834218.issue43477@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Thanks for the clarification! I think I understand what's going on now, and the logic is actually expected.

When you do `from .test_submodule import *`, Python must first import `test_pkg.test_submodule` in order to get you the object for the `import *` part (or frankly anything that comes after `import`). As part of importing `test_pkg.test_submodule`, it automatically gets attached to `test_pkg`, otherwise we wouldn't be able to cache the module in `sys.modules` and prevent redundant/duplicate imports.

As such, when you do `import test_pkg` in`test.py`, the fact that `test_pkg.__init__` has to import `test_pkg.test_submodule` means `test_pkg will automatically end up with a `test_submodule` attribute. That's why your `print()` function call succeeds.

If I'm still misunderstanding, can you please use an `assert` statement that fails because the logic doesn't work the way you expect it to be?

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43477>
_______________________________________

From report at bugs.python.org  Tue Mar 16 15:54:47 2021
From: report at bugs.python.org (Batuhan Taskaya)
Date: Tue, 16 Mar 2021 19:54:47 +0000
Subject: [issue43521] Allow `ast.unparse` to handle NaNs and empty sets
In-Reply-To: <1615923546.68.0.291337558212.issue43521@roundup.psfhosted.org>
Message-ID: <1615924487.54.0.183141877904.issue43521@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:

The reason that we weren't support these cases was there were simply no way achieve them by parsing code so we simply ignored (empty sets etc). Though considering that you have a decent use case in hy, I'd agree that these small additions are viable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43521>
_______________________________________

From report at bugs.python.org  Tue Mar 16 16:07:50 2021
From: report at bugs.python.org (Quentin Pradet)
Date: Tue, 16 Mar 2021 20:07:50 +0000
Subject: [issue43522] SSLContext.hostname_checks_common_name appears to have
 no effect
Message-ID: <1615925270.47.0.272234983925.issue43522@roundup.psfhosted.org>


New submission from Quentin Pradet <quentin.pradet at gmail.com>:

urllib3 is preparing a v2 with various SSL improvements, such as leaning on the ssl module to match hostnames when possible and reject certificates without a SAN. See https://urllib3.readthedocs.io/en/latest/v2-roadmap.html#modern-security-by-default for more details.

For this reason, we want to set `hostname_checks_common_name` to False on Python 3.7+ and OpenSSL 1.1.0+. (In other cases, we use a modified version of `ssl.match_hostname` that does not consider common names.)

I would expect that setting `hostname_checks_common_name` to False would rejects certificates without SANs, but that does not appear to be the case. I used the following Python code:

    import socket
    import ssl
    
    print(ssl.OPENSSL_VERSION)
    hostname = 'localhost'
    context = ssl.create_default_context()
    context.load_verify_locations("client.pem")
    context.hostname_checks_common_name = False
    
    with socket.create_connection((hostname, 8000)) as sock:
        with context.wrap_socket(sock, server_hostname=hostname) as ssock:
                assert "subjectAltName" not in ssock.getpeercert()


which prints `OpenSSL 1.1.1i  8 Dec 2020` and does not fail as expected. I'm testing this on macOS 11.2.2 but this currently breaks our test suite on Ubuntu, Windows and macOS, including on Python 3.10, see https://github.com/urllib3/urllib3/runs/2122811894?check_suite_focus=true.

To reproduce this, I used trustme (https://trustme.readthedocs.io/en/latest/). I modified the code to not include a SAN at all and ran `gunicorn --keyfile server.key --certfile server.pem app:app`, with app being the Flask quickstart application. I'll try to attach all those files if I manage to do it.

What am I missing?

----------
assignee: christian.heimes
components: SSL
files: no_san_ignored.py
messages: 388875
nosy: Quentin.Pradet, christian.heimes
priority: normal
severity: normal
status: open
title: SSLContext.hostname_checks_common_name appears to have no effect
versions: Python 3.10
Added file: https://bugs.python.org/file49879/no_san_ignored.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43522>
_______________________________________

From report at bugs.python.org  Tue Mar 16 16:08:13 2021
From: report at bugs.python.org (Quentin Pradet)
Date: Tue, 16 Mar 2021 20:08:13 +0000
Subject: [issue43522] SSLContext.hostname_checks_common_name appears to have
 no effect
In-Reply-To: <1615925270.47.0.272234983925.issue43522@roundup.psfhosted.org>
Message-ID: <1615925293.84.0.0464915039447.issue43522@roundup.psfhosted.org>


Change by Quentin Pradet <quentin.pradet at gmail.com>:


Added file: https://bugs.python.org/file49880/app.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43522>
_______________________________________

From report at bugs.python.org  Tue Mar 16 16:08:43 2021
From: report at bugs.python.org (Quentin Pradet)
Date: Tue, 16 Mar 2021 20:08:43 +0000
Subject: [issue43522] SSLContext.hostname_checks_common_name appears to have
 no effect
In-Reply-To: <1615925270.47.0.272234983925.issue43522@roundup.psfhosted.org>
Message-ID: <1615925323.86.0.972626044413.issue43522@roundup.psfhosted.org>


Change by Quentin Pradet <quentin.pradet at gmail.com>:


Added file: https://bugs.python.org/file49882/server.pem

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43522>
_______________________________________

From report at bugs.python.org  Tue Mar 16 16:08:32 2021
From: report at bugs.python.org (Quentin Pradet)
Date: Tue, 16 Mar 2021 20:08:32 +0000
Subject: [issue43522] SSLContext.hostname_checks_common_name appears to have
 no effect
In-Reply-To: <1615925270.47.0.272234983925.issue43522@roundup.psfhosted.org>
Message-ID: <1615925312.44.0.998872176033.issue43522@roundup.psfhosted.org>


Change by Quentin Pradet <quentin.pradet at gmail.com>:


Added file: https://bugs.python.org/file49881/client.pem

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43522>
_______________________________________

From report at bugs.python.org  Tue Mar 16 16:09:00 2021
From: report at bugs.python.org (Quentin Pradet)
Date: Tue, 16 Mar 2021 20:09:00 +0000
Subject: [issue43522] SSLContext.hostname_checks_common_name appears to have
 no effect
In-Reply-To: <1615925270.47.0.272234983925.issue43522@roundup.psfhosted.org>
Message-ID: <1615925340.5.0.572534594047.issue43522@roundup.psfhosted.org>


Change by Quentin Pradet <quentin.pradet at gmail.com>:


Added file: https://bugs.python.org/file49883/server.key

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43522>
_______________________________________

From report at bugs.python.org  Tue Mar 16 16:17:22 2021
From: report at bugs.python.org (Frank Ueberschar)
Date: Tue, 16 Mar 2021 20:17:22 +0000
Subject: [issue43514] Disallow fork in a subinterpreter affects
 multiprocessing plugin
In-Reply-To: <1615905667.88.0.462528885021.issue43514@roundup.psfhosted.org>
Message-ID: <1615925842.81.0.503565524097.issue43514@roundup.psfhosted.org>


Frank Ueberschar <fueb at gmx.net> added the comment:

Here is part of the gdb backtrace:

[franku at franku py3plug-fd-libcloud]$ sbin/bareos_fd-py3plug-fd-libcloud -f -c etc/bareos       
Fatal Python error: _PyInterpreterState_DeleteExceptMain: not main interpreter
Python runtime state: initialized

Current thread 0x00007f0dc2ab7640 (most recent call first):
  File "/usr/lib64/python3.9/multiprocessing/popen_fork.py", line 66 in _launch
  File "/usr/lib64/python3.9/multiprocessing/popen_fork.py", line 19 in __init__
  File "/usr/lib64/python3.9/multiprocessing/context.py", line 277 in _Popen
  File "/usr/lib64/python3.9/multiprocessing/context.py", line 224 in _Popen
  File "/usr/lib64/python3.9/multiprocessing/process.py", line 121 in start
  File "/home/franku/git/bareos/master/core/src/plugins/filed/python/libcloud/BareosLibcloudApi.py", line 102 in __init__
  File "/home/franku/git/bareos/master/core/src/plugins/filed/python/libcloud/BareosFdPluginLibcloud.py", line 267 in start_backup_job
  File "/home/franku/git/bareos/master/core/src/plugins/filed/python/pyfiles/BareosFdPluginBaseclass.py", line 285 in handle_plugin_event
  File "/home/franku/git/bareos/master/core/src/plugins/filed/python/pyfiles/BareosFdWrapper.py", line 38 in handle_plugin_event
Fatal Python error: _PyInterpreterState_DeleteExceptMain: not main interpreter
Python runtime state: initialized

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43514>
_______________________________________

From report at bugs.python.org  Tue Mar 16 16:32:38 2021
From: report at bugs.python.org (Frank Ueberschar)
Date: Tue, 16 Mar 2021 20:32:38 +0000
Subject: [issue43514] Disallow fork in a subinterpreter affects
 multiprocessing plugin
In-Reply-To: <1615905667.88.0.462528885021.issue43514@roundup.psfhosted.org>
Message-ID: <1615926758.82.0.458813811128.issue43514@roundup.psfhosted.org>


Frank Ueberschar <fueb at gmx.net> added the comment:

Initialization of the Python interpreter in C-code is here: 
https://github.com/bareos/bareos/blob/fb76608092ba204ce43cd7c262619e01f9d6a2d6/core/src/plugins/filed/python/python-fd.cc#L189

The actual Python code that starts the child processes is here:
https://github.com/bareos/bareos/blob/fb76608092ba204ce43cd7c262619e01f9d6a2d6/core/src/plugins/filed/python/libcloud/BareosLibcloudApi.py#L110

Where this is one of the actual Processes: 
https://github.com/bareos/bareos/blob/fb76608092ba204ce43cd7c262619e01f9d6a2d6/core/src/plugins/filed/python/libcloud/bareos_libcloud_api/bucket_explorer.py#L45

Inherited from this base class: 
https://github.com/bareos/bareos/blob/fb76608092ba204ce43cd7c262619e01f9d6a2d6/core/src/plugins/filed/python/libcloud/bareos_libcloud_api/process_base.py#L36

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43514>
_______________________________________

From report at bugs.python.org  Tue Mar 16 16:44:24 2021
From: report at bugs.python.org (Matthew Suozzo)
Date: Tue, 16 Mar 2021 20:44:24 +0000
Subject: [issue43478] Disallow Mock spec arguments from being Mocks
In-Reply-To: <1615514023.14.0.0477922265442.issue43478@roundup.psfhosted.org>
Message-ID: <1615927464.6.0.77303160672.issue43478@roundup.psfhosted.org>


Matthew Suozzo <msuozzo at google.com> added the comment:

A few more things:

Assertions on Mock-autospec'ed Mocks will silently pass since e.g. assert_called_once_with will now be mocked out. This may justify a more stringent stance on the pattern since it risks hiding real test failures.

One complicating factor with the implementation is that autospec'd objects may have children that are already Mocked out. Failing eagerly, however, would break cases where the child is never used (and consequently risk causing more friction than may be necessary) but failing only upon access of that child makes it trickier for the user to trace back to where the parent was mocked.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43478>
_______________________________________

From report at bugs.python.org  Tue Mar 16 16:48:00 2021
From: report at bugs.python.org (Frank Ueberschar)
Date: Tue, 16 Mar 2021 20:48:00 +0000
Subject: [issue43514] Disallow fork in a subinterpreter affects
 multiprocessing plugin
In-Reply-To: <1615905667.88.0.462528885021.issue43514@roundup.psfhosted.org>
Message-ID: <1615927680.37.0.716981351867.issue43514@roundup.psfhosted.org>


Frank Ueberschar <fueb at gmx.net> added the comment:

These lines correspond (due to dirty working copy): 

File "/home/franku/git/bareos/master/core/src/plugins/filed/python/libcloud/BareosLibcloudApi.py", line 102 in __init__

The actual Python code that starts the child processes is here:
https://github.com/bareos/bareos/blob/fb76608092ba204ce43cd7c262619e01f9d6a2d6/core/src/plugins/filed/python/libcloud/BareosLibcloudApi.py#L110

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43514>
_______________________________________

From report at bugs.python.org  Tue Mar 16 16:49:38 2021
From: report at bugs.python.org (Matthew Suozzo)
Date: Tue, 16 Mar 2021 20:49:38 +0000
Subject: [issue43478] Disallow Mock spec arguments from being Mocks
In-Reply-To: <1615514023.14.0.0477922265442.issue43478@roundup.psfhosted.org>
Message-ID: <1615927778.27.0.512272669282.issue43478@roundup.psfhosted.org>


Matthew Suozzo <msuozzo at google.com> added the comment:

And to give some context for the above autospec child bit, this is the relevant code that determines the spec to use for each child: https://github.com/python/cpython/blob/master/Lib/unittest/mock.py#L2671-L2696

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43478>
_______________________________________

From report at bugs.python.org  Tue Mar 16 17:08:37 2021
From: report at bugs.python.org (Ned Deily)
Date: Tue, 16 Mar 2021 21:08:37 +0000
Subject: [issue43285] ftplib should not use the host from the PASV response
In-Reply-To: <1613908174.7.0.0578051462677.issue43285@roundup.psfhosted.org>
Message-ID: <1615928917.37.0.674053107919.issue43285@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 4134f154ae2f621f25c5d698cc0f1748035a1b88 by Miss Islington (bot) in branch '3.6':
[3.6] bpo-43285 Make ftplib not trust the PASV response. (GH-24838) (GH-24881) (GH-24882)
https://github.com/python/cpython/commit/4134f154ae2f621f25c5d698cc0f1748035a1b88


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43285>
_______________________________________

From report at bugs.python.org  Tue Mar 16 17:08:59 2021
From: report at bugs.python.org (Carl Anderson)
Date: Tue, 16 Mar 2021 21:08:59 +0000
Subject: [issue43520] Fraction only handles regular slashes ("/") and fails
 with other similar slashes
In-Reply-To: <1615918144.03.0.939769511159.issue43520@roundup.psfhosted.org>
Message-ID: <1615928939.82.0.6731368934.issue43520@roundup.psfhosted.org>


Carl Anderson <carl.anderson at ww.com> added the comment:

from https://en.wikipedia.org/wiki/Slash_(punctuation) there is

U+002F / SOLIDUS
U+2044 ? FRACTION SLASH
U+2215 ? DIVISION SLASH
U+29F8 ? BIG SOLIDUS
U+FF0F ? FULLWIDTH SOLIDUS (fullwidth version of solidus)
U+1F67C ? VERY HEAVY SOLIDUS

In XML and HTML, the slash can also be represented with the character entity &#47; or &#x2F; or &sol;.[42]

there are a couple more listed here:

https://unicode-search.net/unicode-namesearch.pl?term=SLASH

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43520>
_______________________________________

From report at bugs.python.org  Tue Mar 16 17:08:54 2021
From: report at bugs.python.org (Anup Parikh)
Date: Tue, 16 Mar 2021 21:08:54 +0000
Subject: [issue43334] venv does not install libpython
In-Reply-To: <1614379216.7.0.137032053148.issue43334@roundup.psfhosted.org>
Message-ID: <1615928934.71.0.0982188898955.issue43334@roundup.psfhosted.org>


Anup Parikh <anuppari at gmail.com> added the comment:

I'm seeing this issue in a third-party package that uses CMake and Make based build systems rather then setuptools (it's a mostly C library which additionally provides some python wrappers). Those build systems can normally parse a python installation with the standard directory structure to find the library and headers, but fail on a venv. I can bring this up with the package developers, but I don't see any downsides to linking the headers/libraries in the venv to make it easy to use.

Regarding the comment that venv's are primarily for runtime, I didn't see anything in PEP 405 that supports that statement. And in any case, even for runtime environments, installing a python package from a source distribution is valid, right? So shouldn't the venv support building extensions?

Again, I agree that third party packages that provide python wrappers should probably use standard tools (i.e., setuptools) to build the python C extensions, but I fail to see the downsides to including links to the headers/libraries in the venv for ease of use.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43334>
_______________________________________

From report at bugs.python.org  Tue Mar 16 17:11:22 2021
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 16 Mar 2021 21:11:22 +0000
Subject: [issue43520] Fraction only handles regular slashes ("/") and fails
 with other similar slashes
In-Reply-To: <1615918144.03.0.939769511159.issue43520@roundup.psfhosted.org>
Message-ID: <1615929082.83.0.174451826694.issue43520@roundup.psfhosted.org>


Change by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43520>
_______________________________________

From report at bugs.python.org  Tue Mar 16 17:20:03 2021
From: report at bugs.python.org (Ned Deily)
Date: Tue, 16 Mar 2021 21:20:03 +0000
Subject: [issue43285] ftplib should not use the host from the PASV response
In-Reply-To: <1613908174.7.0.0578051462677.issue43285@roundup.psfhosted.org>
Message-ID: <1615929603.21.0.323057892798.issue43285@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 79373951b3eab585d42e0f0ab83718cbe1d0ee33 by Miss Islington (bot) in branch '3.7':
[3.7] bpo-43285 Make ftplib not trust the PASV response. (GH-24838) (GH-24881) (GH-24883)
https://github.com/python/cpython/commit/79373951b3eab585d42e0f0ab83718cbe1d0ee33


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43285>
_______________________________________

From report at bugs.python.org  Tue Mar 16 17:20:10 2021
From: report at bugs.python.org (Carl Anderson)
Date: Tue, 16 Mar 2021 21:20:10 +0000
Subject: [issue43520] Fraction only handles regular slashes ("/") and fails
 with other similar slashes
In-Reply-To: <1615918144.03.0.939769511159.issue43520@roundup.psfhosted.org>
Message-ID: <1615929610.31.0.38105986277.issue43520@roundup.psfhosted.org>


Carl Anderson <carl.anderson at ww.com> added the comment:

I guess if we are doing slashes, then the division sign ? (U+00F7) should be included too. 

There are at least 2 minus signs too (U+002D, U+02D7).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43520>
_______________________________________

From report at bugs.python.org  Tue Mar 16 17:29:37 2021
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 16 Mar 2021 21:29:37 +0000
Subject: [issue43522] SSLContext.hostname_checks_common_name appears to have
 no effect
In-Reply-To: <1615925270.47.0.272234983925.issue43522@roundup.psfhosted.org>
Message-ID: <1615930177.91.0.850868645582.issue43522@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Oh heck, this is a genuine bug. I'm not yet sure if it's an undocumented API quirk in OpenSSL, a design bug in OpenSSL, or a bug in my code.

Python sets the host flags on the X509_VERIFY_PARAM of the *SSL_CTX. All flags get copied to *SSL struct and later to *X509_STORE_CTX struct. At least I thought that all flags get copied. Apparently hostflags aren't copied from *SSL_CTX to *SSL because the *SSL_CTX doesn't have any verify hosts configured. They are only ever configured on *SSL struct.

https://github.com/openssl/openssl/blob/081a7061f3da07318c4b0f5de67b82285630bf6b/crypto/x509/x509_vpm.c#L202-L213

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43522>
_______________________________________

From report at bugs.python.org  Tue Mar 16 17:31:14 2021
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 16 Mar 2021 21:31:14 +0000
Subject: [issue43522] SSLContext.hostname_checks_common_name appears to have
 no effect
In-Reply-To: <1615925270.47.0.272234983925.issue43522@roundup.psfhosted.org>
Message-ID: <1615930274.73.0.338626145394.issue43522@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

PS: I don't see any remark or warning about the behavior on the man pages https://www.openssl.org/docs/man1.1.1/man3/X509_VERIFY_PARAM_set_flags.html and https://www.openssl.org/docs/man1.1.1/man3/X509_check_host.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43522>
_______________________________________

From report at bugs.python.org  Tue Mar 16 17:41:38 2021
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 16 Mar 2021 21:41:38 +0000
Subject: [issue43522] SSLContext.hostname_checks_common_name appears to have
 no effect
In-Reply-To: <1615925270.47.0.272234983925.issue43522@roundup.psfhosted.org>
Message-ID: <1615930898.82.0.612973459108.issue43522@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
keywords: +patch
pull_requests: +23663
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24899

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43522>
_______________________________________

From report at bugs.python.org  Tue Mar 16 17:47:22 2021
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 16 Mar 2021 21:47:22 +0000
Subject: [issue43334] venv does not install libpython
In-Reply-To: <1614379216.7.0.137032053148.issue43334@roundup.psfhosted.org>
Message-ID: <1615931242.53.0.184750828521.issue43334@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

This sounds like a bug in CMake or Make. Are you using any CMake plugins or autoconf/automake macros? It's very well possible that the author of these extension made a wrong assumption or the extension was written before venvs were introduced.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43334>
_______________________________________

From report at bugs.python.org  Tue Mar 16 17:48:50 2021
From: report at bugs.python.org (George Sovetov)
Date: Tue, 16 Mar 2021 21:48:50 +0000
Subject: [issue43523] Handling Ctrl+C when waiting on stdin on Windows via
 winrs
Message-ID: <1615931330.13.0.919468061035.issue43523@roundup.psfhosted.org>


New submission from George Sovetov <georgesovetov at gmail.com>:

Ctrl+C alone has no effect, but Ctrl+Break works:
```
winrs -r:127.0.0.1:20465 -u:Administrator -p:qweasd123 python -c "import sys;sys.stdin.read(1)"
```
Although, if I press Ctrl+C, type zero or more symbols and then press Enter, KeyboardInterrupt is raised:
```
lalala
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Program Files\Python39\lib\encodings\cp1252.py", line 22, in decode
    def decode(self, input, final=False):
KeyboardInterrupt
^C^C
```

With the following commands, both Ctrl+C and Ctrl+Break work:
```
winrs -r:127.0.0.1:20465 -u:Administrator -p:qweasd123 python -c "import time;time.sleep(10)"
"c:\Program Files\Python39\python.exe" -c "import sys; sys.stdin.read(1)"
"c:\Program Files\Python39\python.exe" -c "import time;time.sleep(10)"
```

I faced this issue when working with WSMV (Windows remoting API) directly, but I reproduced this with winrs to make sure it's not a bug in my code. I send the Ctrl+C signal, got a no-error response, then poll the running command. It behaves as if a signal had no effect.

----------
messages: 388890
nosy: sovetov
priority: normal
severity: normal
status: open
title: Handling Ctrl+C when waiting on stdin on Windows via winrs
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43523>
_______________________________________

From report at bugs.python.org  Tue Mar 16 17:54:25 2021
From: report at bugs.python.org (Ned Deily)
Date: Tue, 16 Mar 2021 21:54:25 +0000
Subject: [issue43285] ftplib should not use the host from the PASV response
In-Reply-To: <1613908174.7.0.0578051462677.issue43285@roundup.psfhosted.org>
Message-ID: <1615931665.21.0.428723541644.issue43285@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Thanks for the PRs and the What's New entries.

----------
assignee: ned.deily -> 
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43285>
_______________________________________

From report at bugs.python.org  Tue Mar 16 18:20:05 2021
From: report at bugs.python.org (Cebtenzzre)
Date: Tue, 16 Mar 2021 22:20:05 +0000
Subject: [issue43517] Fix false positives in circular import detection with
 from-imports
In-Reply-To: <1615911063.74.0.357076415367.issue43517@roundup.psfhosted.org>
Message-ID: <1615933205.76.0.892104849142.issue43517@roundup.psfhosted.org>


Change by Cebtenzzre <cebtenzzre at gmail.com>:


----------
nosy: +cebtenzzre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43517>
_______________________________________

From report at bugs.python.org  Tue Mar 16 19:22:58 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 16 Mar 2021 23:22:58 +0000
Subject: [issue43520] Fraction only handles regular slashes ("/") and fails
 with other similar slashes
In-Reply-To: <1615918144.03.0.939769511159.issue43520@roundup.psfhosted.org>
Message-ID: <1615936978.76.0.989048287457.issue43520@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I think we should stick the with forward slashes.  That is what the rest of the language does.  Adding more options is recipe for confusion.

>>> 38 / 5
7.6
>>> 38 ? 5
SyntaxError: invalid character '?' (U+2215)

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43520>
_______________________________________

From report at bugs.python.org  Tue Mar 16 19:34:25 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 16 Mar 2021 23:34:25 +0000
Subject: [issue43502] [C-API] Convert obvious unsafe macros to static inline
 functions
In-Reply-To: <1615816484.12.0.00251754107838.issue43502@roundup.psfhosted.org>
Message-ID: <1615937665.09.0.513838632185.issue43502@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Be careful about performance.  We know for sure that macros will inline.  In contrast, inline functions might or might not inline (there are rules for when it can be done).  When applied across source files, inlining often only occurs with an LTO build ? any other build can't inline across object files.  Historically, we've never had to depend on LTO, so that would be a regression for some users.  We've already have a performance bug that needed to be reverted because of too aggressive conversion of macros to inline functions.  

A problem with these blanket PRs is that they second guess the original developer who may have made a conscious and informed decision to use a macro.  If you really think that developer was wrong, they should be included in the conversation and given the chance to opt in or out.  Otherwise, we're mechanically undoing previous intelligent efforts.

Ideally, there needs to be a more nuanced view than "macros are bad, inline functions are good".

----------
nosy: +pablogsal, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43502>
_______________________________________

From report at bugs.python.org  Tue Mar 16 19:38:27 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 16 Mar 2021 23:38:27 +0000
Subject: [issue39511] [subinterpreters] Per-interpreter singletons (None, True,
 False, etc.)
In-Reply-To: <1580484815.27.0.407070570821.issue39511@roundup.psfhosted.org>
Message-ID: <1615937907.28.0.291982459423.issue39511@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Shouldn't this wait to see if the subinterpreters PEP is approved?  Because if it isn't, then no chance should be made.  We shouldn't change something this fundamental without good cause.

----------
nosy: +pablogsal, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39511>
_______________________________________

From report at bugs.python.org  Tue Mar 16 19:51:15 2021
From: report at bugs.python.org (Awal Garg)
Date: Tue, 16 Mar 2021 23:51:15 +0000
Subject: [issue43524] Addition of peek and peekexactly methods to
 asyncio.StreamReader
Message-ID: <1615938675.3.0.818734595532.issue43524@roundup.psfhosted.org>


New submission from Awal Garg <awalgarg at gmail.com>:

I propose the addition of the following methods to asyncio.StreamReader:

> coroutine peek(n=-1)
> Same as read, but does not remove the returned data from the internal buffer.
> 
> coroutine peekexactly(n)
> Same as readexactly, but does not remove the returned data from the internal buffer.

My use case is to multiplex a few protocols over a single TCP socket, for which I need to non-destructively read a few bytes from the socket to decide which parser to hand the stream over to.

Thoughts?

----------
components: asyncio
messages: 388895
nosy: asvetlov, awalgarg, yselivanov
priority: normal
severity: normal
status: open
title: Addition of peek and peekexactly methods to asyncio.StreamReader
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43524>
_______________________________________

From report at bugs.python.org  Tue Mar 16 19:52:56 2021
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 16 Mar 2021 23:52:56 +0000
Subject: [issue43523] Handling Ctrl+C while waiting on I/O in Windows
In-Reply-To: <1615931330.13.0.919468061035.issue43523@roundup.psfhosted.org>
Message-ID: <1615938776.07.0.00048851425138.issue43523@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

winrshost.exe runs Python with its standard I/O redirected to pipes, so sys.stdin.read(1) blocks the main thread while waiting for the synchronous read to complete. If the user types something, then the read completes and the main thread can call the SIGINT handler, which raises KeyboardInterrupt.

By default, SIGBREAK is not handled, so the console CTRL_BREAK_EVENT executes the default handler on the control thread, which calls ExitProcess(STATUS_CONTROL_C_EXIT).

Currently, the only I/O that can be interrupted is reading from console input, since the console itself cancels the request when the user presses Ctrl+C.

To interrupt synchronous I/O in general, the C signal handler could call WinAPI CancelSynchronousIo() with a handle for the main thread. Synchronous I/O calls would have to be updated to handle ERROR_OPERATION_ABORTED (from C _doserrno if calling C read/write). This entails calling PyErr_CheckSignals() in order to call the registered signal handler and return whether it raises an exception. But first PyOS_InterruptOccurred() has to be checked. If SIGINT isn't tripped, the abort request didn't originate from the signal handler, so the call should fail without calling PyErr_CheckSignals().

An asynchronous I/O request (e.g. socket I/O is typically asynchronous) can be canceled with CancelIo[Ex], which requires a handle for the open file that has the pending request. This case can only be addressed by the C signal handler if the main thread registers the file handle with the signal module before waiting for I/O completion. If a wait for I/O completion is alertable, then a user-mode APC can be queued to the thread in order to call CancelIo() on the file handle. If it's not an alertable wait, then the I/O request can be canceled with CancelIoEx(), but preferably the OVERLAPPED record for the request should also be registered, else all of the file's pending I/O requests will be canceled, instead of canceling only the request that's blocking the main thread.

----------
components: +IO, Interpreter Core, Windows
nosy: +eryksun, paul.moore, steve.dower, tim.golden, zach.ware
title: Handling Ctrl+C when waiting on stdin on Windows via winrs -> Handling Ctrl+C while waiting on I/O in Windows
type:  -> enhancement
versions: +Python 3.10, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43523>
_______________________________________

From report at bugs.python.org  Tue Mar 16 19:56:25 2021
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 16 Mar 2021 23:56:25 +0000
Subject: [issue43516] python on raspberry pi
In-Reply-To: <1615909802.06.0.398723617988.issue43516@roundup.psfhosted.org>
Message-ID: <1615938985.49.0.152168219211.issue43516@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Yann,

Eric is correct -- this isn't a help desk. Please ask your question on one of the many forums available for asking help, but before you do, please read:

http://www.sscce.org/

https://stackoverflow.com/help/minimal-reproducible-example

and remember to let them know what you expected the code to do and what it did instead.

You'll also need to tell them the version of Python you are running, and clarify whether you are running on a Raspberry Pi (as the title says) or Android (as the code says).

----------
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43516>
_______________________________________

From report at bugs.python.org  Tue Mar 16 19:57:14 2021
From: report at bugs.python.org (Awal Garg)
Date: Tue, 16 Mar 2021 23:57:14 +0000
Subject: [issue43524] Addition of peek and peekexactly methods to
 asyncio.StreamReader
In-Reply-To: <1615938675.3.0.818734595532.issue43524@roundup.psfhosted.org>
Message-ID: <1615939034.1.0.541436746646.issue43524@roundup.psfhosted.org>


Awal Garg <awalgarg at gmail.com> added the comment:

P.S., I've filed this issue after a brief discussion in #python and following this ticket https://bugs.python.org/issue32052 which asks for exposing the internal buffer as is. Obviously, peek methods don't need to expose the buffer and only provide a readonly view.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43524>
_______________________________________

From report at bugs.python.org  Tue Mar 16 20:00:23 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 17 Mar 2021 00:00:23 +0000
Subject: [issue43502] [C-API] Convert obvious unsafe macros to static inline
 functions
In-Reply-To: <1615816484.12.0.00251754107838.issue43502@roundup.psfhosted.org>
Message-ID: <1615939223.9.0.46992109746.issue43502@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I agree we should be careful here. There are several things to consider:

* Macros transformed into function may or may not get inlined so there is a risk of affecting performance if we just transform them in bulk.

* Because the macro is defined as 'static inline' in the header file, then it *can* be inlined everywhere if the compiled decides to do it. It will be one copy symbol in the text segment on every compilation unit. Notice that 'inline' has a special meaning in C99 and it doesn't only mean "inline this function". It has visibility implications (see section 6.7.4 of the C99 standard).

* There is risk to introducing a backwards-incompatible ABI change by mistake as Victor mentions.

* This can affect also the link patterns of extension modules because these symbols may be visible in the resulting binaries when they were macro-level-inlined before. I cannot see any problem that can happen because of this but we should carefully consider it.

In short, there is the value of converting these macros for extra type safety, but we need to at the very least be very careful and if we decide to go forward this needs as many reviews as possible so we don't miss anything. I would recommend maybe start a thread about this in python-dev.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43502>
_______________________________________

From report at bugs.python.org  Tue Mar 16 20:03:57 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 17 Mar 2021 00:03:57 +0000
Subject: [issue42246] Implement PEP 626 -- Precise line numbers for debugging
In-Reply-To: <1604331162.26.0.596873070589.issue42246@roundup.psfhosted.org>
Message-ID: <1615939437.25.0.139655366476.issue42246@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

PEP 626 deprecates co_lnotab, co_lnotab:

https://www.python.org/dev/peps/pep-0626/#id15

This doesn't seem to be mentioned in the What's new document and is quite important. Mark, do you mind creating a PR for this? I could do it and add you as a reviewer if you wish

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42246>
_______________________________________

From report at bugs.python.org  Tue Mar 16 20:13:41 2021
From: report at bugs.python.org (Greg Darke)
Date: Wed, 17 Mar 2021 00:13:41 +0000
Subject: [issue43497] SyntaxWarning for "assertion is always true,
 perhaps remove parentheses?" does not work with constants
In-Reply-To: <1615793485.02.0.990067169214.issue43497@roundup.psfhosted.org>
Message-ID: <1615940021.36.0.65959042953.issue43497@roundup.psfhosted.org>


Change by Greg Darke <darke at google.com>:


----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43497>
_______________________________________

From report at bugs.python.org  Tue Mar 16 20:26:13 2021
From: report at bugs.python.org (Thomas J. Gallen)
Date: Wed, 17 Mar 2021 00:26:13 +0000
Subject: [issue43477] from x import * behavior inconsistent between module
 types.
In-Reply-To: <1615509638.08.0.549124406797.issue43477@roundup.psfhosted.org>
Message-ID: <1615940773.95.0.0552359944569.issue43477@roundup.psfhosted.org>


Thomas J. Gallen <kaori.hinata at gmail.com> added the comment:

Given the previous example, in test.py, replace:

```
print(test_module.test_submodule)
```

...with:

```
assert(not hasattr(test_module, "test_submodule"))
```

...because the issue is only the bottom half of `_find_and_load_unlocked`. Specifically, the chunk starting at line 1006:

```
    if parent:
        # Set the module as an attribute on its parent.
        parent_module = sys.modules[parent]
        child = name.rpartition('.')[2]
        try:
            setattr(parent_module, child, module)
        except AttributeError:
            msg = f"Cannot set an attribute on {parent!r} for child module {child!r}"
            _warnings.warn(msg, ImportWarning)
```

The issue with these lines is that nothing here was requested by the user, and the actions you mentioned (preventing redundant/duplicate imports) is not handled by anything in, or relating to this code (at least, not that I've seen.) The module and all dependencies would still be loaded into `sys.modules` despite this code. If the module has already been loaded, then we'll never make it past `_find_and_load` to `_find_and_load_unlocked` anyway, as `_NEEDS_LOADING` will no longer match.

Does that make more sense?

----------
resolution: not a bug -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43477>
_______________________________________

From report at bugs.python.org  Tue Mar 16 21:02:39 2021
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 17 Mar 2021 01:02:39 +0000
Subject: [issue15533] subprocess.Popen(cwd) documentation: Posix vs Windows
In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za>
Message-ID: <1615942959.94.0.203620417742.issue15533@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> Python is conceptually multi-platform, so its behavior on 
> Linux and Windows should be as much consistent as possible.

It's not expected for the behavior of all Popen() parameters to be the same on all platforms. For example, the behavior and capabilities of shell=True are different in Windows vs POSIX. But I think a basic set of parameters should have been singled out for cross-platform consistency -- at least in the default case. Unfortunately it wasn't designed that way. New behavior that's consistent with POSIX can be implemented, but at this point it would have to be enabled by a parameter. 

> "In particular, the function looks for executable (or for the 
> first item in args) relative to cwd if the executable path is 
> a relative path." 

For POSIX, this should be stated as a "relative path without a slash in it" or a "relative path without a directory in it". An unqualified filename is a relative path that won't be resolved against `cwd`, unless there's a "." entry in PATH.

For Windows, the use of CreateProcess() is documented. It could be stated more explicitly that `executable`, `args` / list2cmdline(args), `env`, and `cwd` are passed directly to CreateProcess() as lpApplicationName, lpCommandLine, lpEnvironment, and lpCurrentDirectory.

Here are some notes and corrections about the documentation of lpCommandLine, in particular the following paragraph:

    If the file name does not contain an extension, .exe is appended.
    Therefore, if the file name extension is .com, this parameter must
    include the .com extension. If the file name ends in a period (.)
    with no extension, or if the file name contains a path, .exe is
    not appended. If the file name does not contain a directory path,
    the system searches for the executable file in the following
    sequence [1][2][3]:

        * %__APPDIR__%
        * %__CD__% [4]
        * %SystemRoot%\System32
        * %SystemRoot%\System
        * %SystemRoot%
        * %PATH% (machine/user extended search sequence)

    [1] The search sequence is rewritten here succinctly using
        environment variables in the current process, including the
        virtual variables __APPDIR__ (application directory) and
        __CD__ (current directory), which are supported by WinAPI
        GetEnvironmentVariableW().

    [2] A path name is resolved by searching for it if it isn't fully
        qualified and doesn't explicitly begin with the current
        directory (".") or its parent (".."). Note that, unlike POSIX,
        a relative path name is resolved by searching for it even if
        it contains a directory component (i.e. a slash or backslash).
        For example, "spam\eggs.exe" is resolved by looking for
        r"%__APPDIR__%\spam\eggs.exe" and so on.

    [3] If a path name has to be resolved by searching, and its final
        component does not contain a "." character, then ".exe" is
        appended to the name. On the other hand, if a path name does
        not need to be resolved by searching, because it's fully
        qualified or the first component is "." or "..", then if the 
        given path name doesn't exist, it also looks for the name with
        ".exe" appended, even if the final component of the path name
        contains a "." character.

    [4] If "NoDefaultCurrentDirectoryInExePath" is defined in the
        environment and the path name does not contain a directory
        component (i.e. no slash or backslash), then the current
        directory is excluded from the search sequence.

That %__APPDIR__% always takes precedence means that subprocess.Popen(['python']) runs the Python version of the current process, regardless of PATH, unless shell=True is used. 

The implementation of lpApplicationName (executable) and lpCurrentDirectory (cwd) means that argv[0] in the child process, as parsed from its command line, does not necessarily resolve to a name in the filesystem. Windows supports GetModuleFileNameW(NULL, ...) to get the path of the application executable.

----------
versions: +Python 3.10, Python 3.9 -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15533>
_______________________________________

From report at bugs.python.org  Tue Mar 16 21:56:51 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 17 Mar 2021 01:56:51 +0000
Subject: [issue15533] subprocess.Popen(cwd) documentation: Posix vs Windows
In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za>
Message-ID: <1615946211.68.0.78210957078.issue15533@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

For our subprocess docs, Eryk's text:

"""
For POSIX, ``executable`` should be stated as a "relative path without a slash in it" or a "relative path without a directory in it". An unqualified filename is a relative path that won't be resolved against ``cwd``, unless there's a "." entry in PATH.

For Windows, the use of CreateProcess() is documented. It could be stated more explicitly that ``executable``, ``args`` / ``list2cmdline(args)``, ``env``, and ``cwd`` are passed directly to CreateProcess() as lpApplicationName, lpCommandLine, lpEnvironment, and lpCurrentDirectory.
"""

is quite reasonable.  I wouldn't include your long notes.  But a link to a MSDN article explaining that would be useful at the end of the Windows paragraph.

For the POSIX case we should describe which PATH is used.  The current one, or the one set in a ``env`` dict.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15533>
_______________________________________

From report at bugs.python.org  Wed Mar 17 00:04:55 2021
From: report at bugs.python.org (diegoe)
Date: Wed, 17 Mar 2021 04:04:55 +0000
Subject: [issue43525] pathlib: Highlight operator behavior with anchored paths
Message-ID: <1615953895.06.0.527756201685.issue43525@roundup.psfhosted.org>


New submission from diegoe <diegoe at gnome.org>:

In the '/' operator documentation for `pathlib`, the behavior for anchored paths is not described:

https://docs.python.org/3/library/pathlib.html#operators

The behavior (prefer the second/right-hand root/anchor) is only explained in the `PurePath` class:

https://docs.python.org/3/library/pathlib.html#pathlib.PurePath

I ran into this while helping migrate a code base that was using "naive" concatenation of strings, so this:

```
PROJECT_DIR = ROOT_DIR + "/project-name"
```

was migrated to:
```
PROJECT_DIR = ROOT_DIR / "/project-name"
```

Note that, of course, we missed the leading "/".

Although the docs _do_ describe the behavior somewhere else, I believe it's worth being redundant in the operator section.

I believe it's a reasonable mistake to warn new users against, specially since "naive" concatenation is a common "ugly" pattern that many would be migrating from. Plus, a leading "/" is easy to miss, which would only compound the confusion if you are seeing your path "omit the (left-hand) Path object" (because the anchored string took precedence).

----------
assignee: docs at python
components: Documentation
messages: 388904
nosy: diegoe, docs at python
priority: normal
severity: normal
status: open
title: pathlib: Highlight operator behavior with anchored paths
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43525>
_______________________________________

From report at bugs.python.org  Wed Mar 17 00:12:05 2021
From: report at bugs.python.org (Ned Deily)
Date: Wed, 17 Mar 2021 04:12:05 +0000
Subject: [issue43511] tkinter with Tk 8.6.11 is slow on macOS
In-Reply-To: <1615875194.4.0.35991043769.issue43511@roundup.psfhosted.org>
Message-ID: <1615954325.54.0.996982657647.issue43511@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Thanks for submitting a very interesting issue! tkinter/Tk performance is not something we normally pay a lot of attention to. I did not attempt to run your application but I was able to see significant performance differences with your simple "help('modules') test. Before saying more, I want to test some additional configurations but I've run out of time for today. However, the differences don't seem to have anything to do with running on new M1 Macs as I was able to see them on a traditional Intel-based Mac running macOS 11.

----------
title: Tk 8.6.11 slow on M1 Mac Mini MacOS Python 3.9.2 native ARM version -> tkinter with Tk 8.6.11 is slow on macOS

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43511>
_______________________________________

From report at bugs.python.org  Wed Mar 17 00:22:36 2021
From: report at bugs.python.org (diegoe)
Date: Wed, 17 Mar 2021 04:22:36 +0000
Subject: [issue43525] pathlib: Highlight operator behavior with anchored paths
In-Reply-To: <1615953895.06.0.527756201685.issue43525@roundup.psfhosted.org>
Message-ID: <1615954956.72.0.143503605911.issue43525@roundup.psfhosted.org>


Change by diegoe <diegoe at gnome.org>:


----------
keywords: +patch
pull_requests: +23664
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24900

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43525>
_______________________________________

From report at bugs.python.org  Wed Mar 17 00:24:30 2021
From: report at bugs.python.org (diegoe)
Date: Wed, 17 Mar 2021 04:24:30 +0000
Subject: [issue43525] pathlib: Highlight pathlib operator behavior with
 anchored paths
In-Reply-To: <1615953895.06.0.527756201685.issue43525@roundup.psfhosted.org>
Message-ID: <1615955070.72.0.359886512791.issue43525@roundup.psfhosted.org>


Change by diegoe <diegoe at gnome.org>:


----------
title: pathlib: Highlight operator behavior with anchored paths -> pathlib: Highlight pathlib operator behavior with anchored paths

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43525>
_______________________________________

From report at bugs.python.org  Wed Mar 17 00:59:05 2021
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 17 Mar 2021 04:59:05 +0000
Subject: [issue38890] subprocess.Popen should not emit a ResourceWarning for a
 detached process
In-Reply-To: <1574381050.02.0.817865416124.issue38890@roundup.psfhosted.org>
Message-ID: <1615957145.9.0.899147508718.issue38890@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

I wonder if this should be handled more productively by supporting a `daemon` parameter. In POSIX, use the double fork technique for creating a daemon process. In Windows, use DETACHED_PROCESS | CREATE_NEW_PROCESS_GROUP | CREATE_BREAKAWAY_FROM_JOB. For a daemon process, the finalizer would not emit a resource warning or add it to the _active list.

----------
title: A subprocess.Popen created with creationFlags=DETACHED_PROCESS on Windows should not emit a ResourceWarning -> subprocess.Popen should not emit a ResourceWarning for a detached process
versions: +Python 3.10 -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38890>
_______________________________________

From report at bugs.python.org  Wed Mar 17 01:18:38 2021
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 17 Mar 2021 05:18:38 +0000
Subject: [issue32553] Use the py launcher in venv Windows examples
In-Reply-To: <1515982096.25.0.467229070634.issue32553@psf.upfronthosting.co.za>
Message-ID: <1615958318.9.0.899952627651.issue32553@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
title: venv says to use python3 which does not exist in 3.6.4 -> Use the py launcher in venv Windows examples
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32553>
_______________________________________

From report at bugs.python.org  Wed Mar 17 02:01:40 2021
From: report at bugs.python.org (Quentin Pradet)
Date: Wed, 17 Mar 2021 06:01:40 +0000
Subject: [issue43522] SSLContext.hostname_checks_common_name appears to have
 no effect
In-Reply-To: <1615925270.47.0.272234983925.issue43522@roundup.psfhosted.org>
Message-ID: <1615960900.79.0.877722032953.issue43522@roundup.psfhosted.org>


Quentin Pradet <quentin.pradet at gmail.com> added the comment:

Thank you for the quick fix! ? Both the reproducer and the urllib3 test suite run fine with this change.

However, we can't trust `HAS_NEVER_CHECK_COMMON_NAME` anymore, because it will be True in Python versions where `hostname_checks_common_name` does not work. Is it possible to have, uh, `REALLY_HAS_NEVER_CHECK_COMMON_NAME_I_PROMISE` or something like that? :D It could even be private. Otherwise, we will only be able to use `hostname_checks_common_name` in Python 3.10.0a7+.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43522>
_______________________________________

From report at bugs.python.org  Wed Mar 17 02:23:41 2021
From: report at bugs.python.org (Paul)
Date: Wed, 17 Mar 2021 06:23:41 +0000
Subject: [issue43512] Bug in isinstance(instance,
 cls) with cls being a protocol? (PEP 544)
In-Reply-To: <1615888944.07.0.094574416265.issue43512@roundup.psfhosted.org>
Message-ID: <1615962221.58.0.329747519097.issue43512@roundup.psfhosted.org>


Paul <paul.dest at web.de> added the comment:

That's the very first issue I've reported in bugs.python.org and I'm completely new to the Python dev process:

I have some further remarks at the issue (especially about consistency with the current treatment of Protocols vs. ABCs). Will they be read if placed here after the issue has been closed? Or should I (a) open a new issue or (b) change the status of this issue to "open" first?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43512>
_______________________________________

From report at bugs.python.org  Wed Mar 17 02:33:50 2021
From: report at bugs.python.org (Antti Haapala)
Date: Wed, 17 Mar 2021 06:33:50 +0000
Subject: [issue43468] functools.cached_property incorrectly locks the entire
 descriptor on class instead of per-instance locking
In-Reply-To: <1615444667.91.0.948817723419.issue43468@roundup.psfhosted.org>
Message-ID: <1615962830.7.0.729809104655.issue43468@roundup.psfhosted.org>


Change by Antti Haapala <antti at haapala.name>:


----------
title: functools.cached_property locking is plain wrong. -> functools.cached_property incorrectly locks the entire descriptor on class instead of per-instance locking

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43468>
_______________________________________

From report at bugs.python.org  Wed Mar 17 02:56:44 2021
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 17 Mar 2021 06:56:44 +0000
Subject: [issue27602] Enable py launcher to launch repository Python.
In-Reply-To: <1469306499.45.0.411476180863.issue27602@psf.upfronthosting.co.za>
Message-ID: <1615964204.8.0.328768641626.issue27602@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

The narrow scope of this issue could be implemented by defining a scheme for local builds in the PythonCore key -- such as "X.Ys[-32]". The build process would create or update the "HKCU\Software\Python\PythonCore\X.Ys[-32]\InstallPath" key with the "ExecutablePath" and "WindowedExecutablePath" values. 

In PC/launcher.c, validate_version() would have to allow "s" after the major/minor version (e.g. "3s", "3.10s"), and locate_python() would have to ignore "s" when deciding to call get_configured_value(config_key) if no minor version is specified (e.g. for "3s", check PY_PYTHON3 and the "python3" value in py.ini).

----------
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27602>
_______________________________________

From report at bugs.python.org  Wed Mar 17 03:08:52 2021
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 17 Mar 2021 07:08:52 +0000
Subject: [issue29688] Add support for Path.absolute()
In-Reply-To: <1488389848.79.0.700814097868.issue29688@psf.upfronthosting.co.za>
Message-ID: <1615964932.0.0.320704320046.issue29688@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
Removed message: https://bugs.python.org/msg289517

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29688>
_______________________________________

From report at bugs.python.org  Wed Mar 17 03:10:19 2021
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 17 Mar 2021 07:10:19 +0000
Subject: [issue25012] pathlib should allow converting to absolute paths
 without resolving symlinks
In-Reply-To: <1441490748.21.0.647656961559.issue25012@psf.upfronthosting.co.za>
Message-ID: <1615965019.73.0.98978127595.issue25012@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Add support for Path.absolute()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25012>
_______________________________________

From report at bugs.python.org  Wed Mar 17 03:15:06 2021
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 17 Mar 2021 07:15:06 +0000
Subject: [issue34297] Windows py launcher fails to handle a quoted version
 argument
In-Reply-To: <1533058834.14.0.56676864532.issue34297@psf.upfronthosting.co.za>
Message-ID: <1615965306.88.0.00156459534494.issue34297@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
stage: test needed -> needs patch
title: Windows py.exe launcher fail to handle quote correctly -> Windows py launcher fails to handle a quoted version argument
versions: +Python 3.10, Python 3.9 -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34297>
_______________________________________

From report at bugs.python.org  Wed Mar 17 03:30:11 2021
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 17 Mar 2021 07:30:11 +0000
Subject: [issue35216] misleading error message from shutil.copy()
In-Reply-To: <1542025151.44.0.788709270274.issue35216@psf.upfronthosting.co.za>
Message-ID: <1615966211.17.0.423727884093.issue35216@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> shutil.copy raises IsADirectoryError when the directory does not actually exist

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35216>
_______________________________________

From report at bugs.python.org  Wed Mar 17 03:52:54 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Wed, 17 Mar 2021 07:52:54 +0000
Subject: [issue43502] [C-API] Convert obvious unsafe macros to static inline
 functions
In-Reply-To: <1615816484.12.0.00251754107838.issue43502@roundup.psfhosted.org>
Message-ID: <1615967574.07.0.649565690599.issue43502@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

Pablo:
> I agree we should be careful here. There are several things to consider:

Yes, and thanks for your thorough reply and insights. I do not suggest converting macros blindly, and I have no intention of doing so. Apart from the three PyUnicode_*() cases mentioned in msg388870, I've not found any misuse of macros that reuse their arguments in the CPython code base.

Perhaps using a meta-issue is the wrong approach. I guess a PEP is too much? I'll start a thread on dpo (or on the list).

Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43502>
_______________________________________

From report at bugs.python.org  Wed Mar 17 04:54:25 2021
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 17 Mar 2021 08:54:25 +0000
Subject: [issue43214] site: Potential UnicodeDecodeError when handling pth file
In-Reply-To: <1613206406.27.0.848192620201.issue43214@roundup.psfhosted.org>
Message-ID: <1615971265.84.0.207161503662.issue43214@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

locale-specific encoding is not good especially for Windows.
But we used it for a long time. Changing the encoding for pth files is breaking change.

----------
resolution:  -> not a bug
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43214>
_______________________________________

From report at bugs.python.org  Wed Mar 17 05:03:05 2021
From: report at bugs.python.org (Xavier Morel)
Date: Wed, 17 Mar 2021 09:03:05 +0000
Subject: [issue43526] Programmatic management of BytesWarning doesn't work for
 native triggers.
Message-ID: <1615971785.71.0.488992120219.issue43526@roundup.psfhosted.org>


New submission from Xavier Morel <xavier.morel at masklinn.net>:

When setting `BytesWarning` programmatically (via the warnings API), though the `warnings.filters` value matches what's obtained via `python -b` and an explicit `warnings.warn` trigger will trigger, "native" triggers of the warning fail to trigger properly:

    import warnings
    warnings.simplefilter('default', category=BytesWarning)
    str(b'')
    warnings.warn('test', category=BytesWarning)

If run using `python`, this will print:

    test.py:4: BytesWarning: test
      warnings.warn('test', category=BytesWarning)

There is no warning for the string-ification of the bytes instance.

If run using `python -b`, the behaviour is as one would expect:

    test.py:3: BytesWarning: str() on a bytes instance
      str(b'')
    test.py:4: BytesWarning: test
      warnings.warn('test', category=BytesWarning)

Inspecting `warnings.filters` shows now difference in their contents, in both cases it is:

    [('default', None, <class 'BytesWarning'>, None, 0), ('default', None, <class 'DeprecationWarning'>, '__main__', 0), ('ignore', None, <class 'DeprecationWarning'>, None, 0), ('ignore', None, <class 'PendingDeprecationWarning'>, None, 0), ('ignore', None, <class 'ImportWarning'>, None, 0), ('ignore', None, <class 'ResourceWarning'>, None, 0)]

(in Python 3.9).

The warning module's own suggestion:

    import sys
    if not sys.warnoptions:
        import warnings
        warnings.simplefilter("default") # Change the filter in this process

also fails to enable BytesWarning.

If this is intended behaviour, which seems to be the case according to ncoghlan's comment https://bugs.python.org/issue32230#msg307721, it should be clearly documented, as it's rather frustrating.

----------
components: Library (Lib)
messages: 388912
nosy: xmorel
priority: normal
severity: normal
status: open
title: Programmatic management of BytesWarning doesn't work for native triggers.
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43526>
_______________________________________

From report at bugs.python.org  Wed Mar 17 05:08:22 2021
From: report at bugs.python.org (Xavier Morel)
Date: Wed, 17 Mar 2021 09:08:22 +0000
Subject: [issue43526] Programmatic management of BytesWarning doesn't work for
 native triggers.
In-Reply-To: <1615971785.71.0.488992120219.issue43526@roundup.psfhosted.org>
Message-ID: <1615972102.94.0.628446092003.issue43526@roundup.psfhosted.org>


Xavier Morel <xavier.morel at masklinn.net> added the comment:

Addendum: is there a way to force `-b` from within the running Python program?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43526>
_______________________________________

From report at bugs.python.org  Wed Mar 17 05:39:37 2021
From: report at bugs.python.org (Xavier Morel)
Date: Wed, 17 Mar 2021 09:39:37 +0000
Subject: [issue43527] Support full stack trace extraction in warnings.
Message-ID: <1615973977.17.0.0612429597045.issue43527@roundup.psfhosted.org>


New submission from Xavier Morel <xavier.morel at masklinn.net>:

When triggering warnings, it's possible to pass in a `stacklevel` in order to point to a more informative cause than the `warnings.warn` call. 

For instance `stacklevel=2` is a common one for DeprecationWarning in order to mark the call itself as deprecated in the caller's codebase.

The problem with this is that it's not transitive, so when a dependency triggers a warning it can be hard to know where that comes from in the codebase (at least without `-Werror` which can prevent reaching the interesting warning entirely), and whether this is an issue in the codebase (e.g. passing bytes where the library really works in terms of strings) or whether it would be possible to work around the warning by using some other API.

In that case, the ability to show a full stack trace from the `stacklevel` down is very useful to diagnose such issues.

Not quite sure how it would be managed though: I'd think this should be part of the warnings filter information, but the `stacklevel` currently isn't stored there, and it might be risky to extend the warnings filter with a 6th field).

----------
components: Library (Lib)
messages: 388914
nosy: xmorel
priority: normal
severity: normal
status: open
title: Support full stack trace extraction in warnings.
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43527>
_______________________________________

From report at bugs.python.org  Wed Mar 17 05:45:28 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 17 Mar 2021 09:45:28 +0000
Subject: [issue43526] Programmatic management of BytesWarning doesn't work for
 native triggers.
In-Reply-To: <1615971785.71.0.488992120219.issue43526@roundup.psfhosted.org>
Message-ID: <1615974328.38.0.814388667866.issue43526@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Yes, it is intended behaviour. BytesWarning is only emitted when you set a special internal flag (by the -b option). Warning filters control what happen with that warning later: be it ignored, printed, or converted to exception.

In normal circumstances you should never deal with BytesWarning. The -b option is only used for testing your program for some possible bugs caused by migration from Python 2. If your program always worked only with Python 3, the -b option has no use for you.

It may be more complicated if you write a library which support bytes and strings. Since you do not know in what program it will be used, it may be nice to to test it with mixed bytes and str data and ensure that it works with bytes warnings enabled.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43526>
_______________________________________

From report at bugs.python.org  Wed Mar 17 06:30:46 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Mar 2021 10:30:46 +0000
Subject: [issue43214] site: Potential UnicodeDecodeError when handling pth file
In-Reply-To: <1613206406.27.0.848192620201.issue43214@roundup.psfhosted.org>
Message-ID: <1615977046.46.0.463643895314.issue43214@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Since it's a Python script, the default encoding should be UTF-8, as any Python script. I guess that most pth files don't use characters outside ASCII so it's fine.

I think that distutils made a few changes to switch UTF-8 last years, so it's possible.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43214>
_______________________________________

From report at bugs.python.org  Wed Mar 17 07:12:14 2021
From: report at bugs.python.org (Thomas Wamm)
Date: Wed, 17 Mar 2021 11:12:14 +0000
Subject: [issue43511] tkinter with Tk 8.6.11 is slow on macOS
In-Reply-To: <1615875194.4.0.35991043769.issue43511@roundup.psfhosted.org>
Message-ID: <1615979534.12.0.507852133518.issue43511@roundup.psfhosted.org>


Thomas Wamm <thomaswamm at gmail.com> added the comment:

I spent a few hours running numerous configurations (M1 Mac Mini, iMac24-2007, Win10 on i5-8250U, Raspberry Pi 4B, various Pythons from 3.7.3 to 3.10.0a6). It can get confusing. 
The primary interesting result is that Python 3.9.2 and 3.10.0a6 arm64 versions on M1 Mac Mini are the absolute worst performers by factors of 2 to 15, when relying on tkinter/Tcl/Tk for windows or graphics. Any Python3 on Windows 10 on an Intel i5 was at least 8x faster than the M1 Mac.  Intel Python 3.9.2 beats arm64 Python 3.9.2 or 3.10.0a6.  The problem is somewhere in the tkinter/Tcl/Tk layers or their connection to MacOS and arm64.  Python 3.7.3 on Raspberry OS (Linux) performs in the middle between slow MacOS and fast Windows.
The fastest configuration I found on the M1 Mac was Python 3.8.2 (Intel code) in combination with deprecated Tcl/Tk 8.5.9; that config was about 8x faster than 3.9.2 arm64 with Tcl/Tk 8.6.11.

The simplest qualitative performance test is just use 
>>> help('modules')   (in IDLE vs. python in a Terminal window) 
though my TerraLunar.py graphics program can give quantitative results.

The Turtle graphics demo programs in IDLE also perform slow on the M1 Mac.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43511>
_______________________________________

From report at bugs.python.org  Wed Mar 17 07:46:38 2021
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 17 Mar 2021 11:46:38 +0000
Subject: [issue42246] Implement PEP 626 -- Precise line numbers for debugging
In-Reply-To: <1604331162.26.0.596873070589.issue42246@roundup.psfhosted.org>
Message-ID: <1615981598.65.0.458875865706.issue42246@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
pull_requests: +23665
pull_request: https://github.com/python/cpython/pull/24902

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42246>
_______________________________________

From report at bugs.python.org  Wed Mar 17 08:16:09 2021
From: report at bugs.python.org (Fred Drake)
Date: Wed, 17 Mar 2021 12:16:09 +0000
Subject: [issue43353] Document that logging.getLevelName() can return a
 numeric value.
In-Reply-To: <1614600000.66.0.180359096956.issue43353@roundup.psfhosted.org>
Message-ID: <1615983369.34.0.376408259561.issue43353@roundup.psfhosted.org>


Fred Drake <fdrake at gmail.com> added the comment:


New changeset 9bdb5802361016704fb3434369741cc6c5e08f02 by Mariusz Felisiak in branch '3.8':
bpo-43353: Document that logging.getLevelName() accepts string representation of logging level. (GH-24693) (#24825)
https://github.com/python/cpython/commit/9bdb5802361016704fb3434369741cc6c5e08f02


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43353>
_______________________________________

From report at bugs.python.org  Wed Mar 17 08:18:34 2021
From: report at bugs.python.org (Mariusz Felisiak)
Date: Wed, 17 Mar 2021 12:18:34 +0000
Subject: [issue43353] Document that logging.getLevelName() can return a
 numeric value.
In-Reply-To: <1614600000.66.0.180359096956.issue43353@roundup.psfhosted.org>
Message-ID: <1615983514.71.0.528050393688.issue43353@roundup.psfhosted.org>


Change by Mariusz Felisiak <felisiak.mariusz at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43353>
_______________________________________

From report at bugs.python.org  Wed Mar 17 08:43:44 2021
From: report at bugs.python.org (Ivan Kravets)
Date: Wed, 17 Mar 2021 12:43:44 +0000
Subject: [issue43528] "connect_read_pipe" raises errors on Windows for STDIN
Message-ID: <1615985024.13.0.408410632002.issue43528@roundup.psfhosted.org>


New submission from Ivan Kravets <me at ikravets.com>:

Hi there,

It seems that "connect_read_pipe" is not implemented in ProactorEventLoop. Does it make sense to update docs in these places?
- https://docs.python.org/3/library/asyncio-platforms.html#windows
- https://docs.python.org/3/library/asyncio-eventloop.html#working-with-pipes 

Or, this is a bug?

# The code to reproduce

```
import asyncio
import sys


async def read_stdin():
    reader = asyncio.StreamReader()
    protocol = asyncio.StreamReaderProtocol(reader)
    await asyncio.get_running_loop().connect_read_pipe(lambda: protocol, sys.stdin)
    while True:
        line = await reader.readline()
        print("stdin > ", line)


async def main():
    task = asyncio.create_task(read_stdin())
    await asyncio.sleep(5)
    task.cancel()


if __name__ == "__main__":
    asyncio.run(main())
```

P.S: The "loop.add_reader()" raises "NotImplementedError" which is clear according to the docs.

Thanks in advance!

# Log

```
C:\Users\USER>.platformio\python3\python.exe test.py
Exception in callback _ProactorReadPipeTransport._loop_reading()
handle: <Handle _ProactorReadPipeTransport._loop_reading()>
Traceback (most recent call last):
  File "C:\Users\USER\.platformio\python3\lib\asyncio\proactor_events.py", line 299, in _loop_reading
    self._read_fut = self._loop._proactor.recv(self._sock, 32768)
  File "C:\Users\USER\.platformio\python3\lib\asyncio\windows_events.py", line 445, in recv
    self._register_with_iocp(conn)
  File "C:\Users\USER\.platformio\python3\lib\asyncio\windows_events.py", line 718, in _register_with_iocp
    _overlapped.CreateIoCompletionPort(obj.fileno(), self._iocp, 0, 0)
OSError: [WinError 6] The handle is invalid

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Users\USER\.platformio\python3\lib\asyncio\events.py", line 80, in _run
    self._context.run(self._callback, *self._args)
  File "C:\Users\USER\.platformio\python3\lib\asyncio\proactor_events.py", line 309, in _loop_reading
    self._fatal_error(exc, 'Fatal read error on pipe transport')
  File "C:\Users\USER\.platformio\python3\lib\asyncio\proactor_events.py", line 131, in _fatal_error
    self._force_close(exc)
  File "C:\Users\USER\.platformio\python3\lib\asyncio\proactor_events.py", line 134, in _force_close
    if self._empty_waiter is not None and not self._empty_waiter.done():
AttributeError: '_ProactorReadPipeTransport' object has no attribute '_empty_waiter'
Exception ignored in: <function _ProactorBasePipeTransport.__del__ at 0x000002181B927A60>
Traceback (most recent call last):
  File "C:\Users\USER\.platformio\python3\lib\asyncio\proactor_events.py", line 116, in __del__
    self.close()
  File "C:\Users\USER\.platformio\python3\lib\asyncio\proactor_events.py", line 108, in close
    self._loop.call_soon(self._call_connection_lost, None)
  File "C:\Users\USER\.platformio\python3\lib\asyncio\base_events.py", line 746, in call_soon
    self._check_closed()
  File "C:\Users\USER\.platformio\python3\lib\asyncio\base_events.py", line 510, in _check_closed
    raise RuntimeError('Event loop is closed')
RuntimeError: Event loop is closed
```

----------
components: asyncio
messages: 388919
nosy: asvetlov, ivankravets, yselivanov
priority: normal
severity: normal
status: open
title: "connect_read_pipe" raises errors on Windows for STDIN
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43528>
_______________________________________

From report at bugs.python.org  Wed Mar 17 09:01:45 2021
From: report at bugs.python.org (doublex)
Date: Wed, 17 Mar 2021 13:01:45 +0000
Subject: [issue43065] Delegating to thread and process deadlocks
In-Reply-To: <1611950599.0.0.548007285224.issue43065@roundup.psfhosted.org>
Message-ID: <1615986105.6.0.372408919482.issue43065@roundup.psfhosted.org>


Change by doublex <doppelbauer at gmx.net>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43065>
_______________________________________

From report at bugs.python.org  Wed Mar 17 09:55:18 2021
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 17 Mar 2021 13:55:18 +0000
Subject: [issue43352] Add a Barrier object in asyncio lib
In-Reply-To: <1614598796.36.0.0905111746151.issue43352@roundup.psfhosted.org>
Message-ID: <1615989318.33.0.454442272747.issue43352@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
nosy: +python-dev
nosy_count: 4.0 -> 5.0
pull_requests: +23666
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24903

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43352>
_______________________________________

From report at bugs.python.org  Wed Mar 17 10:14:59 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Mar 2021 14:14:59 +0000
Subject: [issue43503] [subinterpreters] PyObject statics exposed in the
 limited API break isolation.
In-Reply-To: <1615834423.72.0.113211272847.issue43503@roundup.psfhosted.org>
Message-ID: <1615990499.85.0.465494490529.issue43503@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Eric Snow proposes that C extensions which want to be compatible with subinterpreters must use an hypothetical variant of the C API which doesn't inherit flaws of the current C API. For example, static types like "&PyLong_Type" would be excluded.

To be clear, the limited C API does expose (indirectly) "&PyLong_Type". We are talking about a new variant of the C API.

The main interpreter would continue to use its static type "&PyLong_Type", whereas each subinterpreter would get its own "int" type allocated on the heap (heap type).

Someone has to write a PoC to ensure that this idea works in practice.

In bpo-40601, I proposed that all interpreters including the main interpreter only use heap types: remove "&PyLong_Type" from the C API which is a backward incompatible C API change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43503>
_______________________________________

From report at bugs.python.org  Wed Mar 17 10:19:10 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Mar 2021 14:19:10 +0000
Subject: [issue39511] [subinterpreters] Per-interpreter singletons (None, True,
 False, etc.)
In-Reply-To: <1580484815.27.0.407070570821.issue39511@roundup.psfhosted.org>
Message-ID: <1615990750.43.0.749403953288.issue39511@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Raymond Hettinger: "Shouldn't this wait to see if the subinterpreters PEP is approved?  Because if it isn't, then no chance should be made.  We shouldn't change something this fundamental without good cause."

I agree that we reached a point where a PEP is needed before pushing further "controversial" changes related to subinterpreters and bpo-1635741 (especially converting static types to heap types (bpo-40077).

I plan to write multiple PEPs:

* One general PEP about the idea of isolating subinterpreters to be able to run them in parallel, without requesting any specific technical change
* One PEP to solve the problem of static types like &PyLong_Type: see bpo-40601 and bpo-43503
* More PEPs for other controversial changes

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39511>
_______________________________________

From report at bugs.python.org  Wed Mar 17 10:40:20 2021
From: report at bugs.python.org (Eric Snow)
Date: Wed, 17 Mar 2021 14:40:20 +0000
Subject: [issue43503] [subinterpreters] PyObject statics exposed in the
 limited API break isolation.
In-Reply-To: <1615834423.72.0.113211272847.issue43503@roundup.psfhosted.org>
Message-ID: <1615992020.89.0.947811627826.issue43503@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

> I am confused. How can widening the usable number of functions (i.e. using
> the whole C-API rather than the limited API) help c-extension modules be
> usable in subinterpreters? Aren't the same singletons, exception types, and
> other types exposed in the full C-API?

If Py_LIMITED_API is defined then things would stay the same.  Otherwise we would replace the names with macros to do the appropriate lookup.  (That isn't the whole story since the Py*_Type names are PyTypeObject and not PyObject*.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43503>
_______________________________________

From report at bugs.python.org  Wed Mar 17 10:45:59 2021
From: report at bugs.python.org (Eric Snow)
Date: Wed, 17 Mar 2021 14:45:59 +0000
Subject: [issue43503] [subinterpreters] PyObject statics exposed in the
 limited API break isolation.
In-Reply-To: <1615834423.72.0.113211272847.issue43503@roundup.psfhosted.org>
Message-ID: <1615992359.08.0.548419184367.issue43503@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

> PEP 489 is *very much* part of the limited API.

Gah, I missed that.  That said, I don't think it matters; I just lose an easy point in the rationale. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43503>
_______________________________________

From report at bugs.python.org  Wed Mar 17 10:46:29 2021
From: report at bugs.python.org (Eric Snow)
Date: Wed, 17 Mar 2021 14:46:29 +0000
Subject: [issue43503] [subinterpreters] PyObject statics exposed in the
 limited API break isolation.
In-Reply-To: <1615834423.72.0.113211272847.issue43503@roundup.psfhosted.org>
Message-ID: <1615992389.26.0.633591448103.issue43503@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

FYI, I'm going to focus discussion on the capi-sig thread.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43503>
_______________________________________

From report at bugs.python.org  Wed Mar 17 10:54:20 2021
From: report at bugs.python.org (Steve Dower)
Date: Wed, 17 Mar 2021 14:54:20 +0000
Subject: [issue43284] Inability to fetch build 20H2
In-Reply-To: <1613904146.72.0.850542213327.issue43284@roundup.psfhosted.org>
Message-ID: <1615992860.66.0.569951234622.issue43284@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Yeah, that all makes sense. 90%+ of the time, checking the version number is a compatibility issue waiting to happen.

For the other 10% (diagnostic logging), it would be nice to have a better option than running "cmd /c ver", but that might be the easiest thing to do. I'd want to remove any pretence that the returned version is a comparable number, and I'm not sure how easily we can do that without hurting compatibility...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43284>
_______________________________________

From report at bugs.python.org  Wed Mar 17 10:55:32 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 17 Mar 2021 14:55:32 +0000
Subject: [issue43512] Bug in isinstance(instance,
 cls) with cls being a protocol? (PEP 544)
In-Reply-To: <1615962221.58.0.329747519097.issue43512@roundup.psfhosted.org>
Message-ID: <CAP7+vJJfuGCC-+aC7AOhONHgnKOu=vvHAhXOBAZ7P8Na2wbcdA@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

Yes, discussion on a close issue is still read, unless people explicitly
unsubscribe (which they rarely do unless the chatter is spam).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43512>
_______________________________________

From report at bugs.python.org  Wed Mar 17 10:59:47 2021
From: report at bugs.python.org (Ryan Hiebert)
Date: Wed, 17 Mar 2021 14:59:47 +0000
Subject: [issue29687] smtplib does not support proxy
In-Reply-To: <1488389372.28.0.822188705276.issue29687@psf.upfronthosting.co.za>
Message-ID: <1615993187.44.0.0248190516819.issue29687@roundup.psfhosted.org>


Change by Ryan Hiebert <ryan at ryanhiebert.com>:


----------
nosy: +ryanhiebert

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29687>
_______________________________________

From report at bugs.python.org  Wed Mar 17 11:23:36 2021
From: report at bugs.python.org (Eric Frederich)
Date: Wed, 17 Mar 2021 15:23:36 +0000
Subject: [issue43529] pathlib.Path.glob causes OSError encountering symlinks
 to long filenames
Message-ID: <1615994616.04.0.762651186772.issue43529@roundup.psfhosted.org>


New submission from Eric Frederich <eric.frederich at gmail.com>:

Calling pathlib.Path.glob("**/*) on a directory containing a symlink which resolves to a very long filename causes OSError.

This is completely avoidable since symlinks are not followed anyway.

In pathlib.py, the _RecursiveWildcardSelector has a method _iterate_directories which first calls entry.is_dir() prior to excluding based on entry.is_symlink().

It's the entry.is_dir() which is failing.
If the check for entry.is_symlink() were to happen first this error would be avoided.

It's worth noting that on Linux "ls -l bad_link" works fine.
Also "find /some/path/containing/bad/link" works fine.
You do get an error however when running "ls bad_link"
I believe Python's glob() should act like "find" on Linux and not fail.
Because it is explicitly ignoring symlinks anyway, it has no business calling is_dir() on a symlink.

I have attached a file which reproduces this problem.  It's meant to be ran inside of an empty directory.

----------
files: uhoh.py
messages: 388927
nosy: eric.frederich
priority: normal
severity: normal
status: open
title: pathlib.Path.glob causes OSError encountering symlinks to long filenames
Added file: https://bugs.python.org/file49884/uhoh.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43529>
_______________________________________

From report at bugs.python.org  Wed Mar 17 11:24:16 2021
From: report at bugs.python.org (Eric Frederich)
Date: Wed, 17 Mar 2021 15:24:16 +0000
Subject: [issue43529] pathlib.Path.glob causes OSError encountering symlinks
 to long filenames
In-Reply-To: <1615994616.04.0.762651186772.issue43529@roundup.psfhosted.org>
Message-ID: <1615994656.76.0.326342888869.issue43529@roundup.psfhosted.org>


Change by Eric Frederich <eric.frederich at gmail.com>:


----------
versions: +Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43529>
_______________________________________

From report at bugs.python.org  Wed Mar 17 11:37:01 2021
From: report at bugs.python.org (Eric Frederich)
Date: Wed, 17 Mar 2021 15:37:01 +0000
Subject: [issue43529] pathlib.Path.glob causes OSError encountering symlinks
 to long filenames
In-Reply-To: <1615994616.04.0.762651186772.issue43529@roundup.psfhosted.org>
Message-ID: <1615995421.97.0.337619266856.issue43529@roundup.psfhosted.org>


Eric Frederich <eric.frederich at gmail.com> added the comment:

I verified against all versions available for me to select.
For 3.10 I used the 3.10-rc Docker image.

----------
versions: +Python 3.10, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43529>
_______________________________________

From report at bugs.python.org  Wed Mar 17 11:45:56 2021
From: report at bugs.python.org (tzing)
Date: Wed, 17 Mar 2021 15:45:56 +0000
Subject: [issue43530] email.parser.BytesParser failed to parse mail when it is
 with BOM
Message-ID: <1615995956.48.0.229285559191.issue43530@roundup.psfhosted.org>


New submission from tzing <tzingshih at gmail.com>:

Python's builtin `email.parser.BytesParser` could not properly parse the message when the bytes starts with BOM.

Not 100% ensured- but this issue seems cause by that `FeedParser._parsegen` could not match any of the header line after the data is decoded.

Steps to reproduce:
1. get email sample. any from https://github.com/python/cpython/tree/master/Lib/test/test_email/data. I use msg_01.txt in following code
2. re-encoded the mail sample to some encoding with BOM
3. use `email.parser.BytesParser` to parse it

```py
import email
with open('msg_01.txt', 'rb') as fp:
    msg = email.parser.BytesParser().parse(fp)
print(msg.get('Message-ID'))
```

Expect output `<15090.61304.110929.45684 at aaa.zzz.org>`, got `None`

----------
components: Library (Lib)
messages: 388929
nosy: tzing
priority: normal
severity: normal
status: open
title: email.parser.BytesParser failed to parse mail when it is with BOM
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43530>
_______________________________________

From report at bugs.python.org  Wed Mar 17 11:58:32 2021
From: report at bugs.python.org (Larry Trammell)
Date: Wed, 17 Mar 2021 15:58:32 +0000
Subject: [issue43483] Loss of content in simple (but oversize) SAX parsing
In-Reply-To: <1615599352.35.0.560655392831.issue43483@roundup.psfhosted.org>
Message-ID: <1615996712.23.0.50583179515.issue43483@roundup.psfhosted.org>


Larry Trammell <ridgerat at nwi.net> added the comment:

Assuming that my understanding is completely correct, the situation is that the xml parser has an unspecified behavior.  This is true in any text content handler, at any time, and applies to the expat parser as well as SAX. In some rare cases, the behavior of the current implementation (and also many past ones) sometimes seems inconsistent and can catch users by surprise -- even some who are relatively knowledgable (which does not include me). 

This is a little abstract, but two things could be done to improve this:

1. Modify the implementation so that the behavior remains unspecified but falls more in line with plausible expectations of the users.  This makes things a little more complicated for the implementer, but does not invalidate the documentation of present or past versions. 

2. The documentation could be updated to expose the new constraints on the previously unspecified behavior, giving users a better chance to recognize and prepare for any remaining difficulties.  However, the implementation changes could be made even without these documentation changes.

So I remain confused about whether this is really a "bug" -- it is an "easy but unfortunate implementation choice" that is technically not wrong, even if sometimes baffling.  Established applications that already use older parser versions are relatively unlikely to start failing given the kind of documents they process, so backport changes might be helpful but do not seem urgent. 

Eric, with this clarification, what is your opinion about how to properly post a new issue -- improvement or bug fix?  I can provide a more detailed technical explanation where a new issue is posted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43483>
_______________________________________

From report at bugs.python.org  Wed Mar 17 12:01:16 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 17 Mar 2021 16:01:16 +0000
Subject: [issue39511] [subinterpreters] Per-interpreter singletons (None, True,
 False, etc.)
In-Reply-To: <1580484815.27.0.407070570821.issue39511@roundup.psfhosted.org>
Message-ID: <1615996875.99.0.000115162887953.issue39511@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/issue39511>
_______________________________________

From report at bugs.python.org  Wed Mar 17 12:06:02 2021
From: report at bugs.python.org (Adrian LeDeaux)
Date: Wed, 17 Mar 2021 16:06:02 +0000
Subject: [issue43531] Turtle module does not work
Message-ID: <1615997162.13.0.111429479171.issue43531@roundup.psfhosted.org>


New submission from Adrian LeDeaux <aledeaux at gmail.com>:

So when I try to do the command "import turtle" all I get back is: 

Traceback (most recent call last):
  File "<pyshell#4>", line 1, in <module>
    import turtle
  File "/Users/Virsatech/Documents/turtle.py", line 2, in <module>
    t = turtle.Pen()
AttributeError: partially initialized module 'turtle' has no attribute 'Pen' (most likely due to a circular import)

that error exactly. And I have tried many times. Anyone know how to fix?

----------
assignee: terry.reedy
components: IDLE
messages: 388931
nosy: aledeaux, terry.reedy
priority: normal
severity: normal
status: open
title: Turtle module does not work
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43531>
_______________________________________

From report at bugs.python.org  Wed Mar 17 12:12:47 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 17 Mar 2021 16:12:47 +0000
Subject: [issue43483] Loss of content in simple (but oversize) SAX parsing
In-Reply-To: <1615599352.35.0.560655392831.issue43483@roundup.psfhosted.org>
Message-ID: <1615997567.25.0.718593374667.issue43483@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Could you give an example (using a list of callbacks and values or something) that shows how it's behaving that you think is problematic? That's the part I'm not understanding. This doesn't have to be a real example, just show what the user is getting that's not obvious to the normal user.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43483>
_______________________________________

From report at bugs.python.org  Wed Mar 17 12:14:57 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 17 Mar 2021 16:14:57 +0000
Subject: [issue43531] Turtle module does not work
In-Reply-To: <1615997162.13.0.111429479171.issue43531@roundup.psfhosted.org>
Message-ID: <1615997697.03.0.777264561276.issue43531@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

You have a local file named `turtle.py`, which is conflicting with the standard library `turtle` module.  Rename your local file to something else, then you'll be able to import the standard library `turtle` module.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43531>
_______________________________________

From report at bugs.python.org  Wed Mar 17 12:16:10 2021
From: report at bugs.python.org (Adrian LeDeaux)
Date: Wed, 17 Mar 2021 16:16:10 +0000
Subject: [issue43531] Turtle module does not work
In-Reply-To: <1615997162.13.0.111429479171.issue43531@roundup.psfhosted.org>
Message-ID: <1615997770.88.0.765631831068.issue43531@roundup.psfhosted.org>


Adrian LeDeaux <aledeaux at gmail.com> added the comment:

Oh, OK. I am not an expert on python so I did not understand the error. Thanks for the help, and I will update you if the problems continue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43531>
_______________________________________

From report at bugs.python.org  Wed Mar 17 12:20:32 2021
From: report at bugs.python.org (Christoph Anton Mitterer)
Date: Wed, 17 Mar 2021 16:20:32 +0000
Subject: [issue43336] document whether io.TextIOBase.readline(size>0) will
 always read the full newline
In-Reply-To: <1614392137.45.0.448589201829.issue43336@roundup.psfhosted.org>
Message-ID: <1615998032.85.0.931810125273.issue43336@roundup.psfhosted.org>


Christoph Anton Mitterer <calestyo at scientia.org> added the comment:

I guess that the translation from CRLF to LF simply happens before the size restriction is enforced (which is good so, btw), so effectively it:

will not *read* at most size characters from the stream, but *return* at most size characters from it (with any newlines translated before, and thus more characters read from the stream than returned)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43336>
_______________________________________

From report at bugs.python.org  Wed Mar 17 12:21:27 2021
From: report at bugs.python.org (Adrian LeDeaux)
Date: Wed, 17 Mar 2021 16:21:27 +0000
Subject: [issue43531] Turtle module does not work
In-Reply-To: <1615997162.13.0.111429479171.issue43531@roundup.psfhosted.org>
Message-ID: <1615998087.6.0.401562579636.issue43531@roundup.psfhosted.org>


Adrian LeDeaux <aledeaux at gmail.com> added the comment:

That fixed it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43531>
_______________________________________

From report at bugs.python.org  Wed Mar 17 12:26:11 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 17 Mar 2021 16:26:11 +0000
Subject: [issue43531] Turtle module does not work
In-Reply-To: <1615997162.13.0.111429479171.issue43531@roundup.psfhosted.org>
Message-ID: <1615998371.02.0.248705554264.issue43531@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/issue43531>
_______________________________________

From report at bugs.python.org  Wed Mar 17 12:26:37 2021
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 17 Mar 2021 16:26:37 +0000
Subject: [issue43284] Inability to fetch build 20H2
In-Reply-To: <1613904146.72.0.850542213327.issue43284@roundup.psfhosted.org>
Message-ID: <1615998397.24.0.600426738723.issue43284@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> For the other 10% (diagnostic logging), it would be nice to have a
> better option than running "cmd /c ver"

CMD's VER command (cmd!eVersion) calls GetVersion(), for which, in its case, the API calls the internal function GetVersion_Current(). The VER command also reads the UBR value (update build revision) directly from the registry.

Other than using CMD, I suppose there's the option of creating an extension module in C++ that gets the Win32_OperatingSystem WMI data, which includes the "major.minor.build" version string. But that's much more complicated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43284>
_______________________________________

From report at bugs.python.org  Wed Mar 17 12:56:50 2021
From: report at bugs.python.org (Larry Trammell)
Date: Wed, 17 Mar 2021 16:56:50 +0000
Subject: [issue43483] Loss of content in simple (but oversize) SAX parsing
In-Reply-To: <1615599352.35.0.560655392831.issue43483@roundup.psfhosted.org>
Message-ID: <1616000210.8.0.758372363558.issue43483@roundup.psfhosted.org>


Larry Trammell <ridgerat at nwi.net> added the comment:

Sure...  I'll cut and paste some of the text I was organizing to go into a possible new issue page.

The only relevant documentation I could find was in the "xml.sax.handler" page in the Python 3.9.2 Documentation for the Python Standard Library (as it has been through many versions):

-----------
ContentHandler.characters(content) -- The Parser will call this method to report each chunk of character data.  SAX parsers may return all contiguous character data in a single chunk, or they may split it into several chunks...
-----------

As an example, here is a typical snippet taken from Web page

     https://www.tutorialspoint.com/parsing-xml-with-sax-apis-in-python 

The application example records the tag name "type" in the "CurrentData" member, and shortly thereafter, the "type" tag's content is received:

   # Call when a character is read
   def characters(self, content):
      if self.CurrentData == "type":
         self.type = content

Suppose that the parser receives the following text line from the input file.  

<type>SciFi</type>

Though there seems no reason for it, the parser could decide to deliver the content text as "Sc" followed by "iFi".  In that case, a second invocation of the "characters" method would overwrite the characters received in the first invocation, and some of the content text seems "lost."  

Given how rarely it happens, I suspect that when internal processing reaches the end of a block of buffered text from the input file, the easiest thing to do is to report any fragments of text that happen to remain at the end, no matter how tiny, and start fresh with the next internal buffer. Easy for the implementer, but baffling to the application developer.  And rare enough to elude application testing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43483>
_______________________________________

From report at bugs.python.org  Wed Mar 17 13:04:22 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 17 Mar 2021 17:04:22 +0000
Subject: [issue43483] Loss of content in simple (but oversize) SAX parsing
In-Reply-To: <1615599352.35.0.560655392831.issue43483@roundup.psfhosted.org>
Message-ID: <1616000662.19.0.654399177981.issue43483@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Thanks, that's very helpful. Does this only affect content text?

This should definitely be documented.

As far as changing it, I think the best thing to do is say that if the context text is less than some size (I don't know, maybe 1MB?) that it's guaranteed to be in one callback, but if it's larger than that it might be in multiple chunks. I think you could open this as a feature request. I have no idea how difficult or expensive it would be to implement this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43483>
_______________________________________

From report at bugs.python.org  Wed Mar 17 13:14:44 2021
From: report at bugs.python.org (Larry Trammell)
Date: Wed, 17 Mar 2021 17:14:44 +0000
Subject: [issue43483] Loss of content in simple (but oversize) SAX parsing
In-Reply-To: <1615599352.35.0.560655392831.issue43483@roundup.psfhosted.org>
Message-ID: <1616001284.51.0.286703067814.issue43483@roundup.psfhosted.org>


Larry Trammell <ridgerat at nwi.net> added the comment:

Great minds think alike I guess... 

I was thinking of a much smaller carryover size... maybe 1K. With individual text blocks longer than that, the user will almost certainly be dealing with collecting and aggregating content text anyway, and in that case, the problem is solved before it happens. 

Here is a documentation change I was experimenting with...

-----------
ContentHandler.characters(content) -- The Parser will call this method to report chunks of character data.  In general, character data may be reported as a single chunk or as sequence of chunks; but character data sequences with fewer than  xml.sax.handler.ContiguousChunkLength characters, when uninterrupted any other xml.sax.handler.ContentHandler event, are guaranteed to be delivered as a single chunk...  
-----------

That puts users on notice, "...wait, are my chunks of text smaller than that?" and they are less likely to be caught unaware.  But of course, the implementation change would be helpful even without this extra warning.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43483>
_______________________________________

From report at bugs.python.org  Wed Mar 17 13:15:29 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 17 Mar 2021 17:15:29 +0000
Subject: [issue43471] Fails to import bz2 on Ubuntu
In-Reply-To: <1615447237.87.0.642854040325.issue43471@roundup.psfhosted.org>
Message-ID: <1616001329.62.0.218884819363.issue43471@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I'm going to close this. @xmm: If you can provide more information showing that this is a bug in Python or its build process, please re-open this issue.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43471>
_______________________________________

From report at bugs.python.org  Wed Mar 17 13:18:00 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 17 Mar 2021 17:18:00 +0000
Subject: [issue43483] Loss of content in simple (but oversize) SAX parsing
In-Reply-To: <1615599352.35.0.560655392831.issue43483@roundup.psfhosted.org>
Message-ID: <1616001480.39.0.566004729123.issue43483@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I think that's good text, once the enhancement is made. But for existing versions of python, shouldn't we just document that the text might come back in chunks?

I don't have a feel for what the limit should be.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43483>
_______________________________________

From report at bugs.python.org  Wed Mar 17 13:19:26 2021
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 17 Mar 2021 17:19:26 +0000
Subject: [issue43477] from x import * behavior inconsistent between module
 types.
In-Reply-To: <1615509638.08.0.549124406797.issue43477@roundup.psfhosted.org>
Message-ID: <1616001566.98.0.842507619819.issue43477@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Having `test_pkg.test_submodule` be set after your import based on the sequence of imports your example executes is entirely expected and a side-effect of how import is (at least now) designed. So I disagree with the assessment "that nothing here was requested by the user", since imports have side-effects, and one of those is setting submodules as attributes on packages post-import.

Thanks for the report and all the details, Thomas, but I am still going to close this as not a bug.

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43477>
_______________________________________

From report at bugs.python.org  Wed Mar 17 13:19:44 2021
From: report at bugs.python.org (Steve Dower)
Date: Wed, 17 Mar 2021 17:19:44 +0000
Subject: [issue43284] Inability to fetch build 20H2
In-Reply-To: <1613904146.72.0.850542213327.issue43284@roundup.psfhosted.org>
Message-ID: <1616001584.29.0.970161427354.issue43284@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

CMD is not going to be subjected to compatibility shims that hide the version number, and I *think* those are not inherited by child processes. So it can use the basic APIs. (It's also likely to be the comparison that most people will check against.)

I agree that using WMI is probably overkill. PyWin32 or a new extension module could handle it for people who have a more urgent need.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43284>
_______________________________________

From report at bugs.python.org  Wed Mar 17 13:19:40 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 17 Mar 2021 17:19:40 +0000
Subject: [issue43531] Turtle module does not work
In-Reply-To: <1615997162.13.0.111429479171.issue43531@roundup.psfhosted.org>
Message-ID: <1616001580.51.0.933763005801.issue43531@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

For next time, the turtle module is not part of IDLE.

----------
assignee: terry.reedy -> 
components: +Library (Lib) -IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43531>
_______________________________________

From report at bugs.python.org  Wed Mar 17 13:20:17 2021
From: report at bugs.python.org (Larry Trammell)
Date: Wed, 17 Mar 2021 17:20:17 +0000
Subject: [issue43483] Loss of content in simple (but oversize) SAX parsing
In-Reply-To: <1615599352.35.0.560655392831.issue43483@roundup.psfhosted.org>
Message-ID: <1616001617.14.0.342974450307.issue43483@roundup.psfhosted.org>


Larry Trammell <ridgerat at nwi.net> added the comment:

Oh, and whether this affects only content text...

I would presume so, but I don't know how to tell for sure.  Unspecified behaviors can be very mysterious!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43483>
_______________________________________

From report at bugs.python.org  Wed Mar 17 13:24:26 2021
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 17 Mar 2021 17:24:26 +0000
Subject: [issue29687] smtplib does not support proxy
In-Reply-To: <1488389372.28.0.822188705276.issue29687@psf.upfronthosting.co.za>
Message-ID: <1616001866.7.0.249000469221.issue29687@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

The Python standard library has no builtin support for socks proxy. I suggest that you report issues with socks library to the author of the package.

By the way the smptlib makes it really easy to override the socket object with a custom implementation:

class SocksSMTP(smtplib.SMTP):
    def _get_socket(self, host, port, timeout):
        return some_socket_like_object(...)

----------
nosy: +christian.heimes
resolution:  -> third party
stage:  -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29687>
_______________________________________

From report at bugs.python.org  Wed Mar 17 13:33:36 2021
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 17 Mar 2021 17:33:36 +0000
Subject: [issue34535] queue.Queue(timeout=0.001) avg delay Windows:14.5ms,
 Ubuntu: 0.063ms
In-Reply-To: <1535484021.65.0.56676864532.issue34535@psf.upfronthosting.co.za>
Message-ID: <1616002416.14.0.777535977948.issue34535@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

See the related discussion in bpo-41299. The system interrupt period can be lowered to 1 ms with timeBeginPeriod() -- or lower with undocumented NtSetTimerResolution(). This affects the resolution of dispatcher waits such as Sleep() and WaitForSingleObject(), as well as the resolution of Query[Unbiased]InterruptTime(). But apparently GetTickCount[64]() has a fixed update frequency of 64 ticks/second (15.625 ms period), regardless of the system interrupt period. The combination of WaitForSingleObject() with GetTickCount64() has marginally better resolution and consistent performance if the system interrupt period is lowered to 1 ms.

If a wait needs to be resumable in order to handle SIGINT, and it should perform consistently with other waits, then there are two choices. One option is to base the timeout on Query[Unbiased]InterruptTime(), for which the resolution depends on the system interrupt period. Conversely, if we want all waits to perform consistently and independent of the system interrupt period, then they should all depend on GetTickCount64(). This could be implemented in one place, such as Modules/signalmodule.c, with the addition of _Py_Sleep(), Py_WaitForSingleObject(), and _Py_WaitForMultipleObjects(). On the main thread, these wait functions would include the SIGINT event and resume the wait if the SIGINT handler doesn't raise an exception.

----------
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34535>
_______________________________________

From report at bugs.python.org  Wed Mar 17 13:39:21 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 17 Mar 2021 17:39:21 +0000
Subject: [issue43532] Add keyword-only fields to dataclasses
Message-ID: <1616002761.92.0.652624260802.issue43532@roundup.psfhosted.org>


New submission from Eric V. Smith <eric at trueblade.com>:

The idea is that a keyword-only field becomes a keyword-only argument to __init__().

For the proposal and a discussion, see https://mail.python.org/archives/list/python-ideas at python.org/message/FI6KS4O67XDEIDYOFWCXMDLDOSCNSEYG/

The @dataclass decorator will get a new parameter, kw_only, which defaults to False. If kw_only=True, all fields in the dataclass will be by efault keyword-only. In addition, field() will have a new kw_only parameter. If true, the field will be keyword-only. If false, it will not be keyword-only. If unspecified, it will use the value of dataclass's kw_only parameter.

In addition, a module-level variable KW_ONLY will be added. If a field has this type, then all fields after it will default to kw_only=True. The field is otherwise completely ignored.

Examples:

@dataclasses.dataclass
class A:
    a: Any = field(kw_only=True) 

Will have __init__(self, *, a)

@dataclasses.dataclass(kw_only=True)
class B:
    a: Any
    b: Any 

Will have __init__(self, *, a, b)

@dataclasses.dataclass
class C:
    a: Any
    _: dataclasses.KW_ONLY
    b: Any
    c: Any

Will have __init__(self, a, *, b, c)

If any non-keyword-only parameters are present, they will be moved before all keyword-only parameters, only for the generated __init__. All other generated methods (__repr__, __lt__, etc.) will keep fields in the declared order, which is the case in versions 3.9 and earlier.

@dataclasses.dataclass
class D:
    a: Any
    b: Any = field(kw_only=True)
    c: Any

Will have __init__(self, a, c, *, b)

PR to follow.

----------
assignee: eric.smith
components: Library (Lib)
messages: 388949
nosy: eric.smith
priority: normal
severity: normal
status: open
title: Add keyword-only fields to dataclasses
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43532>
_______________________________________

From report at bugs.python.org  Wed Mar 17 13:44:41 2021
From: report at bugs.python.org (Steve Dower)
Date: Wed, 17 Mar 2021 17:44:41 +0000
Subject: [issue34535] queue.Queue(timeout=0.001) avg delay Windows:14.5ms,
 Ubuntu: 0.063ms
In-Reply-To: <1535484021.65.0.56676864532.issue34535@psf.upfronthosting.co.za>
Message-ID: <1616003081.26.0.327035489085.issue34535@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Given that extra info, I'd say we're fine to document that our timeouts can't do any better than the OS, which "for example, is typically around 15ms on Windows", and recommend using non-blocking calls instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34535>
_______________________________________

From report at bugs.python.org  Wed Mar 17 14:10:34 2021
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 17 Mar 2021 18:10:34 +0000
Subject: [issue43532] Add keyword-only fields to dataclasses
In-Reply-To: <1616002761.92.0.652624260802.issue43532@roundup.psfhosted.org>
Message-ID: <1616004634.04.0.18390819866.issue43532@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This looks like a duplicate of https://bugs.python.org/issue33129 or that ticket can be closed.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43532>
_______________________________________

From report at bugs.python.org  Wed Mar 17 14:19:37 2021
From: report at bugs.python.org (Larry Trammell)
Date: Wed, 17 Mar 2021 18:19:37 +0000
Subject: [issue43483] Loss of content in simple (but oversize) SAX parsing
In-Reply-To: <1615599352.35.0.560655392831.issue43483@roundup.psfhosted.org>
Message-ID: <1616005177.97.0.664888431094.issue43483@roundup.psfhosted.org>


Larry Trammell <ridgerat at nwi.net> added the comment:

I think the existing ContentHandler.characters(content) documentation DOES say that the text can come back in chunks... but it is subtle.  It might be possible to say more explicitly that any content no matter how small is allowed to be returned as any number of chunks at any time... Though true, that is harsh, overstating considerably what actually happens.   Concentrating on a better implementation would be more effective than worrying about existing documentation, given how long the existing conditions have prevailed. My opinion, as one who has been bitten.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43483>
_______________________________________

From report at bugs.python.org  Wed Mar 17 14:21:09 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 17 Mar 2021 18:21:09 +0000
Subject: [issue33129] Add kwarg-only option to dataclass
In-Reply-To: <1521847997.9.0.467229070634.issue33129@psf.upfronthosting.co.za>
Message-ID: <1616005269.14.0.618890847905.issue33129@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Closing this in favor of issue 43532, which has a slightly elaborated approach.

----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> Add keyword-only fields to dataclasses

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33129>
_______________________________________

From report at bugs.python.org  Wed Mar 17 14:26:46 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 17 Mar 2021 18:26:46 +0000
Subject: [issue43499] Compiler warnings in building Python 3.9 on Windows
In-Reply-To: <1615810323.65.0.00918597187884.issue43499@roundup.psfhosted.org>
Message-ID: <1616005606.61.0.950170244651.issue43499@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset db733761060be92915b5f5cba209dcaada88f94e by Ammar Askar in branch '3.9':
[3.9] bpo-43499: Restrict co_code to be under INT_MAX in codeobject (GH-20628) (GH-24896)
https://github.com/python/cpython/commit/db733761060be92915b5f5cba209dcaada88f94e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43499>
_______________________________________

From report at bugs.python.org  Wed Mar 17 14:27:30 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 17 Mar 2021 18:27:30 +0000
Subject: [issue43499] Compiler warnings in building Python 3.9 on Windows
In-Reply-To: <1615810323.65.0.00918597187884.issue43499@roundup.psfhosted.org>
Message-ID: <1616005650.94.0.716281086471.issue43499@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you Ammar.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43499>
_______________________________________

From report at bugs.python.org  Wed Mar 17 14:35:23 2021
From: report at bugs.python.org (Adrian LeDeaux)
Date: Wed, 17 Mar 2021 18:35:23 +0000
Subject: [issue43531] Turtle module does not work
In-Reply-To: <1615997162.13.0.111429479171.issue43531@roundup.psfhosted.org>
Message-ID: <1616006123.0.0.229348443141.issue43531@roundup.psfhosted.org>


Adrian LeDeaux <aledeaux at gmail.com> added the comment:

OK.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43531>
_______________________________________

From report at bugs.python.org  Wed Mar 17 14:48:42 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 17 Mar 2021 18:48:42 +0000
Subject: [issue43511] tkinter with Tk 8.6.11 is slow on macOS
In-Reply-To: <1615875194.4.0.35991043769.issue43511@roundup.psfhosted.org>
Message-ID: <1616006922.79.0.0713829511628.issue43511@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The result of help('modules') depends on Python version. Do you have any example which does not depend on Python version?

Could you also run some pure Tcl/Tk demos to check whether the difference is in Tcl/Tk instead of the wrapper?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43511>
_______________________________________

From report at bugs.python.org  Wed Mar 17 14:51:03 2021
From: report at bugs.python.org (Ryan Hiebert)
Date: Wed, 17 Mar 2021 18:51:03 +0000
Subject: [issue29687] smtplib does not support proxy
In-Reply-To: <1488389372.28.0.822188705276.issue29687@psf.upfronthosting.co.za>
Message-ID: <1616007063.38.0.0571187159782.issue29687@roundup.psfhosted.org>


Ryan Hiebert <ryan at ryanhiebert.com> added the comment:

Thank you, Christian. It sounds like you believe that we should view the `_get_socket` method as a public interface? That at least makes it possible to use a proxy socket through an appropriate mechanism, which solves my use-case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29687>
_______________________________________

From report at bugs.python.org  Wed Mar 17 14:56:17 2021
From: report at bugs.python.org (Larry Trammell)
Date: Wed, 17 Mar 2021 18:56:17 +0000
Subject: [issue43483] Loss of content in simple (but oversize) SAX parsing
In-Reply-To: <1615599352.35.0.560655392831.issue43483@roundup.psfhosted.org>
Message-ID: <1616007377.97.0.60802504335.issue43483@roundup.psfhosted.org>


Larry Trammell <ridgerat at nwi.net> added the comment:

If there were a decision NOT TO FIX... maybe then it would make sense to consider documentation patches at a higher priority.  That way, SAX-Python (and expat-Python) tutorials across the Web could start patching their presentations accordingly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43483>
_______________________________________

From report at bugs.python.org  Wed Mar 17 15:01:48 2021
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 17 Mar 2021 19:01:48 +0000
Subject: [issue29687] smtplib does not support proxy
In-Reply-To: <1488389372.28.0.822188705276.issue29687@psf.upfronthosting.co.za>
Message-ID: <1616007708.84.0.254462185687.issue29687@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

It's not a public API but it's a stable API. It hasn't changed since Python 2.6 and commit 366d6262f81 from 2007. It's unlikely to change in the near future.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29687>
_______________________________________

From report at bugs.python.org  Wed Mar 17 15:06:40 2021
From: report at bugs.python.org (Kamil Turek)
Date: Wed, 17 Mar 2021 19:06:40 +0000
Subject: [issue43532] Add keyword-only fields to dataclasses
In-Reply-To: <1616002761.92.0.652624260802.issue43532@roundup.psfhosted.org>
Message-ID: <1616008000.92.0.684527206848.issue43532@roundup.psfhosted.org>


Change by Kamil Turek <kamil.turek at hotmail.com>:


----------
nosy: +kamilturek

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43532>
_______________________________________

From report at bugs.python.org  Wed Mar 17 15:16:59 2021
From: report at bugs.python.org (Ryan Hiebert)
Date: Wed, 17 Mar 2021 19:16:59 +0000
Subject: [issue43532] Add keyword-only fields to dataclasses
In-Reply-To: <1616002761.92.0.652624260802.issue43532@roundup.psfhosted.org>
Message-ID: <1616008619.99.0.872805572576.issue43532@roundup.psfhosted.org>


Change by Ryan Hiebert <ryan at ryanhiebert.com>:


----------
nosy: +ryanhiebert

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43532>
_______________________________________

From report at bugs.python.org  Wed Mar 17 15:29:15 2021
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 17 Mar 2021 19:29:15 +0000
Subject: [issue34535] queue.Queue(timeout=0.001) avg delay Windows:14.5ms,
 Ubuntu: 0.063ms
In-Reply-To: <1535484021.65.0.56676864532.issue34535@psf.upfronthosting.co.za>
Message-ID: <1616009355.31.0.333334772861.issue34535@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> Given that extra info, I'd say we're fine to document that our timeouts 
> can't do any better than the OS, which "for example, is typically 
> around 15ms on Windows", and recommend using non-blocking calls 
> instead.

The 15.625 ms resolution limit is fine, as long as performance is predictable. I don't like the random inconsistency introduced by extending only certain waits, in different ways, to support SIGINT and/or waits longer than 49.7 days. For example, time.sleep() doesn't ignore WAIT_TIMEOUT to recompute the remaining time, so it's not subject to the resolution limit that's imposed by GetTickCount64().

I'd prefer a common implementation of _Py_Sleep, _Py_WaitForSingleObject, and _Py_WaitForMultiple objects in order to be able to definitively state that all wait timeouts are unconditionally limited to the resolution reported by time.get_clock_info('monotonic').resolution; are not limited to 49.7 days; and can be interrupted by Ctrl+C in the main thread -- except for waiting on I/O. (There's an open issue to enable Ctrl+C to cancel synchronous I/O in the main thread -- such as reading from a pipe.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34535>
_______________________________________

From report at bugs.python.org  Wed Mar 17 15:35:38 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Mar 2021 19:35:38 +0000
Subject: [issue34535] queue.Queue(timeout=0.001) avg delay Windows:14.5ms,
 Ubuntu: 0.063ms
In-Reply-To: <1535484021.65.0.56676864532.issue34535@psf.upfronthosting.co.za>
Message-ID: <1616009738.99.0.257735149244.issue34535@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34535>
_______________________________________

From report at bugs.python.org  Wed Mar 17 15:40:43 2021
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 17 Mar 2021 19:40:43 +0000
Subject: [issue21822] KeyboardInterrupt during Thread.join hangs that Thread
In-Reply-To: <1403365475.16.0.757881205569.issue21822@psf.upfronthosting.co.za>
Message-ID: <1616010043.7.0.958066258457.issue21822@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
components: +Extension Modules, Interpreter Core
versions: +Python 3.10, Python 3.9 -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21822>
_______________________________________

From report at bugs.python.org  Wed Mar 17 15:49:01 2021
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 17 Mar 2021 19:49:01 +0000
Subject: [issue42855] pathlib.exists on Windows raises an exception on URL
 like/bad input
In-Reply-To: <1610011401.69.0.814272139734.issue42855@roundup.psfhosted.org>
Message-ID: <1616010541.67.0.105664828809.issue42855@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
components: +Library (Lib)
versions:  -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42855>
_______________________________________

From report at bugs.python.org  Wed Mar 17 15:50:33 2021
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 17 Mar 2021 19:50:33 +0000
Subject: [issue43395] os.path states that bytes can't represent all MBCS paths
 under Windows
In-Reply-To: <1614839485.4.0.948731177165.issue43395@roundup.psfhosted.org>
Message-ID: <1616010633.84.0.343662723839.issue43395@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
versions:  -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43395>
_______________________________________

From report at bugs.python.org  Wed Mar 17 15:57:39 2021
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 17 Mar 2021 19:57:39 +0000
Subject: [issue32451] venv activate bash script has wrong line endings in
 Windows
In-Reply-To: <1514607229.33.0.213398074469.issue32451@psf.upfronthosting.co.za>
Message-ID: <1616011059.02.0.778185339545.issue32451@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

The POSIX "Lib/venv/scripts/common/activate" script needs a line-ending exception in ".gitattributes":

https://github.com/python/cpython/blob/master/.gitattributes

----------
title: python -m venv activation issue when using cygwin on windows -> venv activate bash script has wrong line endings in Windows
versions: +Python 3.10, Python 3.9 -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32451>
_______________________________________

From report at bugs.python.org  Wed Mar 17 15:58:00 2021
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 17 Mar 2021 19:58:00 +0000
Subject: [issue43437] venv activate bash script has wrong line endings on
 windows
In-Reply-To: <1615227420.16.0.158256767394.issue43437@roundup.psfhosted.org>
Message-ID: <1616011080.98.0.275689168925.issue43437@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> venv activate bash script has wrong line endings in Windows

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43437>
_______________________________________

From report at bugs.python.org  Wed Mar 17 16:14:04 2021
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 17 Mar 2021 20:14:04 +0000
Subject: [issue39340] shutil.rmtree and write protected files
In-Reply-To: <1579080933.31.0.376881618975.issue39340@roundup.psfhosted.org>
Message-ID: <1616012044.04.0.371725685466.issue39340@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> What I would expect is a consistent behaviour and as a 
> user I am not interested in inner guts of differences 
> between filesystems.

It's already consistent. msg360033 contains a misunderstanding about what write permission on a file means in Unix. The parent directory controls whether a file can be unlinked -- except for immutable files. For example:

    $ mkdir test; touch test/file.txt; chmod -w test
    $ python3.8 -c "import shutil; shutil.rmtree('test')"
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/usr/lib/python3.8/shutil.py", line 715, in rmtree
        _rmtree_safe_fd(fd, path, onerror)
      File "/usr/lib/python3.8/shutil.py", line 672, in _rmtree_safe_fd
        onerror(os.unlink, fullname, sys.exc_info())
      File "/usr/lib/python3.8/shutil.py", line 670, in _rmtree_safe_fd
        os.unlink(entry.name, dir_fd=topfd)
    PermissionError: [Errno 13] Permission denied: 'file.txt'

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39340>
_______________________________________

From report at bugs.python.org  Wed Mar 17 16:27:43 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 17 Mar 2021 20:27:43 +0000
Subject: [issue40521] [subinterpreters] Make free lists and unicode caches
 per-interpreter
In-Reply-To: <1588693682.5.0.219755904926.issue40521@roundup.psfhosted.org>
Message-ID: <1616012863.76.0.940763522067.issue40521@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/issue40521>
_______________________________________

From report at bugs.python.org  Wed Mar 17 16:34:09 2021
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 17 Mar 2021 20:34:09 +0000
Subject: [issue33240] shutil.rmtree fails if inner folder is open in Windows
 Explorer
In-Reply-To: <1523155916.86.0.682650639539.issue33240@psf.upfronthosting.co.za>
Message-ID: <1616013249.13.0.810695243275.issue33240@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> Explorer keeps handles open to directories to get updates via
> ReadDirectoryChangesExW. It opens watched directories with 
> shared delete access, so deleting the child succeeds. But as 
> discussed above, the directory isn't unlinked from the parent
> until Explorer closes its handle.

In Windows 10, NTFS allows deleting an empty directory that's currently opened with shared-delete access, so this race condition will be increasingly less common. For example:

    access = GENERIC_READ
    sharing = FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE
    disposition = OPEN_EXISTING
    flags = FILE_FLAG_BACKUP_SEMANTICS

    os.mkdir('spam')
    h = CreateFile('spam', access, sharing, None, disposition, flags, None)
    os.rmdir('spam')

    >>> print(GetFinalPathNameByHandle(h, 0))
    \\?\C:\$Extend\$Deleted\004E00000000632F70819337

FAT filesystems do not support this capability, and may never support it, so the problem hasn't gone away completely.

----------
versions: +Python 3.10, Python 3.9 -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33240>
_______________________________________

From report at bugs.python.org  Wed Mar 17 16:35:59 2021
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 17 Mar 2021 20:35:59 +0000
Subject: [issue33240] shutil.rmtree fails if inner folder is open in Windows
 Explorer
In-Reply-To: <1523155916.86.0.682650639539.issue33240@psf.upfronthosting.co.za>
Message-ID: <1616013359.72.0.281009155333.issue33240@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
components:  -IO

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33240>
_______________________________________

From report at bugs.python.org  Wed Mar 17 16:47:01 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Mar 2021 20:47:01 +0000
Subject: [issue35883] Python startup fails with a fatal error if a command
 line argument contains an invalid Unicode character
In-Reply-To: <1549040138.25.0.646545491344.issue35883@roundup.psfhosted.org>
Message-ID: <1616014021.65.0.472900296622.issue35883@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 9976834f807ea63ca51bc4f89be457d734148682 by Victor Stinner in branch 'master':
bpo-35883: Py_DecodeLocale() escapes invalid Unicode characters (GH-24843)
https://github.com/python/cpython/commit/9976834f807ea63ca51bc4f89be457d734148682


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35883>
_______________________________________

From report at bugs.python.org  Wed Mar 17 16:47:51 2021
From: report at bugs.python.org (miss-islington)
Date: Wed, 17 Mar 2021 20:47:51 +0000
Subject: [issue35883] Python startup fails with a fatal error if a command
 line argument contains an invalid Unicode character
In-Reply-To: <1549040138.25.0.646545491344.issue35883@roundup.psfhosted.org>
Message-ID: <1616014071.39.0.119096233585.issue35883@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: +23667
pull_request: https://github.com/python/cpython/pull/24905

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35883>
_______________________________________

From report at bugs.python.org  Wed Mar 17 16:48:03 2021
From: report at bugs.python.org (miss-islington)
Date: Wed, 17 Mar 2021 20:48:03 +0000
Subject: [issue35883] Python startup fails with a fatal error if a command
 line argument contains an invalid Unicode character
In-Reply-To: <1549040138.25.0.646545491344.issue35883@roundup.psfhosted.org>
Message-ID: <1616014083.51.0.912608761852.issue35883@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +23668
pull_request: https://github.com/python/cpython/pull/24906

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35883>
_______________________________________

From report at bugs.python.org  Wed Mar 17 16:51:04 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Mar 2021 20:51:04 +0000
Subject: [issue40533] [subinterpreters] Don't share Python objects between
 interpreters
In-Reply-To: <1588777895.61.0.395509624257.issue40533@roundup.psfhosted.org>
Message-ID: <1616014264.33.0.365698516583.issue40533@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> To get one GIL per interpreter (bpo-40512), either PyObject.ob_refcnt member must become an atomic variable, or subinterpreters must not share any object.

The current plan is to not share any object between two interpreters, so this PR is not needed. I close my PR 19958 which marked PyObject.ob_refcnt as atomic.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40533>
_______________________________________

From report at bugs.python.org  Wed Mar 17 16:54:41 2021
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 17 Mar 2021 20:54:41 +0000
Subject: [issue25386] msvcrt_putch/msvcrt_putwch don't check the return value
 of _putch/_putwch
In-Reply-To: <1444693845.85.0.133666844386.issue25386@psf.upfronthosting.co.za>
Message-ID: <1616014481.12.0.586718950222.issue25386@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25386>
_______________________________________

From report at bugs.python.org  Wed Mar 17 16:57:11 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Mar 2021 20:57:11 +0000
Subject: [issue43068] test_subprocess: test_specific_shell() fails on AMD64
 FreeBSD Shared 3.x
In-Reply-To: <1611956940.56.0.594651223595.issue43068@roundup.psfhosted.org>
Message-ID: <1616014631.66.0.204024785158.issue43068@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The two FreeBSD 3.x buildbot are back to green, I close the issue.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43068>
_______________________________________

From report at bugs.python.org  Wed Mar 17 16:57:32 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Mar 2021 20:57:32 +0000
Subject: [issue42370] test_ttk_guionly: test_to() fails on the GitHub Ubuntu
 job
In-Reply-To: <1605538587.9.0.222465124321.issue42370@roundup.psfhosted.org>
Message-ID: <1616014652.53.0.019556529707.issue42370@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/issue42370>
_______________________________________

From report at bugs.python.org  Wed Mar 17 16:58:07 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Mar 2021 20:58:07 +0000
Subject: [issue43228] Regression in function builtins
In-Reply-To: <1613396595.98.0.792771642012.issue43228@roundup.psfhosted.org>
Message-ID: <1616014687.85.0.795909412816.issue43228@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Issue fixed in bpo-42990.

----------
priority: release blocker -> 
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43228>
_______________________________________

From report at bugs.python.org  Wed Mar 17 17:00:33 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Mar 2021 21:00:33 +0000
Subject: [issue42990] Improve the C code for calling Python code:
 _PyEval_EvalCode()
In-Reply-To: <1611245152.12.0.0348161555926.issue42990@roundup.psfhosted.org>
Message-ID: <1616014833.2.0.865399655043.issue42990@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I checked manually cloudpickle_bug.py attached to bpo-43228: it works as expected. The bpo-43228 regression has been fixed. I close again the issue.

It was proposed to add a builtins parameter to the types.FunctionType constructor. If someone wants to add it: please go ahead ;-)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42990>
_______________________________________

From report at bugs.python.org  Wed Mar 17 17:03:55 2021
From: report at bugs.python.org (4-launchpad-kalvdans-no-ip-org)
Date: Wed, 17 Mar 2021 21:03:55 +0000
Subject: [issue39090] Document various options for getting the absolute path
 from pathlib.Path objects
In-Reply-To: <1576693250.66.0.453775762211.issue39090@roundup.psfhosted.org>
Message-ID: <1616015035.39.0.807512721594.issue39090@roundup.psfhosted.org>


Change by 4-launchpad-kalvdans-no-ip-org <launchpad at kalvdans.no-ip.org>:


----------
nosy: +4-launchpad-kalvdans-no-ip-org

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39090>
_______________________________________

From report at bugs.python.org  Wed Mar 17 17:11:23 2021
From: report at bugs.python.org (miss-islington)
Date: Wed, 17 Mar 2021 21:11:23 +0000
Subject: [issue35883] Python startup fails with a fatal error if a command
 line argument contains an invalid Unicode character
In-Reply-To: <1549040138.25.0.646545491344.issue35883@roundup.psfhosted.org>
Message-ID: <1616015483.28.0.562149217091.issue35883@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset aa967ec4d4c2fc844f8f16b339140b050ae4d5e2 by Miss Islington (bot) in branch '3.9':
bpo-35883: Py_DecodeLocale() escapes invalid Unicode characters (GH-24843)
https://github.com/python/cpython/commit/aa967ec4d4c2fc844f8f16b339140b050ae4d5e2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35883>
_______________________________________

From report at bugs.python.org  Wed Mar 17 17:36:07 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Mar 2021 21:36:07 +0000
Subject: [issue43244] Move PyArena C API to the internal C API
In-Reply-To: <1613586690.19.0.383646964758.issue43244@roundup.psfhosted.org>
Message-ID: <1616016967.65.0.717959372355.issue43244@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +23669
pull_request: https://github.com/python/cpython/pull/24907

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43244>
_______________________________________

From report at bugs.python.org  Wed Mar 17 17:44:21 2021
From: report at bugs.python.org (Steve Dower)
Date: Wed, 17 Mar 2021 21:44:21 +0000
Subject: [issue30044] shutil.copystat should (allow to) copy ownership,
 and other attributes
In-Reply-To: <1491925353.8.0.782070431072.issue30044@psf.upfronthosting.co.za>
Message-ID: <1616017461.64.0.109806347182.issue30044@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Just wanted to add that the sooner we can offer a wrapper around CopyFileEx on Windows (with no callbacks), the sooner we can take advantage of some significant optimisations that are being done to this function (which I can't share details of right now, but concrete work is being done).

Personally, I'm fine with it being copy2() and we take the slight behaviour change. But it should definitely be easy for users to access and use.

----------
nosy: +steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30044>
_______________________________________

From report at bugs.python.org  Wed Mar 17 17:45:01 2021
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 17 Mar 2021 21:45:01 +0000
Subject: [issue42730] TypeError/hang inside of Time.Sleep() when
 _thread.interrupt_main()
In-Reply-To: <1608830949.51.0.513581784179.issue42730@roundup.psfhosted.org>
Message-ID: <1616017501.5.0.906359077597.issue42730@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> Shouldn't the behaviour for _thread.interrupt_main() be always to 
> interrupt the main thread. 

The underlying C API function, PyErr_SetInterrupt(), simulates SIGINT without actually sending the signal to the process via kill() or raise(), but the doc string of interrupt_main() doesn't explain this, or at least it didn't used to. bpo-43356 generalized _thread.interrupt_main() to support simulating any available signal, and hopefully the new doc string [1] clarifies the intent.

---

[1] https://github.com/python/cpython/blob/9976834f807ea63ca51bc4f89be457d734148682/Modules/_threadmodule.c#L1194

----------
stage:  -> resolved
status: open -> closed
superseder:  -> _thread.interrupt_main() errors if SIGINT handler in SIG_DFL, SIG_IGN

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42730>
_______________________________________

From report at bugs.python.org  Wed Mar 17 18:11:10 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Mar 2021 22:11:10 +0000
Subject: [issue43244] Move PyArena C API to the internal C API
In-Reply-To: <1613586690.19.0.383646964758.issue43244@roundup.psfhosted.org>
Message-ID: <1616019070.38.0.36799612411.issue43244@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset b4536e1c6abe4c6219177a89e16575d05ea22f64 by Victor Stinner in branch 'master':
bpo-43244: Rename pycore_ast.h to pycore_ast_state.h (GH-24907)
https://github.com/python/cpython/commit/b4536e1c6abe4c6219177a89e16575d05ea22f64


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43244>
_______________________________________

From report at bugs.python.org  Wed Mar 17 18:14:43 2021
From: report at bugs.python.org (Irit Katriel)
Date: Wed, 17 Mar 2021 22:14:43 +0000
Subject: [issue22128] patch: steer people away from codecs.open
In-Reply-To: <1407071838.74.0.684483503953.issue22128@psf.upfronthosting.co.za>
Message-ID: <1616019283.01.0.0964146664485.issue22128@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

Since Martin corrected the docs in issue 19548 for python 3, and python 2 is no longer relevant, I believe this can be closed.

----------
nosy: +iritkatriel
resolution:  -> duplicate
status: open -> pending
superseder:  -> 'codecs' module docs improvements

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22128>
_______________________________________

From report at bugs.python.org  Wed Mar 17 18:18:02 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Mar 2021 22:18:02 +0000
Subject: [issue43244] Move PyArena C API to the internal C API
In-Reply-To: <1613586690.19.0.383646964758.issue43244@roundup.psfhosted.org>
Message-ID: <1616019482.99.0.886377197207.issue43244@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +23670
pull_request: https://github.com/python/cpython/pull/24908

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43244>
_______________________________________

From report at bugs.python.org  Wed Mar 17 18:30:04 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 17 Mar 2021 22:30:04 +0000
Subject: [issue43532] Add keyword-only fields to dataclasses
In-Reply-To: <1616002761.92.0.652624260802.issue43532@roundup.psfhosted.org>
Message-ID: <1616020204.89.0.881558360916.issue43532@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
keywords: +patch
pull_requests: +23671
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24909

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43532>
_______________________________________

From report at bugs.python.org  Wed Mar 17 18:34:46 2021
From: report at bugs.python.org (Irit Katriel)
Date: Wed, 17 Mar 2021 22:34:46 +0000
Subject: [issue27901] DOC: inspect.ismethod returns different results on the
 same basic code between Python2.7 Python3.5
In-Reply-To: <1472585181.25.0.672560198795.issue27901@psf.upfronthosting.co.za>
Message-ID: <1616020486.1.0.48693358603.issue27901@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

There seems to be agreement on this resolution:

> add a cross link from 'bound method' to
> the 'instance methods' section of the data model docs.

I'm updating version and marking as easy.

----------
keywords: +easy
nosy: +iritkatriel
title: inspect.ismethod returns different results on the same basic code between Python2.7 Python3.5 -> DOC: inspect.ismethod returns different results on the same basic code between Python2.7 Python3.5
type:  -> enhancement
versions: +Python 3.10 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27901>
_______________________________________

From report at bugs.python.org  Wed Mar 17 18:51:09 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Mar 2021 22:51:09 +0000
Subject: [issue43244] Move PyArena C API to the internal C API
In-Reply-To: <1613586690.19.0.383646964758.issue43244@roundup.psfhosted.org>
Message-ID: <1616021469.86.0.85279297337.issue43244@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 526fdeb2278b61653df704d7cfcaedde504dee48 by Victor Stinner in branch 'master':
bpo-43244: Add pycore_ast.h header file (GH-24908)
https://github.com/python/cpython/commit/526fdeb2278b61653df704d7cfcaedde504dee48


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43244>
_______________________________________

From report at bugs.python.org  Wed Mar 17 19:09:44 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Mar 2021 23:09:44 +0000
Subject: [issue43244] Move PyArena C API to the internal C API
In-Reply-To: <1613586690.19.0.383646964758.issue43244@roundup.psfhosted.org>
Message-ID: <1616022584.86.0.914317804252.issue43244@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +23672
pull_request: https://github.com/python/cpython/pull/24910

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43244>
_______________________________________

From report at bugs.python.org  Wed Mar 17 19:38:04 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Mar 2021 23:38:04 +0000
Subject: [issue12575] add a AST validator
In-Reply-To: <1310836208.56.0.617429580425.issue12575@psf.upfronthosting.co.za>
Message-ID: <1616024284.41.0.242720577394.issue12575@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +vstinner
nosy_count: 8.0 -> 9.0
pull_requests: +23674
pull_request: https://github.com/python/cpython/pull/24911

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12575>
_______________________________________

From report at bugs.python.org  Wed Mar 17 19:38:04 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Mar 2021 23:38:04 +0000
Subject: [issue43244] Move PyArena C API to the internal C API
In-Reply-To: <1613586690.19.0.383646964758.issue43244@roundup.psfhosted.org>
Message-ID: <1616024284.32.0.416673786681.issue43244@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +23673
pull_request: https://github.com/python/cpython/pull/24911

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43244>
_______________________________________

From report at bugs.python.org  Wed Mar 17 19:57:27 2021
From: report at bugs.python.org (jack1142)
Date: Wed, 17 Mar 2021 23:57:27 +0000
Subject: [issue31861] add aiter() and anext() functions
In-Reply-To: <1508851575.6.0.213398074469.issue31861@psf.upfronthosting.co.za>
Message-ID: <1616025447.88.0.246195666289.issue31861@roundup.psfhosted.org>


Change by jack1142 <kuba.kuczys at gmail.com>:


----------
nosy: +jack1142

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31861>
_______________________________________

From report at bugs.python.org  Wed Mar 17 20:08:45 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 18 Mar 2021 00:08:45 +0000
Subject: [issue43521] Allow `ast.unparse` to handle NaNs and empty sets
In-Reply-To: <1615923546.68.0.291337558212.issue43521@roundup.psfhosted.org>
Message-ID: <1616026125.4.0.880014627403.issue43521@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/issue43521>
_______________________________________

From report at bugs.python.org  Wed Mar 17 20:22:37 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Mar 2021 00:22:37 +0000
Subject: [issue43244] Move PyArena C API to the internal C API
In-Reply-To: <1613586690.19.0.383646964758.issue43244@roundup.psfhosted.org>
Message-ID: <1616026957.23.0.122387812691.issue43244@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +23675
pull_request: https://github.com/python/cpython/pull/24912

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43244>
_______________________________________

From report at bugs.python.org  Wed Mar 17 20:37:30 2021
From: report at bugs.python.org (jack1142)
Date: Thu, 18 Mar 2021 00:37:30 +0000
Subject: [issue43532] Add keyword-only fields to dataclasses
In-Reply-To: <1616002761.92.0.652624260802.issue43532@roundup.psfhosted.org>
Message-ID: <1616027850.18.0.830808466916.issue43532@roundup.psfhosted.org>


Change by jack1142 <kuba.kuczys at gmail.com>:


----------
nosy: +jack1142

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43532>
_______________________________________

From report at bugs.python.org  Wed Mar 17 20:49:33 2021
From: report at bugs.python.org (Ran Chen)
Date: Thu, 18 Mar 2021 00:49:33 +0000
Subject: [issue43533] Exception and contextmanager in __getattr__ causes
 reference cycle
Message-ID: <1616028573.19.0.764954620341.issue43533@roundup.psfhosted.org>


New submission from Ran Chen <crccw at moonux.org>:

If __getattr__ raises exception within a contextlib.context_manager, it creates a reference cycle and prevents the frame from being garbage collected. This only happens if the exception is raised inside a context manager inside __getattr__. It doesn't happen if there's no context manager.

Repro:

```
import contextlib
import gc

@contextlib.contextmanager
def ct():
  yield


class A(object):

  def __getattr__(self, name):
    with ct():
      raise AttributeError()
  


def f():
  a = A()
  hasattr(a, 'notexist')


gc.set_debug(gc.DEBUG_LEAK)
f()
gc.collect()
```

It also doesn't happen if we catch the exception outside of the context manager and re-raise it:

```
  def __getattr__(self, name):
    try:
      with ct():
        raise AttributeError()
    except:
      raise
```

----------
components: Library (Lib)
messages: 388977
nosy: crccw
priority: normal
severity: normal
status: open
title: Exception and contextmanager in __getattr__ causes reference cycle
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43533>
_______________________________________

From report at bugs.python.org  Wed Mar 17 20:53:40 2021
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 18 Mar 2021 00:53:40 +0000
Subject: [issue31103] Windows Installer Product does not include micro version
 in display name
In-Reply-To: <1501668288.41.0.228516476421.issue31103@psf.upfronthosting.co.za>
Message-ID: <1616028820.22.0.255729632342.issue31103@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

FYI, the 3rd field is Field3Value, defined in "PCbuild/python.props" as the value `MicroVersionNumber*1000 + ReleaseLevelNumber*10 + ReleaseSerial`. It gets set as the FIELD3 macro in "PCbuild/pyproject.props", which gets used in the definition of the PYVERSION64 macro in "PC/python_ver_rc.h". PYVERSION64 is used as the FILEVERSION and PRODUCTVERSION in the resource files. But note that the "FileVersion" and "ProductVersion" string values are instead based on the PY_VERSION macro, which is defined in "Include/patchlevel.h", which for release builds is the normal "major.minor.micro" string. 

In "Tools/msi/msi.props", Field3Value is used in the "Version" variable as follows: "$(MajorVersionNumber).$(MinorVersionNumber).$(Field3Value).0", which is used for all of the MSIs and the bundle. 

> Display Version should start with 3.X.Y or 3.X.Y.<build number>

Is this referring to the above MSI version value, which gets displayed in the version column in "Programs and Features"? I'm far from an expert with MSI. This is Steve's wheelhouse, and he'll correct me if I'm wrong, but I think it's important that at least one of the first 3 fields changes for a normal update. In the development cycle, it's thus up to the Field3Value, as the release level (10, 11, 12, 15) and serial (0, 1, 2, ...) are incremented. In that case the 3rd field cannot be just the micro version number.

----------
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31103>
_______________________________________

From report at bugs.python.org  Wed Mar 17 21:03:35 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 18 Mar 2021 01:03:35 +0000
Subject: [issue42128] Structural Pattern Matching (PEP 634)
In-Reply-To: <1603466540.96.0.7677855399.issue42128@roundup.psfhosted.org>
Message-ID: <1616029415.67.0.599262400566.issue42128@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 08fb8ac99ab03d767aa0f1cfab3573eddf9df018 by Pablo Galindo in branch 'master':
bpo-42128: Add 'missing :' syntax error message to match statements (GH-24733)
https://github.com/python/cpython/commit/08fb8ac99ab03d767aa0f1cfab3573eddf9df018


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42128>
_______________________________________

From report at bugs.python.org  Wed Mar 17 21:12:16 2021
From: report at bugs.python.org (Chris Winkler)
Date: Thu, 18 Mar 2021 01:12:16 +0000
Subject: [issue43534] turtle.textinput window is not transient
Message-ID: <1616029936.62.0.714792032874.issue43534@roundup.psfhosted.org>


New submission from Chris Winkler <quidnovum at gmail.com>:

When `turtle.textinput` is called in Python 3.9.2, the resulting dialog window is not marked as transient. This is not a problem in 3.9.1.

The offending change seems to come from bpo-42630. Specifically, `SimpleDialog.__init__` is being passed `parent=None`, and because of this `self.transient(parent)` is not being called.

A minimal program to reproduce the bug is attached. I'm happy to submit a pull request or something if it would help, but I don't know whether it's more correct to replace `parent` with `master` in the aforementioned if statement or something else.

----------
components: Tkinter
files: textinput_test.py
messages: 388980
nosy: quid256
priority: normal
severity: normal
status: open
title: turtle.textinput window is not transient
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file49885/textinput_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43534>
_______________________________________

From report at bugs.python.org  Wed Mar 17 21:43:40 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Mar 2021 01:43:40 +0000
Subject: [issue43395] os.path states that bytes can't represent all MBCS paths
 under Windows
In-Reply-To: <1614839485.4.0.948731177165.issue43395@roundup.psfhosted.org>
Message-ID: <1616031820.93.0.60314113467.issue43395@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43395>
_______________________________________

From report at bugs.python.org  Wed Mar 17 21:44:19 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Mar 2021 01:44:19 +0000
Subject: [issue21822] [Windows] KeyboardInterrupt during Thread.join hangs
 that Thread
In-Reply-To: <1403365475.16.0.757881205569.issue21822@psf.upfronthosting.co.za>
Message-ID: <1616031859.94.0.0135854660669.issue21822@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner
title: KeyboardInterrupt during Thread.join hangs that Thread -> [Windows] KeyboardInterrupt during Thread.join hangs that Thread

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21822>
_______________________________________

From report at bugs.python.org  Wed Mar 17 21:46:30 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Mar 2021 01:46:30 +0000
Subject: [issue43244] Move PyArena C API to the internal C API
In-Reply-To: <1613586690.19.0.383646964758.issue43244@roundup.psfhosted.org>
Message-ID: <1616031990.15.0.249131816605.issue43244@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset e0bf70d08c4a4a68782702e747e6bf7670667591 by Victor Stinner in branch 'master':
bpo-43244: Fix test_peg_generator for PyAST_Validate() (GH-24912)
https://github.com/python/cpython/commit/e0bf70d08c4a4a68782702e747e6bf7670667591


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43244>
_______________________________________

From report at bugs.python.org  Wed Mar 17 22:04:02 2021
From: report at bugs.python.org (John Private)
Date: Thu, 18 Mar 2021 02:04:02 +0000
Subject: [issue43534] turtle.textinput window is not transient
In-Reply-To: <1616029936.62.0.714792032874.issue43534@roundup.psfhosted.org>
Message-ID: <1616033042.2.0.871752100744.issue43534@roundup.psfhosted.org>


John Private <jwmp5051 at gmail.com> added the comment:

I am enclosing a PNG showing the difference between 3.9.1 and 3.9.2

In 3.9.2 the pop-up opens as a new window complete with minimise and maximise buttons, and the position is unrelated to the turtle screen.

----------
nosy: +jwmp5051
Added file: https://bugs.python.org/file49886/textinput.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43534>
_______________________________________

From report at bugs.python.org  Wed Mar 17 22:23:00 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Mar 2021 02:23:00 +0000
Subject: [issue43244] Move PyArena C API to the internal C API
In-Reply-To: <1613586690.19.0.383646964758.issue43244@roundup.psfhosted.org>
Message-ID: <1616034180.88.0.703523406862.issue43244@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +23676
pull_request: https://github.com/python/cpython/pull/24913

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43244>
_______________________________________

From report at bugs.python.org  Wed Mar 17 22:29:06 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 18 Mar 2021 02:29:06 +0000
Subject: [issue43535] Make str.join auto-convert inputs to strings.
Message-ID: <1616034546.27.0.0632217994438.issue43535@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

Rather than just erroring-out, it would be nice if str.join converted inputs to strings when needed.

Currently:

    data = [10, 20, 30, 40, 50]
    s = ', '.join(map(str, data))

Proposed:

    s = ', '.join(data)

That would simplify a common idiom.  That is nice win for beginners and it makes code more readable.  

The join() method is unfriendly in a number of ways.  This would make it a bit nicer.

There is likely to be a performance win as well.  The existing idiom with map() roughly runs like this:

     * Get iterator over: map(str, data)
     * Without length knowledge, build-up a list of strings
       periodically resizing and recopying data (1st pass)
     * Loop over the list strings to compute the combined size
       (2nd pass)
     * Allocate a buffer for the target size
     * Loop over the list strings (3rd pass), copying each
       into the buffer and wrap the result in a string object.

But, it could run like this:
     * Use len(data) or a length-hint to presize the list of strings.
     * Loop over the data, converting each input to a string if needed,
       keeping a running total of the target size, and storing in the
       pre-sized list of strings (all this in a single 1st pass)
     * Allocate a buffer for the target size
     * Loop over the list strings (2nd pass), copying each
       into the buffer
     * Loop over the list strings (3rd pass), copying each
       into the buffer and wrap the result in a string object.

AFAICT, the proposal is mostly backwards compatible, the only change is that code that currently errors-out will succeed.

For bytes.join() and bytearray.join(), the only auto-conversion that makes sense is from ints to bytes so that you could write:  

     b' '.join(data)

instead of the current:

    b' '.join([bytes([x]) for x in data])

----------
components: Interpreter Core
messages: 388983
nosy: pablogsal, rhettinger
priority: normal
severity: normal
status: open
title: Make str.join auto-convert inputs to strings.
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43535>
_______________________________________

From report at bugs.python.org  Wed Mar 17 22:39:28 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 18 Mar 2021 02:39:28 +0000
Subject: [issue34535] queue.Queue(timeout=0.001) avg delay Windows:14.5ms,
 Ubuntu: 0.063ms
In-Reply-To: <1535484021.65.0.56676864532.issue34535@psf.upfronthosting.co.za>
Message-ID: <1616035168.03.0.85953207223.issue34535@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation -Windows
nosy: +docs at python
type: performance -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34535>
_______________________________________

From report at bugs.python.org  Wed Mar 17 22:40:29 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 18 Mar 2021 02:40:29 +0000
Subject: [issue43532] Add keyword-only fields to dataclasses
In-Reply-To: <1616002761.92.0.652624260802.issue43532@roundup.psfhosted.org>
Message-ID: <1616035229.56.0.0891178733635.issue43532@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

+1 for this idea.  I don't see any downside.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43532>
_______________________________________

From report at bugs.python.org  Wed Mar 17 23:02:22 2021
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 18 Mar 2021 03:02:22 +0000
Subject: [issue43535] Make str.join auto-convert inputs to strings.
In-Reply-To: <1616034546.27.0.0632217994438.issue43535@roundup.psfhosted.org>
Message-ID: <1616036542.52.0.805516187534.issue43535@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/issue43535>
_______________________________________

From report at bugs.python.org  Thu Mar 18 00:01:41 2021
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Thu, 18 Mar 2021 04:01:41 +0000
Subject: [issue43535] Make str.join auto-convert inputs to strings.
In-Reply-To: <1616034546.27.0.0632217994438.issue43535@roundup.psfhosted.org>
Message-ID: <1616040101.81.0.137116844589.issue43535@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

I can't find it now, but I seem to remember me having this same proposal (except the part for bytes) quite a few years ago, and you being the most vocal opponent. What changed? Of course, I'm still for it.

(Your second list has fourth item extra. But it's clear what you wanted to say.)

----------
nosy: +veky

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43535>
_______________________________________

From report at bugs.python.org  Thu Mar 18 00:08:10 2021
From: report at bugs.python.org (Thermi)
Date: Thu, 18 Mar 2021 04:08:10 +0000
Subject: [issue43536] 3.9.2 --without-pymalloc --with-pydebug --with-valgrind:
 test failed: test_posix
Message-ID: <1616040490.74.0.308907840702.issue43536@roundup.psfhosted.org>


New submission from Thermi <noel.kuntze+bugs-python-org at thermi.consulting>:

----------------------------------------------------------------------

Ran 210 tests in 0.950s

OK (skipped=26)

== Tests result: FAILURE ==

412 tests OK.

1 test failed:
    test_posix

10 tests skipped:
    test_devpoll test_gdb test_kqueue test_msilib test_ossaudiodev
    test_startfile test_winconsoleio test_winreg test_winsound
    test_zipfile64

Total duration: 1 hour 3 min
Tests result: FAILURE


test test_posix failed                                                                                                                     
0:38:00 load avg: 1.89 [265/423/1] test_posixpath -- test_posix failed                       

Possibly related: test_setscheduler_with_policy (test.test_posix.TestPosixSpawnP) ... ERROR                                                                  

test_setscheduler_with_policy (test.test_posix.TestPosixSpawn) ... ERROR                                                                   

Distribution: Arch Linux
Linux 5.11.6-arch1-1
gcc 10.2.0-6
glibc 2.33-4
valgrind 3.16.1-4

----------
components: Tests
files: config.log
messages: 388986
nosy: Thermi
priority: normal
severity: normal
status: open
title: 3.9.2 --without-pymalloc --with-pydebug --with-valgrind: test failed: test_posix
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file49887/config.log

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43536>
_______________________________________

From report at bugs.python.org  Thu Mar 18 00:09:43 2021
From: report at bugs.python.org (Thermi)
Date: Thu, 18 Mar 2021 04:09:43 +0000
Subject: [issue43536] 3.9.2 --without-pymalloc --with-pydebug --with-valgrind:
 test failed: test_posix
In-Reply-To: <1616040490.74.0.308907840702.issue43536@roundup.psfhosted.org>
Message-ID: <1616040583.97.0.92322391678.issue43536@roundup.psfhosted.org>


Thermi <noel.kuntze+bugs-python-org at thermi.consulting> added the comment:

PKGBUILD I use to build the python package I need for debugging on Arch.

Only changes to it are the addition of the 3 configure flags mentioned in the title.
Other than that, it should work fine.
I built the package previously without those changes and that worked.

flags: --without-pymalloc --with-pydebug --with-valgrind

----------
Added file: https://bugs.python.org/file49888/PKGBUILD

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43536>
_______________________________________

From report at bugs.python.org  Thu Mar 18 00:42:41 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 18 Mar 2021 04:42:41 +0000
Subject: [issue42161] Remove private _PyLong_Zero and _PyLong_One variables
In-Reply-To: <1603749577.35.0.864358738107.issue42161@roundup.psfhosted.org>
Message-ID: <1616042561.99.0.641965967018.issue42161@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> Thanks Raymond, I fixed the code.

Can you fix all the other cases where this is used in inner-loop; otherwise, it is undoing everyone else's optimizations and fast paths.

Also, it seems the that primary motivation for this is support subinterpreters.  That PEP hasn't been approved, so we should not be making code worse until we know there is going to some offsetting benefit.

For example, the inner-loop code in math_lcm() used to have "res == _PyLong_Zero" which was fast a register-to-register comparison (1 cycle at worst and typically 0 cycles with branch prediction).  Also there used to be zero memory accesses.   The new code has five sequentially dependent operations and four memory accesses (not what we want in an inner-loop):

    movq    __PyRuntime at GOTPCREL(%rip), %rax
    movq    616(%rax), %rax
    movq    16(%rax), %rax
    cmpq    %r12, 3560(%rax)
    jne L326

Ideally, the whole PR should be reverted until the subinterpreter PEP is approved.  If not, then at least the changes should be made more carefully, hoisting the new call out of the hot loop:

+   zero = _PyLong_GetZero();
    for (i = 1; i < nargs; i++) {
        x = PyNumber_Index(args[i]);
        if (x == NULL) {
            Py_DECREF(res);
            return NULL;
        }
-       if (res == _PyLong_GetZero()) {
+       if (res == zero) {
            /* Fast path: just check arguments.
               It is okay to use identity comparison here. */
            Py_DECREF(x);
            continue;
        }
        Py_SETREF(res, long_lcm(res, x));
        Py_DECREF(x);
        if (res == NULL) {
            return NULL;
        }
    }
    return res;

----------
nosy: +pablogsal, serhiy.storchaka
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42161>
_______________________________________

From report at bugs.python.org  Thu Mar 18 01:23:57 2021
From: report at bugs.python.org (Mike Glover)
Date: Thu, 18 Mar 2021 05:23:57 +0000
Subject: [issue43493] EmailMessage mis-folding headers of a certain length
In-Reply-To: <1615754789.09.0.690251462615.issue43493@roundup.psfhosted.org>
Message-ID: <1616045037.12.0.319838812735.issue43493@roundup.psfhosted.org>


Mike Glover <mglover at pobox.com> added the comment:

Further research shows that email.parser.Parser is not handling the affected lines correctly -- the leading '\n ' is not being stripped from the header value.

Attached is the (ugly, worksforme) function I'm using to workaround this problem

----------
Added file: https://bugs.python.org/file49889/foldfix.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43493>
_______________________________________

From report at bugs.python.org  Thu Mar 18 02:48:08 2021
From: report at bugs.python.org (Xinmeng Xia)
Date: Thu, 18 Mar 2021 06:48:08 +0000
Subject: [issue43537] nterpreter crashes when handling long text in input()
Message-ID: <1616050088.79.0.477395111242.issue43537@roundup.psfhosted.org>


New submission from Xinmeng Xia <xiaxm at smail.nju.edu.cn>:

When the argument of input() is very long text, the interpreter crashes.  This bug can  be reproduced Python 3.9.2 and Python 2.7.18 on Ubuntu 3.9.2 with GCC7.5.0. I try to  reproduce this bug on other version of Python and Operating System, but it fails. This bug seems to have a connection with the version of GCC.


Python 3.9.2 (default, Mar 12 2021, 15:08:35)
[GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> input([1,2]*10000)
*** Error in `/home/xxm/Desktop/apifuzz/Python-3.9.2/python': realloc(): invalid next size: 0x000000000135fd40 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x777f5)[0x7f714431b7f5]
/lib/x86_64-linux-gnu/libc.so.6(+0x834da)[0x7f71443274da]
/lib/x86_64-linux-gnu/libc.so.6(realloc+0x199)[0x7f71443288a9]
/lib/x86_64-linux-gnu/libreadline.so.6(xrealloc+0xe)[0x7f71446a1ffe]
/lib/x86_64-linux-gnu/libreadline.so.6(rl_redisplay+0x125f)[0x7f714469451f]
/lib/x86_64-linux-gnu/libreadline.so.6(readline_internal_setup+0xb0)[0x7f7144681340]
/lib/x86_64-linux-gnu/libreadline.so.6(+0x2a4ac)[0x7f71446984ac]
/home/xxm/Desktop/apifuzz/Python-3.9.2/python[0x5d60b2]
/home/xxm/Desktop/apifuzz/Python-3.9.2/python(PyOS_Readline+0x116)[0x5da536]
/home/xxm/Desktop/apifuzz/Python-3.9.2/python[0x648495]
/home/xxm/Desktop/apifuzz/Python-3.9.2/python[0x613f26]
/home/xxm/Desktop/apifuzz/Python-3.9.2/python(_PyEval_EvalFrameDefault+0x54e2)[0x4267a2]
/home/xxm/Desktop/apifuzz/Python-3.9.2/python[0x4fa3e9]
/home/xxm/Desktop/apifuzz/Python-3.9.2/python(PyEval_EvalCode+0x36)[0x4fa746]
/home/xxm/Desktop/apifuzz/Python-3.9.2/python[0x543adf]
/home/xxm/Desktop/apifuzz/Python-3.9.2/python[0x546d82]
/home/xxm/Desktop/apifuzz/Python-3.9.2/python(PyRun_InteractiveLoopFlags+0x8e)[0x54704e]
/home/xxm/Desktop/apifuzz/Python-3.9.2/python(PyRun_AnyFileExFlags+0x3c)[0x5478fc]
/home/xxm/Desktop/apifuzz/Python-3.9.2/python(Py_RunMain+0x8d7)[0x42b1e7]
/home/xxm/Desktop/apifuzz/Python-3.9.2/python(Py_BytesMain+0x56)[0x42b586]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f71442c4840]
/home/xxm/Desktop/apifuzz/Python-3.9.2/python(_start+0x29)[0x42a289]
======= Memory map: ========
00400000-00762000 r-xp 00000000 08:07 7740578 /home/xxm/Desktop/apifuzz/Python-3.9.2/python
00961000-00962000 r--p 00361000 08:07 7740578 /home/xxm/Desktop/apifuzz/Python-3.9.2/python
00962000-0099a000 rw-p 00362000 08:07 7740578 /home/xxm/Desktop/apifuzz/Python-3.9.2/python
0099a000-009be000 rw-p 00000000 00:00 0
012dc000-013ce000 rw-p 00000000 00:00 0 [heap]
7f713c000000-7f713c021000 rw-p 00000000 00:00 0
7f713c021000-7f7140000000 ---p 00000000 00:00 0
7f71439b5000-7f71439cc000 r-xp 00000000 08:07 1966109 /lib/x86_64-linux-gnu/libgcc_s.so.1
7f71439cc000-7f7143bcb000 ---p 00017000 08:07 1966109 /lib/x86_64-linux-gnu/libgcc_s.so.1
7f7143bcb000-7f7143bcc000 r--p 00016000 08:07 1966109 /lib/x86_64-linux-gnu/libgcc_s.so.1
7f7143bcc000-7f7143bcd000 rw-p 00017000 08:07 1966109 /lib/x86_64-linux-gnu/libgcc_s.so.1
7f7143bf0000-7f714407b000 r--p 00000000 08:07 4326136 /usr/lib/locale/locale-archive
7f714407b000-7f71440a0000 r-xp 00000000 08:07 1970777 /lib/x86_64-linux-gnu/libtinfo.so.5.9
7f71440a0000-7f714429f000 ---p 00025000 08:07 1970777 /lib/x86_64-linux-gnu/libtinfo.so.5.9
7f714429f000-7f71442a3000 r--p 00024000 08:07 1970777 /lib/x86_64-linux-gnu/libtinfo.so.5.9
7f71442a3000-7f71442a4000 rw-p 00028000 08:07 1970777 /lib/x86_64-linux-gnu/libtinfo.so.5.9
7f71442a4000-7f7144464000 r-xp 00000000 08:07 1966308 /lib/x86_64-linux-gnu/libc-2.23.so
7f7144464000-7f7144664000 ---p 001c0000 08:07 1966308 /lib/x86_64-linux-gnu/libc-2.23.so
7f7144664000-7f7144668000 r--p 001c0000 08:07 1966308 /lib/x86_64-linux-gnu/libc-2.23.so
7f7144668000-7f714466a000 rw-p 001c4000 08:07 1966308 /lib/x86_64-linux-gnu/libc-2.23.so
7f714466a000-7f714466e000 rw-p 00000000 00:00 0
7f714466e000-7f71446ab000 r-xp 00000000 08:07 1970756 /lib/x86_64-linux-gnu/libreadline.so.6.3
7f71446ab000-7f71448ab000 ---p 0003d000 08:07 1970756 /lib/x86_64-linux-gnu/libreadline.so.6.3
7f71448ab000-7f71448ad000 r--p 0003d000 08:07 1970756 /lib/x86_64-linux-gnu/libreadline.so.6.3
7f71448ad000-7f71448b3000 rw-p 0003f000 08:07 1970756 /lib/x86_64-linux-gnu/libreadline.so.6.3
7f71448b3000-7f71448b4000 rw-p 00000000 00:00 0
7f71448b4000-7f71449bc000 r-xp 00000000 08:07 1966312 /lib/x86_64-linux-gnu/libm-2.23.so
7f71449bc000-7f7144bbb000 ---p 00108000 08:07 1966312 /lib/x86_64-linux-gnu/libm-2.23.so
7f7144bbb000-7f7144bbc000 r--p 00107000 08:07 1966312 /lib/x86_64-linux-gnu/libm-2.23.so
7f7144bbc000-7f7144bbd000 rw-p 00108000 08:07 1966312 /lib/x86_64-linux-gnu/libm-2.23.so
7f7144bbd000-7f7144bbf000 r-xp 00000000 08:07 1966307 /lib/x86_64-linux-gnu/libutil-2.23.so
7f7144bbf000-7f7144dbe000 ---p 00002000 08:07 1966307 /lib/x86_64-linux-gnu/libutil-2.23.so
7f7144dbe000-7f7144dbf000 r--p 00001000 08:07 1966307 /lib/x86_64-linux-gnu/libutil-2.23.so
7f7144dbf000-7f7144dc0000 rw-p 00002000 08:07 1966307 /lib/x86_64-linux-gnu/libutil-2.23.so
7f7144dc0000-7f7144dc3000 r-xp 00000000 08:07 1966306 /lib/x86_64-linux-gnu/libdl-2.23.so
7f7144dc3000-7f7144fc2000 ---p 00003000 08:07 1966306 /lib/x86_64-linux-gnu/libdl-2.23.so
7f7144fc2000-7f7144fc3000 r--p 00002000 08:07 1966306 /lib/x86_64-linux-gnu/libdl-2.23.so
7f7144fc3000-7f7144fc4000 rw-p 00003000 08:07 1966306 /lib/x86_64-linux-gnu/libdl-2.23.so
7f7144fc4000-7f7144fdc000 r-xp 00000000 08:07 1966309 /lib/x86_64-linux-gnu/libpthread-2.23.so
7f7144fdc000-7f71451db000 ---p 00018000 08:07 1966309 /lib/x86_64-linux-gnu/libpthread-2.23.so
7f71451db000-7f71451dc000 r--p 00017000 08:07 1966309 /lib/x86_64-linux-gnu/libpthread-2.23.so
7f71451dc000-7f71451dd000 rw-p 00018000 08:07 1966309 /lib/x86_64-linux-gnu/libpthread-2.23.so
7f71451dd000-7f71451e1000 rw-p 00000000 00:00 0
7f71451e1000-7f7145207000 r-xp 00000000 08:07 1966319 /lib/x86_64-linux-gnu/ld-2.23.so
7f7145210000-7f71453e3000 rw-p 00000000 00:00 0
7f71453fe000-7f71453ff000 rw-p 00000000 00:00 0
7f71453ff000-7f7145406000 r--s 00000000 08:07 4589769 /usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache
7f7145406000-7f7145407000 r--p 00025000 08:07 1966319 /lib/x86_64-linux-gnu/ld-2.23.so
7f7145407000-7f7145408000 rw-p 00026000 08:07 1966319 /lib/x86_64-linux-gnu/ld-2.23.so
7f7145408000-7f7145409000 rw-p 00000000 00:00 0
7ffefb5a0000-7ffefb5c1000 rw-p 00000000 00:00 0 [stack]
7ffefb5de000-7ffefb5e1000 r--p 00000000 00:00 0 [vvar]
7ffefb5e1000-7ffefb5e3000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Aborted (core dumped)

----------
components: Interpreter Core
messages: 388990
nosy: xxm
priority: normal
severity: normal
status: open
title: nterpreter crashes when handling long text in input()
type: crash
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43537>
_______________________________________

From report at bugs.python.org  Thu Mar 18 02:48:49 2021
From: report at bugs.python.org (Xinmeng Xia)
Date: Thu, 18 Mar 2021 06:48:49 +0000
Subject: [issue43537] interpreter crashes when handling long text in input()
In-Reply-To: <1616050088.79.0.477395111242.issue43537@roundup.psfhosted.org>
Message-ID: <1616050129.61.0.350343510234.issue43537@roundup.psfhosted.org>


Change by Xinmeng Xia <xiaxm at smail.nju.edu.cn>:


----------
title: nterpreter crashes when handling long text in input() -> interpreter crashes when handling long text in input()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43537>
_______________________________________

From report at bugs.python.org  Thu Mar 18 03:23:53 2021
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 18 Mar 2021 07:23:53 +0000
Subject: [issue43538] [Windows] support args and cwd in os.startfile()
Message-ID: <1616052233.51.0.171946221972.issue43538@roundup.psfhosted.org>


New submission from Eryk Sun <eryksun at gmail.com>:

bpo-8232 has a patch to add an `arguments` parameter to os.startfile(). This improvement is needlessly tied to that issue. It's useful in general as a safer way to execute applications and scripts compared to using subprocess.Popen() with shell=True. It also enables passing arguments to applications and scripts when using the "runas" operation (prompts with a UAC dialog) and "runasuser" operation (prompts with a credential dialog). The latter operations are supported by default for binary executables and batch scripts in Windows 10, and they can be implemented by the progid of any file type.

Setting the working directory with a cwd parameter is not as generally useful, but it's not entirely useless and simple to add at the same time when adding the `args` parameter.

----------
components: Extension Modules, Windows
messages: 388991
nosy: eryksun, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: [Windows] support args and cwd in os.startfile()
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43538>
_______________________________________

From report at bugs.python.org  Thu Mar 18 03:25:52 2021
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 18 Mar 2021 07:25:52 +0000
Subject: [issue8232] webbrowser.open incomplete on Windows
In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za>
Message-ID: <1616052352.6.0.12960131593.issue8232@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
components: +Windows
dependencies: +[Windows] support args and cwd in os.startfile()
nosy: +paul.moore, tim.golden, zach.ware
versions: +Python 3.10 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8232>
_______________________________________

From report at bugs.python.org  Thu Mar 18 03:26:45 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 18 Mar 2021 07:26:45 +0000
Subject: [issue43535] Make str.join auto-convert inputs to strings.
In-Reply-To: <1616034546.27.0.0632217994438.issue43535@roundup.psfhosted.org>
Message-ID: <1616052405.83.0.824001010446.issue43535@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I'm +0.5. Every time this bites me, I apply the same solution, so you're probably right that str.join should just do the work itself. And it's no doubt more performant that way, anyway.

And I've probably got some code that's just waiting for the current behavior to raise an error on me if passed the wrong inputs, even if I'd prefer it to succeed.

I should be +1, but I have a nagging "refuse to guess" feeling. But it doesn't seem like much of a guess: there's no other logical thing I could mean by this code. I'm unlikely to want it to raise an exception, or do any other conversion to a str.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43535>
_______________________________________

From report at bugs.python.org  Thu Mar 18 03:42:50 2021
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 18 Mar 2021 07:42:50 +0000
Subject: [issue8232] webbrowser.open incomplete on Windows
In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za>
Message-ID: <1616053370.87.0.406052708988.issue8232@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

Windows Vista is no longer a concern, so find_windows_browsers() doesn't have to worry about the KEY_WOW64_* flags. IMO, it should get the browser's real name (the default value of the key) and the fully-qualified path of the executable, instead of depending solely on an "App Paths" entry being configured for the base executable name. For example:

    def find_windows_browsers():
        """ Read the installed browsers from the Windows registry."""
        import winreg
        browsers = []
        with winreg.OpenKey(winreg.HKEY_LOCAL_MACHINE,
                r"Software\Clients\StartMenuInternet") as hkey:
            i = 0
            while True:
                try:
                    subkey = winreg.EnumKey(hkey, i)
                    i += 1
                except OSError as e:
                    if e.winerror != 259: # ERROR_NO_MORE_ITEMS
                        raise
                    break
                try:
                    name = winreg.QueryValue(hkey, subkey)
                    if not name or not isinstance(name, str):
                        name = subkey
                except OSError:
                    name = subkey
                try:
                    cmd = winreg.QueryValue(hkey, rf"{subkey}\shell\open\command")
                    cmd = cmd.strip('"')
                    os.stat(cmd)
                except (OSError, AttributeError, TypeError, ValueError):
                    cmd = ""
                browsers.append((name, cmd))
        return browsers

The loop over the result would change to `for browser, cmd in find_windows_browsers()`. The string to match for Internet Explorer, using the real name instead of the registry key name, would be "internet explorer". A class for Microsoft Edge ("msedge") should be added.

The browser would get instantiated with the cmd value, which ideally is the fully-qualified path of the executable. The fallback behavior wouldn't change for the case where self.cmd is an empty string. For example:

    class WindowsDefault(BaseBrowser):
        cmd = newwindow = newtab = ""

        def __init__(self, name="", cmd=""):
            super().__init__(name)
            if cmd:
                self.cmd = cmd
        ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8232>
_______________________________________

From report at bugs.python.org  Thu Mar 18 03:51:50 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 18 Mar 2021 07:51:50 +0000
Subject: [issue43535] Make str.join auto-convert inputs to strings.
In-Reply-To: <1616034546.27.0.0632217994438.issue43535@roundup.psfhosted.org>
Message-ID: <1616053910.88.0.537584761955.issue43535@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It was proposed by newbies several times before. It was rejected because it would make errors to hide unnoticed. Python is dynamically but strongly typed, and it is its advantage.

I am -1.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43535>
_______________________________________

From report at bugs.python.org  Thu Mar 18 04:11:19 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Mar 2021 08:11:19 +0000
Subject: [issue43244] Move PyArena C API to the internal C API
In-Reply-To: <1613586690.19.0.383646964758.issue43244@roundup.psfhosted.org>
Message-ID: <1616055079.48.0.962002100461.issue43244@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +23677
pull_request: https://github.com/python/cpython/pull/24914

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43244>
_______________________________________

From report at bugs.python.org  Thu Mar 18 04:24:09 2021
From: report at bugs.python.org (miss-islington)
Date: Thu, 18 Mar 2021 08:24:09 +0000
Subject: [issue39342] Expose X509_V_FLAG_ALLOW_PROXY_CERTS in ssl
In-Reply-To: <1579082580.52.0.275703305608.issue39342@roundup.psfhosted.org>
Message-ID: <1616055849.93.0.85207926298.issue39342@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e0b4aa0f5c3c2b2c60f5d8b20cf291442a8df8a5 by Chris Burr in branch 'master':
bpo-39342: Expose X509_V_FLAG_ALLOW_PROXY_CERTS in ssl module (GH-18011)
https://github.com/python/cpython/commit/e0b4aa0f5c3c2b2c60f5d8b20cf291442a8df8a5


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39342>
_______________________________________

From report at bugs.python.org  Thu Mar 18 04:24:31 2021
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 18 Mar 2021 08:24:31 +0000
Subject: [issue39342] Expose X509_V_FLAG_ALLOW_PROXY_CERTS in ssl
In-Reply-To: <1579082580.52.0.275703305608.issue39342@roundup.psfhosted.org>
Message-ID: <1616055871.42.0.985588955466.issue39342@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> 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/issue39342>
_______________________________________

From report at bugs.python.org  Thu Mar 18 04:27:23 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Mar 2021 08:27:23 +0000
Subject: [issue43539] test_asyncio:
 test_sendfile_close_peer_in_the_middle_of_receiving() fails randomly
Message-ID: <1616056043.89.0.64862359152.issue43539@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Seen on the Windows x64 job of GitHub Actions:
https://github.com/python/cpython/pull/24913/checks?check_run_id=2137800313


======================================================================
FAIL: test_sendfile_close_peer_in_the_middle_of_receiving (test.test_asyncio.test_sendfile.ProactorEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\a\cpython\cpython\lib\test\test_asyncio\test_sendfile.py", line 458, in test_sendfile_close_peer_in_the_middle_of_receiving
    self.run_loop(
AssertionError: ConnectionError not raised

(...)
0:12:31 load avg: 0.39 Re-running test_asyncio in verbose mode
(...)

======================================================================
FAIL: test_sendfile_close_peer_in_the_middle_of_receiving (test.test_asyncio.test_sendfile.ProactorEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\a\cpython\cpython\lib\test\test_asyncio\test_sendfile.py", line 458, in test_sendfile_close_peer_in_the_middle_of_receiving
    self.run_loop(
AssertionError: ConnectionError not raised

----------
components: Tests, asyncio
messages: 388997
nosy: asvetlov, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: test_asyncio: test_sendfile_close_peer_in_the_middle_of_receiving() fails randomly
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43539>
_______________________________________

From report at bugs.python.org  Thu Mar 18 04:31:52 2021
From: report at bugs.python.org (Milan Balazs)
Date: Thu, 18 Mar 2021 08:31:52 +0000
Subject: [issue43165] Support the same files with new param in shutil.copyfile
In-Reply-To: <1612805521.88.0.931585192254.issue43165@roundup.psfhosted.org>
Message-ID: <1616056312.44.0.989778912029.issue43165@roundup.psfhosted.org>


Milan Balazs <milanbalazs01 at gmail.com> added the comment:

Could you somebody review the PR for this ticket, please?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43165>
_______________________________________

From report at bugs.python.org  Thu Mar 18 04:32:27 2021
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 18 Mar 2021 08:32:27 +0000
Subject: [issue43382] github CI blocked by the Ubuntu CI with an SSL error
In-Reply-To: <1614745744.43.0.675662116863.issue43382@roundup.psfhosted.org>
Message-ID: <1616056347.28.0.171998115746.issue43382@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

CI is passing again.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43382>
_______________________________________

From report at bugs.python.org  Thu Mar 18 04:50:27 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Mar 2021 08:50:27 +0000
Subject: [issue43537] interpreter crashes when handling long text in input()
In-Reply-To: <1616050088.79.0.477395111242.issue43537@roundup.psfhosted.org>
Message-ID: <1616057427.58.0.77124006839.issue43537@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

It looks like a bug in libreadline. Python only calls rl_callback_handler_install (prompt, rlhandler); where prompt is a byte string of 60,000 bytes: len(repr([1,2]*10000)).


$ gdb ./python
(gdb) run
Python 3.10.0a6+ (heads/pycore_symtable-dirty:27700e0c8b, Mar 18 2021, 03:11:22) [GCC 10.2.1 20201125 (Red Hat 10.2.1-9)] on linux
>>> input([1,2]*10000)
realloc(): invalid next size

Program received signal SIGABRT, Aborted.
0x00007ffff7c629d5 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: dnf debuginfo-install libxcrypt-4.4.18-1.fc33.x86_64 ncurses-libs-6.2-3.20200222.fc33.x86_64 readline-8.0-5.fc33.x86_64

(gdb) where
#0  0x00007ffff7c629d5 in raise () from /lib64/libc.so.6
#1  0x00007ffff7c4b8a4 in abort () from /lib64/libc.so.6
#2  0x00007ffff7ca5177 in __libc_message () from /lib64/libc.so.6
#3  0x00007ffff7cace6c in malloc_printerr () from /lib64/libc.so.6
#4  0x00007ffff7cb111c in _int_realloc () from /lib64/libc.so.6
#5  0x00007ffff7cb22a6 in realloc () from /lib64/libc.so.6
#6  0x00007fffea4c9dc2 in xrealloc () from /lib64/libreadline.so.8
#7  0x00007fffea4bb7ab in rl_redisplay () from /lib64/libreadline.so.8
#8  0x00007fffea4a5727 in readline_internal_setup () from /lib64/libreadline.so.8
#9  0x00007fffea4c7489 in _rl_callback_newline () from /lib64/libreadline.so.8
#10 0x00007ffff7fbdb68 in readline_until_enter_or_signal (
    prompt=0xba9b40 "[1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1"..., signal=0x7fffffffb7f4) at /home/vstinner/python/master/Modules/readline.c:1318
#11 0x00007ffff7fbde06 in call_readline (sys_stdin=0x7ffff7de9800 <_IO_2_1_stdin_>, sys_stdout=0x7ffff7dea520 <_IO_2_1_stdout_>, 
    prompt=0xba9b40 "[1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1"...) at /home/vstinner/python/master/Modules/readline.c:1396
#12 0x000000000071f7b3 in PyOS_Readline (sys_stdin=0x7ffff7de9800 <_IO_2_1_stdin_>, sys_stdout=0x7ffff7dea520 <_IO_2_1_stdout_>, 
    prompt=0xba9b40 "[1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1"...) at Parser/myreadline.c:393
#13 0x000000000069d23c in builtin_input_impl (module=<module at remote 0x7fffea69d590>, 
    prompt=[1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, ...(truncated)) at Python/bltinmodule.c:2096
#14 0x0000000000699156 in builtin_input (module=<module at remote 0x7fffea69d590>, args=0x7fffea62c7b8, nargs=1) at Python/clinic/bltinmodule.c.h:662
...


Valgrind also sees many memory errors:

$ PYTHONMALLOC=malloc_debug valgrind --log-file=valgrind.log ./python 
>>> input([1,2]*10000)
[1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, (...)
Erreur de segmentation (core dumped)

$ cat valgrind.log
==8025== Memcheck, a memory error detector
==8025== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==8025== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==8025== Command: ./python
==8025== Parent PID: 7434
==8025== 
==8025== Invalid write of size 4
==8025==    at 0x1297C410: rl_redisplay (display.c:865)
==8025==    by 0x12967726: readline_internal_setup (readline.c:447)
==8025==    by 0x12989488: _rl_callback_newline (callback.c:100)
==8025==    by 0x4854B67: readline_until_enter_or_signal (readline.c:1318)
==8025==    by 0x4854E05: call_readline (readline.c:1396)
==8025==    by 0x71F7B2: PyOS_Readline (myreadline.c:393)
==8025==    by 0x69D23B: builtin_input_impl (bltinmodule.c:2096)
==8025==    by 0x699155: builtin_input (bltinmodule.c.h:662)
==8025==    by 0x6635B2: cfunction_vectorcall_FASTCALL (methodobject.c:426)
==8025==    by 0x50D168: _PyObject_VectorcallTstate (abstract.h:114)
==8025==    by 0x50D1C7: PyObject_Vectorcall (abstract.h:123)
==8025==    by 0x525A14: call_function (ceval.c:5931)
==8025==  Address 0x4e5ef00 is 0 bytes after a block of size 1,024 alloc'd
==8025==    at 0x4839809: malloc (vg_replace_malloc.c:307)
==8025==    by 0x1298B7DC: xmalloc (xmalloc.c:59)
==8025==    by 0x12974F1C: init_line_structures (display.c:641)
==8025==    by 0x1297D856: rl_redisplay (display.c:680)
==8025==    by 0x12967726: readline_internal_setup (readline.c:447)
==8025==    by 0x12989488: _rl_callback_newline (callback.c:100)
==8025==    by 0x4854B67: readline_until_enter_or_signal (readline.c:1318)
==8025==    by 0x4854E05: call_readline (readline.c:1396)
==8025==    by 0x71F7B2: PyOS_Readline (myreadline.c:393)
==8025==    by 0x6281D0: tok_nextc (tokenizer.c:894)
==8025==    by 0x6298E5: tok_get (tokenizer.c:1236)
==8025==    by 0x62B285: PyTokenizer_Get (tokenizer.c:1895)
==8025== 
==8025== Invalid write of size 4
==8025==    at 0x1297C425: rl_redisplay (display.c:862)
==8025==    by 0x12967726: readline_internal_setup (readline.c:447)
==8025==    by 0x12989488: _rl_callback_newline (callback.c:100)
==8025==    by 0x4854B67: readline_until_enter_or_signal (readline.c:1318)
==8025==    by 0x4854E05: call_readline (readline.c:1396)
==8025==    by 0x71F7B2: PyOS_Readline (myreadline.c:393)
==8025==    by 0x69D23B: builtin_input_impl (bltinmodule.c:2096)
==8025==    by 0x699155: builtin_input (bltinmodule.c.h:662)
==8025==    by 0x6635B2: cfunction_vectorcall_FASTCALL (methodobject.c:426)
==8025==    by 0x50D168: _PyObject_VectorcallTstate (abstract.h:114)
==8025==    by 0x50D1C7: PyObject_Vectorcall (abstract.h:123)
==8025==    by 0x525A14: call_function (ceval.c:5931)
==8025==  Address 0x4e5ef04 is 4 bytes after a block of size 1,024 alloc'd
==8025==    at 0x4839809: malloc (vg_replace_malloc.c:307)
==8025==    by 0x1298B7DC: xmalloc (xmalloc.c:59)
==8025==    by 0x12974F1C: init_line_structures (display.c:641)
==8025==    by 0x1297D856: rl_redisplay (display.c:680)
==8025==    by 0x12967726: readline_internal_setup (readline.c:447)
==8025==    by 0x12989488: _rl_callback_newline (callback.c:100)
==8025==    by 0x4854B67: readline_until_enter_or_signal (readline.c:1318)
==8025==    by 0x4854E05: call_readline (readline.c:1396)
==8025==    by 0x71F7B2: PyOS_Readline (myreadline.c:393)
==8025==    by 0x6281D0: tok_nextc (tokenizer.c:894)
==8025==    by 0x6298E5: tok_get (tokenizer.c:1236)
==8025==    by 0x62B285: PyTokenizer_Get (tokenizer.c:1895)
==8025== 
==8025== Conditional jump or move depends on uninitialised value(s)
==8025==    at 0x1297AF01: update_line (display.c:1897)
==8025==    by 0x1297C8A4: rl_redisplay (display.c:1154)
==8025==    by 0x12967726: readline_internal_setup (readline.c:447)
==8025==    by 0x12989488: _rl_callback_newline (callback.c:100)
==8025==    by 0x4854B67: readline_until_enter_or_signal (readline.c:1318)
==8025==    by 0x4854E05: call_readline (readline.c:1396)
==8025==    by 0x71F7B2: PyOS_Readline (myreadline.c:393)
==8025==    by 0x69D23B: builtin_input_impl (bltinmodule.c:2096)
==8025==    by 0x699155: builtin_input (bltinmodule.c.h:662)
==8025==    by 0x6635B2: cfunction_vectorcall_FASTCALL (methodobject.c:426)
==8025==    by 0x50D168: _PyObject_VectorcallTstate (abstract.h:114)
==8025==    by 0x50D1C7: PyObject_Vectorcall (abstract.h:123)
==8025== 
==8025== Conditional jump or move depends on uninitialised value(s)
==8025==    at 0x1297AF0F: update_line (display.c:1921)
==8025==    by 0x1297C8A4: rl_redisplay (display.c:1154)
==8025==    by 0x12967726: readline_internal_setup (readline.c:447)
==8025==    by 0x12989488: _rl_callback_newline (callback.c:100)
==8025==    by 0x4854B67: readline_until_enter_or_signal (readline.c:1318)
==8025==    by 0x4854E05: call_readline (readline.c:1396)
==8025==    by 0x71F7B2: PyOS_Readline (myreadline.c:393)
==8025==    by 0x69D23B: builtin_input_impl (bltinmodule.c:2096)
==8025==    by 0x699155: builtin_input (bltinmodule.c.h:662)
==8025==    by 0x6635B2: cfunction_vectorcall_FASTCALL (methodobject.c:426)
==8025==    by 0x50D168: _PyObject_VectorcallTstate (abstract.h:114)
==8025==    by 0x50D1C7: PyObject_Vectorcall (abstract.h:123)
==8025== 
==8025== Conditional jump or move depends on uninitialised value(s)
==8025==    at 0x1297A8B2: UnknownInlinedFun (display.c:3144)
==8025==    by 0x1297A8B2: update_line (display.c:2200)
==8025==    by 0x1297C8A4: rl_redisplay (display.c:1154)
==8025==    by 0x12967726: readline_internal_setup (readline.c:447)
==8025==    by 0x12989488: _rl_callback_newline (callback.c:100)
==8025==    by 0x4854B67: readline_until_enter_or_signal (readline.c:1318)
==8025==    by 0x4854E05: call_readline (readline.c:1396)
==8025==    by 0x71F7B2: PyOS_Readline (myreadline.c:393)
==8025==    by 0x69D23B: builtin_input_impl (bltinmodule.c:2096)
==8025==    by 0x699155: builtin_input (bltinmodule.c.h:662)
==8025==    by 0x6635B2: cfunction_vectorcall_FASTCALL (methodobject.c:426)
==8025==    by 0x50D168: _PyObject_VectorcallTstate (abstract.h:114)
==8025==    by 0x50D1C7: PyObject_Vectorcall (abstract.h:123)
==8025== 
==8025== Conditional jump or move depends on uninitialised value(s)
==8025==    at 0x483FC63: bcmp (vg_replace_strmem.c:1111)
==8025==    by 0x129794C9: update_line (display.c:1656)
==8025==    by 0x1297C8A4: rl_redisplay (display.c:1154)
==8025==    by 0x12967726: readline_internal_setup (readline.c:447)
==8025==    by 0x12989488: _rl_callback_newline (callback.c:100)
==8025==    by 0x4854B67: readline_until_enter_or_signal (readline.c:1318)
==8025==    by 0x4854E05: call_readline (readline.c:1396)
==8025==    by 0x71F7B2: PyOS_Readline (myreadline.c:393)
==8025==    by 0x69D23B: builtin_input_impl (bltinmodule.c:2096)
==8025==    by 0x699155: builtin_input (bltinmodule.c.h:662)
==8025==    by 0x6635B2: cfunction_vectorcall_FASTCALL (methodobject.c:426)
==8025==    by 0x50D168: _PyObject_VectorcallTstate (abstract.h:114)
==8025== 
==8025== Conditional jump or move depends on uninitialised value(s)
==8025==    at 0x1297959C: update_line (display.c:1703)
==8025==    by 0x1297C8A4: rl_redisplay (display.c:1154)
==8025==    by 0x12967726: readline_internal_setup (readline.c:447)
==8025==    by 0x12989488: _rl_callback_newline (callback.c:100)
==8025==    by 0x4854B67: readline_until_enter_or_signal (readline.c:1318)
==8025==    by 0x4854E05: call_readline (readline.c:1396)
==8025==    by 0x71F7B2: PyOS_Readline (myreadline.c:393)
==8025==    by 0x69D23B: builtin_input_impl (bltinmodule.c:2096)
==8025==    by 0x699155: builtin_input (bltinmodule.c.h:662)
==8025==    by 0x6635B2: cfunction_vectorcall_FASTCALL (methodobject.c:426)
==8025==    by 0x50D168: _PyObject_VectorcallTstate (abstract.h:114)
==8025==    by 0x50D1C7: PyObject_Vectorcall (abstract.h:123)
==8025== 
==8025== Conditional jump or move depends on uninitialised value(s)
==8025==    at 0x1297AB9D: update_line (display.c:1704)
==8025==    by 0x1297C8A4: rl_redisplay (display.c:1154)
==8025==    by 0x12967726: readline_internal_setup (readline.c:447)
==8025==    by 0x12989488: _rl_callback_newline (callback.c:100)
==8025==    by 0x4854B67: readline_until_enter_or_signal (readline.c:1318)
==8025==    by 0x4854E05: call_readline (readline.c:1396)
==8025==    by 0x71F7B2: PyOS_Readline (myreadline.c:393)
==8025==    by 0x69D23B: builtin_input_impl (bltinmodule.c:2096)
==8025==    by 0x699155: builtin_input (bltinmodule.c.h:662)
==8025==    by 0x6635B2: cfunction_vectorcall_FASTCALL (methodobject.c:426)
==8025==    by 0x50D168: _PyObject_VectorcallTstate (abstract.h:114)
==8025==    by 0x50D1C7: PyObject_Vectorcall (abstract.h:123)
==8025== 
==8025== Use of uninitialised value of size 8
==8025==    at 0x129795EA: update_line (display.c:1704)
==8025==    by 0x1297C8A4: rl_redisplay (display.c:1154)
==8025==    by 0x12967726: readline_internal_setup (readline.c:447)
==8025==    by 0x12989488: _rl_callback_newline (callback.c:100)
==8025==    by 0x4854B67: readline_until_enter_or_signal (readline.c:1318)
==8025==    by 0x4854E05: call_readline (readline.c:1396)
==8025==    by 0x71F7B2: PyOS_Readline (myreadline.c:393)
==8025==    by 0x69D23B: builtin_input_impl (bltinmodule.c:2096)
==8025==    by 0x699155: builtin_input (bltinmodule.c.h:662)
==8025==    by 0x6635B2: cfunction_vectorcall_FASTCALL (methodobject.c:426)
==8025==    by 0x50D168: _PyObject_VectorcallTstate (abstract.h:114)
==8025==    by 0x50D1C7: PyObject_Vectorcall (abstract.h:123)
==8025== 
==8025== Invalid read of size 1
==8025==    at 0x129795EA: update_line (display.c:1704)
==8025==    by 0x1297C8A4: rl_redisplay (display.c:1154)
==8025==    by 0x12967726: readline_internal_setup (readline.c:447)
==8025==    by 0x12989488: _rl_callback_newline (callback.c:100)
==8025==    by 0x4854B67: readline_until_enter_or_signal (readline.c:1318)
==8025==    by 0x4854E05: call_readline (readline.c:1396)
==8025==    by 0x71F7B2: PyOS_Readline (myreadline.c:393)
==8025==    by 0x69D23B: builtin_input_impl (bltinmodule.c:2096)
==8025==    by 0x699155: builtin_input (bltinmodule.c.h:662)
==8025==    by 0x6635B2: cfunction_vectorcall_FASTCALL (methodobject.c:426)
==8025==    by 0x50D168: _PyObject_VectorcallTstate (abstract.h:114)
==8025==    by 0x50D1C7: PyObject_Vectorcall (abstract.h:123)
==8025==  Address 0xfffffffff2213d9d is not stack'd, malloc'd or (recently) free'd
==8025== 
==8025== 
==8025== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==8025==  Access not within mapped region at address 0xFFFFFFFFF2213D9D
==8025==    at 0x129795EA: update_line (display.c:1704)
==8025==    by 0x1297C8A4: rl_redisplay (display.c:1154)
==8025==    by 0x12967726: readline_internal_setup (readline.c:447)
==8025==    by 0x12989488: _rl_callback_newline (callback.c:100)
==8025==    by 0x4854B67: readline_until_enter_or_signal (readline.c:1318)
==8025==    by 0x4854E05: call_readline (readline.c:1396)
==8025==    by 0x71F7B2: PyOS_Readline (myreadline.c:393)
==8025==    by 0x69D23B: builtin_input_impl (bltinmodule.c:2096)
==8025==    by 0x699155: builtin_input (bltinmodule.c.h:662)
==8025==    by 0x6635B2: cfunction_vectorcall_FASTCALL (methodobject.c:426)
==8025==    by 0x50D168: _PyObject_VectorcallTstate (abstract.h:114)
==8025==    by 0x50D1C7: PyObject_Vectorcall (abstract.h:123)
==8025==  If you believe this happened as a result of a stack
==8025==  overflow in your program's main thread (unlikely but
==8025==  possible), you can try to increase the size of the
==8025==  main thread stack using the --main-stacksize= flag.
==8025==  The main thread stack size used in this run was 8388608.
==8025== 
==8025== HEAP SUMMARY:
==8025==     in use at exit: 6,501,013 bytes in 73,176 blocks
==8025==   total heap usage: 151,328 allocs, 78,152 frees, 30,639,455 bytes allocated
==8025== 
==8025== LEAK SUMMARY:
==8025==    definitely lost: 0 bytes in 0 blocks
==8025==    indirectly lost: 0 bytes in 0 blocks
==8025==      possibly lost: 5,168,429 bytes in 32,868 blocks
==8025==    still reachable: 1,332,584 bytes in 40,308 blocks
==8025==         suppressed: 0 bytes in 0 blocks
==8025== Rerun with --leak-check=full to see details of leaked memory
==8025== 
==8025== Use --track-origins=yes to see where uninitialised values come from
==8025== For lists of detected and suppressed errors, rerun with: -s
==8025== ERROR SUMMARY: 125 errors from 10 contexts (suppressed: 0 from 0)

Line numbers of readline-8.0-5.fc33.x86_64 and the current master branch of Python.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43537>
_______________________________________

From report at bugs.python.org  Thu Mar 18 04:54:25 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Mar 2021 08:54:25 +0000
Subject: [issue43244] Move PyArena C API to the internal C API
In-Reply-To: <1613586690.19.0.383646964758.issue43244@roundup.psfhosted.org>
Message-ID: <1616057665.08.0.403566228738.issue43244@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 6af528b4ab342805534c0bfe61d84ed7bb519468 by Victor Stinner in branch 'master':
bpo-43244: Fix test_peg_generators on Windows (GH-24913)
https://github.com/python/cpython/commit/6af528b4ab342805534c0bfe61d84ed7bb519468


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43244>
_______________________________________

From report at bugs.python.org  Thu Mar 18 05:00:36 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Mar 2021 09:00:36 +0000
Subject: [issue42161] Remove private _PyLong_Zero and _PyLong_One variables
In-Reply-To: <1603749577.35.0.864358738107.issue42161@roundup.psfhosted.org>
Message-ID: <1616058036.35.0.420563194382.issue42161@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Since it seems like you have already a ready patch to optimize the code, so go ahead and merge it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42161>
_______________________________________

From report at bugs.python.org  Thu Mar 18 05:15:20 2021
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 18 Mar 2021 09:15:20 +0000
Subject: [issue41561] test_ssl fails in Ubuntu 20.04:
 test_min_max_version_mismatch
In-Reply-To: <1597551049.14.0.0578030464715.issue41561@roundup.psfhosted.org>
Message-ID: <1616058920.99.0.671629067162.issue41561@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

I have discussed the problem with downstream engineers on the two issues

- https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1899878
- https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1917625

The gist of the issue is: Canonical has taken a different approach than Debian and other distros to set minimum TLS version.

Most distros use an openssl.cnf file to set "MinProtocol = TLSv1.2". The config file approach allows application to override the setting with SSL_CTX_set_min_proto_version(ctx, TLS1_VERSION) and to detect the current minimum version with SSL_CTX_get_min_proto_version(ctx) == TLS1_VERSION.

Ubuntu doesn't set "MinProtocol = TLSv1.2". Instead the distro has patched OpenSSL source code and modified the meaning of security level "2". Security level is a new OpenSSL API to set various security related settings. On Ubuntu SECLEVEL=2 prevents TLS 1.0 and 1.1 connection. Further SSL_CTX_get_min_proto_version(ctx) returns 0 (dummy value for minimum supported version). SSL_CTX_set_min_proto_version(ctx, TLS1_VERSION) does not fail although TLS 1.0 is prohibited.

https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_security_level.html
    Level 2: SSL version 3 is also not allowed
    Level 4: TLS versions below 1.2 are not permitted.

https://manpages.ubuntu.com/manpages/focal/man3/SSL_CTX_set_security_level.3ssl.html
    Level 2: On Ubuntu, TLS versions below 1.2 are not permitted

The combination of "Ubuntu changed the meaning of security level policy" and "SSL_CTX_get_min_proto_version(ctx) does not report minimum version" breaks our tests.

OpenSSL doesn't provide an easy way to check if a SSL_CTX has a sane configuration. There is a way to check if a security policy allows a TLS version. I'm not sure if we should include the check in CPython and where to best put the check:

    void *sec_ex = SSL_CTX_get0_security_ex_data(ctx);
    sec_cb = SSL_CTX_get_security_callback(ctx);
    int result = sec_cb(NULL, ctx, SSL_SECOP_VERSION, 0, TLS1_VERSION, NULL, sec_ex);
    if (result && (SSL_CTX_get_min_proto_version(ctx) >=  TLS1_VERSION)) ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41561>
_______________________________________

From report at bugs.python.org  Thu Mar 18 05:21:18 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Thu, 18 Mar 2021 09:21:18 +0000
Subject: [issue43492] Upgrade to SQLite 3.35.2 in macOS and Windows
In-Reply-To: <1615752732.27.0.278073347477.issue43492@roundup.psfhosted.org>
Message-ID: <1616059278.63.0.566716239735.issue43492@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

Bug-fix release 3.35.2 is out: https://www.sqlite.org/releaselog/3_35_2.html

Let's wait until end of March before updating the installers.

----------
title: Upgrade to SQLite 3.35.1 in macOS and Windows -> Upgrade to SQLite 3.35.2 in macOS and Windows

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43492>
_______________________________________

From report at bugs.python.org  Thu Mar 18 05:28:50 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Mar 2021 09:28:50 +0000
Subject: [issue37945] [Windows]
 test_locale.TestMiscellaneous.test_getsetlocale_issue1813() fails
In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org>
Message-ID: <1616059730.84.0.0260500070418.issue37945@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

"ERROR: test_getsetlocale_issue1813 (test.test_locale.TestMiscellaneous)" fails on the Windows x64 job of GitHub Actions when Python is built in debug mode:
https://github.com/python/cpython/pull/24914

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37945>
_______________________________________

From report at bugs.python.org  Thu Mar 18 05:35:52 2021
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 18 Mar 2021 09:35:52 +0000
Subject: [issue41561] test_ssl fails in Ubuntu 20.04:
 test_min_max_version_mismatch
In-Reply-To: <1597551049.14.0.0578030464715.issue41561@roundup.psfhosted.org>
Message-ID: <1616060152.84.0.0394115478639.issue41561@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +23678
stage: commit review -> patch review
pull_request: https://github.com/python/cpython/pull/24915

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41561>
_______________________________________

From report at bugs.python.org  Thu Mar 18 06:15:14 2021
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Thu, 18 Mar 2021 10:15:14 +0000
Subject: [issue43535] Make str.join auto-convert inputs to strings.
In-Reply-To: <1616034546.27.0.0632217994438.issue43535@roundup.psfhosted.org>
Message-ID: <1616062514.57.0.688641923146.issue43535@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

Does strong typing mean you should write

    if bool(condition): ...

or 

    for element in iter(sequence): ...

or (more similar to this)

    my_set.symmetric_difference_update(set(some_iterable))

?

As Eric has said, if there's only one possible thing you could have meant, "strong typing" is just bureaucracy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43535>
_______________________________________

From report at bugs.python.org  Thu Mar 18 06:19:33 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Mar 2021 10:19:33 +0000
Subject: [issue43540] importlib: Document how to replace load_module() in
 What's New in Python 3.10
Message-ID: <1616062773.63.0.458155955758.issue43540@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

The load_module() method of importlib loaders is deprecated which cause test failures in multiple projects.

It is not easy to guess how to replace it. Examples:

* pkg_resources fix adding create_module() and exec_module() methods: https://github.com/pypa/setuptools/commit/6ad2fb0b78d11e22672f56ef9d65d13ebd3475a9
* pkg_resources fix replacing importlib.load_module() function call (not loader methods) with importlib.import_module(): https://github.com/pypa/setuptools/commit/a54d9e6b30c6da0542698144d2ff149ae7cadc9a

Cython uses this code:

if sys.version_info[:2] < (3, 3):
    import imp
    def load_dynamic(name, module_path):
        return imp.load_dynamic(name, module_path)
else:
    from importlib.machinery import ExtensionFileLoader
    def load_dynamic(name, module_path):
        return ExtensionFileLoader(name, module_path).load_module()

Fixed Cython code:

if sys.version_info < (3, 5):
    import imp
    def load_dynamic(name, module_path):
        return imp.load_dynamic(name, module_path)
else:
    import importlib.util as _importlib_util
    def load_dynamic(name, module_path):
        spec = _importlib_util.spec_from_file_location(name, module_path)
        module = _importlib_util.module_from_spec(spec)
        # sys.modules[name] = module
        spec.loader.exec_module(module)
        return module

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 389007
nosy: brett.cannon, docs at python, vstinner
priority: normal
severity: normal
status: open
title: importlib: Document how to replace load_module() in What's New in Python 3.10
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43540>
_______________________________________

From report at bugs.python.org  Thu Mar 18 06:45:03 2021
From: report at bugs.python.org (Paul)
Date: Thu, 18 Mar 2021 10:45:03 +0000
Subject: [issue43512] Bug in isinstance(instance,
 cls) with cls being a protocol? (PEP 544)
In-Reply-To: <1615888944.07.0.094574416265.issue43512@roundup.psfhosted.org>
Message-ID: <1616064303.65.0.357689459528.issue43512@roundup.psfhosted.org>


Paul <paul.dest at web.de> added the comment:

Regarding "At runtime, protocol classes will be simple ABCs." (PEP 544):
Unfortunately, this is currently not the case. Actually, there is an extra metaclass for protocols, solely to provide an __instancecheck__.
https://github.com/python/cpython/blob/3.9/Lib/typing.py#L1096

```
class _ProtocolMeta(ABCMeta):
    # This metaclass is really unfortunate and exists only because of
    # the lack of __instancehook__.
    def __instancecheck__(cls, instance):
        # We need this method for situations where attributes are
        # assigned in __init__.
        if ((not getattr(cls, '_is_protocol', False) or
                _is_callable_members_only(cls)) and
                issubclass(instance.__class__, cls)):
            return True
        if cls._is_protocol:
            if all(hasattr(instance, attr) and
                    # All *methods* can be blocked by setting them to None.
                    (not callable(getattr(cls, attr, None)) or
                     getattr(instance, attr) is not None)
                    for attr in _get_protocol_attrs(cls)):
                return True
        return super().__instancecheck__(instance)
```


Regarding "There is no intent to provide sophisticated runtime instance and class checks against protocol classes." (PEP 544):
I fully understand that. But a runtime instance check that simply checks, if a protocol member is there, is not sophisticated. And as you can see in the code above, these checks are already implemented, but unfortunately they don't cover the case reported by me in the initial message.

I could provide a patch for the _ProtocolMeta to cover the case reported by me. It's just a matter of a couple of lines. Even if the runtime isinstance() checking is not required to give the right answer, I think the right answer would be nice - at least for the most basic checks as "Are the protocol members there?"

Regarding "if you inherit from a protocol you are deemed to implement it":
I couldn't find a rule with this meaning in any of the typing PEPs.

But in my point of view, the problem is a different one:
If the instance to check is of a class implemented by another developer (maybe the class is from a third-party library - Bob's library), then such a rule does not help the first developer (Alice). Alice doesn't know anything about such-a-rule-compliance of Bob's classes. She just wants to check if the instance returned by one of Bob's functions complies to the protocol.

-------------

The bottom line is:
I'd like to provide a patch if you want me to.

If you think the current implementation must not be touched, then I would appreciate if the reported case could be documented. I could deliver a draft for this, as well. Currently, the last examples in the sections "Protocol members" and "Explicitly declaring implementation" in PEP 544 contain protocol members with no default implementation in the protocol, but do not suggest the behavior reported above.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43512>
_______________________________________

From report at bugs.python.org  Thu Mar 18 07:11:14 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Mar 2021 11:11:14 +0000
Subject: [issue43541] PyEval_EvalCodeEx() can no longer be called with code
 which has (CO_NEWLOCALS | CO_OPTIMIZED) flags
Message-ID: <1616065874.01.0.576723621403.issue43541@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Cython generates a __Pyx_PyFunction_FastCallDict() function which calls PyEval_EvalCodeEx(). With Python 3.9, it worked well. With Python 3.10 in debug mode, it fails with an assertion error:

python3.10: Python/ceval.c:5148: PyEval_EvalCodeEx: Assertion `(((PyCodeObject *)_co)->co_flags & (CO_NEWLOCALS | CO_OPTIMIZED)) == 0' failed.

With Python 3.10 in release mode, it does crash.

Context of the failed assertion:

* Assertion added recently to CPython 3.10 by python/cpython at 0332e56
* The code object flags = (CO_NEWLOCALS | CO_OPTIMIZED | CO_NOFREE)
* Code co_argcount = 2
* Code co_kwonlyargcount = 0
* Cython __Pyx_PyFunction_FastCallDict() called with: nargs=1 and kwargs=NULL

See the Cython issue to a reproducer: https://github.com/cython/cython/issues/4025#issuecomment-801829541

In Python 3.9, _PyFunction_Vectorcall() has the following fast-path:

    if (co->co_kwonlyargcount == 0 && nkwargs == 0 &&
        (co->co_flags & ~PyCF_MASK) == (CO_OPTIMIZED | CO_NEWLOCALS | CO_NOFREE))
    {
        if (argdefs == NULL && co->co_argcount == nargs) {
            return function_code_fastcall(tstate, co, stack, nargs, globals);
        }
        else if (nargs == 0 && argdefs != NULL
                 && co->co_argcount == PyTuple_GET_SIZE(argdefs)) {
            /* function called with no arguments, but all parameters have
               a default value: use default values as arguments .*/
            stack = _PyTuple_ITEMS(argdefs);
            return function_code_fastcall(tstate, co,
                                          stack, PyTuple_GET_SIZE(argdefs),
                                          globals);
        }
    }

When the bug occurs, __Pyx_PyFunction_FastCallDict() doesn't take the fast-path because nargs < co_argcount (1 < 2).

In Python 3.10, _PyFunction_Vectorcall() is very different:

    if (((PyCodeObject *)f->fc_code)->co_flags & CO_OPTIMIZED) {
        return _PyEval_Vector(tstate, f, NULL, stack, nargs, kwnames);
    }
    else {
        return _PyEval_Vector(tstate, f, f->fc_globals, stack, nargs, kwnames);
    }


PyEval_EvalCodeEx() must not crash if the code object has (CO_NEWLOCALS | CO_OPTIMIZED | CO_NOFREE) flags.

----------
components: C API
messages: 389009
nosy: Mark.Shannon, pablogsal, vstinner
priority: normal
severity: normal
status: open
title: PyEval_EvalCodeEx() can no longer be called with code which has (CO_NEWLOCALS | CO_OPTIMIZED) flags
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43541>
_______________________________________

From report at bugs.python.org  Thu Mar 18 07:17:20 2021
From: report at bugs.python.org (E. Paine)
Date: Thu, 18 Mar 2021 11:17:20 +0000
Subject: [issue43534] turtle.textinput window is not transient
In-Reply-To: <1616029936.62.0.714792032874.issue43534@roundup.psfhosted.org>
Message-ID: <1616066240.49.0.789108184745.issue43534@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

Thank you for reporting this. The problem appears to be a regression with https://github.com/python/cpython/commit/3d569fd6 where the dialog tries to be transient to the user-passed parent rather than the default root. I will create a PR to hopefully rectify this.

----------
nosy: +epaine, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43534>
_______________________________________

From report at bugs.python.org  Thu Mar 18 07:17:33 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Mar 2021 11:17:33 +0000
Subject: [issue43541] PyEval_EvalCodeEx() can no longer be called with code
 which has (CO_NEWLOCALS | CO_OPTIMIZED) flags
In-Reply-To: <1616065874.01.0.576723621403.issue43541@roundup.psfhosted.org>
Message-ID: <1616066253.49.0.492108998444.issue43541@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

If I the comment the following assertion in PyEval_EvalCodeEx():

assert ((((PyCodeObject *)_co)->co_flags & (CO_NEWLOCALS | CO_OPTIMIZED)) == 0);

The garbage collector fails while visiting builtins of the function with func_traverse(), at line:

   Py_VISIT(f->func_builtins);

I guess that the problem is that f->func_builtins doesn't hold a strong reference to builtins.


Error:

Modules/gcmodule.c:113: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small
Enable tracemalloc to get the memory block allocation traceback

object address  : 0x7fffea69d650
object refcount : 2265
object type     : 0x870e80
object type name: dict
object repr     : {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '__loader__': <class '_frozen_importlib.BuiltinImporter'>, '__spec__': ModuleSpec(name='builtins', loader=<class '_frozen_importlib.BuiltinImporter'>, origin='built-in'), '__build_class__': <built-in function __build_class__>, '__import__': <built-in function __import__>, 'abs': <built-in function abs>, 'all': <built-in function all>, 'any': <built-in function any>, 'ascii': <built-in function ascii>, ...}

Fatal Python error: _PyObject_AssertFailed: _PyObject_AssertFailed
Python runtime state: initialized

Current thread 0x00007ffff7c20740 (most recent call first):
  File "/home/vstinner/dev/numpy/env/lib/python3.10/site-packages/Cython/Compiler/Symtab.py", line 339 in __init__
  File "/home/vstinner/dev/numpy/env/lib/python3.10/site-packages/Cython/Compiler/Symtab.py", line 1953 in __init__
  File "/home/vstinner/dev/numpy/env/lib/python3.10/site-packages/Cython/Compiler/Symtab.py", line 2066 in __init__
  File "/home/vstinner/dev/numpy/env/lib/python3.10/site-packages/Cython/Compiler/Symtab.py", line 1549 in declare_c_class
  File "/home/vstinner/dev/numpy/env/lib/python3.10/site-packages/Cython/Compiler/Nodes.py", line 4782 in analyse_declarations
  File "/home/vstinner/dev/numpy/env/lib/python3.10/site-packages/Cython/Compiler/Nodes.py", line 431 in analyse_declarations
  File "/home/vstinner/dev/numpy/env/lib/python3.10/site-packages/Cython/Compiler/ModuleNode.py", line 124 in analyse_declarations
  File "/home/vstinner/dev/numpy/env/lib/python3.10/site-packages/Cython/Compiler/ParseTreeTransforms.py", line 1608 in visit_ModuleNode
  File "/home/vstinner/dev/numpy/env/lib/python3.10/site-packages/Cython/Compiler/ParseTreeTransforms.py", line 1598 in __call__
  File "/home/vstinner/dev/numpy/env/lib/python3.10/site-packages/Cython/Compiler/Pipeline.py", line 335 in run
  File "/home/vstinner/dev/numpy/env/lib/python3.10/site-packages/Cython/Compiler/Pipeline.py", line 355 in run_pipeline
  File "/home/vstinner/dev/numpy/env/lib/python3.10/site-packages/Cython/Compiler/Main.py", line 515 in run_pipeline
  File "/home/vstinner/dev/numpy/env/lib/python3.10/site-packages/Cython/Compiler/Main.py", line 727 in compile_single
  File "/home/vstinner/dev/numpy/env/lib/python3.10/site-packages/Cython/Build/Dependencies.py", line 1208 in cythonize_one
  File "/home/vstinner/dev/numpy/env/lib/python3.10/site-packages/Cython/Build/Dependencies.py", line 1102 in cythonize
  File "/home/vstinner/dev/numpy/env/lib/python3.10/site-packages/Cython/Build/Cythonize.py", line 97 in cython_compile
  File "/home/vstinner/dev/numpy/env/lib/python3.10/site-packages/Cython/Build/Cythonize.py", line 223 in main
  File "/home/vstinner/dev/numpy/env/bin/cythonize", line 33 in <module>

Extension modules: Cython.Plex.Actions, Cython.Plex.Scanners, Cython.Compiler.Scanning, Cython.Tempita._tempita, Cython.Compiler.Visitor, Cython.Compiler.FlowControl (total: 6)

Program received signal SIGABRT, Aborted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43541>
_______________________________________

From report at bugs.python.org  Thu Mar 18 07:19:44 2021
From: report at bugs.python.org (E. Paine)
Date: Thu, 18 Mar 2021 11:19:44 +0000
Subject: [issue43534] turtle.textinput window is not transient
In-Reply-To: <1616029936.62.0.714792032874.issue43534@roundup.psfhosted.org>
Message-ID: <1616066384.67.0.557289961645.issue43534@roundup.psfhosted.org>


Change by E. Paine <paineelisha at gmail.com>:


----------
keywords: +patch
pull_requests: +23679
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24916

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43534>
_______________________________________

From report at bugs.python.org  Thu Mar 18 07:21:39 2021
From: report at bugs.python.org (E. Paine)
Date: Thu, 18 Mar 2021 11:21:39 +0000
Subject: [issue43534] turtle.textinput window is not transient
In-Reply-To: <1616029936.62.0.714792032874.issue43534@roundup.psfhosted.org>
Message-ID: <1616066499.84.0.522668008596.issue43534@roundup.psfhosted.org>


Change by E. Paine <paineelisha at gmail.com>:


----------
versions: +Python 3.10, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43534>
_______________________________________

From report at bugs.python.org  Thu Mar 18 07:34:06 2021
From: report at bugs.python.org (Ilya)
Date: Thu, 18 Mar 2021 11:34:06 +0000
Subject: [issue43542] Add image/heif(heic) to list of media types in
 mimetypes.py
Message-ID: <1616067246.11.0.218850830146.issue43542@roundup.psfhosted.org>


New submission from Ilya <stepinilya at gmail.com>:

Add HEIF and HEIC format to list of media types. It has IANA registration.

IANA: https://www.iana.org/assignments/media-types/image/heic
HEIF Github: https://github.com/nokiatech/heif

----------
components: Library (Lib)
messages: 389012
nosy: martbln
priority: normal
severity: normal
status: open
title: Add image/heif(heic) to list of media types in mimetypes.py
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43542>
_______________________________________

From report at bugs.python.org  Thu Mar 18 07:39:56 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Mar 2021 11:39:56 +0000
Subject: [issue43541] PyEval_EvalCodeEx() can no longer be called with code
 which has (CO_NEWLOCALS | CO_OPTIMIZED) flags
In-Reply-To: <1616065874.01.0.576723621403.issue43541@roundup.psfhosted.org>
Message-ID: <1616067596.45.0.840361708126.issue43541@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

In commit 46496f9d12582bf11f4911ad0f23315d6f277907, I modified _PyEval_BuiltinsFromGlobals() to return a borrowed reference rather than a strong reference. It seems like I forgot to remove a Py_DECREF() in PyEval_EvalCodeEx()!

I'm working on a fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43541>
_______________________________________

From report at bugs.python.org  Thu Mar 18 07:40:05 2021
From: report at bugs.python.org (Ilya)
Date: Thu, 18 Mar 2021 11:40:05 +0000
Subject: [issue43542] Add image/heif(heic) to list of media types in
 mimetypes.py
In-Reply-To: <1616067246.11.0.218850830146.issue43542@roundup.psfhosted.org>
Message-ID: <1616067605.59.0.239866081618.issue43542@roundup.psfhosted.org>


Change by Ilya <stepinilya at gmail.com>:


----------
keywords: +patch
pull_requests: +23680
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24917

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43542>
_______________________________________

From report at bugs.python.org  Thu Mar 18 07:40:07 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 18 Mar 2021 11:40:07 +0000
Subject: [issue42161] Remove private _PyLong_Zero and _PyLong_One variables
In-Reply-To: <1603749577.35.0.864358738107.issue42161@roundup.psfhosted.org>
Message-ID: <1616067607.66.0.536194148052.issue42161@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/issue42161>
_______________________________________

From report at bugs.python.org  Thu Mar 18 07:43:43 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Mar 2021 11:43:43 +0000
Subject: [issue43541] PyEval_EvalCodeEx() can no longer be called with code
 which has (CO_NEWLOCALS | CO_OPTIMIZED) flags
In-Reply-To: <1616065874.01.0.576723621403.issue43541@roundup.psfhosted.org>
Message-ID: <1616067823.19.0.315289689806.issue43541@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +23681
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24918

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43541>
_______________________________________

From report at bugs.python.org  Thu Mar 18 08:34:09 2021
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 18 Mar 2021 12:34:09 +0000
Subject: [issue23767] Library and include paths not added when cross-compiling
 on localized system
In-Reply-To: <1427227440.25.0.884604694697.issue23767@psf.upfronthosting.co.za>
Message-ID: <1616070849.06.0.945760263467.issue23767@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
nosy: +ZackerySpytz
nosy_count: 4.0 -> 5.0
pull_requests: +23683
pull_request: https://github.com/python/cpython/pull/24919

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23767>
_______________________________________

From report at bugs.python.org  Thu Mar 18 09:12:07 2021
From: report at bugs.python.org (R. David Murray)
Date: Thu, 18 Mar 2021 13:12:07 +0000
Subject: [issue43493] EmailMessage mis-folding headers of a certain length
In-Reply-To: <1615754789.09.0.690251462615.issue43493@roundup.psfhosted.org>
Message-ID: <1616073127.46.0.812495855366.issue43493@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

Parsing and newlines have nothing to do with this bug, actually.  I don't think your foldfix post-processing is going to do what you want in the general case.

The source of the bug here is in the folding algorithm in _header_value_parser.  It has checks to see if the "text so far" will fit within the header width, and it starts a new line under vafious conditions.  For example, if there is a single word after Subject: whose length is, say, 70, it would produce the effect you show, because the single word would fit without folding or encoding on a new line.  I don't think this violates the RFC.  What your example shows makes it look like the folder is treating all of the text as if it were a single word, which is obviously wrong.  It is supposed to break at spaces.  You will note that if you increase the repeat count in your example to 16 it folds the line correctly.  So the bug has something to do with the total text so far accumulated for the line being right in that window where it won't fit on the first line but does fit on a line by itself.  This is obviously a bug in the folder, since it should be splitting that text if it isn't a single word, not moving it to a new line as a whole.

Note that this bug is still present on master.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43493>
_______________________________________

From report at bugs.python.org  Thu Mar 18 09:52:01 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Mar 2021 13:52:01 +0000
Subject: [issue43541] PyEval_EvalCodeEx() can no longer be called with code
 which has (CO_NEWLOCALS | CO_OPTIMIZED) flags
In-Reply-To: <1616065874.01.0.576723621403.issue43541@roundup.psfhosted.org>
Message-ID: <1616075521.59.0.658999993373.issue43541@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/issue43541>
_______________________________________

From report at bugs.python.org  Thu Mar 18 09:51:42 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Mar 2021 13:51:42 +0000
Subject: [issue43541] PyEval_EvalCodeEx() can no longer be called with code
 which has (CO_NEWLOCALS | CO_OPTIMIZED) flags
In-Reply-To: <1616065874.01.0.576723621403.issue43541@roundup.psfhosted.org>
Message-ID: <1616075502.36.0.815838701235.issue43541@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset fc980e0be19776ee05dfc5380eb5d6a8092935cb by Victor Stinner in branch 'master':
bpo-43541: Fix PyEval_EvalCodeEx() regression (GH-24918)
https://github.com/python/cpython/commit/fc980e0be19776ee05dfc5380eb5d6a8092935cb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43541>
_______________________________________

From report at bugs.python.org  Thu Mar 18 09:57:56 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Mar 2021 13:57:56 +0000
Subject: [issue43244] Move PyArena C API to the internal C API
In-Reply-To: <1613586690.19.0.383646964758.issue43244@roundup.psfhosted.org>
Message-ID: <1616075876.5.0.517093090642.issue43244@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset eec8e61992fb654d4cf58de4d727c18622b8303e by Victor Stinner in branch 'master':
bpo-43244: Remove the PyAST_Validate() function (GH-24911)
https://github.com/python/cpython/commit/eec8e61992fb654d4cf58de4d727c18622b8303e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43244>
_______________________________________

From report at bugs.python.org  Thu Mar 18 09:57:56 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Mar 2021 13:57:56 +0000
Subject: [issue12575] add a AST validator
In-Reply-To: <1310836208.56.0.617429580425.issue12575@psf.upfronthosting.co.za>
Message-ID: <1616075876.61.0.917243584506.issue12575@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset eec8e61992fb654d4cf58de4d727c18622b8303e by Victor Stinner in branch 'master':
bpo-43244: Remove the PyAST_Validate() function (GH-24911)
https://github.com/python/cpython/commit/eec8e61992fb654d4cf58de4d727c18622b8303e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12575>
_______________________________________

From report at bugs.python.org  Thu Mar 18 10:33:56 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Mar 2021 14:33:56 +0000
Subject: [issue43244] Move PyArena C API to the internal C API
In-Reply-To: <1613586690.19.0.383646964758.issue43244@roundup.psfhosted.org>
Message-ID: <1616078036.45.0.0631021543725.issue43244@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The work on this issue started in Python 3.9 with bpo-21120 which excluded Python-ast.h, ast.h and asdl.h from the limited C API: commit 421a72af4deaec96a49a79951b9c2546a2faa13d.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43244>
_______________________________________

From report at bugs.python.org  Thu Mar 18 10:56:34 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 18 Mar 2021 14:56:34 +0000
Subject: [issue43512] Bug in isinstance(instance,
 cls) with cls being a protocol? (PEP 544)
In-Reply-To: <1616064303.65.0.357689459528.issue43512@roundup.psfhosted.org>
Message-ID: <CAP7+vJ+b5NSQe6Tb-AdxT8G+VvhqY_6idaD_m-SPBMiO5PmVZQ@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

To be honest, I just don?t have time to deal,with this, so I?m hoping some
other core dev has an opinion. But I can?t help you find one either. Sorry,
but that?s the reality of open source development. --
--Guido (mobile)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43512>
_______________________________________

From report at bugs.python.org  Thu Mar 18 11:30:03 2021
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 18 Mar 2021 15:30:03 +0000
Subject: [issue41561] test_ssl fails in Ubuntu 20.04:
 test_min_max_version_mismatch
In-Reply-To: <1597551049.14.0.0578030464715.issue41561@roundup.psfhosted.org>
Message-ID: <1616081403.22.0.680578170428.issue41561@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Dimitri John Ledkov from Canonical has opened a feature request for a context validation feature on the OpenSSL issue tracker, https://github.com/openssl/openssl/issues/14607

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41561>
_______________________________________

From report at bugs.python.org  Thu Mar 18 11:30:37 2021
From: report at bugs.python.org (Paul)
Date: Thu, 18 Mar 2021 15:30:37 +0000
Subject: [issue43512] Bug in isinstance(instance,
 cls) with cls being a protocol? (PEP 544)
In-Reply-To: <1615888944.07.0.094574416265.issue43512@roundup.psfhosted.org>
Message-ID: <1616081437.37.0.22619627111.issue43512@roundup.psfhosted.org>


Paul <paul.dest at web.de> added the comment:

The authors of PEP 544 are Ivan Levkivskyi, Jukka Lehtosalo, and ?ukasz Langa. I think their opinion should count.

I can see "levkivskyi" in the noisy list, but not the other two. And don't see any possibility to add them. Who can add them?

And if added: will they read a notification of an issue in state "closed"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43512>
_______________________________________

From report at bugs.python.org  Thu Mar 18 11:39:47 2021
From: report at bugs.python.org (=?utf-8?b?0JnQvtGC0LAgOjM=?=)
Date: Thu, 18 Mar 2021 15:39:47 +0000
Subject: [issue43543] stupid download
Message-ID: <1616081987.44.0.777033345777.issue43543@roundup.psfhosted.org>


New submission from ???? :3 <yotabestww at gmail.com>:

fucking retards, how to new or default people can download old versions  of python? Maybe you can made better and easy desing? Stupud idiots

----------
components: C API
messages: 389022
nosy: yotabestww
priority: normal
severity: normal
status: open
title: stupid download
type: resource usage

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43543>
_______________________________________

From report at bugs.python.org  Thu Mar 18 11:45:55 2021
From: report at bugs.python.org (Petr Viktorin)
Date: Thu, 18 Mar 2021 15:45:55 +0000
Subject: [issue43543] stupid download
In-Reply-To: <1616081987.44.0.777033345777.issue43543@roundup.psfhosted.org>
Message-ID: <1616082355.93.0.984246303886.issue43543@roundup.psfhosted.org>


Change by Petr Viktorin <encukou at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43543>
_______________________________________

From report at bugs.python.org  Thu Mar 18 11:49:43 2021
From: report at bugs.python.org (=?utf-8?q?Gu=C3=A9na=C3=ABl_Muller?=)
Date: Thu, 18 Mar 2021 15:49:43 +0000
Subject: [issue43544] mimetype default list make a wrong guess for illustrator
 file
Message-ID: <1616082583.58.0.664742834021.issue43544@roundup.psfhosted.org>


New submission from Gu?na?l Muller <inkey at inkey-art.net>:

mimetypes lib consider illustrator file ('.ai') as 'application/postscript' type. This is correct... but also wrong.

Old illustrator file (illustrator 9) are real postscript file but modern one are technically pdf. So guessing .ai as postscript lead to wrong guessing if you're using some software that make decision based on mimetype, you can of course, check both file_extension and mimetype but this remove usefulness of mimetype.

----------
messages: 389023
nosy: Inkhey
priority: normal
severity: normal
status: open
title: mimetype default list make a wrong guess for illustrator file
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43544>
_______________________________________

From report at bugs.python.org  Thu Mar 18 11:54:46 2021
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 18 Mar 2021 15:54:46 +0000
Subject: [issue23767] Library and include paths not added when cross-compiling
 on localized system
In-Reply-To: <1427227440.25.0.884604694697.issue23767@psf.upfronthosting.co.za>
Message-ID: <1616082886.27.0.138851789649.issue23767@roundup.psfhosted.org>


Matthias Klose <doko at debian.org> added the comment:

that looks fine. Maybe also set LANG=C ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23767>
_______________________________________

From report at bugs.python.org  Thu Mar 18 12:02:44 2021
From: report at bugs.python.org (Ken Jin)
Date: Thu, 18 Mar 2021 16:02:44 +0000
Subject: [issue43512] Bug in isinstance(instance,
 cls) with cls being a protocol? (PEP 544)
In-Reply-To: <1615888944.07.0.094574416265.issue43512@roundup.psfhosted.org>
Message-ID: <1616083364.02.0.968165368755.issue43512@roundup.psfhosted.org>


Ken Jin <kenjin4096 at gmail.com> added the comment:

@paul-dest
Anyone can add them using the bug tracker Web interface in the "Nosy List" field above the message box.

Yes they will receive a notification. Adding people sends them an email and subscribes them to this issue (even if closed).

I don't know if Jukka is on this bug tracker (at the very least I can't find them in the search). You may have better luck getting an opinion from others if you send an email to typing-sig instead https://mail.python.org/archives/list/typing-sig at python.org/. That's usually where PEP change/interpretation-related discussion goes (from my own experience).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43512>
_______________________________________

From report at bugs.python.org  Thu Mar 18 12:03:58 2021
From: report at bugs.python.org (Dan Snider)
Date: Thu, 18 Mar 2021 16:03:58 +0000
Subject: [issue43545] Use LOAD_GLOBAL to set __module__ in class def
Message-ID: <1616083438.62.0.932778825065.issue43545@roundup.psfhosted.org>


New submission from Dan Snider <mr.assume.away at gmail.com>:

Other than obvious performance implications this has, usage of LOAD_NAME makes defining cls.__name__ from within metaclass.__prepare__ difficult.

----------
messages: 389026
nosy: bup
priority: normal
severity: normal
status: open
title: Use LOAD_GLOBAL to set __module__ in class def
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43545>
_______________________________________

From report at bugs.python.org  Thu Mar 18 12:14:58 2021
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 18 Mar 2021 16:14:58 +0000
Subject: [issue40645] Use OpenSSL's HMAC API
In-Reply-To: <1589641291.33.0.635001105595.issue40645@roundup.psfhosted.org>
Message-ID: <1616084098.83.0.875288879172.issue40645@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

memo to me: switch to new C implementation of HMAC.

----------
priority: normal -> critical
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40645>
_______________________________________

From report at bugs.python.org  Thu Mar 18 12:28:51 2021
From: report at bugs.python.org (Paul)
Date: Thu, 18 Mar 2021 16:28:51 +0000
Subject: [issue43512] Bug in isinstance(instance,
 cls) with cls being a protocol? (PEP 544)
In-Reply-To: <1615888944.07.0.094574416265.issue43512@roundup.psfhosted.org>
Message-ID: <1616084931.71.0.965777274853.issue43512@roundup.psfhosted.org>


Paul <paul.dest at web.de> added the comment:

@kj
Thank you, Ken! I'll try it on the list as advised by you!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43512>
_______________________________________

From report at bugs.python.org  Thu Mar 18 12:33:56 2021
From: report at bugs.python.org (Larry Trammell)
Date: Thu, 18 Mar 2021 16:33:56 +0000
Subject: [issue43483] Loss of content in simple (but oversize) SAX parsing
In-Reply-To: <1615599352.35.0.560655392831.issue43483@roundup.psfhosted.org>
Message-ID: <1616085236.63.0.943485947872.issue43483@roundup.psfhosted.org>


Larry Trammell <ridgerat at nwi.net> added the comment:

Eric, now that you know as much as I do about the nature and scope of the peculiar parsing behavior, do you have any suggestions about how to proceed from here?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43483>
_______________________________________

From report at bugs.python.org  Thu Mar 18 12:36:04 2021
From: report at bugs.python.org (Paul)
Date: Thu, 18 Mar 2021 16:36:04 +0000
Subject: [issue43512] Bug in isinstance(instance,
 cls) with cls being a protocol? (PEP 544)
In-Reply-To: <1615888944.07.0.094574416265.issue43512@roundup.psfhosted.org>
Message-ID: <1616085364.62.0.555569876816.issue43512@roundup.psfhosted.org>


Change by Paul <paul.dest at web.de>:


----------
nosy: +Jukka Lehtosalo, lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43512>
_______________________________________

From report at bugs.python.org  Thu Mar 18 12:42:51 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 18 Mar 2021 16:42:51 +0000
Subject: [issue43483] Loss of content in simple (but oversize) SAX parsing
In-Reply-To: <1615599352.35.0.560655392831.issue43483@roundup.psfhosted.org>
Message-ID: <1616085771.57.0.513988929421.issue43483@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I'd add a note to the docs about it, then open a feature request to change the behavior. You could turn this issue into a documentation fix.

Unfortunately I don't know if there's a core dev who pays attention to the XML parsers. But I can probably find out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43483>
_______________________________________

From report at bugs.python.org  Thu Mar 18 13:14:28 2021
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 18 Mar 2021 17:14:28 +0000
Subject: [issue43543] stupid download
Message-ID: <1616087668.15.0.263266313114.issue43543@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
Removed message: https://bugs.python.org/msg389022

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43543>
_______________________________________

From report at bugs.python.org  Thu Mar 18 13:14:48 2021
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 18 Mar 2021 17:14:48 +0000
Subject: [issue43543] Spam
Message-ID: <1616087688.01.0.425361252951.issue43543@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
components:  -C API
nosy:  -yotabestww
title: stupid download -> Spam
type: resource usage -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43543>
_______________________________________

From report at bugs.python.org  Thu Mar 18 13:21:55 2021
From: report at bugs.python.org (coyot linden)
Date: Thu, 18 Mar 2021 17:21:55 +0000
Subject: [issue8704] cgitb sends a bogus HTTP header if the app crashes before
 finishing headers
In-Reply-To: <1273759972.28.0.178671810955.issue8704@psf.upfronthosting.co.za>
Message-ID: <1616088115.31.0.00831131852657.issue8704@roundup.psfhosted.org>


coyot linden <coyot at lindenlab.com> added the comment:

Ran into this also, got:

AH02429: Response header name '<!--' contains invalid characters, aborting request

----------
nosy: +coyot

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8704>
_______________________________________

From report at bugs.python.org  Thu Mar 18 13:22:46 2021
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 18 Mar 2021 17:22:46 +0000
Subject: [issue40645] Use OpenSSL's HMAC API
In-Reply-To: <1589641291.33.0.635001105595.issue40645@roundup.psfhosted.org>
Message-ID: <1616088166.64.0.905241497906.issue40645@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +23684
pull_request: https://github.com/python/cpython/pull/24920

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40645>
_______________________________________

From report at bugs.python.org  Thu Mar 18 13:36:22 2021
From: report at bugs.python.org (miss-islington)
Date: Thu, 18 Mar 2021 17:36:22 +0000
Subject: [issue43521] Allow `ast.unparse` to handle NaNs and empty sets
In-Reply-To: <1615923546.68.0.291337558212.issue43521@roundup.psfhosted.org>
Message-ID: <1616088982.73.0.363011142536.issue43521@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 08ff4369afca84587b1c82034af4e9f64caddbf2 by Kodi Arfer in branch 'master':
bpo-43521: Allow ast.unparse with empty sets and NaN (GH-24897)
https://github.com/python/cpython/commit/08ff4369afca84587b1c82034af4e9f64caddbf2


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43521>
_______________________________________

From report at bugs.python.org  Thu Mar 18 13:36:47 2021
From: report at bugs.python.org (miss-islington)
Date: Thu, 18 Mar 2021 17:36:47 +0000
Subject: [issue43521] Allow `ast.unparse` to handle NaNs and empty sets
In-Reply-To: <1615923546.68.0.291337558212.issue43521@roundup.psfhosted.org>
Message-ID: <1616089007.67.0.26002201387.issue43521@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +23685
pull_request: https://github.com/python/cpython/pull/24921

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43521>
_______________________________________

From report at bugs.python.org  Thu Mar 18 13:43:33 2021
From: report at bugs.python.org (hai shi)
Date: Thu, 18 Mar 2021 17:43:33 +0000
Subject: [issue35134] Add a new Include/cpython/ subdirectory for the "CPython
 API" with implementation details
In-Reply-To: <1541076409.33.0.788709270274.issue35134@psf.upfronthosting.co.za>
Message-ID: <1616089413.7.0.629986246826.issue35134@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
nosy: +shihai1991
nosy_count: 8.0 -> 9.0
pull_requests: +23686
pull_request: https://github.com/python/cpython/pull/24922

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35134>
_______________________________________

From report at bugs.python.org  Thu Mar 18 14:32:12 2021
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 18 Mar 2021 18:32:12 +0000
Subject: [issue43540] importlib: Document how to replace load_module() in
 What's New in Python 3.10
In-Reply-To: <1616062773.63.0.458155955758.issue43540@roundup.psfhosted.org>
Message-ID: <1616092332.08.0.162990338757.issue43540@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

The documentation states in the deprecation notice for https://docs.python.org/3/library/importlib.html#importlib.abc.Loader.load_module that create_module() and exec_module() are what are necessary. But the it isn't a direct 1:1 replacement and people are expected to use all of the helper code so it's going to be very specific to the need of the code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43540>
_______________________________________

From report at bugs.python.org  Thu Mar 18 14:58:26 2021
From: report at bugs.python.org (Anentropic)
Date: Thu, 18 Mar 2021 18:58:26 +0000
Subject: [issue43546] "Impossible" KeyError from importlib._bootstrap acquire
 line 110
Message-ID: <1616093906.25.0.990565288145.issue43546@roundup.psfhosted.org>


New submission from Anentropic <ego at anentropic.com>:

We have a Django 2.2.19 project on Python 3.9.2 on Debian (slim-buster) in Docker.

A bizarre problem started happening to us this week.

First I'll show the symptom, we started getting the following error:

...
  File "/root/.pyenv/versions/3.9.2/lib/python3.9/site-packages/django/db/migrations/autodetector.py", line 10, in <module>
    from django.db.migrations.optimizer import MigrationOptimizer
  File "<frozen importlib._bootstrap>", line 1004, in _find_and_load
  File "<frozen importlib._bootstrap>", line 158, in __enter__
  File "<frozen importlib._bootstrap>", line 110, in acquire
KeyError: 140426340123264

If I look at the source for _bootstrap.py, that error should be impossible:
https://github.com/python/cpython/blob/v3.9.2/Lib/importlib/_bootstrap.py#L110

At the top of the acquire method it does:

    tid = _thread.get_ident()
    _blocking_on[tid] = self

and then on line 110 where we get the KeyError:

    del _blocking_on[tid]

both `tid` and `_blocking_on` are local vars and none of the other lines in the method touch them

So how do we get a KeyError?

I can only think that something mutates the underlying value of `tid`, but it's supposed to be an int so that's very weird.

I started with the symptom because our context for this is complicated to explain. I did find a fix that prevents the error but I do not understand the link between cause and effect.

Our context:
- we have a large unit test suite for the project which we run in Jenkins
- we split the tests across several Jenkins nodes to run in parallel in isolated docker environments
- we use some bash to like this to split the test cases:
  find project/ -iname "test*.py" -print0 | \
    xargs --null grep -E '(def test)|(def step_)' -l | \
    split -n "r/$NODE_ID/$NODES" | \
    xargs ci/bin/run-tests
- ci/bin/run-tests is just a wrapper which calls Django's manage.py test command
  so it receives a list of filenames like "project/metrics/tests/test_client.py" as args
- using "nose" test runner via django-nose FWIW

We currently split tests across 3 nodes, and it was always node 2 which would fail.
I found that commenting out a test case in any of the files being passed to node 2 would prevent the error from occurring.
Note that in this case we are still passing *exactly the same filenames* as cli args to the test runner.

Splitting the tests across 4 nodes instead of 3 also seems to prevent the error.
So it seems like, in some way I don't understand, we just have too many test cases.
Perhaps nose is doing something wrong or inefficient when given lots of filenames.

But I'm reporting here because the error we get from importlib._bootstrap looks like it should be impossible.

----------
messages: 389034
nosy: anentropic
priority: normal
severity: normal
status: open
title: "Impossible" KeyError from importlib._bootstrap acquire line 110
type: crash
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43546>
_______________________________________

From report at bugs.python.org  Thu Mar 18 15:09:34 2021
From: report at bugs.python.org (Anentropic)
Date: Thu, 18 Mar 2021 19:09:34 +0000
Subject: [issue43546] "Impossible" KeyError from importlib._bootstrap acquire
 line 110
In-Reply-To: <1616093906.25.0.990565288145.issue43546@roundup.psfhosted.org>
Message-ID: <1616094574.48.0.661311625991.issue43546@roundup.psfhosted.org>


Anentropic <ego at anentropic.com> added the comment:

FWIW...

django-nose==1.4.6
nose==1.3.7

The only use of threading I can see in Nose is here:
https://github.com/nose-devs/nose/blob/release_1.3.7/nose/plugins/logcapture.py

But we are passing --nologcapture flag and nosetests echoes that flag back to us at the top of the test run, so I believe the feature is disabled

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43546>
_______________________________________

From report at bugs.python.org  Thu Mar 18 15:14:07 2021
From: report at bugs.python.org (Anentropic)
Date: Thu, 18 Mar 2021 19:14:07 +0000
Subject: [issue43546] "Impossible" KeyError from importlib._bootstrap acquire
 line 110
In-Reply-To: <1616093906.25.0.990565288145.issue43546@roundup.psfhosted.org>
Message-ID: <1616094847.91.0.673935819117.issue43546@roundup.psfhosted.org>


Anentropic <ego at anentropic.com> added the comment:

https://docs.python.org/3/library/_thread.html#_thread.get_ident

> Thread identifiers may be recycled when a thread exits and another thread is created.

I still don't see how we get that KeyError but it feels like it might be something to do with this

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43546>
_______________________________________

From report at bugs.python.org  Thu Mar 18 15:21:20 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 18 Mar 2021 19:21:20 +0000
Subject: [issue43534] turtle.textinput window is not transient
In-Reply-To: <1616029936.62.0.714792032874.issue43534@roundup.psfhosted.org>
Message-ID: <1616095280.91.0.645618815519.issue43534@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +23687
pull_request: https://github.com/python/cpython/pull/24923

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43534>
_______________________________________

From report at bugs.python.org  Thu Mar 18 15:32:54 2021
From: report at bugs.python.org (Anentropic)
Date: Thu, 18 Mar 2021 19:32:54 +0000
Subject: [issue43546] "Impossible" KeyError from importlib._bootstrap acquire
 line 110
In-Reply-To: <1616093906.25.0.990565288145.issue43546@roundup.psfhosted.org>
Message-ID: <1616095974.23.0.0590134245888.issue43546@roundup.psfhosted.org>


Anentropic <ego at anentropic.com> added the comment:

It turns out splitting the tests across 2 nodes rather than 4 also prevents the error.

So it's not a case of "too many" tests.

So then I think maybe it needs to be a specific number to trigger the error?

And yes, if I duplicate one of our test cases (I mean test method in a TestCase class) so that there is one more than before... that also prevents the error!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43546>
_______________________________________

From report at bugs.python.org  Thu Mar 18 15:43:00 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 18 Mar 2021 19:43:00 +0000
Subject: [issue43546] "Impossible" KeyError from importlib._bootstrap acquire
 line 110
In-Reply-To: <1616093906.25.0.990565288145.issue43546@roundup.psfhosted.org>
Message-ID: <1616096580.17.0.356397195551.issue43546@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It looks like method _ModuleLock.acquire() was re-entered in the same thread.

* Enter acquire() first time, set _blocking_on[tid].
* Trigger some callback (profiler, debugger, tracemalloc) which uses import and calls acquire() again from the same thread.
* Enter acquire() second time, set _blocking_on[tid].
* Delete _blocking_on[tid] and leave the second acquire().
* Try to leave the first acquire() and delete _blocking_on[tid] again.

----------
nosy: +brett.cannon, eric.snow, ncoghlan, pitrou, serhiy.storchaka, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43546>
_______________________________________

From report at bugs.python.org  Thu Mar 18 16:03:39 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Thu, 18 Mar 2021 20:03:39 +0000
Subject: [issue35056] Test leaks of memory not managed by Python allocator
In-Reply-To: <1540323419.75.0.788709270274.issue35056@psf.upfronthosting.co.za>
Message-ID: <1616097819.13.0.281348169513.issue35056@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

> _sqlite: call sqlite3_config(SQLITE_CONFIG_MALLOC, pMem) to use PyMem_RawMalloc()

SQLite requires the xSize member of sqlite3_mem_methods to be implemented for this to work, so we'd have to implement msize(). The msize() idea seems to have been rejected in PEP 445, though it mentions using debug hooks to implement it.

See also https://www.sqlite.org/c3ref/mem_methods.html

Anyway, attached is a PoC patch with a fixed 10k mem pool for the sqlite3 module :)

----------
keywords: +patch
Added file: https://bugs.python.org/file49890/patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35056>
_______________________________________

From report at bugs.python.org  Thu Mar 18 16:18:41 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Mar 2021 20:18:41 +0000
Subject: [issue43546] "Impossible" KeyError from importlib._bootstrap acquire
 line 110
In-Reply-To: <1616093906.25.0.990565288145.issue43546@roundup.psfhosted.org>
Message-ID: <1616098721.75.0.794893091916.issue43546@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43546>
_______________________________________

From report at bugs.python.org  Thu Mar 18 17:25:38 2021
From: report at bugs.python.org (Hans-Christoph Steiner)
Date: Thu, 18 Mar 2021 21:25:38 +0000
Subject: [issue43547] support ZIP files with zeroed out fields (e.g. for
 reproducible builds)
Message-ID: <1616102738.26.0.451702371832.issue43547@roundup.psfhosted.org>


New submission from Hans-Christoph Steiner <hans at eds.org>:

It is now standard for Java JARs and Android APKs (both ZIP files) to zero out lots of the fields in the ZIP header.  For example:

* each file entry has the date set to zero
* the create_system is always set to zero on all platforms

zipfile currently cannot create such ZIPs because of two small restrictions that it introduced:

* must use a tuple of 6 values to set the date
* forced create_system value based on sys.platform == 'win32'
* maybe other fields?

I lump these together because it might make sense to handle this with a single argument, something like zero_header=True.  The use case is for working with ZIP, JAR, APK, AAR files for reproducible builds.  The whole build system for F-Droid is built in Python.  We need to be able to copy the JAR/APK signatures in order to reproduce signed builds using only the source code and the signature files themselves.  Right now, that's not possible because building a ZIP with Python's zipfile cannot zero out the ZIP header like other tools can, including Java.

----------
components: IO, Library (Lib)
messages: 389040
nosy: eighthave
priority: normal
severity: normal
status: open
title: support ZIP files with zeroed out fields (e.g. for reproducible builds)
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43547>
_______________________________________

From report at bugs.python.org  Thu Mar 18 18:00:47 2021
From: report at bugs.python.org (Hans-Christoph Steiner)
Date: Thu, 18 Mar 2021 22:00:47 +0000
Subject: [issue43547] support ZIP files with zeroed out fields (e.g. for
 reproducible builds)
In-Reply-To: <1616102738.26.0.451702371832.issue43547@roundup.psfhosted.org>
Message-ID: <1616104847.06.0.869775369828.issue43547@roundup.psfhosted.org>


Hans-Christoph Steiner <hans at eds.org> added the comment:

I just found another specific example in _open_to_write().  0 is a valid value for zinfo.external_attr.  But this code always forces 0 to something else:

        if not zinfo.external_attr:
            zinfo.external_attr = 0o600 << 16  # permissions: ?rw-------

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43547>
_______________________________________

From report at bugs.python.org  Thu Mar 18 18:06:57 2021
From: report at bugs.python.org (miss-islington)
Date: Thu, 18 Mar 2021 22:06:57 +0000
Subject: [issue41561] test_ssl fails in Ubuntu 20.04:
 test_min_max_version_mismatch
In-Reply-To: <1597551049.14.0.0578030464715.issue41561@roundup.psfhosted.org>
Message-ID: <1616105217.24.0.857584499297.issue41561@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset f6c6b5821bff815bdc810de53992fd1fbdb2edd4 by Christian Heimes in branch 'master':
bpo-41561: Add workaround for Ubuntu's custom security level (GH-24915)
https://github.com/python/cpython/commit/f6c6b5821bff815bdc810de53992fd1fbdb2edd4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41561>
_______________________________________

From report at bugs.python.org  Thu Mar 18 18:07:06 2021
From: report at bugs.python.org (miss-islington)
Date: Thu, 18 Mar 2021 22:07:06 +0000
Subject: [issue41561] test_ssl fails in Ubuntu 20.04:
 test_min_max_version_mismatch
In-Reply-To: <1597551049.14.0.0578030464715.issue41561@roundup.psfhosted.org>
Message-ID: <1616105226.98.0.522022998427.issue41561@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +23688
pull_request: https://github.com/python/cpython/pull/24925

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41561>
_______________________________________

From report at bugs.python.org  Thu Mar 18 18:07:14 2021
From: report at bugs.python.org (miss-islington)
Date: Thu, 18 Mar 2021 22:07:14 +0000
Subject: [issue41561] test_ssl fails in Ubuntu 20.04:
 test_min_max_version_mismatch
In-Reply-To: <1597551049.14.0.0578030464715.issue41561@roundup.psfhosted.org>
Message-ID: <1616105234.23.0.509378041663.issue41561@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +23689
pull_request: https://github.com/python/cpython/pull/24926

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41561>
_______________________________________

From report at bugs.python.org  Thu Mar 18 18:07:25 2021
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 18 Mar 2021 22:07:25 +0000
Subject: [issue21506] [Windows] installations should include pythonX.exe and
 pythonX.Y.exe executables
In-Reply-To: <1400067370.68.0.607872004364.issue21506@psf.upfronthosting.co.za>
Message-ID: <1616105245.48.0.469695150212.issue21506@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

One issues with versioned "X.Y" executables is interference with normal handling of the ".exe" extension. For example, in "python3.10" the ".10"  counts as an extension, so normally ".exe" won't be appended when searching for the name. 

This affects SearchPathW() searches that supply a default ".exe" extension, such as what CreateProcessW() uses to find the executable parsed from lpCommandLine. For example, subprocess.call('python3.9') won't append '.exe' to find "python3.9.exe" in the search path. 

It also affects the shell API's "App Paths" search, since the shell won't append ".exe" to a name that already has an extension. (The machine and user "App Paths" keys are the Windows shell equivalent of Unix "/usr/bin" and "$HOME/.local/bin", but more powerful.) For example, the store app distribution of Python 3.9 creates a "python3.9.exe" entry in the user's "App Paths", but os.startfile('python3.9') doesn't work; it has to be os.startfile('python3.9.exe').

Using "_" instead of "." would be compatible with Windows filename conventions -- e.g. "python3_10.exe". But this is an uphill battle against a Unix convention that's probably been in use since the 1970s or 1980s.

----------
components:  -Build
nosy: +paul.moore
title: Windows MSI installer should mklink (symlink) python.exe to python2.7.exe -> [Windows] installations should include pythonX.exe and pythonX.Y.exe executables
versions: +Python 3.10 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21506>
_______________________________________

From report at bugs.python.org  Thu Mar 18 18:11:51 2021
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 18 Mar 2021 22:11:51 +0000
Subject: [issue27318] Add support for symlinks to zipfile
In-Reply-To: <1465905334.15.0.513827452466.issue27318@psf.upfronthosting.co.za>
Message-ID: <1616105511.35.0.311989121698.issue27318@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
versions: +Python 3.10 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27318>
_______________________________________

From report at bugs.python.org  Thu Mar 18 18:20:31 2021
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 18 Mar 2021 22:20:31 +0000
Subject: [issue28708] Low FD_SETSIZE limit on Windows
In-Reply-To: <1479250358.07.0.768722440644.issue28708@psf.upfronthosting.co.za>
Message-ID: <1616106031.8.0.0968389817663.issue28708@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
components: +Extension Modules -Build
versions: +Python 3.10 -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28708>
_______________________________________

From report at bugs.python.org  Thu Mar 18 18:31:43 2021
From: report at bugs.python.org (miss-islington)
Date: Thu, 18 Mar 2021 22:31:43 +0000
Subject: [issue41561] test_ssl fails in Ubuntu 20.04:
 test_min_max_version_mismatch
In-Reply-To: <1597551049.14.0.0578030464715.issue41561@roundup.psfhosted.org>
Message-ID: <1616106703.78.0.568470636407.issue41561@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 3365e684a83a6bc9e2e2198dca54b42711bd3c90 by Miss Islington (bot) in branch '3.9':
bpo-41561: Add workaround for Ubuntu's custom security level (GH-24915)
https://github.com/python/cpython/commit/3365e684a83a6bc9e2e2198dca54b42711bd3c90


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41561>
_______________________________________

From report at bugs.python.org  Thu Mar 18 18:41:20 2021
From: report at bugs.python.org (miss-islington)
Date: Thu, 18 Mar 2021 22:41:20 +0000
Subject: [issue41561] test_ssl fails in Ubuntu 20.04:
 test_min_max_version_mismatch
In-Reply-To: <1597551049.14.0.0578030464715.issue41561@roundup.psfhosted.org>
Message-ID: <1616107280.57.0.595145059359.issue41561@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 50511677f59464e612cfef0cd0e139fe07e87737 by Miss Islington (bot) in branch '3.8':
bpo-41561: Add workaround for Ubuntu's custom security level (GH-24915)
https://github.com/python/cpython/commit/50511677f59464e612cfef0cd0e139fe07e87737


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41561>
_______________________________________

From report at bugs.python.org  Thu Mar 18 18:46:01 2021
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 18 Mar 2021 22:46:01 +0000
Subject: [issue41561] test_ssl fails in Ubuntu 20.04:
 test_min_max_version_mismatch
In-Reply-To: <1597551049.14.0.0578030464715.issue41561@roundup.psfhosted.org>
Message-ID: <1616107561.99.0.848037397339.issue41561@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +23690
pull_request: https://github.com/python/cpython/pull/24928

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41561>
_______________________________________

From report at bugs.python.org  Thu Mar 18 18:51:56 2021
From: report at bugs.python.org (miss-islington)
Date: Thu, 18 Mar 2021 22:51:56 +0000
Subject: [issue43521] Allow `ast.unparse` to handle NaNs and empty sets
In-Reply-To: <1615923546.68.0.291337558212.issue43521@roundup.psfhosted.org>
Message-ID: <1616107916.56.0.886576389504.issue43521@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e8e341993e3f80a3c456fb8e0219530c93c13151 by Miss Islington (bot) in branch '3.9':
bpo-43521: Allow ast.unparse with empty sets and NaN (GH-24897)
https://github.com/python/cpython/commit/e8e341993e3f80a3c456fb8e0219530c93c13151


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43521>
_______________________________________

From report at bugs.python.org  Thu Mar 18 18:52:29 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 18 Mar 2021 22:52:29 +0000
Subject: [issue43521] Allow `ast.unparse` to handle NaNs and empty sets
In-Reply-To: <1615923546.68.0.291337558212.issue43521@roundup.psfhosted.org>
Message-ID: <1616107949.94.0.805479847496.issue43521@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/issue43521>
_______________________________________

From report at bugs.python.org  Thu Mar 18 18:59:52 2021
From: report at bugs.python.org (Steve Dower)
Date: Thu, 18 Mar 2021 22:59:52 +0000
Subject: [issue31103] Windows Installer Product does not include micro version
 in display name
In-Reply-To: <1501668288.41.0.228516476421.issue31103@psf.upfronthosting.co.za>
Message-ID: <1616108392.79.0.0809823962111.issue31103@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Eryk is correct, the displayed version number is the one that determines whether to update existing files or not, and the fourth field is (IIUC) not used for this by WiX (our installer technology). We also cannot override the displayed version using this technology.

It's also worth noting that the Windows Store package is similarly limited, and has a slightly different scheme again (I forget why, but if it could've been identical then it would have been - I guess it was because we cannot do prerelease versions there).

So the only real fix is for someone to rewrite the entire installer using a new technology. I'm not volunteering to do that, and as long as I'm the build manager I'm not going to accept any PRs doing it (though that's not to say that I won't do it myself, just that I'm not currently considering unsolicited contributions and doing it would be a waste of your time). Consistency between releases is more important right now - it's not difficult to find the version number for a particular install if needed (just look at its file properties).

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31103>
_______________________________________

From report at bugs.python.org  Thu Mar 18 19:22:39 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 18 Mar 2021 23:22:39 +0000
Subject: [issue43535] Make str.join auto-convert inputs to strings.
In-Reply-To: <1616034546.27.0.0632217994438.issue43535@roundup.psfhosted.org>
Message-ID: <1616109759.58.0.139932606575.issue43535@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

>  What changed?

It comes up almost every week that I teach a Python course.  Eventually, I've come to see the light :-)

Also, I worked though the steps and found an efficiency gain for new code with no detriment to existing code.

Lastly, I used to worry a lot about join() also being defined for bytes() and bytearray().  But after working through the use cases, I can see that we get an even bigger win.  People seem to have a hard time figuring out how to convert a single integer to a byte.  The expression "bytes([x])" isn't at all intuitive; it doesn't look nice in a list comprehension, and is incomprehensible when used with map() and lambda.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43535>
_______________________________________

From report at bugs.python.org  Thu Mar 18 19:49:45 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 18 Mar 2021 23:49:45 +0000
Subject: [issue42161] Remove private _PyLong_Zero and _PyLong_One variables
In-Reply-To: <1603749577.35.0.864358738107.issue42161@roundup.psfhosted.org>
Message-ID: <1616111385.45.0.362755556253.issue42161@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I don't have a PR in-hand.  I just ran across this when trying to explain 3.9 vs 3.10 timings and M-1 vs Intel timings.   Ideally, all of these PRs should be reverted.  Short of that, each change needs to be reviewed to see if it created extra work inside a loop.  There are 35 calls to PyLong_GetOne and 3 for PyLong_GetZero.  Each of those should be checked.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42161>
_______________________________________

From report at bugs.python.org  Thu Mar 18 21:56:09 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 19 Mar 2021 01:56:09 +0000
Subject: [issue24823] ctypes.create_string_buffer does not add NUL if
 len(init) == size
In-Reply-To: <1438942688.18.0.266077254276.issue24823@psf.upfronthosting.co.za>
Message-ID: <1616118969.83.0.265832797549.issue24823@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> The Documentation component is for issues that only change the docs

That's not clear in the triaging guide for the multi-select component field. (However, it is clearly stated as such for the GitHub PR label "type-documentation".) If that's really the case, then I'll manually nosy the docs team in cases such as this. When wording is disputed and needs to be clarified, I want an expert at documentation to propose or review the change.

> Adding 'Documentation' amounts to rejecting this patch or anything 
> else that changes the code.

That was not my intent. I accepted Tom's position that "string" means a C string, which must be null-terminated. So I added the "Lib" tag and left it as a "behavior" issue instead of changing it to "enhancement". 

I'm concerned that the old c_buffer() function is defined to call create_string_buffer(), and it's not officially deprecated in the docs or the source code. (There's a commented-out deprecation warning.) A related concern is that the documentation says that the length of a byte-string initializer should not be used if the size is specified, which allows creating a character-array that's not null-terminated. If it raises a ValueError in this case, the wording should be clear that the value of `size` must be large enough to set the initial value as a null-terminated string. I also would want c_buffer() to get a separate implementation in this case. 

If accepted, create_unicode_buffer(init, size) should also be changed to require that init is set as a null-terminated string.

----------
components: +Library (Lib)
priority: low -> normal
stage: needs patch -> patch review
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24823>
_______________________________________

From report at bugs.python.org  Thu Mar 18 21:57:45 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 19 Mar 2021 01:57:45 +0000
Subject: [issue24823] ctypes.create_string_buffer does not add NUL if
 len(init) == size
In-Reply-To: <1438942688.18.0.266077254276.issue24823@psf.upfronthosting.co.za>
Message-ID: <1616119065.15.0.817212184934.issue24823@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
components: +ctypes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24823>
_______________________________________

From report at bugs.python.org  Thu Mar 18 22:44:55 2021
From: report at bugs.python.org (behind thebrain)
Date: Fri, 19 Mar 2021 02:44:55 +0000
Subject: [issue43548] RecursionError depth exceptions break pdb's interactive
 tracing.
Message-ID: <1616121895.83.0.21835485789.issue43548@roundup.psfhosted.org>


New submission from behind thebrain <behindthebrain at zoho.eu>:

If pdb encounters most exception types, it handles them as would be expected. However, if pdb encounters a RecursionError: maximum recursion depth exceeded while calling a Python object, then it will continue to execute the code accurately, but the debugger itself will no longer interactively wait for user input, but instead, just speed through the rest of execution. The code below reproduces the error on python 3.7, 3.8, and 3.9.

```python3
import sys
import inspect

sys.setrecursionlimit(50)


def except_works() -> None:
    raise Exception


try:
    except_works()
except Exception as e:
    print("Exception was:", e)


def funcy(depth: int) -> None:
    print(f"Stack depth is:{len(inspect.stack())}")
    if depth == 0:
        return
    funcy(depth - 1)


try:
    funcy(60)
except Exception as e:
    print("Exception was:", e)

print("This executes without the debugger navigating to it.")
```

----------
components: Interpreter Core
files: runawaystepping.py
messages: 389051
nosy: behindthebrain
priority: normal
severity: normal
status: open
title: RecursionError depth exceptions break pdb's interactive tracing.
versions: Python 3.8
Added file: https://bugs.python.org/file49891/runawaystepping.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43548>
_______________________________________

From report at bugs.python.org  Thu Mar 18 22:46:43 2021
From: report at bugs.python.org (behind thebrain)
Date: Fri, 19 Mar 2021 02:46:43 +0000
Subject: [issue43548] RecursionError depth exceptions break pdb's interactive
 tracing.
In-Reply-To: <1616121895.83.0.21835485789.issue43548@roundup.psfhosted.org>
Message-ID: <1616122003.91.0.375363127655.issue43548@roundup.psfhosted.org>


Change by behind thebrain <behindthebrain at zoho.eu>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43548>
_______________________________________

From report at bugs.python.org  Fri Mar 19 00:22:52 2021
From: report at bugs.python.org (Xinmeng Xia)
Date: Fri, 19 Mar 2021 04:22:52 +0000
Subject: [issue43549] Outdated descriptions for configuring valgrind.
Message-ID: <1616127772.89.0.516830285286.issue43549@roundup.psfhosted.org>


New submission from Xinmeng Xia <xiaxm at smail.nju.edu.cn>:

At line 12-20, cpython/Misc/README.valgrind, the descriptions are out of date. File "Objects/obmalloc.c" does not contain Py_USING_MEMORY_DEBUGGER any more since Python 3.6.  The descriptions should be modified for Python 3.6-3.10


Attached line 12-20, cpython/Misc/README.valgrind: 
=================================================

If you don't want to read about the details of using Valgrind, there

are still two things you must do to suppress the warnings. First,

you must use a suppressions file. One is supplied in

Misc/valgrind-python.supp. Second, you must do one of the following:



* Uncomment Py_USING_MEMORY_DEBUGGER in Objects/obmalloc.c,

then rebuild Python

* Uncomment the lines in Misc/valgrind-python.supp that

suppress the warnings for PyObject_Free and PyObject_Realloc
=================================================

----------
assignee: docs at python
components: Documentation
messages: 389052
nosy: docs at python, xxm
priority: normal
severity: normal
status: open
title: Outdated descriptions for configuring valgrind.
type: behavior
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43549>
_______________________________________

From report at bugs.python.org  Fri Mar 19 00:35:04 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 19 Mar 2021 04:35:04 +0000
Subject: [issue27274] [ctypes] Allow from_pointer creation
In-Reply-To: <1465442258.95.0.0850234987407.issue27274@psf.upfronthosting.co.za>
Message-ID: <1616128504.85.0.391688327331.issue27274@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
versions: +Python 3.10 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27274>
_______________________________________

From report at bugs.python.org  Fri Mar 19 00:37:09 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 19 Mar 2021 04:37:09 +0000
Subject: [issue32745] ctypes string pointer fields should accept embedded null
 characters
In-Reply-To: <1517514890.15.0.467229070634.issue32745@psf.upfronthosting.co.za>
Message-ID: <1616128629.09.0.741398944356.issue32745@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
versions: +Python 3.10, Python 3.9 -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32745>
_______________________________________

From report at bugs.python.org  Fri Mar 19 00:58:54 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 19 Mar 2021 04:58:54 +0000
Subject: [issue41883] ctypes pointee goes out of scope,
 then pointer in struct dangles and crashes
In-Reply-To: <1601350806.96.0.0908350548542.issue41883@roundup.psfhosted.org>
Message-ID: <1616129934.26.0.981215276147.issue41883@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

The ctypes issue is bpo-12836, which has a suggested solution. This issue is a third-party problem introduced by a workaround, which needs to be addressed at the source, such as with helper functions and subclasses that close the loop.

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41883>
_______________________________________

From report at bugs.python.org  Fri Mar 19 01:09:30 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 19 Mar 2021 05:09:30 +0000
Subject: [issue29270] super call in ctypes subclass fails
In-Reply-To: <1484345422.14.0.967631121608.issue29270@psf.upfronthosting.co.za>
Message-ID: <1616130570.24.0.498196899306.issue29270@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
stage: patch review -> needs patch
title: super call in ctypes sub-class fails in 3.6 -> super call in ctypes subclass fails
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29270>
_______________________________________

From report at bugs.python.org  Fri Mar 19 01:13:32 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 19 Mar 2021 05:13:32 +0000
Subject: [issue21130] equivalent functools.partial instances should compare
 equal
In-Reply-To: <1396425472.15.0.80240218298.issue21130@psf.upfronthosting.co.za>
Message-ID: <1616130812.64.0.448852001045.issue21130@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21130>
_______________________________________

From report at bugs.python.org  Fri Mar 19 01:26:18 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 19 Mar 2021 05:26:18 +0000
Subject: [issue33030] GetLastError() may be overwritten by Py_END_ALLOW_THREADS
In-Reply-To: <1520526361.38.0.467229070634.issue33030@psf.upfronthosting.co.za>
Message-ID: <1616131578.12.0.720710086121.issue33030@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
versions: +Python 3.10, Python 3.9 -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33030>
_______________________________________

From report at bugs.python.org  Fri Mar 19 01:38:28 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 19 Mar 2021 05:38:28 +0000
Subject: [issue43175] filecmp is not working for UTF-8 BOM file.
In-Reply-To: <1612848997.29.0.320825258569.issue43175@roundup.psfhosted.org>
Message-ID: <1616132308.8.0.412999457309.issue43175@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

I'm closing this as not a bug. You showed that all of the criteria used in a non-shallow comparison are the same on your end, i.e. they're both regular files with the same reported size and the same contents. Something is going on, which is a mystery, but it's not a bug in os.stat() or filecmp.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43175>
_______________________________________

From report at bugs.python.org  Fri Mar 19 01:53:05 2021
From: report at bugs.python.org (Georgios Petrou)
Date: Fri, 19 Mar 2021 05:53:05 +0000
Subject: [issue43550] pip.exe is missing from the NuGet package
Message-ID: <1616133185.95.0.11826827312.issue43550@roundup.psfhosted.org>


New submission from Georgios Petrou <gipetrou at gmail.com>:

When downloading a package from https://www.nuget.org/packages/python the pip.exe is not included. As far as I understand, the recommended way to use pip from a script is to call it from subprocess. Would it be possible to include the exe in the package?

----------
components: Windows
messages: 389055
nosy: gipetrou, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: pip.exe is missing from the NuGet package
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43550>
_______________________________________

From report at bugs.python.org  Fri Mar 19 03:06:37 2021
From: report at bugs.python.org (junyixie)
Date: Fri, 19 Mar 2021 07:06:37 +0000
Subject: [issue43551] [Subinterpreters]: PyImport_Import use static silly_list
 under building Python with
 --with-experimental-isolated-subinterpreters share
 silly_list in multi subinterpreters cause crash.
Message-ID: <1616137596.99.0.963932745487.issue43551@roundup.psfhosted.org>


New submission from junyixie <xie.junyi at outlook.com>:

fix PyImport_Import use static silly_list under building Python with --with-experimental-isolated-subinterpreters share silly_list in multi subinterpreters  cause crash.

Under the sub interpreters parallel, PyObject_CallFunction clean stack, 
Py_DECREF(stack[i]), Py_DECREF silly_list is not thread safe. cause crash
```
PyObject *
PyImport_Import(PyObject *module_name)
{
    PyThreadState *tstate = _PyThreadState_GET();
    static PyObject *silly_list = NULL;
    ...
    /* Initialize constant string objects */
    if (silly_list == NULL) {
        import_str = PyUnicode_InternFromString("__import__");
        if (import_str == NULL)
            return NULL;
        builtins_str = PyUnicode_InternFromString("__builtins__");
        if (builtins_str == NULL)
            return NULL;
        silly_list = PyList_New(0);
        if (silly_list == NULL)
            return NULL;
    }
    ...
    /* Call the __import__ function with the proper argument list
       Always use absolute import here.
       Calling for side-effect of import. */
    r = PyObject_CallFunction(import, "OOOOi", module_name, globals,
                              globals, silly_list, 0, NULL);

```

----------
messages: 389056
nosy: JunyiXie, vstinner
priority: normal
severity: normal
status: open
title: [Subinterpreters]: PyImport_Import use static silly_list under building Python with --with-experimental-isolated-subinterpreters share silly_list in multi subinterpreters  cause crash.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43551>
_______________________________________

From report at bugs.python.org  Fri Mar 19 03:08:23 2021
From: report at bugs.python.org (junyixie)
Date: Fri, 19 Mar 2021 07:08:23 +0000
Subject: [issue43551] [Subinterpreters]: PyImport_Import use static silly_list
 under building Python with
 --with-experimental-isolated-subinterpreters share
 silly_list in multi subinterpreters cause crash.
In-Reply-To: <1616137596.99.0.963932745487.issue43551@roundup.psfhosted.org>
Message-ID: <1616137703.29.0.281023576384.issue43551@roundup.psfhosted.org>


Change by junyixie <xie.junyi at outlook.com>:


----------
keywords: +patch
pull_requests: +23691
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24929

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43551>
_______________________________________

From report at bugs.python.org  Fri Mar 19 05:17:13 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Mar 2021 09:17:13 +0000
Subject: [issue43552] Add locale.get_locale_encoding() and
 locale.get_current_locale_encoding()
Message-ID: <1616145433.55.0.350148222552.issue43552@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

I propose to add two new functions:

* locale.get_locale_encoding(): it's exactly the same than locale.getpreferredencoding(False).

* locale.get_current_locale_encoding(): always get the current locale encoding. Read the ANSI code page on Windows, or nl_langinfo(CODESET) on other platforms. Ignore the UTF-8 Mode. Don't always return "UTF-8" on macOS, Android, VxWorks.


Technically, locale.get_locale_encoding() would simply expose _locale.get_locale_encoding() that I added recently. It calls the new private _Py_GetLocaleEncoding() function (which has no argument).

By the way, Python requires nl_langinfo(CODESET) to be built. It's not a new requirement of Python 3.10, but I wanted to note that, I noticed it when I implemented _locale.get_locale_encoding() :-)


Python has a bad habit of lying to the user: locale.getpreferredencoding(False) is *NOT* the current locale encoding in multiple cases.

* locale.getpreferredencoding(False) always return "UTF-8" on macOS, Android and VxWorks
* locale.getpreferredencoding(False) always return "UTF-8" if the UTF-8 Mode is enabled
* otherwise, it returns the current locale encoding: ANSI code page on Windwos, or nl_langinfo(CODESET) on other platforms


Even if locale.getpreferredencoding(False) already exists, I propose to add locale.get_locale_encoding() because I dislike locale.getpreferredencoding() API. By default, this function sets temporarily LC_CTYPE to the user preferred locale. It can cause mojibake in other threads since setlocale(LC_CTYPE, "") affects all threads :-( Calling locale.getpreferredencoding(), rather than locale.getpreferredencoding(False), is not what most people expect. This API can be misused.

On the other side, locale.get_locale_encoding() does exactly what it says: only *get* the encoding, don't *set* temporarily a locale to something else.

By the way, the locale.localeconv() function can change temporarily LC_CTYPE locale to the LC_MONETARY locale which can cause other threads to use the wrong LC_CTYPE locale! But this is a different issue.

----------
components: Library (Lib)
messages: 389057
nosy: vstinner
priority: normal
severity: normal
status: open
title: Add  locale.get_locale_encoding() and locale.get_current_locale_encoding()
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43552>
_______________________________________

From report at bugs.python.org  Fri Mar 19 05:29:35 2021
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 19 Mar 2021 09:29:35 +0000
Subject: [issue43466] ssl/hashlib: Add configure option to set or auto-detect
 rpath to OpenSSL libs
In-Reply-To: <1615418043.46.0.229114131093.issue43466@roundup.psfhosted.org>
Message-ID: <1616146175.69.0.54983153345.issue43466@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset 32eba61ea431c76f15a910c0a4eded7f5f8b9b34 by Christian Heimes in branch 'master':
bpo-43466: Add --with-openssl-rpath configure option (GH-24820)
https://github.com/python/cpython/commit/32eba61ea431c76f15a910c0a4eded7f5f8b9b34


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43466>
_______________________________________

From report at bugs.python.org  Fri Mar 19 05:30:12 2021
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 19 Mar 2021 09:30:12 +0000
Subject: [issue43466] ssl/hashlib: Add configure option to set or auto-detect
 rpath to OpenSSL libs
In-Reply-To: <1615418043.46.0.229114131093.issue43466@roundup.psfhosted.org>
Message-ID: <1616146212.37.0.544459705337.issue43466@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

I'm leaving the ticket open as a reminder for me to update whatsnew.

----------
components: +Documentation

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43466>
_______________________________________

From report at bugs.python.org  Fri Mar 19 05:40:27 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Fri, 19 Mar 2021 09:40:27 +0000
Subject: [issue43553] [sqlite3] Improve test coverage
Message-ID: <1616146827.28.0.306861710818.issue43553@roundup.psfhosted.org>


New submission from Erlend Egeberg Aasland <erlend.aasland at innova.no>:

Attached patch improves the code coverage of the sqlite3 module. I've used llvm-cov for coverage measurement.

I'll create a PR for this, if you're fine with this, Berker/Serhiy.

Filename                      Regions    Missed Regions     Cover   Functions  Missed Functions  Executed       Lines      Missed Lines     Cover
-------------------------------------------------------------------------------------------------------------------------------------------------
prepare_protocol.c                 10                 7    30.00%           3                 2    33.33%          16                11    31.25%
util.c                             65                21    67.69%           3                 0   100.00%          78                26    66.67%
module.c                          306                59    80.72%          10                 1    90.00%         236                45    80.93%
row.c                             173                16    90.75%          11                 0   100.00%         146                13    91.10%
microprotocols.c                   81                 9    88.89%           3                 0   100.00%          98                15    84.69%
connection.c                     1113               155    86.07%          43                 0   100.00%        1366               179    86.90%
cache.c                           136                38    72.06%           7                 1    85.71%         227                59    74.01%
cursor.c                          758               116    84.70%          19                 0   100.00%         794               122    84.63%
statement.c                       340                22    93.53%          10                 0   100.00%         392                29    92.60%
-------------------------------------------------------------------------------------------------------------------------------------------------
TOTAL                            2982               443    85.14%         109                 4    96.33%        3353               499    85.12%

----------
components: Library (Lib)
files: improve-sqlite3-coverage.diff
keywords: patch
messages: 389060
nosy: berker.peksag, erlendaasland, serhiy.storchaka
priority: normal
severity: normal
status: open
title: [sqlite3] Improve test coverage
type: enhancement
versions: Python 3.10
Added file: https://bugs.python.org/file49892/improve-sqlite3-coverage.diff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43553>
_______________________________________

From report at bugs.python.org  Fri Mar 19 05:45:02 2021
From: report at bugs.python.org (Emil Styrke)
Date: Fri, 19 Mar 2021 09:45:02 +0000
Subject: [issue43554] email: encoded headers lose their quoting when refolded
Message-ID: <1616147102.5.0.601004900737.issue43554@roundup.psfhosted.org>


New submission from Emil Styrke <emil.styrke at gmail.com>:

When a header with an encoded (QP or Base64) display_name is refolded, it may lose (some of) its encoding.  If it then contains illegal "atext" tokens, an invalid header will result.

For example, `From: =?utf-8?Q?a=2C=20123456789012345678901234567890123456?= <abc at example.com>` will become `From: a, 123456789012345678901234567890123456 <abc at example.com>`  This contains a comma character which needs to be quoted: correct rendering would be `From: "a, 123456789012345678901234567890123456" <abc at example.com>`. Note that this example isn't even folded to multiple lines, since the decoded text is short enough to fit in one line.

This can be triggered by `BytesParser(policy=policy.default).parsebytes("From: =?utf-8?Q?a=2C=20123456789012345678901234567890123456?= <abc at example.com>").as_bytes()`, but the offending code seems to be in or below `email.policy.EmailPolicy.fold`.  See attached file for examples with and without folding.

----------
components: Library (Lib)
files: test_folding_bug.py
messages: 389061
nosy: Emil.Styrke
priority: normal
severity: normal
status: open
title: email: encoded headers lose their quoting when refolded
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file49893/test_folding_bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43554>
_______________________________________

From mal at egenix.com  Fri Mar 19 05:54:40 2021
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri, 19 Mar 2021 10:54:40 +0100
Subject: [issue43552] Add locale.get_locale_encoding() and
 locale.get_current_locale_encoding()
In-Reply-To: <1616145433.55.0.350148222552.issue43552@roundup.psfhosted.org>
References: <1616145433.55.0.350148222552.issue43552@roundup.psfhosted.org>
Message-ID: <e66bcdba-3494-ad8c-8170-11144644e34f@egenix.com>

On 19.03.2021 10:17, STINNER Victor wrote:
> 
> New submission from STINNER Victor <vstinner at python.org>:
> 
> I propose to add two new functions:
> 
> * locale.get_locale_encoding(): it's exactly the same than locale.getpreferredencoding(False).
> 
> * locale.get_current_locale_encoding(): always get the current locale encoding. Read the ANSI code page on Windows, or nl_langinfo(CODESET) on other platforms. Ignore the UTF-8 Mode. Don't always return "UTF-8" on macOS, Android, VxWorks.

I'm not sure whether this would improve the situation much.

The problem is that the locale module is meant to expose the lib C
locale settings, but many of the recent additions actually do something
completely different: they look into the process and user environment
and try to determine external settings, which are not reflected in
the lib C locale settings.

I had added locale.getdefaultlocale() to give applications a chance
to determine the locale setting defined by the process environment
*without* calling setlocale(LC_ALL, '') and causing problems
in other threads. I used the X11 database for locale encodings,
which was the closest you could get to in terms of a standard for
encodings at the time (around 2000).

Part of the return value is the encoding, which would be set.

Martin later added locale.getpreferredencoding(), which tries to
determine the encoding in a different way new way, based on
nl_langset(CODEINFO). As you mentioned, this intention was broken
on several platforms by forcing UTF-8 as output. And in many cases,
the API had to call setlocale() as well, causing the thread problems.

However, the problem with nl_langset(CODEINFO) is the same as
with setlocale(): it returns the current state of the lib C
settings, which may well point to the 'C' locale. Not the ones
the user has configured in the OS environment. So while you get
an encoding defined by lib C for the current locale settings
(without guessing it as with locale.getdefaultlocale()), you
still don't get what the user really wants to use.

Unfortunately, lib C does not provide a way to query the locale
database without changing the locale settings at the same time.
This is the main issue we're facing.

Now, the correct way in all this would be to just call
setlocale(LC_ALL, '') at the start of the application and
not try to apply all the magic to get around this. But this
has to be done by the application and not Python (which may
well be embedded into some other application).

I'd suggest to add a single new API:

locale.getencoding()

which interfaces to nl_langinfo(CODESET) or the Windows code
page and does not try to do any magic, ie. does *not* call
setlocale(). It needs to return what the lib C currently
knows and uses as encoding.

locale.getpreferredencoding() should then be deprecated.

It does not make sense to pretend to query information which is
not really directly available from the lib C locale system.

And the documentation should point out that applications should
call setlocale(LC_ALL, '') when they start up, if they want to
get the lib C locale, and thus Python locale module, setup to
work based on what the user really wants -- instead of just
guessing at this.

PS: The locale module normally does not use underscores in
function names, so it's not a good idea to add more.

-- 
Marc-Andre Lemburg
eGenix.com


From report at bugs.python.org  Fri Mar 19 05:54:45 2021
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 19 Mar 2021 09:54:45 +0000
Subject: [issue43552] Add locale.get_locale_encoding() and
 locale.get_current_locale_encoding()
In-Reply-To: <1616145433.55.0.350148222552.issue43552@roundup.psfhosted.org>
Message-ID: <e66bcdba-3494-ad8c-8170-11144644e34f@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 19.03.2021 10:17, STINNER Victor wrote:
> 
> New submission from STINNER Victor <vstinner at python.org>:
> 
> I propose to add two new functions:
> 
> * locale.get_locale_encoding(): it's exactly the same than locale.getpreferredencoding(False).
> 
> * locale.get_current_locale_encoding(): always get the current locale encoding. Read the ANSI code page on Windows, or nl_langinfo(CODESET) on other platforms. Ignore the UTF-8 Mode. Don't always return "UTF-8" on macOS, Android, VxWorks.

I'm not sure whether this would improve the situation much.

The problem is that the locale module is meant to expose the lib C
locale settings, but many of the recent additions actually do something
completely different: they look into the process and user environment
and try to determine external settings, which are not reflected in
the lib C locale settings.

I had added locale.getdefaultlocale() to give applications a chance
to determine the locale setting defined by the process environment
*without* calling setlocale(LC_ALL, '') and causing problems
in other threads. I used the X11 database for locale encodings,
which was the closest you could get to in terms of a standard for
encodings at the time (around 2000).

Part of the return value is the encoding, which would be set.

Martin later added locale.getpreferredencoding(), which tries to
determine the encoding in a different way new way, based on
nl_langset(CODEINFO). As you mentioned, this intention was broken
on several platforms by forcing UTF-8 as output. And in many cases,
the API had to call setlocale() as well, causing the thread problems.

However, the problem with nl_langset(CODEINFO) is the same as
with setlocale(): it returns the current state of the lib C
settings, which may well point to the 'C' locale. Not the ones
the user has configured in the OS environment. So while you get
an encoding defined by lib C for the current locale settings
(without guessing it as with locale.getdefaultlocale()), you
still don't get what the user really wants to use.

Unfortunately, lib C does not provide a way to query the locale
database without changing the locale settings at the same time.
This is the main issue we're facing.

Now, the correct way in all this would be to just call
setlocale(LC_ALL, '') at the start of the application and
not try to apply all the magic to get around this. But this
has to be done by the application and not Python (which may
well be embedded into some other application).

I'd suggest to add a single new API:

locale.getencoding()

which interfaces to nl_langinfo(CODESET) or the Windows code
page and does not try to do any magic, ie. does *not* call
setlocale(). It needs to return what the lib C currently
knows and uses as encoding.

locale.getpreferredencoding() should then be deprecated.

It does not make sense to pretend to query information which is
not really directly available from the lib C locale system.

And the documentation should point out that applications should
call setlocale(LC_ALL, '') when they start up, if they want to
get the lib C locale, and thus Python locale module, setup to
work based on what the user really wants -- instead of just
guessing at this.

PS: The locale module normally does not use underscores in
function names, so it's not a good idea to add more.

----------
nosy: +lemburg
title: Add  locale.get_locale_encoding() and locale.get_current_locale_encoding() -> Add locale.get_locale_encoding() and locale.get_current_locale_encoding()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43552>
_______________________________________

From report at bugs.python.org  Fri Mar 19 06:15:58 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Mar 2021 10:15:58 +0000
Subject: [issue43552] Add locale.get_locale_encoding() and
 locale.get_current_locale_encoding()
In-Reply-To: <1616145433.55.0.350148222552.issue43552@roundup.psfhosted.org>
Message-ID: <1616148958.36.0.497333536129.issue43552@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +23693
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24931

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43552>
_______________________________________

From report at bugs.python.org  Fri Mar 19 06:17:35 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Mar 2021 10:17:35 +0000
Subject: [issue43552] Add locale.get_locale_encoding() and
 locale.get_current_locale_encoding()
In-Reply-To: <1616145433.55.0.350148222552.issue43552@roundup.psfhosted.org>
Message-ID: <1616149055.42.0.727843855431.issue43552@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I created this issue while reviewing the implementation of the PEP 597: PR 19481.

Copy of my comments on the PR related to this issue.


_locale.get_locale_encoding() calls _Py_GetLocaleEncoding() which returns UTF-8 if the Python UTF-8 Mode is enabled.

Maybe the function could have a flag: please don't lie to me and return the current locale encoding ;-)

Or we could add a function to get the *current* locale encoding: **locale.get_current_locale_encoding()**.

This one would ignore the UTF-8 Mode and call nl_langinfo(CODESET). There are APIs to use the *current* locale encoding: PyUnicode_EncodeLocale/PyUnicode_DecodeLocale and _Py_EncodeLocaleEx/_Py_DecodeLocaleEx with current_locale=1. You can see which functions use it:

* decode tm_zone field of localtime_r() and gmtime()
* decode tzname[0] and tzname[1] strings
* decode setlocale() result
* decode some localeconv() fields (this function requires to switch to different locale encoding, it's bad!)
* decode nl_langinfo() result
* decode gettext(), dgettext(), dcgettext(), textdomain(), bindtextdomain(), bind_textdomain_codeset() result
* decode strerror() and dlerror() result
* encode/decode in the readline module
* encode format string for strftime() in time.strftime() (only used on Windows, Unix provides wcsftime) and then decode strftime() result


> encoding="locale" : Uses locale encoding regardless UTF-8 mode.

Currently, open(encoding=None) doesn't work like that. For example, on macOS, Android and VxWorks, it always use UTF-8. And if the UTF-8 Mode is used, UTF-8 is used.

In the PEP 597, I read the encoding="locale" is the same than encoding=None but don't emit an EncodingWarning. Where the PEP 597 changes the chosen encoding for encoding=None case? The PEP says "locale encoding" without specifying exactly what it is. In Python, it means different things depending on the context. There is subtle difference the **current** locale encoding and "the locale encoding". I agree that it needs some clarification :-)

While we discuss encodings, I never understood why open() gets the current locale encoding from nl_langinfo(CODESET), encoding which can change at runtime while Python is running. For example, if thread A calls open(filename, encoding=None), thread B calls locale.localeconv(), and the LC_MONETARY locale uses a different encoding than the LC_CTYPE locale, thread A can get the LC_MONETARY encoding because of how locale.localeconv() is currently implemented: it changes temporarily LC_CTYPE to LC_MONETARY to decode the monetary fields of localeconv() result.

I would prefer that Python uses the same encoding for the whole lifetime of the process, since the beginning until the end. The Python filesystem encoding is a good choice for that. It's the same than locale.getpreferredencoding(False) (currently used by open() and friends), but becomes different if the LC_CTYPE is changed (temporarily or permanently).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43552>
_______________________________________

From report at bugs.python.org  Fri Mar 19 06:22:54 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Mar 2021 10:22:54 +0000
Subject: [issue43552] Add locale.get_locale_encoding() and
 locale.get_current_locale_encoding()
In-Reply-To: <1616145433.55.0.350148222552.issue43552@roundup.psfhosted.org>
Message-ID: <1616149374.87.0.896687871924.issue43552@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I created PR 24931 to add locale.get_current_locale_encoding(). I tried to clarified the differences between the "current locale encoding" and the "locale encoding".

Maybe we should rename the "locale encoding" to the "Python locale encoding", since it's not what most Unix developers would expect. What do you think?

While most locale function have no underscore in their name, it seems like the current trend is to allow underscores in names for *new* functions. For example, the sys module has without underscores:

* sys.getallocatedblocks()
* sys.getdefaultencoding()
* sys.getfilesystemencodeerrors
* ...

But it got new functions with underscores:

* sys.set_asyncgen_hooks()
* sys.set_coroutine_origin_tracking_depth()

... and there are some old functions with underscores:

* sys.exc_info()
* sys.call_tracing()
* sys._clear_type_cache()
* sys._current_frames()

In the locale module, there is one existing function with an undercore:

* locale.format_string()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43552>
_______________________________________

From report at bugs.python.org  Fri Mar 19 06:31:12 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Mar 2021 10:31:12 +0000
Subject: [issue43552] Add locale.get_locale_encoding() and
 locale.get_current_locale_encoding()
In-Reply-To: <1616145433.55.0.350148222552.issue43552@roundup.psfhosted.org>
Message-ID: <1616149872.12.0.48852102913.issue43552@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Now, the correct way in all this would be to just call setlocale(LC_ALL, '') at the start of the application

Python now does that during its initialization on all platforms. So getpreferredencoding(False) is what its documentation says: the user preferred encoding, the LC_CTYPE locale encoding.

On Python 3.7, _Py_SetLocaleFromEnv(LC_CTYPE) was called in _Py_InitializeCore() on Unix, but not on Windows.

Since Python 3.8, _PyPreConfig_Write() calls _Py_SetLocaleFromEnv(LC_CTYPE) on all platforms including Windows. See bpo-34485 and my article for more details ("C locale on Windows" section):
https://vstinner.github.io/python3-locales-encodings.html

_Py_SetLocaleFromEnv(LC_CTYPE) calls setlocale(LC_CTYPE, ""), but has more complex code on Android.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43552>
_______________________________________

From report at bugs.python.org  Fri Mar 19 06:36:11 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Mar 2021 10:36:11 +0000
Subject: [issue43552] Add locale.get_locale_encoding() and
 locale.get_current_locale_encoding()
In-Reply-To: <1616145433.55.0.350148222552.issue43552@roundup.psfhosted.org>
Message-ID: <1616150171.52.0.85428527583.issue43552@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> locale.getencoding()
>
> which interfaces to nl_langinfo(CODESET) or the Windows code
> page and does not try to do any magic, ie. does *not* call
> setlocale(). It needs to return what the lib C currently
> knows and uses as encoding.

This is locale.get_current_locale_encoding(). I would like to put "current" in the name, because there is a lot of confusion between get_current_locale_encoding() encoding and locale.getpreferredencoding(False) encoding. In locale.getpreferredencoding(False), Python ignores the locale in some cases which is counter intuitive.

I propose to add new functions to reduce confusion and better document the subtle differences between the different "locale encodings".

That's also why I propose to rename the "locale encoding" to the "Python locale encoding" in the documentation: clarify the Python ignores the locale sometimes.

The PEP 538 (coerce the C locale) and PEP 540 (Python UTF-8 Mode) introduced confusion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43552>
_______________________________________

From report at bugs.python.org  Fri Mar 19 06:43:15 2021
From: report at bugs.python.org (Anentropic)
Date: Fri, 19 Mar 2021 10:43:15 +0000
Subject: [issue43546] "Impossible" KeyError from importlib._bootstrap acquire
 line 110
In-Reply-To: <1616093906.25.0.990565288145.issue43546@roundup.psfhosted.org>
Message-ID: <1616150595.53.0.594401173942.issue43546@roundup.psfhosted.org>


Anentropic <ego at anentropic.com> added the comment:

Thank you for your explanation.

I am baffled why this has never happened to us before, and why a specific number of test cases should trigger it (comment one out or add an extra one, it goes away).

I've pasted our full stack trace below. It always fails in this place.

My original thought when getting this error was to check for code that executes at import time. The module being imported when it breaks seems totally innocuous though:
https://github.com/django/django/blob/2.2.19/django/db/migrations/optimizer.py

There are two instances of:

File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
  File "/root/.pyenv/versions/3.9.2/lib/python3.9/site-packages/ddtrace/internal/import_hooks.py", line 215, in wrapped_find_and_load_unlocked
    return exec_and_call_hooks(module_name, wrapped, args, kwargs)

...in the traceback, so https://github.com/DataDog/dd-trace-py starts to look suspicious.


Traceback (most recent call last):
  File "/work/manage.py", line 26, in <module>
    execute_from_command_line(sys.argv)
  File "/root/.pyenv/versions/3.9.2/lib/python3.9/site-packages/django/core/management/__init__.py", line 381, in execute_from_command_line
    utility.execute()
  File "/root/.pyenv/versions/3.9.2/lib/python3.9/site-packages/django/core/management/__init__.py", line 375, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/root/.pyenv/versions/3.9.2/lib/python3.9/site-packages/django/core/management/commands/test.py", line 23, in run_from_argv
    super().run_from_argv(argv)
  File "/root/.pyenv/versions/3.9.2/lib/python3.9/site-packages/django/core/management/base.py", line 323, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/root/.pyenv/versions/3.9.2/lib/python3.9/site-packages/django/core/management/base.py", line 364, in execute
    output = self.handle(*args, **options)
  File "/root/.pyenv/versions/3.9.2/lib/python3.9/site-packages/django/core/management/commands/test.py", line 53, in handle
    failures = test_runner.run_tests(test_labels)
  File "/root/.pyenv/versions/3.9.2/lib/python3.9/site-packages/django_nose/runner.py", line 308, in run_tests
    result = self.run_suite(nose_argv)
  File "/root/.pyenv/versions/3.9.2/lib/python3.9/site-packages/django_nose/runner.py", line 244, in run_suite
    nose.core.TestProgram(argv=nose_argv, exit=False,
  File "/root/.pyenv/versions/3.9.2/lib/python3.9/site-packages/nose/core.py", line 118, in __init__
    unittest.TestProgram.__init__(
  File "/root/.pyenv/versions/3.9.2/lib/python3.9/unittest/main.py", line 101, in __init__
    self.runTests()
  File "/root/.pyenv/versions/3.9.2/lib/python3.9/site-packages/nose/core.py", line 207, in runTests
    result = self.testRunner.run(self.test)
  File "/root/.pyenv/versions/3.9.2/lib/python3.9/site-packages/nose/core.py", line 50, in run
    wrapper = self.config.plugins.prepareTest(test)
  File "/root/.pyenv/versions/3.9.2/lib/python3.9/site-packages/nose/plugins/manager.py", line 99, in __call__
    return self.call(*arg, **kw)
  File "/root/.pyenv/versions/3.9.2/lib/python3.9/site-packages/nose/plugins/manager.py", line 167, in simple
    result = meth(*arg, **kw)
  File "/root/.pyenv/versions/3.9.2/lib/python3.9/site-packages/django_nose/plugin.py", line 82, in prepareTest
    self.old_names = self.runner.setup_databases()
  File "/root/.pyenv/versions/3.9.2/lib/python3.9/site-packages/django_nose/runner.py", line 495, in setup_databases
    return super(NoseTestSuiteRunner, self).setup_databases()
  File "/root/.pyenv/versions/3.9.2/lib/python3.9/site-packages/django/test/runner.py", line 552, in setup_databases
    return _setup_databases(
  File "/root/.pyenv/versions/3.9.2/lib/python3.9/site-packages/django/test/utils.py", line 170, in setup_databases
    connection.creation.create_test_db(
  File "/root/.pyenv/versions/3.9.2/lib/python3.9/site-packages/django/db/backends/base/creation.py", line 67, in create_test_db
    call_command(
  File "/root/.pyenv/versions/3.9.2/lib/python3.9/site-packages/django/core/management/__init__.py", line 110, in call_command
    command = load_command_class(app_name, command_name)
  File "/root/.pyenv/versions/3.9.2/lib/python3.9/site-packages/django/core/management/__init__.py", line 36, in load_command_class
    module = import_module('%s.management.commands.%s' % (app_name, name))
  File "/root/.pyenv/versions/3.9.2/lib/python3.9/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1030, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
  File "/root/.pyenv/versions/3.9.2/lib/python3.9/site-packages/ddtrace/internal/import_hooks.py", line 215, in wrapped_find_and_load_unlocked
    return exec_and_call_hooks(module_name, wrapped, args, kwargs)
  File "/root/.pyenv/versions/3.9.2/lib/python3.9/site-packages/ddtrace/internal/import_hooks.py", line 171, in exec_and_call_hooks
    return wrapped(*args, **kwargs)
  File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 680, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 790, in exec_module
  File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed
  File "/root/.pyenv/versions/3.9.2/lib/python3.9/site-packages/django/core/management/commands/migrate.py", line 14, in <module>
    from django.db.migrations.autodetector import MigrationAutodetector
  File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
  File "/root/.pyenv/versions/3.9.2/lib/python3.9/site-packages/ddtrace/internal/import_hooks.py", line 215, in wrapped_find_and_load_unlocked
    return exec_and_call_hooks(module_name, wrapped, args, kwargs)
  File "/root/.pyenv/versions/3.9.2/lib/python3.9/site-packages/ddtrace/internal/import_hooks.py", line 171, in exec_and_call_hooks
    return wrapped(*args, **kwargs)
  File "/root/.pyenv/versions/3.9.2/lib/python3.9/site-packages/django/db/migrations/autodetector.py", line 10, in <module>
    from django.db.migrations.optimizer import MigrationOptimizer
  File "<frozen importlib._bootstrap>", line 1004, in _find_and_load
  File "<frozen importlib._bootstrap>", line 158, in __enter__
  File "<frozen importlib._bootstrap>", line 110, in acquire
KeyError: 140581625389696

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43546>
_______________________________________

From mal at egenix.com  Fri Mar 19 06:59:39 2021
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri, 19 Mar 2021 11:59:39 +0100
Subject: [issue43552] Add locale.get_locale_encoding() and
 locale.get_current_locale_encoding()
In-Reply-To: <1616150171.52.0.85428527583.issue43552@roundup.psfhosted.org>
References: <1616150171.52.0.85428527583.issue43552@roundup.psfhosted.org>
Message-ID: <1c00fb41-f7fb-0442-fb64-2cae642a0ddf@egenix.com>

On 19.03.2021 11:36, STINNER Victor wrote:
> 
> STINNER Victor <vstinner at python.org> added the comment:
> 
>> locale.getencoding()
>>
>> which interfaces to nl_langinfo(CODESET) or the Windows code
>> page and does not try to do any magic, ie. does *not* call
>> setlocale(). It needs to return what the lib C currently
>> knows and uses as encoding.
> 
> This is locale.get_current_locale_encoding(). I would like to put "current" in the name, because there is a lot of confusion between get_current_locale_encoding() encoding and locale.getpreferredencoding(False) encoding. In locale.getpreferredencoding(False), Python ignores the locale in some cases which is counter intuitive.

These attempts have resulted much of the confusion around the locale
module. It's better not to create more of it.

- "locale" in the name is unnecessary, since this is the locale module.

- If you add "current", people will rightly ask: then what do all the
other APIs in the locale module return ? Of course, they all return
the current state of settings :-) So this is unnecessary as well.

locale.getencoding() works in the same way as locale.getlocale().
It interfaces to the lib C and returns the current encoding setting
as known by the lib C. It's just a more intuitive name than
locale.nl_langinfo(CODESET) and works on Windows as well.

And, again, locale.getpreferredencoding() should be deprecated.
The API has been misused in too many ways and is completely broken
by now. It was a good idea at the time, when Martin added it,
even though I never liked the name.

-- 
Marc-Andre Lemburg
eGenix.com


From report at bugs.python.org  Fri Mar 19 06:59:43 2021
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 19 Mar 2021 10:59:43 +0000
Subject: [issue43552] Add locale.get_locale_encoding() and
 locale.get_current_locale_encoding()
In-Reply-To: <1616150171.52.0.85428527583.issue43552@roundup.psfhosted.org>
Message-ID: <1c00fb41-f7fb-0442-fb64-2cae642a0ddf@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 19.03.2021 11:36, STINNER Victor wrote:
> 
> STINNER Victor <vstinner at python.org> added the comment:
> 
>> locale.getencoding()
>>
>> which interfaces to nl_langinfo(CODESET) or the Windows code
>> page and does not try to do any magic, ie. does *not* call
>> setlocale(). It needs to return what the lib C currently
>> knows and uses as encoding.
> 
> This is locale.get_current_locale_encoding(). I would like to put "current" in the name, because there is a lot of confusion between get_current_locale_encoding() encoding and locale.getpreferredencoding(False) encoding. In locale.getpreferredencoding(False), Python ignores the locale in some cases which is counter intuitive.

These attempts have resulted much of the confusion around the locale
module. It's better not to create more of it.

- "locale" in the name is unnecessary, since this is the locale module.

- If you add "current", people will rightly ask: then what do all the
other APIs in the locale module return ? Of course, they all return
the current state of settings :-) So this is unnecessary as well.

locale.getencoding() works in the same way as locale.getlocale().
It interfaces to the lib C and returns the current encoding setting
as known by the lib C. It's just a more intuitive name than
locale.nl_langinfo(CODESET) and works on Windows as well.

And, again, locale.getpreferredencoding() should be deprecated.
The API has been misused in too many ways and is completely broken
by now. It was a good idea at the time, when Martin added it,
even though I never liked the name.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43552>
_______________________________________

From report at bugs.python.org  Fri Mar 19 07:05:29 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Mar 2021 11:05:29 +0000
Subject: [issue43552] Add locale.get_locale_encoding() and
 locale.get_current_locale_encoding()
In-Reply-To: <1616145433.55.0.350148222552.issue43552@roundup.psfhosted.org>
Message-ID: <1616151929.89.0.714213045925.issue43552@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Attached encodings.py lists the different "locale encodings" used by Python. Example:
---
$ LANG=fr_FR ./python -X utf8 encodings.py fr_FR at euro
Set LC_CTYPE to 'fr_FR at euro'

LC_ALL env var: ''
LC_CTYPE env var: ''
LANG env var: 'fr_FR'
LC_CTYPE locale: 'fr_FR at euro'
Coerce C locale: 0
Python UTF-8 Mode: 1

(1) Python FS encoding
sys.getfilesystemencoding(): 'utf-8'

(2) Python locale encoding
_locale._get_locale_encoding(): 'UTF-8'
locale.getpreferredencoding(False): 'UTF-8'

(3) Current locale encoding
locale.get_current_locale_encoding(): 'ISO-8859-15'

(4) And more encodings for more fun!
locale.getdefaultlocale()[1]: 'ISO8859-1'
locale.getpreferredencoding(True): 'UTF-8'
---

Python starts with LC_CTYPE locale set to fr_FR (ISO8859-1), then the script sets the LC_CTYPE locale to fr_FR at euro (ISO-8859-15). The Python UTF-8 Mode is enabled explicitly. We get a funny combination of not less than 3 encodings!

* UTF-8
* ISO-8859-1
* ISO-8859-15

Which one is the correct one? Wel... It depends :-)

(1) The Python filesystem encoding is used to call almost all operating system functions: encode to the OS and decode from the OS. Filenames, environment variables, command line options, etc.

(2) The "Python" locale encoding is used by open() when no encoding is specific.

(3) The current locale encoding is used for a limited amount of functions that I listed in msg389063. Most users should not use it.

(4) locale.getpreferredencoding(True) is a weird beast. It is Python locale encoding until setlocale(LC_CTYPE, locale) is called for the first time. But it can be same if the Python UTF-8 Mode is enabled. I'm not sure in which category we should put this function :-(

(4 bis) locale.getdefaultlocale()[1] is the only function returning the ISO-8859-1 encoding. This encoding is not used by any function. I'm not sure of the purpose of this function. It sounds confusing.


I suggest to deprecate locale.getpreferredencoding(True).

I'm not sure what to do with locale.getdefaultlocale(). Should we deprecate it? I never used this function. How is it used? For which purpose?

I undertand that in 2000, locale.getdefaultlocale() was interesting to avoid calling setlocale(LC_CTYPE, ""). But Python 3 calls setlocale(LC_CTYPE, "") by default at startup since the early versions, and it's now called on all platforms since Python 3.8. Moreover, its internal database seems to be outdated and is painful to maintain (especially if we consider all platforms supported by Python, not only Linux, there are many issues on macOS).

----------
Added file: https://bugs.python.org/file49894/encodings.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43552>
_______________________________________

From report at bugs.python.org  Fri Mar 19 07:11:34 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Mar 2021 11:11:34 +0000
Subject: [issue43552] Add locale.get_locale_encoding() and
 locale.get_current_locale_encoding()
In-Reply-To: <1616145433.55.0.350148222552.issue43552@roundup.psfhosted.org>
Message-ID: <1616152294.5.0.168060102826.issue43552@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Martin later added locale.getpreferredencoding(), which tries to
> determine the encoding in a different way new way, based on
> nl_langset(CODEINFO). As you mentioned, this intention was broken
> on several platforms by forcing UTF-8 as output.

When I designed and implemented the PEP 540 (Python UTF-8 Mode), I tried to leave getpreferredencoding() unchanged. The problem was that I quickly got mojibake because too many functions call getpreferredencoding(False):

* open() and _pyio.open() -- in Python 3.10, open() now calls the C _Py_GetLocaleEncoding() function to fix issues during Python shutdown, it also avoids issues at startup.
* Many gettext functions
* cgi to decode the query string from QUERY_STRING env var or sys.argv[1]}
* xml.etree.ElementTree.write(encoding="unicode") is some cases

The Python UTF-8 Mode ignores the locale *on purpose*. But I agree that it's surprising and can lead to confusion. That's what I'm trying to fix here :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43552>
_______________________________________

From report at bugs.python.org  Fri Mar 19 07:18:52 2021
From: report at bugs.python.org (Andre Roberge)
Date: Fri, 19 Mar 2021 11:18:52 +0000
Subject: [issue43555] Location of SyntaxError with new parser missing (after
 continuation character)
Message-ID: <1616152732.25.0.508578313833.issue43555@roundup.psfhosted.org>


New submission from Andre Roberge <andre.roberge at gmail.com>:

Normally, for SyntaxErrors, the location of the error is indicated by a ^. There is at least one case where the location is missing for 3.9 and 3.10.0a6 where it was shown before. Using the old parser for 3.9, or with previous versions of Python, the location is shown.

Python 3.10.0a6 ... on win32
>>> a = 3 \ 4
  File "<stdin>", line 1
SyntaxError: unexpected character after line continuation character
>>>


Python 3.9.0 ... on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> a = 3 \ 4
  File "<stdin>", line 1
SyntaxError: unexpected character after line continuation character
>>>

Using the old parser with Python 3.9, the location of the error is shown *after* the unexpected character.

> python -X oldparser
Python 3.9.0 ... on win32
>>> a = 3 \ 4
  File "<stdin>", line 1
    a = 3 \ 4
             ^
SyntaxError: unexpected character after line continuation character
>>>

Using Python 3.8 (and 3.7, 3.6), the location is pointing at the unexpected character.


Python 3.8.4 ... on win32
>>> a = 3 \ 4
  File "<stdin>", line 1
    a = 3 \ 4
            ^
SyntaxError: unexpected character after line continuation character
>>>

----------
components: Interpreter Core
messages: 389071
nosy: aroberge
priority: normal
severity: normal
status: open
title: Location of SyntaxError with new parser missing (after continuation character)
type: behavior
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43555>
_______________________________________

From report at bugs.python.org  Fri Mar 19 07:26:39 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Mar 2021 11:26:39 +0000
Subject: [issue43552] Add locale.get_locale_encoding() and
 locale.get_current_locale_encoding()
In-Reply-To: <1616145433.55.0.350148222552.issue43552@roundup.psfhosted.org>
Message-ID: <1616153199.3.0.00892314562765.issue43552@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Recently, I spent some days to document properly encodings used by Python.

Python filesystem encoding:
https://docs.python.org/dev/c-api/init_config.html#c.PyConfig.filesystem_encoding

Python filesystem errors:
https://docs.python.org/dev/c-api/init_config.html#c.PyConfig.filesystem_errors

stdio encoding and errors:
https://docs.python.org/dev/c-api/init_config.html#c.PyConfig.stdio_encoding

Glossary: "Locale encoding"
https://docs.python.org/dev/glossary.html#term-locale-encoding

Glossary: "filesystem encoding and error handler"
https://docs.python.org/dev/glossary.html#term-filesystem-encoding-and-error-handler

Python UTF-8 Mode:
https://docs.python.org/dev/library/os.html#utf8-mode

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43552>
_______________________________________

From report at bugs.python.org  Fri Mar 19 07:28:12 2021
From: report at bugs.python.org (Eric Frederich)
Date: Fri, 19 Mar 2021 11:28:12 +0000
Subject: [issue43529] pathlib.Path.glob causes OSError encountering symlinks
 to long filenames
In-Reply-To: <1615994616.04.0.762651186772.issue43529@roundup.psfhosted.org>
Message-ID: <1616153292.08.0.585816895493.issue43529@roundup.psfhosted.org>


Eric Frederich <eric.frederich at gmail.com> added the comment:

I'm happy to create a pull request but would need some help.

Looking at that routine it has changed over time and I cannot simply create a single patch against 3.6 and have it merge cleanly into newer versions.

I'd need help explaining the process

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43529>
_______________________________________

From report at bugs.python.org  Fri Mar 19 07:34:54 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Mar 2021 11:34:54 +0000
Subject: [issue43552] Add locale.get_locale_encoding() and
 locale.get_current_locale_encoding()
In-Reply-To: <1616145433.55.0.350148222552.issue43552@roundup.psfhosted.org>
Message-ID: <1616153694.59.0.15965808287.issue43552@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +methane

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43552>
_______________________________________

From report at bugs.python.org  Fri Mar 19 07:35:25 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 19 Mar 2021 11:35:25 +0000
Subject: [issue43552] Add locale.get_locale_encoding() and
 locale.get_current_locale_encoding()
In-Reply-To: <1616145433.55.0.350148222552.issue43552@roundup.psfhosted.org>
Message-ID: <1616153725.56.0.755889802744.issue43552@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> Read the ANSI code page on Windows,

I don't see why the Windows implementation is inconsistent with POSIX here. If it were changed to be consistent, the default encoding at startup would remain the same, since setlocale(LC_CTYPE, "") uses the process code page from GetACP(). In many if not most cases, no one would be the wiser. But it seems to me that if a script calls setlocale(LC_CTYPE, "el_GR"), then it clearly wants to encode Greek text (code page 1253). open() with encoding passed as None or "locale" should respect this. Similarly if it calls setlocale(LC_CTYPE, ".UTF-8"), then it wants the default locale (language/region), but with UTF-8 encoding.

The following is a snippet to get the current locale encoding with ucrt in Windows:

    #include <locale.h>

    int cp = 0;
    __crt_locale_data_public *locale_data;

    _locale_t locale = _get_current_locale();
    if (locale) {
        locale_data = (__crt_locale_data_public *)locale->locinfo;
        cp = locale_data->_locale_lc_codepage;
       _free_locale(locale);
    }

    if (cp == 0) {
    /* "C" locale. The CRT in effect uses Latin-1 (cp28591), but 
       Windows Python prefers the process code page. */
        cp = GetACP();
    }

With ucrt, the C runtime was changed to hide most of the locale definition that was previously public, but it intentionally defines __crt_locale_data_public, so I'm assuming it's there for programs to use. That said, the fact that we have to cast locinfo seems suspect to me. Steve Dower could maybe check with the ucrt devs to ensure that this is supported. 

There's also ___lc_codepage() to get the same value more simply, and also more efficiently since the current locale data doesn't have to be copied and freed. However, it's documented as internal and could be removed (unlikely as that is).

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43552>
_______________________________________

From report at bugs.python.org  Fri Mar 19 07:42:09 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Mar 2021 11:42:09 +0000
Subject: [issue43244] Move PyArena C API to the internal C API
In-Reply-To: <1613586690.19.0.383646964758.issue43244@roundup.psfhosted.org>
Message-ID: <1616154129.87.0.685862119813.issue43244@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 28ad12f8fe889a741661eb99daacebd9243cc1ba by Victor Stinner in branch 'master':
bpo-43244: Remove symtable.h header file (GH-24910)
https://github.com/python/cpython/commit/28ad12f8fe889a741661eb99daacebd9243cc1ba


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43244>
_______________________________________

From mal at egenix.com  Fri Mar 19 08:00:01 2021
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri, 19 Mar 2021 13:00:01 +0100
Subject: [issue43552] Add locale.get_locale_encoding() and
 locale.get_current_locale_encoding()
In-Reply-To: <1616151929.89.0.714213045925.issue43552@roundup.psfhosted.org>
References: <1616151929.89.0.714213045925.issue43552@roundup.psfhosted.org>
Message-ID: <fc88c509-1932-9e97-e24e-85d400301209@egenix.com>

On 19.03.2021 12:05, STINNER Victor wrote:
> I'm not sure what to do with locale.getdefaultlocale(). Should we deprecate it? I never used this function. How is it used? For which purpose?
>
> I undertand that in 2000, locale.getdefaultlocale() was interesting to avoid calling setlocale(LC_CTYPE, ""). But Python 3 calls setlocale(LC_CTYPE, "") by default at startup since the early versions, and it's now called on all platforms since Python 3.8. Moreover, its internal database seems to be outdated and is painful to maintain (especially if we consider all platforms supported by Python, not only Linux, there are many issues on macOS).

Yes, deprecate it as well. If Python calls setlocale() per default now,
it has served its purpose.

The alias database is needed by the normalization engine. We may be
able to drop the encoding part, but this would have to be checked.

-- 
Marc-Andre Lemburg
eGenix.com


From report at bugs.python.org  Fri Mar 19 08:00:06 2021
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 19 Mar 2021 12:00:06 +0000
Subject: [issue43552] Add locale.get_locale_encoding() and
 locale.get_current_locale_encoding()
In-Reply-To: <1616151929.89.0.714213045925.issue43552@roundup.psfhosted.org>
Message-ID: <fc88c509-1932-9e97-e24e-85d400301209@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 19.03.2021 12:05, STINNER Victor wrote:
> I'm not sure what to do with locale.getdefaultlocale(). Should we deprecate it? I never used this function. How is it used? For which purpose?
>
> I undertand that in 2000, locale.getdefaultlocale() was interesting to avoid calling setlocale(LC_CTYPE, ""). But Python 3 calls setlocale(LC_CTYPE, "") by default at startup since the early versions, and it's now called on all platforms since Python 3.8. Moreover, its internal database seems to be outdated and is painful to maintain (especially if we consider all platforms supported by Python, not only Linux, there are many issues on macOS).

Yes, deprecate it as well. If Python calls setlocale() per default now,
it has served its purpose.

The alias database is needed by the normalization engine. We may be
able to drop the encoding part, but this would have to be checked.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43552>
_______________________________________

From report at bugs.python.org  Fri Mar 19 08:01:11 2021
From: report at bugs.python.org (Samwyse)
Date: Fri, 19 Mar 2021 12:01:11 +0000
Subject: [issue43556] fix attr names for ast.expr and ast.stmt
Message-ID: <1616155271.78.0.879688630382.issue43556@roundup.psfhosted.org>


New submission from Samwyse <samwyse at gmail.com>:

In Doc/library/ast.rst, the lineno and end_col attributes are repeated; the second set should have 'end_' prefixed to them.  Also, there's a minor indentation error in the RST file.

# diff ast.rst ast.rst~ 
78c78
<                   col_offset
---
>                         col_offset
83c83
<       :attr:`lineno`, :attr:`col_offset`, :attr:`end_lineno`, and :attr:`end_col_offset`
---
>       :attr:`lineno`, :attr:`col_offset`, :attr:`lineno`, and :attr:`col_offset`

----------
assignee: docs at python
components: Documentation
messages: 389077
nosy: docs at python, samwyse
priority: normal
severity: normal
status: open
title: fix attr names for ast.expr and ast.stmt
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43556>
_______________________________________

From report at bugs.python.org  Fri Mar 19 08:07:02 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Fri, 19 Mar 2021 12:07:02 +0000
Subject: [issue43502] [C-API] Convert obvious unsafe macros to static inline
 functions
In-Reply-To: <1615816484.12.0.00251754107838.issue43502@roundup.psfhosted.org>
Message-ID: <1616155622.82.0.0991691114959.issue43502@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

FYI, thread started on https://discuss.python.org/t/what-to-do-with-unsafe-macros/7771?u=erlendaasland

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43502>
_______________________________________

From mal at egenix.com  Fri Mar 19 08:11:24 2021
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri, 19 Mar 2021 13:11:24 +0100
Subject: [issue43552] Add locale.get_locale_encoding() and
 locale.get_current_locale_encoding()
In-Reply-To: <1616153199.3.0.00892314562765.issue43552@roundup.psfhosted.org>
References: <1616153199.3.0.00892314562765.issue43552@roundup.psfhosted.org>
Message-ID: <c7a8e613-1928-faad-d7c4-a5b983aa5df5@egenix.com>

On 19.03.2021 12:26, STINNER Victor wrote:
> 
> STINNER Victor <vstinner at python.org> added the comment:
> 
> Recently, I spent some days to document properly encodings used by Python.

Thanks for documenting this.

I would prefer to leave the locale module to really just an interface
to the lib C locale logic and not add encoding details which are
specific to Python's view on I/O (sys or io) or the file system (os).

Hopefully, in a few years, we can get rid of all this and standardize
on UTF-8 everywhere.

-- 
Marc-Andre Lemburg
eGenix.com


From mal at egenix.com  Fri Mar 19 08:11:34 2021
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri, 19 Mar 2021 13:11:34 +0100
Subject: [issue43552] Add locale.get_locale_encoding() and
 locale.get_current_locale_encoding()
In-Reply-To: <1616153725.56.0.755889802744.issue43552@roundup.psfhosted.org>
References: <1616153725.56.0.755889802744.issue43552@roundup.psfhosted.org>
Message-ID: <82ce5025-3846-b2c0-7d07-4bb8cf8dec3d@egenix.com>

On 19.03.2021 12:35, Eryk Sun wrote:
> 
> Eryk Sun <eryksun at gmail.com> added the comment:
> 
>> Read the ANSI code page on Windows,
> 
> I don't see why the Windows implementation is inconsistent with POSIX here. If it were changed to be consistent, the default encoding at startup would remain the same, since setlocale(LC_CTYPE, "") uses the process code page from GetACP().

I'm not sure I understand what you're saying (but then, I have little
experience with locales on Windows).

My assumption is that nl_langinfo(CODESET) does not work on Windows
or gives wrong results. Is that incorrect ?

If it does work, getencoding() could just be a shim over
nl_langinfo(CODESET) on all platforms.

-- 
Marc-Andre Lemburg
eGenix.com


From report at bugs.python.org  Fri Mar 19 08:11:27 2021
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 19 Mar 2021 12:11:27 +0000
Subject: [issue43552] Add locale.get_locale_encoding() and
 locale.get_current_locale_encoding()
In-Reply-To: <1616153199.3.0.00892314562765.issue43552@roundup.psfhosted.org>
Message-ID: <c7a8e613-1928-faad-d7c4-a5b983aa5df5@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 19.03.2021 12:26, STINNER Victor wrote:
> 
> STINNER Victor <vstinner at python.org> added the comment:
> 
> Recently, I spent some days to document properly encodings used by Python.

Thanks for documenting this.

I would prefer to leave the locale module to really just an interface
to the lib C locale logic and not add encoding details which are
specific to Python's view on I/O (sys or io) or the file system (os).

Hopefully, in a few years, we can get rid of all this and standardize
on UTF-8 everywhere.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43552>
_______________________________________

From report at bugs.python.org  Fri Mar 19 08:11:37 2021
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 19 Mar 2021 12:11:37 +0000
Subject: [issue43552] Add locale.get_locale_encoding() and
 locale.get_current_locale_encoding()
In-Reply-To: <1616153725.56.0.755889802744.issue43552@roundup.psfhosted.org>
Message-ID: <82ce5025-3846-b2c0-7d07-4bb8cf8dec3d@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 19.03.2021 12:35, Eryk Sun wrote:
> 
> Eryk Sun <eryksun at gmail.com> added the comment:
> 
>> Read the ANSI code page on Windows,
> 
> I don't see why the Windows implementation is inconsistent with POSIX here. If it were changed to be consistent, the default encoding at startup would remain the same, since setlocale(LC_CTYPE, "") uses the process code page from GetACP().

I'm not sure I understand what you're saying (but then, I have little
experience with locales on Windows).

My assumption is that nl_langinfo(CODESET) does not work on Windows
or gives wrong results. Is that incorrect ?

If it does work, getencoding() could just be a shim over
nl_langinfo(CODESET) on all platforms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43552>
_______________________________________

From report at bugs.python.org  Fri Mar 19 08:15:37 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Fri, 19 Mar 2021 12:15:37 +0000
Subject: [issue43492] Upgrade to SQLite 3.35.2 in macOS and Windows
In-Reply-To: <1615752732.27.0.278073347477.issue43492@roundup.psfhosted.org>
Message-ID: <1616156137.81.0.506117669343.issue43492@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

SQLite 3.35.3 is upcoming: https://sqlite.org/forum/forumpost/6e2b05ad62?t=h
Seems like we'll have to wait a little bit for 3.35 to stabilise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43492>
_______________________________________

From report at bugs.python.org  Fri Mar 19 08:25:03 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 19 Mar 2021 12:25:03 +0000
Subject: [issue43552] Add locale.get_locale_encoding() and
 locale.get_current_locale_encoding()
In-Reply-To: <1616145433.55.0.350148222552.issue43552@roundup.psfhosted.org>
Message-ID: <1616156703.05.0.889922202114.issue43552@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> If Python calls setlocale() per default now, it has served its purpose.

Except not for embedding applications if configure_locale [1] isn't set. But in that case determining the default locale isn't Python's problem to solve.

> My assumption is that nl_langinfo(CODESET) does not work on Windows
> or gives wrong results. Is that incorrect ?

There is no such function for CRT locales. I provided two alternatives that would allow implementing this consistent with POSIX, and thus avoid all of the "except on Windows..." disclaimers that have to explain (apologize) that only the process ANSI code page is used in Windows, and, for no good reason as far as I can tell, the LC_CTYPE locale encoding is completely ignored.

---

[1] https://docs.python.org/3/c-api/init_config.html#c.PyPreConfig.configure_locale

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43552>
_______________________________________

From report at bugs.python.org  Fri Mar 19 08:35:01 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Mar 2021 12:35:01 +0000
Subject: [issue43244] Move PyArena C API to the internal C API
In-Reply-To: <1613586690.19.0.383646964758.issue43244@roundup.psfhosted.org>
Message-ID: <1616157301.14.0.907376227269.issue43244@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +23694
pull_request: https://github.com/python/cpython/pull/24933

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43244>
_______________________________________

From report at bugs.python.org  Fri Mar 19 08:48:02 2021
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 19 Mar 2021 12:48:02 +0000
Subject: [issue43552] Add locale.get_locale_encoding() and
 locale.get_current_locale_encoding()
In-Reply-To: <1616156703.05.0.889922202114.issue43552@roundup.psfhosted.org>
Message-ID: <c4d2a975-ef52-8405-8e84-292cdb658aef@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 19.03.2021 13:25, Eryk Sun wrote:
>> My assumption is that nl_langinfo(CODESET) does not work on Windows
>> or gives wrong results. Is that incorrect ?
> 
> There is no such function for CRT locales. I provided two alternatives that would allow implementing this consistent with POSIX, and thus avoid all of the "except on Windows..." disclaimers that have to explain (apologize) that only the process ANSI code page is used in Windows, and, for no good reason as far as I can tell, the LC_CTYPE locale encoding is completely ignored.

Sounds good. If we can get consistent behavior on Windows as well,
all the better :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43552>
_______________________________________

From report at bugs.python.org  Fri Mar 19 08:57:58 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Mar 2021 12:57:58 +0000
Subject: [issue43539] test_asyncio:
 test_sendfile_close_peer_in_the_middle_of_receiving() fails randomly
In-Reply-To: <1616056043.89.0.64862359152.issue43539@roundup.psfhosted.org>
Message-ID: <1616158678.54.0.457278588557.issue43539@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

It failed again:
https://github.com/python/cpython/pull/24933/checks?check_run_id=2148450378

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43539>
_______________________________________

From report at bugs.python.org  Fri Mar 19 09:21:51 2021
From: report at bugs.python.org (Anentropic)
Date: Fri, 19 Mar 2021 13:21:51 +0000
Subject: [issue43546] "Impossible" KeyError from importlib._bootstrap acquire
 line 110
In-Reply-To: <1616093906.25.0.990565288145.issue43546@roundup.psfhosted.org>
Message-ID: <1616160111.05.0.63278125441.issue43546@roundup.psfhosted.org>


Anentropic <ego at anentropic.com> added the comment:

Upgrading ddtrace lib to latest version did not help.

Disabling ddtrace patching of django module does make the error go away.

Thanks again for your help, I will move my bug report over to ddtrace.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43546>
_______________________________________

From report at bugs.python.org  Fri Mar 19 09:27:27 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Mar 2021 13:27:27 +0000
Subject: [issue43557] Deprecate getdefaultlocale(),
 getlocale() and normalize() functions
Message-ID: <1616160447.56.0.84902377628.issue43557@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

I propose to deprecate getdefaultlocale(), getlocale() and normalize() functions since they have multiple issues, and remove them in Python 3.12.


The normalize() function uses the locale.locale_alias dictionary which was copied from the X11 locale database in 2000. It's hard to keep this dictionary up to date and to support all locales of all platforms supported by Python. There are multiple issues on macOS for example.

getdefaultlocale() and getlocale() use heuristics to get an encoding from the locale name. These heuristics are not reliable.

getdefaultlocale() only rely on environment variables. When setlocale() is called, environment variables are not updated, and so the encoding returned by getdefaultlocale() is not the effective LC_CTYPE locale encoding. Example:
https://bugs.python.org/issue43552#msg389069

getlocale() open issues:

* bpo-20088: locale.getlocale() fails if locale name doesn't include encoding 
* bpo-23425: Windows getlocale unix-like with french, german, portuguese, spanish 
* bpo-33934: locale.getlocale() seems wrong when the locale is yet unset (python3 on linux) 
* bpo-38805: locale.getlocale() returns a non RFC1766 language code 
* bpo-43115: locale.getlocale fails if locale is set 

getdefaultlocale() open issue:

* bpo-6981: locale.getdefaultlocale() envvars default code and documentation mismatch 
* bpo-30755: locale.normalize() and getdefaultlocale() convert C.UTF-8 to en_US.UTF-8


Replacements:

* getdefaultlocale()[1] => getpreferredencoding(False) or get_current_locale_encoding(), see bpo-43552
* getlocale(loc) => setlocale(loc) or setlocale(loc, None)
* normalize => no replacement. There is no standard way to normalize a locale name.

----------
components: Library (Lib)
messages: 389086
nosy: vstinner
priority: normal
severity: normal
status: open
title: Deprecate getdefaultlocale(), getlocale() and normalize() functions
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43557>
_______________________________________

From report at bugs.python.org  Fri Mar 19 09:27:51 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Mar 2021 13:27:51 +0000
Subject: [issue43552] Add locale.get_locale_encoding() and
 locale.get_current_locale_encoding()
In-Reply-To: <1616145433.55.0.350148222552.issue43552@roundup.psfhosted.org>
Message-ID: <1616160471.74.0.788449772302.issue43552@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I created bpo-43557 "Deprecate getdefaultlocale(), getlocale() and normalize() functions". Let's discuss deprecating getdefaultlocale() there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43552>
_______________________________________

From report at bugs.python.org  Fri Mar 19 09:47:36 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Mar 2021 13:47:36 +0000
Subject: [issue43552] Add locale.get_locale_encoding() and
 locale.get_current_locale_encoding()
In-Reply-To: <1616145433.55.0.350148222552.issue43552@roundup.psfhosted.org>
Message-ID: <1616161656.73.0.605355864914.issue43552@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> - If you add "current", people will rightly ask: then what do all the
> other APIs in the locale module return ? Of course, they all return
> the current state of settings :-) So this is unnecessary as well.

The problem is that there are two different "locale encodings", what I call:

* "current locale encoding": nl_langinfo(CODESET) in short
* "Python locale encoding": "UTF-8" in some cases, nl_langinfo(CODESET) otherwise

It is unfortunate that the Python UTF-8 Mode which "ignores the locale" changes the behavior of the locale module, of the locale.getpreferredencoding() function. But the ship has sailed.

People are used to look into the "locale" module to get the "locale" encoding. So I prefer to put  the function to get the "Python locale encoding" in the locale module.

I propose to add "current" in the name since this encoding is not the one you are looking for usually.

An alternative is to have a single function with an optional parameter. Example:

* get_locale_encoding() or get_locale_encoding(True) returns the locale encoding
* get_locale_encoding(False) returns the current locale encoding

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43552>
_______________________________________

From report at bugs.python.org  Fri Mar 19 09:57:29 2021
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 19 Mar 2021 13:57:29 +0000
Subject: [issue43552] Add locale.get_locale_encoding() and
 locale.get_current_locale_encoding()
In-Reply-To: <1616145433.55.0.350148222552.issue43552@roundup.psfhosted.org>
Message-ID: <1616162249.48.0.772700997915.issue43552@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

> I created this issue while reviewing the implementation of the PEP 597: PR 19481.

What I want is same to `locale.getpreferredencoding(False)` but ignores UTF-8 mode.

Background: PEP 597 adds new `encoding="locale"`option to open() and TextIOWrapper(). It is same to `encoding=None` for now, but it means using "locale encoding" explicitly.

But this is wrong in UTF-8 mode.

In UTF-8 mode, it's fine to `open(filename)` uses UTF-8. But I want to use "locale encoding" for `open(filename, encoding="locale")` because "locale" encoding is specified.

I don't want to add new meaning here. It should be same to `locale.getpreferredencoding(False)` without UTF-8 mode. So I need "cp%d" % GetACP() on Windows, not CRT locale encoding.

I don't care its name. both of sys.locale_encoding() and locale.get_encoding() are OK.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43552>
_______________________________________

From report at bugs.python.org  Fri Mar 19 10:01:13 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Mar 2021 14:01:13 +0000
Subject: [issue43552] Add locale.get_locale_encoding() and
 locale.get_current_locale_encoding()
In-Reply-To: <1616145433.55.0.350148222552.issue43552@roundup.psfhosted.org>
Message-ID: <1616162473.75.0.890679777572.issue43552@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> In UTF-8 mode, it's fine to `open(filename)` uses UTF-8. But I want to use "locale encoding" for `open(filename, encoding="locale")` because "locale" encoding is specified.

Is it about the current implementation of the PEP 597, or are you thinking at the future Python which would use UTF-8 by default?

Currently, getpreferredencoding(False) respects the behavior that you described, no?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43552>
_______________________________________

From report at bugs.python.org  Fri Mar 19 10:12:25 2021
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 19 Mar 2021 14:12:25 +0000
Subject: [issue43552] Add locale.get_locale_encoding() and
 locale.get_current_locale_encoding()
In-Reply-To: <1616145433.55.0.350148222552.issue43552@roundup.psfhosted.org>
Message-ID: <1616163145.7.0.944015798705.issue43552@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

> Is it about the current implementation of the PEP 597, or are you thinking at the future Python which would use UTF-8 by default?

I had forgot to consider about UTF-8 mode while finishing PEP 597. If possible, I want to ignore UTF-8 mode when `encoding="locale"` is specified from Python 3.10.
Otherwise, behavior will be changed between Python 3.10 and 3.11.

> Currently, getpreferredencoding(False) respects the behavior that you described, no?

getpreferredencoding(False) respects UTF-8 mode. That's what PEP 597 said (because the PEP don't define behavior in UTF-8 mode) and GH-19481 implements. 

But it is not what I want for now. I want to ignore UTF-8 mode when `encoding="locale"` is specified.

This is almost "only in Windows" issue, and users can use `encoding="mbcs"` in Windows-only script.

But `encoding="locale"` is new and recommended way to specify using "locale" encoding explicitly. When user specify "locale" encoding explicitly, I think we should respect it regardless UTF-8 mode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43552>
_______________________________________

From report at bugs.python.org  Fri Mar 19 10:14:04 2021
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 19 Mar 2021 14:14:04 +0000
Subject: [issue43555] Location of SyntaxError with new parser missing (after
 continuation character)
In-Reply-To: <1616152732.25.0.508578313833.issue43555@roundup.psfhosted.org>
Message-ID: <1616163244.31.0.352231592745.issue43555@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +gvanrossum, lys.nikolaou, pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43555>
_______________________________________

From report at bugs.python.org  Fri Mar 19 10:16:06 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Mar 2021 14:16:06 +0000
Subject: [issue43510] PEP 597: Implemente encoding="locale" option and
 EncodingWarning
In-Reply-To: <1615868389.17.0.260147645451.issue43510@roundup.psfhosted.org>
Message-ID: <1616163366.63.0.258541997283.issue43510@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I replied to INADA-san message on bpo-43552:
https://bugs.python.org/issue43552#msg389091

> I had forgot to consider about UTF-8 mode while finishing PEP 597. If possible, I want to ignore UTF-8 mode when `encoding="locale"` is specified from Python 3.10.

In this case, the PEP 597 statement that open(filename, encoding="locale") is the same  than open(filename) is wrong. It would mean that users which got the UTF-8 Mode enabled (implicitly or explicitly) would switch to a legacy encoding like latin1 rather than using the UTF-8 encoding, if they add encoding="locale" to their open() calls?

Since the final goal is to move everybody towards to UTF-8, I'm not sure how it's a good thing.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43510>
_______________________________________

From report at bugs.python.org  Fri Mar 19 10:17:18 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Mar 2021 14:17:18 +0000
Subject: [issue43552] Add locale.get_locale_encoding() and
 locale.get_current_locale_encoding()
In-Reply-To: <1616145433.55.0.350148222552.issue43552@roundup.psfhosted.org>
Message-ID: <1616163438.7.0.0895116263687.issue43552@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Hum, latest messages are specific to the PEP 597 (implementation).

> I had forgot to consider about UTF-8 mode while finishing PEP 597.

I propose to continue the discussion about the PEP 597 in bpo-43510. I replied there.

I prefer to keep this issue to discuss the locale module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43552>
_______________________________________

From report at bugs.python.org  Fri Mar 19 10:28:46 2021
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 19 Mar 2021 14:28:46 +0000
Subject: [issue43510] PEP 597: Implemente encoding="locale" option and
 EncodingWarning
In-Reply-To: <1615868389.17.0.260147645451.issue43510@roundup.psfhosted.org>
Message-ID: <1616164126.16.0.476326194435.issue43510@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

> Since the final goal is to move everybody towards to UTF-8, I'm not sure how it's a good thing.

The final goal (the third motivation of the pep 597) is changing the default encoding (i.e. encoding used when it is not specified) to UTF-8.

But forcing people to use UTF-8 even they specify locale encoding explicitly is not the goal. That's why I want to ignore UTF-8 mode when `encoding="locale"` is specified.

I think this is almost Windows-only issue, and "mbcs" can be used in Windows already. It is documented in https://docs.python.org/3/using/windows.html#utf-8-mode

So this is not a blocker. Just my preference.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43510>
_______________________________________

From report at bugs.python.org  Fri Mar 19 10:31:58 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Mar 2021 14:31:58 +0000
Subject: [issue43510] PEP 597: Implemente encoding="locale" option and
 EncodingWarning
In-Reply-To: <1615868389.17.0.260147645451.issue43510@roundup.psfhosted.org>
Message-ID: <1616164318.88.0.414287905715.issue43510@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I see different cases when open() is called with no encoding argument:

(A) User wants to use UTF-8: add encoding="utf-8"

(B) Windows user wants to use the ANSI code page of their computer, local file not intended to be shared with other computers: add encoding="mbcs". This makes the code specific to Windows ("mbcs" alias doesn't exist on Unix).

(C) User wants to use the locale encoding and is fine with the UTF-8 Mode: add encoding=getpreferredencoding(False)

(D) Unix user wants to use the locale encoding but not the UTF-8 Mode: encoding=get_current_locale_encoding() (function proposed in bpo-43552) or nl_langinfo(CODESET) (should work on any Python version). I don't know if nl_langinfo(CODESET) is available on Windows.

(E) User has no idea of what they are doing and don't understand anything to Unicode: please trust us and specify explicitly UTF-8 :-)

Apart the encoding="utf-8" case, I understand that they are two main complex cases:

(1) "UTF-8" in the UTF-8 Mode, or the locale encoding
(2) Always use the locale encoding, ignore the UTF-8 Mode

What I don't expect is the current behavior, before PEP 597. Who uses open() without specifying an encoding but always want to use the locale encoding? (case 2) So this use case is already broken when the UTF-8 Mode is enabled explicitly?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43510>
_______________________________________

From report at bugs.python.org  Fri Mar 19 10:42:31 2021
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 19 Mar 2021 14:42:31 +0000
Subject: [issue43557] Deprecate getdefaultlocale(),
 getlocale() and normalize() functions
In-Reply-To: <1616160447.56.0.84902377628.issue43557@roundup.psfhosted.org>
Message-ID: <6374a567-6d1f-93ff-ddbc-be30e1a39056@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

+1 on getdefaultlocale() as mentioned in https://bugs.python.org/issue43552

However, -1 on getlocale() and normalize().

Those two are needed to access and successfully set the locale on
Linux: the lib C setlocale() is very picky about locale names and
so normalization helps in finding the right form and getting
usable results across platforms.

The issues open for these should be addressed and fixed.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43557>
_______________________________________

From report at bugs.python.org  Fri Mar 19 10:47:18 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 19 Mar 2021 14:47:18 +0000
Subject: [issue43558] The dataclasses documentation should mention how to call
 super().__init__
Message-ID: <1616165238.01.0.0594716110393.issue43558@roundup.psfhosted.org>


New submission from Eric V. Smith <eric at trueblade.com>:

https://docs.python.org/3/library/dataclasses.html#post-init-processing should mention that if you need to call super().__init__, you should do it in __post_init__. Dataclasses cannot know what parameters to pass to the super class's __init__, so you'll need to do it yourself manually in __post_init__.

----------
assignee: eric.smith
components: Documentation
messages: 389097
nosy: eric.smith
priority: low
severity: normal
stage: needs patch
status: open
title: The dataclasses documentation should mention how to call super().__init__
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43558>
_______________________________________

From mal at egenix.com  Fri Mar 19 10:56:50 2021
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri, 19 Mar 2021 15:56:50 +0100
Subject: [issue43552] Add locale.get_locale_encoding() and
 locale.get_current_locale_encoding()
In-Reply-To: <1616161656.73.0.605355864914.issue43552@roundup.psfhosted.org>
References: <1616161656.73.0.605355864914.issue43552@roundup.psfhosted.org>
Message-ID: <ad56a593-943f-af5f-3da0-f65f2ca89eab@egenix.com>

On 19.03.2021 14:47, STINNER Victor wrote:
> 
> STINNER Victor <vstinner at python.org> added the comment:
> 
>> - If you add "current", people will rightly ask: then what do all the
>> other APIs in the locale module return ? Of course, they all return
>> the current state of settings :-) So this is unnecessary as well.
> 
> The problem is that there are two different "locale encodings", what I call:
> 
> * "current locale encoding": nl_langinfo(CODESET) in short
> * "Python locale encoding": "UTF-8" in some cases, nl_langinfo(CODESET) otherwise

The UTF-8 mode is a Python invention. It doesn't have anything to
do with the lib C locale functions, which this module addresses and
interfaces to.

Please don't mix the two.

In fact, in order to avoid issues, Python should probably set the locale
encoding to UTF-8 as well, when run in UTF-8 mode. It's dangerous to
have Python and the lib C use different assumptions about the encoding,
esp. in embedded applications.

> It is unfortunate that the Python UTF-8 Mode which "ignores the locale" changes the behavior of the locale module, of the locale.getpreferredencoding() function. But the ship has sailed.
> 
> People are used to look into the "locale" module to get the "locale" encoding. So I prefer to put  the function to get the "Python locale encoding" in the locale module.
> 
> I propose to add "current" in the name since this encoding is not the one you are looking for usually.
> 
> An alternative is to have a single function with an optional parameter. Example:
> 
> * get_locale_encoding() or get_locale_encoding(True) returns the locale encoding
> * get_locale_encoding(False) returns the current locale encoding

-1, both on the names and the idea to again add parameters which change
their meaning. We should have one function per meaning and really
only need the interface getencoding(), since the UTF-8 mode
doesn't fit into the locale module scope.

-- 
Marc-Andre Lemburg
eGenix.com


From report at bugs.python.org  Fri Mar 19 10:56:53 2021
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 19 Mar 2021 14:56:53 +0000
Subject: [issue43552] Add locale.get_locale_encoding() and
 locale.get_current_locale_encoding()
In-Reply-To: <1616161656.73.0.605355864914.issue43552@roundup.psfhosted.org>
Message-ID: <ad56a593-943f-af5f-3da0-f65f2ca89eab@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 19.03.2021 14:47, STINNER Victor wrote:
> 
> STINNER Victor <vstinner at python.org> added the comment:
> 
>> - If you add "current", people will rightly ask: then what do all the
>> other APIs in the locale module return ? Of course, they all return
>> the current state of settings :-) So this is unnecessary as well.
> 
> The problem is that there are two different "locale encodings", what I call:
> 
> * "current locale encoding": nl_langinfo(CODESET) in short
> * "Python locale encoding": "UTF-8" in some cases, nl_langinfo(CODESET) otherwise

The UTF-8 mode is a Python invention. It doesn't have anything to
do with the lib C locale functions, which this module addresses and
interfaces to.

Please don't mix the two.

In fact, in order to avoid issues, Python should probably set the locale
encoding to UTF-8 as well, when run in UTF-8 mode. It's dangerous to
have Python and the lib C use different assumptions about the encoding,
esp. in embedded applications.

> It is unfortunate that the Python UTF-8 Mode which "ignores the locale" changes the behavior of the locale module, of the locale.getpreferredencoding() function. But the ship has sailed.
> 
> People are used to look into the "locale" module to get the "locale" encoding. So I prefer to put  the function to get the "Python locale encoding" in the locale module.
> 
> I propose to add "current" in the name since this encoding is not the one you are looking for usually.
> 
> An alternative is to have a single function with an optional parameter. Example:
> 
> * get_locale_encoding() or get_locale_encoding(True) returns the locale encoding
> * get_locale_encoding(False) returns the current locale encoding

-1, both on the names and the idea to again add parameters which change
their meaning. We should have one function per meaning and really
only need the interface getencoding(), since the UTF-8 mode
doesn't fit into the locale module scope.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43552>
_______________________________________

From report at bugs.python.org  Fri Mar 19 10:57:12 2021
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 19 Mar 2021 14:57:12 +0000
Subject: [issue43510] PEP 597: Implemente encoding="locale" option and
 EncodingWarning
In-Reply-To: <1615868389.17.0.260147645451.issue43510@roundup.psfhosted.org>
Message-ID: <1616165832.62.0.0630082984.issue43510@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

> (1) "UTF-8" in the UTF-8 Mode, or the locale encoding
> (2) Always use the locale encoding, ignore the UTF-8 Mode
>
> What I don't expect is the current behavior, before PEP 597. Who uses open() without specifying an encoding but always want to use the locale encoding? (case 2) So this use case is already broken when the UTF-8 Mode is enabled explicitly?

Yes, it is broken already.  So they can not use UTF-8 mode.

If `encoding="locale"` ignore UTF-8 mode, it save the use case. They can add `encoding="locale"` where they need to use locale/GetACP encoding and enable UTF-8 mode.

That's why it is important If we enable UTF-8 mode by default in the future.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43510>
_______________________________________

From mal at egenix.com  Fri Mar 19 11:02:36 2021
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri, 19 Mar 2021 16:02:36 +0100
Subject: [issue43552] Add locale.get_locale_encoding() and
 locale.get_current_locale_encoding()
In-Reply-To: <1616162249.48.0.772700997915.issue43552@roundup.psfhosted.org>
References: <1616162249.48.0.772700997915.issue43552@roundup.psfhosted.org>
Message-ID: <d93d560b-58bb-ab92-3706-7905ba26138b@egenix.com>

On 19.03.2021 14:57, Inada Naoki wrote:
> 
> Background: PEP 597 adds new `encoding="locale"`option to open() and TextIOWrapper(). It is same to `encoding=None` for now, but it means using "locale encoding" explicitly.
> 
> But this is wrong in UTF-8 mode.

Please address UTF-8 mode explicitly in open() or elsewhere. The locale
module is about the state of the lib C, not what Python enforces via
options in its own I/O layers.

As mentioned, both should ideally be synchronized, though, so
UTF-8 mode in Python should trigger setting a UTF-8 encoding
via setlocale().

-- 
Marc-Andre Lemburg
eGenix.com


From report at bugs.python.org  Fri Mar 19 11:02:41 2021
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 19 Mar 2021 15:02:41 +0000
Subject: [issue43552] Add locale.get_locale_encoding() and
 locale.get_current_locale_encoding()
In-Reply-To: <1616162249.48.0.772700997915.issue43552@roundup.psfhosted.org>
Message-ID: <d93d560b-58bb-ab92-3706-7905ba26138b@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 19.03.2021 14:57, Inada Naoki wrote:
> 
> Background: PEP 597 adds new `encoding="locale"`option to open() and TextIOWrapper(). It is same to `encoding=None` for now, but it means using "locale encoding" explicitly.
> 
> But this is wrong in UTF-8 mode.

Please address UTF-8 mode explicitly in open() or elsewhere. The locale
module is about the state of the lib C, not what Python enforces via
options in its own I/O layers.

As mentioned, both should ideally be synchronized, though, so
UTF-8 mode in Python should trigger setting a UTF-8 encoding
via setlocale().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43552>
_______________________________________

From mal at egenix.com  Fri Mar 19 10:42:27 2021
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri, 19 Mar 2021 15:42:27 +0100
Subject: [issue43557] Deprecate getdefaultlocale(), getlocale() and
 normalize() functions
In-Reply-To: <1616160447.56.0.84902377628.issue43557@roundup.psfhosted.org>
References: <1616160447.56.0.84902377628.issue43557@roundup.psfhosted.org>
Message-ID: <6374a567-6d1f-93ff-ddbc-be30e1a39056@egenix.com>

+1 on getdefaultlocale() as mentioned in https://bugs.python.org/issue43552

However, -1 on getlocale() and normalize().

Those two are needed to access and successfully set the locale on
Linux: the lib C setlocale() is very picky about locale names and
so normalization helps in finding the right form and getting
usable results across platforms.

The issues open for these should be addressed and fixed.

-- 
Marc-Andre Lemburg
eGenix.com


From report at bugs.python.org  Fri Mar 19 11:15:12 2021
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 19 Mar 2021 15:15:12 +0000
Subject: [issue43552] Add locale.get_locale_encoding() and
 locale.get_current_locale_encoding()
In-Reply-To: <1616145433.55.0.350148222552.issue43552@roundup.psfhosted.org>
Message-ID: <1616166912.09.0.266429410501.issue43552@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

> Please address UTF-8 mode explicitly in open() or elsewhere. The locale
> module is about the state of the lib C, not what Python enforces via
> options in its own I/O layers.

I agree with you. APIs in locale module shouldn't aware UTF-8 mode.

`locale.getpreferredencoding()` is special, because it "Return the encoding used for text data, according to user preferences. User preferences are expressed differently on different systems, and might not be available programmatically on some systems, so this function only returns a guess."


> As mentioned, both should ideally be synchronized, though, so
> UTF-8 mode in Python should trigger setting a UTF-8 encoding
> via setlocale().

There is PEP 538 already :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43552>
_______________________________________

From report at bugs.python.org  Fri Mar 19 11:22:29 2021
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 19 Mar 2021 15:22:29 +0000
Subject: [issue43552] Add locale.get_locale_encoding() and
 locale.get_current_locale_encoding()
In-Reply-To: <1616166912.09.0.266429410501.issue43552@roundup.psfhosted.org>
Message-ID: <72248799-0c0b-dc14-c666-3f8c3054788a@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 19.03.2021 16:15, Inada Naoki wrote:
> 
> `locale.getpreferredencoding()` is special, because it "Return the encoding used for text data, according to user preferences. User preferences are expressed differently on different systems, and might not be available programmatically on some systems, so this function only returns a guess."

I already wrote earlier that we should deprecate this API, since the
overloading with different meanings in the past has turned it into
an unreliable source of information. At this point, it returns
"some encoding, which may or may not be what you want" :-)

We need to get things separated out clearly again: the locale
module is for the lib C locale state. What Python does in the
I/O layers has to be defined and queries at the appropriate
places elsewhere (e.g. os, sys or io modules).

>> As mentioned, both should ideally be synchronized, though, so
>> UTF-8 mode in Python should trigger setting a UTF-8 encoding
>> via setlocale().
> 
> There is PEP 538 already :)

Great :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43552>
_______________________________________

From report at bugs.python.org  Fri Mar 19 12:11:57 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Mar 2021 16:11:57 +0000
Subject: [issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu
 triplet)
In-Reply-To: <1612870873.59.0.718960539942.issue43179@roundup.psfhosted.org>
Message-ID: <1616170317.91.0.96972225887.issue43179@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43179>
_______________________________________

From report at bugs.python.org  Fri Mar 19 12:11:52 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Mar 2021 16:11:52 +0000
Subject: [issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu
 triplet)
In-Reply-To: <1612870873.59.0.718960539942.issue43179@roundup.psfhosted.org>
Message-ID: <1616170312.85.0.895296542044.issue43179@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

https://bugs.python.org/issue43179 and https://mail.python.org/archives/list/python-dev at python.org/thread/F5BXISYP7RAINXUMYJSEYG7GCFRFAENF/ discussions didn't reach kind of consensus. I'm tired of these discussions, so I just closed my PR 24534. If someone wants to drop support of the 31-bit Linux s390 platform, please go ahead, feel free to copy my patch.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43179>
_______________________________________

From report at bugs.python.org  Fri Mar 19 12:14:56 2021
From: report at bugs.python.org (John Paul Adrian Glaubitz)
Date: Fri, 19 Mar 2021 16:14:56 +0000
Subject: [issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu
 triplet)
In-Reply-To: <1612870873.59.0.718960539942.issue43179@roundup.psfhosted.org>
Message-ID: <1616170496.59.0.642413365142.issue43179@roundup.psfhosted.org>


John Paul Adrian Glaubitz <glaubitz at debian.org> added the comment:

I think there is one productive result of this discussion which is this patch by Jessica Clark which gets rid of architecture-specific alignment code:

> https://github.com/python/cpython/pull/24624

Unfortunately, it has not seen any positive reviews yet. Getting this merged would remove some maintenance burden from the CPython maintainers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43179>
_______________________________________

From report at bugs.python.org  Fri Mar 19 13:42:50 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Mar 2021 17:42:50 +0000
Subject: [issue41718] test.regrtest has way too many imports
In-Reply-To: <1599233772.93.0.299899979889.issue41718@roundup.psfhosted.org>
Message-ID: <1616175770.31.0.788601016417.issue41718@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +23695
pull_request: https://github.com/python/cpython/pull/24934

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41718>
_______________________________________

From report at bugs.python.org  Fri Mar 19 13:45:20 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Mar 2021 17:45:20 +0000
Subject: [issue41718] test.regrtest has way too many imports
In-Reply-To: <1599233772.93.0.299899979889.issue41718@roundup.psfhosted.org>
Message-ID: <1616175920.11.0.508864208837.issue41718@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Serhiy: "You could save/restore this data only when corresponded modules was imported, like it was done in clear_caches() in refleak.py."

That's a very good idea! I implemented it in PR 24934. But I modified runtest() to use *two* saved_test_environment instance. One before the test module is imported, one after. The one before is needed to check if the import itself has side effect, for example if the module body has side effect. The second is to check if running tests has side effect. The second one is more likely to have modules imported. The first one may miss some bugs, but IMO it's an acceptable trade-off.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41718>
_______________________________________

From report at bugs.python.org  Fri Mar 19 14:16:57 2021
From: report at bugs.python.org (Matthew Barnett)
Date: Fri, 19 Mar 2021 18:16:57 +0000
Subject: [issue43535] Make str.join auto-convert inputs to strings.
In-Reply-To: <1616034546.27.0.0632217994438.issue43535@roundup.psfhosted.org>
Message-ID: <1616177817.15.0.521250960052.issue43535@roundup.psfhosted.org>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

I'm also -1, for the same reason as Serhiy gave. However, if it was opt-in, then I'd be OK with it.

----------
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43535>
_______________________________________

From report at bugs.python.org  Fri Mar 19 14:19:33 2021
From: report at bugs.python.org (=?utf-8?q?Canberk_S=C3=B6nmez?=)
Date: Fri, 19 Mar 2021 18:19:33 +0000
Subject: [issue43559] ctypes: Heap Pointer is damaged between C and Python
Message-ID: <1616177973.2.0.159103598259.issue43559@roundup.psfhosted.org>


New submission from Canberk S?nmez <canberk.sonmez.409 at gmail.com>:

Please see the SO post:

https://stackoverflow.com/questions/66713071/ctypes-heap-pointer-is-damaged-between-c-and-python-linux-x86-64

In summary, when I return a pointer to a heap-allocated memory location from a C function, its most significant 32 bits are chopped off for some reason.

I observed this behavior in Python 3.7 and Python 3.8, on Ubuntu 18.04 and Centos 7 (x86_64).

----------
messages: 389107
nosy: canberk.sonmez.409
priority: normal
severity: normal
status: open
title: ctypes: Heap Pointer is damaged between C and Python

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43559>
_______________________________________

From report at bugs.python.org  Fri Mar 19 14:30:12 2021
From: report at bugs.python.org (hai shi)
Date: Fri, 19 Mar 2021 18:30:12 +0000
Subject: [issue43554] email: encoded headers lose their quoting when refolded
In-Reply-To: <1616147102.5.0.601004900737.issue43554@roundup.psfhosted.org>
Message-ID: <1616178612.26.0.858957237608.issue43554@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
nosy: +barry, maxking, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43554>
_______________________________________

From report at bugs.python.org  Fri Mar 19 14:39:18 2021
From: report at bugs.python.org (Larry Trammell)
Date: Fri, 19 Mar 2021 18:39:18 +0000
Subject: [issue43560] Modify SAX/expat parsing to avoid fragmentation of
 already-tiny content chunks
Message-ID: <1616179158.85.0.552129981658.issue43560@roundup.psfhosted.org>


New submission from Larry Trammell <ridgerat at nwi.net>:

Issue 43483 was posted as a "bug" but retracted.  Though the problem is real, it is tricky to declare an UNSPECIFIED behavior to be a bug.  See that issue page for more discussion and a test case.  A brief overview is repeated here.

SCENARIO - XML PARSING LOSES DATA (or not)

The parsing attempts to capture text consisting of very tiny quoted strings. A typical content line reads something like this: 

   <p>Colchuck</p>

The parser implements a scheme presented at various tutorial Web sites, using two member functions. 

   # Note the name attribute of the current tag group
   def element_handler(self, tagname, attrs) :
       self.CurrentTag = tagname      

   # Record the content from each "p" tag when encountered
   def characters(self, content):
       if self.CurrentTag == "p":
           self.name = content

   ...

   > print(parser.name)
   "Colchuck" 

But then, after successfully extracting content from perhaps hundreds of thousands of XML tag sets in this way, the parsing suddenly "drops" a few characters of content. 

   > print(parser.name)
   "lchuck" 

While this problem was observed with a SAX parser, it can affect expat parsers as well.  It affects 32-bit and 64-bit implementations the same, over several major releases of the Python 3 system.  

SPECIFIED BEHAVIOR (or not) 

The "xml.sax.handler" page in the Python 3.9.2 Documentation for the Python Standard Library (and many prior versions) states:

-----------
ContentHandler.characters(content) -- The Parser will call this method to report each chunk of character data.  SAX parsers may return all contiguous character data in a single chunk, or they may split it into several chunks...
-----------

If it happens that the content is delivered in two chunks instead of one, the characters() method shown above overwrites the first part of the text with the second part, and some content seems lost.  This completely explains the observed behavior.  

EXPECTED BEHAVIOR (or not)

Even though the behavior is unspecified, users can have certain expectations about what a reasonable parser should do.  Among these:

  -- EFFICIENCY: the parser should do simple things simply, and complicated things as simply as possible
  -- CONSISTENCY: the parser behavior should be repeatable and dependable

The design can be considered "poor" if thorough testing cannot identify what the actual behaviors are going to be, because those behaviors are rare and unpredictable.

The obvious "simple thing," from the user perspective, is that the parser should return each tiny text string as one tiny text chunk.  In fact, this is precisely what it does... 99.999% of the time.  But then, suddenly, it doesn't.  

One hypothesis is that when the parsing scan of raw input text reaches the end of a large internal text buffer, it is easier from the implementer's perspective to flush any text remaining in the old buffer prior to fetching a new one, even if that produces a fragmented chunk with only a couple of characters.  

IMPROVEMENTS REQUIRED

Review the code to determine whether the text buffer scenario is in fact the primary cause of inconsistent behavior. Modify the data handling to defer delivery of content fragments that are small, carrying over a small amount of previously scanned text so that small contiguous text chunks are recombined rather than reported as multiple fragments. If the length of the content text to carry over is greater than some configurable xml.sax.handler.ContiguousChunkLength, the parser can go ahead and deliver it as a fragment.  

DOCUMENTING THE IMPROVEMENTS 

Strictly speaking:  none required.  Undefined behaviors are undefined, whether consistent or otherwise.  But after the improvements are implemented, it would be helpful to modify documentation to expose the new performance guarantees, making users more aware of the possible hazards.  For example, a new description in the "xml.sax.handler" page might read as follows: 

-----------
ContentHandler.characters(content) -- The Parser will call this method to report chunks of character data.  In general, character data may be reported as a single chunk or as sequence of chunks; but character data sequences with fewer than  xml.sax.handler.ContiguousChunkLength characters, when uninterrupted any other xml.sax.handler.ContentHandler event, are guaranteed to be delivered as a single chunk...  
-----------

----------
components: XML
messages: 389108
nosy: ridgerat1611
priority: normal
severity: normal
status: open
title: Modify SAX/expat parsing to avoid fragmentation of already-tiny content chunks
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43560>
_______________________________________

From report at bugs.python.org  Fri Mar 19 14:40:01 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 19 Mar 2021 18:40:01 +0000
Subject: [issue43559] ctypes: Heap Pointer is damaged between C and Python
In-Reply-To: <1616177973.2.0.159103598259.issue43559@roundup.psfhosted.org>
Message-ID: <1616179201.37.0.298404868595.issue43559@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Are you using a 64-bit version of python? What is sys.maxsize?

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43559>
_______________________________________

From report at bugs.python.org  Fri Mar 19 14:47:37 2021
From: report at bugs.python.org (=?utf-8?q?Canberk_S=C3=B6nmez?=)
Date: Fri, 19 Mar 2021 18:47:37 +0000
Subject: [issue43559] ctypes: Heap Pointer is damaged between C and Python
In-Reply-To: <1616177973.2.0.159103598259.issue43559@roundup.psfhosted.org>
Message-ID: <1616179657.93.0.439144983252.issue43559@roundup.psfhosted.org>


Canberk S?nmez <canberk.sonmez.409 at gmail.com> added the comment:

Alright, I solved the problem. It was simply a typo: "restypes" instead of "res_types". It didn't cause a problem in Python 3.6 but obviously, something was changed. A nice error message might be nice when setting these attributes.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43559>
_______________________________________

From report at bugs.python.org  Fri Mar 19 14:52:35 2021
From: report at bugs.python.org (Larry Trammell)
Date: Fri, 19 Mar 2021 18:52:35 +0000
Subject: [issue43561] Modify XML parsing library descriptions to forewarn of
 content loss hazard
Message-ID: <1616179955.42.0.129876890529.issue43561@roundup.psfhosted.org>


New submission from Larry Trammell <ridgerat at nwi.net>:

With reference to improvement issue 43560 :

If those improvements remain unimplemented, or are demoted to "don't fix", users are left in the tricky situation where XML parsing applications can fail, apparently "losing content" in a rare and unpredictable manner.  It would be useful to patch the documentation to give users fair warning of this hazard. 

For example: the "xml.sax.handler" page in the Python 3.9.2 Documentation for the Python Standard Library (and many prior versions) currently states:

-----------
ContentHandler.characters(content) -- The Parser will call this method to report each chunk of character data.  SAX parsers may return all contiguous character data in a single chunk, or they may split it into several chunks...
-----------
 
The modified documentation would read something like the following:

-----------
ContentHandler.characters(content) -- The Parser will call this method to report each chunk of character data.  SAX parsers may return all contiguous character data in a single chunk, or they may split it into several chunks... To avoid a situation in which one small content fragment unexpectedly overwrites another one, it is essential for the characters() method to collect content by appending, rather than by assignment.
-----------

To give a concrete example, suppose that a Python programming site recommends the following coding to preserve a small text chunk bracketed by "<p>" tags: 

   # Note the name attribute of the current tag group
   def element_handler(self, tagname, attrs) :
       self.CurrentTag = tagname      

   # Record the content from each "p" tag when encountered
   def characters(self, content):
       if self.CurrentTag == "p" :
           self.name = content

Even though that coding could be expected to work most of the time, it is exposed to the hazard that an unanticipated sequence of calls to the characters() function would overwrite data.

Instead, the coding should look something like this.

   # Note the name attribute of the current tag group
   def element_handler(self, tagname, attrs) :
       self.CurrentTag = tagname 
       self.name = ""     

   # Accumulate the content from each "p" tag when encountered
   def characters(self, content):
       if self.CurrentTag == "p":
           self.name.append(content)

----------
assignee: docs at python
components: Documentation
messages: 389111
nosy: docs at python, ridgerat1611
priority: normal
severity: normal
status: open
title: Modify XML parsing library descriptions to forewarn of content loss hazard
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43561>
_______________________________________

From report at bugs.python.org  Fri Mar 19 14:56:06 2021
From: report at bugs.python.org (Larry Trammell)
Date: Fri, 19 Mar 2021 18:56:06 +0000
Subject: [issue43483] Loss of content in simple (but oversize) SAX parsing
In-Reply-To: <1615599352.35.0.560655392831.issue43483@roundup.psfhosted.org>
Message-ID: <1616180166.56.0.0595744081553.issue43483@roundup.psfhosted.org>


Larry Trammell <ridgerat at nwi.net> added the comment:

Check out issues 

43560 (an enhancement issue to improve handling of small XML content chunks)

43561 (a documentation issue to give users warning about the hazard in the interim before the changes are implemented)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43483>
_______________________________________

From report at bugs.python.org  Fri Mar 19 15:31:33 2021
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Mar 2021 19:31:33 +0000
Subject: [issue43484] we can create valid datetime objects that become invalid
 if the timezone is changed
In-Reply-To: <1615606212.76.0.00672395304579.issue43484@roundup.psfhosted.org>
Message-ID: <1616182293.03.0.391443878144.issue43484@roundup.psfhosted.org>


Change by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions:  -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43484>
_______________________________________

From report at bugs.python.org  Fri Mar 19 16:57:27 2021
From: report at bugs.python.org (Carl Meyer)
Date: Fri, 19 Mar 2021 20:57:27 +0000
Subject: [issue43562] test_ssl.NetworkedTests.test_timeout_connect_ex fails if
 network is unreachable
Message-ID: <1616187447.7.0.603298479381.issue43562@roundup.psfhosted.org>


New submission from Carl Meyer <carl at oddbird.net>:

In general it seems the CPython test suite takes care to not fail if the network is unreachable, but `test_timeout_connect_ex` fails because the result code of the connection is checked without any exception being raised that would reach `support.transient_internet`.

----------
components: Tests
messages: 389113
nosy: carljm
priority: normal
severity: normal
status: open
title: test_ssl.NetworkedTests.test_timeout_connect_ex fails if network is unreachable
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43562>
_______________________________________

From report at bugs.python.org  Fri Mar 19 16:57:57 2021
From: report at bugs.python.org (Vladimir Matveev)
Date: Fri, 19 Mar 2021 20:57:57 +0000
Subject: [issue43563] Use dedicated opcodes to speed up calls/attribute
 lookups with super() as receiver
Message-ID: <1616187477.95.0.162642980766.issue43563@roundup.psfhosted.org>


New submission from Vladimir Matveev <desco.by at gmail.com>:

Calling methods and lookup up attributes when receiver is `super()` has extra cost comparing to regular attribute lookup. It mainly comes from the need to allocate and initialize the instance of the `super` which for zero argument case also include peeking into frame/code object for the `__class__` cell and first argument. In addition because `PySuper_Type` has custom implementation of tp_getattro - `_PyObject_GetMethod` would always return bound method. 
```
import timeit

setup = """
class A:
    def f(self): pass
class B(A):
    def f(self): super().f()
    def g(self): A.f(self)
b = B()
"""
print(timeit.timeit("b.f()", setup=setup, number=20000000))
print(timeit.timeit("b.g()", setup=setup, number=20000000))

7.329449548968114
3.892987059080042
```
 
One option to improve it could be to make compiler/interpreter aware of super calls so they can be treated specially. Attached patch introduces two new opcodes LOAD_METHOD_SUPER and LOAD_ATTR_SUPER that are intended to be counterparts for LOAD_METHOD and LOAD_ATTR for cases when receiver is super with either zero or two arguments.

Immediate argument for both LOAD_METHOD_SUPER and LOAD_ATTR_SUPER is a pair that consist of:
 0: index of method/attribute in co_names
 1: Py_True if super was originally called with 0 arguments and Py_False otherwise.

Both LOAD_METHOD_SUPER and LOAD_ATTR_SUPER expect 3 elements on the stack:
TOS3: global_super
TOS2: type
TOS1: self/cls

Result of LOAD_METHOD_SUPER is the same as LOAD_METHOD.
Result of LOAD_ATTR_SUPER is the same as LOAD_ATTR

In runtime both LOAD_METHOD_SUPER and LOAD_ATTR_SUPER will check if `global_super` is `PySuper_Type` to handle situations when `super` is patched. If `global_super` is `PySuper_Type` then it can use dedicated routine to perform the lookup for provided `__class__` and `cls/self` without allocating new `super` instance. If `global_super` is different from `PySuper_Type` then runtime will fallback to the original logic using `global_super` and original number of arguments that was captured in immediate.

Benchmark results with patch:
4.381768501014449
3.9492998640052974

----------
components: Interpreter Core
messages: 389114
nosy: v2m
priority: normal
severity: normal
status: open
title: Use dedicated opcodes to speed up calls/attribute lookups with super() as receiver
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43563>
_______________________________________

From report at bugs.python.org  Fri Mar 19 16:59:46 2021
From: report at bugs.python.org (Vladimir Matveev)
Date: Fri, 19 Mar 2021 20:59:46 +0000
Subject: [issue43563] Use dedicated opcodes to speed up calls/attribute
 lookups with super() as receiver
In-Reply-To: <1616187477.95.0.162642980766.issue43563@roundup.psfhosted.org>
Message-ID: <1616187586.92.0.0173022288069.issue43563@roundup.psfhosted.org>


Change by Vladimir Matveev <desco.by at gmail.com>:


----------
keywords: +patch
pull_requests: +23696
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24936

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43563>
_______________________________________

From report at bugs.python.org  Fri Mar 19 17:01:36 2021
From: report at bugs.python.org (Carl Meyer)
Date: Fri, 19 Mar 2021 21:01:36 +0000
Subject: [issue43562] test_ssl.NetworkedTests.test_timeout_connect_ex fails if
 network is unreachable
In-Reply-To: <1616187447.7.0.603298479381.issue43562@roundup.psfhosted.org>
Message-ID: <1616187696.98.0.146849234989.issue43562@roundup.psfhosted.org>


Change by Carl Meyer <carl at oddbird.net>:


----------
keywords: +patch
pull_requests: +23697
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24937

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43562>
_______________________________________

From report at bugs.python.org  Fri Mar 19 17:10:20 2021
From: report at bugs.python.org (Batuhan Taskaya)
Date: Fri, 19 Mar 2021 21:10:20 +0000
Subject: [issue43563] Use dedicated opcodes to speed up calls/attribute
 lookups with super() as receiver
In-Reply-To: <1616187477.95.0.162642980766.issue43563@roundup.psfhosted.org>
Message-ID: <1616188220.37.0.300346910396.issue43563@roundup.psfhosted.org>


Change by Batuhan Taskaya <isidentical at gmail.com>:


----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43563>
_______________________________________

From report at bugs.python.org  Fri Mar 19 17:21:09 2021
From: report at bugs.python.org (Carl Meyer)
Date: Fri, 19 Mar 2021 21:21:09 +0000
Subject: [issue43564] some tests in test_urllib2net fail instead of skipping
 on unreachable network
Message-ID: <1616188869.43.0.436044106244.issue43564@roundup.psfhosted.org>


New submission from Carl Meyer <carl at oddbird.net>:

In general it seems the CPython test suite takes care to skip instead of failing networked tests when the network is unavailable (c.f. `support.transient_internet` test helper).

In this case of the 5 FTP tests in `test_urllib2net` (that is, `test_ftp`, `test_ftp_basic`, `test_ftp_default_timeout`, `test_ftp_no_timeout`, and `test_ftp_timeout`), even though they use `support_transient_internet`, they still fail if the network is unavailable.

The reason is that they make calls which end up raising an exception in the form `URLError("ftp error: OSError(101, 'Network is unreachable')"` -- the original OSError is flattened into the exception string message, but is otherwise not in the exception args. This means that `transient_network` does not detect it as a suppressable exception.

It seems like many uses of `URLError` in urllib pass the original `OSError` directly to `URLError.__init__()`, which means it ends up in `args` and the unwrapping code in `transient_internet` is able to find the original `OSError`. But the ftp code instead directly interpolates the `OSError` into a new message string.

----------
components: Tests
messages: 389115
nosy: carljm
priority: normal
severity: normal
status: open
title: some tests in test_urllib2net fail instead of skipping on unreachable network
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43564>
_______________________________________

From report at bugs.python.org  Fri Mar 19 17:21:16 2021
From: report at bugs.python.org (Carl Meyer)
Date: Fri, 19 Mar 2021 21:21:16 +0000
Subject: [issue43564] ftp tests in test_urllib2net fail instead of skipping on
 unreachable network
In-Reply-To: <1616188869.43.0.436044106244.issue43564@roundup.psfhosted.org>
Message-ID: <1616188876.74.0.764409858735.issue43564@roundup.psfhosted.org>


Change by Carl Meyer <carl at oddbird.net>:


----------
title: some tests in test_urllib2net fail instead of skipping on unreachable network -> ftp tests in test_urllib2net fail instead of skipping on unreachable network

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43564>
_______________________________________

From report at bugs.python.org  Fri Mar 19 17:26:52 2021
From: report at bugs.python.org (Carl Meyer)
Date: Fri, 19 Mar 2021 21:26:52 +0000
Subject: [issue43564] ftp tests in test_urllib2net fail instead of skipping on
 unreachable network
In-Reply-To: <1616188869.43.0.436044106244.issue43564@roundup.psfhosted.org>
Message-ID: <1616189212.52.0.823186280432.issue43564@roundup.psfhosted.org>


Change by Carl Meyer <carl at oddbird.net>:


----------
keywords: +patch
pull_requests: +23699
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24938

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43564>
_______________________________________

From report at bugs.python.org  Fri Mar 19 17:28:09 2021
From: report at bugs.python.org (Carl Meyer)
Date: Fri, 19 Mar 2021 21:28:09 +0000
Subject: [issue43564] ftp tests in test_urllib2net fail instead of skipping on
 unreachable network
In-Reply-To: <1616188869.43.0.436044106244.issue43564@roundup.psfhosted.org>
Message-ID: <1616189289.07.0.327041145648.issue43564@roundup.psfhosted.org>


Carl Meyer <carl at oddbird.net> added the comment:

Created a PR that fixes this by being more consistent in how urllib wraps network errors. If there are backward-compatibility concerns with this change, another option could be some really ugly regex-matching code in `test.support.transient_internet`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43564>
_______________________________________

From report at bugs.python.org  Fri Mar 19 17:38:05 2021
From: report at bugs.python.org (Steve Dower)
Date: Fri, 19 Mar 2021 21:38:05 +0000
Subject: [issue43550] pip.exe is missing from the NuGet package
In-Reply-To: <1616133185.95.0.11826827312.issue43550@roundup.psfhosted.org>
Message-ID: <1616189885.12.0.61896054455.issue43550@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Unfortunately not, because we don't know where it will be installed to, and that executable embeds the full path to its matching python.exe.

I suggest running "python.exe -m pip" instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43550>
_______________________________________

From report at bugs.python.org  Fri Mar 19 18:13:13 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 19 Mar 2021 22:13:13 +0000
Subject: [issue43552] Add locale.get_locale_encoding() and
 locale.get_current_locale_encoding()
In-Reply-To: <1616145433.55.0.350148222552.issue43552@roundup.psfhosted.org>
Message-ID: <1616191993.74.0.348928927305.issue43552@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> But it is not what I want for now. I want to ignore UTF-8 mode 
> when `encoding="locale"` is specified.
> This is almost "only in Windows" issue, and users can use 
> `encoding="mbcs"` in Windows-only script.

Why is it being specified that the current LC_CTYPE encoding should be ignored in Windows when a "locale" encoding is requested? Cross-platform C code would use mbstowcs() and wcstombs(), with the current LC_CTYPE encoding. That's Latin-1 in the initial "C" locale and defaults to GetACP() if setlocale(LC_CTYPE, "") is called, but otherwise it's whatever locale is requested by the program and supported by the system (all Windows installations support pretty much every locale).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43552>
_______________________________________

From report at bugs.python.org  Fri Mar 19 18:18:51 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 19 Mar 2021 22:18:51 +0000
Subject: [issue43550] pip.exe is missing from the NuGet package
In-Reply-To: <1616133185.95.0.11826827312.issue43550@roundup.psfhosted.org>
Message-ID: <1616192331.91.0.562481460119.issue43550@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

I suppose if you really need a plain `pip` command, you could reinstall with `python.exe -m pip install --force-reinstall pip`.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43550>
_______________________________________

From report at bugs.python.org  Fri Mar 19 18:38:53 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 19 Mar 2021 22:38:53 +0000
Subject: [issue43481] PyEval_EvalCode() namespace issue not observed in Python
 2.7.
In-Reply-To: <1615585477.01.0.106665214672.issue43481@roundup.psfhosted.org>
Message-ID: <1616193533.23.0.0813426742333.issue43481@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I cannot reproduce in Python with either 3.8 or 3.10.  (Please try with latter if you can.)  I thought the issue might possibly be passing two different dicts, which results in the code being executed as if in a class statement, but it is not.  

code = '''
c=[1,2,3,4]
d={'list': [c[i] for i in range(len(c))]}
print(d)
'''
bcode = compile(code, '', 'exec')
gdict = globals()
ldict = {}
exec(bcode, gdict, gdict)
exec(bcode, gdict, ldict)
class C:
    c=[1,2,3,4]
    d={'list': [c[i] for i in range(len(c))]}
    print(d)

prints {'list': [1, 2, 3, 4]} 3 times.  Using 'eval' instead of 'exec' gives the same.  I presume that code compiled with 'exec' is 'exec'ed even if use eval.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43481>
_______________________________________

From report at bugs.python.org  Fri Mar 19 18:46:00 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 19 Mar 2021 22:46:00 +0000
Subject: [issue43484] valid datetimes can become invalid if the timezone is
 changed
In-Reply-To: <1615606212.76.0.00672395304579.issue43484@roundup.psfhosted.org>
Message-ID: <1616193960.5.0.728537721693.issue43484@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This tracker is for patching CPython, including the docs.  Questions for discussion should be posted to python-list.  Perhaps such a discussion would lead to a concrete change proposal.  In the meanwhile, I think that this should be closed as 'not a bug' (as you admit).

----------
nosy: +terry.reedy
title: we can create valid datetime objects that become invalid if the timezone is changed -> valid datetimes can become invalid if the timezone is changed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43484>
_______________________________________

From report at bugs.python.org  Fri Mar 19 18:47:31 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 19 Mar 2021 22:47:31 +0000
Subject: [issue43487] Rename __unicode__ methods to __str__ in 2to3 conversion
In-Reply-To: <1615652086.71.0.102921679786.issue43487@roundup.psfhosted.org>
Message-ID: <1616194051.08.0.164505805362.issue43487@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43487>
_______________________________________

From report at bugs.python.org  Fri Mar 19 18:50:16 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 19 Mar 2021 22:50:16 +0000
Subject: [issue43555] Location of SyntaxError with new parser missing (after
 continuation character)
In-Reply-To: <1616152732.25.0.508578313833.issue43555@roundup.psfhosted.org>
Message-ID: <1616194216.32.0.779758193898.issue43555@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +23700
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24939

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43555>
_______________________________________

From report at bugs.python.org  Fri Mar 19 18:59:53 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 19 Mar 2021 22:59:53 +0000
Subject: [issue43490] IDLE freezes at random
In-Reply-To: <1615684694.01.0.00673865405837.issue43490@roundup.psfhosted.org>
Message-ID: <1616194793.99.0.988457464828.issue43490@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

How are you starting IDLE? How are you using the turtle module?  What does "can't get the window open" mean exactly?  Does the menu item Shell => Restart Shell work?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43490>
_______________________________________

From report at bugs.python.org  Fri Mar 19 19:02:04 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 19 Mar 2021 23:02:04 +0000
Subject: [issue43484] valid datetimes can become invalid if the timezone is
 changed
In-Reply-To: <1615606212.76.0.00672395304579.issue43484@roundup.psfhosted.org>
Message-ID: <1616194924.88.0.0847044859941.issue43484@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

That it allows creating the datetime instance looks like a bug to me, i.e. a time before 0001-01-01 00:00 UTC is invalid. What am I misunderstanding?

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43484>
_______________________________________

From report at bugs.python.org  Fri Mar 19 19:11:04 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 19 Mar 2021 23:11:04 +0000
Subject: [issue43494] Minor changes to Objects/lnotab_notes.txt
In-Reply-To: <1615755405.52.0.84657941654.issue43494@roundup.psfhosted.org>
Message-ID: <1616195464.61.0.873795959942.issue43494@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 7cb033c423b65def1632d6c3c747111543b342a2 by Skip Montanaro in branch 'master':
bpo-43494: Make some minor changes to lnotab notes (GH-24861)
https://github.com/python/cpython/commit/7cb033c423b65def1632d6c3c747111543b342a2


----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43494>
_______________________________________

From report at bugs.python.org  Fri Mar 19 19:27:29 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 19 Mar 2021 23:27:29 +0000
Subject: [issue43494] Minor changes to Objects/lnotab_notes.txt
In-Reply-To: <1615755405.52.0.84657941654.issue43494@roundup.psfhosted.org>
Message-ID: <1616196449.29.0.802216855622.issue43494@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Skip, if you do not make a backport, you can close this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43494>
_______________________________________

From report at bugs.python.org  Fri Mar 19 19:29:39 2021
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 19 Mar 2021 23:29:39 +0000
Subject: [issue43494] Minor changes to Objects/lnotab_notes.txt
In-Reply-To: <1615755405.52.0.84657941654.issue43494@roundup.psfhosted.org>
Message-ID: <1616196579.73.0.203479323529.issue43494@roundup.psfhosted.org>


Skip Montanaro <skip.montanaro at gmail.com> added the comment:

Closing, per Terry's comment.

----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43494>
_______________________________________

From report at bugs.python.org  Fri Mar 19 19:31:45 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 19 Mar 2021 23:31:45 +0000
Subject: [issue43504] Site linked in docs, effbot.org, down
In-Reply-To: <1615849580.97.0.243341860557.issue43504@roundup.psfhosted.org>
Message-ID: <1616196705.18.0.673862333194.issue43504@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
stage:  -> needs patch
title: effbot.org down -> Site linked in docs, effbot.org, down
versions: +Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43504>
_______________________________________

From report at bugs.python.org  Fri Mar 19 20:05:32 2021
From: report at bugs.python.org (Paul Ganssle)
Date: Sat, 20 Mar 2021 00:05:32 +0000
Subject: [issue43484] valid datetimes can become invalid if the timezone is
 changed
In-Reply-To: <1615606212.76.0.00672395304579.issue43484@roundup.psfhosted.org>
Message-ID: <1616198732.12.0.574286590999.issue43484@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

> That it allows creating the datetime instance looks like a bug to me, i.e. a time before 0001-01-01 00:00 UTC is invalid. What am I misunderstanding?

`datetime.datetime(1, 1, 1, tzinfo=timezone(timedelta(hours=1)))` is a valid datetime, it's just that it cannot be converted to all other timestamps, because in some time zones, the same absolute time is out of datetime's range.

`datetime.datetime` is a representation of an abstract datetime, and it can also be annotated with a time zone to basically tag the civil time with a function for converting it into other representations of the same *absolute* time. The range of valid `datetime.datetime` objects is based entirely on the na?ve portion of the datetime, and has nothing to do with the absolute time. So this is indeed a natural consequence of the chosen design.

If we wanted to change things, it would cause a number of problems, and the cure would be much worse than the "disease". For one thing, accessing UTC offsets is done lazily, so `.utcoffset()` is not currently called during `datetime` creation. The datetime documentation lays out that this is consistent with the raison d'?tre of `datetime`: "While date and time arithmetic is supported, the focus of the implementation is on efficient attribute extraction for output formatting and manipulation." In order to determine whether a given `datetime` can always be converted to an equivalent datetime in any time zone, we'd need to actively determine its UTC offset, which would be a major performance regression in creating aware datetimes. We could avoid this performance regression by only doing the `.utcoffset()` check when the datetime is within 2 days of `MINYEAR` or `MAXYEAR`, but while this would be a more minor performance regression, it would also add new edge cases where `.utcoffset()` is sometimes called during the constructor and sometimes not, which is not ideal. Not to mention if we were to ever open up the allowed return values for `.utcoffset()` the logic might get hairier (depending on the nature of the allowed values).

Another issue with "fixing" this is that it would take currently-valid datetimes and turn them into invalid datetimes, which violates backwards compatibility. I imagine in most cases this is only done as part of test suites, since TZ-aware datetimes near 0 and 10,000 CE are anachronistic and not likely to be of much instrumental value, but the same can be said of these potentially "invalid" dates in the first place.

Additionally, even worse is that even na?ve datetimes can be converted to UTC or other time zones, and if we want to add a new constraint that `some_datetime.astimezone(some_timezone)` must always work, then you wouldn't even be able to *construct* `datetime.MINYEAR` or `datetime.MAXYEAR`, since `datetime.MINYEAR.astimezone(timezone(timedelta(hours=-24)))` would fail everywhere, and worse, the minimum datetime value you could construct would depend on your system locale! Again, the alternative would be to make an exception for na?ve datetimes, but given that this change is of dubious value to start with, I don't think it is worth it.

> So I'm pretty sure this is "not a bug" but it's a bit of a problem and I have a user suggesting the "security vulnerability" bell on this one, and to be honest I don't even know what any library would do to "prevent" this.

I don't really know why it would be a "security vulnerability", but presumably a library could either convert their datetimes to UTC as soon as they get them from the user if they want to use them as UTC in the future, or they could simply refuse to accept any datetimes outside the range `datetime.datetime.MINYEAR + timedelta(hours=48) < dt.replace(tzinfo=None) < datetime.datetime.MAXYEAR - timedelta(hours=48)`, or if the concern is only about UTC, then refuse datetimes outside the range `datetime.MINYEAR.replace(tzinfo=timezone.utc) < dt < datetime.MAXYEAR.replace(tzinfo=timezone.utc)`.

> Why's this a security problem?   ish?    because PostgreSQL has a data type "TIMESTAMP WITH TIMEZONE" and if you take said date and INSERT it into your database, then SELECT it back using any Python DBAPI that returns datetime() objects like psycopg2, if your server is in a timezone with zero or negative offset compared to the given date, you get an error.  So the mischievous user can create that datetime for some reason and now they've broken your website which can't SELECT that table anymore without crashing.

Can you clarify why this crashes? Is it because it always returns the datetime value in UTC?

> So, suppose you maintain the database library that helps people send data in and out of psycopg2.    We have, the end user's application, we have the database abstraction library, we have the psycopg2 driver, we have Python's datetime() object with MIN_YEAR, and finally we have PostgreSQL with the TIMEZONE WITH TIMESTAMP datatype that I've never liked.
>
>Of those five roles, whose bug is this?    I'd like to say it's the end user for letting untrusted input that can put unusual timezones and timestamps in their system.   But at the same time it's a little weird Python is letting me create this date that lacks the ability to convert into UTC.     thanks for reading!

It sounds like the fundamental issue here is that PostgreSQL supports a different range of datetimes than Python does, regardless of the question of whether any Python datetime can be converted into another timezone. It sounds to me like that's a mismatch between PostgreSQL's data type and Python's data type, and I'm not sure how they are squared up now. If the database abstraction layer is making the guarantee that anything you can INSERT into the database can be SELECTed back out (meaning that it will artificially restrict the range of valid values to the union of those supported by Postgres and Python), then if the abstraction layer allows you to choose what time zone applies when you read the values out, it should probably make sure that it doesn't write something in that can't be represented in another time zone.

If the abstraction layer's guarantee is that it can read out anything that can be stored in a postgres database, then I still think it might be the abstraction layer's bug, since apparently Postgres lets you store values that cannot be represented in all the supported time zones that you could read them out as ? the abstraction layer may need to use a different type (possibly a subclass) for "out-of-range" values.

I'll note that I don't actually understand the difference between "abstraction layer" and "psycopg2 driver", so I may be conflating those two, but at the end of the day I think one of those two is the right place to fix this. If there are good reasons for not fixing it in either of those two layers, then obviously the buck stops in the user's application ? though obviously it would be better to fix it lower in the stack, since it's difficult for users to keep track of minutia like this. I think it likely that neither CPython nor Postgres are the right levels of abstraction to fix it as, since neither one is in the business of making their datetime types compatible with one another (and each presumably has a thousand other integrations to also worry about).

Hopefully that's helpful information! Understandable if the answer is somewhat disappointing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43484>
_______________________________________

From report at bugs.python.org  Fri Mar 19 20:15:45 2021
From: report at bugs.python.org (mike bayer)
Date: Sat, 20 Mar 2021 00:15:45 +0000
Subject: [issue43484] valid datetimes can become invalid if the timezone is
 changed
In-Reply-To: <1615606212.76.0.00672395304579.issue43484@roundup.psfhosted.org>
Message-ID: <1616199345.35.0.0984241721447.issue43484@roundup.psfhosted.org>


mike bayer <mike_mp at zzzcomputing.com> added the comment:

> 
I don't really know why it would be a "security vulnerability", but presumably a library could either convert their datetimes to UTC as soon as they get them from the user if they want to use them as UTC in the future, or they could simply refuse to accept any datetimes outside the range `datetime.datetime.MINYEAR + timedelta(hours=48) < dt.replace(tzinfo=None) < datetime.datetime.MAXYEAR - timedelta(hours=48)`, 

this is absolutely correct, but I'm not sure if you're aware, there's kind of a whole subsection of the tech community that considers anything that a user might do without understanding all the consequences which could in any way allow untrusted input to affect things to be a "security risk".  In SQLAlchemy i had CVEs posted because we have a method called order_by() that accepted a string, and the notion was, someone will write a web app that takes an arbitrary string as input and send it there!  CVE!   For you and me that would of course be crazy as this is obviously part of the SQL string being sent to the database,  but this is a particular programming subculture that has the ability to create a lot of havoc by filling up the CVE system with "Security Vulnerabilities" based on what many of us consider obviously wrong.

> Can you clarify why this crashes? Is it because it always returns the datetime value in UTC?

it returns the datetime value in the default timezone set up for the server which could be UTC or a local timezone, but the idea is it's potentially different from the timezone that's been put in.

> I'll note that I don't actually understand the difference between "abstraction layer" and "psycopg2 driver", so I may be conflating those two, 

from my POV I have always thought PostgreSQLs' TIMESTAMP WITH TIMEZONE datatype is nuts, and that you should only be sending UTC timestamps to a database.   But people want to use PG's type and IMO they need to understand what they're doing.  thanks for the response.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43484>
_______________________________________

From report at bugs.python.org  Fri Mar 19 20:16:07 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 20 Mar 2021 00:16:07 +0000
Subject: [issue43518] textwrap.shorten does not always respect word boundaries
In-Reply-To: <1615911865.24.0.216349409983.issue43518@roundup.psfhosted.org>
Message-ID: <1616199367.91.0.433068143758.issue43518@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Verified in 3.10.0a6 that change is at 3 !s.  I agree that is is a bug relative to the doc.

The issue is that 'world!!!' is 8 chars, and by default, wrap splits that into 'w' and 'orld!!!' and add ' w' to 'hello'.
>>> sh('hello world!!!', width=7)
['hello w', 'orld!!!']

A solution is to not break long words.
>>> sh('hello world!!!', width=7, placeholder='', break_long_words=False)
'hello'

Then

>>> sh('hello!!!! world!!!', width=7, placeholder='', break_long_words=False)
''

versus

>>> sh('hello!!!! world!!!', width=7, placeholder='')
'hello!!'

The docstring and doc say "enough words are dropped from the end so that the remaining words plus the placeholder fit within width:".  Taking this literally, '' is correct.  So a fix would be to add "break_long_words=False" to options if break_long_words not in options.

Antoine, you last touched the shorten docstring.  Serhiy, you last touched its code.  What do you two think?

----------
nosy: +pitrou, serhiy.storchaka, terry.reedy
stage:  -> needs patch
versions: +Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43518>
_______________________________________

From report at bugs.python.org  Fri Mar 19 20:28:49 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 20 Mar 2021 00:28:49 +0000
Subject: [issue43484] valid datetimes can become invalid if the timezone is
 changed
In-Reply-To: <1615606212.76.0.00672395304579.issue43484@roundup.psfhosted.org>
Message-ID: <1616200129.36.0.141105933933.issue43484@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

Thank you for thoughtful and detailed answer, Paul.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43484>
_______________________________________

From report at bugs.python.org  Fri Mar 19 20:36:21 2021
From: report at bugs.python.org (Inada Naoki)
Date: Sat, 20 Mar 2021 00:36:21 +0000
Subject: [issue43552] Add locale.get_locale_encoding() and
 locale.get_current_locale_encoding()
In-Reply-To: <1616145433.55.0.350148222552.issue43552@roundup.psfhosted.org>
Message-ID: <1616200581.48.0.224428503508.issue43552@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

> Why is it being specified that the current LC_CTYPE encoding should be ignored in Windows when a "locale" encoding is requested?

Because `encoding="locale"` must be replacement of the current `encoding=None` (i.e. locale.getpreferredencoding(False).

`encoding=None` behavior will be changed if we change the default encoding or enable UTF-8 mode by default. So we are adding an explicit name to current behavior.

So It is not an option to assign other encoding. ?See PEP 597 for detail.

I know you are proposing to use CRT locale on Windows. If we change the `locale.getpreferredencoding(False)` to use CRT locale, `encoding="locale"` follow it.
But please discuss it in another issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43552>
_______________________________________

From report at bugs.python.org  Fri Mar 19 20:36:24 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 20 Mar 2021 00:36:24 +0000
Subject: [issue43520] Make Fraction(string) handle non-ascii slashes
In-Reply-To: <1615918144.03.0.939769511159.issue43520@roundup.psfhosted.org>
Message-ID: <1616200584.73.0.389391322175.issue43520@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I agree with Raymond, at least for now.  I would expect the string argument to Fraction to be quoted legal Python code.  Without a lot of thought and discussion leading to a change in python design with respect to unicode and operators, this limits  '/' to ascii '/'.

I believe that we accept non-ascii digits in at least some places, but operators are a different case.

----------
nosy: +terry.reedy
title: Fraction only handles regular slashes ("/") and fails with other similar slashes -> Make Fraction(string) handle non-ascii slashes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43520>
_______________________________________

From report at bugs.python.org  Fri Mar 19 20:43:08 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 20 Mar 2021 00:43:08 +0000
Subject: [issue43526] Programmatic management of BytesWarning doesn't work for
 native triggers.
In-Reply-To: <1615971785.71.0.488992120219.issue43526@roundup.psfhosted.org>
Message-ID: <1616200988.93.0.263222491639.issue43526@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.10 -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43526>
_______________________________________

From report at bugs.python.org  Fri Mar 19 21:10:53 2021
From: report at bugs.python.org (Max Bachmann)
Date: Sat, 20 Mar 2021 01:10:53 +0000
Subject: [issue43565] PyUnicode_KIND macro does not has specified return type
Message-ID: <1616202653.73.0.639291876959.issue43565@roundup.psfhosted.org>


New submission from Max Bachmann <kontakt at maxbachmann.de>:

The documentation stated, that the PyUnicode_KIND macro has the following interface:
- int PyUnicode_KIND(PyObject *o)
However it actually returns a value of the underlying type of the PyUnicode_Kind enum. This could be e.g. an unsigned int as well.

----------
components: C API
messages: 389133
nosy: maxbachmann
priority: normal
severity: normal
status: open
title: PyUnicode_KIND macro does not has specified return type
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43565>
_______________________________________

From report at bugs.python.org  Fri Mar 19 21:16:25 2021
From: report at bugs.python.org (Dino Viehland)
Date: Sat, 20 Mar 2021 01:16:25 +0000
Subject: [issue43452] Microoptimize PyType_Lookup for cache hits
In-Reply-To: <1615317677.24.0.232039554227.issue43452@roundup.psfhosted.org>
Message-ID: <1616202985.14.0.898497661194.issue43452@roundup.psfhosted.org>


Dino Viehland <dinoviehland at gmail.com> added the comment:

Setup a micro-benchmark, foo.c:

#define PY_SSIZE_T_CLEAN
#include <Python.h>
#include <string.h>
#include <stdlib.h>

int
main(int argc, char *argv[])
{
    wchar_t *program = Py_DecodeLocale(argv[0], NULL);
    if (program == NULL) {
        fprintf(stderr, "Fatal error: cannot decode argv[0]\n");
        exit(1);
    }
    Py_SetProgramName(program);  /* optional but recommended */
    Py_Initialize();
    PyObject *pName = PyUnicode_DecodeFSDefault("foo");
    if (pName == NULL) { printf("no foo\n"); PyErr_Print(); }
    PyObject *pModule = PyImport_Import(pName);
    if (pModule == NULL) { printf("no mod\n"); PyErr_Print(); return 0; }
    PyObject *cls = PyObject_GetAttrString(pModule, "C");
    if (cls == NULL) { printf("no cls\n"); }
    PyObject *fs[20];
    for(int i = 0; i<20; i++) {
         char buf[4];
         sprintf(buf, "f%d", i);
         fs[i] = PyUnicode_DecodeFSDefault(buf);
    }
    for(int i = 0; i<100000000; i++) {
         for(int j = 0; j<20; j++) {
             if(_PyType_Lookup(cls, fs[j])==NULL) {
		printf("Uh oh\n");
	     }
         }
    }

   if (Py_FinalizeEx() < 0) {
        exit(120);
    }
    PyMem_RawFree(program);
    return 0;
}


Lib/foo.py:
import time


class C:
    pass

for i in range(20):
    setattr(C, f"f{i}", lambda self: None)


obj hash: 0m6.222s
str hash: 0m6.327s
baseline: 0m6.784s

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43452>
_______________________________________

From report at bugs.python.org  Fri Mar 19 21:34:45 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 20 Mar 2021 01:34:45 +0000
Subject: [issue43535] Make str.join auto-convert inputs to strings.
In-Reply-To: <1616034546.27.0.0632217994438.issue43535@roundup.psfhosted.org>
Message-ID: <1616204085.32.0.968952811703.issue43535@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I am sympathetic to the 'hiding bugs' argument in general, but what bugs would this proposal hide?  What bugs does print hide by auto-converting non-strings to strings?

I recently had the same thought as Raymond's: "it would be nice if str.join converted inputs to strings when needed."

I have always known that print() is slower in IDLE than in a console.  A recent SO question https://stackoverflow.com/questions/66286367/why-is-my-function-faster-than-pythons-print-function-in-idle showed that it could be 20X slower and asked why?  It turns out that while

print(*values, sep=sep, end=end, file=file) # is equivalent to file.write(sep.join(map(str, values))+end)

print must be implemented as the C equivalent of something like

first=True
for val in values:
    if first:
        first = False
    else
        file.write(sep)
    file.write(str(value))
file.write(end)

When sys.stdout is a screen buffer, the multiple writes effectively implement a join.  But in IDLE, each write(s) results in a separate socket.send(s.encode) and socket.receive).decode + text.insert(s, tag).  I discovered that removing nearly all the overhead from the very slow example with sep.join and end.join made the example only trivially slower on IDLE (5%) than the standard REPL.  In #43283 I added the option of speedups using .join and .format to the IDLE doc, but this workaround would be much more usable if map(str, x) were not needed.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43535>
_______________________________________

From report at bugs.python.org  Fri Mar 19 21:37:15 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 20 Mar 2021 01:37:15 +0000
Subject: [issue43552] Add locale.get_locale_encoding() and
 locale.get_current_locale_encoding()
In-Reply-To: <1616145433.55.0.350148222552.issue43552@roundup.psfhosted.org>
Message-ID: <1616204235.41.0.203608660163.issue43552@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> But please discuss it in another issue.

What's returned by locale.get_locale_encoding() and locale.get_current_locale_encoding() is relevant to adding them as new functions and is a chance to implement this correctly in Windows. 

You're right that what open() does for encoding="locale" is a separate issue, with backwards compatibility problems. I think it was implemented badly and needlessly inconsistent with POSIX. But we may be stuck with the behavior considering scripts are within their rights, per documented behavior, to expect that calling setlocale(LC_CTYPE, locale_name) in Windows has no effect on the result of locale.getpreferredencoding(False), unlike POSIX generally, except for some platforms such as macOS and Android.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43552>
_______________________________________

From report at bugs.python.org  Fri Mar 19 21:55:14 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 20 Mar 2021 01:55:14 +0000
Subject: [issue43544] mimetype default list make a wrong guess for illustrator
 file
In-Reply-To: <1616082583.58.0.664742834021.issue43544@roundup.psfhosted.org>
Message-ID: <1616205314.3.0.476863516004.issue43544@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43544>
_______________________________________

From report at bugs.python.org  Fri Mar 19 22:06:32 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 20 Mar 2021 02:06:32 +0000
Subject: [issue24505] shutil.which wrong result on Windows
In-Reply-To: <1435183779.2.0.13075721906.issue24505@psf.upfronthosting.co.za>
Message-ID: <1616205992.7.0.0561656265963.issue24505@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

Regarding Toby's patch:

Probably _is_windows_nt_internal_command() isn't needed or desired. It's more of a command-line parsing issue, rather than a file-search issue. For example, CMD will search for an internal name if it's quoted in double quotes in the command line, such as `"dir" spam`, and where.exe doesn't reserve the names of CMD's internal functions. If it's kept, note that the following four names are missing from the nt_internal_commands list: 'BREAK', 'MKLINK', 'VERIFY', 'VOL'.

The patch also makes a couple incorrect assumptions, corrected as follows:

    * A filename with an extension will be found and executed 
      even if the extension is not in PATHEXT.
    * The PATHEXT extensions are tried even if a name already
      has an extension.

----------
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24505>
_______________________________________

From report at bugs.python.org  Fri Mar 19 22:13:46 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 20 Mar 2021 02:13:46 +0000
Subject: [issue37894] [win] shutil.which can not find the path if 'cmd'
 include directory path and not include extension name
In-Reply-To: <1566316777.4.0.882745227499.issue37894@roundup.psfhosted.org>
Message-ID: <1616206426.21.0.2682101382.issue37894@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> shutil.which wrong result on Windows

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37894>
_______________________________________

From report at bugs.python.org  Fri Mar 19 22:17:03 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 20 Mar 2021 02:17:03 +0000
Subject: [issue28188] os.putenv should support bytes arguments on Windows
In-Reply-To: <1474123387.93.0.730915025745.issue28188@psf.upfronthosting.co.za>
Message-ID: <1616206623.65.0.22733915186.issue28188@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

I thought this was a good idea at the time, but a core dev never took up the mantle in over 4 years, and no one else showed interest.

----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28188>
_______________________________________

From report at bugs.python.org  Fri Mar 19 22:24:48 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 20 Mar 2021 02:24:48 +0000
Subject: [issue33140] shutil.chown on Windows
In-Reply-To: <1522018536.28.0.467229070634.issue33140@psf.upfronthosting.co.za>
Message-ID: <1616207088.83.0.413830693625.issue33140@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

Apparently there's no one else interested in implementing shutil.chown() in Windows. Okay, but as long as that's the case, the definition should be skipped in Windows, which is an easy problem.

----------
components:  -IO
keywords: +easy
versions: +Python 3.10, Python 3.9 -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33140>
_______________________________________

From report at bugs.python.org  Fri Mar 19 22:26:15 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 20 Mar 2021 02:26:15 +0000
Subject: [issue33140] shutil.chown should not be defined in Windows
In-Reply-To: <1522018536.28.0.467229070634.issue33140@psf.upfronthosting.co.za>
Message-ID: <1616207175.14.0.537733446431.issue33140@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
title: shutil.chown on Windows -> shutil.chown should not be defined in Windows

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33140>
_______________________________________

From report at bugs.python.org  Fri Mar 19 22:32:58 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 20 Mar 2021 02:32:58 +0000
Subject: [issue28168] Use _winapi.WaitForMultipleObjects in Popen.wait()
In-Reply-To: <1473936169.85.0.779071092468.issue28168@psf.upfronthosting.co.za>
Message-ID: <1616207578.32.0.266739988004.issue28168@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

I'm no longer interested in solving the SIGINT event problem locally at the wait site. A common implementation of _Py_Sleep, _Py_WaitForSingleObject, and _Py_WaitForMultipleObjects is needed. _winapi.WaitForSingleObject would call _Py_WaitForSingleObject and automatically support the SIGINT event on the main thread.

----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28168>
_______________________________________

From report at bugs.python.org  Fri Mar 19 23:12:23 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 20 Mar 2021 03:12:23 +0000
Subject: [issue43520] Make Fraction(string) handle non-ascii slashes
In-Reply-To: <1615918144.03.0.939769511159.issue43520@roundup.psfhosted.org>
Message-ID: <1616209943.03.0.763555658634.issue43520@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Dr Racket supports fraction conversions but insists on a forward slash just like we do.

Welcome to DrRacket, version 7.9.0.17--2020-12-24(f6b7f93/a) [cs].
Language: racket, with debugging; memory limit: 128 MB.
> (/ 1 2)
1/2
> (string->number "3/5")
3/5
> (string->number "2?3")
#f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43520>
_______________________________________

From report at bugs.python.org  Fri Mar 19 23:49:58 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 20 Mar 2021 03:49:58 +0000
Subject: [issue26350] [Windows] signal.signal and os.kill doc should better
 explain what is supported
In-Reply-To: <1455285703.05.0.44078516142.issue26350@psf.upfronthosting.co.za>
Message-ID: <1616212198.41.0.5779542429.issue26350@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

The signal.signal() docs should explain that only SIGINT and SIGBREAK can be signaled from another process, and only if the current process is a console application. A link to os.kill() could be added, which should explain their use as signals in relation to console control events. Also, setting a handler for SIGABRT, SIGFPE, SIGILL, and SIGSEGV should be discouraged in the documentation because they are not compatible with how Python handles signals by tripping a flag for deferred processing on the main thread.

The design of os.kill() in Windows has some unfortunate mistakes, but it needs to be better documented at least. It should explain that the pid value, when used with CTRL_C_EVENT and CTRL_BREAK_EVENT, is a process-group ID, not a process ID. It should explain that CTRL_C_EVENT will be ignored by a process in the target group if the process calls SetConsoleCtrlHandler(NULL, TRUE), or if it's started with Ctrl+C ignored either due to inheritance or due to being created in a new process group. It should explain that these console control events get mapped to the C signals SIGINT and SIGBREAK. 

Also the line "[t]he Windows version of kill() additionally takes process handles to be killed" needs to removed. os.kill() has never accepted handles in addition to PIDs. Implementing that reliably would require an additional parameter.

---

Ideally, the code path in os.kill() that generates a console control event would have been reserved for a negative PID value (i.e. a process group ID), with -1 reserved to send the event to all processes in the console session (i.e. console process group 0). Also, in this case, os.kill() would use SIGINT and SIGBREAK instead of WinAPI CTRL_C_EVENT and CTRL_BREAK_EVENT. Such a design would have conformed much better with POSIX kill().

----------
components: +Extension Modules, Windows
nosy: +eric.araujo, ezio.melotti, mdk, paul.moore, steve.dower, tim.golden, willingc, zach.ware
stage:  -> needs patch
title: Windows: signal doc should state certains signals can't be registered -> [Windows] signal.signal and os.kill doc should better explain what is supported
type:  -> enhancement
versions: +Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26350>
_______________________________________

From report at bugs.python.org  Fri Mar 19 23:51:30 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 20 Mar 2021 03:51:30 +0000
Subject: [issue23948] Deprecate os.kill() on Windows
In-Reply-To: <1429025061.32.0.415018485708.issue23948@psf.upfronthosting.co.za>
Message-ID: <1616212290.5.0.77041492793.issue23948@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
Removed message: https://bugs.python.org/msg256166

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23948>
_______________________________________

From report at bugs.python.org  Sat Mar 20 00:05:29 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 20 Mar 2021 04:05:29 +0000
Subject: [issue23948] Deprecate os.kill() on Windows
In-Reply-To: <1429025061.32.0.415018485708.issue23948@psf.upfronthosting.co.za>
Message-ID: <1616213129.5.0.393317499971.issue23948@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

I'd prefer to change os.kill() to take the code path that generates a console control event only when the pid value is negative (i.e. a process group ID), with -1 reserved to send the event to all processes in the console session (i.e. console process group 0). Also, in this case, I'd map SIGINT and SIGBREAK to CTRL_C_EVENT and CTRL_BREAK_EVENT, instead of directly using the Windows API constants. Such a design conforms better with POSIX kill() [1], and it cleanly separates the GenerateConsoleCtrlEvent() and TerminateProcess() usage.

The older usage with kill(non_negative_pid, console_control_event) could be retained by checking for the enum instances signal.CTRL_C_EVENT and signal.CTRL_BREAK_EVENT by object ID instead of by value.

---

[1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/kill.html

----------
components: +Extension Modules
nosy: +paul.moore
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23948>
_______________________________________

From report at bugs.python.org  Sat Mar 20 01:31:39 2021
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Sat, 20 Mar 2021 05:31:39 +0000
Subject: [issue43535] Make str.join auto-convert inputs to strings.
In-Reply-To: <1616034546.27.0.0632217994438.issue43535@roundup.psfhosted.org>
Message-ID: <1616218299.83.0.765773601988.issue43535@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

Matthew: can you then answer the same question I asked Serhiy?

The example usually given when advocating strong typing is whether 2 + '3' should be '23' or 5. Our uneasiness with it doesn't stem from coercions between int and str, but from the fact that + has two distinct meanings.

Of course, binary operators are always like that, even if it's not obvious, since there's always a tension created by difference of types of the left and right operand. Even if it's obvious that 2 - '3' should coerce the second argument to int since str doesn't define -, this can't be a general rule because e.g. set does (what about 2 - {3}?).

But method calls (and many protocols) are _not_ of that kind. As I said above, my_set ^ some_list makes us uneasy (even though list doesn't implement ^), but my_set.symmetric_difference(some_list) doesn't, simply because there is no ambiguity: there is only one thing we could have meant.

The same can be said about "for x in not_an_iterator", or "if not_a_bool".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43535>
_______________________________________

From report at bugs.python.org  Sat Mar 20 02:19:44 2021
From: report at bugs.python.org (Chris Wilson)
Date: Sat, 20 Mar 2021 06:19:44 +0000
Subject: [issue43566] Docs say int('010', 0) is not legal, but it is
Message-ID: <1616221184.91.0.644321599481.issue43566@roundup.psfhosted.org>


New submission from Chris Wilson <wilscm at gmail.com>:

The documentation for the int() builtin says:

Base 0 means to interpret exactly as a code literal, so that the actual base is 2, 8, 10, or 16, and so that int('010', 0) is not legal, while int('010') is, as well as int('010', 8).

https://docs.python.org/3/library/functions.html#int

However 010 is a valid code literal, and int('010', 0) is legal (both are correctly interpreted as octal).

----------
assignee: docs at python
components: Documentation
messages: 389145
nosy: docs at python, wilscm
priority: normal
severity: normal
status: open
title: Docs say int('010', 0) is not legal, but it is
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43566>
_______________________________________

From report at bugs.python.org  Sat Mar 20 02:31:21 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 20 Mar 2021 06:31:21 +0000
Subject: [issue32865] os.pipe creates inheritable FDs with a bad internal
 state on Windows
In-Reply-To: <1518882714.97.0.467229070634.issue32865@psf.upfronthosting.co.za>
Message-ID: <1616221881.33.0.991778839232.issue32865@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
components: +Extension Modules -Library (Lib)
versions: +Python 3.10, Python 3.9 -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32865>
_______________________________________

From report at bugs.python.org  Sat Mar 20 02:38:25 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 20 Mar 2021 06:38:25 +0000
Subject: [issue32862] os.dup2(fd, fd, inheritable=False) behaves inconsistently
In-Reply-To: <1518837842.39.0.467229070634.issue32862@psf.upfronthosting.co.za>
Message-ID: <1616222305.56.0.899841556396.issue32862@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32862>
_______________________________________

From report at bugs.python.org  Sat Mar 20 02:55:56 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 20 Mar 2021 06:55:56 +0000
Subject: [issue36305] Inconsistent behavior of pathlib.WindowsPath with drive
 paths
In-Reply-To: <1552664225.98.0.0986812073641.issue36305@roundup.psfhosted.org>
Message-ID: <1616223356.84.0.790706281019.issue36305@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
versions: +Python 3.10, Python 3.9 -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36305>
_______________________________________

From report at bugs.python.org  Sat Mar 20 03:01:28 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 20 Mar 2021 07:01:28 +0000
Subject: [issue29971] Lock.acquire() not interruptible on Windows
In-Reply-To: <1491230618.78.0.644794311178.issue29971@psf.upfronthosting.co.za>
Message-ID: <1616223688.05.0.317054083771.issue29971@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
Removed message: https://bugs.python.org/msg291089

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29971>
_______________________________________

From report at bugs.python.org  Sat Mar 20 03:02:35 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 20 Mar 2021 07:02:35 +0000
Subject: [issue29971] Lock.acquire() not interruptible on Windows
In-Reply-To: <1491230618.78.0.644794311178.issue29971@psf.upfronthosting.co.za>
Message-ID: <1616223755.75.0.615025315195.issue29971@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
components: +Extension Modules, Interpreter Core
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29971>
_______________________________________

From report at bugs.python.org  Sat Mar 20 03:13:30 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 20 Mar 2021 07:13:30 +0000
Subject: [issue29178] Adding bytes.frombuffer(byteslike) constructor
In-Reply-To: <1483701377.3.0.893514886442.issue29178@psf.upfronthosting.co.za>
Message-ID: <1616224410.34.0.147170118975.issue29178@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29178>
_______________________________________

From report at bugs.python.org  Sat Mar 20 03:24:28 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 20 Mar 2021 07:24:28 +0000
Subject: [issue30374] Make win_add2path.py take effect without having to log
 off
In-Reply-To: <1494870505.18.0.0357720836897.issue30374@psf.upfronthosting.co.za>
Message-ID: <1616225068.0.0.30335911601.issue30374@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
components:  -ctypes
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30374>
_______________________________________

From report at bugs.python.org  Sat Mar 20 03:27:25 2021
From: report at bugs.python.org (Chris Wilson)
Date: Sat, 20 Mar 2021 07:27:25 +0000
Subject: [issue43566] Docs say int('010', 0) is not legal, but it is
In-Reply-To: <1616221184.91.0.644321599481.issue43566@roundup.psfhosted.org>
Message-ID: <1616225245.52.0.406951939703.issue43566@roundup.psfhosted.org>


Chris Wilson <wilscm at gmail.com> added the comment:

Actually, octal is not a legal literal in Python 3, sorry.

----------
resolution:  -> rejected

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43566>
_______________________________________

From report at bugs.python.org  Sat Mar 20 03:30:40 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 20 Mar 2021 07:30:40 +0000
Subject: [issue43566] Docs say int('010', 0) is not legal, but it is
In-Reply-To: <1616221184.91.0.644321599481.issue43566@roundup.psfhosted.org>
Message-ID: <1616225440.69.0.2360542398.issue43566@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43566>
_______________________________________

From report at bugs.python.org  Sat Mar 20 03:31:29 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 20 Mar 2021 07:31:29 +0000
Subject: [issue30405] build.bat: register binaries for py launcher
In-Reply-To: <1495223200.37.0.229712024273.issue30405@psf.upfronthosting.co.za>
Message-ID: <1616225489.87.0.73112794946.issue30405@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
Removed message: https://bugs.python.org/msg293989

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30405>
_______________________________________

From report at bugs.python.org  Sat Mar 20 03:36:01 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 20 Mar 2021 07:36:01 +0000
Subject: [issue27602] Enable py launcher to launch repository Python.
In-Reply-To: <1469306499.45.0.411476180863.issue27602@psf.upfronthosting.co.za>
Message-ID: <1616225761.76.0.975282095326.issue27602@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

See also bpo-30405, which has more discussion about supporting PEP 514 in the launcher.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27602>
_______________________________________

From report at bugs.python.org  Sat Mar 20 03:36:24 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 20 Mar 2021 07:36:24 +0000
Subject: [issue30405] build.bat: register binaries for py launcher
In-Reply-To: <1495223200.37.0.229712024273.issue30405@psf.upfronthosting.co.za>
Message-ID: <1616225784.02.0.425451382371.issue30405@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30405>
_______________________________________

From report at bugs.python.org  Sat Mar 20 03:38:49 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 20 Mar 2021 07:38:49 +0000
Subject: [issue29996] Use terminal width by default in pprint
In-Reply-To: <1491409756.85.0.158082896832.issue29996@psf.upfronthosting.co.za>
Message-ID: <1616225929.84.0.755275573736.issue29996@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
Removed message: https://bugs.python.org/msg291198

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29996>
_______________________________________

From report at bugs.python.org  Sat Mar 20 03:39:32 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 20 Mar 2021 07:39:32 +0000
Subject: [issue29996] Use terminal width by default in pprint
In-Reply-To: <1491409756.85.0.158082896832.issue29996@psf.upfronthosting.co.za>
Message-ID: <1616225972.57.0.73128701336.issue29996@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29996>
_______________________________________

From report at bugs.python.org  Sat Mar 20 03:44:15 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 20 Mar 2021 07:44:15 +0000
Subject: [issue28166] WindowsConsoleIO misbehavior when Ctrl+C is ignored
In-Reply-To: <1473927025.25.0.183534906845.issue28166@psf.upfronthosting.co.za>
Message-ID: <1616226255.89.0.768786562692.issue28166@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
Removed message: https://bugs.python.org/msg359933

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28166>
_______________________________________

From report at bugs.python.org  Sat Mar 20 03:45:47 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 20 Mar 2021 07:45:47 +0000
Subject: [issue28166] WindowsConsoleIO misbehavior when Ctrl+C is ignored
In-Reply-To: <1473927025.25.0.183534906845.issue28166@psf.upfronthosting.co.za>
Message-ID: <1616226347.18.0.450528290291.issue28166@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
components: +Interpreter Core -Library (Lib)
versions: +Python 3.10 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28166>
_______________________________________

From report at bugs.python.org  Sat Mar 20 03:49:05 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 20 Mar 2021 07:49:05 +0000
Subject: [issue37871] Windows: WindowsConsoleIO produces mojibake for strings
 longer than 32 KiB
In-Reply-To: <1565915764.5.0.613301280158.issue37871@roundup.psfhosted.org>
Message-ID: <1616226545.23.0.437066273152.issue37871@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
stage:  -> needs patch
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37871>
_______________________________________

From report at bugs.python.org  Sat Mar 20 04:31:34 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 20 Mar 2021 08:31:34 +0000
Subject: [issue43535] Make str.join auto-convert inputs to strings.
In-Reply-To: <1616034546.27.0.0632217994438.issue43535@roundup.psfhosted.org>
Message-ID: <1616229094.21.0.698344738763.issue43535@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Vedran, it is not what strong typing means. Strong typing means that '2'+3 is an error instead of '23' or 5. str.join() expects an iterable of strings. If some of items is not a string, it is a sign of programming error. I prefer to get an exception rather of silently conversion of unexpected value to string 'None', '[]' or '<Foo object at 0x12345678>'.

So if you want such feature, it should be separate method or function.

But there is other consideration. Of 721 uses of the join() method (excluding os.path.join()) in the stdlib, only 10 need forceful stringification with map(str, ...). For tests it is 842 to 20, and for Doc/venv/ it is 1388 to 30. I am sure the same ratio is for any other large volume of code. So that feature would actually have very small use - 1-2% of use of str.join().

Specially to Raymond, map(str, ...) is good opportunity to teach about iterators and introduce to itertools.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43535>
_______________________________________

From report at bugs.python.org  Sat Mar 20 04:38:43 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 20 Mar 2021 08:38:43 +0000
Subject: [issue29996] Use terminal width by default in pprint
In-Reply-To: <1491409756.85.0.158082896832.issue29996@psf.upfronthosting.co.za>
Message-ID: <1616229523.63.0.2068868063.issue29996@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Closing then. I'll just add my implementation in my .pythonrc.py.

----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29996>
_______________________________________

From report at bugs.python.org  Sat Mar 20 04:53:13 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 20 Mar 2021 08:53:13 +0000
Subject: [issue29178] Adding bytes.frombuffer(byteslike) constructor
In-Reply-To: <1483701377.3.0.893514886442.issue29178@psf.upfronthosting.co.za>
Message-ID: <1616230393.21.0.426490245047.issue29178@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I am more warm to this feature now (+0). Not because it would allow to write some code shorter, but because it can be in line with other type-strict alternate constructors, like int.fromnumber() and int.parse(). But questions about parameters and subclasses still stay.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29178>
_______________________________________

From report at bugs.python.org  Sat Mar 20 04:59:12 2021
From: report at bugs.python.org (Zackery Spytz)
Date: Sat, 20 Mar 2021 08:59:12 +0000
Subject: [issue43556] fix attr names for ast.expr and ast.stmt
In-Reply-To: <1616155271.78.0.879688630382.issue43556@roundup.psfhosted.org>
Message-ID: <1616230752.71.0.417690630787.issue43556@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 2.0 -> 3.0
pull_requests: +23701
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24940

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43556>
_______________________________________

From report at bugs.python.org  Sat Mar 20 04:59:59 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 20 Mar 2021 08:59:59 +0000
Subject: [issue43520] Make Fraction(string) handle non-ascii slashes
In-Reply-To: <1615918144.03.0.939769511159.issue43520@roundup.psfhosted.org>
Message-ID: <1616230799.3.0.848586473912.issue43520@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It would be nice to have an utility function in unicodedata to convert Unicode characters to their ASCII equivalents (if they exist). It would allow to explicitly convert all slashes to / (and all digits to 0-9) before passing string to Fraction constructor.

AFAIK there is a special Unicode document and tables for this.

----------
components: +Unicode
nosy: +serhiy.storchaka, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43520>
_______________________________________

From report at bugs.python.org  Sat Mar 20 05:10:27 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 20 Mar 2021 09:10:27 +0000
Subject: [issue43520] Make Fraction(string) handle non-ascii slashes
In-Reply-To: <1615918144.03.0.939769511159.issue43520@roundup.psfhosted.org>
Message-ID: <1616231427.98.0.205935280487.issue43520@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Carl: can you say more about the problem that motivated this issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43520>
_______________________________________

From report at bugs.python.org  Sat Mar 20 06:32:47 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Sat, 20 Mar 2021 10:32:47 +0000
Subject: [issue43502] [C-API] Convert obvious unsafe macros to static inline
 functions
In-Reply-To: <1615816484.12.0.00251754107838.issue43502@roundup.psfhosted.org>
Message-ID: <1616236367.35.0.0131979681222.issue43502@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

Based on the feedback, I'm closing this. The PyUnicode_* macros, or the callers, can be fixed in a separate issue.

----------
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43502>
_______________________________________

From report at bugs.python.org  Sat Mar 20 06:48:26 2021
From: report at bugs.python.org (Xavier Morel)
Date: Sat, 20 Mar 2021 10:48:26 +0000
Subject: [issue43526] Programmatic management of BytesWarning doesn't work for
 native triggers.
In-Reply-To: <1615971785.71.0.488992120219.issue43526@roundup.psfhosted.org>
Message-ID: <1616237306.46.0.916350152544.issue43526@roundup.psfhosted.org>


Xavier Morel <xavier.morel at masklinn.net> added the comment:

> In normal circumstances you should never deal with BytesWarning. The -b option is only used for testing your program for some possible bugs caused by migration from Python 2. If your program always worked only with Python 3, the -b option has no use for you.

That's technically true for perfect programs, but practically if the program is not tested enough it's possible for it to contain unexpected instances of stringifying bytes which pass by mostly unnoticed, just with garbage bits of output which may or may not get reported.

Noticing such cases in an existing codebase is exactly what prompted me to try and enable BytesWarning (and then try and filter them to just conversion warnings, as the category is quite noisy with somewhat uninteresting warnings), and then spend a while trying to understand why programmatically enabling BytesWarning didn't do anything.

As noted in the last paragraph it's fine if `-b` is required to enable the feature, I'd just like to know if it could be documented clearly as it's somewhat frustrating to pore over the documentation of `warnings`, `BytesWarning`, and `-b`, diff the state of the filters configuration, etc? and end up finding out from a bpo comment whether the behaviour you're observing is intentional or not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43526>
_______________________________________

From report at bugs.python.org  Sat Mar 20 07:02:18 2021
From: report at bugs.python.org (Jiaxin Peng)
Date: Sat, 20 Mar 2021 11:02:18 +0000
Subject: [issue43567] regen.vcxproj cannot regenerate some necessary files
Message-ID: <1616238138.44.0.687655765468.issue43567@roundup.psfhosted.org>


New submission from Jiaxin Peng <pjx206 at 163.com>:

I tried to modify Grammar/python.gram, Grammar/Tokens, Parser/Python.asdl, to add a new token to the grammar. And when using `build.bat --regen`, only parser.c is newly generated. Other files, as mentioned in https://devguide.python.org/grammar/ that should be updated:ast.c, Python-ast.h etc.
regen.vcxproj is now not capable for the new PEG parser. So an update is need.

----------
components: Build
messages: 389155
nosy: pjx206
priority: normal
severity: normal
status: open
title: regen.vcxproj cannot regenerate some necessary files
type: compile error
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43567>
_______________________________________

From report at bugs.python.org  Sat Mar 20 08:21:52 2021
From: report at bugs.python.org (Mark Shannon)
Date: Sat, 20 Mar 2021 12:21:52 +0000
Subject: [issue43563] Use dedicated opcodes to speed up calls/attribute
 lookups with super() as receiver
In-Reply-To: <1616187477.95.0.162642980766.issue43563@roundup.psfhosted.org>
Message-ID: <1616242912.92.0.501412592772.issue43563@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

Why?

Do you have any evidence that the overhead of super() is significant in real programs, or that the proposed change actually speeds up anything beyond your micro-benchmark?

----------
nosy: +Mark.Shannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43563>
_______________________________________

From report at bugs.python.org  Sat Mar 20 09:08:22 2021
From: report at bugs.python.org (Joshua Root)
Date: Sat, 20 Mar 2021 13:08:22 +0000
Subject: [issue43568] Drop support for Mac OS X < 10.3 module linking
Message-ID: <1616245702.65.0.278864424752.issue43568@roundup.psfhosted.org>


New submission from Joshua Root <josh+python at root.id.au>:

The `-undefined dynamic_lookup` option can only be used in LDSHARED on Mac OS X 10.3 and later. There is a fallback to explicitly linking with the framework for 10.2 and earlier. I'm pretty sure that currently supported Python versions don't build on 10.2 or older for several other reasons (I happen to know that even building on 10.5 requires a little patching.) So it's probably reasonable to just drop this code path.

There is a closely related check in distutils, though you would only know it's related if you looked through the history as I did. It errors out if you try to build a module for an older MACOSX_DEPLOYMENT_TARGET than Python was configured with. The purpose of that is to prevent using the wrong LDSHARED flags for the target platform. If 10.2 support is dropped, that check can be removed entirely.

I am aware that distutils is deprecated, going away, etc., and I am submitting a PR to setuptools as well. But setuptools does not yet override the stdlib distutils with its own by default, so bugs in the stdlib copy are still relevant.

If it's decided to keep 10.2 support, the check in distutils should still be relaxed to error only if the current MDT is < 10.3 and the configured MDT is >= 10.3. I can easily put together a PR for that if needed.

Either way, the approach taken in setuptools will depend on how LDSHARED is handled here.

----------
components: Build, Distutils, macOS
messages: 389157
nosy: dstufft, eric.araujo, jmr, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Drop support for Mac OS X < 10.3 module linking
type: enhancement
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43568>
_______________________________________

From report at bugs.python.org  Sat Mar 20 09:56:41 2021
From: report at bugs.python.org (Joshua Root)
Date: Sat, 20 Mar 2021 13:56:41 +0000
Subject: [issue43568] Drop support for Mac OS X < 10.3 module linking
In-Reply-To: <1616245702.65.0.278864424752.issue43568@roundup.psfhosted.org>
Message-ID: <1616248601.97.0.700884054451.issue43568@roundup.psfhosted.org>


Change by Joshua Root <josh+python at root.id.au>:


----------
keywords: +patch
pull_requests: +23702
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24941

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43568>
_______________________________________

From report at bugs.python.org  Sat Mar 20 10:30:08 2021
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Mar 2021 14:30:08 +0000
Subject: [issue24505] shutil.which wrong result on Windows
In-Reply-To: <1435183779.2.0.13075721906.issue24505@psf.upfronthosting.co.za>
Message-ID: <1616250608.7.0.848114349419.issue24505@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24505>
_______________________________________

From report at bugs.python.org  Sat Mar 20 10:32:18 2021
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Mar 2021 14:32:18 +0000
Subject: [issue28188] os.putenv should support bytes arguments on Windows
In-Reply-To: <1474123387.93.0.730915025745.issue28188@psf.upfronthosting.co.za>
Message-ID: <1616250738.45.0.182270405356.issue28188@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28188>
_______________________________________

From report at bugs.python.org  Sat Mar 20 10:32:47 2021
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Mar 2021 14:32:47 +0000
Subject: [issue32865] os.pipe creates inheritable FDs with a bad internal
 state on Windows
In-Reply-To: <1518882714.97.0.467229070634.issue32865@psf.upfronthosting.co.za>
Message-ID: <1616250767.25.0.0372866094137.issue32865@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32865>
_______________________________________

From report at bugs.python.org  Sat Mar 20 10:32:55 2021
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Mar 2021 14:32:55 +0000
Subject: [issue32862] os.dup2(fd, fd, inheritable=False) behaves inconsistently
In-Reply-To: <1518837842.39.0.467229070634.issue32862@psf.upfronthosting.co.za>
Message-ID: <1616250775.06.0.198913658702.issue32862@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32862>
_______________________________________

From report at bugs.python.org  Sat Mar 20 10:33:22 2021
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Mar 2021 14:33:22 +0000
Subject: [issue29971] Lock.acquire() not interruptible on Windows
In-Reply-To: <1491230618.78.0.644794311178.issue29971@psf.upfronthosting.co.za>
Message-ID: <1616250802.72.0.435487711439.issue29971@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29971>
_______________________________________

From report at bugs.python.org  Sat Mar 20 10:33:34 2021
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Mar 2021 14:33:34 +0000
Subject: [issue30405] build.bat: register binaries for py launcher
In-Reply-To: <1495223200.37.0.229712024273.issue30405@psf.upfronthosting.co.za>
Message-ID: <1616250814.66.0.939349662843.issue30405@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30405>
_______________________________________

From report at bugs.python.org  Sat Mar 20 10:33:48 2021
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Mar 2021 14:33:48 +0000
Subject: [issue37871] Windows: WindowsConsoleIO produces mojibake for strings
 longer than 32 KiB
In-Reply-To: <1565915764.5.0.613301280158.issue37871@roundup.psfhosted.org>
Message-ID: <1616250828.59.0.758959751516.issue37871@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37871>
_______________________________________

From report at bugs.python.org  Sat Mar 20 10:41:27 2021
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Mar 2021 14:41:27 +0000
Subject: [issue43520] Make Fraction(string) handle non-ascii slashes
In-Reply-To: <1615918144.03.0.939769511159.issue43520@roundup.psfhosted.org>
Message-ID: <1616251287.8.0.603906849027.issue43520@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Usually, constructors try to accept format returned by repr(obj), or even str(obj). It's the case for Fraction:

>>> str(fractions.Fraction(1, 2))
'1/2'
>>> fractions.Fraction("1/2")
Fraction(1, 2)

It works as expected.

I dislike the idea of trying to handle more Unicode characters which "look like" "/", or characters like "?". It sounds like a can of worm, and I don't think that such feature belongs to the stdlib. You can easily write your helper function accepting string and returning a fraction.

If someone is motivated to accept more character, I would prefer to have an unified proposition covering all Python number types (int, float, Fraction, complex, etc.) and listing all characters. Maybe a PEP would make sense.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43520>
_______________________________________

From report at bugs.python.org  Sat Mar 20 10:45:16 2021
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Mar 2021 14:45:16 +0000
Subject: [issue43552] Add locale.get_locale_encoding() and
 locale.get_current_locale_encoding()
In-Reply-To: <1616145433.55.0.350148222552.issue43552@roundup.psfhosted.org>
Message-ID: <1616251516.6.0.129333180507.issue43552@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Python uses GetACP(), the ANSI code page of the operating system, for years. What is the advantage of using a different encoding? In my experience, most applications use the ANSI code page because they use the ANSI flavor of the Windows API.

What is the use case for using ___lc_codepage()? Is it a different encoding?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43552>
_______________________________________

From report at bugs.python.org  Sat Mar 20 10:58:06 2021
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Mar 2021 14:58:06 +0000
Subject: [issue43569] test_importlib failed on installed Python
Message-ID: <1616252286.95.0.663253122373.issue43569@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Example on aarch64 Fedora Stable Clang Installed 3.x:
https://buildbot.python.org/all/#/builders/14/builds/804

======================================================================
ERROR: test_open_binary (test.test_importlib.test_open.OpenDiskNamespaceTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/test/test_importlib/test_open.py", line 67, in setUp
    from . import namespacedata01
ImportError: cannot import name 'namespacedata01' from 'test.test_importlib' (/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/test/test_importlib/__init__.py)

======================================================================
ERROR: test_open_binary_FileNotFoundError (test.test_importlib.test_open.OpenDiskNamespaceTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/test/test_importlib/test_open.py", line 67, in setUp
    from . import namespacedata01
ImportError: cannot import name 'namespacedata01' from 'test.test_importlib' (/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/test/test_importlib/__init__.py)

======================================================================
ERROR: test_open_text_FileNotFoundError (test.test_importlib.test_open.OpenDiskNamespaceTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/test/test_importlib/test_open.py", line 67, in setUp
    from . import namespacedata01
ImportError: cannot import name 'namespacedata01' from 'test.test_importlib' (/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/test/test_importlib/__init__.py)

======================================================================
ERROR: test_open_text_default_encoding (test.test_importlib.test_open.OpenDiskNamespaceTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/test/test_importlib/test_open.py", line 67, in setUp
    from . import namespacedata01
ImportError: cannot import name 'namespacedata01' from 'test.test_importlib' (/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/test/test_importlib/__init__.py)

======================================================================
ERROR: test_open_text_given_encoding (test.test_importlib.test_open.OpenDiskNamespaceTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/test/test_importlib/test_open.py", line 67, in setUp
    from . import namespacedata01
ImportError: cannot import name 'namespacedata01' from 'test.test_importlib' (/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/test/test_importlib/__init__.py)

======================================================================
ERROR: test_open_text_with_errors (test.test_importlib.test_open.OpenDiskNamespaceTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/test/test_importlib/test_open.py", line 67, in setUp
    from . import namespacedata01
ImportError: cannot import name 'namespacedata01' from 'test.test_importlib' (/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/test/test_importlib/__init__.py)

======================================================================
ERROR: test_is_dir (test.test_importlib.test_reader.MultiplexedPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/test/test_importlib/test_reader.py", line 48, in test_is_dir
    self.assertEqual(MultiplexedPath(self.folder).is_dir(), True)
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/importlib/readers.py", line 63, in __init__
    raise NotADirectoryError('MultiplexedPath only supports directories')
NotADirectoryError: MultiplexedPath only supports directories

======================================================================
ERROR: test_is_file (test.test_importlib.test_reader.MultiplexedPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/test/test_importlib/test_reader.py", line 51, in test_is_file
    self.assertEqual(MultiplexedPath(self.folder).is_file(), False)
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/importlib/readers.py", line 63, in __init__
    raise NotADirectoryError('MultiplexedPath only supports directories')
NotADirectoryError: MultiplexedPath only supports directories

======================================================================
ERROR: test_iterdir (test.test_importlib.test_reader.MultiplexedPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/test/test_importlib/test_reader.py", line 25, in test_iterdir
    contents = {path.name for path in MultiplexedPath(self.folder).iterdir()}
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/importlib/readers.py", line 63, in __init__
    raise NotADirectoryError('MultiplexedPath only supports directories')
NotADirectoryError: MultiplexedPath only supports directories

======================================================================
ERROR: test_iterdir_duplicate (test.test_importlib.test_reader.MultiplexedPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/test/test_importlib/test_reader.py", line 35, in test_iterdir_duplicate
    path.name for path in MultiplexedPath(self.folder, data01).iterdir()
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/importlib/readers.py", line 63, in __init__
    raise NotADirectoryError('MultiplexedPath only supports directories')
NotADirectoryError: MultiplexedPath only supports directories

======================================================================
ERROR: test_join_path (test.test_importlib.test_reader.MultiplexedPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/test/test_importlib/test_reader.py", line 66, in test_join_path
    path = MultiplexedPath(self.folder, data01)
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/importlib/readers.py", line 63, in __init__
    raise NotADirectoryError('MultiplexedPath only supports directories')
NotADirectoryError: MultiplexedPath only supports directories

======================================================================
ERROR: test_open_file (test.test_importlib.test_reader.MultiplexedPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/test/test_importlib/test_reader.py", line 54, in test_open_file
    path = MultiplexedPath(self.folder)
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/importlib/readers.py", line 63, in __init__
    raise NotADirectoryError('MultiplexedPath only supports directories')
NotADirectoryError: MultiplexedPath only supports directories

======================================================================
ERROR: test_repr (test.test_importlib.test_reader.MultiplexedPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/test/test_importlib/test_reader.py", line 82, in test_repr
    repr(MultiplexedPath(self.folder)),
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/importlib/readers.py", line 63, in __init__
    raise NotADirectoryError('MultiplexedPath only supports directories')
NotADirectoryError: MultiplexedPath only supports directories

======================================================================
ERROR: test_files (test.test_importlib.test_reader.NamespaceReaderTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/test/test_importlib/test_reader.py", line 115, in test_files
    namespacedata01 = import_module('namespacedata01')
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1049, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1026, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1003, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'namespacedata01'

======================================================================
ERROR: test_resource_path (test.test_importlib.test_reader.NamespaceReaderTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/test/test_importlib/test_reader.py", line 103, in test_resource_path
    namespacedata01 = import_module('namespacedata01')
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1049, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1026, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1003, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'namespacedata01'

======================================================================
ERROR: test_is_submodule_resource (test.test_importlib.test_resource.ResourceFromNamespaceTest01)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/test/test_importlib/test_resource.py", line 230, in test_is_submodule_resource
    resources.is_resource(import_module('namespacedata01'), 'binary.file')
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1049, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1026, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1003, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'namespacedata01'

======================================================================
ERROR: test_read_submodule_resource_by_name (test.test_importlib.test_resource.ResourceFromNamespaceTest01)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/test/test_importlib/test_resource.py", line 234, in test_read_submodule_resource_by_name
    self.assertTrue(resources.is_resource('namespacedata01', 'binary.file'))
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/importlib/resources.py", line 152, in is_resource
    package = _common.get_package(package)
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/importlib/_common.py", line 65, in get_package
    resolved = resolve(package)
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/importlib/_common.py", line 56, in resolve
    return cand if isinstance(cand, types.ModuleType) else importlib.import_module(cand)
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1049, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1026, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1003, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'namespacedata01'

======================================================================
ERROR: test_submodule_contents (test.test_importlib.test_resource.ResourceFromNamespaceTest01)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/test/test_importlib/test_resource.py", line 237, in test_submodule_contents
    contents = set(resources.contents(import_module('namespacedata01')))
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1049, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1026, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1003, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'namespacedata01'

======================================================================
ERROR: test_submodule_contents_by_name (test.test_importlib.test_resource.ResourceFromNamespaceTest01)
----------------------------------------------------------------------
test test_importlib failed
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/test/test_importlib/test_resource.py", line 245, in test_submodule_contents_by_name
    contents = set(resources.contents('namespacedata01'))
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/importlib/resources.py", line 170, in contents
    package = _common.get_package(package)
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/importlib/_common.py", line 65, in get_package
    resolved = resolve(package)
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/importlib/_common.py", line 56, in resolve
    return cand if isinstance(cand, types.ModuleType) else importlib.import_module(cand)
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.clang-installed/build/target/lib/python3.10/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1049, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1026, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1003, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'namespacedata01'

----------
components: Tests
messages: 389160
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_importlib failed on installed Python
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43569>
_______________________________________

From report at bugs.python.org  Sat Mar 20 10:58:26 2021
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Mar 2021 14:58:26 +0000
Subject: [issue43569] test_importlib failed on installed Python
In-Reply-To: <1616252286.95.0.663253122373.issue43569@roundup.psfhosted.org>
Message-ID: <1616252306.54.0.526903682305.issue43569@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

It seems like tests were added by:

commit 67148254146948041a77d8a2989f41b88cdb2f99
Author: Jason R. Coombs <jaraco at jaraco.com>
Date:   Thu Mar 4 13:43:00 2021 -0500

    bpo-42129: Add support for resources in namespaces (GH-24670)
    
    * Unify behavior in ResourceReaderDefaultsTests and align with the behavior found in importlib_resources.
    * Equip NamespaceLoader with a NamespaceReader.
    * Apply changes from importlib_resources 5.0.4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43569>
_______________________________________

From report at bugs.python.org  Sat Mar 20 10:58:58 2021
From: report at bugs.python.org (Alex Kanitz)
Date: Sat, 20 Mar 2021 14:58:58 +0000
Subject: [issue11354] argparse: nargs could accept range of options count
In-Reply-To: <1298911895.1.0.590272861033.issue11354@psf.upfronthosting.co.za>
Message-ID: <1616252338.49.0.291682566607.issue11354@roundup.psfhosted.org>


Alex Kanitz <alexander.kanitz at sib.swiss> added the comment:

Given that people were asking for real-world use cases, here's one: high-throughput sequencing, e.g., in RNA-Seq (https://en.wikipedia.org/wiki/RNA-Seq), typically yields either one or two output files, depending on the type of the sequencing library. As the processing of these library types is very similar, bioinformatics tools dealing with these inputs thus typically have APIs that take exactly 1 or 2 files as inputs. As there is quite a wide range of tools for dealing with such inputs, several of which implemented in Python, I believe there is indeed an interest in this functionality. On a more conceptual note: it is also consistent with similar and often-used functionality in regexes, from which, I suppose, the '+' and '*' notation is borrowed.

Currently implementing such a tool, I ran into the argparse limitation described here: either I (a) use a positional param with nargs=1 for the first file and define an optional param for the second file (inconsistent, non-intuitive and semantically incorrect API, because if there IS a second file, it is not really optional), (b) use nargs='+', do the admittedly simple post-processing/validation and either ignore keep the auto-generated usage string(wrong/misleading), hardcode the correct usage string (maintenance burden because of several optional params) or apply this patch (or just the auto-usage generation function), which seems rather expensive, or (c) have the user pass the second file in one string, separated by a comma or similar (also not very intuitive and needs some checks to ensure that the filename/s don't actually include commas).

----------
nosy: +uniqueg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11354>
_______________________________________

From report at bugs.python.org  Sat Mar 20 10:59:06 2021
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Mar 2021 14:59:06 +0000
Subject: [issue42129] Support resources in namespace packages
In-Reply-To: <1603469006.87.0.128715336786.issue42129@roundup.psfhosted.org>
Message-ID: <1616252346.86.0.911747954339.issue42129@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Please see bpo-43569: "test_importlib failed on installed Python" regression introduced by commit 67148254146948041a77d8a2989f41b88cdb2f99.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42129>
_______________________________________

From report at bugs.python.org  Sat Mar 20 10:59:16 2021
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Mar 2021 14:59:16 +0000
Subject: [issue42129] Support resources in namespace packages
In-Reply-To: <1603469006.87.0.128715336786.issue42129@roundup.psfhosted.org>
Message-ID: <1616252356.92.0.531517634543.issue42129@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I reopen the issue.

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42129>
_______________________________________

From report at bugs.python.org  Sat Mar 20 11:15:25 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 20 Mar 2021 15:15:25 +0000
Subject: [issue40521] [subinterpreters] Make free lists and unicode caches
 per-interpreter
In-Reply-To: <1588693682.5.0.219755904926.issue40521@roundup.psfhosted.org>
Message-ID: <1616253325.96.0.361517816757.issue40521@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
pull_requests: +23703
pull_request: https://github.com/python/cpython/pull/24944

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40521>
_______________________________________

From report at bugs.python.org  Sat Mar 20 11:29:56 2021
From: report at bugs.python.org (Chris Morton)
Date: Sat, 20 Mar 2021 15:29:56 +0000
Subject: [issue43481] PyEval_EvalCode() namespace issue not observed in Python
 2.7.
In-Reply-To: <1615585477.01.0.106665214672.issue43481@roundup.psfhosted.org>
Message-ID: <1616254196.27.0.60505924607.issue43481@roundup.psfhosted.org>


Chris Morton <chrisgmorton at yahoo.com> added the comment:

Hi Terry, The reason why your code does not reproduce the issue is because you first execute the code in a global context which then puts the definition of c in that context. Subsequent calling in the local context then works. If you remove the first exec call (no need for the Class lines either), you will now see the issue in 3.8.
This issue is reproducible for other containers such as lists and sets, instead of dictionary, in this case. Replacing range(len(c)) with range(4) also shows the same error. The error relates to the use of the indexing operator []. The same error is observed with other sequences such as:

c={1,2,3,4} 

or

c='1234'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43481>
_______________________________________

From report at bugs.python.org  Sat Mar 20 11:49:52 2021
From: report at bugs.python.org (John Ehresman)
Date: Sat, 20 Mar 2021 15:49:52 +0000
Subject: [issue23948] Deprecate os.kill() on Windows
In-Reply-To: <1429025061.32.0.415018485708.issue23948@psf.upfronthosting.co.za>
Message-ID: <1616255392.4.0.935818496107.issue23948@roundup.psfhosted.org>


John Ehresman <jpe at wingware.com> added the comment:

The original idea was to not use kill on win32 because developers often assume it will work like it does on unix-like OS's -- my claim is while kill could be improved on win32, it still won't support all the things kill can do elsewhere.  

I don't think this idea has much, if any support so I suggest closing this bug and opening other specific bugs to improve it on win32 for the ideas mentioned in the comments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23948>
_______________________________________

From report at bugs.python.org  Sat Mar 20 12:04:17 2021
From: report at bugs.python.org (Ned Deily)
Date: Sat, 20 Mar 2021 16:04:17 +0000
Subject: [issue43536] 3.9.2 --without-pymalloc --with-pydebug --with-valgrind:
 test failed: test_posix
In-Reply-To: <1616040490.74.0.308907840702.issue43536@roundup.psfhosted.org>
Message-ID: <1616256257.61.0.974002107087.issue43536@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Please report the verbose results from the failing test cases; otherwise we are just guessing at what the exact failure is.  Use the -w or -v options to test.regrtest.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43536>
_______________________________________

From report at bugs.python.org  Sat Mar 20 12:06:01 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 20 Mar 2021 16:06:01 +0000
Subject: [issue43563] Use dedicated opcodes to speed up calls/attribute
 lookups with super() as receiver
In-Reply-To: <1616187477.95.0.162642980766.issue43563@roundup.psfhosted.org>
Message-ID: <1616256361.64.0.241708148718.issue43563@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Currently, super() is decoupled from the core language.  It is just a builtin that provides customized attribute lookup.  This PR makes super() more tightly integrated with the core language, treating it as if it were a keyword and part of the grammar.  Also note, users can currently create their own versions of super(), shadowing the builtin super().

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43563>
_______________________________________

From report at bugs.python.org  Sat Mar 20 12:26:35 2021
From: report at bugs.python.org (Julien Palard)
Date: Sat, 20 Mar 2021 16:26:35 +0000
Subject: [issue43570] pyspecific.py >  AuditEvent mess with translations
Message-ID: <1616257595.38.0.162769956248.issue43570@roundup.psfhosted.org>


New submission from Julien Palard <julien+python at palard.fr>:

In case an `.. audit-event::` has a content, Sphinx gets confused:

It will provide both "auto-generated" and the content in po files, for interactivehook for example we have:

    #: library/sys.rst:953
    msgid ""
    "Raises an :ref:`auditing event <auditing>` ``cpython.run_interactivehook`` "
    "with argument ``hook``."
    msgstr ""

    #: library/sys.rst:955
    msgid ""
    "Raises an :ref:`auditing event <auditing>` ``cpython.run_interactivehook`` "
    "with the hook object as the argument when the hook is called on startup."
    msgstr ""
    "L?ve un :ref:`?v?nement d'audit <auditing>` ``cpython.run_interactivehook`` "
    "avec l'objet de point d'entr?e comme argument lorsqu'il est appel? au "
    "d?marrage."

Which is not needed as only the content is used to render the doc, but it's the least issue. The issue is that Sphinx will then check the used one (content) against the translation of the auto-generated one leading it to trigger a warning on case the :ref: used don't match, typically for:


    .. audit-event:: sys.unraisablehook hook,unraisable sys.unraisablehook

       Raise an auditing event ``sys.unraisablehook`` with arguments
       ``hook``, ``unraisable`` when an exception that cannot be handled occurs.
       The ``unraisable`` object is the same as what will be passed to the hook.
       If no hook has been set, ``hook`` may be ``None``.

    
Sphinx will compare the auto-generated one:

    Raises an :ref:`auditing event <auditing>` ``sys.unraisablehook`` with arguments ``hook``, ``unraisable``.

Against our translated one (L?ve un ?v?nement d'audit ...).

Issue is, as in "Raise an auditing event" there's no :ref:, but as we translated "Raises an :ref:`auditing event <auditing>`" we used one, Sphinx whines about inconsistent term references.

As far as I understand it, it's related, or near, the:

    if self.content:
        self.state.nested_parse(self.content, self.content_offset, pnode)
    else:
        n, m = self.state.inline_text(text, self.lineno)
        pnode.extend(n + m)

part of pyspecific.py.

----------
assignee: docs at python
components: Documentation
messages: 389169
nosy: docs at python, mdk, steve.dower
priority: normal
severity: normal
status: open
title: pyspecific.py >  AuditEvent mess with translations
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43570>
_______________________________________

From report at bugs.python.org  Sat Mar 20 12:53:08 2021
From: report at bugs.python.org (Rui Cunha)
Date: Sat, 20 Mar 2021 16:53:08 +0000
Subject: [issue43571] Add option to create MPTCP sockets
Message-ID: <1616259188.08.0.788716564189.issue43571@roundup.psfhosted.org>


Change by Rui Cunha <ruicunham at hotmail.com>:


----------
components: Extension Modules
nosy: RuiCunhaM, ncoghlan, petr.viktorin
priority: normal
severity: normal
status: open
title: Add option to create MPTCP sockets
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43571>
_______________________________________

From report at bugs.python.org  Sat Mar 20 13:15:46 2021
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 20 Mar 2021 17:15:46 +0000
Subject: [issue43535] Make str.join auto-convert inputs to strings.
In-Reply-To: <1616034546.27.0.0632217994438.issue43535@roundup.psfhosted.org>
Message-ID: <1616260546.39.0.0325974852781.issue43535@roundup.psfhosted.org>


Change by Batuhan Taskaya <isidentical at gmail.com>:


----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43535>
_______________________________________

From report at bugs.python.org  Sat Mar 20 13:30:53 2021
From: report at bugs.python.org (Julien Palard)
Date: Sat, 20 Mar 2021 17:30:53 +0000
Subject: [issue43570] pyspecific.py >  AuditEvent mess with translations
In-Reply-To: <1616257595.38.0.162769956248.issue43570@roundup.psfhosted.org>
Message-ID: <1616261453.08.0.80595640573.issue43570@roundup.psfhosted.org>


Change by Julien Palard <julien+python at palard.fr>:


----------
keywords: +patch
pull_requests: +23704
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24945

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43570>
_______________________________________

From report at bugs.python.org  Sat Mar 20 13:36:28 2021
From: report at bugs.python.org (Rui Cunha)
Date: Sat, 20 Mar 2021 17:36:28 +0000
Subject: [issue43571] Add option to create MPTCP sockets
Message-ID: <1616261788.89.0.537621763387.issue43571@roundup.psfhosted.org>


Change by Rui Cunha <ruicunham at hotmail.com>:


----------
keywords: +patch
pull_requests: +23705
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24946

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43571>
_______________________________________

From report at bugs.python.org  Sat Mar 20 13:57:23 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 20 Mar 2021 17:57:23 +0000
Subject: [issue43535] Make str.join auto-convert inputs to strings.
In-Reply-To: <1616034546.27.0.0632217994438.issue43535@roundup.psfhosted.org>
Message-ID: <1616263043.39.0.937004155125.issue43535@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> Of 721 uses of the join() method (excluding os.path.join()) 
> in the stdlib, only 10 need forceful stringification with 
> map(str, ...)

Thanks for looking a real world code.  I'm surprised that the standard library stats aren't representative of my experience, perhaps because I tend to write numeric code and do more output formatting than is used internally.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43535>
_______________________________________

From report at bugs.python.org  Sat Mar 20 13:57:52 2021
From: report at bugs.python.org (jack1142)
Date: Sat, 20 Mar 2021 17:57:52 +0000
Subject: [issue43535] Make str.join auto-convert inputs to strings.
In-Reply-To: <1616034546.27.0.0632217994438.issue43535@roundup.psfhosted.org>
Message-ID: <1616263072.66.0.808398327233.issue43535@roundup.psfhosted.org>


Change by jack1142 <kuba.kuczys at gmail.com>:


----------
nosy: +jack1142

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43535>
_______________________________________

From report at bugs.python.org  Sat Mar 20 14:00:24 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 20 Mar 2021 18:00:24 +0000
Subject: [issue43535] Make str.join auto-convert inputs to strings.
In-Reply-To: <1616034546.27.0.0632217994438.issue43535@roundup.psfhosted.org>
Message-ID: <1616263224.17.0.60972527826.issue43535@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

FWIW, I'm running a user poll on Twitter and have asked people to state their rationale:

    https://twitter.com/raymondh/status/1373315362062626823

Take it with a grain of salt.  Polls totals don't reflect how much thought each person put into their vote.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43535>
_______________________________________

From report at bugs.python.org  Sat Mar 20 15:07:52 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Mar 2021 19:07:52 +0000
Subject: [issue43517] Fix false positives in circular import detection with
 from-imports
In-Reply-To: <1615911063.74.0.357076415367.issue43517@roundup.psfhosted.org>
Message-ID: <1616267272.32.0.582184577297.issue43517@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:


New changeset 2fd16ef406bba239b1334057fb499496a84b3aa2 by Antoine Pitrou in branch 'master':
bpo-43517: Fix false positive in detection of circular imports (#24895)
https://github.com/python/cpython/commit/2fd16ef406bba239b1334057fb499496a84b3aa2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43517>
_______________________________________

From report at bugs.python.org  Sat Mar 20 15:12:13 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 20 Mar 2021 19:12:13 +0000
Subject: [issue43452] Microoptimize PyType_Lookup for cache hits
In-Reply-To: <1615317677.24.0.232039554227.issue43452@roundup.psfhosted.org>
Message-ID: <1616267533.61.0.469721385407.issue43452@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset ee48c7d54147ae906776b9f6f96e8920e097d0c4 by Dino Viehland in branch 'master':
bpo-43452: Micro-optimizations to PyType_Lookup (GH-24804)
https://github.com/python/cpython/commit/ee48c7d54147ae906776b9f6f96e8920e097d0c4


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43452>
_______________________________________

From report at bugs.python.org  Sat Mar 20 15:13:03 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 20 Mar 2021 19:13:03 +0000
Subject: [issue43452] Microoptimize PyType_Lookup for cache hits
In-Reply-To: <1615317677.24.0.232039554227.issue43452@roundup.psfhosted.org>
Message-ID: <1616267583.92.0.787742092835.issue43452@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/issue43452>
_______________________________________

From report at bugs.python.org  Sat Mar 20 15:17:01 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Mar 2021 19:17:01 +0000
Subject: [issue43517] Fix false positives in circular import detection with
 from-imports
In-Reply-To: <1615911063.74.0.357076415367.issue43517@roundup.psfhosted.org>
Message-ID: <1616267821.35.0.938499943113.issue43517@roundup.psfhosted.org>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
pull_requests: +23706
pull_request: https://github.com/python/cpython/pull/24948

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43517>
_______________________________________

From report at bugs.python.org  Sat Mar 20 15:17:30 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 20 Mar 2021 19:17:30 +0000
Subject: [issue43452] Microoptimize PyType_Lookup for cache hits
In-Reply-To: <1615317677.24.0.232039554227.issue43452@roundup.psfhosted.org>
Message-ID: <1616267850.95.0.251062857034.issue43452@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +23707
pull_request: https://github.com/python/cpython/pull/24949

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43452>
_______________________________________

From report at bugs.python.org  Sat Mar 20 15:31:56 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 20 Mar 2021 19:31:56 +0000
Subject: [issue43569] test_importlib failed on installed Python
In-Reply-To: <1616252286.95.0.663253122373.issue43569@roundup.psfhosted.org>
Message-ID: <1616268716.71.0.655338255873.issue43569@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
assignee:  -> jaraco
nosy: +jaraco

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43569>
_______________________________________

From report at bugs.python.org  Sat Mar 20 15:40:28 2021
From: report at bugs.python.org (miss-islington)
Date: Sat, 20 Mar 2021 19:40:28 +0000
Subject: [issue43517] Fix false positives in circular import detection with
 from-imports
In-Reply-To: <1615911063.74.0.357076415367.issue43517@roundup.psfhosted.org>
Message-ID: <1616269228.14.0.31679436231.issue43517@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ac17ed60f2033253248be494a8e1980fe7e3531d by Antoine Pitrou in branch '3.9':
[3.9] bpo-43517: Fix false positive in detection of circular imports (GH-24895) (GH-24948)
https://github.com/python/cpython/commit/ac17ed60f2033253248be494a8e1980fe7e3531d


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43517>
_______________________________________

From report at bugs.python.org  Sat Mar 20 15:44:18 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 20 Mar 2021 19:44:18 +0000
Subject: [issue43569] test_importlib failed on installed Python
In-Reply-To: <1616252286.95.0.663253122373.issue43569@roundup.psfhosted.org>
Message-ID: <1616269458.17.0.232319221406.issue43569@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Interestingly, the pull request never alerted to any buildbot failures.

Any idea how I can reproduce the issue locally? Is there a docker image that would likely replicate the environment in which the tests are failing?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43569>
_______________________________________

From report at bugs.python.org  Sat Mar 20 15:55:54 2021
From: report at bugs.python.org (=?utf-8?q?Emil_Stenstr=C3=B6m?=)
Date: Sat, 20 Mar 2021 19:55:54 +0000
Subject: [issue43535] Make str.join auto-convert inputs to strings.
In-Reply-To: <1616034546.27.0.0632217994438.issue43535@roundup.psfhosted.org>
Message-ID: <1616270154.87.0.686695244066.issue43535@roundup.psfhosted.org>


Emil Stenstr?m <emil at emilstenstrom.se> added the comment:

Since the proposal is fully backwards compatible I don?t think preferring the old version is a reason against this nicer API. After all, people that like the current version can continue using it as they do today. 

Teaching Python to beginners is a great way to find the warts of a language (I?ve done it too). In the beginning people struggle with arrays and if-blocks, and having to go into how map and the str constructor work together to get a comma separated list of ints is just too much. Beginners are an important group of programmers that this proposal will clearly benefit.

I?m sure there will be some ?None?-strings that will slip through this, but I think the upside far outweighs the downside in this case.

Big +1 from me.

----------
nosy: +EmilStenstrom

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43535>
_______________________________________

From report at bugs.python.org  Sat Mar 20 16:04:50 2021
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 20 Mar 2021 20:04:50 +0000
Subject: [issue42137] Raise an ImportWarning for calling module_repr() on
 loaders
In-Reply-To: <1603495255.51.0.316157271396.issue42137@roundup.psfhosted.org>
Message-ID: <1616270690.68.0.375632232283.issue42137@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Should try to use __spec__ first, but if it isn't set then fall back on module_repr() and raise an ImportWarning. See Lib/importlib/_bootstrap.py:_module_repr.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42137>
_______________________________________

From report at bugs.python.org  Sat Mar 20 16:23:21 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Mar 2021 20:23:21 +0000
Subject: [issue43517] Fix false positives in circular import detection with
 from-imports
In-Reply-To: <1615911063.74.0.357076415367.issue43517@roundup.psfhosted.org>
Message-ID: <1616271801.73.0.376780919554.issue43517@roundup.psfhosted.org>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
pull_requests: +23708
pull_request: https://github.com/python/cpython/pull/24950

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43517>
_______________________________________

From report at bugs.python.org  Sat Mar 20 16:29:23 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 20 Mar 2021 20:29:23 +0000
Subject: [issue43481] PyEval_EvalCode() namespace issue not observed in Python
 2.7.
In-Reply-To: <1615585477.01.0.106665214672.issue43481@roundup.psfhosted.org>
Message-ID: <1616272163.17.0.162989690168.issue43481@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Foolish me. Commenting out the first exec results in the 2nd exec raising.  Commenting out the 2nd exec also results in the class code raising, which is what I expected.  The point of the class code is to partially explain the exception, which is not a bug, but a consequence of passing separate global and initial local namespaces, combined with comprehensions being executed, starting in 3.0, in a new local namespace, separate from the one you passed in.

The exec doc in https://docs.python.org/3/library/functions.html#exec explains the effect of passing different global and local namespaces with "If exec gets two separate objects as globals and locals, the code will be executed as if it were embedded in a class definition."  There is no class, but this is the only way to get the same effect in Python code (without exec/eval).

The NameError has nothing to do with subscripting as it happens upon the attempt to load c.  Remove the subscription and the exception it remains.  Instead, it arises because in 3.x, but not in 2.x, comprehensions are executed in a separate local namespace, the same as a method, where the passed in local namespace is invisible.

Here are simpler examples that both raise NameError.

exec("c=1\nlist(c for i in [1])", globals(), {})
----

class A:
    c =1
    def f(self): c

A().f()

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43481>
_______________________________________

From report at bugs.python.org  Sat Mar 20 16:46:07 2021
From: report at bugs.python.org (miss-islington)
Date: Sat, 20 Mar 2021 20:46:07 +0000
Subject: [issue43517] Fix false positives in circular import detection with
 from-imports
In-Reply-To: <1615911063.74.0.357076415367.issue43517@roundup.psfhosted.org>
Message-ID: <1616273167.22.0.0482346764919.issue43517@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 66c8adfa27aeea004657ef29b6db4e4c360ad611 by Antoine Pitrou in branch 'master':
bpo-43517 (followup): Install additional test directory (GH-24950)
https://github.com/python/cpython/commit/66c8adfa27aeea004657ef29b6db4e4c360ad611


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43517>
_______________________________________

From report at bugs.python.org  Sat Mar 20 17:01:25 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Mar 2021 21:01:25 +0000
Subject: [issue43517] Fix false positives in circular import detection with
 from-imports
In-Reply-To: <1615911063.74.0.357076415367.issue43517@roundup.psfhosted.org>
Message-ID: <1616274085.46.0.12078583543.issue43517@roundup.psfhosted.org>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
pull_requests: +23709
pull_request: https://github.com/python/cpython/pull/24951

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43517>
_______________________________________

From report at bugs.python.org  Sat Mar 20 17:28:24 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 20 Mar 2021 21:28:24 +0000
Subject: [issue43535] Make str.join auto-convert inputs to strings.
In-Reply-To: <1616034546.27.0.0632217994438.issue43535@roundup.psfhosted.org>
Message-ID: <1616275704.68.0.17074531942.issue43535@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I read all the responses as of this timestamp. They left me more persuaded that joining objects with a string (or bytes) is explicit enough that the objects *must* be coerced to strings.

A problem with coercion in "1 + '2'" is that there is no 'must'.  The desired answer could be either 3 or '12', and neither can be converted to the other, so don't guess.

The desired answer for "1 + .5" is much more obviously 1.5 rather than either 1 or 2, plus the former avoids information loss and leaves the option available of rounding or converting however one wants.

One tweet answered my question about masking a bug. Suppose 'words' is intended to be an iterable of strings.

>>> words = ['This', 'is', 'a', 'list', 'of', 7, 'words']  # Buggy
>>> print(*words)  # Auto-coercion masks the bug.
This is a list of 7 words
>>> '-'.join(words)  # Current .join does not.
Traceback (most recent call last):
  File "<pyshell#8>", line 1, in <module>
    '-'.join(words)
TypeError: sequence item 5: expected str instance, int found

With the proposed change, detection of the bug is delayed, as is already the case with print.  How much do we care about this possibility?  One possible answer is to add a new method, such as 'joins' or builtin function 'join'.

Given the variety of opinions, I think a PEP and SC decision would be needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43535>
_______________________________________

From report at bugs.python.org  Sat Mar 20 17:43:31 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 20 Mar 2021 21:43:31 +0000
Subject: [issue43535] Make str.join auto-convert inputs to strings.
In-Reply-To: <1616034546.27.0.0632217994438.issue43535@roundup.psfhosted.org>
Message-ID: <1616276611.11.0.219921166963.issue43535@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

-10.  I agree with Serhiy.  Automatic type conversion is rarely a feature.  It leads to silent bugs when people pass the wrong things.  Be explicit.

We are intentionally not one of those everything is really a string languages like Perl or Javascript.

This core API behavior change is big enough to need a PEP and steering council approval.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43535>
_______________________________________

From report at bugs.python.org  Sat Mar 20 17:47:51 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 20 Mar 2021 21:47:51 +0000
Subject: [issue43569] test_importlib failed on installed Python
In-Reply-To: <1616252286.95.0.663253122373.issue43569@roundup.psfhosted.org>
Message-ID: <1616276871.02.0.773044114246.issue43569@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Oh, "installed python". So maybe Python requires one register files in more than one place to add them to the installation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43569>
_______________________________________

From report at bugs.python.org  Sat Mar 20 17:50:16 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 20 Mar 2021 21:50:16 +0000
Subject: [issue43517] Fix false positives in circular import detection with
 from-imports
In-Reply-To: <1615911063.74.0.357076415367.issue43517@roundup.psfhosted.org>
Message-ID: <1616277016.54.0.470314269316.issue43517@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

Thanks Antoine!

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43517>
_______________________________________

From report at bugs.python.org  Sat Mar 20 17:51:02 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Mar 2021 21:51:02 +0000
Subject: [issue43572] "Too many open files" on macOS buildbot
Message-ID: <1616277062.42.0.179950736754.issue43572@roundup.psfhosted.org>


New submission from Antoine Pitrou <pitrou at free.fr>:

See https://buildbot.python.org/all/#/builders/366/builds/960/steps/5/logs/stdio

----------
messages: 389184
nosy: mattbillenstein, pablogsal, pitrou, zach.ware
priority: normal
severity: normal
status: open
title: "Too many open files" on macOS buildbot

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43572>
_______________________________________

From report at bugs.python.org  Sat Mar 20 17:52:07 2021
From: report at bugs.python.org (miss-islington)
Date: Sat, 20 Mar 2021 21:52:07 +0000
Subject: [issue43517] Fix false positives in circular import detection with
 from-imports
In-Reply-To: <1615911063.74.0.357076415367.issue43517@roundup.psfhosted.org>
Message-ID: <1616277127.23.0.804055294526.issue43517@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 107cf078910db7c1cafdd486270ba8083d72aed7 by Antoine Pitrou in branch '3.9':
[3.9] bpo-43517 (followup): Install additional test directory (GH-24950) (GH-24951)
https://github.com/python/cpython/commit/107cf078910db7c1cafdd486270ba8083d72aed7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43517>
_______________________________________

From report at bugs.python.org  Sat Mar 20 17:52:36 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Mar 2021 21:52:36 +0000
Subject: [issue43517] Fix false positives in circular import detection with
 from-imports
In-Reply-To: <1615911063.74.0.357076415367.issue43517@roundup.psfhosted.org>
Message-ID: <1616277156.45.0.592693802365.issue43517@roundup.psfhosted.org>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43517>
_______________________________________

From report at bugs.python.org  Sat Mar 20 17:54:24 2021
From: report at bugs.python.org (Robert Pollak)
Date: Sat, 20 Mar 2021 21:54:24 +0000
Subject: [issue43547] support ZIP files with zeroed out fields (e.g. for
 reproducible builds)
In-Reply-To: <1616102738.26.0.451702371832.issue43547@roundup.psfhosted.org>
Message-ID: <1616277264.75.0.856313951988.issue43547@roundup.psfhosted.org>


Change by Robert Pollak <robert.pollak at posteo.net>:


----------
nosy: +jondo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43547>
_______________________________________

From report at bugs.python.org  Sat Mar 20 17:59:06 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 20 Mar 2021 21:59:06 +0000
Subject: [issue43569] test_importlib failed on installed Python
In-Reply-To: <1616252286.95.0.663253122373.issue43569@roundup.psfhosted.org>
Message-ID: <1616277546.1.0.684345415623.issue43569@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
keywords: +patch
pull_requests: +23710
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24952

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43569>
_______________________________________

From report at bugs.python.org  Sat Mar 20 18:01:36 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 20 Mar 2021 22:01:36 +0000
Subject: [issue43520] Make Fraction(string) handle non-ascii slashes
In-Reply-To: <1615918144.03.0.939769511159.issue43520@roundup.psfhosted.org>
Message-ID: <1616277696.36.0.86340511909.issue43520@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

The proposal I like is for a unicode numeric normalization functions that return the ascii equivalent to exist.

These ideally belong in a third party PyPI library anyways, as they're the kind of thing that needs updating every time a new unicode revision comes out.  And there are often multiple cultural interpretations for some symbols, despite any standard, so you'd wind up with a variety of functions and options for which behavior to obtain.  That isn't the kind of thing that make for a good stdlib.

Doing this by default within the language syntax itself (and thus stdlib constructors) is potentially dangerous and confusing as everything in existence in the world today that processes Python source code already has baked in single-ascii-token assumptions.  While parsing and tooling could be evolved for that, it'd be a major ecosystem impacting change.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43520>
_______________________________________

From report at bugs.python.org  Sat Mar 20 18:02:11 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 20 Mar 2021 22:02:11 +0000
Subject: [issue43520] Make Fraction(string) handle non-ascii slashes
In-Reply-To: <1615918144.03.0.939769511159.issue43520@roundup.psfhosted.org>
Message-ID: <1616277731.07.0.537816122013.issue43520@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43520>
_______________________________________

From report at bugs.python.org  Sat Mar 20 18:05:02 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 20 Mar 2021 22:05:02 +0000
Subject: [issue43571] Add option to create MPTCP sockets
Message-ID: <1616277902.89.0.378904885058.issue43571@roundup.psfhosted.org>


New submission from Gregory P. Smith <greg at krypto.org>:


New changeset b05b48dd7ab68bf0046356f2abd6d7fe3b5b3d77 by Rui Cunha in branch 'master':
bpo-43571: Add IPPROTO_MPTCP macro (GH-24946)
https://github.com/python/cpython/commit/b05b48dd7ab68bf0046356f2abd6d7fe3b5b3d77


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43571>
_______________________________________

From report at bugs.python.org  Sat Mar 20 18:06:54 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 20 Mar 2021 22:06:54 +0000
Subject: [issue43571] Add option to create MPTCP sockets
In-Reply-To: <1616277902.89.0.378904885058.issue43571@roundup.psfhosted.org>
Message-ID: <1616278014.73.0.30224137296.issue43571@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

Thanks for the contribution!

Simple constant addition.  I ignored the contributor CLA status as a result.  There's only one way to write this non-logic plumbing.

----------
assignee:  -> gregory.p.smith
resolution:  -> fixed
stage: patch review -> commit review
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43571>
_______________________________________

From report at bugs.python.org  Sat Mar 20 18:08:40 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 20 Mar 2021 22:08:40 +0000
Subject: [issue27602] Enable py launcher to launch repository Python.
In-Reply-To: <1469306499.45.0.411476180863.issue27602@psf.upfronthosting.co.za>
Message-ID: <1616278120.06.0.224757684706.issue27602@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27602>
_______________________________________

From report at bugs.python.org  Sat Mar 20 18:10:11 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 20 Mar 2021 22:10:11 +0000
Subject: [issue29178] Adding bytes.frombuffer(byteslike) constructor
In-Reply-To: <1483701377.3.0.893514886442.issue29178@psf.upfronthosting.co.za>
Message-ID: <1616278211.49.0.00313397246688.issue29178@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
stage:  -> patch review
versions:  -Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29178>
_______________________________________

From report at bugs.python.org  Sat Mar 20 18:13:06 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 20 Mar 2021 22:13:06 +0000
Subject: [issue43487] Rename __unicode__ methods to __str__ in 2to3 conversion
In-Reply-To: <1615652086.71.0.102921679786.issue43487@roundup.psfhosted.org>
Message-ID: <1616278386.71.0.959889272418.issue43487@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

We're not accepting anything new into lib2to3 anymore as it is deprecated and slated for eventual removal.  I recommend putting any fixers you develop up as on PyPI as package(s) for others to use.

----------
nosy: +gregory.p.smith
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43487>
_______________________________________

From report at bugs.python.org  Sat Mar 20 18:13:48 2021
From: report at bugs.python.org (=?utf-8?q?Emil_Stenstr=C3=B6m?=)
Date: Sat, 20 Mar 2021 22:13:48 +0000
Subject: [issue43535] Make str.join auto-convert inputs to strings.
In-Reply-To: <1616034546.27.0.0632217994438.issue43535@roundup.psfhosted.org>
Message-ID: <1616278428.01.0.846997309497.issue43535@roundup.psfhosted.org>


Emil Stenstr?m <emil at emilstenstrom.se> added the comment:

Terry, Gregory: The suggestion is not to change what 1 + "2" does, I fully agree that it behaves at it should. The suggestion is to change what ",".join(1, "2") does. There's no doubt that the intended result is "1, 2". That's why it's possible to coerce.

About the example with a list with mixed types: If the reason that example is buggy is "this list should only have strings", a better way to enforce that is to add types to enforces it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43535>
_______________________________________

From report at bugs.python.org  Sat Mar 20 18:26:35 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 20 Mar 2021 22:26:35 +0000
Subject: [issue37871] Windows: WindowsConsoleIO produces mojibake for strings
 longer than 32 KiB
In-Reply-To: <1565915764.5.0.613301280158.issue37871@roundup.psfhosted.org>
Message-ID: <1616279195.89.0.882657824378.issue37871@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

Steve's approach makes sense and should be robust.

side note: do we need to care about Windows 7 anymore in 3.10 given that microsoft no longer supports it?

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37871>
_______________________________________

From report at bugs.python.org  Sat Mar 20 18:45:22 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 20 Mar 2021 22:45:22 +0000
Subject: [issue43542] Add image/heif(heic) to list of media types in
 mimetypes.py
In-Reply-To: <1616067246.11.0.218850830146.issue43542@roundup.psfhosted.org>
Message-ID: <1616280322.33.0.221257790879.issue43542@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43542>
_______________________________________

From report at bugs.python.org  Sat Mar 20 18:50:58 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 20 Mar 2021 22:50:58 +0000
Subject: [issue43535] Make str.join auto-convert inputs to strings.
In-Reply-To: <1616034546.27.0.0632217994438.issue43535@roundup.psfhosted.org>
Message-ID: <1616280658.85.0.982106095212.issue43535@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

There is a lot of doubt.  That should clearly raise an exception because this function is intended to only operate on strings.

Trivial types examples like that gloss over the actual problem.

data_from_some_computations = [b"foo", b"bar"]  # probably returned by a function

... later on, some other place in the code ...

colon_sep_data = ":".join(data_from_some_computations)

I guarantee you that 99.999% of the time everyone wants an exception there instead of their colon_sep_data to contain `b"foo":b"bar"`.

Implicit conversions always lead to hard to pin down bugs.  An exception raised at the source of the problem is very easy to debug in comparison.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43535>
_______________________________________

From report at bugs.python.org  Sat Mar 20 18:56:30 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 20 Mar 2021 22:56:30 +0000
Subject: [issue33240] shutil.rmtree fails if inner folder is open in Windows
 Explorer
In-Reply-To: <1523155916.86.0.682650639539.issue33240@psf.upfronthosting.co.za>
Message-ID: <1616280990.77.0.995576389508.issue33240@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

Isn't this just "how windows behaves" on some filesystems with little that we can do about it?

The only real action item I can see here is that if it is _reasonable_ for us to detect the situation and improve the error message, that'd help the users (and reduce bugreports like this).

Otherwise I suggest closing it as wont fix / working as the platform intends.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33240>
_______________________________________

From report at bugs.python.org  Sat Mar 20 19:02:12 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 20 Mar 2021 23:02:12 +0000
Subject: [issue43569] test_importlib failed on installed Python
In-Reply-To: <1616252286.95.0.663253122373.issue43569@roundup.psfhosted.org>
Message-ID: <1616281332.11.0.637043850712.issue43569@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I've submitted a PR and triggered build by buildbots, but I don't see that the indicated builder is building the PR. Shall I just submit and see what happens? Any other ideas how to verify the installed builder buildbots?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43569>
_______________________________________

From report at bugs.python.org  Sat Mar 20 19:05:25 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 20 Mar 2021 23:05:25 +0000
Subject: [issue43552] Add locale.get_locale_encoding() and
 locale.get_current_locale_encoding()
In-Reply-To: <1616145433.55.0.350148222552.issue43552@roundup.psfhosted.org>
Message-ID: <1616281525.24.0.605949642762.issue43552@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> In my experience, most applications use the ANSI code page because 
> they use the ANSI flavor of the Windows API.

The default encoding at startup and in the "C" locale wouldn't change. It would only differ from the default if setlocale(LC_CTYPE, locale_name) sets it otherwise. The suggestion is to match the behavior of nl_langinfo(CODESET) in Linux and many other POSIX systems.

When I say the default encoding won't change, I mean that the Universal C Runtime (ucrt) system component uses the process ANSI code page as the default locale encoding for setlocale(LC_CTYPE, ""). This agrees with what Python has always done, but it disagrees with previous versions of the CRT in Windows. Personally, I think it's a misstep because the user locale isn't necessarily compatible with the process code page, but I'm not looking to change this decision. For example, if the user locale is "el_GR" (Greek, Greece) but the process code page is 1252 (Latin) instead of 1253 (Greek), I get the following result in Python 3.4 (VC++ 10) vs Python 3.5 (ucrt):

    >py -3.4 -c "from locale import *; print(setlocale(LC_CTYPE, ''))"
    Greek_Greece.1253

    >py -3.5 -c "from locale import *; print(setlocale(LC_CTYPE, ''))"
    Greek_Greece.1252

The result from VC++ 10 is consistent with the user locale. It's also consistent with multilingual user interface (MUI) text, such as error messages, or at least it should be, because the user locale and user preferred language (i.e. Windows display language) should be consistent. (The control panel dialog to set the user locale in Windows 10 has an option to match the display language, which is the recommended and default setting.)  For example, Python uses system error messages that are localized to the user's preferred language:

    >py -c "import os; os.stat('spam')"
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
    FileNotFoundError: [WinError 2] ??? ????? ?????? ? ?????? ??? ???????????? ??????? ??? ?? ???????: 'spam'

This example is on a system where the process (system) ANSI code page is 1252 (Latin), which cannot encode the user's preferred Greek text. Thankfully Python 3.6+ uses the console's Unicode API, so neither the console session's output code page nor the process code page gets in the way. On the other hand, if this Greek text is written to a file or piped to a child process using subprocess.Popen(), Python's choice of locale encoding based on the process code page (Latin) is incompatible with Greek text, and thus it's incompatible with the current user's preferred locale and language settings.

The process ANSI code page from GetACP() has its uses, which are important. It's a system setting that's independent of the current user locale and thus useful when interacting with the legacy system API and as a common encoding for inter-process data exchange when applications do not use Unicode and may be operating in different locales. So if you're writing to a legacy-encoded text file that's shared by multiple users or piping text to an arbitrary program, then using the ANSI code page is probably okay. Though, especially for IPC, there's a good chance that's it's wrong since Windows has never set, let alone enforced, a standard in that case. 

Using the process ANSI code page in the "C" locale makes sense to me. 

> What is the use case for using ___lc_codepage()? Is it a different 
> encoding?

I always forget the "_func" suffix in the name; it's ___lc_codepage_func() [1]. The lc_codepage value is the current LC_CTYPE codeset as an integer code page. It's the equivalent of nl_langinfo(CODESET) in POSIX. For UTF-8, the code page is CP_UTF8 (65001), but this get displayed in locale strings as "UTF-8" (or variants such as "utf8"). It could be the LC_CTYPE encoding of just the current thread, but Python does not enable per-thread locales.

The CRT has exported ___lc_codepage_func() since VC++ 7.0 (2002), and before that the current lc_codepage value itself was directly exported as __lc_codepage. However, this triple-dundered function is documented as internal and not recommended for use. That's why the code snippet I showed uses _get_current_locale() with locinfo cast to __crt_locale_data_public *. This takes "public" in the struct name at face value. Anything that's declared public should be safe to use, but the locale_t type is frustratingly undocumented even for this public data [2].

If neither approach is supported, locale.get_current_locale_encoding() could instead parse the current locale encoding from setlocale(LC_CTYPE, NULL). The resulting locale string usually includes the codeset (e.g. "Greek_Greece.1253"). The exceptions are the "C" locale and BCP-47 (RFC 5646) locales that do not explicitly use UTF-8 (e.g. "el_GR" or "el" instead of "el_GR.UTF-8"), but these cases can be handled reliably.

---

[1] https://docs.microsoft.com/en-us/cpp/c-runtime-library/lc-codepage-func
[2] https://docs.microsoft.com/en-us/cpp/c-runtime-library/locale

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43552>
_______________________________________

From report at bugs.python.org  Sat Mar 20 19:05:48 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 20 Mar 2021 23:05:48 +0000
Subject: [issue38890] subprocess.Popen should not emit a ResourceWarning for a
 detached process
In-Reply-To: <1574381050.02.0.817865416124.issue38890@roundup.psfhosted.org>
Message-ID: <1616281548.37.0.199393812943.issue38890@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

On POSIX the norm for anything daemonizing itself is to fork() and let the parent die so that its original process with the child pid has ended.  But I'm used to this being the responsibility of the daemon process.  Not the code launching the daemon.

Related, a deferred PEP on supporting any form of daemon stuff in the stdlib:  https://www.python.org/dev/peps/pep-3143/ along with https://pypi.org/project/python-daemon/ and a plethora of other daemon/daemonize related PyPI libraries.

Those tend to be about implement proper become a daemon behavior in Python processes themselves.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38890>
_______________________________________

From report at bugs.python.org  Sat Mar 20 19:06:32 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 20 Mar 2021 23:06:32 +0000
Subject: [issue43542] Add image/heif(heic) to list of media types in
 mimetypes.py
In-Reply-To: <1616067246.11.0.218850830146.issue43542@roundup.psfhosted.org>
Message-ID: <1616281592.88.0.152196138139.issue43542@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:


New changeset 20a5b7e986377bdfd929d7e8c4e3db5847dfdb2d by Ilya Stepin in branch 'master':
bpo-43542: Add heif/heic formats in mimetypes (GH-24917)
https://github.com/python/cpython/commit/20a5b7e986377bdfd929d7e8c4e3db5847dfdb2d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43542>
_______________________________________

From report at bugs.python.org  Sat Mar 20 19:06:52 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 20 Mar 2021 23:06:52 +0000
Subject: [issue43542] Add image/heif(heic) to list of media types in
 mimetypes.py
In-Reply-To: <1616067246.11.0.218850830146.issue43542@roundup.psfhosted.org>
Message-ID: <1616281612.77.0.0709052664738.issue43542@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43542>
_______________________________________

From report at bugs.python.org  Sat Mar 20 19:12:59 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 20 Mar 2021 23:12:59 +0000
Subject: [issue43080] pprint for dataclass instances
In-Reply-To: <1612052078.12.0.741479641556.issue43080@roundup.psfhosted.org>
Message-ID: <1616281979.51.0.135900812225.issue43080@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

+0.5 I lean towards just accepting this under the conditions Eric describes given that dataclass is a stdlib concept and nobody is likely to claim that such output from pprint is a bad thing.

The larger "some form of protocol for pprint to work on all sorts of other things" issue (regardless of how) remains a long term wish list item that'll probably wind up in PEP land if someone wants to take it on.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43080>
_______________________________________

From report at bugs.python.org  Sat Mar 20 19:14:46 2021
From: report at bugs.python.org (Felix C. Stegerman)
Date: Sat, 20 Mar 2021 23:14:46 +0000
Subject: [issue43547] support ZIP files with zeroed out fields (e.g. for
 reproducible builds)
In-Reply-To: <1616102738.26.0.451702371832.issue43547@roundup.psfhosted.org>
Message-ID: <1616282086.08.0.838568506195.issue43547@roundup.psfhosted.org>


Change by Felix C. Stegerman <flx at obfusk.net>:


----------
nosy: +obfusk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43547>
_______________________________________

From report at bugs.python.org  Sat Mar 20 19:23:36 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 20 Mar 2021 23:23:36 +0000
Subject: [issue42917] Block stack size for frame objects should be dynamically
 sizable
In-Reply-To: <1610502849.77.0.30833881241.issue42917@roundup.psfhosted.org>
Message-ID: <1616282616.79.0.790537935956.issue42917@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/issue42917>
_______________________________________

From report at bugs.python.org  Sat Mar 20 19:25:26 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 20 Mar 2021 23:25:26 +0000
Subject: [issue32592] Drop support of Windows Vista and Windows 7
In-Reply-To: <1516268238.05.0.467229070634.issue32592@psf.upfronthosting.co.za>
Message-ID: <1616282726.62.0.061056389904.issue32592@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
title: Drop support of Windows Vista and 7 in Python 3.9 -> Drop support of Windows Vista and Windows 7
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32592>
_______________________________________

From report at bugs.python.org  Sat Mar 20 19:32:18 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 20 Mar 2021 23:32:18 +0000
Subject: [issue42914] pprint numbers with underscore
In-Reply-To: <1610493681.29.0.683565759752.issue42914@roundup.psfhosted.org>
Message-ID: <1616283138.83.0.375547642521.issue42914@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/issue42914>
_______________________________________

From report at bugs.python.org  Sat Mar 20 19:35:16 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 20 Mar 2021 23:35:16 +0000
Subject: [issue37871] Windows: WindowsConsoleIO produces mojibake for strings
 longer than 32 KiB
In-Reply-To: <1565915764.5.0.613301280158.issue37871@roundup.psfhosted.org>
Message-ID: <1616283316.34.0.10735093183.issue37871@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> side note: do we need to care about Windows 7 anymore in 
> 3.10 given that microsoft no longer supports it?

If the fix comes in time for Python 3.8, then it needs to support Windows 7. For Python 3.9+, the 32 KiB limit can be removed. 

The console documentation still includes the misleading disclaimer about "available heap". This refers to a relatively small block of shared memory (64 KiB IIRC) that's overlayed by a heap, not the default process heap. Shared memory is used by system LPC ports to efficiently pass large messages between a system server (e.g. csrss.exe, conhost.exe) and a client process. The console API used to use an LPC port, but in Windows 8.1+ it uses a driver instead, so none of the "available heap" warnings apply anymore. Microsoft should clarify the docs to stress that the warning is for Windows 7 and earlier.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37871>
_______________________________________

From report at bugs.python.org  Sat Mar 20 19:47:29 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 20 Mar 2021 23:47:29 +0000
Subject: [issue33240] shutil.rmtree fails if inner folder is open in Windows
 Explorer
In-Reply-To: <1523155916.86.0.682650639539.issue33240@psf.upfronthosting.co.za>
Message-ID: <1616284049.66.0.452341849486.issue33240@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> Isn't this just "how windows behaves" on some filesystems with 
> little that we can do about it?

The suggestion was to include an error handler that retries unlink() and rmdir() -- particularly rmdir() -- a given number of times, probably with an exponential back off, before giving up and failing. This accounts for race conditions in which the delete succeeds but the file/directory can't be unlinked because it's currently open (with delete sharing). A lot of these cases are similar to ReadDirectoryChangesExW(), in which the owner of the open is immediately notified that the directory was deleted. If they're well behaved, like Explorer, they immediately close their handle to allow the directory to be unlinked by the system. But that may not be soon enough for the process that deleted the directory. The suggested retry loop would help to work around this race condition. A couple people were in favor of this being provided by the standard library, so everyone isn't forced to implement there own workaround for a common problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33240>
_______________________________________

From report at bugs.python.org  Sat Mar 20 19:53:14 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 20 Mar 2021 23:53:14 +0000
Subject: [issue33240] shutil.rmtree fails if inner folder is open in Windows
 Explorer
In-Reply-To: <1523155916.86.0.682650639539.issue33240@psf.upfronthosting.co.za>
Message-ID: <1616284394.08.0.835664153681.issue33240@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

oh, I missed that a notification happens to the other process(es) in a common case, a bit of retrying with backoff would actually make sense there.  But I wouldn't let a retry run for longer than a second or three, as code tends to assume that rmtree is pretty quick and if something is going to close asynchronously, it should close quickly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33240>
_______________________________________

From report at bugs.python.org  Sat Mar 20 20:05:17 2021
From: report at bugs.python.org (Ben Buchwald)
Date: Sun, 21 Mar 2021 00:05:17 +0000
Subject: [issue40894] asyncio.gather() cancelled() always False
In-Reply-To: <1591481631.01.0.634103349075.issue40894@roundup.psfhosted.org>
Message-ID: <1616285117.76.0.783629114143.issue40894@roundup.psfhosted.org>


Ben Buchwald <sparkyb at gmail.com> added the comment:

Hopefully I'm not too late to comment on this. I also just hit this issue, but I do not agree with the proposed PR. Only modifying _GatheringFuture.cancelled() just fixes one of the side-effects of the problem. The state of the future is still FINISHED and not CANCELLED and there are still other differences that can be observed due to this. When calling .exception() a cancelled future should *raise* a CancelledError, but with a _GatheringFuture it will return a CancelledError regardless of the value that .cancelled() returns. Also, if you don't fetch the exception of a future, when it gets deleted it will warn you, but this is not supposed to happen with cancellation. This unexpected warning was how I discovered that I have this issue, and the proposed fix doesn't solve my case.

Instead of overriding .cancelled() on _GatheringFuture, gather() should be updated to actually cancel the _GatheringFuture. I suggest that in gather's _done_callback this:

if outer._cancel_requested:
    # If gather is being cancelled we must propagate the
    # cancellation regardless of *return_exceptions* argument.
    # See issue 32684.
    exc = fut._make_cancelled_error()
    outer.set_exception(exc)

Should be changed to:

if outer._cancel_requested:
    # If gather is being cancelled we must propagate the
    # cancellation regardless of *return_exceptions* argument.
    # See issue 32684.
    exc = fut._make_cancelled_error()
    super(_GatheringFuture, other).cancel(fut._cancel_message)

This alone would only fix it in the return_exceptions=True case. To fix it when return_exceptions=False, a bit higher up in the same function, change:

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 = fut._make_cancelled_error()
        outer.set_exception(exc)
        return

to:

if not return_exceptions:
    if fut.cancelled():
        # Check if 'fut' is cancelled first, as
        # 'fut.exception()' will *raise* a CancelledError
        # instead of returning it.
        if outer._cancel_requested:
          super(_GatheringFuture, outer).cancel(fut._cancel_message)
        else:
          exc = fut._make_cancelled_error()
          outer.set_exception(exc)
        return

This case is a little trickier. Notice that I added a new if. As Caleb and Kyle pointed out, a task gets cancelled implicitly if its child gets cancelled. To be consistent with that behavior, you wouldn't actually care if _cancel_requested is set, if you'd always just call the super cancel. However, I actually think that gather *should* differ from Task here. A task wraps a single coroutine. If that coroutine is cancelled it makes sense that the task is implicitly cancelled. But with gather, I'm not convinced that cancelling one of the children should apply to the whole gather. It think it makes more sense that one child being cancelled would be treated as an exceptional return of the collection.

The one other thing I'd change is that I'd not actually use fut._cancel_message as I do in those examples above. I'd save the original message in _GatheringFuture.cancel() when setting _cancel_requested, and then use outer._cancel_message. I've attached The whole code I would suggest. I don't have time right now to make my own PR, but since Timm already has an open PR, hopefully this helps.

----------
nosy: +sparkyb
Added file: https://bugs.python.org/file49895/gather.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40894>
_______________________________________

From report at bugs.python.org  Sat Mar 20 20:29:42 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 21 Mar 2021 00:29:42 +0000
Subject: [issue33240] shutil.rmtree fails if inner folder is open in Windows
 Explorer
In-Reply-To: <1523155916.86.0.682650639539.issue33240@psf.upfronthosting.co.za>
Message-ID: <1616286582.71.0.348335764683.issue33240@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> oh, I missed that a notification happens to the other process(es) in a 
> common case, a bit of retrying with backoff would actually make sense 

The other common problem with deleting an empty directory is when it's opened as the working directory of a process. This case fails as a sharing violation because the open doesn't share delete access. There's nothing reasonable to do about it without user interaction, which would be a complicated bit of code: find the process that has the directory open, display a message to the user in the desktop session of the process, and wait for a response. That's not a good candidate for the standard library.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33240>
_______________________________________

From report at bugs.python.org  Sat Mar 20 21:13:24 2021
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 21 Mar 2021 01:13:24 +0000
Subject: [issue43573] [types] Document __spec__ for types.ModuleType
Message-ID: <1616289204.63.0.465511334804.issue43573@roundup.psfhosted.org>


New submission from Brett Cannon <brett at python.org>:

https://docs.python.org/3/library/types.html#types.ModuleType does not document __spec__.

----------
assignee: docs at python
components: Documentation
messages: 389204
nosy: brett.cannon, docs at python
priority: normal
severity: normal
status: open
title: [types] Document __spec__ for types.ModuleType
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43573>
_______________________________________

From report at bugs.python.org  Sat Mar 20 21:37:23 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 21 Mar 2021 01:37:23 +0000
Subject: [issue42914] pprint numbers with underscore
In-Reply-To: <1610493681.29.0.683565759752.issue42914@roundup.psfhosted.org>
Message-ID: <1616290643.72.0.799300354397.issue42914@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I don't think underscores can be on by default.  It needs to be opt-in to be backwards compatible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42914>
_______________________________________

From report at bugs.python.org  Sat Mar 20 22:28:45 2021
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 21 Mar 2021 02:28:45 +0000
Subject: [issue42137] Prefer using __spec__ over module_repr() for
 ModuleType.__repr__
In-Reply-To: <1603495255.51.0.316157271396.issue42137@roundup.psfhosted.org>
Message-ID: <1616293725.61.0.902191866837.issue42137@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Thinking about it more, raising ImportWarning (or DeprecationWarning) is unnecessarily noisy as the existence of the module isn't problematic, it just won't be used anymore in the future. So updating the code to use __spec__ first and then document in "What's New" should be good enough.

----------
assignee:  -> brett.cannon
title: Raise an ImportWarning for calling module_repr() on loaders -> Prefer using __spec__ over module_repr() for ModuleType.__repr__

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42137>
_______________________________________

From report at bugs.python.org  Sat Mar 20 22:31:54 2021
From: report at bugs.python.org (Chad Netzer)
Date: Sun, 21 Mar 2021 02:31:54 +0000
Subject: [issue43574] Regression in overallocation for literal list
 initialization in v3.9+
Message-ID: <1616293914.75.0.599644741052.issue43574@roundup.psfhosted.org>


New submission from Chad Netzer <chad.netzer at gmail.com>:

In Python v3.9+ there was a regression in the amount of used memory for
list-literals, due to switching to using list_extend() to allocate memory for
the new list to accomodate the literal elements.

Example, in Python v3.8.x (and before):
```
$ python38
Python 3.8.5 (default, Sep  4 2020, 02:22:02)
>>> [1].__sizeof__()
48
>>> [1,2].__sizeof__()
56
>>> [1,2,3].__sizeof__()
64
```

whereas for v3.9 (and later):
```
$ python39
Python 3.9.2 (default, Feb 19 2021, 17:09:53)
>>> [1].__sizeof__()
48
>>> [1,2].__sizeof__()
56
>>> [1,2,3].__sizeof__()
104  # a 60% increase in memory allocated
```

However, this seems like an unintented regression, and is a side-effect of the
new way of building the lists from literals, using the list_extend() function (via
list_resize(), which overallocates).  In particular, a consequence is that
making a copy of the list that's initialized from a literal can end up using
less memory:
```
$ python39
Python 3.9.2 (default, Feb 19 2021, 17:09:53)
>>> a = [1,2,3]
>>> b = list(a)  # Same behavior if list.copy() or slice copy is performed
>>> a.__sizeof__()
104
>>> b.__sizeof__()
64
```

Prior to v3.9, the byte-code for making a list from a literal had the
"BUILD_LIST" opcode with an explicit length argument, allowing allocation of
the exact amount of memory needed for the literal.  As of v3.9, the
LIST_EXTEND opcode is used, instead.  I believe the simplest way of restoring
the old behavior is to change list_extend() to not overallocate when the list
being extended currently has 0 elements.


Ie. a minimal-change patch to restore the previous behavior (though with a
side-effect of removing the overallocaton of a list that is initialzed empty,
and then immediately extended):

diff --git a/Objects/listobject.c b/Objects/listobject.c
index e7987a6d35..7820e033af 100644
--- a/Objects/listobject.c
+++ b/Objects/listobject.c
@@ -75,8 +75,9 @@ list_resize(PyListObject *self, Py_ssize_t newsize)
     if (newsize - Py_SIZE(self) > (Py_ssize_t)(new_allocated - newsize))
         new_allocated = ((size_t)newsize + 3) & ~(size_t)3;

-    if (newsize == 0)
-        new_allocated = 0;
+    /* Don't overallocate for lists that start empty or are set to empty. */
+    if (newsize == 0 || Py_SIZE(self) == 0)
+        new_allocated = newsize;
     num_allocated_bytes = new_allocated * sizeof(PyObject *);
     items = (PyObject **)PyMem_Realloc(self->ob_item, num_allocated_bytes);
     if (items == NULL) {



Relevant/related bugs/PRs:
# Switched to initializing list literals w/ LIST_EXTEND
https://bugs.python.org/issue39320
https://github.com/python/cpython/pull/17984

# Commit where over-allocation of list literals first appeared
https://bugs.python.org/issue38328
https://github.com/python/cpython/pull/17114
https://github.com/python/cpython/commit/6dd9b64770af8905bef293c81d541eaaf8d8df52

https://bugs.python.org/issue38373
https://github.com/python/cpython/pull/18952
https://github.com/python/cpython/commit/2fe815edd6778fb9deef8f8044848647659c2eb8

----------
components: Interpreter Core
messages: 389207
nosy: Chad.Netzer
priority: normal
severity: normal
status: open
title: Regression in overallocation for literal list initialization in v3.9+
type: resource usage
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43574>
_______________________________________

From report at bugs.python.org  Sat Mar 20 22:33:40 2021
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 21 Mar 2021 02:33:40 +0000
Subject: [issue43574] Regression in overallocation for literal list
 initialization in v3.9+
In-Reply-To: <1616293914.75.0.599644741052.issue43574@roundup.psfhosted.org>
Message-ID: <1616294020.64.0.533224855775.issue43574@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
nosy: +serhiy.storchaka, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43574>
_______________________________________

From report at bugs.python.org  Sat Mar 20 22:33:45 2021
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 21 Mar 2021 02:33:45 +0000
Subject: [issue43574] Regression in overallocation for literal list
 initialization in v3.9+
In-Reply-To: <1616293914.75.0.599644741052.issue43574@roundup.psfhosted.org>
Message-ID: <1616294025.73.0.39030512924.issue43574@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/issue43574>
_______________________________________

From report at bugs.python.org  Sat Mar 20 22:41:53 2021
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 21 Mar 2021 02:41:53 +0000
Subject: [issue42137] Prefer using __spec__ over module_repr() for
 ModuleType.__repr__
In-Reply-To: <1603495255.51.0.316157271396.issue42137@roundup.psfhosted.org>
Message-ID: <1616294513.34.0.866162874321.issue42137@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
dependencies:  -[importlib] deprecate module_repr() methods

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42137>
_______________________________________

From report at bugs.python.org  Sat Mar 20 22:46:37 2021
From: report at bugs.python.org (Matt Billenstein)
Date: Sun, 21 Mar 2021 02:46:37 +0000
Subject: [issue43572] "Too many open files" on macOS buildbot
In-Reply-To: <1616277062.42.0.179950736754.issue43572@roundup.psfhosted.org>
Message-ID: <1616294797.2.0.391173798698.issue43572@roundup.psfhosted.org>


Matt Billenstein <matt at vazor.com> added the comment:

I don't see that error message - where are you seeing it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43572>
_______________________________________

From report at bugs.python.org  Sat Mar 20 22:51:19 2021
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 21 Mar 2021 02:51:19 +0000
Subject: [issue42137] Prefer using __spec__ over module_repr() for
 ModuleType.__repr__
In-Reply-To: <1603495255.51.0.316157271396.issue42137@roundup.psfhosted.org>
Message-ID: <1616295079.43.0.700939695828.issue42137@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
keywords: +patch
pull_requests: +23711
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24953

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42137>
_______________________________________

From report at bugs.python.org  Sat Mar 20 23:10:02 2021
From: report at bugs.python.org (Matt Billenstein)
Date: Sun, 21 Mar 2021 03:10:02 +0000
Subject: [issue43572] "Too many open files" on macOS buildbot
In-Reply-To: <1616277062.42.0.179950736754.issue43572@roundup.psfhosted.org>
Message-ID: <1616296202.45.0.449244395833.issue43572@roundup.psfhosted.org>


Matt Billenstein <matt at vazor.com> added the comment:

In any case - I've raised file/process limits on the buildbot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43572>
_______________________________________

From report at bugs.python.org  Sat Mar 20 23:19:58 2021
From: report at bugs.python.org (Chad Netzer)
Date: Sun, 21 Mar 2021 03:19:58 +0000
Subject: [issue43574] Regression in overallocation for literal list
 initialization in v3.9+
In-Reply-To: <1616293914.75.0.599644741052.issue43574@roundup.psfhosted.org>
Message-ID: <1616296798.17.0.801747815386.issue43574@roundup.psfhosted.org>


Change by Chad Netzer <chad.netzer at gmail.com>:


----------
keywords: +patch
pull_requests: +23712
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24954

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43574>
_______________________________________

From report at bugs.python.org  Sat Mar 20 23:25:03 2021
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 21 Mar 2021 03:25:03 +0000
Subject: [issue43575] map() instantiation time reducing by using PEP 590
 vectorcall
Message-ID: <1616297103.49.0.396627193734.issue43575@roundup.psfhosted.org>


New submission from Dong-hee Na <donghee.na at python.org>:

+-----------+------------------+----------------------+
| Benchmark | map_bench_master | map_bench_vectorcall |
+===========+==================+======================+
| bench map | 151 ns           | 116 ns: 1.30x faster |
+-----------+------------------+----------------------+

We already apply this feature for filter().
No reason not to apply map().

----------
assignee: corona10
components: Interpreter Core
files: map_bench.py
messages: 389210
nosy: corona10, vstinner
priority: normal
severity: normal
status: open
title: map() instantiation time reducing by using PEP 590 vectorcall
type: performance
versions: Python 3.10
Added file: https://bugs.python.org/file49896/map_bench.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43575>
_______________________________________

From report at bugs.python.org  Sat Mar 20 23:27:36 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 21 Mar 2021 03:27:36 +0000
Subject: [issue43572] "Too many open files" on macOS buildbot
In-Reply-To: <1616277062.42.0.179950736754.issue43572@roundup.psfhosted.org>
Message-ID: <1616297256.06.0.655876992158.issue43572@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

>> I don't see that error message - where are you seeing it?


You need to search for it in the full log:


stderr:
---
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/test/test_importlib/partial/pool_in_threads.py", line 9, in t
    with multiprocessing.Pool(1):
  File "/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/multiprocessing/context.py", line 119, in Pool
    return Pool(processes, initializer, initargs, maxtasksperchild,
  File "/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/multiprocessing/pool.py", line 212, in __init__
    self._repopulate_pool()
  File "/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/multiprocessing/pool.py", line 303, in _repopulate_pool
    return self._repopulate_pool_static(self._ctx, self.Process,
  File "/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/multiprocessing/pool.py", line 326, in _repopulate_pool_static
    w.start()
  File "/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/multiprocessing/process.py", line 121, in start
    self._popen = self._Popen(self)
  File "/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/multiprocessing/context.py", line 284, in _Popen
    return Popen(process_obj)
  File "/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/multiprocessing/popen_spawn_posix.py", line 32, in __init__
    super().__init__(process_obj)
  File "/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/multiprocessing/popen_fork.py", line 19, in __init__
    self._launch(process_obj)
  File "/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/multiprocessing/popen_spawn_posix.py", line 42, in _launch
    prep_data = spawn.get_preparation_data(process_obj._name)
  File "/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/multiprocessing/spawn.py", line 176, in get_preparation_data
    dir=os.getcwd(),
OSError: [Errno 24] Too many open files

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43572>
_______________________________________

From report at bugs.python.org  Sat Mar 20 23:28:08 2021
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 21 Mar 2021 03:28:08 +0000
Subject: [issue43575] map() instantiation time reducing by using PEP 590
 vectorcall
In-Reply-To: <1616297103.49.0.396627193734.issue43575@roundup.psfhosted.org>
Message-ID: <1616297288.7.0.833158254437.issue43575@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
keywords: +patch
pull_requests: +23714
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24955

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43575>
_______________________________________

From report at bugs.python.org  Sat Mar 20 23:35:16 2021
From: report at bugs.python.org (Matt Billenstein)
Date: Sun, 21 Mar 2021 03:35:16 +0000
Subject: [issue43572] "Too many open files" on macOS buildbot
In-Reply-To: <1616277062.42.0.179950736754.issue43572@roundup.psfhosted.org>
Message-ID: <1616297716.96.0.0273068706252.issue43572@roundup.psfhosted.org>


Matt Billenstein <matt at vazor.com> added the comment:

Ah, word, was looking at stdout -- 256 is pretty low, raised it to 200k...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43572>
_______________________________________

From report at bugs.python.org  Sat Mar 20 23:36:58 2021
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Sun, 21 Mar 2021 03:36:58 +0000
Subject: [issue43535] Make str.join auto-convert inputs to strings.
In-Reply-To: <1616034546.27.0.0632217994438.issue43535@roundup.psfhosted.org>
Message-ID: <1616297818.21.0.947264406368.issue43535@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

Yes, I know what strong typing means, and can you please read again what I've written? It was exactly about "In the face of ambiguity, refuse the temptation to guess.", because binary operators are inherently ambiguous when given differently typed operands. Methods are not: the method _name_ itself is resolved according to self's type, it seems obvious to me that the arguments should too. Otherwise "explicit fanatics" would probably want to write list.append(things, more) instead of things.append(more).

The only reason we're having this conversation is that when it was introduced, `join` was a function, not a method. If it were a method from the start, we would've never even questioned its stringification of the iterable elements (and of course it would do that from the start, cf. set or dict update methods).

Gregory: yes, `bytes` elements are a problem, but that's a completely orthogonal problem (probably best left for linters). The easiest way to see it: do you object to (the current behavior of)

>>> s = {2, 7}
>>> s.update(b'Veky')

? :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43535>
_______________________________________

From report at bugs.python.org  Sat Mar 20 23:46:26 2021
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 21 Mar 2021 03:46:26 +0000
Subject: [issue43447] Generate vectorcall code to parse arguments using
 Argument Clinic
In-Reply-To: <1615289664.02.0.198288195908.issue43447@roundup.psfhosted.org>
Message-ID: <1616298386.03.0.859634230101.issue43447@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:

I agree with we should update AC to generate vectorcall.
I am going to investigate what we can :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43447>
_______________________________________

From report at bugs.python.org  Sun Mar 21 00:46:52 2021
From: report at bugs.python.org (rushant)
Date: Sun, 21 Mar 2021 04:46:52 +0000
Subject: [issue43576] python3.6.4 os.environ error when write chinese to file
Message-ID: <1616302012.93.0.356074990603.issue43576@roundup.psfhosted.org>


New submission from rushant <953779014 at qq.com>:

# -*- coding: utf-8 -*-
import os
job_name = os.environ['a']
print(job_name)
print(isinstance(job_name, str))
print(type(job_name))
with open('name.txt', 'w', encoding='utf-8')as fw:
    fw.write(job_name)


i have set environment param by :
export a="??"
it returns error:
??
True
<class 'str'>
Traceback (most recent call last):
  File "aa.py", line 8, in <module>
    fw.write(job_name)
UnicodeEncodeError: 'utf-8' codec can't encode characters in position 0-5: surrogates not allowed

----------
components: C API
messages: 389215
nosy: rushant
priority: normal
severity: normal
status: open
title: python3.6.4 os.environ error when write chinese to file
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43576>
_______________________________________

From report at bugs.python.org  Sun Mar 21 01:00:42 2021
From: report at bugs.python.org (Andrew Dailey)
Date: Sun, 21 Mar 2021 05:00:42 +0000
Subject: [issue43577] Deadlock when using SSLContext._msg_callback and
 SSLContext.sni_callback
Message-ID: <1616302842.44.0.286720324373.issue43577@roundup.psfhosted.org>


New submission from Andrew Dailey <steveday168 at gmail.com>:

Hello,

I think I might've stumbled onto an oversight with how an SSLSocket handles overwriting its SSLContext within an sni_callback. If both "_msg_callback" and "sni_callback" are defined on an SSLContext object and the sni_callback replaces the context with new one, the interpreter locks up indefinitely. It fails to respond to keyboard interrupts and must be forcefully killed.

This seems to be a common use case of the sni_callback: create a new context with a different cert chain and attach it to the current socket (which replaces the existing one). If _msg_callback never gets defined on the original context then this deadlock never occurs. Curiously, if you assign the same _msg_callback to the new context before replacement, this also avoids the deadlock.

I've attached as minimal of a reproduction as I could come up with. I think the code within will probably do a better job explaining this problem than I've done here in prose. I've only tested it on a couple Linux distros (Ubuntu Server and Void Linux) but the lock occurs 100% of the time in my experience.

In the brief time I've spent digging into the CPython source, I've come to understand that replacing the SSLContext on an SSLSocket isn't "just" a simple replacement but actually involves some OpenSSL mechanics (specifically, SSL_set_SSL_CTX) [0]. I'm wondering if maybe this context update routine isn't properly cleaning up whatever resources / references were being used by the msg_callback? Maybe this is even closer to an OpenSSL bug (or a least a gotcha)?

I also feel the need to explain why I'd even be using an undocumented property (SSLContext._msg_callback) in the first place. I'm trying to implement a program that automatically manages TLS certs on a socket via Let's Encrypt and the ACME protocol (RFC8555). Part of this process involves serving up a specific cert when a connection requests the acme-tls/1 ALPN protocol. Given the existing Python SSL API, I don't believe there is any way for me to do this "correctly".

The documentation for SSLContext.sni_callback [1] mentions that the selected_alpn_protocol function should be usable within the callback but I don't that is quite true. According to the OpenSSL docs [2]:
Several callbacks are executed during ClientHello processing, including the ClientHello, ALPN, and servername callbacks. The ClientHello callback is executed first, then the servername callback, followed by the ALPN callback.

If there is a better way for me to identify a specific ALPN protocol _before_ the sni_callback, I could definitely use the guidance. That would avoid this deadlock altogether (even though it'd still be waiting to catch someone else...).

This is my first Python issue so I hope what I've supplied makes sense. If there is anything more I can do to help or provide more info, please let me know.

[0] https://github.com/python/cpython/blob/3.9/Modules/_ssl.c#L2194
[1] https://docs.python.org/3/library/ssl.html#ssl.SSLContext.sni_callback
[2] https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_tlsext_servername_callback.html

----------
assignee: christian.heimes
components: SSL
files: deadlock.zip
messages: 389216
nosy: christian.heimes, theandrew168
priority: normal
severity: normal
status: open
title: Deadlock when using SSLContext._msg_callback and SSLContext.sni_callback
type: behavior
versions: Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49897/deadlock.zip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43577>
_______________________________________

From report at bugs.python.org  Sun Mar 21 01:16:10 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 21 Mar 2021 05:16:10 +0000
Subject: [issue33935] shutil.copyfile throws incorrect SameFileError on Google
 Drive File Stream
In-Reply-To: <1529627906.69.0.56676864532.issue33935@psf.upfronthosting.co.za>
Message-ID: <1616303770.95.0.520464938566.issue33935@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
components: +Extension Modules
versions: +Python 3.10, Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33935>
_______________________________________

From report at bugs.python.org  Sun Mar 21 01:20:32 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 21 Mar 2021 05:20:32 +0000
Subject: [issue4198] os.path.normcase gets fooled on windows with mapped linux
 network drive
In-Reply-To: <1224885833.7.0.0397055051655.issue4198@psf.upfronthosting.co.za>
Message-ID: <1616304032.34.0.391595643043.issue4198@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

Filesystem paths in Windows are normally opened case insensitive, but a filesystem can choose to ignore this. NTFS does so for directories that flagged as case sensitive [1]. ntpath.normcase() doesn't incorporate this information. It would have to query the case-sensitive information for each component in the path. Instead it just assumes that all path components are case insensitive. That said, the way it does this does not correspond to how Windows filesystems implement case-insensitive comparisons. See bpo-42658. If supporting case-sensitive directories is needed, it should be addressed in that issue.

> same = os.path.samefile(f, f)
> print(same) # expected True; got False

I just followed up on investigating this. Apparently the VirtualBox "VBoxSharedFolderFS" filesystem generates a different file reference number randomly on each access. This violates the requirements for FileInternalInformation as specified in [MS-FSCC][2]. If file reference numbers aren't supported, the filesystem is supposed to return 0. That said, Python's samefile() doesn't currently follow the spec either. It blindly uses the st_dev (volume serial number) and st_ino (file reference number) values even when they're 0. See bpo-33935.

---

[1] https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/ns-ntifs-_file_case_sensitive_information
[2] https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/7d796611-2fa5-41ac-8178-b6fea3a017b3

----------
resolution:  -> not a bug
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4198>
_______________________________________

From report at bugs.python.org  Sun Mar 21 01:25:57 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 21 Mar 2021 05:25:57 +0000
Subject: [issue33935] [Windows] samefile() should not use zero-valued st_dev
 and st_ino
In-Reply-To: <1529627906.69.0.56676864532.issue33935@psf.upfronthosting.co.za>
Message-ID: <1616304357.09.0.598829170137.issue33935@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
title: shutil.copyfile throws incorrect SameFileError on Google Drive File Stream -> [Windows] samefile() should not use zero-valued st_dev and st_ino

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33935>
_______________________________________

From report at bugs.python.org  Sun Mar 21 01:58:10 2021
From: report at bugs.python.org (Brandt Bucher)
Date: Sun, 21 Mar 2021 05:58:10 +0000
Subject: [issue43574] Regression in overallocation for literal list
 initialization in v3.9+
In-Reply-To: <1616293914.75.0.599644741052.issue43574@roundup.psfhosted.org>
Message-ID: <1616306290.09.0.547099662666.issue43574@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
nosy: +brandtbucher

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43574>
_______________________________________

From report at bugs.python.org  Sun Mar 21 02:53:15 2021
From: report at bugs.python.org (lincheney)
Date: Sun, 21 Mar 2021 06:53:15 +0000
Subject: [issue43578] With asyncio subprocess,
 send_signal() and the child process watcher will both call waitpid()
Message-ID: <1616309595.59.0.425616668728.issue43578@roundup.psfhosted.org>


New submission from lincheney <lincheney at gmail.com>:

Under unix, when creating a asyncio subprocess, the child process watcher will call waitpid() to reap the child, but if you call send_signal() (or terminate() or kill() ) on the asyncio subprocess, this will also call waitpid(), causing exactly one of these to fail, as you cannot call waitpid() on a PID more than once.

If the send_signal() fails, this doesn't seem much of an issue.
If the child process watcher fails however, it sets the returncode to 255 and also returns 255 when running wait() and also emits a warning.

I've seen this behaviour with the ThreadedChildWatcher, but possibly other Unix child watchers that use waitpid() suffer from the same problem.

The behaviour is racey (it depends on which one completes the waitpid() first), but if you try it enough it will appear:
```
import asyncio
import signal

async def main():
    while True:
        proc = await asyncio.create_subprocess_exec('sleep', '0.1')
        await asyncio.sleep(0.1)
        try:
            proc.send_signal(signal.SIGUSR1)
        except ProcessLookupError:
            pass
        assert (await proc.wait() != 255)

asyncio.run(main())

```

The output looks like:
```
Unknown child process pid 1394331, will report returncode 255
Traceback (most recent call last):
  File "/tmp/bob.py", line 14, in <module>
    asyncio.run(main())
  File "/usr/lib/python3.9/asyncio/runners.py", line 44, in run
    return loop.run_until_complete(main)
  File "/usr/lib/python3.9/asyncio/base_events.py", line 642, in run_until_complete
    return future.result()
  File "/tmp/bob.py", line 12, in main
    assert (await proc.wait() != 255)
AssertionError
```

This would be expected behaviour if I were explicitly calling waitpid() myself (ie I'm shooting my own foot, so I'd deserve the bad behaviour), but that's not the case here nor any other exotic code.

----------
components: asyncio
messages: 389218
nosy: asvetlov, lincheney, yselivanov
priority: normal
severity: normal
status: open
title: With asyncio subprocess, send_signal() and the child process watcher will both call waitpid()
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43578>
_______________________________________

From report at bugs.python.org  Sun Mar 21 03:11:11 2021
From: report at bugs.python.org (begnac)
Date: Sun, 21 Mar 2021 07:11:11 +0000
Subject: [issue43579] Leak in asyncio.selector_events._SelectorSocketTransport
Message-ID: <1616310671.0.0.615896867507.issue43579@roundup.psfhosted.org>


New submission from begnac <candeb at free.fr>:

Hello,

Even after close()ing, asyncio.selector_events._SelectorSocketTransport keeps a reference to itself via self._read_ready_cb.

should probably add

def close(self):
    super().close()
    self._read_ready_cb = None

Cheers !
Ita?.

----------
components: asyncio
messages: 389219
nosy: asvetlov, begnac, yselivanov
priority: normal
severity: normal
status: open
title: Leak in asyncio.selector_events._SelectorSocketTransport
type: performance
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43579>
_______________________________________

From report at bugs.python.org  Sun Mar 21 05:07:50 2021
From: report at bugs.python.org (LittleGuy)
Date: Sun, 21 Mar 2021 09:07:50 +0000
Subject: [issue43580] A Question about List Slice
Message-ID: <1616317670.15.0.486423863335.issue43580@roundup.psfhosted.org>


New submission from LittleGuy <674980165 at qq.com>:

# There is a question when I use list.
# If I run this following code:

x = list(range(10))
a = x[1 : -1 : -1]
print(a)

# the answer will be:
[]

# the right answer should be: [1, 0]
# But in some cases, it works well, like:

a = x[4 : 2 : -1]
print(a)

# the answer will be:
[4, 3]

# so, there may be some problems.

----------
components: Regular Expressions
messages: 389220
nosy: YangS007, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: A Question about List Slice
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43580>
_______________________________________

From report at bugs.python.org  Sun Mar 21 05:19:58 2021
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 21 Mar 2021 09:19:58 +0000
Subject: [issue43577] Deadlock when using SSLContext._msg_callback and
 SSLContext.sni_callback
In-Reply-To: <1616302842.44.0.286720324373.issue43577@roundup.psfhosted.org>
Message-ID: <1616318398.34.0.389629213455.issue43577@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
keywords: +patch
pull_requests: +23715
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24957

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43577>
_______________________________________

From report at bugs.python.org  Sun Mar 21 05:28:12 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 21 Mar 2021 09:28:12 +0000
Subject: [issue43580] A Question about List Slice
In-Reply-To: <1616317670.15.0.486423863335.issue43580@roundup.psfhosted.org>
Message-ID: <1616318892.03.0.446059035666.issue43580@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

It's behaving as designed and documented; see the docs here: https://docs.python.org/3/library/stdtypes.html#sequence-types-list-tuple-range (and particularly note 3).

In your first example, the first `-1` in `x[1:-1:-1]` is interpreted relative to the end of the list, so `x[1:-1:-1]` is equivalent to `x[1:9:-1]`.

`x[1::-1]` may give you what you want for the first case.

----------
nosy: +mark.dickinson
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43580>
_______________________________________

From report at bugs.python.org  Sun Mar 21 05:38:34 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 21 Mar 2021 09:38:34 +0000
Subject: [issue43580] A Question about List Slice
In-Reply-To: <1616317670.15.0.486423863335.issue43580@roundup.psfhosted.org>
Message-ID: <1616319514.17.0.88253276092.issue43580@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
components:  -Regular Expressions

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43580>
_______________________________________

From report at bugs.python.org  Sun Mar 21 06:21:49 2021
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 21 Mar 2021 10:21:49 +0000
Subject: [issue43577] Deadlock when using SSLContext._msg_callback and
 SSLContext.sni_callback
In-Reply-To: <1616302842.44.0.286720324373.issue43577@roundup.psfhosted.org>
Message-ID: <1616322109.16.0.882465261864.issue43577@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Thanks for the excellent bug report and reproducer! I have identified the issue and submitted a fix for review. OpenSSL copies the internal msg_callback to SSL struct, but SSL_set_SSL_CTX() does not update the msg_callback with value from new context.

Could you please open a new bug regarding the issue with SNI and ALPN order? This is unrelated. It looks like OpenSSL processes the ALPN extension after the SNI extension, https://github.com/openssl/openssl/blob/abded2ced44b94d96f08ea5cf01df6519b80f5d3/ssl/ssl_local.h#L740-L769 . I can see that the state machines fires "final_server_name" first (which triggers the SNI callback), then "tls_handle_alpn". This makes sense. This allows the new context to select ALPNs.


#0  final_server_name (s=0x8a4080, context=128, sent=1) at ssl/statem/extensions.c:925
#1  0x00007fffea3ec146 in tls_parse_all_extensions (x=<optimized out>, chainidx=<optimized out>, fin=<optimized out>, exts=<optimized out>, context=<optimized out>, 
    s=<optimized out>) at ssl/statem/extensions.c:762
#2  tls_parse_all_extensions (s=0x8a4080, context=128, exts=<optimized out>, x=<optimized out>, chainidx=<optimized out>, fin=1) at ssl/statem/extensions.c:737
#3  0x00007fffea417db6 in tls_early_post_process_client_hello (s=0x8a4080) at ssl/statem/statem_srvr.c:1906
#4  tls_post_process_client_hello (wst=<optimized out>, s=0x8a4080) at ssl/statem/statem_srvr.c:2249
#5  ossl_statem_server_post_process_message (s=s at entry=0x8a4080, wst=<optimized out>) at ssl/statem/statem_srvr.c:1243
#6  0x00007fffea3fe34c in read_state_machine (s=0x8a4080) at ssl/statem/statem.c:664
#7  state_machine (s=0x8a4080, server=<optimized out>) at ssl/statem/statem.c:434
#8  0x00007fffea48a9df in _ssl__SSLSocket_do_handshake_impl (self=0x7fffe9fe3ed0) at /home/heimes/dev/python/cpython/Modules/_ssl.c:1084
#9  _ssl__SSLSocket_do_handshake (self=0x7fffe9fe3ed0, _unused_ignored=<optimized out>) at /home/heimes/dev/python/cpython/Modules/clinic/_ssl.c.h:19


#0  tls_handle_alpn (s=0x8a4080) at ssl/statem/statem_srvr.c:2167
#1  0x00007fffea3ec146 in tls_parse_all_extensions (x=<optimized out>, chainidx=<optimized out>, fin=<optimized out>, exts=<optimized out>, context=<optimized out>, 
    s=<optimized out>) at ssl/statem/extensions.c:762
#2  tls_parse_all_extensions (s=0x8a4080, context=128, exts=<optimized out>, x=<optimized out>, chainidx=<optimized out>, fin=1) at ssl/statem/extensions.c:737
#3  0x00007fffea417db6 in tls_early_post_process_client_hello (s=0x8a4080) at ssl/statem/statem_srvr.c:1906
#4  tls_post_process_client_hello (wst=<optimized out>, s=0x8a4080) at ssl/statem/statem_srvr.c:2249
#5  ossl_statem_server_post_process_message (s=s at entry=0x8a4080, wst=<optimized out>) at ssl/statem/statem_srvr.c:1243
#6  0x00007fffea3fe34c in read_state_machine (s=0x8a4080) at ssl/statem/statem.c:664
#7  state_machine (s=0x8a4080, server=<optimized out>) at ssl/statem/statem.c:434
#8  0x00007fffea48a9df in _ssl__SSLSocket_do_handshake_impl (self=0x7fffe9fe3ed0) at /home/heimes/dev/python/cpython/Modules/_ssl.c:1084

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43577>
_______________________________________

From report at bugs.python.org  Sun Mar 21 07:01:00 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 21 Mar 2021 11:01:00 +0000
Subject: [issue31863] Inconsistent exitcode for terminated child processes on
 Windows
In-Reply-To: <1508860013.85.0.213398074469.issue31863@psf.upfronthosting.co.za>
Message-ID: <1616324460.26.0.965592601291.issue31863@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> I'm not actually sure what the proposal here is. Are we suggesting 
> that all Python's means of terminating a process should use the 
> same exit code?

That's how I read it, but I don't agree if it means always pretending that a process was killed by a SIGTERM POSIX signal. That's fighting an uphill battle against the platform and its conventions.

I singled out the case where multiprocessing tries to pretend that Windows has Unix signals. It documents that `exitcode` will be negative if terminated by a signal. It doesn't qualify that this is only in Unix.

    exitcode
        The child?s exit code. This will be None if the process has not
        yet terminated. A negative value -N indicates that the child
        was terminated by signal N.

A negative exit code in Windows (i.e. 0x8000_0000 and above) has many possible meanings. Generally it indicates an abnormal error of some sort that terminated the process, and generally the code is an NTSTATUS or HRESULT value, such as STATUS_CONTROL_C_EXIT or E_FAIL (0x8000_4005). However, there isn't a convention to use an NTSTATUS or HRESULT error code when manually terminating a process. Instead, the convention is to use EXIT_FAILURE (1).

multiprocessing pretends that terminate() is implemented with a SIGTERM signal. To do so, it terminates with an exit code that's just above the system 16-bit range:

    TERMINATE = 0x10000

    def terminate(self):
        if self.returncode is None:
            try:
                _winapi.TerminateProcess(int(self._handle), TERMINATE)
            except OSError:
                if self.wait(timeout=1.0) is None:
                    raise

and maps this code to -signal.SIGTERM:

    def wait(self, timeout=None):
        if self.returncode is None:
            if timeout is None:
                msecs = _winapi.INFINITE
            else:
                msecs = max(0, int(timeout * 1000 + 0.5))

            res = _winapi.WaitForSingleObject(int(self._handle), msecs)
            if res == _winapi.WAIT_OBJECT_0:
                code = _winapi.GetExitCodeProcess(self._handle)
                if code == TERMINATE:
                    code = -signal.SIGTERM
                self.returncode = code

        return self.returncode

I don't know why it doesn't simply use -SIGTERM instead of involving the intermediate error code. 

It's apparently trying to close a loop for scripts that call terminate() and look for this case, or for logging, but the platform convention in Windows doesn't allow distinguishing when a process was forcibly terminated. We don't know whether an exit status of 1 means the process failed internally or was forcibly terminated by another tool. So we can't rely on the exit code in Windows in the same way that it can be relied on in POSIX. All we know is that the process failed. Terminating with an exit code of 15 or -15 in some cases does nothing to solve the problem in general.

----------
title: Inconsistent returncode/exitcode for terminated child processes on Windows -> Inconsistent exitcode for terminated child processes on Windows
versions: +Python 3.10 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31863>
_______________________________________

From report at bugs.python.org  Sun Mar 21 07:39:20 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Mar 2021 11:39:20 +0000
Subject: [issue43572] "Too many open files" on macOS buildbot
In-Reply-To: <1616277062.42.0.179950736754.issue43572@roundup.psfhosted.org>
Message-ID: <1616326760.01.0.069640638146.issue43572@roundup.psfhosted.org>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43572>
_______________________________________

From report at bugs.python.org  Sun Mar 21 07:39:13 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Mar 2021 11:39:13 +0000
Subject: [issue43572] "Too many open files" on macOS buildbot
In-Reply-To: <1616277062.42.0.179950736754.issue43572@roundup.psfhosted.org>
Message-ID: <1616326753.26.0.319744128052.issue43572@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thank you!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43572>
_______________________________________

From report at bugs.python.org  Sun Mar 21 07:49:33 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Mar 2021 11:49:33 +0000
Subject: [issue32592] Drop support of Windows Vista and Windows 7
In-Reply-To: <1516268238.05.0.467229070634.issue32592@psf.upfronthosting.co.za>
Message-ID: <1616327373.56.0.0107367406927.issue32592@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

As a data point, my Windows development VM uses Windows 7.  It would be a major annoyance for me to reinstall a new development VM from scratch (going through the usual hurdles to have a usable development environment would probably be a full day of work, perhaps more).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32592>
_______________________________________

From report at bugs.python.org  Sun Mar 21 07:59:21 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 21 Mar 2021 11:59:21 +0000
Subject: [issue40521] [subinterpreters] Make free lists and unicode caches
 per-interpreter
In-Reply-To: <1588693682.5.0.219755904926.issue40521@roundup.psfhosted.org>
Message-ID: <1616327961.83.0.672542009295.issue40521@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hi Victor,

I just noticed the change to dtoa.c in GH-24821. Please could you explain what the benefit of this change was?

In general, we need to be very conservative with changes to dtoa.c: it's a complex, fragile, performance-critical piece of code, and ideally we'd like it not to diverge from the upstream code any more than it already has, in case we need to integrate bugfixes from upstream.

It's feeling as though the normal Python development process is being bypassed here. As I understand it, this and similar changes are in aid of per-subinterpreter GILs. Has there been agreement from the core devs or steering council that this is a desirable goal? Should there be a PEP before more changes like this are made? (Or maybe there's already a PEP, that I missed? I know about PEP 554, but that PEP is explicit that GIL sharing is out of scope.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40521>
_______________________________________

From report at bugs.python.org  Sun Mar 21 08:43:49 2021
From: report at bugs.python.org (Kamil Turek)
Date: Sun, 21 Mar 2021 12:43:49 +0000
Subject: [issue43535] Make str.join auto-convert inputs to strings.
In-Reply-To: <1616034546.27.0.0632217994438.issue43535@roundup.psfhosted.org>
Message-ID: <1616330629.83.0.436983041763.issue43535@roundup.psfhosted.org>


Change by Kamil Turek <kamil.turek at hotmail.com>:


----------
nosy: +kamilturek

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43535>
_______________________________________

From report at bugs.python.org  Sun Mar 21 08:45:57 2021
From: report at bugs.python.org (Kamil Turek)
Date: Sun, 21 Mar 2021 12:45:57 +0000
Subject: [issue33140] shutil.chown should not be defined in Windows
In-Reply-To: <1522018536.28.0.467229070634.issue33140@psf.upfronthosting.co.za>
Message-ID: <1616330757.76.0.956357250815.issue33140@roundup.psfhosted.org>


Change by Kamil Turek <kamil.turek at hotmail.com>:


----------
nosy: +kamilturek

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33140>
_______________________________________

From report at bugs.python.org  Sun Mar 21 09:04:18 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 21 Mar 2021 13:04:18 +0000
Subject: [issue19124] os.execv executes in background on Windows
In-Reply-To: <1380451602.11.0.517013085188.issue19124@psf.upfronthosting.co.za>
Message-ID: <1616331858.19.0.513660806298.issue19124@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> On Windows, the new process is executed in the background but 
> can send output to a console if the original process was 
> started in a console.

C execv[e]() is a mess for console applications. The child process is competing for console input with an ancestor process in the console session, which is typically a CLI shell such as CMD or PowerShell. This is dysfunctional. It's worth either fixing or deprecating. It's not worth documenting since it's way off spec compared to exec() in POSIX systems. exec() is supposed to overlay the current process with a new image, not terminate the current process. That cannot be implemented in Windows, but we could do our best to emulate it. 

The implementation could leave the current Python process running in much the same way as a launcher functions, i.e. wait for the child process to exit and proxy its exit status, and set the child process in a kill-on-close job object.

It would be better at this point to use subprocess.Popen() to implement os.exec*, considering it can work concurrently with itself, without race conditions involving inheritable handles. nt.spawnv[e](), nt.waitpid(), and nt.system() could also be implemented with subprocess.

----------
assignee: docs at python -> 
components: +Extension Modules, Library (Lib) -Documentation
versions: +Python 3.10 -Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19124>
_______________________________________

From report at bugs.python.org  Sun Mar 21 09:53:05 2021
From: report at bugs.python.org (=?utf-8?q?Gr=C3=A9gory_Starck?=)
Date: Sun, 21 Mar 2021 13:53:05 +0000
Subject: [issue43535] Make str.join auto-convert inputs to strings.
In-Reply-To: <1616034546.27.0.0632217994438.issue43535@roundup.psfhosted.org>
Message-ID: <1616334785.93.0.041180977713.issue43535@roundup.psfhosted.org>


Gr?gory Starck <g.starck at gmail.com> added the comment:

FWIW -1 from me too.

That should be solved by creating a new function IMO : 

def joinstr(sep, *seq):
    return sep.join(str(i) for i in seq)

----------
nosy: +g.starck at gmail.com

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43535>
_______________________________________

From report at bugs.python.org  Sun Mar 21 10:42:07 2021
From: report at bugs.python.org (Andrew Dailey)
Date: Sun, 21 Mar 2021 14:42:07 +0000
Subject: [issue43577] Deadlock when using SSLContext._msg_callback and
 SSLContext.sni_callback
In-Reply-To: <1616302842.44.0.286720324373.issue43577@roundup.psfhosted.org>
Message-ID: <1616337727.6.0.630418828697.issue43577@roundup.psfhosted.org>


Andrew Dailey <steveday168 at gmail.com> added the comment:

I'm glad that the info I provided was helpful! I'll go ahead and create another issue for the misleading docs surrounding SSLContext.sni_callback. Thanks for looking into this and coming up with a fix so quickly.

I do have one more question: does python provide a "safe" way to test for deadlocks like this? I noticed that you added a test case to verify that this lockup doesn't happen but what would happen if someone ran that test on an earlier version? Would the test runner also freeze or are there facilities in-place to catch such behavior? Maybe something nutty like:

with should_deadlock():
    my_buggy_test()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43577>
_______________________________________

From report at bugs.python.org  Sun Mar 21 10:45:47 2021
From: report at bugs.python.org (Wen Hao)
Date: Sun, 21 Mar 2021 14:45:47 +0000
Subject: [issue43581] array assignment error
Message-ID: <1616337947.23.0.922610060887.issue43581@roundup.psfhosted.org>


New submission from Wen Hao <haowenqi.zz at gmail.com>:

>>>mat = [[0]*4]*4
>>> mat
[[0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0]]
>>> mat[1][2]=1
>>> mat
[[0, 0, 1, 0], [0, 0, 1, 0], [0, 0, 1, 0], [0, 0, 1, 0]]

----------
components: Build
messages: 389230
nosy: haowenqi.zz
priority: normal
severity: normal
status: open
title: array assignment error
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43581>
_______________________________________

From report at bugs.python.org  Sun Mar 21 10:53:57 2021
From: report at bugs.python.org (Andrew Dailey)
Date: Sun, 21 Mar 2021 14:53:57 +0000
Subject: [issue43582] SSLContext.sni_callback docs inaccurately describe
 available handshake info
Message-ID: <1616338437.57.0.677049840589.issue43582@roundup.psfhosted.org>


New submission from Andrew Dailey <steveday168 at gmail.com>:

Hello,

The documentation for SSLContext.sni_callback [0] seems to incorrectly describe the information available at that stage of the TLS handshake.

According to the docs:
Due to the early negotiation phase of the TLS connection, only limited methods and attributes are usable like SSLSocket.selected_alpn_protocol() and SSLSocket.context. SSLSocket.getpeercert(), SSLSocket.getpeercert(), SSLSocket.cipher() and SSLSocket.compress() methods require that the TLS connection has progressed beyond the TLS Client Hello and therefore will not contain return meaningful values nor can they be called safely.

This paragraph claims that SSLSocket.selected_alpn_protocol() should be usable within sni_callback but I think this is inaccurate. Based on the OpenSSL docs [1] and my own testing, the servername callback occurs after ClientHello but _before_ the ALPN callback. This prevents accurate ALPN information from being available until later. I believe that any call to SSLSocket.selected_alpn_protocol() within an SSLContext.sni_callback will simply return None.

Excerpt from the OpenSSL docs:
Several callbacks are executed during ClientHello processing, including the ClientHello, ALPN, and servername callbacks. The ClientHello callback is executed first, then the servername callback, followed by the ALPN callback.

I think it'd be better to explain that the only "useful" thing you can do within sni_callback is to see what sni_name is desired an optionally swap out the context for one with a more appropriate cert chain. Any information about the selected ALPN protocol has to wait until later in the handshake.

[0] https://docs.python.org/3/library/ssl.html#ssl.SSLContext.sni_callback
[1] https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_tlsext_servername_callback.html

----------
assignee: docs at python
components: Documentation, SSL
messages: 389231
nosy: docs at python, theandrew168
priority: normal
severity: normal
status: open
title: SSLContext.sni_callback docs inaccurately describe available handshake info
type: enhancement
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43582>
_______________________________________

From report at bugs.python.org  Sun Mar 21 10:54:30 2021
From: report at bugs.python.org (Andrew Dailey)
Date: Sun, 21 Mar 2021 14:54:30 +0000
Subject: [issue43582] SSLContext.sni_callback docs inaccurately describe
 available handshake info
In-Reply-To: <1616338437.57.0.677049840589.issue43582@roundup.psfhosted.org>
Message-ID: <1616338470.35.0.942623524161.issue43582@roundup.psfhosted.org>


Change by Andrew Dailey <steveday168 at gmail.com>:


----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43582>
_______________________________________

From report at bugs.python.org  Sun Mar 21 11:13:21 2021
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 21 Mar 2021 15:13:21 +0000
Subject: [issue43577] Deadlock when using SSLContext._msg_callback and
 SSLContext.sni_callback
In-Reply-To: <1616302842.44.0.286720324373.issue43577@roundup.psfhosted.org>
Message-ID: <1616339601.38.0.968353268014.issue43577@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset 77cde5042a2f1eae489c11a67540afaf43cd5cdf by Christian Heimes in branch 'master':
bpo-43577: Fix deadlock with SSLContext._msg_callback and sni_callback (GH-24957)
https://github.com/python/cpython/commit/77cde5042a2f1eae489c11a67540afaf43cd5cdf


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43577>
_______________________________________

From report at bugs.python.org  Sun Mar 21 11:13:25 2021
From: report at bugs.python.org (miss-islington)
Date: Sun, 21 Mar 2021 15:13:25 +0000
Subject: [issue43577] Deadlock when using SSLContext._msg_callback and
 SSLContext.sni_callback
In-Reply-To: <1616302842.44.0.286720324373.issue43577@roundup.psfhosted.org>
Message-ID: <1616339605.42.0.718970893812.issue43577@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: +23716
pull_request: https://github.com/python/cpython/pull/24958

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43577>
_______________________________________

From report at bugs.python.org  Sun Mar 21 11:13:34 2021
From: report at bugs.python.org (miss-islington)
Date: Sun, 21 Mar 2021 15:13:34 +0000
Subject: [issue43577] Deadlock when using SSLContext._msg_callback and
 SSLContext.sni_callback
In-Reply-To: <1616302842.44.0.286720324373.issue43577@roundup.psfhosted.org>
Message-ID: <1616339614.26.0.798158745824.issue43577@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +23717
pull_request: https://github.com/python/cpython/pull/24959

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43577>
_______________________________________

From report at bugs.python.org  Sun Mar 21 11:19:37 2021
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Sun, 21 Mar 2021 15:19:37 +0000
Subject: [issue43581] array assignment error
In-Reply-To: <1616337947.23.0.922610060887.issue43581@roundup.psfhosted.org>
Message-ID: <1616339977.77.0.910161747861.issue43581@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

All three words in the title are wrong. :-D

----------
nosy: +veky

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43581>
_______________________________________

From report at bugs.python.org  Sun Mar 21 11:32:26 2021
From: report at bugs.python.org (miss-islington)
Date: Sun, 21 Mar 2021 15:32:26 +0000
Subject: [issue43577] Deadlock when using SSLContext._msg_callback and
 SSLContext.sni_callback
In-Reply-To: <1616302842.44.0.286720324373.issue43577@roundup.psfhosted.org>
Message-ID: <1616340746.98.0.284986086507.issue43577@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 93b0da7527ae1b7d705052cf352ef9da81e608ec by Miss Islington (bot) in branch '3.8':
bpo-43577: Fix deadlock with SSLContext._msg_callback and sni_callback (GH-24957)
https://github.com/python/cpython/commit/93b0da7527ae1b7d705052cf352ef9da81e608ec


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43577>
_______________________________________

From report at bugs.python.org  Sun Mar 21 11:34:21 2021
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 21 Mar 2021 15:34:21 +0000
Subject: [issue43577] Deadlock when using SSLContext._msg_callback and
 SSLContext.sni_callback
In-Reply-To: <1616302842.44.0.286720324373.issue43577@roundup.psfhosted.org>
Message-ID: <1616340861.49.0.264270057801.issue43577@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

No, there is no check for that. This kind of deadlock should never occur. The problem was an implementation bug in low-level C code that had bad interaction with the global interpreter lock. Python releases the GIL around OpenSSL calls. Callbacks have to re-acquire the GIL correctly and release it again at the end of a callback.

By the way the _msg_cb attribute is deliberately undocumented and marked as an internal property. I implemented the callback to debug some issues with TLS 1.3 and OpenSSL 1.1.1. It's neither well tested nor stable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43577>
_______________________________________

From report at bugs.python.org  Sun Mar 21 11:37:16 2021
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 21 Mar 2021 15:37:16 +0000
Subject: [issue43582] SSLContext.sni_callback docs inaccurately describe
 available handshake info
In-Reply-To: <1616338437.57.0.677049840589.issue43582@roundup.psfhosted.org>
Message-ID: <1616341036.33.0.774097199339.issue43582@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

I analysed the issue in comment https://bugs.python.org/issue43577#msg389222

----------
nosy: +alex, dstufft, janssen, njs
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43582>
_______________________________________

From report at bugs.python.org  Sun Mar 21 11:38:59 2021
From: report at bugs.python.org (Pattesvador)
Date: Sun, 21 Mar 2021 15:38:59 +0000
Subject: [issue43583] make test failures,
 2 tests failed:     test_embed test_tabnanny
Message-ID: <1616341139.4.0.592020830762.issue43583@roundup.psfhosted.org>


New submission from Pattesvador <Pattesvador at hotmail.fr>:

I'm trying to install python 3.9.2 on a 18.04.5 ubuntu. I downloaded the Python-3.9.2.tar.xz and followed the readme.txt installation instructions. When executing the "make test" command I get this error : 

== Tests result: FAILURE then FAILURE ==

397 tests OK.

2 tests failed:
    test_embed test_tabnanny

26 tests skipped:
    test_bz2 test_dbm_gnu test_dbm_ndbm test_devpoll test_idle
    test_ioctl test_kqueue test_lzma test_msilib test_ossaudiodev
    test_readline test_smtpnet test_sqlite test_ssl test_startfile
    test_tcl test_tix test_tk test_ttk_guionly test_ttk_textonly
    test_turtle test_winconsoleio test_winreg test_winsound
    test_zipfile64 test_zoneinfo

2 re-run tests:
    test_embed test_tabnanny

Total duration: 9 min 26 sec
Tests result: FAILURE then FAILURE
R?colte du processus fils perdant 0x55e48cc2b400 PID 15880 
Makefile:1199: recipe for target 'test' failed
make: *** [test] Error 2
Retrait du processus fils 0x55e48cc2b400 PID 15880 de la cha?ne.

I don't know what to do. I've read one issue on the topic but I have to admit that I didn't understand a thing. Here's the issue https://bugs.python.org/issue43001

Thank you for your answers.

----------
messages: 389237
nosy: Pattesvador
priority: normal
severity: normal
status: open
title: make test failures, 2 tests failed:     test_embed test_tabnanny
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43583>
_______________________________________

From report at bugs.python.org  Sun Mar 21 11:39:24 2021
From: report at bugs.python.org (miss-islington)
Date: Sun, 21 Mar 2021 15:39:24 +0000
Subject: [issue43577] Deadlock when using SSLContext._msg_callback and
 SSLContext.sni_callback
In-Reply-To: <1616302842.44.0.286720324373.issue43577@roundup.psfhosted.org>
Message-ID: <1616341164.4.0.624251275098.issue43577@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c145c03281af850130dd7f75abc19c6ea49626e6 by Miss Islington (bot) in branch '3.9':
bpo-43577: Fix deadlock with SSLContext._msg_callback and sni_callback (GH-24957)
https://github.com/python/cpython/commit/c145c03281af850130dd7f75abc19c6ea49626e6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43577>
_______________________________________

From report at bugs.python.org  Sun Mar 21 12:02:59 2021
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 21 Mar 2021 16:02:59 +0000
Subject: [issue43582] SSLContext.sni_callback docs inaccurately describe
 available handshake info
In-Reply-To: <1616338437.57.0.677049840589.issue43582@roundup.psfhosted.org>
Message-ID: <1616342579.82.0.353698427069.issue43582@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

I don't see any way to fix the issue with our current API. OpenSSL 1.1.1 provides a new API SSL_client_hello_get0_ext() to access raw extension during early stage of ClientHello phase. https://www.openssl.org/docs/man1.1.1/man3/SSL_client_hello_get1_extensions_present.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43582>
_______________________________________

From report at bugs.python.org  Sun Mar 21 12:03:49 2021
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 21 Mar 2021 16:03:49 +0000
Subject: [issue43577] Deadlock when using SSLContext._msg_callback and
 SSLContext.sni_callback
In-Reply-To: <1616302842.44.0.286720324373.issue43577@roundup.psfhosted.org>
Message-ID: <1616342629.01.0.347211206196.issue43577@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

The fix will be available in next 3.9 and 3.8 release.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43577>
_______________________________________

From report at bugs.python.org  Sun Mar 21 12:04:45 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Mar 2021 16:04:45 +0000
Subject: [issue43422] Revert _decimal C API changes
In-Reply-To: <1615043906.44.0.566874098139.issue43422@roundup.psfhosted.org>
Message-ID: <1616342685.26.0.640014827076.issue43422@roundup.psfhosted.org>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
pull_requests: +23718
pull_request: https://github.com/python/cpython/pull/24960

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43422>
_______________________________________

From report at bugs.python.org  Sun Mar 21 12:06:46 2021
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 21 Mar 2021 16:06:46 +0000
Subject: [issue43535] Make str.join auto-convert inputs to strings.
In-Reply-To: <1616034546.27.0.0632217994438.issue43535@roundup.psfhosted.org>
Message-ID: <1616342806.33.0.59632131451.issue43535@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

I'm also -1 and would prefer something like Gr?gory's proposal instead.

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43535>
_______________________________________

From report at bugs.python.org  Sun Mar 21 12:11:00 2021
From: report at bugs.python.org (Grant Edwards)
Date: Sun, 21 Mar 2021 16:11:00 +0000
Subject: [issue43584] Doc description of str.title() upper case vs. title case.
Message-ID: <1616343060.26.0.656949080319.issue43584@roundup.psfhosted.org>


New submission from Grant Edwards <grant.b.edwards at gmail.com>:

The documentation for str.title() states that the first character in each world is converted to upper case. That is not correct for recent versions of Python. The first character in each word is converted to title case. Title and upper may be the same for English/ASCII, but other languages have characters for which upper and title case are different.

----------
assignee: docs at python
components: Documentation
messages: 389242
nosy: docs at python, grant.b.edwards
priority: normal
severity: normal
status: open
title: Doc description of str.title() upper case vs. title case.
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43584>
_______________________________________

From report at bugs.python.org  Sun Mar 21 12:14:25 2021
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 21 Mar 2021 16:14:25 +0000
Subject: [issue43581] array assignment error
In-Reply-To: <1616337947.23.0.922610060887.issue43581@roundup.psfhosted.org>
Message-ID: <1616343265.37.0.0998679664737.issue43581@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

By using * 4 in the end you are making four lists having same reference. Hence change in one causes change in other 4 lists.

Relevant FAQ : https://docs.python.org/3/faq/programming.html#how-do-i-create-a-multidimensional-list

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43581>
_______________________________________

From report at bugs.python.org  Sun Mar 21 12:14:34 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Mar 2021 16:14:34 +0000
Subject: [issue41324] Add a minimal decimal capsule API
In-Reply-To: <1594984713.74.0.721782226907.issue41324@roundup.psfhosted.org>
Message-ID: <1616343274.71.0.79564187454.issue41324@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

For the record, this is going to be reverted at Stefan's request in issue43422.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41324>
_______________________________________

From report at bugs.python.org  Sun Mar 21 12:20:11 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 21 Mar 2021 16:20:11 +0000
Subject: [issue43581] array assignment error
In-Reply-To: <1616337947.23.0.922610060887.issue43581@roundup.psfhosted.org>
Message-ID: <1616343611.97.0.510552423545.issue43581@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43581>
_______________________________________

From report at bugs.python.org  Sun Mar 21 12:21:52 2021
From: report at bugs.python.org (John Cena)
Date: Sun, 21 Mar 2021 16:21:52 +0000
Subject: [issue43581] array assignment error
In-Reply-To: <1616337947.23.0.922610060887.issue43581@roundup.psfhosted.org>
Message-ID: <1616343712.71.0.871832933488.issue43581@roundup.psfhosted.org>


John Cena <crazyguyx4 at gmail.com> added the comment:

You are actually creating 4 references to the same list(See the ending *4). This is how python behaves. See the below link as well

https://stackoverflow.com/questions/240178/list-of-lists-changes-reflected-across-sublists-unexpectedly

----------
nosy: +crazyguyx4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43581>
_______________________________________

From report at bugs.python.org  Sun Mar 21 12:26:49 2021
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 21 Mar 2021 16:26:49 +0000
Subject: [issue43584] Doc description of str.title() upper case vs. title case.
In-Reply-To: <1616343060.26.0.656949080319.issue43584@roundup.psfhosted.org>
Message-ID: <1616344009.4.0.757967991056.issue43584@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

There was recent change to str.capitalize. I am not sure if Serhiy was referring to this doc change in https://bugs.python.org/issue36549#msg339570

----------
nosy: +serhiy.storchaka, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43584>
_______________________________________

From report at bugs.python.org  Sun Mar 21 12:27:37 2021
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 21 Mar 2021 16:27:37 +0000
Subject: [issue43575] map() instantiation time reducing by using PEP 590
 vectorcall
In-Reply-To: <1616297103.49.0.396627193734.issue43575@roundup.psfhosted.org>
Message-ID: <1616344057.22.0.852567482532.issue43575@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/issue43575>
_______________________________________

From report at bugs.python.org  Sun Mar 21 12:27:57 2021
From: report at bugs.python.org (miss-islington)
Date: Sun, 21 Mar 2021 16:27:57 +0000
Subject: [issue43422] Revert _decimal C API changes
In-Reply-To: <1615043906.44.0.566874098139.issue43422@roundup.psfhosted.org>
Message-ID: <1616344077.62.0.844184093376.issue43422@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset cdddc2b742750e3f289305cf276433a8170c32c1 by Antoine Pitrou in branch 'master':
bpo-43422: Revert _decimal C API addition (GH-24960)
https://github.com/python/cpython/commit/cdddc2b742750e3f289305cf276433a8170c32c1


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43422>
_______________________________________

From report at bugs.python.org  Sun Mar 21 12:32:55 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Mar 2021 16:32:55 +0000
Subject: [issue43422] Revert _decimal C API changes
In-Reply-To: <1615043906.44.0.566874098139.issue43422@roundup.psfhosted.org>
Message-ID: <1616344375.19.0.936676274123.issue43422@roundup.psfhosted.org>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43422>
_______________________________________

From report at bugs.python.org  Sun Mar 21 12:38:13 2021
From: report at bugs.python.org (Tobi)
Date: Sun, 21 Mar 2021 16:38:13 +0000
Subject: [issue43585] perf_counter() returns computers uptime
Message-ID: <1616344693.53.0.493745901493.issue43585@roundup.psfhosted.org>


New submission from Tobi <txhx38 at gmail.com>:

perf_counter() does not behave as expected

----------
messages: 389248
nosy: txhx38
priority: normal
severity: normal
status: open
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43585>
_______________________________________

From report at bugs.python.org  Sun Mar 21 12:54:57 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Mar 2021 16:54:57 +0000
Subject: [issue41369] Update to libmpdec-2.5.1
In-Reply-To: <1595446041.62.0.150992911256.issue41369@roundup.psfhosted.org>
Message-ID: <1616345697.69.0.437644526681.issue41369@roundup.psfhosted.org>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
pull_requests: +23719
pull_request: https://github.com/python/cpython/pull/24962

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41369>
_______________________________________

From report at bugs.python.org  Sun Mar 21 12:55:27 2021
From: report at bugs.python.org (Dennis Sweeney)
Date: Sun, 21 Mar 2021 16:55:27 +0000
Subject: [issue43585] perf_counter() returns computers uptime
In-Reply-To: <1616344693.53.0.493745901493.issue43585@roundup.psfhosted.org>
Message-ID: <1616345727.23.0.904402776754.issue43585@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

Can you explain why you think this is the wrong behavior, and what operating system and version of Python you're using?


from https://docs.python.org/3/library/time.html#time.perf_counter

Return the value (in fractional seconds) of a performance counter, i.e. a clock with the highest available resolution to measure a short duration. It does include time elapsed during sleep and is system-wide. The reference point of the returned value is undefined, so that only the difference between the results of two calls is valid.


Returning the uptime seems like acceptable behavior to me, since "the reference point ... is undefined".

----------
nosy: +Dennis Sweeney

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43585>
_______________________________________

From report at bugs.python.org  Sun Mar 21 13:16:19 2021
From: report at bugs.python.org (Andrew Dailey)
Date: Sun, 21 Mar 2021 17:16:19 +0000
Subject: [issue43582] SSLContext.sni_callback docs inaccurately describe
 available handshake info
In-Reply-To: <1616338437.57.0.677049840589.issue43582@roundup.psfhosted.org>
Message-ID: <1616346979.23.0.0655990700433.issue43582@roundup.psfhosted.org>


Andrew Dailey <steveday168 at gmail.com> added the comment:

Yea, I'm still on the hunt for a better way to solve my primary problem: detect an acme-tls/1 ALPN protocol request during the TLS handshake so that I can swap out the context to one with the cert chain that Let's Encrypt is expecting to see.

It seems like OpenSSL provides three primary hooks into the handshake: ClientHello, servername, and ALPN. The servername callback is the only one that can be "officially" customized by Python's SSL API. The ALPN callback seems to be used under the hood to implement SSLContext.set_alpn_protocols() but there isn't a way to specify complete control of the callback.

My current "hack" is to use the SSLContext._msg_callback to check for the acme-tls/1 protocol explicitly:

def msg_callback(conn, direction, version, content_type, msg_type, data):
    if direction == 'read' and b'acme-tls/1' in data:
        print('got an acme-tls/1 request')
        print('set a flag for sni_callback to check, etc etc')

I know this probably isn't a good or safe way to solve the problem. The current docs make it sound like sni_callback would be my one-stop shop but that ended up not being the case. Maybe I could subclass SSLSocket, override do_handshake(), and then swap out the context before or after super().do_handshake()? I'm quite new to Python/OpenSSL internals so I'm not sure if that is even possible. Can a context be swapped out so late in the handshake process?

The SSL_client_hello_get0_ext() function you mentioned could be a contender. The _msg_callback I'm currently using _does_ do the trick but maybe shouldn't be documented and made official? Regardless of how best to solve my current acme-tls/1 ALPN detection issue, the sni_callback won't ever be the full answer unless some internal mechanics are added to watch ClientHello and preemptively peek at the requested ALPN protocol(s).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43582>
_______________________________________

From report at bugs.python.org  Sun Mar 21 13:20:52 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Mar 2021 17:20:52 +0000
Subject: [issue41701] Buildbot web page: connection lost after 1 minute,
 then display "Connection restored" popup
In-Reply-To: <1599128479.83.0.639934661132.issue41701@roundup.psfhosted.org>
Message-ID: <1616347252.63.0.211174076005.issue41701@roundup.psfhosted.org>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41701>
_______________________________________

From report at bugs.python.org  Sun Mar 21 13:24:55 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Mar 2021 17:24:55 +0000
Subject: [issue43569] test_importlib failed on installed Python
In-Reply-To: <1616252286.95.0.663253122373.issue43569@roundup.psfhosted.org>
Message-ID: <1616347495.5.0.17091255659.issue43569@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

You can find your submitted change here by looking here:
https://buildbot.python.org/all/#/changes

For some reason, though, it seems that no build was triggered:
https://buildbot.python.org/all/#/changes/3344

In any case, the fix is a no-brainer.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43569>
_______________________________________

From report at bugs.python.org  Sun Mar 21 13:26:51 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Mar 2021 17:26:51 +0000
Subject: [issue43569] test_importlib failed on installed Python
In-Reply-To: <1616252286.95.0.663253122373.issue43569@roundup.psfhosted.org>
Message-ID: <1616347611.74.0.411687048101.issue43569@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:


New changeset 9a50ef43e42ee32450a81ce13ed5a0729d3b84e8 by Jason R. Coombs in branch 'master':
bpo-43569: Add test/test_importlib/namespacedata01 to TESTSUBDIRS (GH-24952)
https://github.com/python/cpython/commit/9a50ef43e42ee32450a81ce13ed5a0729d3b84e8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43569>
_______________________________________

From report at bugs.python.org  Sun Mar 21 13:27:19 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Mar 2021 17:27:19 +0000
Subject: [issue43569] test_importlib failed on installed Python
In-Reply-To: <1616252286.95.0.663253122373.issue43569@roundup.psfhosted.org>
Message-ID: <1616347639.37.0.916809435712.issue43569@roundup.psfhosted.org>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43569>
_______________________________________

From report at bugs.python.org  Sun Mar 21 13:47:15 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Sun, 21 Mar 2021 17:47:15 +0000
Subject: [issue43060] Convert _decimal C API from pointer array to struct
In-Reply-To: <1611913613.83.0.451385849535.issue43060@roundup.psfhosted.org>
Message-ID: <1616348835.12.0.501707768934.issue43060@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

Closing, as the C API was removed in GH-24960.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43060>
_______________________________________

From report at bugs.python.org  Sun Mar 21 14:00:39 2021
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 21 Mar 2021 18:00:39 +0000
Subject: [issue43582] SSLContext.sni_callback docs inaccurately describe
 available handshake info
In-Reply-To: <1616338437.57.0.677049840589.issue43582@roundup.psfhosted.org>
Message-ID: <1616349639.55.0.17271253142.issue43582@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

SSLContext.set_alpn_protocols() is a high level interface on top of SSL_CTX_set_alpn_select_cb(). Python doesn't directly expose the ALPN selector callback. The ssl module only provides a way to set a hard-coded callback that wraps SSL_select_next_proto().

https://github.com/python/cpython/blob/9a50ef43e42ee32450a81ce13ed5a0729d3b84e8/Modules/_ssl.c#L3487-L3535

https://github.com/python/cpython/blob/9a50ef43e42ee32450a81ce13ed5a0729d3b84e8/Modules/_ssl.c#L3393-L3415

To solve your problem Python would have to support something like:

def alpn_cb(sslsocket, client_alpn_protocols, negotiated):
    return negotiated

context.alpn_cb = alpn_cb

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43582>
_______________________________________

From report at bugs.python.org  Sun Mar 21 14:24:50 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 21 Mar 2021 18:24:50 +0000
Subject: [issue43569] test_importlib failed on installed Python
In-Reply-To: <1616252286.95.0.663253122373.issue43569@roundup.psfhosted.org>
Message-ID: <1616351090.96.0.377644569448.issue43569@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Unfortunately, it seems the patch didn't have the intended effect. The [build is still failing](https://buildbot.python.org/all/#/builders/14/builds/810). So I'm left without a way to test without committing code to the main branch.

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43569>
_______________________________________

From report at bugs.python.org  Sun Mar 21 14:40:39 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Mar 2021 18:40:39 +0000
Subject: [issue43569] test_importlib failed on installed Python
In-Reply-To: <1616252286.95.0.663253122373.issue43569@roundup.psfhosted.org>
Message-ID: <1616352039.83.0.649925461753.issue43569@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't think that build includes your change.
Here are the builds that have been triggered (the list seems incomplete for now):
https://buildbot.python.org/all/#/changes/3355

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43569>
_______________________________________

From report at bugs.python.org  Sun Mar 21 14:43:02 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 21 Mar 2021 18:43:02 +0000
Subject: [issue43569] test_importlib failed on installed Python
In-Reply-To: <1616252286.95.0.663253122373.issue43569@roundup.psfhosted.org>
Message-ID: <1616352182.84.0.156204383685.issue43569@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Okay, I think you may be right. I saw your name on the build and assumed that meant the merge triggered that build. I'll trigger a build now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43569>
_______________________________________

From report at bugs.python.org  Sun Mar 21 14:46:06 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 21 Mar 2021 18:46:06 +0000
Subject: [issue43569] test_importlib failed on installed Python
In-Reply-To: <1616252286.95.0.663253122373.issue43569@roundup.psfhosted.org>
Message-ID: <1616352366.03.0.221276835017.issue43569@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Assuming Antoine is correct (a likely story), I'm closing and will only re-open if a subsequent failure is confirmed to have run and failed after the submission. Sorry for the noise.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43569>
_______________________________________

From report at bugs.python.org  Sun Mar 21 14:55:30 2021
From: report at bugs.python.org (Irit Katriel)
Date: Sun, 21 Mar 2021 18:55:30 +0000
Subject: [issue14189] C API documentation must document if returned object is
 a borrowed reference or strong reference
In-Reply-To: <1330834739.26.0.103894619612.issue14189@psf.upfronthosting.co.za>
Message-ID: <1616352930.74.0.161807008722.issue14189@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

This was fixed for all the functions listed by the OP, except a few that no longer exist AFAICT:

Doc/c-api/import.rst:  _PyImport_FindExtension
Doc/c-api/import.rst:  _PyImport_FixupExtension
Doc/c-api/init.rst:  PyEval_GetCallStats
Doc/c-api/int.rst:  PyInt_FromSize_t

----------
nosy: +iritkatriel
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14189>
_______________________________________

From report at bugs.python.org  Sun Mar 21 15:53:55 2021
From: report at bugs.python.org (Irit Katriel)
Date: Sun, 21 Mar 2021 19:53:55 +0000
Subject: [issue37891] Exceptions tutorial page does not mention raise from
In-Reply-To: <1566285667.91.0.992762773609.issue37891@roundup.psfhosted.org>
Message-ID: <1616356435.3.0.68943913168.issue37891@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
keywords: +easy
versions: +Python 3.10 -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/issue37891>
_______________________________________

From report at bugs.python.org  Sun Mar 21 16:15:15 2021
From: report at bugs.python.org (Andrew Dailey)
Date: Sun, 21 Mar 2021 20:15:15 +0000
Subject: [issue43582] SSLContext.sni_callback docs inaccurately describe
 available handshake info
In-Reply-To: <1616338437.57.0.677049840589.issue43582@roundup.psfhosted.org>
Message-ID: <1616357715.09.0.4079207853.issue43582@roundup.psfhosted.org>


Andrew Dailey <steveday168 at gmail.com> added the comment:

Yea, I noticed that through some of my digging. The ALPN callback is used to implement SSLContext.set_alpn_protocols() but full control of the callback isn't exposed. Aside from adjusting how the ALPN callback used, do you know of any other way to swap contexts once the selected ALPN proto is known but not before it's too late? As I said before, I'm not super familiar with Python / OpenSSL internals but maybe overriding SSLSocket.do_handshake() would suffice? I don't want this issue to get too far off track.

I'm still doing research on how I'd go about drafting and submitting a formal patch here on the issue tracker. I'm new to this process but definitely want to help out as much as I can.

Here's my current idea for how to adjust the documentation given the current behavior / capabilities.

CURRENT:
Due to the early negotiation phase of the TLS connection, only limited methods and attributes are usable like SSLSocket.selected_alpn_protocol() and SSLSocket.context. SSLSocket.getpeercert(), SSLSocket.getpeercert(), SSLSocket.cipher() and SSLSocket.compress() methods require that the TLS connection has progressed beyond the TLS Client Hello and therefore will not contain return meaningful values nor can they be called safely.

REVISED:
Based on the value of `sni_name`, a new SSLContext can be created and attached to the current SSLSocket. Due to the early negotiation phase of the TLS connection, only the Client Hello will have occurred by the time this callback is called. Methods and attributes such as SSLSocket.selected_alpn_protocol(), SSLSocket.getpeercert(), SSLSocket.cipher(), and SSLSocket.compress() require that the TLS connection has progressed beyond the TLS Client Hello and therefore will not contain return meaningful values nor can they be called safely.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43582>
_______________________________________

From report at bugs.python.org  Sun Mar 21 16:16:14 2021
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 21 Mar 2021 20:16:14 +0000
Subject: [issue43567] regen.vcxproj cannot regenerate some necessary files
In-Reply-To: <1616238138.44.0.687655765468.issue43567@roundup.psfhosted.org>
Message-ID: <1616357774.14.0.455437541034.issue43567@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43567>
_______________________________________

From report at bugs.python.org  Sun Mar 21 17:08:52 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 21 Mar 2021 21:08:52 +0000
Subject: [issue39484] [time] document that integer nanoseconds may be more
 precise than float
In-Reply-To: <1580302965.78.0.0683890137903.issue39484@roundup.psfhosted.org>
Message-ID: <1616360932.49.0.882180093325.issue39484@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation, Extension Modules -Library (Lib)
nosy: +docs at python
title: time_ns() and time() cannot be compared on windows -> [time] document that integer nanoseconds may be more precise than float
type: behavior -> enhancement
versions: +Python 3.10, Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39484>
_______________________________________

From report at bugs.python.org  Sun Mar 21 17:10:58 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 21 Mar 2021 21:10:58 +0000
Subject: [issue37205] time.perf_counter() is not system-wide on Windows,
 in disagreement with documentation
In-Reply-To: <1560017700.11.0.127727162727.issue37205@roundup.psfhosted.org>
Message-ID: <1616361058.22.0.369366060959.issue37205@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
Removed message: https://bugs.python.org/msg380941

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37205>
_______________________________________

From report at bugs.python.org  Sun Mar 21 17:11:01 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 21 Mar 2021 21:11:01 +0000
Subject: [issue37205] time.perf_counter() is not system-wide on Windows,
 in disagreement with documentation
In-Reply-To: <1560017700.11.0.127727162727.issue37205@roundup.psfhosted.org>
Message-ID: <1616361061.65.0.924389687274.issue37205@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
Removed message: https://bugs.python.org/msg380944

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37205>
_______________________________________

From report at bugs.python.org  Sun Mar 21 17:16:32 2021
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 21 Mar 2021 21:16:32 +0000
Subject: [issue43582] SSLContext.sni_callback docs inaccurately describe
 available handshake info
In-Reply-To: <1616338437.57.0.677049840589.issue43582@roundup.psfhosted.org>
Message-ID: <1616361392.68.0.288832669923.issue43582@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

The callback from context.alpn_callback would fire when OpenSSL handles the ALPN extension. Since the callback is triggered in the ClientHello phase of the handshake, you'll be able to replace the socket's context with another context.

The OpenSSL codes work a bit like this:

TLSEXT_INDEX = [
    ...,
    TLSEXT_IDX_server_name,
    ...,
    TLSEXT_IDX_application_layer_protocol_negotiation,
]

for extid in TLSEXT_INDEX:
    if client.has_extension(extid):
        ext = do_stuff(client, extid)
        ext.callback(client)

Any of the callbacks is able to replace the context.

The process for contributing to Python is explained in the devguide:
https://devguide.python.org/. Please start by signing a contributor agreement. Then you can file a PR on Github.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43582>
_______________________________________

From report at bugs.python.org  Sun Mar 21 18:01:27 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 21 Mar 2021 22:01:27 +0000
Subject: [issue43585] perf_counter() returns computers uptime
In-Reply-To: <1616344693.53.0.493745901493.issue43585@roundup.psfhosted.org>
Message-ID: <1616364087.14.0.974665540421.issue43585@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

For Windows, starting with Python 3.10, the value of time.perf_counter[_ns]() is system wide instead of relative to the first time it's accessed in the current process. This allows comparing the counter value across processes. See bpo-37205.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43585>
_______________________________________

From report at bugs.python.org  Sun Mar 21 18:59:12 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 21 Mar 2021 22:59:12 +0000
Subject: [issue15286] normpath does not work with local literal paths
In-Reply-To: <1341679642.43.0.277228630346.issue15286@psf.upfronthosting.co.za>
Message-ID: <1616367552.42.0.115751459604.issue15286@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
Removed message: https://bugs.python.org/msg338058

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15286>
_______________________________________

From report at bugs.python.org  Sun Mar 21 19:12:21 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 21 Mar 2021 23:12:21 +0000
Subject: [issue15286] normpath does not work with local literal paths
In-Reply-To: <1341679642.43.0.277228630346.issue15286@psf.upfronthosting.co.za>
Message-ID: <1616368341.04.0.961206008482.issue15286@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

This old issue still needs to be fixed. The check for special_prefixes in ntpath.normpath() must be removed in order to be consistent with WinAPI GetFullPathNameW(). In Windows, one can just call ntpath.abspath() to ensure that nt._getfullpathname() is called. But "Lib/ntpath.py" is cross-platform.

----------
assignee: brian.curtin -> 
components: +Library (Lib)
nosy: +paul.moore, steve.dower, zach.ware
stage: patch review -> needs patch
versions: +Python 3.10, Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15286>
_______________________________________

From report at bugs.python.org  Sun Mar 21 19:22:07 2021
From: report at bugs.python.org (Irit Katriel)
Date: Sun, 21 Mar 2021 23:22:07 +0000
Subject: [issue17792] Unhelpful UnboundLocalError due to del'ing of exception
 target
In-Reply-To: <1366329322.51.0.489771554551.issue17792@psf.upfronthosting.co.za>
Message-ID: <1616368927.6.0.408405131904.issue17792@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

I think the issue is that the error message for UnboundLocalError is wrong, see this example:

>>> def g():
...    x = 42
...    del x
...    print(x)
...
>>> g()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 4, in g
UnboundLocalError: local variable 'x' referenced before assignment
>>>


How about we change it to "local variable 'x' referenced before assignment or after deletion"?

----------
components: +Interpreter Core
nosy: +iritkatriel
versions: +Python 3.10 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17792>
_______________________________________

From report at bugs.python.org  Sun Mar 21 19:39:26 2021
From: report at bugs.python.org (pmp-p)
Date: Sun, 21 Mar 2021 23:39:26 +0000
Subject: [issue17792] Unhelpful UnboundLocalError due to del'ing of exception
 target
In-Reply-To: <1366329322.51.0.489771554551.issue17792@psf.upfronthosting.co.za>
Message-ID: <1616369966.93.0.484532479062.issue17792@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/issue17792>
_______________________________________

From report at bugs.python.org  Sun Mar 21 19:53:10 2021
From: report at bugs.python.org (Irit Katriel)
Date: Sun, 21 Mar 2021 23:53:10 +0000
Subject: [issue27823] Change bare AttributeError messages to be more
 informative
In-Reply-To: <1471796868.81.0.379385981847.issue27823@psf.upfronthosting.co.za>
Message-ID: <1616370790.49.0.531183552832.issue27823@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

-1

As Anilyka wrote: "it (AttributeError) doesn't even mean the attribute doesn't exist, as it may".

So it's not safe to fill in a missing message based on the assumption that we know what it should be.

----------
nosy: +iritkatriel

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27823>
_______________________________________

From report at bugs.python.org  Sun Mar 21 20:14:18 2021
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 22 Mar 2021 00:14:18 +0000
Subject: [issue35754] [Windows] I/O on a broken pipe may raise an EINVAL
 OSError instead of BrokenPipeError
In-Reply-To: <1547674388.65.0.744708229654.issue35754@roundup.psfhosted.org>
Message-ID: <1616372058.59.0.237822905314.issue35754@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

It's still the case that we have to guess that a generic EINVAL (22) is actually EPIPE. Low-level wrapper functions in Python/fileutils.c, such as _Py_read() and _Py_write_impl(), should try to get a better error code by calling Python's custom winerror_to_errno() mapping function on the CRT's _doserrno value. For example:

_Py_read:

    #ifdef MS_WINDOWS
            n = read(fd, buf, (int)count);
            if (n < 0 && errno == EINVAL) {
                errno = winerror_to_errno(_doserrno);
            }

_Py_write_impl:

    #ifdef MS_WINDOWS
                n = write(fd, buf, (int)count);
                if (n < 0 && errno == EINVAL) {
                    errno = winerror_to_errno(_doserrno);
                }

This maps ERROR_NO_DATA to EPIPE.

----------
title: When writing/closing a closed Popen.stdin, I get OSError vs. BrokenPipeError randomly or depending on bufsize -> [Windows] I/O on a broken pipe may raise an EINVAL OSError instead of BrokenPipeError
versions: +Python 3.10, Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35754>
_______________________________________

From report at bugs.python.org  Sun Mar 21 20:46:22 2021
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 22 Mar 2021 00:46:22 +0000
Subject: [issue38188] Incorrect Argument Order for Calls to
 _winapi.DuplicateHandle() in multiprocessing.reduction.DupHandle
In-Reply-To: <1568656297.2.0.121307750927.issue38188@roundup.psfhosted.org>
Message-ID: <1616373982.69.0.00891140728476.issue38188@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
components: +Library (Lib)
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38188>
_______________________________________

From report at bugs.python.org  Sun Mar 21 21:00:39 2021
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 22 Mar 2021 01:00:39 +0000
Subject: [issue39920] os.stat() and os.lstat() fail with Windows device paths
In-Reply-To: <1583802295.48.0.863493828127.issue39920@roundup.psfhosted.org>
Message-ID: <1616374839.53.0.654155361456.issue39920@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

3.7.8, released on 2020-06-27, was the last bugfix release of Python 3.7, so I'm closing this issue as a duplicate of bpo-33898, which is about supporting device paths correctly in pathlib.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> pathlib issues with Windows device paths

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39920>
_______________________________________

From report at bugs.python.org  Sun Mar 21 21:07:54 2021
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 22 Mar 2021 01:07:54 +0000
Subject: [issue36860] Inconsistent/Undocumented behavior with pathlib resolve
 and absolute on Windows
In-Reply-To: <1557368270.63.0.171172492568.issue36860@roundup.psfhosted.org>
Message-ID: <1616375274.42.0.0895285715809.issue36860@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

The issue with non-strict resolution of relative paths that do not exist is being addressed in bpo-38671. The proposal to support and document the absolute() method is addressed in bpo-29688.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> pathlib.Path.resolve(strict=False) returns relative path on Windows if the entry does not exist

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36860>
_______________________________________

From report at bugs.python.org  Sun Mar 21 21:21:45 2021
From: report at bugs.python.org (Ashwin Ramaswami)
Date: Mon, 22 Mar 2021 01:21:45 +0000
Subject: [issue37860] Add deploy preview for docs
In-Reply-To: <1565817286.53.0.142673590989.issue37860@roundup.psfhosted.org>
Message-ID: <1616376105.28.0.42810570026.issue37860@roundup.psfhosted.org>


Ashwin Ramaswami <aramaswamis at gmail.com> added the comment:

I realized there's another alternative which is probably simpler. We can use Netlify to host the deploy previews, but we can use GitHub Actions to build the documentation. This way, we won't run into the build time limits for Netlify, and we can still use Netlify to host deploy previews.

We can use this GitHub Actions action: https://github.com/marketplace/actions/netlify-actions, and just add it as an additional step to our existing doc GitHub Actions workflow (https://github.com/python/cpython/blob/master/.github/workflows/doc.yml).

What do you think about this approach?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37860>
_______________________________________

From report at bugs.python.org  Sun Mar 21 21:23:26 2021
From: report at bugs.python.org (Ashwin Ramaswami)
Date: Mon, 22 Mar 2021 01:23:26 +0000
Subject: [issue37860] Add deploy preview for docs
In-Reply-To: <1565817286.53.0.142673590989.issue37860@roundup.psfhosted.org>
Message-ID: <1616376206.38.0.206052040581.issue37860@roundup.psfhosted.org>


Change by Ashwin Ramaswami <aramaswamis at gmail.com>:


----------
nosy: +EWDurbin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37860>
_______________________________________

From report at bugs.python.org  Sun Mar 21 22:31:24 2021
From: report at bugs.python.org (Tim Peters)
Date: Mon, 22 Mar 2021 02:31:24 +0000
Subject: [issue43420] Optimize rational arithmetics
In-Reply-To: <1615040297.73.0.541090358152.issue43420@roundup.psfhosted.org>
Message-ID: <1616380284.65.0.704663299214.issue43420@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:


New changeset 690aca781152a498f5117682524d2cd9aa4d7657 by Sergey B Kirpichev in branch 'master':
bpo-43420: Simple optimizations for Fraction's arithmetics (GH-24779)
https://github.com/python/cpython/commit/690aca781152a498f5117682524d2cd9aa4d7657


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43420>
_______________________________________

From report at bugs.python.org  Sun Mar 21 22:35:59 2021
From: report at bugs.python.org (Tim Peters)
Date: Mon, 22 Mar 2021 02:35:59 +0000
Subject: [issue43420] Optimize rational arithmetics
In-Reply-To: <1615040297.73.0.541090358152.issue43420@roundup.psfhosted.org>
Message-ID: <1616380559.06.0.14316350785.issue43420@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Thanks, all! This has been merged now. If someone wants to continue pursuing things left hanging, I'd suggest opening a different BPO report.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43420>
_______________________________________

From report at bugs.python.org  Sun Mar 21 22:40:15 2021
From: report at bugs.python.org (Vincent Pelletier)
Date: Mon, 22 Mar 2021 02:40:15 +0000
Subject: [issue34747] SSLSocket.context cannot be changed on non-connected
 sockets
In-Reply-To: <1537429145.63.0.956365154283.issue34747@psf.upfronthosting.co.za>
Message-ID: <1616380815.67.0.728863186244.issue34747@roundup.psfhosted.org>


Vincent Pelletier <vincent at nexedi.com> added the comment:

Added: affects Python 3.9

This bug is still preventing (...or shall I say "discourages", as the setter is effective but raises) server-side SSL certificate reloading on long-running services.
This codepath on listening sockets is necessary for seamless certificate renewal, so the new certificate is used on any accepted connection past the setter call.

Is there anything that needs to be changed to the fix I proposed ?
Should I open a merge/pull request somewhere ?

----------
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34747>
_______________________________________

From report at bugs.python.org  Sun Mar 21 23:06:04 2021
From: report at bugs.python.org (Max Prokop)
Date: Mon, 22 Mar 2021 03:06:04 +0000
Subject: [issue26680] Incorporating float.is_integer into Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1616382364.95.0.758946041724.issue26680@roundup.psfhosted.org>


Change by Max Prokop <maxusz666 at gmail.com>:


----------
components: +2to3 (2.x to 3.x conversion tool), Argument Clinic, Build, C API, Cross-Build, Demos and Tools, Distutils, Documentation, asyncio, ctypes
nosy: +Alex.Willmer, asvetlov, dstufft, eric.araujo, larry, yselivanov
type: enhancement -> compile error
Added file: https://bugs.python.org/file49898/Mobile_Signup.vcf

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26680>
_______________________________________

From report at bugs.python.org  Sun Mar 21 23:12:37 2021
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 22 Mar 2021 03:12:37 +0000
Subject: [issue38428] Can't gracefully ctrl+C multiprocessing pool on Python3
 & Windows
In-Reply-To: <1570696551.92.0.213022823921.issue38428@roundup.psfhosted.org>
Message-ID: <1616382757.36.0.653427509932.issue38428@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

In bpo-29971 it was suggested to split the PyThread lock API in Windows into an "interruptible lock" API that's based on emulated condition variables and a "fast lock" API that's based on native condition variables and SRW locks. Maybe the only API change that's needed in that regard is to add PyThread_allocate_lock_ex(int interruptible), and otherwise dispatch on the lock type that's set in the PNRMUTEX.

----------
versions: +Python 3.10 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38428>
_______________________________________

From report at bugs.python.org  Mon Mar 22 00:10:47 2021
From: report at bugs.python.org (Sergey B Kirpichev)
Date: Mon, 22 Mar 2021 04:10:47 +0000
Subject: [issue43420] Optimize rational arithmetics
In-Reply-To: <1616380559.06.0.14316350785.issue43420@roundup.psfhosted.org>
Message-ID: <YFgYwuHY/XV9cLdc@note>


Sergey B Kirpichev <skirpichev at gmail.com> added the comment:

On Mon, Mar 22, 2021 at 02:35:59AM +0000, Tim Peters wrote:
> Thanks, all! This has been merged now. If someone wants to
> continue pursuing things left hanging, I'd suggest opening
> a different BPO report.

Tim, if you are about micro-optimizations for small components
(properties->attributes and so on, I think this not worth
BPO report of the news entry, isn't?

Thanks for all reviewers and commenters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43420>
_______________________________________

From report at bugs.python.org  Mon Mar 22 00:14:43 2021
From: report at bugs.python.org (Shin Ryu)
Date: Mon, 22 Mar 2021 04:14:43 +0000
Subject: [issue43586] sys.path is weird in Windows 10.
Message-ID: <1616386482.98.0.154100807253.issue43586@roundup.psfhosted.org>


New submission from Shin Ryu <kurishin at gmail.com>:

import sys
print(sys.path)

only on windows, they print sys.path[0] is python38.zip not "".

(docs.python.org says "As initialized upon program startup, the first item of this list, path[0], is the directory containing the script that was used to invoke the Python interpreter. If the script directory is not available (e.g. if the interpreter is invoked interactively or if the script is read from standard input), path[0] is the empty string, which directs Python to search modules in the current directory first. Notice that the script directory is inserted before the entries inserted as a result of PYTHONPATH.")

----------
components: Windows
messages: 389275
nosy: RyuSh1n, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: sys.path is weird in Windows 10.
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43586>
_______________________________________

From report at bugs.python.org  Mon Mar 22 00:34:32 2021
From: report at bugs.python.org (Tim Peters)
Date: Mon, 22 Mar 2021 04:34:32 +0000
Subject: [issue43420] Optimize rational arithmetics
In-Reply-To: <1615040297.73.0.541090358152.issue43420@roundup.psfhosted.org>
Message-ID: <1616387672.27.0.516556515031.issue43420@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

If experience is any guide, nothing about anything here will go smoothly ;-)

For example, setting up a module global `_gcd` name for `math.gcd` is a very standard, widespread kind of micro-optimization. But - if that's thought to be valuable (who knows? maybe someone will complain) - why not go on instead to add not-intended-to-be-passed trailing default `_gcd=math.gcd` arguments to the methods? Then it's even faster (& uglier, of course).

Or wrt changing properties to private attributes, that speeds some things but slows others - and, unless I missed it, nobody who wrote that code to begin with said a word about why it was done that way.

I'm not going to "pre-bless" shortcuts in an area where everything so far has been more contentious than it "should have been" (to my eyes). Opening a BPO report is a trivial effort. Skipping NEWS, or not, depends on how it goes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43420>
_______________________________________

From report at bugs.python.org  Mon Mar 22 01:00:57 2021
From: report at bugs.python.org (Sergey B Kirpichev)
Date: Mon, 22 Mar 2021 05:00:57 +0000
Subject: [issue43420] Optimize rational arithmetics
In-Reply-To: <1616387672.27.0.516556515031.issue43420@roundup.psfhosted.org>
Message-ID: <YFgkhGL9rMa1GcEn@note>


Sergey B Kirpichev <skirpichev at gmail.com> added the comment:

On Mon, Mar 22, 2021 at 04:34:32AM +0000, Tim Peters wrote:
> For example, setting up a module global `_gcd` name for `math.gcd`

Looking on the stdlib, I would just import gcd.

> default `_gcd=math.gcd` arguments to the methods? Then it's
> even faster (& uglier, of course).

... and less readable.

Not sure if speedup will be noticeable.  But more important is
that I see no such micro-optimizations across the stdlib.  Probably,
this will be the reason for rejection.

> Or wrt changing properties to private attributes, that speeds some
> things but slows others - and, unless I missed it, nobody who wrote
> that code to begin with said a word about why it was done that way.

Yes, I'll dig into the history.  Commen^WDocstring doesn't explain
this (for me).

> Opening a BPO report is a trivial effort.

Sure, but such report will require patch to be
discussed, anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43420>
_______________________________________

From report at bugs.python.org  Mon Mar 22 01:23:30 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 22 Mar 2021 05:23:30 +0000
Subject: [issue26680] Incorporating float.is_integer into Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1616390610.83.0.630084875971.issue26680@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


Removed file: https://bugs.python.org/file49898/Mobile_Signup.vcf

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26680>
_______________________________________

From report at bugs.python.org  Mon Mar 22 01:28:39 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 22 Mar 2021 05:28:39 +0000
Subject: [issue26680] Incorporating float.is_integer into Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1616390919.06.0.823738671995.issue26680@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
components:  -2to3 (2.x to 3.x conversion tool), Argument Clinic, Build, C API, Cross-Build, Demos and Tools, Distutils, Documentation, Extension Modules, asyncio, ctypes
nosy:  -Alex.Willmer, asvetlov, dstufft, eric.araujo, larry, yselivanov
type: compile error -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26680>
_______________________________________

From report at bugs.python.org  Mon Mar 22 02:01:49 2021
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 22 Mar 2021 06:01:49 +0000
Subject: [issue43586] sys.path is weird in Windows 10.
In-Reply-To: <1616386482.98.0.154100807253.issue43586@roundup.psfhosted.org>
Message-ID: <1616392909.1.0.215916855044.issue43586@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> on windows, they print sys.path[0] is python38.zip not "".

Isolated mode is probably enabled, i.e. `sys.flags.isolated == 1`. It's enabled by default for the embedded distribution [1], or if a "._pth" file exists beside and with the same base name as the executable or DLL (e.g.  "python._pth" or "python38._pth") [2].

---

[1] https://docs.python.org/3/using/windows.html#the-embeddable-package
[2] https://docs.python.org/3/using/windows.html#finding-modules

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43586>
_______________________________________

From report at bugs.python.org  Mon Mar 22 02:54:25 2021
From: report at bugs.python.org (Shin Ryu)
Date: Mon, 22 Mar 2021 06:54:25 +0000
Subject: [issue43586] sys.path is weird in Windows 10.
In-Reply-To: <1616386482.98.0.154100807253.issue43586@roundup.psfhosted.org>
Message-ID: <1616396065.32.0.091992351879.issue43586@roundup.psfhosted.org>


Shin Ryu <kurishin at gmail.com> added the comment:

Thank you.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43586>
_______________________________________

From report at bugs.python.org  Mon Mar 22 03:11:17 2021
From: report at bugs.python.org (Xinmeng Xia)
Date: Mon, 22 Mar 2021 07:11:17 +0000
Subject: [issue43509] CFunctionType object should be hashable in Python
In-Reply-To: <1615864232.13.0.0243161103861.issue43509@roundup.psfhosted.org>
Message-ID: <1616397077.83.0.275149781848.issue43509@roundup.psfhosted.org>


Change by Xinmeng Xia <xiaxm at smail.nju.edu.cn>:


----------
type: compile error -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43509>
_______________________________________

From report at bugs.python.org  Mon Mar 22 03:12:49 2021
From: report at bugs.python.org (Xinmeng Xia)
Date: Mon, 22 Mar 2021 07:12:49 +0000
Subject: [issue43587] Long string arguments cause nis.map() segfault
Message-ID: <1616397169.5.0.857668484113.issue43587@roundup.psfhosted.org>


New submission from Xinmeng Xia <xiaxm at smail.nju.edu.cn>:

nis.maps() with long string argument will lead to segfault of interpreter.  See the following example:

=====================================================
Python 3.10.0a6 (default, Mar 19 2021, 11:45:56) [GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import nis;
>>> nis.maps('abs/'*10000000)
Segmentation fault (core dumped)
=====================================================

System: ubuntu 16.04

----------
components: Library (Lib)
messages: 389280
nosy: xxm
priority: normal
severity: normal
status: open
title: Long string arguments cause nis.map() segfault
type: crash
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43587>
_______________________________________

From report at bugs.python.org  Mon Mar 22 04:01:03 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Mar 2021 08:01:03 +0000
Subject: [issue43587] Long string arguments cause nis.map() segfault
In-Reply-To: <1616397169.5.0.857668484113.issue43587@roundup.psfhosted.org>
Message-ID: <1616400063.68.0.783070444419.issue43587@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I can reproduce the crash. It's a not a bug in Python but in yp_master(). On my Fedora 33, this function comes from libnsl2 (/lib64/libnsl.so.2):

* https://bugz.fedoraproject.org/libnsl2
* https://github.com/thkukuk/libnsl

"""
This package contains the libnsl library. This library contains
the public client interface for NIS(YP) and NIS+.
This code was formerly part of glibc, but is now standalone to
be able to link against TI-RPC for IPv6 support.
"""

Please report the bug to https://bugz.fedoraproject.org/libnsl2 (or to you nis implementation).

----------
nosy: +vstinner
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43587>
_______________________________________

From report at bugs.python.org  Mon Mar 22 04:09:32 2021
From: report at bugs.python.org (junyixie)
Date: Mon, 22 Mar 2021 08:09:32 +0000
Subject: [issue43588] [Subinterpreters]: use static variable under building
 Python with --with-experimental-isolated-subinterpreters cause crash.
Message-ID: <1616400572.08.0.67077600893.issue43588@roundup.psfhosted.org>


New submission from junyixie <xie.junyi at outlook.com>:

use static module variable under building Python with --with-experimental-isolated-subinterpreters cause crash.
compiler_mod(struct compiler *c, mod_ty mod)
{
    PyCodeObject *co;
    int addNone = 1;
    static PyObject *module;
    if (!module) {
        module = PyUnicode_InternFromString("<module>");
        if (!module)
            return NULL;
    }
...
}

----------
components: Subinterpreters
messages: 389282
nosy: JunyiXie, vstinner
priority: normal
severity: normal
status: open
title: [Subinterpreters]: use static variable under building Python with --with-experimental-isolated-subinterpreters cause crash.
type: crash
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43588>
_______________________________________

From report at bugs.python.org  Mon Mar 22 04:18:41 2021
From: report at bugs.python.org (junyixie)
Date: Mon, 22 Mar 2021 08:18:41 +0000
Subject: [issue43588] [Subinterpreters]: use static variable under building
 Python with --with-experimental-isolated-subinterpreters cause crash.
In-Reply-To: <1616400572.08.0.67077600893.issue43588@roundup.psfhosted.org>
Message-ID: <1616401121.24.0.925533090918.issue43588@roundup.psfhosted.org>


Change by junyixie <xie.junyi at outlook.com>:


----------
keywords: +patch
pull_requests: +23720
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24963

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43588>
_______________________________________

From report at bugs.python.org  Mon Mar 22 04:20:23 2021
From: report at bugs.python.org (junyixie)
Date: Mon, 22 Mar 2021 08:20:23 +0000
Subject: [issue43588] [Subinterpreters]: use static variable under building
 Python with --with-experimental-isolated-subinterpreters cause crash.
In-Reply-To: <1616400572.08.0.67077600893.issue43588@roundup.psfhosted.org>
Message-ID: <1616401223.94.0.584251463286.issue43588@roundup.psfhosted.org>


junyixie <xie.junyi at outlook.com> added the comment:

43551 [Subinterpreters]: PyImport_Import use static silly_list under building Python with --with-experimental-isolated-subinterpreters share silly_list in multi subinterpreters  cause crash.
https://bugs.python.org/issue43551

----------
message_count: 1.0 -> 2.0
pull_requests: +23722
pull_request: https://github.com/python/cpython/pull/24929

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43588>
_______________________________________

From report at bugs.python.org  Mon Mar 22 04:32:21 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Mar 2021 08:32:21 +0000
Subject: [issue35134] Add a new Include/cpython/ subdirectory for the "CPython
 API" with implementation details
In-Reply-To: <1541076409.33.0.788709270274.issue35134@psf.upfronthosting.co.za>
Message-ID: <1616401941.31.0.757063103399.issue35134@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 56f031ec5281723b7c617edfa5748f2ae6a4c347 by Hai Shi in branch 'master':
bpo-35134: Add include/cpython/compile.h (GH-24922)
https://github.com/python/cpython/commit/56f031ec5281723b7c617edfa5748f2ae6a4c347


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35134>
_______________________________________

From report at bugs.python.org  Mon Mar 22 05:00:50 2021
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 22 Mar 2021 09:00:50 +0000
Subject: [issue23407] os.walk always follows Windows junctions
In-Reply-To: <1423342763.81.0.179122512075.issue23407@psf.upfronthosting.co.za>
Message-ID: <1616403650.02.0.940345907974.issue23407@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

Python 3.8 introduced some behavior changes to how reparse points are supported, but generalized support for handling name-surrogate reparse points as symlinks was not implemented. Python continues to set S_IFLNK in st_mode only for IO_REPARSE_TAG_SYMLINK reparse points. This ensures that if os.path.islink() is true, the link can be read and copied exactly via os.readlink() and os.symlink(). Otherwise, islink() could be true but readlink() will fail or symlink() will be used to mistakenly copy a mountpoint as a symlink. 

A mountpoint is not equivalent to a symlink in a few cases. The major difference is that mountpoints are evaluated on the server side in a remote path, targeting devices on the server, whereas symlinks are evaluated on the client side, targeting devices on the client (e.g. its "C:" drive) and are subject to the client system's L2R (local to remote), L2L, R2L, and R2R symlink policy. Replacing a mountpoint with a symlink means that, at best, the path will no longer work when accessed remotely, and at worst the client will allow resolving the target locally to something that's dangerously wrong.

Another difference is how the kernel handles mounpoints when opening a path. The target of a mountpoint does not replace the previously traversed path components in the opened path, whereas the target path of a symlink does replace the opened path. The previously traversed path matters when the kernel resolves ".." components in the target of a relative symlink. For example, a relative symlink that traverses up the tree with ".." components may have been tested on a traversed directory, which worked fine. Then later the directory was replaced with a mountpoint (junction) for compatibility, which continued to work fine. But after a CopyTree() that naively replaces the mountpoint with a symlink, the copied relative symlink is either broken, or worse, it resolves to a target that's dangerously wrong.

A generalization of the readlink() and symlink() combination could be implemented to copy any type of name-surrogate reparse point. If Python had something like that, then it could reasonably support any name-surrogate reparse point as a "symlink". That's not without problems, considering the behavior isn't the same and APIs and other applications may only support IO_REPARSE_TAG_SYMLINK in various cases, but sometimes perfect is the enemy of good.

That said, os.walk() can still special case mountpoints and other name-surrogate reparse points. To support cases like this, the lstat() result was extended to include the st_reparse_tag value of name-surrogate reparse points. The stat module has the IO_REPARSE_TAG_SYMLINK and IO_REPARSE_TAG_MOUNT_POINT constants. A simple function that checks for a name-surrogate reparse point could be added as well -- i.e. bool(reparse_tag & 0x20000000).

---

Using st_reparse_tag to abstract checking the file type is awkward. I wanted to support a keyword-only parameter in Windows to expand the 'symlink' domain to include all name-surrogate reparse points. This parameter would have been added to os.[l]stat(), DirEntry.stat(), DirEntry.is_dir(), and DirEntry.is_file(), as well as os.path.islink() and DirEntry.is_symlink(). By default only IO_REPARSE_TAG_SYMLINK would have been handled as a symlink. But this idea wasn't accepted. Instead, custom checks have to be implemented whenever a problem needs the expanded 'symlink' domain.

----------
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23407>
_______________________________________

From report at bugs.python.org  Mon Mar 22 05:01:01 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Mar 2021 09:01:01 +0000
Subject: [issue43569] test_importlib failed on installed Python
In-Reply-To: <1616252286.95.0.663253122373.issue43569@roundup.psfhosted.org>
Message-ID: <1616403661.06.0.94571658123.issue43569@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I confirm that aarch64 Fedora Stable Clang Installed 3.x is back to green, thanks for the fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43569>
_______________________________________

From report at bugs.python.org  Mon Mar 22 05:01:32 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Mar 2021 09:01:32 +0000
Subject: [issue42129] Support resources in namespace packages
In-Reply-To: <1603469006.87.0.128715336786.issue42129@roundup.psfhosted.org>
Message-ID: <1616403692.53.0.951803210164.issue42129@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Please see bpo-43569: "test_importlib failed on installed Python" regression introduced by commit 67148254146948041a77d8a2989f41b88cdb2f99.

It's now fixed, I close again this issue.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42129>
_______________________________________

From report at bugs.python.org  Mon Mar 22 05:15:29 2021
From: report at bugs.python.org (Tenzin)
Date: Mon, 22 Mar 2021 09:15:29 +0000
Subject: [issue43589] Using defaultdict as kwarg to function reuses same
 dictionary every function call
Message-ID: <1616404529.38.0.239841546052.issue43589@roundup.psfhosted.org>


New submission from Tenzin <tenzin_chan at mymail.sutd.edu.sg>:

When using a `defaultdict` as a kwarg to a function that requires another argument, every call to the function uses the same dictionary instance instead of creating a new one.

```>>> from collections import defaultdict
>>> def meow(a, b=defaultdict(list)):
...     b[a].append('moo')
...     return b
... 
>>> c = meow('hi')
>>> c
defaultdict(<class 'list'>, {'hi': ['moo']})
>>> c = meow('bye')
>>> c
defaultdict(<class 'list'>, {'hi': ['moo'], 'bye': ['moo']})
>>> d = meow('hello')
>>> d
defaultdict(<class 'list'>, {'hi': ['moo'], 'bye': ['moo'], 'hello': ['moo']})```

Is this the correct behaviour? Occurred in 3.6.12, 3.7.9, 3.8.5, 3.8.6 and 3.9.0.

----------
messages: 389289
nosy: TenzinCHW
priority: normal
severity: normal
status: open
title: Using defaultdict as kwarg to function reuses same dictionary every function call
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43589>
_______________________________________

From report at bugs.python.org  Mon Mar 22 05:38:40 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 22 Mar 2021 09:38:40 +0000
Subject: [issue43447] Generate vectorcall code to parse arguments using
 Argument Clinic
In-Reply-To: <1615289664.02.0.198288195908.issue43447@roundup.psfhosted.org>
Message-ID: <1616405920.22.0.542745812084.issue43447@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


----------
nosy: +erlendaasland

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43447>
_______________________________________

From report at bugs.python.org  Mon Mar 22 05:47:19 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Mar 2021 09:47:19 +0000
Subject: [issue43551] [Subinterpreters]: PyImport_Import use static silly_list
 under building Python with
 --with-experimental-isolated-subinterpreters share
 silly_list in multi subinterpreters cause crash.
In-Reply-To: <1616137596.99.0.963932745487.issue43551@roundup.psfhosted.org>
Message-ID: <1616406439.75.0.663959969772.issue43551@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 88d9983b561cd59e5f186d98227de0c1a022b498 by junyixie in branch 'master':
bpo-43551: Fix PyImport_Import() for subinterpreters (GH-24929)
https://github.com/python/cpython/commit/88d9983b561cd59e5f186d98227de0c1a022b498


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43551>
_______________________________________

From report at bugs.python.org  Mon Mar 22 05:51:10 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Mar 2021 09:51:10 +0000
Subject: [issue43551] [subinterpreters] Fix PyImport_Import() for
 subinterpreters
In-Reply-To: <1616137596.99.0.963932745487.issue43551@roundup.psfhosted.org>
Message-ID: <1616406670.2.0.159027727498.issue43551@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
components: +Subinterpreters
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
title: [Subinterpreters]: PyImport_Import use static silly_list under building Python with --with-experimental-isolated-subinterpreters share silly_list in multi subinterpreters  cause crash. -> [subinterpreters] Fix PyImport_Import() for subinterpreters
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43551>
_______________________________________

From report at bugs.python.org  Mon Mar 22 05:56:12 2021
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 22 Mar 2021 09:56:12 +0000
Subject: [issue43589] Using defaultdict as kwarg to function reuses same
 dictionary every function call
In-Reply-To: <1616404529.38.0.239841546052.issue43589@roundup.psfhosted.org>
Message-ID: <1616406972.0.0.349963061793.issue43589@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

This is normal, expected behaviour and has nothing to do with defaultdicts specifically. Any mutable object would behave the same way.

Function default parameters are evaluated only once, when the function is defined. They are not re-evaluated on each call.

The standard pattern used for re-evaluating the default is:

    def function(arg=None):
        if arg is None:
            arg = defaultdict(list)
        ...

----------
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43589>
_______________________________________

From report at bugs.python.org  Mon Mar 22 05:58:12 2021
From: report at bugs.python.org (junyixie)
Date: Mon, 22 Mar 2021 09:58:12 +0000
Subject: [issue43588] [Subinterpreters]: use static variable under building
 Python with --with-experimental-isolated-subinterpreters cause crash.
In-Reply-To: <1616400572.08.0.67077600893.issue43588@roundup.psfhosted.org>
Message-ID: <1616407092.82.0.595206675131.issue43588@roundup.psfhosted.org>


junyixie <xie.junyi at outlook.com> added the comment:

grep -E 'static (\w+) \*(\w+) =' $(find . -name "*.c") | wc -l
67 static variable may need fix
?  cpython git:(master) grep -E 'static (\w+) \*(\w+) =' $(find . -name "*.c")
./PC/winreg.c:static char *failMsg = "bad operand type";
./Python/codecs.c:static _PyUnicode_Name_CAPI *ucnhash_capi = NULL;
./Python/initconfig.c:static char *_Py_StandardStreamEncoding = NULL;
./Python/initconfig.c:static char *_Py_StandardStreamErrors = NULL;
./Python/import.c:static PyObject *extensions = NULL;
./Python/import.c:    static PyObject *builtins_str = NULL;
./Python/import.c:    static PyObject *import_str = NULL;
./Python/sysmodule.c:    static PyObject *newline = NULL;
./Python/_warnings.c:    static PyObject *importlib_string = NULL;
./Python/_warnings.c:    static PyObject *bootstrap_string = NULL;
./Objects/unicodeobject.c:static _PyUnicode_Name_CAPI *ucnhash_capi = NULL;
./Objects/codeobject.c:    static PyObject *emptystring = NULL;
./Objects/codeobject.c:    static PyObject *nulltuple = NULL;
./Objects/listobject.c:static PyObject *indexerr = NULL;
./Objects/exceptions.c:    static PyObject *print_prefix = NULL;
./Objects/exceptions.c:    static PyObject *exec_prefix = NULL;
./Objects/boolobject.c:static PyObject *false_str = NULL;
./Objects/boolobject.c:static PyObject *true_str = NULL;
./Parser/pegen.c:    static void *cache = NULL;
./Modules/_cursesmodule.c:static char *screen_encoding = NULL;
./Modules/arraymodule.c:    static PyObject *array_reconstructor = NULL;
./Modules/_tkinter.c:    static PyObject *tcl_library_path = NULL;
./Modules/_tkinter.c:static PyThreadState *tcl_tstate = NULL;
./Modules/_tkinter.c:static PyThreadState *event_tstate = NULL;
./Modules/syslogmodule.c:static PyObject *S_ident_o = NULL;                      /*  identifier, held by openlog()  */
./Modules/_tracemalloc.c:static PyObject *unknown_filename = NULL;
./Modules/_tracemalloc.c:static _Py_hashtable_t *tracemalloc_filenames = NULL;
./Modules/_tracemalloc.c:static traceback_t *tracemalloc_traceback = NULL;
./Modules/_tracemalloc.c:static _Py_hashtable_t *tracemalloc_tracebacks = NULL;
./Modules/_tracemalloc.c:static _Py_hashtable_t *tracemalloc_traces = NULL;
./Modules/_tracemalloc.c:static _Py_hashtable_t *tracemalloc_domains = NULL;
./Modules/_ssl.c:    static PyObject *x509_asn = NULL;
./Modules/_ssl.c:    static PyObject *pkcs_7_asn = NULL;
./Modules/_ssl.c:static PyThread_type_lock *_ssl_locks = NULL;
./Modules/_testbuffer.c:static PyObject *structmodule = NULL;
./Modules/_testbuffer.c:static PyObject *Struct = NULL;
./Modules/_testbuffer.c:static PyObject *calcsize = NULL;
./Modules/_testbuffer.c:static PyObject *simple_format = NULL;
./Modules/_testbuffer.c:static char *infobuf = NULL;
./Modules/_io/bufferedio.c:    static PyObject *eintr_int = NULL;
./Modules/_asynciomodule.c:static futureiterobject *fi_freelist = NULL;
./Modules/_zoneinfo.c:static PyObject *io_open = NULL;
./Modules/_zoneinfo.c:static PyObject *_tzpath_find_tzfile = NULL;
./Modules/_zoneinfo.c:static PyObject *_common_mod = NULL;
./Modules/_zoneinfo.c:static PyObject *TIMEDELTA_CACHE = NULL;
./Modules/_zoneinfo.c:static PyObject *ZONEINFO_WEAK_CACHE = NULL;
./Modules/_zoneinfo.c:static StrongCacheNode *ZONEINFO_STRONG_CACHE = NULL;
./Modules/_sqlite/microprotocols.c:static PyObject *psyco_adapters = NULL;
./Modules/_ssl/debughelpers.c:    static PyThread_type_lock *lock = NULL;
./Modules/_datetimemodule.c:static PyObject *us_per_ms = NULL;      /* 1000 */
./Modules/_datetimemodule.c:static PyObject *us_per_second = NULL;  /* 1000000 */
./Modules/_datetimemodule.c:static PyObject *us_per_minute = NULL;  /* 1e6 * 60 as Python int */
./Modules/_datetimemodule.c:static PyObject *us_per_hour = NULL;    /* 1e6 * 3600 as Python int */
./Modules/_datetimemodule.c:static PyObject *us_per_day = NULL;     /* 1e6 * 3600 * 24 as Python int */
./Modules/_datetimemodule.c:static PyObject *us_per_week = NULL;    /* 1e6*3600*24*7 as Python int */
./Modules/_datetimemodule.c:static PyObject *seconds_per_day = NULL; /* 3600*24 as Python int */
./Modules/_datetimemodule.c:    static PyObject *module = NULL;
./Modules/_decimal/_decimal.c:static PyObject *tls_context_key = NULL;
./Modules/_decimal/_decimal.c:static PyDecContextObject *cached_context = NULL;
./Modules/_decimal/_decimal.c:static PyObject *current_context_var = NULL;
./Modules/_decimal/_decimal.c:static PyObject *default_context_template = NULL;
./Modules/_decimal/_decimal.c:static PyObject *basic_context_template = NULL;
./Modules/_decimal/_decimal.c:static PyObject *extended_context_template = NULL;
./Modules/_decimal/_decimal.c:static PyObject *DecimalException = NULL;
./Modules/_decimal/_decimal.c:static PyObject *Rational = NULL;
./Modules/_decimal/_decimal.c:static PyTypeObject *DecimalTuple = NULL;
./Modules/_decimal/_decimal.c:    static PyObject *capsule = NULL;

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43588>
_______________________________________

From report at bugs.python.org  Mon Mar 22 06:01:27 2021
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 22 Mar 2021 10:01:27 +0000
Subject: [issue43575] map() instantiation time reducing by using PEP 590
 vectorcall
In-Reply-To: <1616297103.49.0.396627193734.issue43575@roundup.psfhosted.org>
Message-ID: <1616407287.88.0.209421833544.issue43575@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:


New changeset 86883d40e93acae980e52b90fddd7d042e439beb by Dong-hee Na in branch 'master':
bpo-43575: Use PEP 590 vectorcall to speed up map() (GH-24955)
https://github.com/python/cpython/commit/86883d40e93acae980e52b90fddd7d042e439beb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43575>
_______________________________________

From report at bugs.python.org  Mon Mar 22 06:01:34 2021
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 22 Mar 2021 10:01:34 +0000
Subject: [issue43575] map() instantiation time reducing by using PEP 590
 vectorcall
In-Reply-To: <1616297103.49.0.396627193734.issue43575@roundup.psfhosted.org>
Message-ID: <1616407294.69.0.767785202591.issue43575@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43575>
_______________________________________

From report at bugs.python.org  Mon Mar 22 06:02:15 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Mar 2021 10:02:15 +0000
Subject: [issue40521] [subinterpreters] Make free lists and unicode caches
 per-interpreter
In-Reply-To: <1588693682.5.0.219755904926.issue40521@roundup.psfhosted.org>
Message-ID: <1616407335.69.0.982795416782.issue40521@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Mark Dickinson: "I just noticed the change to dtoa.c in GH-24821. Please could you explain what the benefit of this change was?"

The rationale is explained in bpo-40512. The goal is to run multiple Python interpreters in parallel in the same process.

dtoa.c had global variables shared by all interpreters without locking, so two intepreters could corrupt the freelist consistency.


Mark Dickinson: "In general, we need to be very conservative with changes to dtoa.c: it's a complex, fragile, performance-critical piece of code, and ideally we'd like it not to diverge from the upstream code any more than it already has, in case we need to integrate bugfixes from upstream."

I know that dtoa.c was copied from a third party project. But the commit 5bd1059184b154d339f1bd53d23c98b5bcf14c8c change change only makes sense in Python, I don't think that it would make sense to propose it upstream.

dtoa.c _Py_dg_strtod() is called by:

* float.__round__()
* _PyOS_ascii_strtod()

_PyOS_ascii_strtod() is called PyOS_string_to_double() which is called by:

* float_from_string_inner()
* complex_from_string_inner()
* pickle load_float()
* parser parsenumber_raw()
* marshal r_float_str

dtoa.c _Py_dg_dtoa() is called by:

* float.__round__()
* PyOS_double_to_string()

PyOS_double_to_string() is called by:

* float_repr()
* complex_repr()
* bytes % float: _PyBytes_FormatEx()
* str % float: PyUnicode_Format()
* _PyLong_FormatAdvancedWriter()
* _PyComplex_FormatAdvancedWriter()
* pickle save_float()
* marshal w_float_str


I guess that the most important use case are float(str) and str(float). I wrote attached bench_dtoa.py to measure the effect on performance of the commit 5bd1059184b154d339f1bd53d23c98b5bcf14c8c:
---
$ python3 -m pyperf compare_to before.json after.json 
float('0'): Mean +- std dev: [before] 80.5 ns +- 3.1 ns -> [after] 90.1 ns +- 3.6 ns: 1.12x slower
float('1.0'): Mean +- std dev: [before] 89.5 ns +- 4.3 ns -> [after] 97.2 ns +- 2.6 ns: 1.09x slower
float('340282366920938463463374607431768211455'): Mean +- std dev: [before] 480 ns +- 42 ns -> [after] 514 ns +- 13 ns: 1.07x slower
float('1044388881413152506691752710716624382579964249047383780384233483283953907971557456848826811934997558340890106714439262837987573438185793607263236087851365277945956976543709998340361590134383718314428070011855946226376318839397712745672334684344586617496807908705803704071284048740118609114467977783598029006686938976881787785946905630190260940599579453432823469303026696443059025015972399867714215541693835559885291486318237914434496734087811872639496475100189041349008417061675093668333850551032972088269550769983616369411933015213796825837188091833656751221318492846368125550225998300412344784862595674492194617023806505913245610825731835380087608622102834270197698202313169017678006675195485079921636419370285375124784014907159135459982790513399611551794271106831134090584272884279791554849782954323534517065223269061394905987693002122963395687782878948440616007412945674919823050571642377154816321380631045902916136926708342856440730447899971901781465763473223850267253059899795996090799469201774624817718449867455659250178329070473119433165550807568221846571746373296884912819520317457002440926616910874148385078411929804522981857338977648103126085903001302413467189726673216491511131602920781738033436090243804708340403154190335'): Mean +- std dev: [before] 717 ns +- 36 ns -> [after] 990 ns +- 27 ns: 1.38x slower
str(0.0): Mean +- std dev: [before] 113 ns +- 8 ns -> [after] 106 ns +- 4 ns: 1.06x faster
str(1.0): Mean +- std dev: [before] 141 ns +- 11 ns -> [after] 135 ns +- 17 ns: 1.05x faster
str(inf): Mean +- std dev: [before] 110 ns +- 11 ns -> [after] 98.9 ns +- 3.3 ns: 1.12x faster

Benchmark hidden because not significant (1): str(3.402823669209385e+38)

Geometric mean: 1.05x slower
---

I built Python with "./configure --enable-optimizations --with-lto" on Fedora 33 (GCC 10.2.1). I didn't use CPU isolation.

Oh, float(str) is between 1.09x slower and 1.38x slower.

On the other side, str(float) is between 1.06x and 1.12x faster, I'm not sure why. I guess that the problem is that PGO+LTO build is not reproducible, GCC might prefer to optimize some functions or others depending on the PROFILE_TASK (Makefile.pre.in, command used by GCC profiler).


Mark Dickinson: "It's feeling as though the normal Python development process is being bypassed here. As I understand it, this and similar changes are in aid of per-subinterpreter GILs. Has there been agreement from the core devs or steering council that this is a desirable goal? Should there be a PEP before more changes like this are made? (Or maybe there's already a PEP, that I missed? I know about PEP 554, but that PEP is explicit that GIL sharing is out of scope.)"


Honestly, I didn't expect any significant impact on performance on the change. So I merged the PR as I merge other fixes for subinterpreters. It seems like I underestimated the number of Balloc/Bmalloc calls per float(str) or str(float) call.

There is no PEP about running multiple Python interpreters in the same process. There is no consensus on this topic. I discussed it in private with some core devs, but that's not relevant here.

My plan is to merge changes which have no significant impact on performances, and wait for a PEP for changes which have a significant impact on performances. Most changes fix bugs in subinterpreters which still share a GIL. This use case is not new and is supported for 10-20 years.


For now, I will the commit 5bd1059184b154d339f1bd53d23c98b5bcf14c8c.

----------
Added file: https://bugs.python.org/file49899/bench_dtoa.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40521>
_______________________________________

From report at bugs.python.org  Mon Mar 22 06:03:06 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Mar 2021 10:03:06 +0000
Subject: [issue40521] [subinterpreters] Make free lists and unicode caches
 per-interpreter
In-Reply-To: <1588693682.5.0.219755904926.issue40521@roundup.psfhosted.org>
Message-ID: <1616407386.34.0.736152981798.issue40521@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +23723
pull_request: https://github.com/python/cpython/pull/24964

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40521>
_______________________________________

From report at bugs.python.org  Mon Mar 22 06:07:14 2021
From: report at bugs.python.org (Erez Zinman)
Date: Mon, 22 Mar 2021 10:07:14 +0000
Subject: [issue43010] @functools.wraps and abc.abstractmethod interoperability
In-Reply-To: <1611411971.69.0.738980453065.issue43010@roundup.psfhosted.org>
Message-ID: <1616407634.27.0.812548225948.issue43010@roundup.psfhosted.org>


Erez Zinman <erezinman.programmer at gmail.com> added the comment:

Sorry for the late response. I forgot about that.

I believe one of us misunderstands the problem. The problem is that `functools.wraps` copies the `__isabstractmethod__` in the first place. 

Consider the following example:

```

class ModuleTemplate(ABC):

    @abstractmethod
    def _internal_main_operation(self, a: int, b: str, c: list) -> bool:
        pass

    @functools.wraps(_internal_main_operation)
    def external_main_operation(self, *args, **kwargs):
        print('LOG: Operation started.')
        try:
            ret = self._internal_main_operation(*args, **kwargs)
        except:
            print('LOG: Operation finished successfully.')
            raise
        else:
            print('LOG: Operation finished successfully.')

        return ret


class ModulePositiveCheck(ModuleTemplate):
    def _internal_main_operation(self, a: int, b: str, c: list) -> bool:
        return a > 0

```

In that case, I have a class that has a main operation that can be called either from the outside or internally. The outside call may be wrapped with some aspect-specific functionality like thread-safety, logging, exception handling, etc.; and the internal call implements the core logic of the class. 
In that (pretty common) pattern, I wouldn't want the `wraps` function to copy all the `abc` attributes because they're irrelevant. In fact, I'm having trouble thinking of a case where you WOULD like these attributes to be copied.


The solution here, I think, is to exclude these attributes from being copied within `functools.update_wrapper`. If you do want to allow copying these attributes (I don't see why, but anyway), you could add an `excluded` parameter to `update_wrapper`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43010>
_______________________________________

From report at bugs.python.org  Mon Mar 22 06:15:28 2021
From: report at bugs.python.org (junyixie)
Date: Mon, 22 Mar 2021 10:15:28 +0000
Subject: [issue43588] [Subinterpreters]: use static variable under building
 Python with --with-experimental-isolated-subinterpreters cause crash.
In-Reply-To: <1616400572.08.0.67077600893.issue43588@roundup.psfhosted.org>
Message-ID: <1616408128.02.0.741829818409.issue43588@roundup.psfhosted.org>


Change by junyixie <xie.junyi at outlook.com>:


----------
pull_requests: +23724
pull_request: https://github.com/python/cpython/pull/24965

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43588>
_______________________________________

From report at bugs.python.org  Mon Mar 22 06:25:25 2021
From: report at bugs.python.org (Lucijan Drnasin)
Date: Mon, 22 Mar 2021 10:25:25 +0000
Subject: [issue43590] Collapse sidebar issue on https://docs.python.org/3/
Message-ID: <1616408725.68.0.0305800294993.issue43590@roundup.psfhosted.org>


New submission from Lucijan Drnasin <lucijan345 at gmail.com>:

Sidebar bug on python welcoming page for version 3.9.2. Two-arrow  span on sidebar (span that has fixed position) is going off the sidebar if I scroll all the way down and then I inspect the page. After inspecting (opening dev tools) it appears there is a litle bit more room to scrool down and span(litle two arrows) goes off the page.

----------
messages: 389296
nosy: lucijan345
priority: normal
severity: normal
status: open
title: Collapse sidebar issue on https://docs.python.org/3/
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43590>
_______________________________________

From report at bugs.python.org  Mon Mar 22 06:25:46 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 22 Mar 2021 10:25:46 +0000
Subject: [issue43591] Parser aborts on incomplete/incorrect unicode literals
 in interactive mode
Message-ID: <1616408746.94.0.619968687767.issue43591@roundup.psfhosted.org>


New submission from Erlend Egeberg Aasland <erlend.aasland at innova.no>:

Incomplete unicode literals abort iso. generating SyntaxError:

(lldb) target create "./python.exe"
Current executable set to '/Users/erlendaasland/src/cpython.git/python.exe' (x86_64).
(lldb) r
Process 98955 launched: '/Users/erlendaasland/src/cpython.git/python.exe' (x86_64)
Python 3.10.0a6+ (heads/main:9a50ef43e4, Mar 22 2021, 11:18:33) [Clang 12.0.0 (clang-1200.0.32.29)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> "\u1f"
Assertion failed: (col_offset >= 0 && (unsigned long)col_offset <= strlen(str)), function byte_offset_to_character_offset, file Parser/pegen.c, line 150.
Process 98955 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = hit program assert
    frame #4: 0x0000000100009bd6 python.exe`byte_offset_to_character_offset(line=0x00000001013f1220, col_offset=7) at pegen.c:150:5
   147 	    if (!str) {
   148 	        return 0;
   149 	    }
-> 150 	    assert(col_offset >= 0 && (unsigned long)col_offset <= strlen(str));
   151 	    PyObject *text = PyUnicode_DecodeUTF8(str, col_offset, "replace");
   152 	    if (!text) {
   153 	        return 0;
Target 0: (python.exe) stopped.
(lldb) p col_offset
(Py_ssize_t) $0 = 7
(lldb) p str
(const char *) $1 = 0x00000001013f1250 "\"\\u1f\""
(lldb) p (size_t) strlen(str)
(size_t) $2 = 6



Python 3.9 behaviour:
Python 3.9.2 (v3.9.2:1a79785e3e, Feb 19 2021, 09:06:10) 
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> "\u1f"
  File "<stdin>", line 1
    "\u1f"
          ^
SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes in position 0-3: truncated \uXXXX escape



Git bisect says the regression was introduced by this commit:

commit 08fb8ac99ab03d767aa0f1cfab3573eddf9df018
Author: Pablo Galindo <Pablogsal at gmail.com>
Date:   Thu Mar 18 01:03:11 2021 +0000

    bpo-42128: Add 'missing :' syntax error message to match statements (GH-24733)


I made a workaround (see attached patch), but I guess that's far from the correct solution :)

----------
components: Unicode
files: patch.diff
keywords: patch
messages: 389297
nosy: erlendaasland, ezio.melotti, lys.nikolaou, pablogsal, vstinner
priority: normal
severity: normal
status: open
title: Parser aborts on incomplete/incorrect unicode literals in interactive mode
type: crash
versions: Python 3.10
Added file: https://bugs.python.org/file49900/patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43591>
_______________________________________

From report at bugs.python.org  Mon Mar 22 06:28:15 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 22 Mar 2021 10:28:15 +0000
Subject: [issue43591] Parser aborts on incomplete/incorrect unicode literals
 in interactive mode
In-Reply-To: <1616408746.94.0.619968687767.issue43591@roundup.psfhosted.org>
Message-ID: <1616408895.11.0.703898789305.issue43591@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

Correction, git bisect pointed to _this_ commit (not 08fb8ac99ab03d767aa0f1cfab3573eddf9df018):

commit cd8dcbc851fcc312722cdb5544c2f25cf46b3f8a
Author: Pablo Galindo <Pablogsal at gmail.com>
Date:   Sun Mar 14 04:38:40 2021 +0100

    bpo-43410: Fix crash in the parser when producing syntax errors when reading from stdin (GH-24763)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43591>
_______________________________________

From report at bugs.python.org  Mon Mar 22 06:31:04 2021
From: report at bugs.python.org (junyixie)
Date: Mon, 22 Mar 2021 10:31:04 +0000
Subject: [issue43588] [Subinterpreters]: use static variable under building
 Python with --with-experimental-isolated-subinterpreters cause crash.
In-Reply-To: <1616400572.08.0.67077600893.issue43588@roundup.psfhosted.org>
Message-ID: <1616409064.45.0.187327282315.issue43588@roundup.psfhosted.org>


junyixie <xie.junyi at outlook.com> added the comment:

fix
./Objects/exceptions.c:    static PyObject *print_prefix = NULL;
./Objects/exceptions.c:    static PyObject *exec_prefix = NULL;

https://github.com/python/cpython/pull/24965

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43588>
_______________________________________

From report at bugs.python.org  Mon Mar 22 06:33:02 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Mar 2021 10:33:02 +0000
Subject: [issue43592] test_importlib:
 test_multiprocessing_pool_circular_import() fails with "Too many open files"
 error on os.pipe()
Message-ID: <1616409182.92.0.0882668450853.issue43592@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

x86-64 macOS 3.x:
https://buildbot.python.org/all/#/builders/366/builds/969

Build triggered by the commit 88d9983b561cd59e5f186d98227de0c1a022b498 which changes PyImport_Import().


The buildbot is running on macOS 10.15.7 (Darwin Kernel Version 19.6.0) with a limit of 256 file descriptors.


The latest successful build is build 968, whereas the the RLIMIT_NOFILE resource soft limit was also set to 256:
https://buildbot.python.org/all/#/builders/366/builds/968


test.pythoninfo:

* os.uname: posix.uname_result(sysname='Darwin', nodename='mattb-mbp2', release='19.6.0', version='Darwin Kernel Version 19.6.0: Tue Jan 12 22:13:05 PST 2021; root:xnu-6153.141.16~1/RELEASE_X86_64', machine='x86_64')
* sysconfig[HOST_GNU_TYPE]: x86_64-apple-darwin19.6.0
* platform.platform: macOS-10.15.7-x86_64-i386-64bit
* resource.RLIMIT_NOFILE: (256, 9223372036854775807)


FAIL: test_multiprocessing_pool_circular_import (test.test_importlib.test_threaded_import.ThreadedImportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/test/test_importlib/test_threaded_import.py", line 258, in test_multiprocessing_pool_circular_import
    script_helper.assert_python_ok(fn)
  File "/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/test/support/script_helper.py", line 160, in assert_python_ok
    return _assert_python(True, *args, **env_vars)
  File "/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/test/support/script_helper.py", line 145, in _assert_python
    res.fail(cmd_line)
  File "/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/test/support/script_helper.py", line 72, in fail
    raise AssertionError("Process return code is %d\n"
AssertionError: Process return code is 1
command line: ['/Users/buildbot/buildarea/3.x.billenstein-macos/build/python.exe', '-X', 'faulthandler', '-I', '/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/test/test_importlib/partial/pool_in_threads.py']

stdout:
---

---

stderr:
---
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/test/test_importlib/partial/pool_in_threads.py", line 9, in t
  File "/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/multiprocessing/context.py", line 119, in Pool
  File "/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/multiprocessing/pool.py", line 196, in __init__
  File "/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/multiprocessing/context.py", line 113, in SimpleQueue
  File "/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/multiprocessing/queues.py", line 341, in __init__
    self._reader, self._writer = connection.Pipe(duplex=False)
  File "/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/multiprocessing/connection.py", line 532, in Pipe
    fd1, fd2 = os.pipe()
OSError: [Errno 24] Too many open files
/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/multiprocessing/resource_tracker.py:224: UserWarning: resource_tracker: There appear to be 110 leaked semaphore objects to clean up at shutdown
  warnings.warn('resource_tracker: There appear to be %d '
/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/multiprocessing/resource_tracker.py:237: UserWarning: resource_tracker: '/mp-56i6i4ap': [Errno 2] No such file or directory
  warnings.warn('resource_tracker: %r: %s' % (name, e))
/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/multiprocessing/resource_tracker.py:237: UserWarning: resource_tracker: '/mp-0au5otkl': [Errno 2] No such file or directory
  warnings.warn('resource_tracker: %r: %s' % (name, e))
/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/multiprocessing/resource_tracker.py:237: UserWarning: resource_tracker: '/mp-vcv0xwbi': [Errno 2] No such file or directory
  warnings.warn('resource_tracker: %r: %s' % (name, e))
/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/multiprocessing/resource_tracker.py:237: UserWarning: resource_tracker: '/mp-vxfb4ks9': [Errno 2] No such file or directory
  warnings.warn('resource_tracker: %r: %s' % (name, e))
/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/multiprocessing/resource_tracker.py:237: UserWarning: resource_tracker: '/mp-5e2_0z1f': [Errno 2] No such file or directory
  warnings.warn('resource_tracker: %r: %s' % (name, e))
/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/multiprocessing/resource_tracker.py:237: UserWarning: resource_tracker: '/mp-6vsgax4k': [Errno 2] No such file or directory
  warnings.warn('resource_tracker: %r: %s' % (name, e))
/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/multiprocessing/resource_tracker.py:237: UserWarning: resource_tracker: '/mp-mq51g4b_': [Errno 2] No such file or directory
  warnings.warn('resource_tracker: %r: %s' % (name, e))
/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/multiprocessing/resource_tracker.py:237: UserWarning: resource_tracker: '/mp-eik0n2aq': [Errno 2] No such file or directory
  warnings.warn('resource_tracker: %r: %s' % (name, e))
/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/multiprocessing/resource_tracker.py:237: UserWarning: resource_tracker: '/mp-g7oeb4aw': [Errno 2] No such file or directory
  warnings.warn('resource_tracker: %r: %s' % (name, e))
/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/multiprocessing/resource_tracker.py:237: UserWarning: resource_tracker: '/mp-tiabsvgr': [Errno 2] No such file or directory
  warnings.warn('resource_tracker: %r: %s' % (name, e))
/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/multiprocessing/resource_tracker.py:237: UserWarning: resource_tracker: '/mp-ykag01b2': [Errno 2] No such file or directory
  warnings.warn('resource_tracker: %r: %s' % (name, e))
/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/multiprocessing/resource_tracker.py:237: UserWarning: resource_tracker: '/mp-nl2kdidn': [Errno 2] No such file or directory
  warnings.warn('resource_tracker: %r: %s' % (name, e))
---

----------
components: Tests
messages: 389301
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_importlib: test_multiprocessing_pool_circular_import() fails with "Too many open files" error on os.pipe()
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43592>
_______________________________________

From report at bugs.python.org  Mon Mar 22 06:33:18 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Mar 2021 10:33:18 +0000
Subject: [issue43551] [subinterpreters] Fix PyImport_Import() for
 subinterpreters
In-Reply-To: <1616137596.99.0.963932745487.issue43551@roundup.psfhosted.org>
Message-ID: <1616409198.57.0.118211401968.issue43551@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

See bpo-43592: test_importlib: test_multiprocessing_pool_circular_import() fails with "Too many open files" error on os.pipe().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43551>
_______________________________________

From report at bugs.python.org  Mon Mar 22 06:32:53 2021
From: report at bugs.python.org (junyixie)
Date: Mon, 22 Mar 2021 10:32:53 +0000
Subject: [issue43588] [Subinterpreters]: use static variable under building
 Python with --with-experimental-isolated-subinterpreters cause crash.
In-Reply-To: <1616400572.08.0.67077600893.issue43588@roundup.psfhosted.org>
Message-ID: <1616409173.37.0.675699315813.issue43588@roundup.psfhosted.org>


Change by junyixie <xie.junyi at outlook.com>:


----------
pull_requests: +23726
pull_request: https://github.com/python/cpython/pull/24966

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43588>
_______________________________________

From report at bugs.python.org  Mon Mar 22 06:51:31 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Mar 2021 10:51:31 +0000
Subject: [issue43592] test_importlib:
 test_multiprocessing_pool_circular_import() fails with "Too many open files"
 error on os.pipe()
In-Reply-To: <1616409182.92.0.0882668450853.issue43592@roundup.psfhosted.org>
Message-ID: <1616410291.52.0.675947471595.issue43592@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

test_importlib only fails *randomly* on x86-64 macOS 3.x.

For example, the build 970 is a success (but orange): "Tests result: FAILURE then SUCCESS". test_importlib failed with too many open files, and then passed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43592>
_______________________________________

From report at bugs.python.org  Mon Mar 22 06:57:32 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Mar 2021 10:57:32 +0000
Subject: [issue43588] [Subinterpreters]: use static variable under building
 Python with --with-experimental-isolated-subinterpreters cause crash.
In-Reply-To: <1616400572.08.0.67077600893.issue43588@roundup.psfhosted.org>
Message-ID: <1616410652.48.0.508770935672.issue43588@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Oh. I didn't expect so many "static" variables. I suggest to wait until a PEP is accepted for running multiple interpreters in parallel.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43588>
_______________________________________

From report at bugs.python.org  Mon Mar 22 06:58:01 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Mar 2021 10:58:01 +0000
Subject: [issue43591] Parser aborts on incomplete/incorrect unicode literals
 in interactive mode
In-Reply-To: <1616408746.94.0.619968687767.issue43591@roundup.psfhosted.org>
Message-ID: <1616410681.05.0.932875965574.issue43591@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43591>
_______________________________________

From report at bugs.python.org  Mon Mar 22 06:59:05 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Mar 2021 10:59:05 +0000
Subject: [issue40521] [subinterpreters] Make free lists and unicode caches
 per-interpreter
In-Reply-To: <1588693682.5.0.219755904926.issue40521@roundup.psfhosted.org>
Message-ID: <1616410745.98.0.261899305311.issue40521@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 39f643614d03748a5fad462fe7ed26a174a522fa by Victor Stinner in branch 'master':
Revert "bpo-40521: Make dtoa bigint free list per-interpreter (GH-24821)" (GH-24964)
https://github.com/python/cpython/commit/39f643614d03748a5fad462fe7ed26a174a522fa


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40521>
_______________________________________

From report at bugs.python.org  Mon Mar 22 07:22:33 2021
From: report at bugs.python.org (Dennis Sweeney)
Date: Mon, 22 Mar 2021 11:22:33 +0000
Subject: [issue43010] @functools.wraps and abc.abstractmethod interoperability
In-Reply-To: <1611411971.69.0.738980453065.issue43010@roundup.psfhosted.org>
Message-ID: <1616412153.21.0.885340196241.issue43010@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

Did you try adding updated=()?

    @functools.wraps(_internal_main_operation, updated=())
    def external_main_operation(self, *args, **kwargs):

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43010>
_______________________________________

From report at bugs.python.org  Mon Mar 22 08:15:41 2021
From: report at bugs.python.org (Erez Zinman)
Date: Mon, 22 Mar 2021 12:15:41 +0000
Subject: [issue43010] @functools.wraps and abc.abstractmethod interoperability
In-Reply-To: <1611411971.69.0.738980453065.issue43010@roundup.psfhosted.org>
Message-ID: <1616415341.02.0.363175798314.issue43010@roundup.psfhosted.org>


Erez Zinman <erezinman.programmer at gmail.com> added the comment:

I haven't because I don't need it anymore and it will surely work. Yet by doing so, other attributes will not be copied. I think that the `abc`-related attributes are irrelevant regardless, and should be omitted (at least by default).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43010>
_______________________________________

From report at bugs.python.org  Mon Mar 22 08:16:43 2021
From: report at bugs.python.org (Erez Zinman)
Date: Mon, 22 Mar 2021 12:16:43 +0000
Subject: [issue43010] @functools.wraps and abc.abstractmethod interoperability
In-Reply-To: <1611411971.69.0.738980453065.issue43010@roundup.psfhosted.org>
Message-ID: <1616415403.65.0.261467275909.issue43010@roundup.psfhosted.org>


Erez Zinman <erezinman.programmer at gmail.com> added the comment:

This is an interoperability bug. Maybe not a severe one (due to the workaround), but it's still a bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43010>
_______________________________________

From report at bugs.python.org  Mon Mar 22 08:25:08 2021
From: report at bugs.python.org (Carl Anderson)
Date: Mon, 22 Mar 2021 12:25:08 +0000
Subject: [issue43520] Make Fraction(string) handle non-ascii slashes
In-Reply-To: <1615918144.03.0.939769511159.issue43520@roundup.psfhosted.org>
Message-ID: <1616415908.24.0.607466173651.issue43520@roundup.psfhosted.org>


Carl Anderson <carl.anderson at ww.com> added the comment:

>Carl: can you say more about the problem that motivated this issue?

@mark.dickinson

I was parsing a large corpus of ingredients strings from web-scraped recipes. My code to interpret strings such as "1/2 cup sugar" would fall over every so often due to this issue as they used fraction slash and other visually similar characters

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43520>
_______________________________________

From report at bugs.python.org  Mon Mar 22 09:05:26 2021
From: report at bugs.python.org (junyixie)
Date: Mon, 22 Mar 2021 13:05:26 +0000
Subject: [issue43588] [Subinterpreters]: use static variable under building
 Python with --with-experimental-isolated-subinterpreters cause crash.
In-Reply-To: <1616400572.08.0.67077600893.issue43588@roundup.psfhosted.org>
Message-ID: <1616418326.33.0.952714144336.issue43588@roundup.psfhosted.org>


Change by junyixie <xie.junyi at outlook.com>:


----------
pull_requests: +23727
pull_request: https://github.com/python/cpython/pull/24968

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43588>
_______________________________________

From report at bugs.python.org  Mon Mar 22 09:16:40 2021
From: report at bugs.python.org (junyixie)
Date: Mon, 22 Mar 2021 13:16:40 +0000
Subject: [issue43588] [Subinterpreters]: use static variable under building
 Python with --with-experimental-isolated-subinterpreters cause crash.
In-Reply-To: <1616400572.08.0.67077600893.issue43588@roundup.psfhosted.org>
Message-ID: <1616419000.67.0.402462943212.issue43588@roundup.psfhosted.org>


junyixie <xie.junyi at outlook.com> added the comment:

-> Okay, I will fix these problems first. (Need for my own project)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43588>
_______________________________________

From report at bugs.python.org  Mon Mar 22 09:16:22 2021
From: report at bugs.python.org (junyixie)
Date: Mon, 22 Mar 2021 13:16:22 +0000
Subject: [issue43588] [Subinterpreters]: use static variable under building
 Python with --with-experimental-isolated-subinterpreters cause crash.
In-Reply-To: <1616400572.08.0.67077600893.issue43588@roundup.psfhosted.org>
Message-ID: <1616418982.93.0.0631020019706.issue43588@roundup.psfhosted.org>


junyixie <xie.junyi at outlook.com> added the comment:

Okay, I will fix these problems first. (Need for your own project)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43588>
_______________________________________

From report at bugs.python.org  Mon Mar 22 09:19:42 2021
From: report at bugs.python.org (junyixie)
Date: Mon, 22 Mar 2021 13:19:42 +0000
Subject: [issue43588] [Subinterpreters]: use static variable under building
 Python with --with-experimental-isolated-subinterpreters cause crash.
In-Reply-To: <1616400572.08.0.67077600893.issue43588@roundup.psfhosted.org>
Message-ID: <1616419182.32.0.476932933092.issue43588@roundup.psfhosted.org>


Change by junyixie <xie.junyi at outlook.com>:


----------
pull_requests: +23728
pull_request: https://github.com/python/cpython/pull/24969

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43588>
_______________________________________

From report at bugs.python.org  Mon Mar 22 09:29:47 2021
From: report at bugs.python.org (ggardet)
Date: Mon, 22 Mar 2021 13:29:47 +0000
Subject: [issue43593] pymalloc is not aware of Memory Tagging Extension (MTE)
 and crashes
Message-ID: <1616419787.13.0.506382582675.issue43593@roundup.psfhosted.org>


New submission from ggardet <guillaume.gardet at arm.com>:

When Memory Tagging Extension (MTE) [0] is enabled on aarch64, python malloc make programs to crash. 
I noticed it while trying to use GDB with MTE enabled in user-space [1], and gdb crashed on start-up. Rebuilding python (3.8) using '--without-pymalloc' option allows to workaround the problem. 
For glibc, you need version 2.33 or later and build glibc with '--enable-memory-tagging' option. I guess that patches similar to glibc's patches are required for pymalloc.

[0]: https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/enhancing-memory-safety
[1]: https://en.opensuse.org/ARM_architecture_support#User-space_support

----------
components: Library (Lib)
messages: 389312
nosy: ggardet
priority: normal
severity: normal
status: open
title: pymalloc is not aware of Memory Tagging Extension (MTE) and crashes
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43593>
_______________________________________

From report at bugs.python.org  Mon Mar 22 09:39:46 2021
From: report at bugs.python.org (ggardet)
Date: Mon, 22 Mar 2021 13:39:46 +0000
Subject: [issue43593] pymalloc is not aware of Memory Tagging Extension (MTE)
 and crashes
In-Reply-To: <1616419787.13.0.506382582675.issue43593@roundup.psfhosted.org>
Message-ID: <1616420386.91.0.104834678426.issue43593@roundup.psfhosted.org>


ggardet <guillaume.gardet at arm.com> added the comment:

Is there any runtime option (env variable or something else) to use glibc malloc instead of pymalloc? Or the choice made at compile time is immutable?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43593>
_______________________________________

From report at bugs.python.org  Mon Mar 22 09:41:57 2021
From: report at bugs.python.org (junyixie)
Date: Mon, 22 Mar 2021 13:41:57 +0000
Subject: [issue43588] [Subinterpreters]: use static variable under building
 Python with --with-experimental-isolated-subinterpreters cause crash.
In-Reply-To: <1616400572.08.0.67077600893.issue43588@roundup.psfhosted.org>
Message-ID: <1616420517.97.0.813922760035.issue43588@roundup.psfhosted.org>


Change by junyixie <xie.junyi at outlook.com>:


----------
pull_requests: +23729
pull_request: https://github.com/python/cpython/pull/24970

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43588>
_______________________________________

From report at bugs.python.org  Mon Mar 22 09:42:00 2021
From: report at bugs.python.org (Erez Zinman)
Date: Mon, 22 Mar 2021 13:42:00 +0000
Subject: [issue43594] A metaclass that inherits both `ABC` and `ABCMeta`
 breaks on `__subclasscheck__`
Message-ID: <1616420520.96.0.331295909751.issue43594@roundup.psfhosted.org>


New submission from Erez Zinman <erezinman.programmer at gmail.com>:

Consider the following example:

```
from abc import ABCMeta, ABC

class MetaclassMixin(ABC):
    pass 

class Meta(MetaclassMixin, ABCMeta):
    pass

class A(metaclass=Meta):
    pass

```

Then the call `isinstance(A, Meta)` returns `True` but `isinstance(1, Meta)` raises 

 >>> TypeError: __subclasscheck__() missing 1 required positional argument: 'subclass'

Checked on 3.6.9, 3.8.0 & 3.8.8

----------
components: Library (Lib)
messages: 389314
nosy: erezinman
priority: normal
severity: normal
status: open
title: A metaclass that inherits both `ABC`  and `ABCMeta` breaks on `__subclasscheck__`
versions: Python 3.6, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43594>
_______________________________________

From report at bugs.python.org  Mon Mar 22 09:45:46 2021
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 22 Mar 2021 13:45:46 +0000
Subject: [issue43593] pymalloc is not aware of Memory Tagging Extension (MTE)
 and crashes
In-Reply-To: <1616419787.13.0.506382582675.issue43593@roundup.psfhosted.org>
Message-ID: <1616420746.05.0.97063236168.issue43593@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

pymalloc is a compile-time option. The configure flag sets or unsets WITH_PYMALLOC. The define is then used by https://github.com/python/cpython/blob/master/Objects/obmalloc.c to change the internal allocator.

The flag may also affect the ABI of Python and affect binary wheels. It might break compatibility with manylinux wheels for aarch64.

Victor, please take a look.

----------
nosy: +christian.heimes, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43593>
_______________________________________

From report at bugs.python.org  Mon Mar 22 09:49:02 2021
From: report at bugs.python.org (Jeremy Kloth)
Date: Mon, 22 Mar 2021 13:49:02 +0000
Subject: [issue43538] [Windows] support args and cwd in os.startfile()
In-Reply-To: <1616052233.51.0.171946221972.issue43538@roundup.psfhosted.org>
Message-ID: <1616420942.4.0.328955749682.issue43538@roundup.psfhosted.org>


Change by Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com>:


----------
nosy: +jkloth

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43538>
_______________________________________

From report at bugs.python.org  Mon Mar 22 09:53:36 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Mar 2021 13:53:36 +0000
Subject: [issue43593] pymalloc is not aware of Memory Tagging Extension (MTE)
 and crashes
In-Reply-To: <1616419787.13.0.506382582675.issue43593@roundup.psfhosted.org>
Message-ID: <1616421216.64.0.108061697915.issue43593@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> When Memory Tagging Extension (MTE) [0] is enabled on aarch64, python malloc make programs to crash. 

Would you mind to elaborate what does crash exactly?

Can you please test if https://github.com/python/cpython/pull/14474 fix your issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43593>
_______________________________________

From report at bugs.python.org  Mon Mar 22 09:53:50 2021
From: report at bugs.python.org (Erez Zinman)
Date: Mon, 22 Mar 2021 13:53:50 +0000
Subject: [issue43595] Can not add a metclass that inherits both ABCMeta & ABC
 to a Union
Message-ID: <1616421230.45.0.492887326456.issue43595@roundup.psfhosted.org>


New submission from Erez Zinman <erezinman.programmer at gmail.com>:

Related to Issue #43594.

When running the following code

```
from abc import ABCMeta, ABC
from typing import Union

class MetaclassMixin(ABC):
    pass 

class Meta(MetaclassMixin, ABCMeta):
    pass

print(Union[str, Meta])
```

An exception is raised

 >>> TypeError: descriptor '__subclasses__' of 'type' object needs an argument


Tested on v3.6.9

----------
messages: 389317
nosy: erezinman
priority: normal
severity: normal
status: open
title: Can not add a metclass that inherits both ABCMeta & ABC to a Union
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43595>
_______________________________________

From report at bugs.python.org  Mon Mar 22 09:54:34 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Mar 2021 13:54:34 +0000
Subject: [issue43593] pymalloc is not aware of Memory Tagging Extension (MTE)
 and crashes
In-Reply-To: <1616419787.13.0.506382582675.issue43593@roundup.psfhosted.org>
Message-ID: <1616421274.64.0.298140525033.issue43593@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

A workaround is to disable pymalloc at runtime using PYTHONMALLOC=malloc environment variable. But it makes Python 10-20% slower.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43593>
_______________________________________

From report at bugs.python.org  Mon Mar 22 10:05:55 2021
From: report at bugs.python.org (junyixie)
Date: Mon, 22 Mar 2021 14:05:55 +0000
Subject: [issue43558] The dataclasses documentation should mention how to call
 super().__init__
In-Reply-To: <1616165238.01.0.0594716110393.issue43558@roundup.psfhosted.org>
Message-ID: <1616421955.7.0.494999858252.issue43558@roundup.psfhosted.org>


Change by junyixie <xie.junyi at outlook.com>:


----------
keywords: +patch
nosy: +JunyiXie
nosy_count: 1.0 -> 2.0
pull_requests: +23730
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/24971

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43558>
_______________________________________

From report at bugs.python.org  Mon Mar 22 10:10:36 2021
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Blondon?=)
Date: Mon, 22 Mar 2021 14:10:36 +0000
Subject: [issue42914] pprint numbers with underscore
In-Reply-To: <1610493681.29.0.683565759752.issue42914@roundup.psfhosted.org>
Message-ID: <1616422236.04.0.729832523378.issue42914@roundup.psfhosted.org>


St?phane Blondon <stephane.blondon at gmail.com> added the comment:

I changed the default to be backward compatible (so underscore_numbers=False).

I think it would be better with underscore_numbers enabled by default but I understand the need for stability. Perhaps such break could be done in the future (in version 3.12 or v.4)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42914>
_______________________________________

From report at bugs.python.org  Mon Mar 22 10:14:35 2021
From: report at bugs.python.org (Erez Zinman)
Date: Mon, 22 Mar 2021 14:14:35 +0000
Subject: [issue43595] Can not add a metclass that inherits both ABCMeta & ABC
 to a Union
In-Reply-To: <1616421230.45.0.492887326456.issue43595@roundup.psfhosted.org>
Message-ID: <1616422475.21.0.567999561156.issue43595@roundup.psfhosted.org>


Erez Zinman <erezinman.programmer at gmail.com> added the comment:

This is actually a lot worse and unrelated to the aforementioned issue.

The code 

```
from typing import Union
from abc import ABC


Union[str, ABC]
```

raises the exception

 >>> TypeError: descriptor '__subclasses__' of 'type' object needs an argument

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43595>
_______________________________________

From report at bugs.python.org  Mon Mar 22 10:17:28 2021
From: report at bugs.python.org (Assaf)
Date: Mon, 22 Mar 2021 14:17:28 +0000
Subject: [issue38905] venv python reports wrong sys.executable in a subprocess
 on Windows
In-Reply-To: <1574583460.3.0.94905817038.issue38905@roundup.psfhosted.org>
Message-ID: <1616422648.48.0.333595925541.issue38905@roundup.psfhosted.org>


Assaf <awaizman at gmail.com> added the comment:

The fact that now there is a redirector process seems to me like a regression issue.
I have an application which Popen several processes and uses the Popen object in order to get the subprocesses pids and act upon this pids (i.e. looks for log files with associated pid).

Now this breaks because the subprocess pid is the one of the redirector and not the actual one.

This is similar to 'Ray' issue mentioned earlier.

----------
nosy: +awaizman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38905>
_______________________________________

From report at bugs.python.org  Mon Mar 22 10:17:25 2021
From: report at bugs.python.org (junyixie)
Date: Mon, 22 Mar 2021 14:17:25 +0000
Subject: [issue43558] The dataclasses documentation should mention how to call
 super().__init__
In-Reply-To: <1616165238.01.0.0594716110393.issue43558@roundup.psfhosted.org>
Message-ID: <1616422645.28.0.441553148085.issue43558@roundup.psfhosted.org>


Change by junyixie <xie.junyi at outlook.com>:


----------
pull_requests: +23731
pull_request: https://github.com/python/cpython/pull/24972

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43558>
_______________________________________

From report at bugs.python.org  Mon Mar 22 10:18:16 2021
From: report at bugs.python.org (junyixie)
Date: Mon, 22 Mar 2021 14:18:16 +0000
Subject: [issue43588] [Subinterpreters]: use static variable under building
 Python with --with-experimental-isolated-subinterpreters cause crash.
In-Reply-To: <1616400572.08.0.67077600893.issue43588@roundup.psfhosted.org>
Message-ID: <1616422696.58.0.0198604638579.issue43588@roundup.psfhosted.org>


junyixie <xie.junyi at outlook.com> added the comment:

I will fix the static variable problem of frequently used code

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43588>
_______________________________________

From report at bugs.python.org  Mon Mar 22 10:25:54 2021
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 22 Mar 2021 14:25:54 +0000
Subject: [issue43588] [Subinterpreters]: use static variable under building
 Python with --with-experimental-isolated-subinterpreters cause crash.
In-Reply-To: <1616400572.08.0.67077600893.issue43588@roundup.psfhosted.org>
Message-ID: <1616423154.56.0.874743610463.issue43588@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:

@JunyiXie

Please wait your patch until the PEP is approved.

----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43588>
_______________________________________

From report at bugs.python.org  Mon Mar 22 10:33:57 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Mar 2021 14:33:57 +0000
Subject: [issue43588] [Subinterpreters]: use static variable under building
 Python with --with-experimental-isolated-subinterpreters cause crash.
In-Reply-To: <1616400572.08.0.67077600893.issue43588@roundup.psfhosted.org>
Message-ID: <1616423637.47.0.877779323712.issue43588@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Until the PEP is accepted, you can start working on a branch if you want. You can post the link to your branch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43588>
_______________________________________

From report at bugs.python.org  Mon Mar 22 11:24:16 2021
From: report at bugs.python.org (Ned Deily)
Date: Mon, 22 Mar 2021 15:24:16 +0000
Subject: [issue43590] Collapse sidebar issue on https://docs.python.org/3/
In-Reply-To: <1616408725.68.0.0305800294993.issue43590@roundup.psfhosted.org>
Message-ID: <1616426656.09.0.25608200908.issue43590@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
type: behavior -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43590>
_______________________________________

From report at bugs.python.org  Mon Mar 22 11:41:11 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 22 Mar 2021 15:41:11 +0000
Subject: [issue43591] Parser aborts on incomplete/incorrect unicode literals
 in interactive mode
In-Reply-To: <1616408746.94.0.619968687767.issue43591@roundup.psfhosted.org>
Message-ID: <1616427671.47.0.86648119429.issue43591@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +23732
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24973

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43591>
_______________________________________

From report at bugs.python.org  Mon Mar 22 11:41:56 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 22 Mar 2021 15:41:56 +0000
Subject: [issue43591] Parser aborts on incomplete/incorrect unicode literals
 in interactive mode
In-Reply-To: <1616408746.94.0.619968687767.issue43591@roundup.psfhosted.org>
Message-ID: <1616427716.55.0.522531642028.issue43591@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Thanks for the report and the patch Erlend!. I have transformed it into a PR with attribution in PR 24973

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43591>
_______________________________________

From report at bugs.python.org  Mon Mar 22 11:47:35 2021
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 22 Mar 2021 15:47:35 +0000
Subject: [issue43573] [types] Document __spec__ for types.ModuleType
In-Reply-To: <1616289204.63.0.465511334804.issue43573@roundup.psfhosted.org>
Message-ID: <1616428055.45.0.344103782612.issue43573@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
keywords: +patch
pull_requests: +23733
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24974

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43573>
_______________________________________

From report at bugs.python.org  Mon Mar 22 11:49:40 2021
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 22 Mar 2021 15:49:40 +0000
Subject: [issue43573] [types] Document __spec__ for types.ModuleType
In-Reply-To: <1616289204.63.0.465511334804.issue43573@roundup.psfhosted.org>
Message-ID: <1616428180.84.0.725485758156.issue43573@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
assignee: docs at python -> brett.cannon
stage: patch review -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43573>
_______________________________________

From report at bugs.python.org  Mon Mar 22 11:50:21 2021
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 22 Mar 2021 15:50:21 +0000
Subject: [issue42137] Prefer using __spec__ over module_repr() for
 ModuleType.__repr__
In-Reply-To: <1603495255.51.0.316157271396.issue42137@roundup.psfhosted.org>
Message-ID: <1616428221.84.0.572432044618.issue42137@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Meant to say, "existence of the _method_ isn't problematic".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42137>
_______________________________________

From report at bugs.python.org  Mon Mar 22 12:00:51 2021
From: report at bugs.python.org (Irit Katriel)
Date: Mon, 22 Mar 2021 16:00:51 +0000
Subject: [issue24147] Dialect class defaults are not documented.
In-Reply-To: <1431133519.25.0.806037285537.issue24147@psf.upfronthosting.co.za>
Message-ID: <1616428851.61.0.0127659013339.issue24147@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

Brandon's patch has not been applied, it needs to be converted into a git PR.

----------
keywords: +easy -patch
nosy: +iritkatriel
versions: +Python 3.10 -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24147>
_______________________________________

From report at bugs.python.org  Mon Mar 22 12:15:07 2021
From: report at bugs.python.org (Irit Katriel)
Date: Mon, 22 Mar 2021 16:15:07 +0000
Subject: [issue12762] OSError msg should display symbolic error codes
In-Reply-To: <1313514546.35.0.211291095895.issue12762@psf.upfronthosting.co.za>
Message-ID: <1616429707.94.0.630731082058.issue12762@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
title: EnvironmentError_str contributes to unportable code -> OSError msg should display symbolic error codes
versions: +Python 3.10 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12762>
_______________________________________

From report at bugs.python.org  Mon Mar 22 12:16:06 2021
From: report at bugs.python.org (R. Samuel Klatchko)
Date: Mon, 22 Mar 2021 16:16:06 +0000
Subject: [issue43596] change assertRaises message when wrong exception is
 raised
Message-ID: <1616429766.92.0.297524624601.issue43596@roundup.psfhosted.org>


New submission from R. Samuel Klatchko <rsk at google.com>:

Right now, this code:

    class FooError(Exception): pass
    class BarError(Exception): pass

    def test_me(self):
      with self.assertRaises(FooError):
        raise BarError("something")

will have the error "BarError: something" with no indication that an exception was expected but just that we got the wrong one.

It would be help to change the message to something like:

  Expected exception of type FooError but exception BarError('something') was raised.

----------
messages: 389328
nosy: rsk2
priority: normal
severity: normal
status: open
title: change assertRaises message when wrong exception is raised

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43596>
_______________________________________

From report at bugs.python.org  Mon Mar 22 12:17:48 2021
From: report at bugs.python.org (Nathaniel Manista)
Date: Mon, 22 Mar 2021 16:17:48 +0000
Subject: [issue43596] change assertRaises message when wrong exception is
 raised
In-Reply-To: <1616429766.92.0.297524624601.issue43596@roundup.psfhosted.org>
Message-ID: <1616429868.98.0.984770965332.issue43596@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/issue43596>
_______________________________________

From report at bugs.python.org  Mon Mar 22 12:24:51 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 22 Mar 2021 16:24:51 +0000
Subject: [issue43591] Parser aborts on incomplete/incorrect unicode literals
 in interactive mode
In-Reply-To: <1616408746.94.0.619968687767.issue43591@roundup.psfhosted.org>
Message-ID: <1616430291.87.0.828871390288.issue43591@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/issue43591>
_______________________________________

From report at bugs.python.org  Mon Mar 22 12:24:56 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 22 Mar 2021 16:24:56 +0000
Subject: [issue43591] Parser aborts on incomplete/incorrect unicode literals
 in interactive mode
In-Reply-To: <1616408746.94.0.619968687767.issue43591@roundup.psfhosted.org>
Message-ID: <1616430296.77.0.218225392655.issue43591@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 123ff266cda9ad279106f20dca06ba114f6a9b8a by Pablo Galindo in branch 'master':
bpo-43591: Fix error location in interactive mode for errors at the end of the line (GH-24973)
https://github.com/python/cpython/commit/123ff266cda9ad279106f20dca06ba114f6a9b8a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43591>
_______________________________________

From report at bugs.python.org  Mon Mar 22 12:28:50 2021
From: report at bugs.python.org (Irit Katriel)
Date: Mon, 22 Mar 2021 16:28:50 +0000
Subject: [issue26403] Catch FileNotFoundError in
 socketserver.DatagramRequestHandler
In-Reply-To: <1456082925.77.0.767922099224.issue26403@psf.upfronthosting.co.za>
Message-ID: <1616430530.85.0.902595415815.issue26403@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
versions: +Python 3.10 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26403>
_______________________________________

From report at bugs.python.org  Mon Mar 22 12:35:26 2021
From: report at bugs.python.org (Zackery Spytz)
Date: Mon, 22 Mar 2021 16:35:26 +0000
Subject: [issue12762] OSError msg should display symbolic error codes
In-Reply-To: <1313514546.35.0.211291095895.issue12762@psf.upfronthosting.co.za>
Message-ID: <1616430926.4.0.852577329925.issue12762@roundup.psfhosted.org>


Zackery Spytz <zspytz at gmail.com> added the comment:

This is a duplicate of bpo-2920 (which has a PR).

----------
nosy: +ZackerySpytz
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> Patch to print symbolic value of errno in OSError.__str__()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12762>
_______________________________________

From report at bugs.python.org  Mon Mar 22 12:37:47 2021
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 22 Mar 2021 16:37:47 +0000
Subject: [issue43596] change assertRaises message when wrong exception is
 raised
In-Reply-To: <1616429766.92.0.297524624601.issue43596@roundup.psfhosted.org>
Message-ID: <1616431067.87.0.775337823589.issue43596@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/issue43596>
_______________________________________

From report at bugs.python.org  Mon Mar 22 12:47:15 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Mar 2021 16:47:15 +0000
Subject: =?utf-8?q?=5Bissue43181=5D_Python_macros_don=E2=80=99t_shield_arguments?=
In-Reply-To: <1612908350.59.0.954965139249.issue43181@roundup.psfhosted.org>
Message-ID: <1616431635.49.0.110235354328.issue43181@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Me:
> I don't think that PR 24533 should be backported to Python 3.8 and Python 3.9. I prefer to avoid any risk of regression, and so only change Python 3.10.

Sometimes. I'm wise :-D This change broken 2 extension modules which rely on the fact that the macro magically add parenthesis:

python-cvxopt: "if Matrix_Check((PyObject *)val)" with: "#define Matrix_Check(self) PyObject_TypeCheck(self, &matrix_tp)"
https://bugzilla.redhat.com/show_bug.cgi?id=1941557
PR proposed: https://github.com/cvxopt/cvxopt/pull/190

python-Bottleneck: "if PyArray_Check(a_obj) {" with: "#define PyArray_Check(op) PyObject_TypeCheck(op, &PyArray_Type)"
https://bugzilla.redhat.com/show_bug.cgi?id=1941559

"if func(...) {" is not valid C code, but the old macro added magically parenthesis!

It's hard to say if the Python change is a backward incompatible or not... I prefer to keep it and fix the few broken C extensions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43181>
_______________________________________

From report at bugs.python.org  Mon Mar 22 12:59:15 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 22 Mar 2021 16:59:15 +0000
Subject: [issue43563] Use dedicated opcodes to speed up calls/attribute
 lookups with super() as receiver
In-Reply-To: <1616187477.95.0.162642980766.issue43563@roundup.psfhosted.org>
Message-ID: <1616432355.29.0.649597500497.issue43563@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/issue43563>
_______________________________________

From report at bugs.python.org  Mon Mar 22 13:09:32 2021
From: report at bugs.python.org (Dennis Sweeney)
Date: Mon, 22 Mar 2021 17:09:32 +0000
Subject: [issue43010] @functools.wraps and abc.abstractmethod interoperability
In-Reply-To: <1611411971.69.0.738980453065.issue43010@roundup.psfhosted.org>
Message-ID: <1616432972.74.0.660642078637.issue43010@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

> other attributes will not be copied

The signature of wraps() is

    wraps(wrapped, assigned=('__module__', '__name__', '__qualname__', '__doc__', '__annotations__'), updated=('__dict__',))

Passing the updated=() will prevent the __dict__ from being updated, but those other attributes will still be assigned to:

    >>> from functools import wraps
    >>> def f(x: int) -> int:
    ...     "Square of a number"
    ...     return x ** 2
    ...
    >>> @wraps(f, updated=())
    ... def g(*args, **kwargs):
    ...     return f(*args, **kwargs)
    ...
    >>> help(g)
    Help on function f in module __main__:
    
    f(x: int) -> int
        Square of a number

> This is an interoperability bug

This is probably somewhat subjective, but I think the current behavior is okay: copy all of the attributes of the wrapped function into the wrapper. That's predictable, well-specified behavior, even if it has unexpected consequences in some situations -- I would say unusual situations, since 90% of the time I've seen @wraps used is in making custom decorators, where you really do mean to copy *all* of the attributes of the old function into the new one, and never think of the wrapped function again.

My thinking is also that to add a special case for abstract methods in functools would be to unnecessarily couple the functools module to implementation details of the ABC module. If someone using the ABC module wants to not update the __dict__ when using functools.wraps, there's already an easy switch for that, and it's completely orthogonal to what the __dict__ contains.

For an interesting precedent, @abstractclassmethod was created in https://bugs.python.org/issue5867 to solve a similar (I think) interoperability problem between @abstractmethod and @classmethod rather than adding a special case to @classmethod.

I would be interested in hearing if others want something to change about wraps().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43010>
_______________________________________

From report at bugs.python.org  Mon Mar 22 13:28:22 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 22 Mar 2021 17:28:22 +0000
Subject: [issue43555] Location of SyntaxError with new parser missing (after
 continuation character)
In-Reply-To: <1616152732.25.0.508578313833.issue43555@roundup.psfhosted.org>
Message-ID: <1616434102.66.0.469061638563.issue43555@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 96eeff516204b7cc751103fa33dcc665e387846e by Pablo Galindo in branch 'master':
bpo-43555: Report the column offset for invalid line continuation character (GH-24939)
https://github.com/python/cpython/commit/96eeff516204b7cc751103fa33dcc665e387846e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43555>
_______________________________________

From report at bugs.python.org  Mon Mar 22 13:28:59 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 22 Mar 2021 17:28:59 +0000
Subject: [issue43555] Location of SyntaxError with new parser missing (after
 continuation character)
In-Reply-To: <1616152732.25.0.508578313833.issue43555@roundup.psfhosted.org>
Message-ID: <1616434139.18.0.861737495023.issue43555@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: +23734
pull_request: https://github.com/python/cpython/pull/24975

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43555>
_______________________________________

From report at bugs.python.org  Mon Mar 22 13:48:29 2021
From: report at bugs.python.org (Irit Katriel)
Date: Mon, 22 Mar 2021 17:48:29 +0000
Subject: [issue17792] Unhelpful UnboundLocalError due to del'ing of exception
 target
In-Reply-To: <1366329322.51.0.489771554551.issue17792@psf.upfronthosting.co.za>
Message-ID: <1616435309.79.0.181478889572.issue17792@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
pull_requests: +23735
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24976

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17792>
_______________________________________

From report at bugs.python.org  Mon Mar 22 13:49:15 2021
From: report at bugs.python.org (Gabriel Amine Eddine)
Date: Mon, 22 Mar 2021 17:49:15 +0000
Subject: [issue15751] [subinterpreters] Make the PyGILState API compatible
 with subinterpreters
In-Reply-To: <1345526301.75.0.455071650321.issue15751@psf.upfronthosting.co.za>
Message-ID: <1616435355.84.0.608819794647.issue15751@roundup.psfhosted.org>


Change by Gabriel Amine Eddine <gabrielhae at gmail.com>:


----------
nosy: +gabrielhae

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15751>
_______________________________________

From report at bugs.python.org  Mon Mar 22 13:53:20 2021
From: report at bugs.python.org (Zackery Spytz)
Date: Mon, 22 Mar 2021 17:53:20 +0000
Subject: [issue42444] pathlib.PurePath properties annotated with .. data
 directive
In-Reply-To: <1606147111.69.0.159922070788.issue42444@roundup.psfhosted.org>
Message-ID: <1616435600.19.0.613944801654.issue42444@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 6.0 -> 7.0
pull_requests: +23736
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24977

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42444>
_______________________________________

From report at bugs.python.org  Mon Mar 22 14:14:29 2021
From: report at bugs.python.org (Ned Deily)
Date: Mon, 22 Mar 2021 18:14:29 +0000
Subject: [issue43592] test_importlib:
 test_multiprocessing_pool_circular_import() fails with "Too many open files"
 error on os.pipe()
In-Reply-To: <1616409182.92.0.0882668450853.issue43592@roundup.psfhosted.org>
Message-ID: <1616436869.8.0.416211952625.issue43592@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

FWIW, I don't recall ever seeing a "too many open files" failure for test_importlib on any of my macOS systems.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43592>
_______________________________________

From report at bugs.python.org  Mon Mar 22 15:07:16 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 22 Mar 2021 19:07:16 +0000
Subject: [issue43555] Location of SyntaxError with new parser missing (after
 continuation character)
In-Reply-To: <1616152732.25.0.508578313833.issue43555@roundup.psfhosted.org>
Message-ID: <1616440036.46.0.0488697329917.issue43555@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 994a519915bff4901abaa7476e2b91682dea619a by Miss Islington (bot) in branch '3.9':
bpo-43555: Report the column offset for invalid line continuation character (GH-24939) (#24975)
https://github.com/python/cpython/commit/994a519915bff4901abaa7476e2b91682dea619a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43555>
_______________________________________

From report at bugs.python.org  Mon Mar 22 15:07:24 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 22 Mar 2021 19:07:24 +0000
Subject: [issue43555] Location of SyntaxError with new parser missing (after
 continuation character)
In-Reply-To: <1616152732.25.0.508578313833.issue43555@roundup.psfhosted.org>
Message-ID: <1616440044.45.0.62647383296.issue43555@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/issue43555>
_______________________________________

From report at bugs.python.org  Mon Mar 22 15:20:55 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 22 Mar 2021 19:20:55 +0000
Subject: [issue43591] Parser aborts on incomplete/incorrect unicode literals
 in interactive mode
In-Reply-To: <1616408746.94.0.619968687767.issue43591@roundup.psfhosted.org>
Message-ID: <1616440855.3.0.794892427526.issue43591@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

Thanks, Pablo!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43591>
_______________________________________

From report at bugs.python.org  Mon Mar 22 15:26:00 2021
From: report at bugs.python.org (Vladimir Matveev)
Date: Mon, 22 Mar 2021 19:26:00 +0000
Subject: [issue43563] Use dedicated opcodes to speed up calls/attribute
 lookups with super() as receiver
In-Reply-To: <1616187477.95.0.162642980766.issue43563@roundup.psfhosted.org>
Message-ID: <1616441160.53.0.882324988953.issue43563@roundup.psfhosted.org>


Vladimir Matveev <desco.by at gmail.com> added the comment:

>Currently, super() is decoupled from the core language.  It is just a builtin that provides customized attribute lookup.  This PR makes super() more tightly integrated with the core language, treating it as if it were a keyword and part of the grammar.  Also note, users can currently create their own versions of super(), shadowing the builtin super().

This is true however:
- this patch does not block people from introducing custom version of `super` so this scenario still work. The idea was to streamline the common case
- based on digging into Instagram codebase and its transitive dependencies (which is reasonably large amount of code) all spots where `super()` appear in sources assume `super` to be builtin and for a pretty common use-case its cost is noticeable in profiler.
- zero-argument `super()` still a bit magical since it requires compiler support to create cell for `__class__` and assumes certain shape of the frame object so this patch is a step forward with a better compiler support and removing runtime dependency on the frame

> Do you have any evidence that the overhead of super() is significant in real programs

I do see the non-negligible cost of allocation/initialization of `super` object in IG profiling data.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43563>
_______________________________________

From report at bugs.python.org  Mon Mar 22 15:43:06 2021
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 22 Mar 2021 19:43:06 +0000
Subject: [issue2920] Patch to print symbolic value of errno in
 OSError.__str__()
In-Reply-To: <1211228076.96.0.534347381118.issue2920@psf.upfronthosting.co.za>
Message-ID: <1616442186.92.0.53331693258.issue2920@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
versions: +Python 3.10 -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2920>
_______________________________________

From report at bugs.python.org  Mon Mar 22 16:13:07 2021
From: report at bugs.python.org (Felix C. Stegerman)
Date: Mon, 22 Mar 2021 20:13:07 +0000
Subject: [issue43547] support ZIP files with zeroed out fields (e.g. for
 reproducible builds)
In-Reply-To: <1616102738.26.0.451702371832.issue43547@roundup.psfhosted.org>
Message-ID: <1616443987.97.0.118124412155.issue43547@roundup.psfhosted.org>


Change by Felix C. Stegerman <flx at obfusk.net>:


----------
keywords: +patch
pull_requests: +23737
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24979

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43547>
_______________________________________

From report at bugs.python.org  Mon Mar 22 16:20:47 2021
From: report at bugs.python.org (Felix C. Stegerman)
Date: Mon, 22 Mar 2021 20:20:47 +0000
Subject: [issue43547] support ZIP files with zeroed out fields (e.g. for
 reproducible builds)
In-Reply-To: <1616102738.26.0.451702371832.issue43547@roundup.psfhosted.org>
Message-ID: <1616444447.38.0.379084897851.issue43547@roundup.psfhosted.org>


Felix C. Stegerman <flx at obfusk.net> added the comment:

I've created a draft PR; RFC :)

Also:

* setting the date to (1980,0,0,0,0,0) already works;
* the main issue seems to be that external_attr cannot be 0 atm.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43547>
_______________________________________

From report at bugs.python.org  Mon Mar 22 16:31:03 2021
From: report at bugs.python.org (junyixie)
Date: Mon, 22 Mar 2021 20:31:03 +0000
Subject: [issue43588] [Subinterpreters]: use static variable under building
 Python with --with-experimental-isolated-subinterpreters cause crash.
In-Reply-To: <1616400572.08.0.67077600893.issue43588@roundup.psfhosted.org>
Message-ID: <1616445063.9.0.691091413594.issue43588@roundup.psfhosted.org>


Change by junyixie <xie.junyi at outlook.com>:


----------
pull_requests: +23738
pull_request: https://github.com/python/cpython/pull/24971

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43588>
_______________________________________

From report at bugs.python.org  Mon Mar 22 16:31:42 2021
From: report at bugs.python.org (junyixie)
Date: Mon, 22 Mar 2021 20:31:42 +0000
Subject: [issue43588] [Subinterpreters]: use static variable under building
 Python with --with-experimental-isolated-subinterpreters cause crash.
In-Reply-To: <1616400572.08.0.67077600893.issue43588@roundup.psfhosted.org>
Message-ID: <1616445102.92.0.384093564578.issue43588@roundup.psfhosted.org>


Change by junyixie <xie.junyi at outlook.com>:


----------
pull_requests: +23739
pull_request: https://github.com/python/cpython/pull/24972

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43588>
_______________________________________

From report at bugs.python.org  Mon Mar 22 16:32:56 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 22 Mar 2021 20:32:56 +0000
Subject: [issue43558] The dataclasses documentation should mention how to call
 super().__init__
In-Reply-To: <1616165238.01.0.0594716110393.issue43558@roundup.psfhosted.org>
Message-ID: <1616445176.95.0.106248533206.issue43558@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
pull_requests:  -23730

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43558>
_______________________________________

From report at bugs.python.org  Mon Mar 22 16:33:03 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 22 Mar 2021 20:33:03 +0000
Subject: [issue43558] The dataclasses documentation should mention how to call
 super().__init__
In-Reply-To: <1616165238.01.0.0594716110393.issue43558@roundup.psfhosted.org>
Message-ID: <1616445183.55.0.741646008724.issue43558@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
pull_requests:  -23731

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43558>
_______________________________________

From report at bugs.python.org  Mon Mar 22 16:33:26 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 22 Mar 2021 20:33:26 +0000
Subject: [issue43558] The dataclasses documentation should mention how to call
 super().__init__
In-Reply-To: <1616165238.01.0.0594716110393.issue43558@roundup.psfhosted.org>
Message-ID: <1616445206.2.0.747500186011.issue43558@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
keywords: +easy -patch
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43558>
_______________________________________

From report at bugs.python.org  Mon Mar 22 16:44:28 2021
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 22 Mar 2021 20:44:28 +0000
Subject: [issue43547] support ZIP files with zeroed out fields (e.g. for
 reproducible builds)
In-Reply-To: <1616102738.26.0.451702371832.issue43547@roundup.psfhosted.org>
Message-ID: <1616445868.14.0.939293398227.issue43547@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Hi,

thanks for looking into reproducible builds. I have a few suggestions:

- since it's a new feature, it cannot go into older releases.
- zeroed is not a self-explanatory term. I suggest to find a term that does describe the result, not the internal operation.
- I don't think you have to introduce a new argument at all. Instead you can provide a new method that creates a carefully crafted zipinfo object that results into zeroed arguments. That's how I implemented reproducible tar.bz2 files.
- For full reproducible builds you may have to write files to zipfiles in a well-defined order.

----------
components:  -IO
nosy: +christian.heimes
type:  -> enhancement
versions:  -Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43547>
_______________________________________

From report at bugs.python.org  Mon Mar 22 16:49:58 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 22 Mar 2021 20:49:58 +0000
Subject: [issue43563] Use dedicated opcodes to speed up calls/attribute
 lookups with super() as receiver
In-Reply-To: <1616187477.95.0.162642980766.issue43563@roundup.psfhosted.org>
Message-ID: <1616446198.17.0.75955255624.issue43563@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

This looks like a sensible idea to me. The safeguards to ensure that customized 'super' still works seem reasonable to me. I have to admit that I sometimes refrain from using super() where I should because of the expense, so this would be welcome.

I do wonder -- is two-arg super() important enough to support it at all? Maybe the code would be somewhat simpler if the special opcodes were only generated for zero-arg super() calls.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43563>
_______________________________________

From report at bugs.python.org  Mon Mar 22 16:50:31 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 22 Mar 2021 20:50:31 +0000
Subject: [issue43492] Upgrade to SQLite 3.35.3 in macOS and Windows
In-Reply-To: <1615752732.27.0.278073347477.issue43492@roundup.psfhosted.org>
Message-ID: <1616446231.67.0.581392260376.issue43492@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

FYI: https://www.sqlite.org/cgi/src/info/8de4cb984a4b019f:

"We anticipate 3.35.3 in a few days. Hopefully there will never be a need for 3.35.4."

----------
title: Upgrade to SQLite 3.35.2 in macOS and Windows -> Upgrade to SQLite 3.35.3 in macOS and Windows

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43492>
_______________________________________

From report at bugs.python.org  Mon Mar 22 16:50:56 2021
From: report at bugs.python.org (Tim Peters)
Date: Mon, 22 Mar 2021 20:50:56 +0000
Subject: [issue43420] Optimize rational arithmetics
In-Reply-To: <1615040297.73.0.541090358152.issue43420@roundup.psfhosted.org>
Message-ID: <1616446256.32.0.0489135425536.issue43420@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

This report is closed. Please open a different report.

We've already demonstrated that, as predicted, nothing can be said here without it being taken as invitation to open-ended discussion. So it goes, but it doesn't belong on _this_ report anymore.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43420>
_______________________________________

From report at bugs.python.org  Mon Mar 22 16:58:58 2021
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 22 Mar 2021 20:58:58 +0000
Subject: [issue43547] support ZIP files with zeroed out fields (e.g. for
 reproducible builds)
In-Reply-To: <1616102738.26.0.451702371832.issue43547@roundup.psfhosted.org>
Message-ID: <1616446738.23.0.333275442828.issue43547@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

zinfo = zipfile.ZipInfo()
zinfo.date_time = (1980, 0, 0, 0, 0, 0)
zinfo.create_system = 0

external_attr == 0 may cause issues with permissions. I do something like this in my reproducible tarfile code:

if zinfo.isdir():
    # 0755 + MS-DOS directory flag
    zinfo.external_attr = 0o755 | 0x010
else:
    zinfo.external_attr = 0o644

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43547>
_______________________________________

From report at bugs.python.org  Mon Mar 22 17:27:59 2021
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 22 Mar 2021 21:27:59 +0000
Subject: [issue43563] Use dedicated opcodes to speed up calls/attribute
 lookups with super() as receiver
In-Reply-To: <1616187477.95.0.162642980766.issue43563@roundup.psfhosted.org>
Message-ID: <1616448479.43.0.598688691947.issue43563@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

Numbers please.

What is "non-negligible cost of allocation/initialization" mean as a fraction of runtime?
What sort of speed up are you seeing on whole programs?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43563>
_______________________________________

From report at bugs.python.org  Mon Mar 22 17:40:24 2021
From: report at bugs.python.org (Irit Katriel)
Date: Mon, 22 Mar 2021 21:40:24 +0000
Subject: [issue20692] Tutorial and  FAQ: how to call a method on an int
In-Reply-To: <1392850224.09.0.571764135364.issue20692@psf.upfronthosting.co.za>
Message-ID: <1616449224.78.0.760891305536.issue20692@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
keywords: +easy
versions: +Python 3.10 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20692>
_______________________________________

From report at bugs.python.org  Mon Mar 22 17:58:23 2021
From: report at bugs.python.org (Kamil Turek)
Date: Mon, 22 Mar 2021 21:58:23 +0000
Subject: [issue43594] A metaclass that inherits both `ABC` and `ABCMeta`
 breaks on `__subclasscheck__`
In-Reply-To: <1616420520.96.0.331295909751.issue43594@roundup.psfhosted.org>
Message-ID: <1616450303.69.0.284397864828.issue43594@roundup.psfhosted.org>


Change by Kamil Turek <kamil.turek at hotmail.com>:


----------
nosy: +kamilturek

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43594>
_______________________________________

From report at bugs.python.org  Mon Mar 22 18:07:20 2021
From: report at bugs.python.org (Kamil Turek)
Date: Mon, 22 Mar 2021 22:07:20 +0000
Subject: [issue43596] change assertRaises message when wrong exception is
 raised
In-Reply-To: <1616429766.92.0.297524624601.issue43596@roundup.psfhosted.org>
Message-ID: <1616450840.97.0.450205256569.issue43596@roundup.psfhosted.org>


Change by Kamil Turek <kamil.turek at hotmail.com>:


----------
nosy: +kamilturek

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43596>
_______________________________________

From report at bugs.python.org  Mon Mar 22 18:14:35 2021
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 22 Mar 2021 22:14:35 +0000
Subject: [issue38905] venv python reports wrong sys.executable in a subprocess
 on Windows
In-Reply-To: <1574583460.3.0.94905817038.issue38905@roundup.psfhosted.org>
Message-ID: <1616451275.07.0.568197800274.issue38905@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

In some cases, the problem can be worked around by setting the __PYVENV_LAUNCHER__ environment variable and executing the base executable. For example:

    import os
    import sys
    import subprocess

    def get_python_exe_env():
        if sys.executable == getattr(sys, '_base_executable', sys.executable):
            return sys.executable, None
        environ = os.environ.copy()
        environ['__PYVENV_LAUNCHER__'] = sys.executable
        return sys._base_executable, environ

    executable, environ = get_python_exe_env()
    p = subprocess.Popen([executable], env=environ)

---

As is, I don't know how to solve the problem in which an arbitrary application runs a script using the "python" launcher. Half of the problem could be solved. When the launcher creates the base Python process, it could set the parent via PROC_THREAD_ATTRIBUTE_PARENT_PROCESS [1], presuming it can open a handle for the parent application with PROCESS_CREATE_PROCESS access. However, this doesn't solve the problem from the application's perspective. It still gets the handle and process ID of the launcher.

If the purpose of using a launcher was only to allow an in-place upgrade of the base "python3x.dll", then an alternative design would be to set the __PYVENV_LAUNCHER__ environment variable, load the Python DLL from the pyvenv.cfg "home" directory, and call Py_Main(argc, argv). This would eliminate the parent<->child problem and the application directory (__APPDIR__) problem. 

However, naively implementing something like that cannot work for the store app distribution. "python3x.dll" in the app installation directory under "%ProgramFiles%\WindowsApps" only grants execute access to users that have the app's WIN://SYSAPPID identifier in their access token, which gets added by CreateProcessW() when the "python[3[.x]].exe" appexec link is executed. I'd have to experiment to see what works. Maybe "python.exe" in the virtual environment could be created as an appexec link to "venvlauncher.exe" in the app, which loads the DLL, etc.

---

[1] https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38905>
_______________________________________

From report at bugs.python.org  Mon Mar 22 18:50:36 2021
From: report at bugs.python.org (Irit Katriel)
Date: Mon, 22 Mar 2021 22:50:36 +0000
Subject: [issue39091] _PyErr_CreateException() must check that the result is
 an exception (CPython Segfault in 5 lines of code)
In-Reply-To: <1576694715.09.0.414064649134.issue39091@roundup.psfhosted.org>
Message-ID: <1616453436.12.0.347285647466.issue39091@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
versions: +Python 3.10 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39091>
_______________________________________

From report at bugs.python.org  Mon Mar 22 18:51:03 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 22 Mar 2021 22:51:03 +0000
Subject: [issue40813] Line number of SyntaxError
In-Reply-To: <1590746912.78.0.622485430276.issue40813@roundup.psfhosted.org>
Message-ID: <1616453463.56.0.0465447115548.issue40813@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Whatever the situation was last May, current 3.10 now results in a correct and improved traceback ending in

  File "F:\Python\a\tem4.py", line 2
    print("hello world"
         ^
SyntaxError: '(' was never closed

Same if \n or additional text is added to the file without closing ')'.

----------
nosy: +terry.reedy
resolution:  -> out of date
stage:  -> resolved
status: open -> closed
versions:  -Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40813>
_______________________________________

From report at bugs.python.org  Mon Mar 22 18:52:24 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Mar 2021 22:52:24 +0000
Subject: [issue41718] test.regrtest has way too many imports
In-Reply-To: <1599233772.93.0.299899979889.issue41718@roundup.psfhosted.org>
Message-ID: <1616453544.29.0.0178312033721.issue41718@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 532e063fc2bf9e6e80550670ddc5dc5d2b1d2450 by Victor Stinner in branch 'master':
bpo-41718: regrtest saved_test_environment avoids imports (GH-24934)
https://github.com/python/cpython/commit/532e063fc2bf9e6e80550670ddc5dc5d2b1d2450


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41718>
_______________________________________

From report at bugs.python.org  Mon Mar 22 18:57:28 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Mar 2021 22:57:28 +0000
Subject: [issue41718] test.regrtest has way too many imports
In-Reply-To: <1599233772.93.0.299899979889.issue41718@roundup.psfhosted.org>
Message-ID: <1616453848.1.0.527554394565.issue41718@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +23740
pull_request: https://github.com/python/cpython/pull/24980

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41718>
_______________________________________

From report at bugs.python.org  Mon Mar 22 18:58:03 2021
From: report at bugs.python.org (Felix C. Stegerman)
Date: Mon, 22 Mar 2021 22:58:03 +0000
Subject: [issue43547] support ZIP files with zeroed out fields (e.g. for
 reproducible builds)
In-Reply-To: <1616102738.26.0.451702371832.issue43547@roundup.psfhosted.org>
Message-ID: <1616453883.44.0.37209372146.issue43547@roundup.psfhosted.org>


Felix C. Stegerman <flx at obfusk.net> added the comment:

I've closed the PR for now.

Using a carefully crafted ZipInfo object doesn't work because ZipFile modifies its .external_attr when set to 0.

Using something like this quickly hacked together ZipInfo subclass does work:

class ZeroedZipInfo(zipfile.ZipInfo):
    def __init__(self, zinfo):
        for k in self.__slots__:
            setattr(self, k, getattr(zinfo, k))

    def __getattribute__(self, name):
        if name == "date_time":
            return (1980,0,0,0,0,0)
        if name == "external_attr":
            return 0
        return object.__getattribute__(self, name)

...

myzipfile.writestr(ZeroedZipInfo(info), data)

----------
components: +IO
type: enhancement -> 
versions: +Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43547>
_______________________________________

From report at bugs.python.org  Mon Mar 22 18:58:57 2021
From: report at bugs.python.org (Felix C. Stegerman)
Date: Mon, 22 Mar 2021 22:58:57 +0000
Subject: [issue43547] support ZIP files with zeroed out fields (e.g. for
 reproducible builds)
In-Reply-To: <1616102738.26.0.451702371832.issue43547@roundup.psfhosted.org>
Message-ID: <1616453937.72.0.825539046492.issue43547@roundup.psfhosted.org>


Change by Felix C. Stegerman <flx at obfusk.net>:


----------
components:  -IO, Library (Lib)
versions:  -Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43547>
_______________________________________

From report at bugs.python.org  Mon Mar 22 18:59:15 2021
From: report at bugs.python.org (Felix C. Stegerman)
Date: Mon, 22 Mar 2021 22:59:15 +0000
Subject: [issue43547] support ZIP files with zeroed out fields (e.g. for
 reproducible builds)
In-Reply-To: <1616102738.26.0.451702371832.issue43547@roundup.psfhosted.org>
Message-ID: <1616453955.44.0.21864225737.issue43547@roundup.psfhosted.org>


Change by Felix C. Stegerman <flx at obfusk.net>:


----------
components: +Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43547>
_______________________________________

From report at bugs.python.org  Mon Mar 22 18:59:47 2021
From: report at bugs.python.org (Felix C. Stegerman)
Date: Mon, 22 Mar 2021 22:59:47 +0000
Subject: [issue43547] support ZIP files with zeroed out fields (e.g. for
 reproducible builds)
In-Reply-To: <1616102738.26.0.451702371832.issue43547@roundup.psfhosted.org>
Message-ID: <1616453987.43.0.987080398231.issue43547@roundup.psfhosted.org>


Change by Felix C. Stegerman <flx at obfusk.net>:


----------
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43547>
_______________________________________

From report at bugs.python.org  Mon Mar 22 19:01:10 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Mar 2021 23:01:10 +0000
Subject: [issue41718] test.regrtest has way too many imports
In-Reply-To: <1599233772.93.0.299899979889.issue41718@roundup.psfhosted.org>
Message-ID: <1616454070.13.0.94825282465.issue41718@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +23741
pull_request: https://github.com/python/cpython/pull/24981

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41718>
_______________________________________

From report at bugs.python.org  Mon Mar 22 19:05:05 2021
From: report at bugs.python.org (Felix C. Stegerman)
Date: Mon, 22 Mar 2021 23:05:05 +0000
Subject: [issue43547] support ZIP files with zeroed out fields (e.g. for
 reproducible builds)
In-Reply-To: <1616102738.26.0.451702371832.issue43547@roundup.psfhosted.org>
Message-ID: <1616454305.07.0.826653767239.issue43547@roundup.psfhosted.org>


Felix C. Stegerman <flx at obfusk.net> added the comment:

> external_attr == 0 may cause issues with permissions.

That may be true in some scenarios, but not being able to set it to 0 means you can't create identical files to those produced by other tools -- like those used to generate APKs -- which do in fact set it to 0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43547>
_______________________________________

From report at bugs.python.org  Mon Mar 22 19:08:07 2021
From: report at bugs.python.org (Tarun Chinmai Sekar)
Date: Mon, 22 Mar 2021 23:08:07 +0000
Subject: [issue43597] robotparser should support specifying SSL context
Message-ID: <1616454487.19.0.339190443454.issue43597@roundup.psfhosted.org>


Change by Tarun Chinmai Sekar  <tchinmai7 at gmail.com>:


----------
nosy: Tchinmai7
priority: normal
severity: normal
status: open
title: robotparser should support specifying SSL context
type: enhancement
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43597>
_______________________________________

From report at bugs.python.org  Mon Mar 22 19:17:08 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Mar 2021 23:17:08 +0000
Subject: [issue41718] test.regrtest has way too many imports
In-Reply-To: <1599233772.93.0.299899979889.issue41718@roundup.psfhosted.org>
Message-ID: <1616455028.96.0.601997834843.issue41718@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 10417dd15f135c179cf4234d1abe506915d802ff by Victor Stinner in branch 'master':
bpo-41718: Reduce libregrtest runtest imports (GH-24980)
https://github.com/python/cpython/commit/10417dd15f135c179cf4234d1abe506915d802ff


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41718>
_______________________________________

From report at bugs.python.org  Mon Mar 22 19:21:30 2021
From: report at bugs.python.org (Tarun Chinmai Sekar)
Date: Mon, 22 Mar 2021 23:21:30 +0000
Subject: [issue43597] robotparser should support specifying SSL context
Message-ID: <1616455290.24.0.546819531577.issue43597@roundup.psfhosted.org>


Change by Tarun Chinmai Sekar  <tchinmai7 at gmail.com>:


----------
components: +Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43597>
_______________________________________

From report at bugs.python.org  Mon Mar 22 19:24:12 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 22 Mar 2021 23:24:12 +0000
Subject: [issue43555] Location of SyntaxError with new parser missing (after
 continuation character)
In-Reply-To: <1616152732.25.0.508578313833.issue43555@roundup.psfhosted.org>
Message-ID: <1616455452.89.0.326554344962.issue43555@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Before the patch, IDLE highlighted the \n endline with a red background,  which tk displays as red background from the blank space after the 4 to the right edge of the text widget, including in 3.8.8.

The 3.8 result, different from REPL, is due the the difference of using code._maybe_compile.  The latter catches the SyntaxError for "3 \\ 4", which has offset 5, recompiles "3 \\ 4\n", and raises the subsequent SyntaxError, which has offset 6.  (In this particular case where the message remains the same, the original SyntaxError instance with the original offset should have been kept and raised.)

I have occasionally made this typing mistake and found the long red line slightly annoying, but never thought to compare it to the REPL caret or report it as a bug.  The new parser made no difference in IDLE to newly annoy.

After the patch, the (1-based) offset stays 5, which IDLE knows means the 5th char and hence it now highlights the '4'.  Much better.  Thank you both for the report and fix.

Side question: https://docs.python.org/3/library/exceptions.html#SyntaxError says "Instances of this class have attributes filename, lineno, offset and text ...". Should it be documented that lineno and offset are both 1-based?  Are these CPython accidents or part of the language?  1-based line numbers can be expected as common across languages, tk and python included.  I believe that 1-based column offsets were viewed in a previous issue as a bug that we would not fix.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43555>
_______________________________________

From report at bugs.python.org  Mon Mar 22 19:25:16 2021
From: report at bugs.python.org (Tarun Chinmai Sekar)
Date: Mon, 22 Mar 2021 23:25:16 +0000
Subject: [issue43597] robotparser should support specifying SSL context
Message-ID: <1616455516.19.0.272349627897.issue43597@roundup.psfhosted.org>


New submission from Tarun Chinmai Sekar  <tchinmai7 at gmail.com>:

IMO this could be enhanced by adding a sslcontext parameter to read method

a sample change would it could look like
```
def read(self, sslcontext=None):
    """Reads the robots.txt URL and feeds it to the parser."""
    try:
        if sslcontext:
           f = urllib.request.urlopen(self.url, context=sslcontext)
        else:
           f = urllib.request.urlopen(self.url)
    except urllib.error.HTTPError as err:
        if err.code in (401, 403):
            self.disallow_all = True
        elif err.code >= 400 and err.code < 500:
            self.allow_all = True
    else:
        raw = f.read()
        self.parse(raw.decode("utf-8").splitlines())

```

Happy to send a PR if this proposal makes sense.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43597>
_______________________________________

From report at bugs.python.org  Mon Mar 22 19:35:32 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Mar 2021 23:35:32 +0000
Subject: [issue41718] test.regrtest has way too many imports
In-Reply-To: <1599233772.93.0.299899979889.issue41718@roundup.psfhosted.org>
Message-ID: <1616456132.03.0.452306648587.issue41718@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +23742
pull_request: https://github.com/python/cpython/pull/24982

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41718>
_______________________________________

From report at bugs.python.org  Mon Mar 22 19:48:46 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Mar 2021 23:48:46 +0000
Subject: [issue41718] test.regrtest has way too many imports
In-Reply-To: <1599233772.93.0.299899979889.issue41718@roundup.psfhosted.org>
Message-ID: <1616456926.53.0.611531545243.issue41718@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +23743
pull_request: https://github.com/python/cpython/pull/24983

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41718>
_______________________________________

From report at bugs.python.org  Mon Mar 22 19:50:43 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 22 Mar 2021 23:50:43 +0000
Subject: [issue43555] Location of SyntaxError with new parser missing (after
 continuation character)
In-Reply-To: <1616152732.25.0.508578313833.issue43555@roundup.psfhosted.org>
Message-ID: <1616457043.33.0.0399283667858.issue43555@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

We should definitely document the column offset being 1-based, if it hasn't been already. But be careful, there are some APIs that are 0-based and others that are 1-based, for column offsets.

I was quite surprised at some point to find out that we were inconsistent with the column offset, and then I looked at what Emacs and vim do, and I found that both interpret column offsets (in the familiar "filename:lineno:offset: message" format) as 1-based. IIRC I had to fix it in quite a few places because we were actually being inconsistent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43555>
_______________________________________

From report at bugs.python.org  Mon Mar 22 19:53:31 2021
From: report at bugs.python.org (Ammar Askar)
Date: Mon, 22 Mar 2021 23:53:31 +0000
Subject: [issue43555] Location of SyntaxError with new parser missing (after
 continuation character)
In-Reply-To: <1616152732.25.0.508578313833.issue43555@roundup.psfhosted.org>
Message-ID: <1616457211.26.0.262123735353.issue43555@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

> We should definitely document the column offset being 1-based

Yes please, I remember working on that issue to make it consistently 1-based a while ago and I remember that the tooling was relying on 1-based indexes for column offsets.

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43555>
_______________________________________

From report at bugs.python.org  Mon Mar 22 20:03:17 2021
From: report at bugs.python.org (Tarun Chinmai Sekar)
Date: Tue, 23 Mar 2021 00:03:17 +0000
Subject: [issue43597] robotparser should support specifying SSL context
In-Reply-To: <1616455516.19.0.272349627897.issue43597@roundup.psfhosted.org>
Message-ID: <1616457797.35.0.515356502801.issue43597@roundup.psfhosted.org>


Change by Tarun Chinmai Sekar  <tchinmai7 at gmail.com>:


----------
keywords: +patch
pull_requests: +23744
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24984

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43597>
_______________________________________

From report at bugs.python.org  Mon Mar 22 20:08:56 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Mar 2021 00:08:56 +0000
Subject: [issue41718] test.regrtest has way too many imports
In-Reply-To: <1599233772.93.0.299899979889.issue41718@roundup.psfhosted.org>
Message-ID: <1616458136.76.0.726398767513.issue41718@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 0473fb222956063814b6beb5fd401f9eeaa8a56a by Victor Stinner in branch 'master':
bpo-41718: libregrtest runtest avoids import_helper (GH-24983)
https://github.com/python/cpython/commit/0473fb222956063814b6beb5fd401f9eeaa8a56a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41718>
_______________________________________

From report at bugs.python.org  Mon Mar 22 20:11:37 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Mar 2021 00:11:37 +0000
Subject: [issue41718] test.regrtest has way too many imports
In-Reply-To: <1599233772.93.0.299899979889.issue41718@roundup.psfhosted.org>
Message-ID: <1616458297.88.0.475928430186.issue41718@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 30793e81bd90f3346e962435d49073bc588f067c by Victor Stinner in branch 'master':
bpo-41718: Disable support.testresult XML output by default (GH-24982)
https://github.com/python/cpython/commit/30793e81bd90f3346e962435d49073bc588f067c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41718>
_______________________________________

From report at bugs.python.org  Mon Mar 22 20:17:02 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Mar 2021 00:17:02 +0000
Subject: [issue41718] test.regrtest has way too many imports
In-Reply-To: <1599233772.93.0.299899979889.issue41718@roundup.psfhosted.org>
Message-ID: <1616458622.27.0.265055784658.issue41718@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +23745
pull_request: https://github.com/python/cpython/pull/24985

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41718>
_______________________________________

From report at bugs.python.org  Mon Mar 22 20:20:43 2021
From: report at bugs.python.org (Tarun Chinmai Sekar)
Date: Tue, 23 Mar 2021 00:20:43 +0000
Subject: [issue43597] robotparser should support specifying SSL context
In-Reply-To: <1616455516.19.0.272349627897.issue43597@roundup.psfhosted.org>
Message-ID: <1616458843.71.0.242097306138.issue43597@roundup.psfhosted.org>


Change by Tarun Chinmai Sekar  <tchinmai7 at gmail.com>:


----------
pull_requests: +23746
pull_request: https://github.com/python/cpython/pull/24986

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43597>
_______________________________________

From report at bugs.python.org  Mon Mar 22 20:26:37 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Mar 2021 00:26:37 +0000
Subject: [issue41718] test.regrtest has way too many imports
In-Reply-To: <1599233772.93.0.299899979889.issue41718@roundup.psfhosted.org>
Message-ID: <1616459197.3.0.860872334443.issue41718@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +23747
pull_request: https://github.com/python/cpython/pull/24987

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41718>
_______________________________________

From report at bugs.python.org  Mon Mar 22 20:27:25 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 23 Mar 2021 00:27:25 +0000
Subject: [issue10572] Move test sub-packages to Lib/test
In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za>
Message-ID: <1616459245.95.0.230973585741.issue10572@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I added idlelib.idletest in May 2013 with the concurrence of Nick Coughlin, who also suggested 'idle_test' rather than just 'test'.  It currently has 72 files (66 test_xyz files for idlelib modules).

Foord's opening justification for moving package tests was "Having tests in Lib/test instead of inside the package makes it easier to grep the unittest package without grepping the tests."

I presume 'tests' refers to the unittest tests but I don't understand 'easier'.  Is recursive grepping really not optional for the grep he uses?  In any case, if Michael as package author preferred to put them in /Lib, fine.

Having package tests in the package makes it possible to grep both package code and tests together from an editor that allows searching all files in a single directory or tree.  IDLE's editor and Notepad++ are 2 examples and both have a recurse checkmark option off by default.  I routinely do both types of searches of idlelib from an IDLE editor.

I have never grepped Lib/test, but if others do, would symlinks work?

For optional packages like tkinter and idlelib, having the tests in the package means that tests are automatically omitted when the package is.  If they were moved, vendors wanting a clean test directory would have to write new code to omit or include package tests when the package is omitted or included.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10572>
_______________________________________

From report at bugs.python.org  Mon Mar 22 20:40:46 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Mar 2021 00:40:46 +0000
Subject: [issue41718] test.regrtest has way too many imports
In-Reply-To: <1599233772.93.0.299899979889.issue41718@roundup.psfhosted.org>
Message-ID: <1616460046.68.0.854707010117.issue41718@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 9feae41c4f04ca27fd2c865807a5caeb50bf4fc4 by Victor Stinner in branch 'master':
bpo-41718: libregrtest avoids importing datetime (GH-24985)
https://github.com/python/cpython/commit/9feae41c4f04ca27fd2c865807a5caeb50bf4fc4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41718>
_______________________________________

From report at bugs.python.org  Mon Mar 22 20:41:55 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Mar 2021 00:41:55 +0000
Subject: [issue43598] test_subprocess logs multiple ResourceWarning warnings
Message-ID: <1616460115.42.0.31373302099.issue43598@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

$ ./python -m test test_subprocess -v
(...)
test_send_signal_race2 (test.test_subprocess.POSIXProcessTestCase) ... /home/vstinner/python/master/Lib/subprocess.py:1062: ResourceWarning: subprocess 137193 is still running
  _warn("subprocess %s is still running" % self.pid,
ResourceWarning: Enable tracemalloc to get the object allocation traceback
ok

test_pipesize_default (test.test_subprocess.ProcessTestCase) ... /home/vstinner/python/master/Lib/unittest/case.py:549: ResourceWarning: unclosed file <_io.BufferedReader name=8>
  method()
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/home/vstinner/python/master/Lib/unittest/case.py:549: ResourceWarning: unclosed file <_io.BufferedReader name=10>
  method()
ResourceWarning: Enable tracemalloc to get the object allocation traceback
ok

test_pipesize_default (test.test_subprocess.ProcessTestCaseNoPoll) ... /home/vstinner/python/master/Lib/unittest/case.py:549: ResourceWarning: unclosed file <_io.BufferedReader name=8>
  method()
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/home/vstinner/python/master/Lib/unittest/case.py:549: ResourceWarning: unclosed file <_io.BufferedReader name=10>
  method()
ResourceWarning: Enable tracemalloc to get the object allocation traceback
ok
(...)

----------
components: Tests
messages: 389359
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_subprocess logs multiple ResourceWarning warnings
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43598>
_______________________________________

From report at bugs.python.org  Mon Mar 22 20:47:13 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Mar 2021 00:47:13 +0000
Subject: [issue41718] test.regrtest has way too many imports
In-Reply-To: <1599233772.93.0.299899979889.issue41718@roundup.psfhosted.org>
Message-ID: <1616460433.57.0.039488239217.issue41718@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

len(sys.modules) of msg376374 test_sys_modules:

* Python 3.6: 184
* Python 3.7: 183
* Python 3.8: 221
* Python 3.9: 233
* master: 131

The master branch imports 102 less modules than Python 3.9 (233 => 131)! Almost the half.

asyncio, logging, multiprocessing, etc. are no longer always imported by default.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41718>
_______________________________________

From report at bugs.python.org  Mon Mar 22 21:02:49 2021
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 23 Mar 2021 01:02:49 +0000
Subject: [issue43598] test_subprocess logs multiple ResourceWarning warnings
In-Reply-To: <1616460115.42.0.31373302099.issue43598@roundup.psfhosted.org>
Message-ID: <1616461369.6.0.655530157778.issue43598@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/issue43598>
_______________________________________

From report at bugs.python.org  Mon Mar 22 21:03:26 2021
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 23 Mar 2021 01:03:26 +0000
Subject: [issue43558] The dataclasses documentation should mention how to call
 super().__init__
In-Reply-To: <1616165238.01.0.0594716110393.issue43558@roundup.psfhosted.org>
Message-ID: <1616461406.19.0.862389934487.issue43558@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/issue43558>
_______________________________________

From report at bugs.python.org  Mon Mar 22 21:07:11 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 23 Mar 2021 01:07:11 +0000
Subject: [issue14364] Argparse incorrectly handles '--' as argument to option
In-Reply-To: <1332080953.55.0.495639573781.issue14364@psf.upfronthosting.co.za>
Message-ID: <1616461631.31.0.347994964785.issue14364@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Unassigning because I haven't been able to make time for this one.

----------
assignee: rhettinger -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14364>
_______________________________________

From report at bugs.python.org  Mon Mar 22 21:31:51 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 23 Mar 2021 01:31:51 +0000
Subject: [issue35118] Add peek() or first() method in queue
In-Reply-To: <1540956018.19.0.788709270274.issue35118@psf.upfronthosting.co.za>
Message-ID: <1616463111.02.0.409918262521.issue35118@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

>> FWIW, the standard library queue module doesn't have 
>> a straight-forward way to implement a peek() method.

> I currently use `q.deque[0]`

The Queue class is only allowed to call _init, _qsize, _put, and _get.  It is not allowed to directly touch the underlying data structure.  Otherwise, subclasses relying on the abstraction would fail.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35118>
_______________________________________

From report at bugs.python.org  Mon Mar 22 21:54:58 2021
From: report at bugs.python.org (Xinmeng Xia)
Date: Tue, 23 Mar 2021 01:54:58 +0000
Subject: [issue43599] Setting long domain of locale.dgettext() crashes Python
 interpreter
Message-ID: <1616464498.74.0.582898049043.issue43599@roundup.psfhosted.org>


New submission from Xinmeng Xia <xiaxm at smail.nju.edu.cn>:

Setting the first argument of locale.dgettext() long string, Python interpreter crashes. 

======================================================
Python 3.10.0a6 (default, Mar 19 2021, 11:45:56) [GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale;locale.dgettext('abs'*10000000,'')
Segmentation fault (core dumped)
======================================================

System: Ubuntu 16.04

BTW, the api of module locale seems to be inconsistent between Ubuntu and Mac OS.  E.g.  there is no dgettext() for Python on Mac OS.

----------
components: Library (Lib)
messages: 389363
nosy: xxm
priority: normal
severity: normal
status: open
title: Setting long domain of locale.dgettext() crashes Python interpreter
type: crash
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43599>
_______________________________________

From report at bugs.python.org  Mon Mar 22 21:58:56 2021
From: report at bugs.python.org (FRANK BENNETT)
Date: Tue, 23 Mar 2021 01:58:56 +0000
Subject: [issue37405] socket.getsockname() returns string instead of tuple
In-Reply-To: <1561496477.42.0.179203753139.issue37405@roundup.psfhosted.org>
Message-ID: <1616464736.43.0.604784504753.issue37405@roundup.psfhosted.org>


FRANK BENNETT <fbennett78 at reagan.com> added the comment:

$ make test TESTOPTS="-v test_socket"

ERROR: testSendFrame (__main__.CANTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/s/opt/cpython/debug/test_socket.py", line 2052, in testSendFrame
    self.assertEqual(addr[1], socket.AF_CAN)
IndexError: tuple index out of range

$ cat ../.git/config
https://github.com/bennett78/cpython.git

$ uname -r
5.4.0-67-genericg$ cat /etc/issue
Ubuntu 20.04.2 LTS \n \l

$ /s/opt/cpython/debug$ ./python -V
Python 3.10.0a6+

----------
components: +Tests -Documentation, Extension Modules
nosy: +bennett78
versions: +Python 3.10 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37405>
_______________________________________

From report at bugs.python.org  Mon Mar 22 22:03:51 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 23 Mar 2021 02:03:51 +0000
Subject: [issue43600] IDLE: fix highlight locationfor f-string field errors
Message-ID: <1616465031.1.0.790398051902.issue43600@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Spinoff from #41064.  In current python, the f'{*x}' traceback ends with 

    (*x)
     ^
SyntaxError: f-string: can't use starred expression here.

For f'{**x}', the message is "f-string: invalid syntax" and the ^ is also under the 2nd character in the replacement expression actually parsed (with a restricted grammar).

The Python error handler must special case a syntax error message beginning with 'f-string:' and search the input line for {...} and add its offset.

IDLE currently highlights "'", the 2nd char of the original code, instead of '*', the 2nd char of the e.text replacement.  It needs to also adjust the offset.

----------
assignee: terry.reedy
components: IDLE
messages: 389365
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: IDLE: fix highlight locationfor f-string field errors
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43600>
_______________________________________

From report at bugs.python.org  Mon Mar 22 22:11:13 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 23 Mar 2021 02:11:13 +0000
Subject: [issue41064] Specialise syntax error of **dict in f-string field
In-Reply-To: <1592742758.57.0.680300455155.issue41064@roundup.psfhosted.org>
Message-ID: <1616465473.97.0.136643011299.issue41064@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Cressey noted both a compile and IDLE Shell issue.  They must be handled separately by different people in separate bpo issues.

The first is about the helpful versus less helpful SyntaxError messages in the following (master compiled today).

>>> f'{*x}'
  File "<stdin>", line 1
    (*x)
     ^
SyntaxError: f-string: can't use starred expression here
>>> f'{**x}'
  File "<stdin>", line 1
    (**x)
     ^
SyntaxError: f-string: invalid syntax

The request is make the 2nd message the same or like the 1st.  Seems like it should be possible.  I am limiting this bpo issue to this request and opened #43600 for fixing IDLE's highlight location.

Pablo, I leave it to you to handle the message enhancement request.  Do you know if there is any other situation like this in which the compiled text is not the input code?

----------
assignee: terry.reedy -> 
components:  -IDLE
title: f-string SyntaxError gives offset within fake line, other issues -> Specialise syntax error of **dict in f-string field

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41064>
_______________________________________

From report at bugs.python.org  Mon Mar 22 22:16:55 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 23 Mar 2021 02:16:55 +0000
Subject: [issue25130] Make tests more PyPy compatible
In-Reply-To: <1442340924.34.0.752221775968.issue25130@psf.upfronthosting.co.za>
Message-ID: <1616465815.26.0.339704108343.issue25130@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

With 2.7 EOL, is this still relevant?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25130>
_______________________________________

From report at bugs.python.org  Mon Mar 22 22:20:23 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 23 Mar 2021 02:20:23 +0000
Subject: [issue20608] 'SyntaxError: invalid token' is unfriendly
In-Reply-To: <1392213800.84.0.505532685284.issue20608@psf.upfronthosting.co.za>
Message-ID: <1616466023.94.0.28646185171.issue20608@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Fixed elsewhere.

>>> 04208
  File "<stdin>", line 1
    04208
        ^
SyntaxError: leading zeros in decimal integer literals are not permitted; use an 0o prefix for octal integers
>>> 0o38
  File "<stdin>", line 1
    0o38
       ^
SyntaxError: invalid digit '8' in octal literal

----------
nosy: +terry.reedy
resolution:  -> out of date
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20608>
_______________________________________

From report at bugs.python.org  Mon Mar 22 22:50:20 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 23 Mar 2021 02:50:20 +0000
Subject: [issue1634034] Show "expected" token on syntax error
Message-ID: <1616467820.39.0.0724131043263.issue1634034@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I think that this issue should be closed as 'out of date' as it was pretty open-ended and it is unclear what request remains.

For the specific case "for a in (8,9)", the suggested "expected ':'" has been added on another issue.  I expect that there are other additions from other issues.

For "for a in (8,9: print a," there is no change but for "for a in (8,9]" we now have "closing parenthesis ']' does not match opening parenthesis '('".  This properly does not say that "expected ')'" as the needed fix might be to insert opener '['.

For many other cases, the proposed additions were disputed as not helpful, mostly because multiple things could be expected.  I think other suggestions, based on current master, should be new issues.

----------
nosy: +pablogsal, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1634034>
_______________________________________

From report at bugs.python.org  Tue Mar 23 00:04:11 2021
From: report at bugs.python.org (junyixie)
Date: Tue, 23 Mar 2021 04:04:11 +0000
Subject: [issue43601] Tools/c-analyzer/check-c-globals.py run throw exception
 err
Message-ID: <1616472251.02.0.323968573256.issue43601@roundup.psfhosted.org>


New submission from junyixie <xie.junyi at outlook.com>:

how to use Tools/c-analyzer/check-c-globals.py? 
in readme, 
python3 Tools/c-analyzer/check-c-globals.py

/Users/xiejunyi/cpython/Tools/c-analyzer/c_common/tables.py:236: FutureWarning: Possible nested set at position 12
  _COLSPEC_RE = re.compile(textwrap.dedent(r'''
Traceback (most recent call last):
  File "Tools/c-analyzer/check-c-globals.py", line 33, in <module>
    (cmd, cmd_kwargs, verbosity, traceback_cm) = parse_args()
  File "Tools/c-analyzer/check-c-globals.py", line 16, in parse_args
    _cli_check(parser, checks='<globals>'),
  File "/Users/xiejunyi/cpython/Tools/c-analyzer/cpython/__main__.py", line 119, in _cli_check
    return c_analyzer._cli_check(parser, CHECKS, **kwargs, **FILES_KWARGS)
TypeError: _cli_check() got multiple values for argument 'checks'

----------
components: Demos and Tools
messages: 389370
nosy: JunyiXie
priority: normal
severity: normal
status: open
title: Tools/c-analyzer/check-c-globals.py run throw exception err
type: crash
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43601>
_______________________________________

From report at bugs.python.org  Tue Mar 23 00:52:34 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 23 Mar 2021 04:52:34 +0000
Subject: [issue43347] IDLE crashes in macOS Apple chip, maybe completions
In-Reply-To: <1614559444.76.0.552687903275.issue43347@roundup.psfhosted.org>
Message-ID: <1616475154.79.0.723395991856.issue43347@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

This time I got a screen shot showing the gray completion box that appeared just as IDLE stopped responding and froze:

https://www.dropbox.com/s/eu3wd13vytz6tt8/Screen%20Shot%202021-03-22%20at%209.37.56%20PM.png?dl=0

Am now running Python 3.10.0a6 on Big Sur 11.2.3 running on a 2020 M-1 MacBook Air.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43347>
_______________________________________

From report at bugs.python.org  Tue Mar 23 02:30:40 2021
From: report at bugs.python.org (Sergey B Kirpichev)
Date: Tue, 23 Mar 2021 06:30:40 +0000
Subject: [issue43602] Include Decimal's in numbers.Real
Message-ID: <1616481040.42.0.772549255299.issue43602@roundup.psfhosted.org>


New submission from Sergey B Kirpichev <skirpichev at gmail.com>:

Commit 82417ca9b2 includes Decimal's in the numbers tower, but only as an implementation of the abstract numbers.Number.  The mentioned reason is "Decimals are not interoperable with floats" (see comments in the numbers.py as well), i.e. there is no lossless conversion (in general, in both directions).

While this seems to be reasonable, there are arguments against:

1) The numbers module docs doesn't assert there should be a lossless conversion for implementations of same abstract type.  (Perhaps, it should.)  This obviously may be assumed for cases, where does exist an exact representation (integers, rationals and so on) - but not for real numbers (or complex), where representations are inexact (unless we consider some subsets of real numbers, e.g. some real finite extension of rationals - I doubt such class can represent numbers.Real).

(Unfortunately, the Scheme distinction of exact/inexact was lost in PEP 3141.)

2) By same reason, I think, neither binary-based multiprecision arithmetics package can represent numbers.Real: i.e. gmpy2.mpfr, mpmath.mpf and so on.  (In general, there is no lossless conversion float's, in both directions.)

3) That might confuse users (why 10-th base arbitrary precision floating point arithmetic can't represent real numbers?).

4) Last, but not least, even some parts of stdlib uses both types in an interoperable way, e.g. Fraction constructor:
    elif isinstance(numerator, (float, Decimal)):
        # Exact conversion
        self._numerator, self._denominator = numerator.as_integer_ratio()
        return self

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 389372
nosy: Sergey.Kirpichev, docs at python
priority: normal
severity: normal
status: open
title: Include Decimal's in numbers.Real
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43602>
_______________________________________

From report at bugs.python.org  Tue Mar 23 03:28:11 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 23 Mar 2021 07:28:11 +0000
Subject: [issue43602] Include Decimal's in numbers.Real
In-Reply-To: <1616481040.42.0.772549255299.issue43602@roundup.psfhosted.org>
Message-ID: <1616484491.7.0.560125533154.issue43602@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

We don't have a choice here.  Operations between decimals and floats raise a TypeError.  So, we can't register Decimal as a Real; otherwise, static type checking wouldn't be able to flag the following as invalid:

    def add(a: Real, b: Real) -> Real:
        return a + b

    a: Real = Decimal('1.1')
    b: Real = 2.2
    print(add(a, b))

This gives:

    Traceback (most recent call last):
      File "/Users/raymond/Documents/tmp.py", line 10, in <module>
        print(add(a, b))
      File "/Users/raymond/Documents/tmp.py", line 6, in add
        return a + b
    TypeError: unsupported operand type(s) for +: 'decimal.Decimal' and 'float'

Almost the whole point of static checking is to avoid these TypeErrors at runtime

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43602>
_______________________________________

From report at bugs.python.org  Tue Mar 23 03:35:30 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 23 Mar 2021 07:35:30 +0000
Subject: [issue43602] Include Decimal's in numbers.Real
In-Reply-To: <1616481040.42.0.772549255299.issue43602@roundup.psfhosted.org>
Message-ID: <1616484930.01.0.00256945371356.issue43602@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

We don't have a choice here.  Operations between decimals and floats raise a TypeError.  So, we can't register Decimal as a Real; otherwise, static type checking wouldn't be able to flag the following as invalid:

    def add(a: Real, b: Real) -> Real:
        return a + b

    a: Real = Decimal('1.1')
    b: Real = 2.2
    print(add(a, b))

This gives:

    Traceback (most recent call last):
      File "/Users/raymond/Documents/tmp.py", line 10, in <module>
        print(add(a, b))
      File "/Users/raymond/Documents/tmp.py", line 6, in add
        return a + b
    TypeError: unsupported operand type(s) for +: 'decimal.Decimal' and 'float'

Almost the whole point of static checking is early detection of these problems so we won't encounter the TypeError at runtime.

P.S.  With respect to #4, we've harmonized the APIs as much as we sensibly can.  That allows some code to be more polymorphic as long at the type is consistent throughout.  That is much different than freely mixing floats and decimals in the direct interactions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43602>
_______________________________________

From report at bugs.python.org  Tue Mar 23 03:35:42 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 23 Mar 2021 07:35:42 +0000
Subject: [issue43602] Include Decimal's in numbers.Real
In-Reply-To: <1616481040.42.0.772549255299.issue43602@roundup.psfhosted.org>
Message-ID: <1616484942.14.0.197136072792.issue43602@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
Removed message: https://bugs.python.org/msg389373

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43602>
_______________________________________

From report at bugs.python.org  Tue Mar 23 03:44:42 2021
From: report at bugs.python.org (Ammar Askar)
Date: Tue, 23 Mar 2021 07:44:42 +0000
Subject: [issue43601] Tools/c-analyzer/check-c-globals.py run throw exception
 err
In-Reply-To: <1616472251.02.0.323968573256.issue43601@roundup.psfhosted.org>
Message-ID: <1616485482.29.0.999127364612.issue43601@roundup.psfhosted.org>


Change by Ammar Askar <ammar at ammaraskar.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43601>
_______________________________________

From report at bugs.python.org  Tue Mar 23 04:04:03 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 23 Mar 2021 08:04:03 +0000
Subject: [issue41064] Specialise syntax error of **dict in f-string field
In-Reply-To: <1592742758.57.0.680300455155.issue41064@roundup.psfhosted.org>
Message-ID: <1616486643.74.0.555465018475.issue41064@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

The parens are added in fstring_compile_expr at https://github.com/python/cpython/blob/9feae41c4f04ca27fd2c865807a5caeb50bf4fc4/Parser/string_parser.c#L391

I don't recall if this is really only a "skip leading whitespace" problem, or if there's some other reason they're required. If it's just a whitespace issue, maybe skipping leading whitespace in fstring_compile_expr is a better idea? One of the reasons I originally didn't want to skip leading whitespace is because I didn't want to add yet another place where we'd have to maintain a "what qualifies as whitespace to the compiler?" decision.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41064>
_______________________________________

From report at bugs.python.org  Tue Mar 23 04:21:56 2021
From: report at bugs.python.org (Sergey B Kirpichev)
Date: Tue, 23 Mar 2021 08:21:56 +0000
Subject: [issue43602] Include Decimal's in numbers.Real
In-Reply-To: <1616481040.42.0.772549255299.issue43602@roundup.psfhosted.org>
Message-ID: <1616487716.28.0.177493646825.issue43602@roundup.psfhosted.org>


Sergey B Kirpichev <skirpichev at gmail.com> added the comment:

> Operations between decimals and floats raise a TypeError.

I saw this)  And as I said, I assume, the reason is: there is no lossless conversion to float's (and vice verse).

If so (point 2), neither multiple-precision type (e.g. gmpy2.mpfr) can subclass from the numbers.Real (there can be different precisions, different bases) and that sounds too restrictive.

>From the mathematician point of view, both built-in float's and Decimal's could be viewed as (inexact!) representations for real numbers.  But if _any_ such representations, conforming the numbers abc must be lossless converted to each other - that might be a documentation issue.

> P.S.  With respect to #4, we've harmonized the APIs as much as we sensibly can.

That was very minor, yes.  Something like try-except could be used here, trying as_integer_ratio().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43602>
_______________________________________

From report at bugs.python.org  Tue Mar 23 04:49:15 2021
From: report at bugs.python.org (=?utf-8?b?TWl0amEga29jamFuxI1pxI0=?=)
Date: Tue, 23 Mar 2021 08:49:15 +0000
Subject: [issue32592] Drop support of Windows Vista and Windows 7
In-Reply-To: <1516268238.05.0.467229070634.issue32592@psf.upfronthosting.co.za>
Message-ID: <1616489355.63.0.0955124337603.issue32592@roundup.psfhosted.org>


Mitja kocjan?i? <veso266 at gmail.com> added the comment:

I have to agree with msg389225, I use windows 7 on my dev machine as well as I use some programs and devices that unfortionatly do not work on windows 10 so update is not possible, now it would be realy anoying that I would loose python support as well since I use one device with python that does not work on win10

so I am in favour that python keeps the workarounds and fallback code for Windows 7 at least until ESU supports ends (since if its a dead code why would you remove it just leave it in, if it works well and you don't touch it often it does no harm)

----------
nosy: +veso266

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32592>
_______________________________________

From report at bugs.python.org  Tue Mar 23 05:23:55 2021
From: report at bugs.python.org (Alexey Izbyshev)
Date: Tue, 23 Mar 2021 09:23:55 +0000
Subject: [issue32592] Drop support of Windows Vista and Windows 7
In-Reply-To: <1516268238.05.0.467229070634.issue32592@psf.upfronthosting.co.za>
Message-ID: <1616491435.11.0.585262538175.issue32592@roundup.psfhosted.org>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

As far as I understand, commit [1] explicitly prevents CPython from running on Windows 7, and it's included into 3.9. So it seems to be too late to complain, despite that, according to Wikipedia, more than 15% of all Windows PCs are still running Windows 7 [2].

[1] https://github.com/izbyshev/cpython/commit/6a65eba44bfd82ccc8bed4b5c6dd6637549955d5
[2] https://en.wikipedia.org/wiki/Windows_7

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32592>
_______________________________________

From report at bugs.python.org  Tue Mar 23 05:53:27 2021
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 23 Mar 2021 09:53:27 +0000
Subject: [issue43466] ssl/hashlib: Add configure option to set or auto-detect
 rpath to OpenSSL libs
In-Reply-To: <1615418043.46.0.229114131093.issue43466@roundup.psfhosted.org>
Message-ID: <1616493207.94.0.235869236438.issue43466@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +23748
pull_request: https://github.com/python/cpython/pull/24989

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43466>
_______________________________________

From report at bugs.python.org  Tue Mar 23 06:04:34 2021
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 23 Mar 2021 10:04:34 +0000
Subject: [issue43466] ssl/hashlib: Add configure option to set or auto-detect
 rpath to OpenSSL libs
In-Reply-To: <1615418043.46.0.229114131093.issue43466@roundup.psfhosted.org>
Message-ID: <1616493874.61.0.1868346084.issue43466@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

GH-24989 adds -Wl,--exclude-libs just for libssl.a and libcrypto.a IFF support for -Wl,--exclude-libs,ALL is detected by configure. This puts the symbols from the OpenSSL archive files into the LOCAL segment of ELF binaries. The PR does not set -Wl,--exclude-libs,ALL because I like to keep behavior the same as with 3.9.

When OpenSSL is locally build with "no-shared -fPIC", then Python automatically builds a partially static-linked _ssl and _hashlib extension modules that do not pollute the global namespace:


$ ./config \
    --prefix=/home/heimes/dev/python/multissl/openssl/1.1.1j-static \
    --openssldir=/etc/pki/tls \
    no-shared -fPIC
...
$ ./configure --with-openssl=/home/heimes/dev/python/multissl/openssl/1.1.1j-static
$ make
$ ldd build/lib.linux-x86_64-3.10/_ssl.cpython-310-x86_64-linux-gnu.so 
        linux-vdso.so.1 (0x00007fff8dbbc000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fa5a533d000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fa5a5172000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fa5a56ac000)
$ readelf -Ws build/lib.linux-x86_64-3.10/_ssl.cpython-310-x86_64-linux-gnu.so | grep SSL_CTX_new
  5617: 0000000000072a90  1133 FUNC    LOCAL  DEFAULT   11 SSL_CTX_new


I deliberately did not update documentation with instructions for static linking. Static linking of OpenSSL has security and compatibility implications. I don't want to officially support it and deal with bug reports. -Wl,--exclude-libs just enables sane partial static-linking.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43466>
_______________________________________

From report at bugs.python.org  Tue Mar 23 06:21:49 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 23 Mar 2021 10:21:49 +0000
Subject: [issue43602] Include Decimal's in numbers.Real
In-Reply-To: <1616481040.42.0.772549255299.issue43602@roundup.psfhosted.org>
Message-ID: <1616494909.96.0.966499377348.issue43602@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I assume, the reason is: there is no lossless conversion to float's (and vice verse).

No, I don't think that's the reason (and in fact we _do_ have lossless conversion of floats to Decimal instances). IMO, the reasons are:

- it's not obvious what the *type* of the result of some_float + some_other_decimal should be, and

- it seems rather likely that any attempt to combine a float and a Decimal instance in this way is a bug, or at least something that hasn't been fully thought through by the developer, so we force the developer to make an explicit conversion

For historical discussions, see #1682.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43602>
_______________________________________

From report at bugs.python.org  Tue Mar 23 06:22:43 2021
From: report at bugs.python.org (junyixie)
Date: Tue, 23 Mar 2021 10:22:43 +0000
Subject: [issue43601] Tools/c-analyzer/check-c-globals.py run throw exception
 err
In-Reply-To: <1616472251.02.0.323968573256.issue43601@roundup.psfhosted.org>
Message-ID: <1616494963.74.0.920854163514.issue43601@roundup.psfhosted.org>


junyixie <xie.junyi at outlook.com> added the comment:

found in must-reslove.sh
function run_capi() {
    ./python Tools/c-analyzer/c-analyzer.py capi \
        --no-progress \
        --group-by kind \
        --func --inline --macro \
        --no-show-empty \
        --ignore '<must-resolve.ignored>' \
        $@
}

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43601>
_______________________________________

From report at bugs.python.org  Tue Mar 23 06:30:58 2021
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 23 Mar 2021 10:30:58 +0000
Subject: [issue43547] support ZIP files with zeroed out fields (e.g. for
 reproducible builds)
In-Reply-To: <1616102738.26.0.451702371832.issue43547@roundup.psfhosted.org>
Message-ID: <1616495458.69.0.0110864034677.issue43547@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

The __getattr__ hack is not needed. You can reset the flags in a different, more straight forward way:


class ReproducibleZipInfo(ZipInfo):
    __slots__ = ()

    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self._reset_flags()

    @classmethod
    def from_file(cls, *args, **kwargs):
        zinfo = super().from_file(*args, **kwargs)
        zinfo._reset_flags()
        return zinfo

    def _reset_flags(self):
        self.date_time = (1980, 0, 0, 0, 0, 0)
        self.create_system = 0
        self.external_attr = 0


>>> zinfo = ReproducibleZipInfo.from_file("/etc/os-release")
>>> zinfo.external_attr
0
>>> zinfo.create_system
0
>>> zinfo.date_time
(1980, 0, 0, 0, 0, 0)


I think it makes also sense to replace hard-coded ZipInfo class with dispatcher attribute on the class:


@@ -1203,6 +1211,7 @@ class ZipFile:
 
     fp = None                   # Set here since __del__ checks it
     _windows_illegal_name_trans_table = None
+    zipinfo_class = ZipInfo
 
     def __init__(self, file, mode="r", compression=ZIP_STORED, allowZip64=True,
                  compresslevel=None, *, strict_timestamps=True):
@@ -1362,7 +1371,7 @@ def _RealGetContents(self):
                 # Historical ZIP filename encoding
                 filename = filename.decode('cp437')
             # Create ZipInfo instance to store file information
-            x = ZipInfo(filename)
+            x = self.zipinfo_class(filename)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43547>
_______________________________________

From report at bugs.python.org  Tue Mar 23 06:53:46 2021
From: report at bugs.python.org (Thomas Wamm)
Date: Tue, 23 Mar 2021 10:53:46 +0000
Subject: [issue43511] tkinter with Tk 8.6.11 is slow on macOS
In-Reply-To: <1615875194.4.0.35991043769.issue43511@roundup.psfhosted.org>
Message-ID: <1616496826.67.0.898566221856.issue43511@roundup.psfhosted.org>


Thomas Wamm <thomaswamm at gmail.com> added the comment:

Summary: "poor tkinter performance correlates with failed self-tests"

I'm an amateur hobbyist noobie programmer, so sophisticated testing is a challenge for me.  I raised this issue because I noticed Python graphics thru tkinter is especially slow on MacOS, and especially ultra-slow on my new M1 Mac Mini with Python 3.9.2 or 3.10.0a6 for Apple silicon. Aside from this weird issue, the M1 Mac outperforms all my other computers (including Win10 on i5-9500T, and Raspberry Pi 400). I'm expecting at least 10x performance improvement on M1 Macs when this issue gets resolved. 

Anyway, I looked under the hood.  I found some tkinter test programs runnable on MacOS with: 

/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/tkinter/test/runtktests.py

The same program is buried in the Windows Python modules library, but was not findable in Python 3.7.3 for Linux on Raspberry Pi.

So I ran runtktests.py on Windows 10 and MacOS in many configurations. All was good EXCEPT Python 3.9.2 and 3.10.0a6 on old MacOS 10.11.6 and new MacOS 11.2.3.  Those configs report about 10 Failed tests in a suite of over 1000 tests, and interestingly the 3.9 and 3.10 tests run about 4x slower than the older Python 3.8 tests that reported zero failures.

So poor tkinter performance on MacOS correlates with failed tkinter self-tests. Maybe a more expert person could dig deeper?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43511>
_______________________________________

From report at bugs.python.org  Tue Mar 23 07:11:58 2021
From: report at bugs.python.org (Thomas Wamm)
Date: Tue, 23 Mar 2021 11:11:58 +0000
Subject: [issue43511] tkinter with Tk 8.6.11 is slow on macOS
In-Reply-To: <1615875194.4.0.35991043769.issue43511@roundup.psfhosted.org>
Message-ID: <1616497918.95.0.80861985741.issue43511@roundup.psfhosted.org>


Thomas Wamm <thomaswamm at gmail.com> added the comment:

Failed tkinter tests were already noted in Issue 42507.
No mention of failures correlating with much slower testing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43511>
_______________________________________

From report at bugs.python.org  Tue Mar 23 07:13:31 2021
From: report at bugs.python.org (=?utf-8?b?TWl0amEga29jamFuxI1pxI0=?=)
Date: Tue, 23 Mar 2021 11:13:31 +0000
Subject: [issue32592] Drop support of Windows Vista and Windows 7
In-Reply-To: <1516268238.05.0.467229070634.issue32592@psf.upfronthosting.co.za>
Message-ID: <1616498011.86.0.183124823159.issue32592@roundup.psfhosted.org>


Mitja kocjan?i? <veso266 at gmail.com> added the comment:

doh, thats unfortunate I was too late to complain, and now its all gone
oh well, I guess people will not roll back commits now, I hoped windows 7 supported could be kept at least til python4 (or when microsoft completly abandons  win7 (when the API will change as well, just like with python3 there was python2.7 which was like a LST release for ubuntu)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32592>
_______________________________________

From report at bugs.python.org  Tue Mar 23 08:43:22 2021
From: report at bugs.python.org (Sergey B Kirpichev)
Date: Tue, 23 Mar 2021 12:43:22 +0000
Subject: [issue43602] Include Decimal's in numbers.Real
In-Reply-To: <1616494909.96.0.966499377348.issue43602@roundup.psfhosted.org>
Message-ID: <YFniZb5je2kGrdik@note>


Sergey B Kirpichev <skirpichev at gmail.com> added the comment:

On Tue, Mar 23, 2021 at 10:21:50AM +0000, Mark Dickinson wrote:
> Mark Dickinson <dickinsm at gmail.com> added the comment:
> > I assume, the reason is: there is no lossless conversion to float's (and vice verse).
> and in fact we _do_ have lossless conversion of floats to Decimal instances

Indeed, context precision doesn't affect this.  (But still, reversed
conversion is inexact in general).

> - it's not obvious what the *type* of the result of some_float + some_other_decimal should be

Seems so, for a static typing.  But Python is a dynamically typed
language, isn't?

  >>> import gmpy2
  >>> gmpy2.mpfr('1.0') + 1.0
  mpfr('2.0')
  >>> 1.0 + gmpy2.mpfr('1.0')
  mpfr('2.0')

(ditto mpmath)

> - it seems rather likely that any attempt to combine a float and
> a Decimal instance in this way is a bug, or at least something that
> hasn't been fully thought through by the developer, so we
> force the developer to make an explicit conversion

Maybe it's ok for base-2 multiprecision arithmetics, as in the
example above.

Maybe not.  But in this case, if interoperability with float's (or any other
implementation for numbers.Real) is a requirement for any
numbers.Real-derived class - that should be documented.  Perhaps, then
there are bugs in mpmath/gmp2, which do claim they implement Real type:
i.e. either they should't implement automatic conversion or don't claim
they do implement numbers.Real.

> For historical discussions, see #1682.

Thank you, I'll look into.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43602>
_______________________________________

From report at bugs.python.org  Tue Mar 23 09:03:47 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 23 Mar 2021 13:03:47 +0000
Subject: [issue43602] Include Decimal's in numbers.Real
In-Reply-To: <1616481040.42.0.772549255299.issue43602@roundup.psfhosted.org>
Message-ID: <1616504627.78.0.253653247438.issue43602@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Seems so, for a static typing.  But Python is a dynamically typed
> language, isn't?

I think we're talking at cross purposes. Static and dynamic typing have nothing to do with this.

What do you think the result of `1.0 + Decimal(1)` should be, and more importantly why? Possible options are:

- Decimal('2')
- 2.0 (a float)
- a `TypeError` (as now)
- some kind of horrible user-configurable-global-state-dependent answer

Bear in mind that you have to pick a behaviour that's a good default choice for all potential application domains, and that's *hard*. ("In the face of ambiguity ...", and all that.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43602>
_______________________________________

From report at bugs.python.org  Tue Mar 23 10:35:14 2021
From: report at bugs.python.org (aaa dsghsu)
Date: Tue, 23 Mar 2021 14:35:14 +0000
Subject: [issue15352] importlib.h should be regenerated when the marshaling
 code changes
In-Reply-To: <1342294865.71.0.8673703337.issue15352@psf.upfronthosting.co.za>
Message-ID: <1616510114.53.0.746223398164.issue15352@roundup.psfhosted.org>


Change by aaa dsghsu <aaadsghsu at gmail.com>:


Added file: https://bugs.python.org/file49901/442723

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15352>
_______________________________________

From report at bugs.python.org  Tue Mar 23 10:39:51 2021
From: report at bugs.python.org (aaa dsghsu)
Date: Tue, 23 Mar 2021 14:39:51 +0000
Subject: [issue43603] safgf
Message-ID: <1616510391.68.0.379076746309.issue43603@roundup.psfhosted.org>


Change by aaa dsghsu <aaadsghsu at gmail.com>:


----------
components: C API
files: 442724
nosy: aaadsghsu
priority: normal
severity: normal
status: open
title: safgf
type: performance
versions: Python 3.6
Added file: https://bugs.python.org/file49902/442724

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43603>
_______________________________________

From report at bugs.python.org  Tue Mar 23 10:41:01 2021
From: report at bugs.python.org (aaa dsghsu)
Date: Tue, 23 Mar 2021 14:41:01 +0000
Subject: [issue43603] safgf
Message-ID: <1616510461.84.0.493740249708.issue43603@roundup.psfhosted.org>


Change by aaa dsghsu <aaadsghsu at gmail.com>:


Added file: https://bugs.python.org/file49903/442723

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43603>
_______________________________________

From report at bugs.python.org  Tue Mar 23 10:44:57 2021
From: report at bugs.python.org (aaa dsghsu)
Date: Tue, 23 Mar 2021 14:44:57 +0000
Subject: [issue43603] safgf
Message-ID: <1616510697.78.0.288966285587.issue43603@roundup.psfhosted.org>


Change by aaa dsghsu <aaadsghsu at gmail.com>:


Added file: https://bugs.python.org/file49904/131970

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43603>
_______________________________________

From report at bugs.python.org  Tue Mar 23 10:47:20 2021
From: report at bugs.python.org (Brent Gardner)
Date: Tue, 23 Mar 2021 14:47:20 +0000
Subject: [issue37405] socket.getsockname() returns string instead of tuple
In-Reply-To: <1561496477.42.0.179203753139.issue37405@roundup.psfhosted.org>
Message-ID: <1616510840.83.0.252372959687.issue37405@roundup.psfhosted.org>


Brent Gardner <bggardner at gmail.com> added the comment:

This test was overlooked, and line 2052 should now be removed per the discussion here:

https://github.com/python/cpython/pull/14392#issuecomment-506133908

In short, getsockname() used to return `(interface, socket.AF_CAN)`, in which the socket.AF_CAN element was superfluous (also undocumented), so it was removed in the fix, and the tuple format was reinstated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37405>
_______________________________________

From report at bugs.python.org  Tue Mar 23 10:48:45 2021
From: report at bugs.python.org (aaa dsghsu)
Date: Tue, 23 Mar 2021 14:48:45 +0000
Subject: [issue43603] safgf
Message-ID: <1616510925.05.0.204381031995.issue43603@roundup.psfhosted.org>


Change by aaa dsghsu <aaadsghsu at gmail.com>:


Removed file: https://bugs.python.org/file49903/442723

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43603>
_______________________________________

From report at bugs.python.org  Tue Mar 23 10:55:17 2021
From: report at bugs.python.org (E. Paine)
Date: Tue, 23 Mar 2021 14:55:17 +0000
Subject: [issue43511] tkinter with Tk 8.6.11 is slow on macOS
In-Reply-To: <1615875194.4.0.35991043769.issue43511@roundup.psfhosted.org>
Message-ID: <1616511317.7.0.445918483539.issue43511@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

This *appears* to be a Tk issue. I ran a benchmark (see attached) which repeatedly performed canvas actions. The first test ("clearing") clears the canvas, creates a rectangle, then calls both `update` and `update_idletasks`. The second test ("not clearing") is the same as the above but did not clear the canvas (causing rectangles to be drawn over each other). Here is a table of the results (times are per iteration in milliseconds):

+------------+-------------------------+-------------------------+
| Tk Version | Python                  | Wish                    |
|            +----------+--------------+----------+--------------+
|            | clearing | not clearing | clearing | not clearing |
+============+==========+==============+==========+==============+
| 8.6.8      | 6.6      | 41.4         | 4.2      | 16.2         |
+------------+----------+--------------+----------+--------------+
| 8.6.11     | 37.0     | 37.1         | 36.1     | 36.1         |
+------------+----------+--------------+----------+--------------+

A few notes:
- These were performed on a slow machine and results could be influenced by background CPU usage fluctuations
- Because it is a slow computer, I limited the iterations to just 1000 per test.
- Python version was 3.9.2
- Wish 8.6.8 was installed using an ActiveTcl binary whereas 8.6.11 was installed through homebrew

----------
Added file: https://bugs.python.org/file49905/tkbench.zip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43511>
_______________________________________

From report at bugs.python.org  Tue Mar 23 11:11:04 2021
From: report at bugs.python.org (Rupert Nash)
Date: Tue, 23 Mar 2021 15:11:04 +0000
Subject: [issue14527] How to link with a non-system libffi?
In-Reply-To: <1333851935.11.0.629390980004.issue14527@psf.upfronthosting.co.za>
Message-ID: <1616512264.3.0.904066963488.issue14527@roundup.psfhosted.org>


Rupert Nash <r.nash at epcc.ed.ac.uk> added the comment:

Due to some major changes in setup.py around libffi, I've had to re-implement my patch - please see Github. I'd appreciate any comments so we can get this merged. Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14527>
_______________________________________

From report at bugs.python.org  Tue Mar 23 11:12:20 2021
From: report at bugs.python.org (Lars Hammarstrand)
Date: Tue, 23 Mar 2021 15:12:20 +0000
Subject: [issue18304] ElementTree -- provide a way to ignore namespace in tags
 and searches
In-Reply-To: <1372218497.28.0.26294900817.issue18304@psf.upfronthosting.co.za>
Message-ID: <1616512340.61.0.585931481787.issue18304@roundup.psfhosted.org>


Lars Hammarstrand <lars.hammarstrand at centix.se> added the comment:

Any update regarding this? 

We switched to lxml to make life easier but it would be useful if this functionality also was implemented in the standard library.

Wishlist: 
1. Flag to ignore all namespaces during find().
2. Ability to set default namespace the during find().
3. Clear existing namespaces similar to lxml cleanup_namespaces.

----------
nosy: +Lars_Hammarstrand

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18304>
_______________________________________

From report at bugs.python.org  Tue Mar 23 11:12:21 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 23 Mar 2021 15:12:21 +0000
Subject: [issue43603] spam
Message-ID: <1616512341.02.0.168974403842.issue43603@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
title: safgf -> spam
type: performance -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43603>
_______________________________________

From report at bugs.python.org  Tue Mar 23 11:14:42 2021
From: report at bugs.python.org (Brent Gardner)
Date: Tue, 23 Mar 2021 15:14:42 +0000
Subject: [issue37405] socket.getsockname() returns string instead of tuple
In-Reply-To: <1561496477.42.0.179203753139.issue37405@roundup.psfhosted.org>
Message-ID: <1616512482.95.0.335715160713.issue37405@roundup.psfhosted.org>


Change by Brent Gardner <bggardner at gmail.com>:


----------
pull_requests: +23749
pull_request: https://github.com/python/cpython/pull/24991

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37405>
_______________________________________

From report at bugs.python.org  Tue Mar 23 11:26:30 2021
From: report at bugs.python.org (=?utf-8?q?David_Luke=C5=A1?=)
Date: Tue, 23 Mar 2021 15:26:30 +0000
Subject: [issue43604] Fix tempfile.mktemp()
Message-ID: <1616513190.72.0.841940564849.issue43604@roundup.psfhosted.org>


New submission from David Luke? <dafydd.lukes at gmail.com>:

I recently came across a non-testing use case for `tempfile.mktemp()` where I struggle to find a viable alternative -- temporary named pipes (FIFOs):

```
import os
import tempfile
import subprocess as sp

fifo_path = tempfile.mktemp()
os.mkfifo(fifo_path, 0o600)
try:
    proc = sp.Popen(["cat", fifo_path], stdout=sp.PIPE, text=True)
    with open(fifo_path, "w") as fifo:
        for c in "Ko?ka leze d?rou, pes oknem.":
            print(c, file=fifo)
    proc.wait()
finally:
    os.unlink(fifo_path)

for l in proc.stdout:
    print(l.strip())
```

(`cat` is obviously just a stand-in for some useful program which needs to read from a file, but you want to send it input from Python.)

`os.mkfifo()` needs a path which doesn't point to an existing file, so it's not possible to use a `tempfile.NamedTemporaryFile(delete=False)`, close it, and pass its `.name` attribute to `mkfifo()`.

I know there has been some discussion regarding `mktemp()` in the relatively recent past (see the Python-Dev thread starting with <https://mail.python.org/pipermail/python-dev/2019-March/156721.html>). There has also been some confusion as to what actually makes it unsafe (see <https://mail.python.org/pipermail/python-dev/2019-March/156778.html>). Before the discussion petered out, it looked like people were reaching a consensus "that mktemp() could be made secure by using a longer name generated by a secure random generator" (quoting from the previous link).

A secure `mktemp` could be as simple as (see <https://mail.python.org/pipermail/python-dev/2019-March/156765.html>):

```
def mktemp(suffix='', prefix='tmp', dir=None):
    if dir is None:
        dir = gettempdir()
    return _os.path.join(dir, prefix + secrets.token_urlsafe(ENTROPY_BYTES) + suffix)
```

There's been some discussion as to what `ENTROPY_BYTES` should be. I like Steven D'Aprano's suggestion (see <https://mail.python.org/pipermail/python-dev/2019-March/156777.html>) of having an overkill default just to be on the safe side, which can be overridden if needed. Of course, the security implications of lowering it should be clearly documented.

Fixing `mktemp` would make it possible to get rid of its hybrid deprecated (in the docs) / not depracated (in code) status, which is somewhat confusing for users. Speaking from experience -- when I realized I needed it, the deprecation notice led me down this rabbit hole of reading mailing list threads and submitting issues :) People could stop losing time worrying about `mktemp` and trying to weed it out whenever they come across it (see e.g. https://bugs.python.org/issue42278).

So I'm wondering whether there would be interest in:

1. A PR which would modify `mktemp` along the lines sketched above, to make it safe in practice. Along with that, it would probably make sense to undeprecate it in the docs, or at least indicate that while users should prefer `mkstemp` when they're fine with the file being created for them, `mktemp` is alright in cases where this is not acceptable.
2. Following that, possibly a PR which would encapsulate the new `mktemp` + `mkfifo` into a `TemporaryNamedPipe` or `TemporaryFifo`:

```
import os
import tempfile
import subprocess as sp

with tempfile.TemporaryNamedPipe() as fifo:
    proc = sp.Popen(["cat", fifo.name], stdout=sp.PIPE, text=True)
    for c in "Ko?ka leze d?rou, pes oknem.":
        print(c, file=fifo)
    proc.wait()

for l in proc.stdout:
    print(l.strip())
```

(Caveat: opening the FIFO for writing cannot happen in `__enter__`, it would have to be delayed until the first call to `fifo.write()` because it hangs if no one is reading from it.)

----------
components: Library (Lib)
messages: 389393
nosy: David Luke?
priority: normal
severity: normal
status: open
title: Fix tempfile.mktemp()
type: security
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43604>
_______________________________________

From report at bugs.python.org  Tue Mar 23 11:26:22 2021
From: report at bugs.python.org (Felix C. Stegerman)
Date: Tue, 23 Mar 2021 15:26:22 +0000
Subject: [issue43547] support ZIP files with zeroed out fields (e.g. for
 reproducible builds)
In-Reply-To: <1616102738.26.0.451702371832.issue43547@roundup.psfhosted.org>
Message-ID: <1616513182.97.0.261467025139.issue43547@roundup.psfhosted.org>


Felix C. Stegerman <flx at obfusk.net> added the comment:

> The __getattr__ hack is not needed. You can reset the flags in a different, more straight forward way

As mentioned, ZipFile._open_to_write() will modify the ZipInfo's .external_attr when it is set to 0.

> I just found another specific example in _open_to_write().  0 is a valid value for zinfo.external_attr.  But this code always forces 0 to something else:
>
>     if not zinfo.external_attr:
>         zinfo.external_attr = 0o600 << 16  # permissions: ?rw-------

Your alternative doesn't seem to take that subsequent modification into account.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43547>
_______________________________________

From report at bugs.python.org  Tue Mar 23 11:27:14 2021
From: report at bugs.python.org (miss-islington)
Date: Tue, 23 Mar 2021 15:27:14 +0000
Subject: [issue43573] [types] Document __spec__ for types.ModuleType
In-Reply-To: <1616289204.63.0.465511334804.issue43573@roundup.psfhosted.org>
Message-ID: <1616513234.66.0.258824605089.issue43573@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: +23750
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24992

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43573>
_______________________________________

From report at bugs.python.org  Tue Mar 23 11:27:53 2021
From: report at bugs.python.org (miss-islington)
Date: Tue, 23 Mar 2021 15:27:53 +0000
Subject: [issue43573] [types] Document __spec__ for types.ModuleType
In-Reply-To: <1616289204.63.0.465511334804.issue43573@roundup.psfhosted.org>
Message-ID: <1616513273.34.0.243284567308.issue43573@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +23751
pull_request: https://github.com/python/cpython/pull/24993

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43573>
_______________________________________

From report at bugs.python.org  Tue Mar 23 11:41:03 2021
From: report at bugs.python.org (=?utf-8?q?David_Luke=C5=A1?=)
Date: Tue, 23 Mar 2021 15:41:03 +0000
Subject: [issue43604] Fix tempfile.mktemp()
In-Reply-To: <1616513190.72.0.841940564849.issue43604@roundup.psfhosted.org>
Message-ID: <1616514063.52.0.708008091286.issue43604@roundup.psfhosted.org>


David Luke? <dafydd.lukes at gmail.com> added the comment:

> A secure `mktemp` could be as simple as ...

Though in practice, I'd rather be inclined to make the change in `tempfile._RandomNameSequence`, so as to get the same behavior across the entire module, instead of special-casing `mktemp`. As Guido van Rossum points out (see <https://mail.python.org/pipermail/python-dev/2019-March/156746.html>), that would improve the security of all the names generated by the `tempfile` module, not just `mktemp`:

> Hm, the random sequence (implemented in tempfile._RandomNameSequence) is
> currently derived from the random module, which is not cryptographically
> secure. Maybe all we need to do is replace its source of randomness with
> one derived from the secrets module. That seems a one-line change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43604>
_______________________________________

From report at bugs.python.org  Tue Mar 23 11:41:27 2021
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 23 Mar 2021 15:41:27 +0000
Subject: [issue43573] [types] Document __spec__ for types.ModuleType
In-Reply-To: <1616289204.63.0.465511334804.issue43573@roundup.psfhosted.org>
Message-ID: <1616514087.75.0.912213399282.issue43573@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
pull_requests: +23752
pull_request: https://github.com/python/cpython/pull/24994

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43573>
_______________________________________

From report at bugs.python.org  Tue Mar 23 12:43:00 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Mar 2021 16:43:00 +0000
Subject: [issue41718] test.regrtest has way too many imports
In-Reply-To: <1599233772.93.0.299899979889.issue41718@roundup.psfhosted.org>
Message-ID: <1616517780.03.0.615717515385.issue41718@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset d72e8d487553c103bf2742e229f8266b515fd951 by Victor Stinner in branch 'master':
bpo-41718: subprocess imports grp and pwd on demand (GH-24987)
https://github.com/python/cpython/commit/d72e8d487553c103bf2742e229f8266b515fd951


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41718>
_______________________________________

From report at bugs.python.org  Tue Mar 23 12:48:02 2021
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 23 Mar 2021 16:48:02 +0000
Subject: [issue35930] Raising an exception raised in a "future" instance will
 create reference cycles
In-Reply-To: <1549549530.21.0.398741964575.issue35930@roundup.psfhosted.org>
Message-ID: <1616518082.42.0.948341352951.issue35930@roundup.psfhosted.org>


Change by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
keywords: +patch
pull_requests: +23753
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24995

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35930>
_______________________________________

From report at bugs.python.org  Tue Mar 23 12:55:35 2021
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 23 Mar 2021 16:55:35 +0000
Subject: [issue35930] Raising an exception raised in a "future" instance will
 create reference cycles
In-Reply-To: <1549549530.21.0.398741964575.issue35930@roundup.psfhosted.org>
Message-ID: <1616518535.6.0.595119464907.issue35930@roundup.psfhosted.org>


Change by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
assignee:  -> jcea

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35930>
_______________________________________

From report at bugs.python.org  Tue Mar 23 12:55:46 2021
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 23 Mar 2021 16:55:46 +0000
Subject: [issue35930] Raising an exception raised in a "future" instance will
 create reference cycles
In-Reply-To: <1549549530.21.0.398741964575.issue35930@roundup.psfhosted.org>
Message-ID: <1616518546.39.0.579485262584.issue35930@roundup.psfhosted.org>


Change by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35930>
_______________________________________

From report at bugs.python.org  Tue Mar 23 13:01:05 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Mar 2021 17:01:05 +0000
Subject: [issue41718] test.regrtest has way too many imports
In-Reply-To: <1599233772.93.0.299899979889.issue41718@roundup.psfhosted.org>
Message-ID: <1616518865.6.0.367842472059.issue41718@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +23754
pull_request: https://github.com/python/cpython/pull/24996

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41718>
_______________________________________

From report at bugs.python.org  Tue Mar 23 13:20:30 2021
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 23 Mar 2021 17:20:30 +0000
Subject: [issue25716] typeobject.c call_method & call_maybe can leak
 references on 'func'
In-Reply-To: <1448318679.04.0.579867693106.issue25716@psf.upfronthosting.co.za>
Message-ID: <1616520030.06.0.395561146224.issue25716@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

I believe this issue is out of date. There are no longer such functions as call_method and call_maybe. There are vectorcall_method and vectorcall_maybe, but they don't have that check for (args == NULL).

----------
nosy: +iritkatriel
resolution:  -> out of date
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25716>
_______________________________________

From report at bugs.python.org  Tue Mar 23 13:26:04 2021
From: report at bugs.python.org (Bruno Loff)
Date: Tue, 23 Mar 2021 17:26:04 +0000
Subject: [issue43605] Issue of scopes unclear in documentation,
 or wrongly implemented
Message-ID: <1616520364.91.0.0936665126175.issue43605@roundup.psfhosted.org>


New submission from Bruno Loff <bruno.loff at gmail.com>:

Python 3.9.2 seems to be giving me some unexpected difficulty evaluating generators inside evals. Here is the example:

```python
def func(l):
    def get(i):
        return l[i]


    print(sum(get(i) for i in range(len(l)))) # works as expected, prints 10
    print(eval("get(0) + get(1) + get(2) + get(3)")) # works just fine, prints 10

    # if __globals is set to locals(), it still works, prints 10
    print(eval("sum(get(i) for i in range(len(l)))", locals()))

    # This will complain
    print(eval("sum(get(i) for i in range(len(l)))"))

func([1,2,3,4])
```

The last line gives the following error

```
Traceback (most recent call last):
  File "/something/test_eval.py", line 28, in <module>
    func([1,2,3,4])
  File "/something/test_eval.py", line 10, in func
    print(eval("sum(get(i) for i in range(len(l)))"))  # this does not work... bug?
  File "<string>", line 1, in <module>
  File "<string>", line 1, in <genexpr>

NameError: name 'get' is not defined
```

Any kind of generator-based code wont work. The following lines would give the same an error:
```
print(eval("sum(get(i) for i in range(len(l)))"), globals(), locals())
print(eval("[get(i) for i in range(len(l))]"))
print(eval("{i:get(i) for i in range(len(l))}"))
```


Any clue what is happening? The documentation on eval seems to give no insight on why this behavior is as is. This really feels like an issue, at the very least, it's an issue in the documentation.

----------
messages: 389397
nosy: bruno.loff
priority: normal
severity: normal
status: open
title: Issue of scopes unclear in documentation, or wrongly implemented
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43605>
_______________________________________

From report at bugs.python.org  Tue Mar 23 13:41:24 2021
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 23 Mar 2021 17:41:24 +0000
Subject: [issue43573] [types] Document __spec__ for types.ModuleType
In-Reply-To: <1616289204.63.0.465511334804.issue43573@roundup.psfhosted.org>
Message-ID: <1616521284.78.0.678332127052.issue43573@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/issue43573>
_______________________________________

From report at bugs.python.org  Tue Mar 23 13:43:01 2021
From: report at bugs.python.org (Thomas Kluyver)
Date: Tue, 23 Mar 2021 17:43:01 +0000
Subject: [issue37612] os.link(..., follow_symlinks=True) broken on Linux
In-Reply-To: <1563404695.9.0.284402565462.issue37612@roundup.psfhosted.org>
Message-ID: <1616521381.28.0.968594193046.issue37612@roundup.psfhosted.org>


Change by Thomas Kluyver <thomas at kluyver.me.uk>:


----------
nosy: +takluyver
nosy_count: 4.0 -> 5.0
pull_requests: +23755
pull_request: https://github.com/python/cpython/pull/24997

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37612>
_______________________________________

From report at bugs.python.org  Tue Mar 23 14:17:48 2021
From: report at bugs.python.org (C.A.M. Gerlach)
Date: Tue, 23 Mar 2021 18:17:48 +0000
Subject: [issue32592] Drop support of Windows Vista and Windows 7
In-Reply-To: <1516268238.05.0.467229070634.issue32592@psf.upfronthosting.co.za>
Message-ID: <1616523468.62.0.35940161371.issue32592@roundup.psfhosted.org>


C.A.M. Gerlach <CAM.Gerlach at Gerlach.CAM> added the comment:

In my limited understanding, all PR #15951 does is set a compiler macro to allow use of Win API calls present on >=Win8 instead of >=Win7. If Win8-only calls are not used, then presumably it should still build and run on Windows 7, presumably with the flag flipped back to Win7. And if there are Win8-only calls used and the flag is set to Win7+, I assume that the MSVC compiler will catch any instances of Win8-only calls at build time? Is this understanding correct?

If the latter is true, its very likely a lost cause. However, if the former is the case, then at least devs using Python 3.9+ on Windows 7 will be able to easily build their own versions with support, though that could change at any time. If the upside to supporting the latest Python versions on an EoL platform that is no longer receiving security updates but still has significant use is greater than the (seemingly pretty small) benefits of dropping support, then I imagine it would at least be conceivable to switch the flag back, though it probably is a lost cause now that a major version has been released without support and the buildbots have been presumably retired. At least third parties should be able to easily release patched versions, for now.

For those in the know, have there been a lot of reports/discontent surrounding the dropping of support in Py3.9, by anyone aware of that? 

However, I don't think it should be tied to the ESU date at all, as opposed to real-world usage of bleeding-edge Python on that version; ESU is a paid-only service for large corporate customers; if they're willing to pay through the nose for updates to their EoL OS and also need the latest bleeding-edge Python, surely they can fund the pittance required for maintenance or building it themselves.

All that said, I'll hold off on doing anything further until there's consensus. I'd think whatever we do it should be consistent, at least in the docs and installer; if dropping support in the code itself is more risk and pain than benefit, then that needn't be done.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32592>
_______________________________________

From report at bugs.python.org  Tue Mar 23 14:19:03 2021
From: report at bugs.python.org (Carl Anderson)
Date: Tue, 23 Mar 2021 18:19:03 +0000
Subject: [issue43520] Make Fraction(string) handle non-ascii slashes
In-Reply-To: <1615918144.03.0.939769511159.issue43520@roundup.psfhosted.org>
Message-ID: <1616523543.68.0.481294883188.issue43520@roundup.psfhosted.org>


Carl Anderson <carl.anderson at ww.com> added the comment:

>The proposal I like is for a unicode numeric normalization functions that return the ascii equivalent to exist.

@Gregory P. Smith 
this makes sense to me. That does feel like the cleanest solution. 
I'm currently doing s = s.replace("?","/") but it would be good to have a well-maintained normalization method that contained the all the relevant mappings as an independent preprocess step to Fraction would work well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43520>
_______________________________________

From report at bugs.python.org  Tue Mar 23 14:20:17 2021
From: report at bugs.python.org (Sergey B Kirpichev)
Date: Tue, 23 Mar 2021 18:20:17 +0000
Subject: [issue43602] Include Decimal's in numbers.Real
In-Reply-To: <1616504627.78.0.253653247438.issue43602@roundup.psfhosted.org>
Message-ID: <YFoxW+Q3cLpcUZxJ@note>


Sergey B Kirpichev <skirpichev at gmail.com> added the comment:

On Tue, Mar 23, 2021 at 01:03:47PM +0000, Mark Dickinson wrote:
> What do you think the result of `1.0 + Decimal(1)` should be, and
> more importantly why? Possible options are:
> 
> - Decimal('2')
> - 2.0 (a float)
> - a `TypeError` (as now)
> - some kind of horrible user-configurable-global-state-dependent answer

Decimal, with a some kind of "horrible
user-configurable-global-state-dependent answer" (Decimal
context): reverse conversion might be inexact.
Same, in principle, holds for 2-base multiprecision arithmetic
types like gmpy2.mpfr and mpmath.mpf.  "More powerfull data type,
claiming it implements numbers.Real - should know better."
That's the first option.

Maybe I (and authors of mentioned above packages) - do miss something
important.  (Oh, count on SageMath too.)
But do we have other examples of numbers.Real implementations (or
claiming to be such)?  If the numbers.Real does mean something like "only
python's builtin floats, but maybe with a different multiplication
algorithm" - that's hardly something that people may expect from
the docs.  Real numbers have a very specific mathematical meaning and
things like mpmath's mpf or Decimal fit this.

> Bear in mind that you have to pick a behaviour that's a good default
> choice for all potential application domains, and that's *hard*.

I think, that TypeError (a second option) might make sense too.  I'm not
sure that different implementations of numbers.Real must be interoperable (i.e.
without explicit conversions).  Such requirement clearly does make sense for
exact data types in the numerical tower (i.e. different
numbers.Rational implementations).

So, this implementation of the numbers tower:
  int (Integral) - Fraction (Rational) - float (Real) - complex (Complex)
doesn't look "more correct", than this:
  gmpy2.mpz - gmpy2.mpq - gmpy2.mpfr - gmpy2.mpc
regardless on how do "inexact" data types (e.g. float vs mpfr)
interoperate.  Same may be for the Decimal (but this is not a full tower):
  int - Fraction - Decimal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43602>
_______________________________________

From report at bugs.python.org  Tue Mar 23 14:23:12 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Mar 2021 18:23:12 +0000
Subject: [issue41718] test.regrtest has way too many imports
In-Reply-To: <1599233772.93.0.299899979889.issue41718@roundup.psfhosted.org>
Message-ID: <1616523792.31.0.231483514222.issue41718@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset bd9154a495434464283f74b660160f89930cd791 by Victor Stinner in branch 'master':
bpo-41718: runpy now imports pkgutil in functions (GH-24996)
https://github.com/python/cpython/commit/bd9154a495434464283f74b660160f89930cd791


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41718>
_______________________________________

From report at bugs.python.org  Tue Mar 23 14:49:53 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Mar 2021 18:49:53 +0000
Subject: [issue41718] test.regrtest has way too many imports
In-Reply-To: <1599233772.93.0.299899979889.issue41718@roundup.psfhosted.org>
Message-ID: <1616525393.36.0.947728710238.issue41718@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +23756
pull_request: https://github.com/python/cpython/pull/24998

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41718>
_______________________________________

From report at bugs.python.org  Tue Mar 23 14:50:58 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 23 Mar 2021 18:50:58 +0000
Subject: [issue43604] Fix tempfile.mktemp()
In-Reply-To: <1616513190.72.0.841940564849.issue43604@roundup.psfhosted.org>
Message-ID: <1616525458.11.0.863158637304.issue43604@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

You can use TemporaryDirectory.

with tempfile.TemporaryDirectory() as dir:
    fifo_path = os.path.join(dir, "fifo")
    os.mkfifo(fifo_path, 0o600)
    ...

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43604>
_______________________________________

From report at bugs.python.org  Tue Mar 23 15:06:15 2021
From: report at bugs.python.org (FRANK BENNETT)
Date: Tue, 23 Mar 2021 19:06:15 +0000
Subject: [issue43606] initial huge window  && no widgets visible
Message-ID: <1616526375.72.0.973402567023.issue43606@roundup.psfhosted.org>


New submission from FRANK BENNETT <fbennett78 at reagan.com>:

with any PySimpleGUI, tkinter, tk, *.py

The initial window is huge & with a size no widgets are visible

fwb at fw:/s/opt/cpython$ uname -r
5.4.0-67-generic

fwb at fw:/s/opt/cpython$ cat /etc/issue
Ubuntu 20.04.2 LTS \n \l

fwb at fw:/s/opt/cpython$ ./python -V
Python 3.10.0a6+fwb at fw:/s/opt/cpython$ cat .git/config 
[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
[remote "origin"]
        url = https://github.com/bennett78/cpython.git
        fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
        remote = origin
        merge = refs/heads/master


What sets initial window configuration ?

----------
components: Tkinter, Windows
files: t4.py
messages: 389403
nosy: bennett78, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: initial huge window  && no widgets visible
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49906/t4.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43606>
_______________________________________

From report at bugs.python.org  Tue Mar 23 15:22:44 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Mar 2021 19:22:44 +0000
Subject: [issue41718] test.regrtest has way too many imports
In-Reply-To: <1599233772.93.0.299899979889.issue41718@roundup.psfhosted.org>
Message-ID: <1616527364.15.0.32560632205.issue41718@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset cd27af70d58161c59072e27a10e0e63dcbf0bccb by Victor Stinner in branch 'master':
bpo-41718: Update runpy startup time What's New (GH-24998)
https://github.com/python/cpython/commit/cd27af70d58161c59072e27a10e0e63dcbf0bccb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41718>
_______________________________________

From report at bugs.python.org  Tue Mar 23 15:23:01 2021
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 23 Mar 2021 19:23:01 +0000
Subject: [issue39572] [typing] TypedDict's 'total' argument is undocumented
In-Reply-To: <1581019680.46.0.628292741765.issue39572@roundup.psfhosted.org>
Message-ID: <1616527381.38.0.70599810816.issue39572@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
nosy: +python-dev
nosy_count: 6.0 -> 7.0
pull_requests: +23757
pull_request: https://github.com/python/cpython/pull/24999

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39572>
_______________________________________

From report at bugs.python.org  Tue Mar 23 15:23:33 2021
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 23 Mar 2021 19:23:33 +0000
Subject: [issue31907] doc: Clarify error message when attempting to call
 function via str.format()
In-Reply-To: <1509410120.18.0.213398074469.issue31907@psf.upfronthosting.co.za>
Message-ID: <1616527413.12.0.0340823513551.issue31907@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

I would suggest the following change in https://docs.python.org/3/library/string.html#format-string-syntax

replace the sentence:

The syntax is related to that of formatted string literals, but there are differences.

by:

The syntax is related to that of formatted string literals, but it is less sophisticated and, in particular, does not support arbitrary expressions.

Is this accurate? Is it enough?

----------
nosy: +iritkatriel
title: Clarify error message when attempting to call function via str.format() -> doc: Clarify error message when attempting to call function via str.format()
versions: +Python 3.10 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31907>
_______________________________________

From report at bugs.python.org  Tue Mar 23 15:24:20 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Mar 2021 19:24:20 +0000
Subject: [issue41718] test.regrtest has way too many imports
In-Reply-To: <1599233772.93.0.299899979889.issue41718@roundup.psfhosted.org>
Message-ID: <1616527460.98.0.600129629284.issue41718@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Ok, the most important changes have been merged. Thanks everyone who helped on this large project! See also my summary email on python-dev:
https://mail.python.org/archives/list/python-dev at python.org/thread/I3OQTA3F66NQUN7CH2NHC5XZTO24QCIK/

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41718>
_______________________________________

From report at bugs.python.org  Tue Mar 23 15:35:25 2021
From: report at bugs.python.org (=?utf-8?q?David_Luke=C5=A1?=)
Date: Tue, 23 Mar 2021 19:35:25 +0000
Subject: [issue43604] Fix tempfile.mktemp()
In-Reply-To: <1616513190.72.0.841940564849.issue43604@roundup.psfhosted.org>
Message-ID: <1616528125.0.0.601103424918.issue43604@roundup.psfhosted.org>


David Luke? <dafydd.lukes at gmail.com> added the comment:

> You can use TemporaryDirectory.

That was actually the first approach I tried :) I even thought this could be used to make `mktemp` safe -- just create the name in a `TemporaryDirectory`.

However, after reading through the mailing list thread, I realized this just restricts the potential collision/hijacking to misbehaving/malicious processes running under the same user or under the super user. But the core problem with too easily guessable filenames (= not random enough, or not at all, as in your example) remains. Correct me if I'm wrong though.

Sorry, I should probably have mentioned this in OP. I thought about doing so, but then it turned out very long even without it, so I decided it would be better to discuss it only if someone else mentions it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43604>
_______________________________________

From report at bugs.python.org  Tue Mar 23 15:47:49 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Mar 2021 19:47:49 +0000
Subject: [issue43244] Move PyArena C API to the internal C API
In-Reply-To: <1613586690.19.0.383646964758.issue43244@roundup.psfhosted.org>
Message-ID: <1616528869.06.0.442950385036.issue43244@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 94faa0724f8cbae6867c491c8e465e35f4fdbfbb by Victor Stinner in branch 'master':
bpo-43244: Remove ast.h, asdl.h, Python-ast.h headers (GH-24933)
https://github.com/python/cpython/commit/94faa0724f8cbae6867c491c8e465e35f4fdbfbb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43244>
_______________________________________

From report at bugs.python.org  Tue Mar 23 15:58:39 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Mar 2021 19:58:39 +0000
Subject: [issue43244] Move PyArena C API to the internal C API
In-Reply-To: <1613586690.19.0.383646964758.issue43244@roundup.psfhosted.org>
Message-ID: <1616529519.5.0.894701182336.issue43244@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +23758
pull_request: https://github.com/python/cpython/pull/25000

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43244>
_______________________________________

From report at bugs.python.org  Tue Mar 23 16:28:04 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Mar 2021 20:28:04 +0000
Subject: [issue43244] Move PyArena C API to the internal C API
In-Reply-To: <1613586690.19.0.383646964758.issue43244@roundup.psfhosted.org>
Message-ID: <1616531284.51.0.840946107242.issue43244@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +23759
pull_request: https://github.com/python/cpython/pull/25001

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43244>
_______________________________________

From report at bugs.python.org  Tue Mar 23 16:37:55 2021
From: report at bugs.python.org (E. Paine)
Date: Tue, 23 Mar 2021 20:37:55 +0000
Subject: [issue43606] PySimpleGUI: initial huge window & no widgets visible
In-Reply-To: <1616526375.72.0.973402567023.issue43606@roundup.psfhosted.org>
Message-ID: <1616531875.43.0.88408106613.issue43606@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

I have removed the Windows component as the issue reported seems to be on Ubuntu (but I don't like removing others from the nosy, so have left that alone).

Tkinter does no initial window configuration created through either `Tk()` or `Toplevel()` as this is all handled by Tk (though I don't believe that would do the behaviour you describe). I cannot reproduce the issue (either with or without the 'size' argument) but suggest you take it up with the PySimpleGui team as they may be doing some custom configuration.

----------
components:  -Windows
nosy: +epaine, pau, serhiy.storchaka
title: initial huge window  && no widgets visible -> PySimpleGUI: initial huge window & no widgets visible

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43606>
_______________________________________

From report at bugs.python.org  Tue Mar 23 16:38:18 2021
From: report at bugs.python.org (E. Paine)
Date: Tue, 23 Mar 2021 20:38:18 +0000
Subject: [issue43606] PySimpleGUI: initial huge window & no widgets visible
In-Reply-To: <1616526375.72.0.973402567023.issue43606@roundup.psfhosted.org>
Message-ID: <1616531898.87.0.236769065928.issue43606@roundup.psfhosted.org>


Change by E. Paine <paineelisha at gmail.com>:


----------
nosy:  -pau

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43606>
_______________________________________

From report at bugs.python.org  Tue Mar 23 17:14:11 2021
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 23 Mar 2021 21:14:11 +0000
Subject: [issue43466] ssl/hashlib: Add configure option to set or auto-detect
 rpath to OpenSSL libs
In-Reply-To: <1615418043.46.0.229114131093.issue43466@roundup.psfhosted.org>
Message-ID: <1616534051.25.0.652698798815.issue43466@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +23760
pull_request: https://github.com/python/cpython/pull/25002

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43466>
_______________________________________

From report at bugs.python.org  Tue Mar 23 17:17:11 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 23 Mar 2021 21:17:11 +0000
Subject: [issue43602] Include Decimal's in numbers.Real
In-Reply-To: <1616481040.42.0.772549255299.issue43602@roundup.psfhosted.org>
Message-ID: <1616534231.94.0.545936923053.issue43602@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/issue43602>
_______________________________________

From report at bugs.python.org  Tue Mar 23 17:19:14 2021
From: report at bugs.python.org (Jacob Nilsson)
Date: Tue, 23 Mar 2021 21:19:14 +0000
Subject: [issue43535] Make str.join auto-convert inputs to strings.
In-Reply-To: <1616034546.27.0.0632217994438.issue43535@roundup.psfhosted.org>
Message-ID: <1616534354.63.0.844621785411.issue43535@roundup.psfhosted.org>


Jacob Nilsson <jacob.nilsson at ltu.se> added the comment:

For what my opinion is worth, I agree with Gr?gory's suggestion because the ',' part of ','.join(...) is almost as unintuitive as the problems Raymond's suggestions are trying to fix.

I was going to suggest a builtin to work on both str and bytes, like join(sep=None, strtype=str, *strings) but that interface looks pretty bad...

I think joinstr/joinbytes according to Gr?gory's suggestion (perhaps as classmethods of str/bytes?) would make the most sense.

----------
nosy: +ajoino

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43535>
_______________________________________

From report at bugs.python.org  Tue Mar 23 17:21:24 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 23 Mar 2021 21:21:24 +0000
Subject: [issue43535] Make str.join auto-convert inputs to strings.
In-Reply-To: <1616034546.27.0.0632217994438.issue43535@roundup.psfhosted.org>
Message-ID: <1616534484.63.0.614284284411.issue43535@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43535>
_______________________________________

From report at bugs.python.org  Tue Mar 23 17:56:21 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Tue, 23 Mar 2021 21:56:21 +0000
Subject: [issue20364] Rename & explain sqlite3.Cursor.execute 'parameters'
 param
In-Reply-To: <1390473779.26.0.463818219743.issue20364@psf.upfronthosting.co.za>
Message-ID: <1616536581.31.0.842377539127.issue20364@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


----------
keywords: +patch
nosy: +erlendaasland
nosy_count: 6.0 -> 7.0
pull_requests: +23761
pull_request: https://github.com/python/cpython/pull/25003

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20364>
_______________________________________

From report at bugs.python.org  Tue Mar 23 17:59:28 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Tue, 23 Mar 2021 21:59:28 +0000
Subject: [issue20364] Rename & explain sqlite3.Cursor.execute 'parameters'
 param
In-Reply-To: <1390473779.26.0.463818219743.issue20364@psf.upfronthosting.co.za>
Message-ID: <1616536768.94.0.757711385939.issue20364@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

Terry, I've created GH-25003 based on your suggested changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20364>
_______________________________________

From report at bugs.python.org  Tue Mar 23 18:00:53 2021
From: report at bugs.python.org (Jacob Nilsson)
Date: Tue, 23 Mar 2021 22:00:53 +0000
Subject: [issue43595] Can not add a metclass that inherits both ABCMeta & ABC
 to a Union
In-Reply-To: <1616421230.45.0.492887326456.issue43595@roundup.psfhosted.org>
Message-ID: <1616536853.79.0.514480339495.issue43595@roundup.psfhosted.org>


Jacob Nilsson <jacob.nilsson at ltu.se> added the comment:

Hi, I tried both code snippets, and they work for me with the output:

    typing.Union[str, abc.ABC]

For your second code snippet.

Tested on 3.7.6 (IPython though) on a Windows machine, can test it on Linux tomorrow.

----------
nosy: +ajoino

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43595>
_______________________________________

From report at bugs.python.org  Tue Mar 23 18:35:20 2021
From: report at bugs.python.org (Alexey Izbyshev)
Date: Tue, 23 Mar 2021 22:35:20 +0000
Subject: [issue32592] Drop support of Windows Vista and Windows 7
In-Reply-To: <1516268238.05.0.467229070634.issue32592@psf.upfronthosting.co.za>
Message-ID: <1616538920.13.0.469239575629.issue32592@roundup.psfhosted.org>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

> If Win8-only calls are not used, then presumably it should still build and run on Windows 7, presumably with the flag flipped back to Win7. And if there are Win8-only calls used and the flag is set to Win7+, I assume that the MSVC compiler will catch any instances of Win8-only calls at build time? Is this understanding correct?

It's the latter. In the patch, calls to functions like PathCchCanonicalizeEx(), which had previously been conditional on runtime availability of those functions, were made direct. Those functions are not from UCRT (so you can't just distribute it to regain Windows 7 support) and are not available in Windows 7.

There was also another patch that adds a check to Python 3.9+ installer that prevents installation on Windows 7 (but again, even if you take the Windows "embedded" distro instead of the installer, it won't run due to Win8-only functions).

> If the latter is true, its very likely a lost cause. However, if the former is the case, then at least devs using Python 3.9+ on Windows 7 will be able to easily build their own versions with support, though that could change at any time.

For now, it's not entirely lost cause in the sense that the number of Win8-specific patches and their size is very small (I'm not aware of anything not already mentioned, but I may be not up-to-date). So an interested party can probably revert them locally without much hassle.

> For those in the know, have there been a lot of reports/discontent surrounding the dropping of support in Py3.9, by anyone aware of that? 

I semi-casually follow the bug tracker and remember only bpo-41412 and bpo-42027.

Personally, I do consider tying of Windows support in CPython to arbitrary support periods set by Microsoft unfortunate, and it's also true that Win8-specific changes I'm aware of are not critical and don't remove any significant maintenance burden. For now, both relative and absolute usage of Windows 7 is huge and hard to ignore, so developers who use CPython in their own software are faced with an unpleasant choice of sticking to 3.8 or dropping Win 7. (I'm one of them since software I work on has to run in build environments setup for other projects, and such environments routinely stick to old OS versions due to breakage on updates). But this is what we have according to PEP 11, and a little grumbling here certainly won't change that :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32592>
_______________________________________

From report at bugs.python.org  Tue Mar 23 18:47:42 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 23 Mar 2021 22:47:42 +0000
Subject: [issue31861] add aiter() and anext() functions
In-Reply-To: <1508851575.6.0.213398074469.issue31861@psf.upfronthosting.co.za>
Message-ID: <1616539662.87.0.160194033611.issue31861@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset f0a6fde8827d5d4f7a1c741ab1a8b206b66ffd57 by Joshua Bronson in branch 'master':
bpo-31861: Add aiter and anext to builtins (#23847)
https://github.com/python/cpython/commit/f0a6fde8827d5d4f7a1c741ab1a8b206b66ffd57


----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31861>
_______________________________________

From report at bugs.python.org  Tue Mar 23 18:54:54 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 23 Mar 2021 22:54:54 +0000
Subject: [issue31861] add aiter() and anext() functions
In-Reply-To: <1508851575.6.0.213398074469.issue31861@psf.upfronthosting.co.za>
Message-ID: <1616540094.37.0.775890491973.issue31861@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/issue31861>
_______________________________________

From report at bugs.python.org  Tue Mar 23 18:56:49 2021
From: report at bugs.python.org (D Levine)
Date: Tue, 23 Mar 2021 22:56:49 +0000
Subject: [issue43607] urllib's request.pathname2url not compatible with
 extended-length Windows file paths
Message-ID: <1616540209.08.0.34606490658.issue43607@roundup.psfhosted.org>


New submission from D Levine <levineds at gmail.com>:

Windows file paths are limited to 256 characters, and one of Windows's prescribed methods to address this is to prepend "\\?\" before a Windows absolute path (see: https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation)

urllib.request.pathname2url raises an error on such paths as this function calls nturl2path.py's pathname2url function which explicitly checks that the number of characters before the ":" in a Windows path is precisely one, which is, of course, not the case if you are using an extended-length path (e.g. "\\?\C:\Python39").

As a result, urllib cannot handle pathname2url conversion for some valid Windows paths.

----------
components: Windows
messages: 389415
nosy: levineds, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: urllib's request.pathname2url not compatible with extended-length Windows file paths
type: crash
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43607>
_______________________________________

From report at bugs.python.org  Tue Mar 23 18:57:28 2021
From: report at bugs.python.org (D Levine)
Date: Tue, 23 Mar 2021 22:57:28 +0000
Subject: [issue43607] urllib's request.pathname2url not compatible with
 extended-length Windows file paths
In-Reply-To: <1616540209.08.0.34606490658.issue43607@roundup.psfhosted.org>
Message-ID: <1616540248.75.0.167055161406.issue43607@roundup.psfhosted.org>


Change by D Levine <levineds at gmail.com>:


----------
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43607>
_______________________________________

From report at bugs.python.org  Tue Mar 23 19:46:24 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 23 Mar 2021 23:46:24 +0000
Subject: [issue31861] add aiter() and anext() functions
In-Reply-To: <1508851575.6.0.213398074469.issue31861@psf.upfronthosting.co.za>
Message-ID: <1616543184.98.0.364201947879.issue31861@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
nosy: +pablogsal
nosy_count: 12.0 -> 13.0
pull_requests: +23762
pull_request: https://github.com/python/cpython/pull/25004

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31861>
_______________________________________

From report at bugs.python.org  Tue Mar 23 19:51:57 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Mar 2021 23:51:57 +0000
Subject: [issue43244] Move PyArena C API to the internal C API
In-Reply-To: <1613586690.19.0.383646964758.issue43244@roundup.psfhosted.org>
Message-ID: <1616543517.78.0.749788493688.issue43244@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset a81fca6ec8e0f748f8eafa12fb12cf9e12df465c by Victor Stinner in branch 'master':
bpo-43244: Add pycore_compile.h header file (GH-25000)
https://github.com/python/cpython/commit/a81fca6ec8e0f748f8eafa12fb12cf9e12df465c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43244>
_______________________________________

From report at bugs.python.org  Tue Mar 23 19:53:47 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 23 Mar 2021 23:53:47 +0000
Subject: [issue31861] add aiter() and anext() functions
In-Reply-To: <1508851575.6.0.213398074469.issue31861@psf.upfronthosting.co.za>
Message-ID: <1616543627.03.0.610023905878.issue31861@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +23763
pull_request: https://github.com/python/cpython/pull/25005

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31861>
_______________________________________

From report at bugs.python.org  Tue Mar 23 19:57:13 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 23 Mar 2021 23:57:13 +0000
Subject: [issue31861] add aiter() and anext() functions
In-Reply-To: <1508851575.6.0.213398074469.issue31861@psf.upfronthosting.co.za>
Message-ID: <1616543833.66.0.832821505123.issue31861@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset d9692027f41ee7600fe401c066617ebfc8bac930 by Pablo Galindo in branch 'master':
bpo-31861: Complete the C-API docs for PyObject_GetAiter and PyAiter_Check (GH-25004)
https://github.com/python/cpython/commit/d9692027f41ee7600fe401c066617ebfc8bac930


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31861>
_______________________________________

From report at bugs.python.org  Tue Mar 23 20:04:59 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 24 Mar 2021 00:04:59 +0000
Subject: [issue43452] Microoptimize PyType_Lookup for cache hits
In-Reply-To: <1615317677.24.0.232039554227.issue43452@roundup.psfhosted.org>
Message-ID: <1616544299.07.0.515020521674.issue43452@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset a054f6b2b1d9f75edfb5ec2247bbf60f07491977 by Pablo Galindo in branch 'master':
bpo-43452: Document the PyType_Lookup optimizations in the What's New for 3.10 (GH-24949)
https://github.com/python/cpython/commit/a054f6b2b1d9f75edfb5ec2247bbf60f07491977


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43452>
_______________________________________

From report at bugs.python.org  Tue Mar 23 20:29:17 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Mar 2021 00:29:17 +0000
Subject: [issue43244] Move PyArena C API to the internal C API
In-Reply-To: <1613586690.19.0.383646964758.issue43244@roundup.psfhosted.org>
Message-ID: <1616545757.75.0.0233505691844.issue43244@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 57364ce34e0492fbc8b0a6b8c882f384bb489457 by Victor Stinner in branch 'master':
bpo-43244: Remove parser_interface.h header file (GH-25001)
https://github.com/python/cpython/commit/57364ce34e0492fbc8b0a6b8c882f384bb489457


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43244>
_______________________________________

From report at bugs.python.org  Tue Mar 23 20:30:11 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 24 Mar 2021 00:30:11 +0000
Subject: [issue31861] add aiter() and anext() functions
In-Reply-To: <1508851575.6.0.213398074469.issue31861@psf.upfronthosting.co.za>
Message-ID: <1616545811.39.0.984156172941.issue31861@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 919d42d477093154a30b55d9d79f023dbbe5614a by Pablo Galindo in branch 'master':
bpo-31861: Fix possible crash in PyAnextAwaitable_New (GH-25005)
https://github.com/python/cpython/commit/919d42d477093154a30b55d9d79f023dbbe5614a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31861>
_______________________________________

From report at bugs.python.org  Tue Mar 23 20:32:52 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 24 Mar 2021 00:32:52 +0000
Subject: [issue41064] Specialise syntax error of **dict in f-string field
In-Reply-To: <1592742758.57.0.680300455155.issue41064@roundup.psfhosted.org>
Message-ID: <1616545972.23.0.674101627533.issue41064@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +23764
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25006

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41064>
_______________________________________

From report at bugs.python.org  Tue Mar 23 20:35:25 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 24 Mar 2021 00:35:25 +0000
Subject: [issue41064] Specialise syntax error of **dict in f-string field
In-Reply-To: <1592742758.57.0.680300455155.issue41064@roundup.psfhosted.org>
Message-ID: <1616546125.79.0.021707587485.issue41064@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> I don't recall if this is really only a "skip leading whitespace" problem, or if there's some other reason they're required.

IIRC, this forces the expression inside to be parsed as an expression. This helps the quite a lot the parser. For instance, detecting a bare **x without grouping is more difficult, even with the old parser. With parentheses it must be an expression so is easier to disambiguate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41064>
_______________________________________

From report at bugs.python.org  Tue Mar 23 20:43:47 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Mar 2021 00:43:47 +0000
Subject: [issue43244] Move PyArena C API to the internal C API
In-Reply-To: <1613586690.19.0.383646964758.issue43244@roundup.psfhosted.org>
Message-ID: <1616546627.94.0.996113391254.issue43244@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +23765
pull_request: https://github.com/python/cpython/pull/25007

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43244>
_______________________________________

From report at bugs.python.org  Tue Mar 23 21:04:38 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Mar 2021 01:04:38 +0000
Subject: [issue31861] add aiter() and anext() functions
In-Reply-To: <1508851575.6.0.213398074469.issue31861@psf.upfronthosting.co.za>
Message-ID: <1616547878.02.0.15711546107.issue31861@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I reopen the issue.

The commit f0a6fde8827d5d4f7a1c741ab1a8b206b66ffd57 introduced a reference leak:

$ ./python -m test -R 3:3 test_asyncgen

0:00:00 load avg: 4.75 Run tests sequentially
0:00:00 load avg: 4.75 [1/1] test_asyncgen
beginning 6 repetitions
123456
......
test_asyncgen leaked [72, 72, 72] references, sum=216
test_asyncgen leaked [30, 30, 30] memory blocks, sum=90
test_asyncgen failed

== Tests result: FAILURE ==

1 test failed:
    test_asyncgen

Total duration: 6.0 sec
Tests result: FAILURE

----------
nosy: +vstinner
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31861>
_______________________________________

From report at bugs.python.org  Tue Mar 23 21:19:20 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 24 Mar 2021 01:19:20 +0000
Subject: [issue31861] add aiter() and anext() functions
In-Reply-To: <1508851575.6.0.213398074469.issue31861@psf.upfronthosting.co.za>
Message-ID: <1616548760.07.0.775976180378.issue31861@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +23766
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/25008

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31861>
_______________________________________

From report at bugs.python.org  Tue Mar 23 21:23:08 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Mar 2021 01:23:08 +0000
Subject: [issue43244] Move PyArena C API to the internal C API
In-Reply-To: <1613586690.19.0.383646964758.issue43244@roundup.psfhosted.org>
Message-ID: <1616548988.78.0.154477588913.issue43244@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 8370e07e1e5b626e78ddc7aadbfaf248976c4454 by Victor Stinner in branch 'master':
bpo-43244: Remove the pyarena.h header (GH-25007)
https://github.com/python/cpython/commit/8370e07e1e5b626e78ddc7aadbfaf248976c4454


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43244>
_______________________________________

From report at bugs.python.org  Tue Mar 23 21:26:54 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Mar 2021 01:26:54 +0000
Subject: [issue43244] Move PyArena C API to the internal C API
In-Reply-To: <1613586690.19.0.383646964758.issue43244@roundup.psfhosted.org>
Message-ID: <1616549214.29.0.440703289798.issue43244@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Ok, the whole C API related to parser, compiler, AST, ASDL and PyArena moved to the internal C API. So we will have more freedom to evolve it!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43244>
_______________________________________

From report at bugs.python.org  Tue Mar 23 21:40:24 2021
From: report at bugs.python.org (FRANK BENNETT)
Date: Wed, 24 Mar 2021 01:40:24 +0000
Subject: [issue43606] PySimpleGUI: initial huge window & no widgets visible
In-Reply-To: <1616526375.72.0.973402567023.issue43606@roundup.psfhosted.org>
Message-ID: <1616550024.79.0.725239916679.issue43606@roundup.psfhosted.org>


FRANK BENNETT <fbennett78 at reagan.com> added the comment:

How about the following - title ok but no label visible ?

# t8.py
import tkinter as tk

class Application(tk.Tk):
    def __init__(self):
        tk.Tk.__init__(self)
        self.geometry('500x500')
        self.title('Your first App')

        first_label = tk.Label(self, text = "I'm a cool App!!", font=10, bg="black",fg="red" )
        first_label.pack(pady= 2, padx = 2)

app = Application()
app.mainloop()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43606>
_______________________________________

From report at bugs.python.org  Tue Mar 23 21:42:29 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 24 Mar 2021 01:42:29 +0000
Subject: [issue31861] add aiter() and anext() functions
In-Reply-To: <1508851575.6.0.213398074469.issue31861@psf.upfronthosting.co.za>
Message-ID: <1616550149.89.0.380129592091.issue31861@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset a02683ac38183fa3a45c32319dfd329c5e622f0e by Pablo Galindo in branch 'master':
bpo-31861: Fix reference leak in builtin_anext_impl() (GH-25008)
https://github.com/python/cpython/commit/a02683ac38183fa3a45c32319dfd329c5e622f0e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31861>
_______________________________________

From report at bugs.python.org  Tue Mar 23 21:43:07 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 24 Mar 2021 01:43:07 +0000
Subject: [issue31861] add aiter() and anext() functions
In-Reply-To: <1508851575.6.0.213398074469.issue31861@psf.upfronthosting.co.za>
Message-ID: <1616550187.68.0.736452654869.issue31861@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Fixed by PR25008

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31861>
_______________________________________

From report at bugs.python.org  Tue Mar 23 21:48:29 2021
From: report at bugs.python.org (Sebastian Berg)
Date: Wed, 24 Mar 2021 01:48:29 +0000
Subject: [issue43608] `bytes_concat` and Buffer cleanup
Message-ID: <1616550509.19.0.257186689995.issue43608@roundup.psfhosted.org>


New submission from Sebastian Berg <sebastian at sipsolutions.net>:

`pybytes_concate` currently uses the following code to get the data:

    va.len = -1;
    vb.len = -1;
    if (PyObject_GetBuffer(a, &va, PyBUF_SIMPLE) != 0 ||
        PyObject_GetBuffer(b, &vb, PyBUF_SIMPLE) != 0) {
        PyErr_Format(PyExc_TypeError, "can't concat %.100s to %.100s",
                     Py_TYPE(b)->tp_name, Py_TYPE(a)->tp_name);
        goto done;
    }

I don't actually know if it is realistically possible to issues here (I ended up here by chasing the wrong thing).  But this (and the identical code in `bytearray`) strictly rely on `view->len` not being modified on error (or else may not clean `va`)!

That seems wrong to me?  Although, I now saw that `PyBuffer_GetBuffer` says:

    If the exporter cannot provide a buffer of the exact type, it MUST raise PyExc_BufferError, set view->obj to NULL and return -1.

Pretty much all code in NumPy (and cpython as far as I can tell), will guarantee that `obj` (and `len` probably) is untouched on error, but it will not set it to NULL!

I can see some wisdom in NULL'ing `view->obj` since it means the caller can call `PyBuffer_Release` unconditionally (but then we have to explicitly do that!).  But realistically, it seems to me the realistic thing is to say that a caller must never release an unexported buffer and make no assumption about its content?

(Which doesn't mean I won't ensure NumPy will keep `len` and `obj` unmodified or NULL `obj` on error.)

----------
components: C API
messages: 389428
nosy: seberg
priority: normal
severity: normal
status: open
title: `bytes_concat` and Buffer cleanup
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43608>
_______________________________________

From report at bugs.python.org  Tue Mar 23 22:14:47 2021
From: report at bugs.python.org (midori)
Date: Wed, 24 Mar 2021 02:14:47 +0000
Subject: [issue43609] ast.unparse-ing a FunctionType gives ambiguous result
Message-ID: <1616552087.93.0.261462178392.issue43609@roundup.psfhosted.org>


New submission from midori <cleoold at member.fsf.org>:

Hi all, this is probably my first issue here, so don't blame me if I do something wrong lol

The ast.FunctionType gives syntax like (a, b) -> c for function types, this is ok, and also since Python 3.10 we can use X | Y to denote unions, this is ok. So Given the following two trees:

fun1 = ast.FunctionType(
    argtypes=[],
    returns=ast.BinOp(
        left=ast.Name(id='int'),
        op=ast.BitOr(),
        right=ast.Name(id='float'),
    )
)
fun2 = ast.BinOp(
    left=ast.FunctionType(
        argtypes=[],
        returns=ast.Name(id='int'),
    ),
    op=ast.BitOr(),
    right=ast.Name(id='float'),
)

Calling:

print(ast.unparse(fun1))
print(ast.unparse(fun2))

The results are these:

() -> int | float
() -> int | float

So there is some ambiguity. By feeding this string to ast.parse(mode='func_type'), I know that it means "returning a union".

Don't know if there is any impact to simply add a pair of parens, or does this problem even matters at all.

I tested it using Python 3.10 a6 and Python 3.9.2.

----------
components: Library (Lib)
messages: 389429
nosy: Batuhan Taskaya, cleoold
priority: normal
severity: normal
status: open
title: ast.unparse-ing a FunctionType gives ambiguous result
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43609>
_______________________________________

From report at bugs.python.org  Tue Mar 23 22:54:50 2021
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 24 Mar 2021 02:54:50 +0000
Subject: [issue43607] urllib's request.pathname2url not compatible with
 extended-length Windows file paths
In-Reply-To: <1616540209.08.0.34606490658.issue43607@roundup.psfhosted.org>
Message-ID: <1616554490.47.0.576104865169.issue43607@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

RFC8089 doesn't specify "a mechanism for translating namespaced paths ["\\?\" and "\\.\"] to or from file URIs", and the Windows shell doesn't support them. So what's the practical benefit of supporting them in nturl2path?

> Windows file paths are limited to 256 characters,

Classically, normal filepaths are limited to MAX_PATH - 1 (259) characters, in most cases, except for a few cases in which the limit is even smaller. 

For a normal filepath, the API replaces slashes with backlashes; resolves relative paths; resolves "." and ".." components; strips trailing dots and spaces from the final path component; and, for relative paths and DOS drive-letter paths, reserves DOS device names in the final path component (e.g. CON, NUL). 

The kernel supports filepaths with up to 32,767 characters, but classically this was only accessible by using a verbatim \\?\ filepath, or by using workarounds based on substitute drives or filesystem mountpoints and symlinks.

With Python 3.6+ in Windows 10, if long paths are enabled in the system, normal filepaths support up to the full 32,767 characters in most cases. The need for the \\?\ prefix is thus limited to the rare case when a verbatim path is required, or when a filepath has to be passed to a legacy application that doesn't support long paths.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43607>
_______________________________________

From report at bugs.python.org  Tue Mar 23 23:04:29 2021
From: report at bugs.python.org (Xinmeng Xia)
Date: Wed, 24 Mar 2021 03:04:29 +0000
Subject: [issue43610] Ctrl C makes interpreter exit
Message-ID: <1616555069.73.0.540309240427.issue43610@roundup.psfhosted.org>


New submission from Xinmeng Xia <xiaxm at smail.nju.edu.cn>:

Python interpreter will exit when using Ctrl C to interrupt some Python module functions with read operations. e.g.  sndhdr.what(0), pdb.find_function('abs/'*100000,False), mimetypes.read_mime_types(0).  This is not the expected behavior.  Ctrl C is to raise a KeyboardInterrupt, it should not crash Python and make interpreter exit.

Reproduce:
1. type 'python3' in command console;
2. type 'import sndhdr;sndhdr.what(0)'
3. type ctrl C

Expected behavior:  type ctrl c, raise a KeyboardInterrupt,  Python does not exit.
========================================
xxm at xxm-System-Product-Name:~$ python
Python 3.9.2 (default, Mar 12 2021, 15:08:35)
[GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>
KeyboardInterrupt
>>>
========================================

Unexpected behavior:  type ctrl c, raise a KeyboardInterrupt, Python exits.
===========================================================
xxm at xxm-System-Product-Name:~$ python
Python 3.9.2 (default, Mar 12 2021, 15:08:35)
[GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sndhdr;sndhdr.what(0)
^CTraceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/xxm/Desktop/apifuzz/Python-3.9.2/Lib/sndhdr.py", line 54, in what
    res = whathdr(filename)
  File "/home/xxm/Desktop/apifuzz/Python-3.9.2/Lib/sndhdr.py", line 61, in whathdr
    h = f.read(512)
KeyboardInterrupt
>>>

xxm at xxm-System-Product-Name:~$
===========================================================

System: Ubuntu 16.04

----------
components: Library (Lib)
messages: 389431
nosy: xxm
priority: normal
severity: normal
status: open
title: Ctrl C makes interpreter exit
type: crash
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43610>
_______________________________________

From report at bugs.python.org  Tue Mar 23 23:12:58 2021
From: report at bugs.python.org (D Levine)
Date: Wed, 24 Mar 2021 03:12:58 +0000
Subject: [issue43607] urllib's request.pathname2url not compatible with
 extended-length Windows file paths
In-Reply-To: <1616540209.08.0.34606490658.issue43607@roundup.psfhosted.org>
Message-ID: <1616555578.57.0.536712343111.issue43607@roundup.psfhosted.org>


D Levine <levineds at gmail.com> added the comment:

I really meant 255 characters not 256 because I was leaving three for "<drive name>:/". I suppose the most reasonable behavior is to strip out the "\\?\" before attempting the conversion as the path is sensible and parsable without that, as opposed to the current behavior which is to  crash. The practical benefit is to permit the function to work on a wider range of inputs than currently is possible for essentially no cost.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43607>
_______________________________________

From report at bugs.python.org  Tue Mar 23 23:26:21 2021
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 24 Mar 2021 03:26:21 +0000
Subject: [issue43607] urllib's request.pathname2url not compatible with
 extended-length Windows file paths
In-Reply-To: <1616540209.08.0.34606490658.issue43607@roundup.psfhosted.org>
Message-ID: <1616556381.5.0.865709114708.issue43607@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> I suppose the most reasonable behavior is to strip out the "\\?\" before 
> attempting the conversion as the path is sensible and parsable without 

Okay, so you're not looking to preserve the fact that it's a \\?\ verbatim path in the URI. You just want to automatically convert from verbatim \\?\X: or \\?\UNC\server\share to normal form. Devices other than drive letters and "UNC" wouldn't be supported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43607>
_______________________________________

From report at bugs.python.org  Tue Mar 23 23:30:39 2021
From: report at bugs.python.org (D Levine)
Date: Wed, 24 Mar 2021 03:30:39 +0000
Subject: [issue43607] urllib's request.pathname2url not compatible with
 extended-length Windows file paths
In-Reply-To: <1616540209.08.0.34606490658.issue43607@roundup.psfhosted.org>
Message-ID: <1616556639.68.0.566011549242.issue43607@roundup.psfhosted.org>


D Levine <levineds at gmail.com> added the comment:

I think that would make the most sense, yes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43607>
_______________________________________

From report at bugs.python.org  Tue Mar 23 23:38:42 2021
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 24 Mar 2021 03:38:42 +0000
Subject: [issue43610] Ctrl C makes interpreter exit
In-Reply-To: <1616555069.73.0.540309240427.issue43610@roundup.psfhosted.org>
Message-ID: <1616557122.5.0.55120574231.issue43610@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> Python interpreter will exit when using Ctrl C to interrupt 
> some Python module functions with read operations. 

The REPL exits when stdin is closed. open() allows the filename to be an existing file descriptor without requiring a parameter such as "file_is_fd". So it's really simple to accidentally close stdin with something like `with open(0): pass`. The only role of Ctrl+C here is in canceling a blocking operation in the context such as a read(), after which the file is guaranteed to be closed by the context manager protocol.

----------
nosy: +eryksun
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43610>
_______________________________________

From report at bugs.python.org  Wed Mar 24 01:36:13 2021
From: report at bugs.python.org (Xinmeng Xia)
Date: Wed, 24 Mar 2021 05:36:13 +0000
Subject: [issue43611] Function tcflow() in module termios can not be
 interupted when the second argument is 0
Message-ID: <1616564173.74.0.426077496185.issue43611@roundup.psfhosted.org>


New submission from Xinmeng Xia <xiaxm at smail.nju.edu.cn>:

In Ubuntu 16.04, termios.tcflow(1, 0) cannot be interrupted by Ctrl C, Ctrl D, Ctrl Z.   
It work well on mac OS. (Ctrl C can interrupt it on Mac OS).

Reproduce:
1. type 'python3' in command console;
2. type ?import termios; termios.tcflow(1, 0)?
3. try ?ctrl C?, ?Ctrl D?, ?Ctrl Z?



=========================================================================
xxm at xxm-System-Product-Name:~$ '/home/xxm/Desktop/apifuzz/Python-3.10.0a6/python' 
Python 3.10.0a6 (default, Mar 19 2021, 11:45:56) [GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import termios
>>> termios.tcflow(1, 0)

=========================================================================
Expected result: this function can be interrupted or stopped by Ctrl C, Ctrl D, Ctrl Z.

Actual result: No response for Ctrl C, Ctrl D, Ctrl Z

System Ubuntu 16.04

----------
components: Library (Lib)
messages: 389436
nosy: xxm
priority: normal
severity: normal
status: open
title: Function tcflow() in module termios can not be interupted when the second argument is 0
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43611>
_______________________________________

From report at bugs.python.org  Wed Mar 24 02:04:20 2021
From: report at bugs.python.org (Ruben Vorderman)
Date: Wed, 24 Mar 2021 06:04:20 +0000
Subject: [issue43612] zlib.compress should have a wbits argument
Message-ID: <1616565860.52.0.251244097489.issue43612@roundup.psfhosted.org>


New submission from Ruben Vorderman <r.h.p.vorderman at lumc.nl>:

zlib.compress can now only be used to output zlib blocks.
Arguably `zlib.compress(my_data, level, wbits=-15)` is even more useful as it gives you a raw deflate block. That is quite interesting if you are writing your own file format and want to use compression, but like to use a different hash.

Also gzip.compress(data, level, mtime) is extremely slow due to it instantiating a GzipFile object which then streams a bytes object. Explicitly not taking advantage of the fact that the bytes object is entirely in memory already (I will create another bug for this). zlib.compress(my_data, level, wbits=31) should be faster in all possible circumstances, but that option is not available now.

----------
components: Library (Lib)
messages: 389437
nosy: rhpvorderman
priority: normal
severity: normal
status: open
title: zlib.compress should have a wbits argument
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43612>
_______________________________________

From report at bugs.python.org  Wed Mar 24 02:18:39 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 24 Mar 2021 06:18:39 +0000
Subject: [issue43198] One operation on sets < 1/100th as efficient in 3.9 than
 before
In-Reply-To: <1613002507.49.0.48232719319.issue43198@roundup.psfhosted.org>
Message-ID: <1616566719.24.0.760262402772.issue43198@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
keywords: +patch
pull_requests: +23767
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/25010

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43198>
_______________________________________

From report at bugs.python.org  Wed Mar 24 02:27:19 2021
From: report at bugs.python.org (Ruben Vorderman)
Date: Wed, 24 Mar 2021 06:27:19 +0000
Subject: [issue43613] gzip.compress and gzip.decompress are sub-optimally
 implemented.
Message-ID: <1616567239.03.0.950381696666.issue43613@roundup.psfhosted.org>


New submission from Ruben Vorderman <r.h.p.vorderman at lumc.nl>:

When working on python-isal which aims to provide faster drop-in replacements for the zlib and gzip modules I found that the gzip.compress and gzip.decompress are suboptimally implemented which hurts performance.

gzip.compress and gzip.decompress both do the following things:
- Instantiate a BytesIO object to mimick a file
- Instantiate a GzipFile object to compress or read the file.

That means there is way more Python code involved than strictly necessary. Also the 'data' is already fully in memory, but the data is streamed anyway. That is quite a waste.

I propose the following:
- The documentation should make it clear that zlib.decompress(... ,wbits=31) and zlib.compress(..., wbits=31) (after 43612 has been addressed), are both quicker but come with caveats. zlib.compress can not set mtime. zlib.decompress does not take multimember gzip into account. 
- For gzip.compress -> The GzipFile._write_gzip_header function should be moved to a module wide _gzip_header function that returns a bytes object. GzipFile._write_gzip_header can call this function. gzip.compress can also call this function to create a header. gzip.compress than calls zlib.compress(data, wbits=-15) (after 43612 has been fixed) to create a raw deflate block. A gzip trailer can be easily created by calling zlib.crc32(data) and len(data) & 0xffffffff and packing those into a struct. See for an example implementation here: https://github.com/pycompression/python-isal/blob/v0.8.0/src/isal/igzip.py#L242
-> For gzip.decompress it becomes quite more involved. A read_gzip_header function can be created, but the current implementation returns EOFErrors if the header is incomplete due to a truncated file instead of BadGzipFile errors. This makes it harder to implement something that is not a major break from current gzip.decompress. Apart from the header, the implementation is straightforward. Do a while true loop. All operations are performed in the loop. Validate the header and report the end of the header. Create a zlib.decompressobj(wbits=-15). Decompress all the data from the end of header. Flush. Extract the crc and length from the first 8 bytes of the unused data. data = decompobj.unused_data[8:]. if not data: break. For a reference implementation check here: https://github.com/pycompression/python-isal/blob/v0.8.0/src/isal/igzip.py#L300. Note that the decompress function is quite straightforward. Checking the header however while maintaining backwards compatibility with gzip.decompress is not so simple.

And that brings to another point. Should non-descriptive EOFErrors be raised when reading the gzip header? Or throw informative BadGzipFile errors when the header is parsed. I tend towards the latter. For example BadGzipFile("Truncated header") instead of EOFError. Or at least EOFError("Truncated gzip header"). I am aware that confounds this issue with another issue, but these things are coupled in the implementation so both need to be solved at the same time.

Given the headaches that gzip.decompress gives it might be easier to solve gzip.compress first in a first PR and do gzip.decompress later.

----------
messages: 389438
nosy: rhpvorderman
priority: normal
severity: normal
status: open
title: gzip.compress and gzip.decompress are sub-optimally implemented.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43613>
_______________________________________

From report at bugs.python.org  Wed Mar 24 02:56:11 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 24 Mar 2021 06:56:11 +0000
Subject: [issue43613] gzip.compress and gzip.decompress are sub-optimally
 implemented.
In-Reply-To: <1616567239.03.0.950381696666.issue43613@roundup.psfhosted.org>
Message-ID: <1616568971.49.0.23212256049.issue43613@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/issue43613>
_______________________________________

From report at bugs.python.org  Wed Mar 24 04:23:34 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 24 Mar 2021 08:23:34 +0000
Subject: [issue42914] pprint numbers with underscore
In-Reply-To: <1610493681.29.0.683565759752.issue42914@roundup.psfhosted.org>
Message-ID: <1616574214.75.0.149904465114.issue42914@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:


New changeset 3ba3d513b1e3c63d09cb798b982a9e6c369cea4c by sblondon in branch 'master':
bpo-42914: add a pprint underscore_numbers option (GH-24864)
https://github.com/python/cpython/commit/3ba3d513b1e3c63d09cb798b982a9e6c369cea4c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42914>
_______________________________________

From report at bugs.python.org  Wed Mar 24 04:28:50 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 24 Mar 2021 08:28:50 +0000
Subject: [issue42914] pprint numbers with underscore
In-Reply-To: <1610493681.29.0.683565759752.issue42914@roundup.psfhosted.org>
Message-ID: <1616574530.93.0.362836111157.issue42914@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

Thanks for the contribution St?phane!

I agree that this would be a nice default.  We're just being conservative in the pace of default behavior changes.  Changing the default could be considered in the future after a few releases with this parameter have shipped.

----------
resolution:  -> fixed
stage: patch review -> commit review
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42914>
_______________________________________

From report at bugs.python.org  Wed Mar 24 04:43:53 2021
From: report at bugs.python.org (Ruben Vorderman)
Date: Wed, 24 Mar 2021 08:43:53 +0000
Subject: [issue43612] zlib.compress should have a wbits argument
In-Reply-To: <1616565860.52.0.251244097489.issue43612@roundup.psfhosted.org>
Message-ID: <1616575433.1.0.53568817802.issue43612@roundup.psfhosted.org>


Change by Ruben Vorderman <r.h.p.vorderman at lumc.nl>:


----------
keywords: +patch
pull_requests: +23768
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25011

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43612>
_______________________________________

From report at bugs.python.org  Wed Mar 24 04:44:19 2021
From: report at bugs.python.org (Ruben Vorderman)
Date: Wed, 24 Mar 2021 08:44:19 +0000
Subject: [issue43612] zlib.compress should have a wbits argument
In-Reply-To: <1616565860.52.0.251244097489.issue43612@roundup.psfhosted.org>
Message-ID: <1616575459.39.0.561229536174.issue43612@roundup.psfhosted.org>


Change by Ruben Vorderman <r.h.p.vorderman at lumc.nl>:


----------
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43612>
_______________________________________

From report at bugs.python.org  Wed Mar 24 04:44:31 2021
From: report at bugs.python.org (Ruben Vorderman)
Date: Wed, 24 Mar 2021 08:44:31 +0000
Subject: [issue43613] gzip.compress and gzip.decompress are sub-optimally
 implemented.
In-Reply-To: <1616567239.03.0.950381696666.issue43613@roundup.psfhosted.org>
Message-ID: <1616575471.28.0.199996541499.issue43613@roundup.psfhosted.org>


Change by Ruben Vorderman <r.h.p.vorderman at lumc.nl>:


----------
type:  -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43613>
_______________________________________

From report at bugs.python.org  Wed Mar 24 06:41:43 2021
From: report at bugs.python.org (Hans-Christoph Steiner)
Date: Wed, 24 Mar 2021 10:41:43 +0000
Subject: [issue43547] support ZIP files with zeroed out fields (e.g. for
 reproducible builds)
In-Reply-To: <1616102738.26.0.451702371832.issue43547@roundup.psfhosted.org>
Message-ID: <1616582503.72.0.333977597851.issue43547@roundup.psfhosted.org>


Hans-Christoph Steiner <hans at eds.org> added the comment:

> - For full reproducible builds you may have to write files to zipfiles in a well-defined order.

That already works fine now, we've been doing that with Python for years.  But that leaves it up to the implemented to do.  I suppose zipfile could provide a method to sort entries, but that's out of scope for this issue IMHO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43547>
_______________________________________

From report at bugs.python.org  Wed Mar 24 07:12:48 2021
From: report at bugs.python.org (Anthony Flury)
Date: Wed, 24 Mar 2021 11:12:48 +0000
Subject: [issue43614] Search is not beginner friendly
Message-ID: <1616584368.72.0.108883750732.issue43614@roundup.psfhosted.org>


New submission from Anthony Flury <anthony.flury at btinternet.com>:

A commonly asked question on Quora is 'What do *args and **kwargs' mean ?

While it is relatively easy for community to answer these questions the search tool on the standard documentation doesn't make it easy.

I understand that 'args' and 'kwargs' are both naming conventions, they are very common across the documentation, but searching on '*args' or '**kwargs' doesn't actually find anything useful - it certainly doesn't place 'https://docs.python.org/3/tutorial/controlflow.html#arbitrary-argument-lists' at or close to the top of the list.

It is my view that the documentation should be beginner friendly, but in this case (and many other I guess) you have to know what to search for to find something useful.

I note that even common phrases in Computing (such as 'variable arguments' or 'variable parameters') don't find anything useful. The term 'variadic' does find the relevant page, but the link displayed in the search results lands on the page (but not the relevant section) - and many beginners wont search for 'variadic'.

The index and search need to be improved to help beginners - specifically in this case
* Search Index should include common conventional names (such as args, kwargs)
* Search Index should include common computing terms ('variable arguments' for example - even if the documentation doesn't actually use that terminology).
* Search should link to the relevant section (and not just the page).

----------
assignee: docs at python
components: Documentation
messages: 389442
nosy: anthony-flury, docs at python
priority: normal
severity: normal
status: open
title: Search is not beginner friendly
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43614>
_______________________________________

From report at bugs.python.org  Wed Mar 24 07:30:31 2021
From: report at bugs.python.org (E. Paine)
Date: Wed, 24 Mar 2021 11:30:31 +0000
Subject: [issue43606] PySimpleGUI: initial huge window & no widgets visible
In-Reply-To: <1616526375.72.0.973402567023.issue43606@roundup.psfhosted.org>
Message-ID: <1616585431.26.0.660335059261.issue43606@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

That example also works on my setup (see attached). The only reason I could think that your label is not showing is that the font given is not of a valid format (see https://www.tcl.tk/man/tcl8.6/TkCmd/font.htm#M13), though I would have thought this would raise a TclError.

Please confirm what platform and Python version you are using as well as the output of `tkinter.test.support.get_tk_patchlevel()`.

----------
Added file: https://bugs.python.org/file49907/working example.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43606>
_______________________________________

From report at bugs.python.org  Wed Mar 24 07:36:43 2021
From: report at bugs.python.org (E. Paine)
Date: Wed, 24 Mar 2021 11:36:43 +0000
Subject: [issue43606] PySimpleGUI: initial huge window & no widgets visible
In-Reply-To: <1616526375.72.0.973402567023.issue43606@roundup.psfhosted.org>
Message-ID: <1616585803.45.0.817170045892.issue43606@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

Apologies, you did give the platform and Python version. I presume you are compiling the master branch, in which case do you have the 'tk8.6-dev' package installed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43606>
_______________________________________

From report at bugs.python.org  Wed Mar 24 07:55:28 2021
From: report at bugs.python.org (Steve Dower)
Date: Wed, 24 Mar 2021 11:55:28 +0000
Subject: [issue32592] Drop support of Windows Vista and Windows 7
In-Reply-To: <1516268238.05.0.467229070634.issue32592@psf.upfronthosting.co.za>
Message-ID: <1616586928.79.0.910960491873.issue32592@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

FWIW, the installer change was only to forcibly warn naive users that they need to stick with the previous version, so I wouldn't read much into it. It's easily rolled back.

The real issue is that we need to decide how to drop support _somehow_, and following the company that has the most to gain/lose from declaring support for one of their platforms makes the most sense.

If we had a dedicated maintainer who was supporting Win7 and making releases for it, then we (i.e. they) could support it. But then, there's nothing to stop someone doing that already, and even to stop them charging money for it if they want (which they wouldn't be able to do under the auspices of python-dev). So I suspect nobody is really that motivated ;)

(Also, a "little bit of complaining" here is totally worthwhile, as it helps us gauge community sentiment. Without it, we're limited to trawling forums and Twitter - especially without conferences to actually meet and hear directly from people - and so our inputs are biased. Having polite, informed, discussion on the tracker is a great way for us to see and capture these positions.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32592>
_______________________________________

From report at bugs.python.org  Wed Mar 24 08:06:14 2021
From: report at bugs.python.org (Thomas Wamm)
Date: Wed, 24 Mar 2021 12:06:14 +0000
Subject: [issue43511] tkinter with Tk 8.6.11 is slow on macOS
In-Reply-To: <1615875194.4.0.35991043769.issue43511@roundup.psfhosted.org>
Message-ID: <1616587574.23.0.244911236317.issue43511@roundup.psfhosted.org>


Thomas Wamm <thomaswamm at gmail.com> added the comment:

I ran the bench.py and bench.tcl programs from E. Paine (epaine) on my M1 Mac Mini.  Attached is a commented Terminal transcript.

The tl;dr summary again is that Python 3.10.0a6 arm64 for Apple silicon is 3 to 100 times SLOWER than earlier pythons compiled for Intel x86-64 running with Rosetta2, when doing window operations thru Tcl/Tk.

I have not yet attempted to install any version of Tcl/Tk independent of any Python or Apple build.  I'm still learning slowly.  And I am inspired to re-jig my little TerraLunar graphics program to run with python2.7 arm64.

----------
Added file: https://bugs.python.org/file49908/results-tkbench.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43511>
_______________________________________

From report at bugs.python.org  Wed Mar 24 08:17:49 2021
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 24 Mar 2021 12:17:49 +0000
Subject: [issue43511] tkinter with Tk 8.6.11 is slow on macOS
In-Reply-To: <1615875194.4.0.35991043769.issue43511@roundup.psfhosted.org>
Message-ID: <1616588269.34.0.778211335943.issue43511@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

If this is a Tk issue we should report it in their bug tracker.

I'm definitely against switching to an older version of Tk, the most recent release fixes a lot of problems with Tk on macOS.  Correctness before performance.

How bad is the performance compared to Tk on other platforms (with similar hardware)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43511>
_______________________________________

From report at bugs.python.org  Wed Mar 24 08:37:11 2021
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 24 Mar 2021 12:37:11 +0000
Subject: [issue43511] tkinter with Tk 8.6.11 is slow on macOS
In-Reply-To: <1615875194.4.0.35991043769.issue43511@roundup.psfhosted.org>
Message-ID: <1616589431.59.0.488987732333.issue43511@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

One thing to look into: there appears to be a tk 8.6.11.1 release, I have no idea what changed in this micro release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43511>
_______________________________________

From report at bugs.python.org  Wed Mar 24 08:44:09 2021
From: report at bugs.python.org (=?utf-8?b?TWl0amEga29jamFuxI1pxI0=?=)
Date: Wed, 24 Mar 2021 12:44:09 +0000
Subject: [issue32592] Drop support of Windows Vista and Windows 7
In-Reply-To: <1516268238.05.0.467229070634.issue32592@psf.upfronthosting.co.za>
Message-ID: <1616589849.28.0.296080980364.issue32592@roundup.psfhosted.org>


Mitja kocjan?i? <veso266 at gmail.com> added the comment:

not sure about the strategies here but maybe a better approach would be to kill support for unsupported version of windows in a major release
since I guess python 3 was a complete rewrite of python2 (at least the low level side I assume it was) 

and it would be easier for people to remeber (eg, if I have to rewrite my app because python4 has a major language differences I might as well drop support for older OSes in it), eg, python2 works on XP, python3 works on vista and up, python4 works on windows 10

for instance, I didn't even know you can run python3 on XP, I always thought that python2.7 is the last version that would run there

and since the code to support windows 7 is still present (almost, just the installer change would need to be rolleed back and some compiler declaratives: 
https://github.com/python/cpython/commit/0b72ccff56fb47e14f7b1f6590eafff8d104c229
https://github.com/izbyshev/cpython/commit/6a65eba44bfd82ccc8bed4b5c6dd6637549955d5

I see no reason to touch it (it probably just stays there serving its purpose) and when python4 comes along (if its a rewrite then windows 7 hacks (would just not be written anymore)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32592>
_______________________________________

From report at bugs.python.org  Wed Mar 24 08:50:53 2021
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 24 Mar 2021 12:50:53 +0000
Subject: [issue41100] Support macOS 11 and Apple Silicon Macs
In-Reply-To: <1592999467.1.0.372512113251.issue41100@roundup.psfhosted.org>
Message-ID: <1616590253.88.0.972601485901.issue41100@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +23769
pull_request: https://github.com/python/cpython/pull/25014

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41100>
_______________________________________

From report at bugs.python.org  Wed Mar 24 09:15:11 2021
From: report at bugs.python.org (E. Paine)
Date: Wed, 24 Mar 2021 13:15:11 +0000
Subject: [issue43511] tkinter with Tk 8.6.11 is slow on macOS
In-Reply-To: <1615875194.4.0.35991043769.issue43511@roundup.psfhosted.org>
Message-ID: <1616591711.57.0.384962841746.issue43511@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

The reduction in speed with later Tk versions does not seem to occur on Linux. See the below table (times are microseconds per iteration - tested using wish):

+------------+----------+--------------+
| Tk Version | clearing | not clearing |
+============+==========+==============+
| 8.6.8      | 197.7    | 183.46       |
+------------+----------+--------------+
| 8.6.11     | 170.3    | 201.6        |
+------------+----------+--------------+

I have not tested on Windows but I don't think it's unreasonable to conclude the performance issue is limited to MacOS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43511>
_______________________________________

From report at bugs.python.org  Wed Mar 24 09:21:27 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Mar 2021 13:21:27 +0000
Subject: [issue42988] [security] CVE-2021-3426: Information disclosure via
 pydoc -p: /getfile?key=path allows to read arbitrary file on the filesystem
In-Reply-To: <1611231517.86.0.296188996897.issue42988@roundup.psfhosted.org>
Message-ID: <1616592087.66.0.902032568418.issue42988@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +23770
pull_request: https://github.com/python/cpython/pull/25015

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42988>
_______________________________________

From report at bugs.python.org  Wed Mar 24 09:40:45 2021
From: report at bugs.python.org (FRANK BENNETT)
Date: Wed, 24 Mar 2021 13:40:45 +0000
Subject: [issue43606] PySimpleGUI: initial huge window & no widgets visible
In-Reply-To: <1616526375.72.0.973402567023.issue43606@roundup.psfhosted.org>
Message-ID: <1616593245.31.0.838785323483.issue43606@roundup.psfhosted.org>


FRANK BENNETT <fbennett78 at reagan.com> added the comment:

fwb at fw:/s/opt/cpython/debug$ ./python -V
Python 3.10.0a6+

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43606>
_______________________________________

From report at bugs.python.org  Wed Mar 24 09:41:34 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Mar 2021 13:41:34 +0000
Subject: [issue42988] [security] CVE-2021-3426: Information disclosure via
 pydoc -p: /getfile?key=path allows to read arbitrary file on the filesystem
In-Reply-To: <1611231517.86.0.296188996897.issue42988@roundup.psfhosted.org>
Message-ID: <1616593294.94.0.724662754225.issue42988@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The "pydoc -p port" command only listen on the local link ("localhost") by default, even if it's possible to listen on another IPv4 address using -n HOSTNAME command line option.

While the "getfile" feature is convenient when the pydoc server is accessed from a different machine, I don't think that it's worth it, compared to the security risks and the complexity of PR 24285 and PR 24337 fixes.

I propose to simply remove the "getfile" feature with PR 25015, but keep links using file:// scheme. So we delegate the security to the web browser. If the web server is allowed to read sensitive data of a local Python file, it's not our problem: pydoc doesn't make things worse.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42988>
_______________________________________

From report at bugs.python.org  Wed Mar 24 09:47:05 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Mar 2021 13:47:05 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1616593625.62.0.898148179841.issue2001@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The "getfile" feature has a directory traversal vulnerability and so I propose to remove the feature: see bpo-42988.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2001>
_______________________________________

From report at bugs.python.org  Wed Mar 24 09:59:19 2021
From: report at bugs.python.org (Cong Ma)
Date: Wed, 24 Mar 2021 13:59:19 +0000
Subject: [issue43615] [PATCH] Properly implement Py_UNREACHABLE macro using
 autoconf.
Message-ID: <1616594359.79.0.245413708193.issue43615@roundup.psfhosted.org>


New submission from Cong Ma <m.cong at protonmail.ch>:

(This is a summarized form of the commit message in the attached patch. I'm submitting a patch instead of a PR over GitHub, because it seems that the ``autoreconf`` output files are part of the repository. In order for the changes to take effect in the repo, I may have to run ``autoreconf`` and add the clobbered output files to the repo, which I don't think is a good idea. Also on my system the ``autoreconf`` can only work correctly if I add a missing M4 file "ax_check_compile_flag.m4" from the Autoconf Archive <https://www.gnu.org/software/autoconf-archive/ax_check_compile_flag.html> for the ``AX_CHECK_COMPILE_FLAG`` macro used in the existing ``configure.ac``. I don't think it's wise for me to introduce so many changes at once if most developers don't need to run ``autoreconf`` often.)

The problem
-----------

Definition of the ``Py_UNREACHABLE()`` macro relied on testing compiler versions in preprocessor directives. This is unreliable chiefly because compilers masquerade as each other.

The current implementation tests the ``__GNUC__`` and ``__GNUC_MINOR__`` macros as the logic (GCC version >= 4.5) for determining whether the compiler intrinsic ``__builtin_unreachable()`` is present (see commits eebaa9bf, 24ba3b0d). However, Clang defines these macros too and can cause confusion. Clang 11 pretends to be GCC 4.2.1 in its predefined macros. As a result, Clang won't use the intrinsic even if it's supported. This doesn't seem to match the intent behind the original implementation.

The solution
------------

Test the presence of the compiler-builtin ``__builtin_unreachable()`` at configure-time using Autoconf, and conditionally define the ``Py_UNREACHABLE()`` macro depending on the configuration.

The idea is based on the ``ax_gcc_builtin.m4`` code [0] by Gabriele Svelto.

Alternative ideas
-----------------

Recent versions of Clang and GCC support the ``__has_builtin()`` macro.
However, this may be unreliable before Clang 10 [1], while GCC support is only available as of GCC 10 and its semantics may not be the same as Clang's [2]. Therefore ``__has_builtin()`` may not be as useful as it seems.

We may attempt to improve the accuracy of version checking in ``#if`` directives, but this could be brittle and difficult to explain, verify, or maintain.

Links
-----

[0] https://www.gnu.org/software/autoconf-archive/ax_gcc_builtin.html
[1] https://clang.llvm.org/docs/LanguageExtensions.html#has-builtin
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66970#c24

----------
components: Build
files: 0001-Properly-implement-Py_UNREACHABLE-macro-using-autoco.patch
keywords: patch
messages: 389454
nosy: congma
priority: normal
severity: normal
status: open
title: [PATCH] Properly implement Py_UNREACHABLE macro using autoconf.
type: enhancement
Added file: https://bugs.python.org/file49910/0001-Properly-implement-Py_UNREACHABLE-macro-using-autoco.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43615>
_______________________________________

From report at bugs.python.org  Wed Mar 24 10:06:29 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Mar 2021 14:06:29 +0000
Subject: [issue43615] [PATCH] Properly implement Py_UNREACHABLE macro using
 autoconf.
In-Reply-To: <1616594359.79.0.245413708193.issue43615@roundup.psfhosted.org>
Message-ID: <1616594789.39.0.884555568806.issue43615@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> The current implementation tests the ``__GNUC__`` and ``__GNUC_MINOR__`` macros as the logic (GCC version >= 4.5) for determining whether the compiler intrinsic ``__builtin_unreachable()`` is present (see commits eebaa9bf, 24ba3b0d). However, Clang defines these macros too and can cause confusion. Clang 11 pretends to be GCC 4.2.1 in its predefined macros. As a result, Clang won't use the intrinsic even if it's supported. This doesn't seem to match the intent behind the original implementation.

Hum. The current code is:

#elif defined(__GNUC__) && (__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 5))
#  define Py_UNREACHABLE() __builtin_unreachable()
#elif defined(__clang__) || defined(__INTEL_COMPILER)
#  define Py_UNREACHABLE() __builtin_unreachable()

Even if clang pretends to be GCC 4.2 and the first test fails, the second test is true and so Py_UNREACHABLE() is always defined as __builtin_unreachable() on clang, no?

You can please better explain your problem? You can write a short C code demonstrating the bug?

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43615>
_______________________________________

From report at bugs.python.org  Wed Mar 24 10:16:11 2021
From: report at bugs.python.org (Rowan Sylvester-Bradley)
Date: Wed, 24 Mar 2021 14:16:11 +0000
Subject: [issue43616] random.shuffle() crashes with Unhandled exception
Message-ID: <1616595371.88.0.389934384043.issue43616@roundup.psfhosted.org>


New submission from Rowan Sylvester-Bradley <rowan at sylvesterbradley.org>:

When I do 
  random.shuffle(questions_element) 
(questions_element is an element generated by lxml via the code
  questions_element = exams.find("questions") )
I get a crash:
Unhandled exception at 0x00007FFD7AE8EF89 (ntdll.dll) in python.exe: 0xC0000374: A heap has been corrupted (parameters: 0x00007FFD7AEF77F0).

Is there a way to work around this?

Thanks - Rowan

----------
messages: 389456
nosy: rowan.bradley
priority: normal
severity: normal
status: open
title: random.shuffle() crashes with Unhandled exception
type: crash
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43616>
_______________________________________

From report at bugs.python.org  Wed Mar 24 10:30:35 2021
From: report at bugs.python.org (Cong Ma)
Date: Wed, 24 Mar 2021 14:30:35 +0000
Subject: [issue43615] [PATCH] Properly implement Py_UNREACHABLE macro using
 autoconf.
In-Reply-To: <1616594359.79.0.245413708193.issue43615@roundup.psfhosted.org>
Message-ID: <1616596235.03.0.527117793182.issue43615@roundup.psfhosted.org>


Cong Ma <m.cong at protonmail.ch> added the comment:

Hello Victor,

I think you're right. This is bogus on my part. TL;DR: The Python version is 3.8 but I was trying to understand what's going on using the latest source.

Full version: I was trying to understand why the following C file when compiled with -shared using Clang 11 generates a call to Py_FatalError():

```
#define PY_SSIZE_T_CLEAN
#include "Python.h"


void
unreach(void)
{
    Py_UNREACHABLE();
}
```

The headers Python.h and also the ones pulled in by it were actually from Python 3.8 release, which unconditionally defines the macro as a call to Py_FatalError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43615>
_______________________________________

From report at bugs.python.org  Wed Mar 24 10:34:32 2021
From: report at bugs.python.org (Cong Ma)
Date: Wed, 24 Mar 2021 14:34:32 +0000
Subject: [issue43615] [PATCH] Properly implement Py_UNREACHABLE macro using
 autoconf.
In-Reply-To: <1616594359.79.0.245413708193.issue43615@roundup.psfhosted.org>
Message-ID: <1616596472.82.0.815690419491.issue43615@roundup.psfhosted.org>


Cong Ma <m.cong at protonmail.ch> added the comment:

BTW, do we need to fix the missing definition of the AX_CHECK_COMPILE_FLAG macro in configure.ac? This is a separate problem, if a problem at all.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43615>
_______________________________________

From report at bugs.python.org  Wed Mar 24 10:37:28 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Mar 2021 14:37:28 +0000
Subject: [issue43615] [PATCH] Properly implement Py_UNREACHABLE macro using
 autoconf.
In-Reply-To: <1616594359.79.0.245413708193.issue43615@roundup.psfhosted.org>
Message-ID: <1616596648.29.0.190409442513.issue43615@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> The headers Python.h and also the ones pulled in by it were actually from Python 3.8 release, which unconditionally defines the macro as a call to Py_FatalError.

Using __builtin_unreachable() is a recent change (bpo-38249), Python 3.9.0:

* commit eebaa9bfc593d5a46b293c1abd929fbfbfd28199

Fix for old GCC (bpo-41875):

* master: commit 24ba3b0df5e5f2f237d7b23b4017ba12f16320ae
* 3.9.1: commit cca896e13b230a934fdb709b7f10c5451ffc25ba

I prefer to not backport this feature, since, as you wrote, it's tricky to make sure that it's available on the C compiler.

I close the issue since Py_UNREACHABLE() works as expected on Python 3.9 and newer.

----------
stage: resolved -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43615>
_______________________________________

From report at bugs.python.org  Wed Mar 24 10:38:18 2021
From: report at bugs.python.org (Steve Dower)
Date: Wed, 24 Mar 2021 14:38:18 +0000
Subject: [issue32592] Drop support of Windows Vista and Windows 7
In-Reply-To: <1516268238.05.0.467229070634.issue32592@psf.upfronthosting.co.za>
Message-ID: <1616596698.28.0.583595283159.issue32592@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> not sure about the strategies here but maybe a better approach would be to kill support for unsupported version of windows in a major release

We do, but the "major" release is the second field of the version number (you can think of the first field as the "series" or "product" number).

Yes, this is not SemVer. Sorry. We pre-date SemVer.

Python 3.8 and earlier are just as supported for Windows 7 as our volunteers can handle, which is all that has ever been offered here. If people need better support than that, I'd suggest paying someone.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32592>
_______________________________________

From report at bugs.python.org  Wed Mar 24 10:38:30 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Mar 2021 14:38:30 +0000
Subject: [issue43615] [PATCH] Properly implement Py_UNREACHABLE macro using
 autoconf.
In-Reply-To: <1616594359.79.0.245413708193.issue43615@roundup.psfhosted.org>
Message-ID: <1616596710.58.0.661361733333.issue43615@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> BTW, do we need to fix the missing definition of the AX_CHECK_COMPILE_FLAG macro in configure.ac? This is a separate problem, if a problem at all.

I'm not sure which problem you are trying to solve. If you consider that there is a bug, please open a new issue since you closed this one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43615>
_______________________________________

From report at bugs.python.org  Wed Mar 24 10:46:46 2021
From: report at bugs.python.org (Jelle Zijlstra)
Date: Wed, 24 Mar 2021 14:46:46 +0000
Subject: [issue43616] random.shuffle() crashes with Unhandled exception
In-Reply-To: <1616595371.88.0.389934384043.issue43616@roundup.psfhosted.org>
Message-ID: <1616597206.89.0.527223294511.issue43616@roundup.psfhosted.org>


Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:

Could you post code that fully reproduces the problem?

I suspect the root cause for the bug is in lxml (a third-party library), not in CPython itself.

----------
nosy: +Jelle Zijlstra

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43616>
_______________________________________

From report at bugs.python.org  Wed Mar 24 10:52:18 2021
From: report at bugs.python.org (Cong Ma)
Date: Wed, 24 Mar 2021 14:52:18 +0000
Subject: [issue43617] Missing definition in configure.ac causing autoreconf to
 create damaged configure script
Message-ID: <1616597538.33.0.0386305243834.issue43617@roundup.psfhosted.org>


New submission from Cong Ma <m.cong at protonmail.ch>:

The problem
-----------

In the repository, the definition for ``AX_CHECK_COMPILE_FLAG`` in Python's ``configure.ac`` file is missing. If ``autoreconf`` is run, an invalid ``configure`` script is generated. The following is the behaviour of running ``autoreconf`` followed by ``configure``:

```
# In cpython repository top-level directory
$ autoreconf
$ mkdir build
$ cd build
$ ../configure  # <- using newly generated configure script
[... omitted ...]
checking for --enable-optimizations... no
../configure: line 6498: syntax error near unexpected token `-fno-semantic-interposition,'
../configure: line 6498: `      AX_CHECK_COMPILE_FLAG(-fno-semantic-interposition,'
```


The solution
------------

It appears a file was missing in the m4/ directory. The file matches this one from the Autoconf Archive:

https://www.gnu.org/software/autoconf-archive/ax_check_compile_flag.html

Simply adding the correct m4 file to m4/ should make ``autoreconf`` work.

----------
components: Build
messages: 389463
nosy: congma
priority: normal
severity: normal
status: open
title: Missing definition in configure.ac causing autoreconf to create damaged configure script

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43617>
_______________________________________

From report at bugs.python.org  Wed Mar 24 10:53:34 2021
From: report at bugs.python.org (Cong Ma)
Date: Wed, 24 Mar 2021 14:53:34 +0000
Subject: [issue43617] Missing definition in configure.ac causing autoreconf to
 create damaged configure script
In-Reply-To: <1616597538.33.0.0386305243834.issue43617@roundup.psfhosted.org>
Message-ID: <1616597614.68.0.264017697683.issue43617@roundup.psfhosted.org>


Change by Cong Ma <m.cong at protonmail.ch>:


----------
type:  -> compile error

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43617>
_______________________________________

From report at bugs.python.org  Wed Mar 24 10:54:02 2021
From: report at bugs.python.org (Cong Ma)
Date: Wed, 24 Mar 2021 14:54:02 +0000
Subject: [issue43615] [PATCH] Properly implement Py_UNREACHABLE macro using
 autoconf.
In-Reply-To: <1616594359.79.0.245413708193.issue43615@roundup.psfhosted.org>
Message-ID: <1616597642.45.0.100692867874.issue43615@roundup.psfhosted.org>


Cong Ma <m.cong at protonmail.ch> added the comment:

> If you consider that there is a bug, please open a new issue since you closed this one.

Please see the follow up in Issue 43617.

Many thanks for bearing with me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43615>
_______________________________________

From report at bugs.python.org  Wed Mar 24 11:11:34 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Mar 2021 15:11:34 +0000
Subject: [issue43617] Missing definition in configure.ac causing autoreconf to
 create damaged configure script
In-Reply-To: <1616597538.33.0.0386305243834.issue43617@roundup.psfhosted.org>
Message-ID: <1616598694.76.0.949372885172.issue43617@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> If ``autoreconf`` is run, ...

I never used autoreconf. If you don't run it, ./configure works fine.

I only use "autoconf" and "autoheader".

$ ./configure --enable-optimizations --enable-shared
(...)
$ grep semantic Makefile
CONFIGURE_CFLAGS_NODIST= -fno-semantic-interposition -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -fvisibility=hidden
CONFIGURE_LDFLAGS_NODIST= -fno-semantic-interposition

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43617>
_______________________________________

From report at bugs.python.org  Wed Mar 24 11:15:33 2021
From: report at bugs.python.org (Cong Ma)
Date: Wed, 24 Mar 2021 15:15:33 +0000
Subject: [issue43617] Missing definition in configure.ac causing autoreconf to
 create damaged configure script
In-Reply-To: <1616597538.33.0.0386305243834.issue43617@roundup.psfhosted.org>
Message-ID: <1616598933.07.0.656859828675.issue43617@roundup.psfhosted.org>


Cong Ma <m.cong at protonmail.ch> added the comment:

>From the configure.ac file:

> dnl ***********************************************
> dnl * Please run autoreconf to test your changes! *
> dnl ***********************************************

I take it to mean "if configure.ac is changed, run autoreconf first", and that's what I did. Could you let me know what is the intended way to modify configure.ac and have it take effect?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43617>
_______________________________________

From report at bugs.python.org  Wed Mar 24 11:16:12 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Mar 2021 15:16:12 +0000
Subject: [issue43617] Missing definition in configure.ac causing autoreconf to
 create damaged configure script
In-Reply-To: <1616597538.33.0.0386305243834.issue43617@roundup.psfhosted.org>
Message-ID: <1616598972.21.0.301120312136.issue43617@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Ah, maybe the configure.ac comment should be updated to suggest running "autoconf" instead ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43617>
_______________________________________

From report at bugs.python.org  Wed Mar 24 11:20:11 2021
From: report at bugs.python.org (Chris Morton)
Date: Wed, 24 Mar 2021 15:20:11 +0000
Subject: [issue43481] PyEval_EvalCode() namespace issue not observed in Python
 2.7.
In-Reply-To: <1615585477.01.0.106665214672.issue43481@roundup.psfhosted.org>
Message-ID: <1616599211.17.0.194415792863.issue43481@roundup.psfhosted.org>


Chris Morton <chrisgmorton at yahoo.com> added the comment:

Is this change in behavior considered to be by design or is this issue an unintended consequence? It seems inconsistent that comprehensions have no visibility of variable previously defined in the same scoping for this particular use-case. Is there a way to work around this other than reworking the comprehension?

It seems odd that [ci for ci in c] does not produce the error but [c for i in [1]] does produce the error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43481>
_______________________________________

From report at bugs.python.org  Wed Mar 24 11:25:01 2021
From: report at bugs.python.org (Cong Ma)
Date: Wed, 24 Mar 2021 15:25:01 +0000
Subject: [issue43605] Issue of scopes unclear in documentation,
 or wrongly implemented
In-Reply-To: <1616520364.91.0.0936665126175.issue43605@roundup.psfhosted.org>
Message-ID: <1616599501.55.0.974031275466.issue43605@roundup.psfhosted.org>


Cong Ma <m.cong at protonmail.ch> added the comment:

I think this is in the same class of behaviours as

```
def func(l):
    def get(i):
        return l[i]
    print(eval("(lambda x: get(x))(0)"))  # Call anonymous lambda with the constant 0 as argument
```
 
Calls like ``func(["spam"])`` will not "work", and ``NameError`` is raised.

In this case, inside the lambda's body the name "get" can't be resolved. For the lambda body, the name "get" is a nonlocal but there's no way to access a nonlocal in a lambda.

The comprehensions, like lambdas, are in their own nested scope.

----------
nosy: +congma

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43605>
_______________________________________

From report at bugs.python.org  Wed Mar 24 11:27:04 2021
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 24 Mar 2021 15:27:04 +0000
Subject: [issue42137] Prefer using __spec__ over module_repr() for
 ModuleType.__repr__
In-Reply-To: <1603495255.51.0.316157271396.issue42137@roundup.psfhosted.org>
Message-ID: <1616599624.64.0.359833488524.issue42137@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:


New changeset 9cb31d671646a5ff0901f79d2d61022621447190 by Brett Cannon in branch 'master':
bpo-42137: have ModuleType.__repr__ prefer __spec__ over module_repr() (GH-24953)
https://github.com/python/cpython/commit/9cb31d671646a5ff0901f79d2d61022621447190


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42137>
_______________________________________

From report at bugs.python.org  Wed Mar 24 11:27:17 2021
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 24 Mar 2021 15:27:17 +0000
Subject: [issue42137] Prefer using __spec__ over module_repr() for
 ModuleType.__repr__
In-Reply-To: <1603495255.51.0.316157271396.issue42137@roundup.psfhosted.org>
Message-ID: <1616599637.59.0.874758788783.issue42137@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/issue42137>
_______________________________________

From report at bugs.python.org  Wed Mar 24 11:37:44 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 24 Mar 2021 15:37:44 +0000
Subject: [issue43606] PySimpleGUI: initial huge window & no widgets visible
In-Reply-To: <1616526375.72.0.973402567023.issue43606@roundup.psfhosted.org>
Message-ID: <1616600264.95.0.446963639183.issue43606@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

PySimpleGUI is not a part of the stdlib.

If you have problems with pure Tkinter, look if you have files .Xdefaults or .Xresources in your home directory. They can alter default look of Tk widgets. Try to remove them and test whether the problem is gone.

If the problem is still here, perhaps you have some fonts misconfiguration.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43606>
_______________________________________

From report at bugs.python.org  Wed Mar 24 11:40:02 2021
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 24 Mar 2021 15:40:02 +0000
Subject: [issue43617] Missing definition in configure.ac causing autoreconf to
 create damaged configure script
In-Reply-To: <1616597538.33.0.0386305243834.issue43617@roundup.psfhosted.org>
Message-ID: <1616600402.18.0.0808676347836.issue43617@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

The extra macros are provided by optional packages. On Fedora and Debian/Ubuntu the package is called autoconf-archive.

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43617>
_______________________________________

From report at bugs.python.org  Wed Mar 24 11:45:44 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 24 Mar 2021 15:45:44 +0000
Subject: [issue43614] Search is not beginner friendly
In-Reply-To: <1616584368.72.0.108883750732.issue43614@roundup.psfhosted.org>
Message-ID: <1616600744.78.0.605999256156.issue43614@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Ha! I just was going to open the same issue (perhaps we read the same post on Quora).

I concur that it is perhaps worth to add index entries for common parameter names (args, kwargs, self, cls) and also for *args and **kwargs and add notions that such name is commonly used for such parameter.

----------
nosy: +rhettinger, serhiy.storchaka
type:  -> enhancement
versions: +Python 3.10, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43614>
_______________________________________

From report at bugs.python.org  Wed Mar 24 11:57:44 2021
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 24 Mar 2021 15:57:44 +0000
Subject: [issue43617] Missing definition in configure.ac causing autoreconf to
 create damaged configure script
In-Reply-To: <1616597538.33.0.0386305243834.issue43617@roundup.psfhosted.org>
Message-ID: <1616601464.15.0.0123207613783.issue43617@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
keywords: +patch
pull_requests: +23771
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25016

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43617>
_______________________________________

From report at bugs.python.org  Wed Mar 24 11:59:37 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 24 Mar 2021 15:59:37 +0000
Subject: [issue40601] [C API] Hide static types from the limited C API
In-Reply-To: <1589235805.82.0.0888479979707.issue40601@roundup.psfhosted.org>
Message-ID: <1616601577.46.0.0583205154569.issue40601@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

FWIW I have an idea that would allow code using e.g. &PyList_Type to continue to work, and even ABI compatible (though only in the main interpreter).

// In some header file

PyAPI_FUNC(PyHeapTypeObject *) PyList_GetType();

#define PyList_Type (PyList_GetType()->ht_type)

For the main interpreter we could make this return the address of PyList_Type.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40601>
_______________________________________

From report at bugs.python.org  Wed Mar 24 12:19:19 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 24 Mar 2021 16:19:19 +0000
Subject: [issue43616] random.shuffle() crashes with Unhandled exception
In-Reply-To: <1616595371.88.0.389934384043.issue43616@roundup.psfhosted.org>
Message-ID: <1616602759.79.0.837721025406.issue43616@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/issue43616>
_______________________________________

From report at bugs.python.org  Wed Mar 24 12:59:21 2021
From: report at bugs.python.org (Alexey Izbyshev)
Date: Wed, 24 Mar 2021 16:59:21 +0000
Subject: [issue32592] Drop support of Windows Vista and Windows 7
In-Reply-To: <1516268238.05.0.467229070634.issue32592@psf.upfronthosting.co.za>
Message-ID: <1616605161.17.0.419962164246.issue32592@roundup.psfhosted.org>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

> If we had a dedicated maintainer who was supporting Win7 and making releases for it, then we (i.e. they) could support it. But then, there's nothing to stop someone doing that already, and even to stop them charging money for it if they want (which they wouldn't be able to do under the auspices of python-dev). So I suspect nobody is really that motivated ;)

That's totally fair.

> (Also, a "little bit of complaining" here is totally worthwhile, as it helps us gauge community sentiment. Without it, we're limited to trawling forums and Twitter - especially without conferences to actually meet and hear directly from people - and so our inputs are biased. Having polite, informed, discussion on the tracker is a great way for us to see and capture these positions.)

I agree. In my comment, I only intended to contrast "complaining" with stepping up to do the work. I didn't mean to imply that it's inappropriate per-se.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32592>
_______________________________________

From report at bugs.python.org  Wed Mar 24 12:59:06 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 24 Mar 2021 16:59:06 +0000
Subject: [issue43481] PyEval_EvalCode() namespace issue not observed in Python
 2.7.
In-Reply-To: <1615585477.01.0.106665214672.issue43481@roundup.psfhosted.org>
Message-ID: <1616605146.76.0.0586333446374.issue43481@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Perhaps both.  If you want more discussion, please post to python-list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43481>
_______________________________________

From report at bugs.python.org  Wed Mar 24 13:03:28 2021
From: report at bugs.python.org (E. Paine)
Date: Wed, 24 Mar 2021 17:03:28 +0000
Subject: [issue43511] tkinter with Tk 8.6.11 is slow on macOS
In-Reply-To: <1615875194.4.0.35991043769.issue43511@roundup.psfhosted.org>
Message-ID: <1616605408.65.0.998924033277.issue43511@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

> there appears to be a tk 8.6.11.1 release

This was the version I used when testing Wish on both MacOS and Linux.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43511>
_______________________________________

From report at bugs.python.org  Wed Mar 24 13:29:21 2021
From: report at bugs.python.org (E. Paine)
Date: Wed, 24 Mar 2021 17:29:21 +0000
Subject: [issue43511] tkinter with Tk 8.6.11 is slow on macOS
In-Reply-To: <1615875194.4.0.35991043769.issue43511@roundup.psfhosted.org>
Message-ID: <1616606961.99.0.231674670968.issue43511@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

As this appears to be a Tk issue, I have created https://core.tcl-lang.org/tk/tktview/f642d7c0f4.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43511>
_______________________________________

From report at bugs.python.org  Wed Mar 24 13:46:40 2021
From: report at bugs.python.org (hai shi)
Date: Wed, 24 Mar 2021 17:46:40 +0000
Subject: [issue41551] test.support has way too many imports in libregrtest
In-Reply-To: <1597397929.74.0.568680866086.issue41551@roundup.psfhosted.org>
Message-ID: <1616608000.86.0.561152063251.issue41551@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

There have another related issue and have been fixed now in bpo 41718.
So I suggest to close this bpo.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41551>
_______________________________________

From report at bugs.python.org  Wed Mar 24 13:47:14 2021
From: report at bugs.python.org (hai shi)
Date: Wed, 24 Mar 2021 17:47:14 +0000
Subject: [issue41551] test.support has way too many imports in libregrtest
In-Reply-To: <1597397929.74.0.568680866086.issue41551@roundup.psfhosted.org>
Message-ID: <1616608034.82.0.952462295348.issue41551@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

bpo-41718

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41551>
_______________________________________

From report at bugs.python.org  Wed Mar 24 14:07:06 2021
From: report at bugs.python.org (Cong Ma)
Date: Wed, 24 Mar 2021 18:07:06 +0000
Subject: [issue43617] Missing definition in configure.ac causing autoreconf to
 create damaged configure script
In-Reply-To: <1616597538.33.0.0386305243834.issue43617@roundup.psfhosted.org>
Message-ID: <1616609226.24.0.900629377138.issue43617@roundup.psfhosted.org>


Cong Ma <m.cong at protonmail.ch> added the comment:

> The extra macros are provided by optional packages. On Fedora and Debian/Ubuntu the package is called autoconf-archive.

Thank you very much. This (and the patch) is clearing things up for me a lot. At first I thought I was supposed to copy the m4 files over from the autoconf archive into the m4 directory under the repo.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43617>
_______________________________________

From report at bugs.python.org  Wed Mar 24 14:08:39 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 24 Mar 2021 18:08:39 +0000
Subject: [issue43616] random.shuffle() crashes with Unhandled exception
In-Reply-To: <1616595371.88.0.389934384043.issue43616@roundup.psfhosted.org>
Message-ID: <1616609319.78.0.676179455372.issue43616@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43616>
_______________________________________

From report at bugs.python.org  Wed Mar 24 14:30:46 2021
From: report at bugs.python.org (Rowan Sylvester-Bradley)
Date: Wed, 24 Mar 2021 18:30:46 +0000
Subject: [issue43618] random.shuffle loses most of the elements
Message-ID: <1616610646.13.0.165363579885.issue43618@roundup.psfhosted.org>


New submission from Rowan Sylvester-Bradley <rowan at sylvesterbradley.org>:

This issue is probably related to issue ??? but I have created it as a separate issue. When shuffle doesn't crash it sometimes (or maybe always - I haven't fully analysed this yet) looses most of the elements in the list that it is supposed to be shuffling. Here is an extract of the code that I'm using:

import io
from io import StringIO 
from lxml import etree 
import random  

filename_xml = 'MockExam5.xml'
with io.open(filename_xml, mode="r", encoding="utf-8") as xml_file:
    xml_to_check = xml_file.read()
doc = etree.parse(StringIO(xml_to_check))
exams = doc.getroot()
questions_element = exams.find("questions")
logmsg(L_TRACE, "There are now " + str(len(questions_element.findall("question"))) + " questions")
logmsg(L_TRACE, "Randomising order of questions in this exam")
random.shuffle(questions_element)
logmsg(L_TRACE, "Finished randomise")
logmsg(L_TRACE, "There are now " + str(len(questions_element.findall("question"))) + " questions")

And here is the log produced by this code:

21-03-24 18:10:11.989 line:  2057 file: D:\XPS_8700 Extended Files\Users\RowanB\Documents\My_Scripts NEW\mockexam\put_exam.py 2 There are now 79 questions
21-03-24 18:10:11.991 line:  2065 file: D:\XPS_8700 Extended Files\Users\RowanB\Documents\My_Scripts NEW\mockexam\put_exam.py 2 Randomising order of questions in this exam
21-03-24 18:10:11.992 line:  2067 file: D:\XPS_8700 Extended Files\Users\RowanB\Documents\My_Scripts NEW\mockexam\put_exam.py 2 Finished randomise
21-03-24 18:10:11.993 line:  2068 file: D:\XPS_8700 Extended Files\Users\RowanB\Documents\My_Scripts NEW\mockexam\put_exam.py 2 There are now 6 questions

How come the shuffle starts off with 79 elements, and finishes with 6?

Thanks - Rowan

----------
messages: 389482
nosy: rowan.bradley
priority: normal
severity: normal
status: open
title: random.shuffle loses most of the elements
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43618>
_______________________________________

From report at bugs.python.org  Wed Mar 24 14:34:01 2021
From: report at bugs.python.org (Irit Katriel)
Date: Wed, 24 Mar 2021 18:34:01 +0000
Subject: [issue43618] random.shuffle loses most of the elements
In-Reply-To: <1616610646.13.0.165363579885.issue43618@roundup.psfhosted.org>
Message-ID: <1616610841.68.0.233813517318.issue43618@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
components: +Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43618>
_______________________________________

From report at bugs.python.org  Wed Mar 24 14:34:45 2021
From: report at bugs.python.org (Irit Katriel)
Date: Wed, 24 Mar 2021 18:34:45 +0000
Subject: [issue43616] random.shuffle() crashes with Unhandled exception
In-Reply-To: <1616595371.88.0.389934384043.issue43616@roundup.psfhosted.org>
Message-ID: <1616610885.08.0.673703739118.issue43616@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
components: +Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43616>
_______________________________________

From report at bugs.python.org  Wed Mar 24 14:36:17 2021
From: report at bugs.python.org (Irit Katriel)
Date: Wed, 24 Mar 2021 18:36:17 +0000
Subject: [issue43613] gzip.compress and gzip.decompress are sub-optimally
 implemented.
In-Reply-To: <1616567239.03.0.950381696666.issue43613@roundup.psfhosted.org>
Message-ID: <1616610977.5.0.0672420619566.issue43613@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
components: +Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43613>
_______________________________________

From report at bugs.python.org  Wed Mar 24 14:37:57 2021
From: report at bugs.python.org (Irit Katriel)
Date: Wed, 24 Mar 2021 18:37:57 +0000
Subject: [issue42964] Draft PEP blob etc
In-Reply-To: <b6c8112f-edb0-a860-5a52-5be7590d38f8@hastings.org>
Message-ID: <1616611077.37.0.117816442924.issue42964@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42964>
_______________________________________

From report at bugs.python.org  Wed Mar 24 14:44:11 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 24 Mar 2021 18:44:11 +0000
Subject: [issue43618] random.shuffle loses most of the elements
In-Reply-To: <1616610646.13.0.165363579885.issue43618@roundup.psfhosted.org>
Message-ID: <1616611451.55.0.664774648233.issue43618@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Same advice as issue 43616: please provide an example we can run.

This most likely a problem with how you're using lxml, and not a bug in python. But since we can't test it, we can't know for sure.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43618>
_______________________________________

From report at bugs.python.org  Wed Mar 24 15:23:14 2021
From: report at bugs.python.org (FRANK BENNETT)
Date: Wed, 24 Mar 2021 19:23:14 +0000
Subject: [issue43606] PySimpleGUI: initial huge window & no widgets visible
In-Reply-To: <1616526375.72.0.973402567023.issue43606@roundup.psfhosted.org>
Message-ID: <1616613794.37.0.161084773693.issue43606@roundup.psfhosted.org>


FRANK BENNETT <fbennett78 at reagan.com> added the comment:

Roundup requires submission inplain text...forget how to turn this off in thunderbird...sounds like a left over from microsoft emailers...how do I see/respond to comments with an issue ?

On 3/24/21 9:37 AM, Serhiy Storchaka wrote:
> Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:
>
> PySimpleGUI is not a part of the stdlib.
>
> If you have problems with pure Tkinter, look if you have files .Xdefaults or .Xresources in your home directory. They can alter default look of Tk widgets. Try to remove them and test whether the problem is gone.
>
> If the problem is still here, perhaps you have some fonts misconfiguration.
Good suggestion but same results...
  Tkinter ? Python 3.10 wants tkinter
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue43606>

----------
components:  -Tkinter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43606>
_______________________________________

From report at bugs.python.org  Wed Mar 24 15:30:00 2021
From: report at bugs.python.org (Tim Peters)
Date: Wed, 24 Mar 2021 19:30:00 +0000
Subject: [issue43618] random.shuffle loses most of the elements
In-Reply-To: <1616610646.13.0.165363579885.issue43618@roundup.psfhosted.org>
Message-ID: <1616614200.54.0.856420918613.issue43618@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Are you sure it's "a list"? At least print out `type(questions_element)`. `random.shuffle()` doesn't contain any code _capable_ of changing a list's length. It only does indexed accessing of the list:

...
    for i in reversed(range(1, len(x))):
        # pick an element in x[:i+1] with which to exchange x[i]
        j = randbelow(i + 1)
        x[i], x[j] = x[j], x[i]

That's about all there is to it. Note that, for this purpose, it doesn't matter want `randbelow()` does, because that function never even sees `x`.

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43618>
_______________________________________

From report at bugs.python.org  Wed Mar 24 15:34:39 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 24 Mar 2021 19:34:39 +0000
Subject: [issue41064] Specialise syntax error of **dict in f-string field
In-Reply-To: <1592742758.57.0.680300455155.issue41064@roundup.psfhosted.org>
Message-ID: <1616614479.46.0.537227318958.issue41064@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/issue41064>
_______________________________________

From report at bugs.python.org  Wed Mar 24 15:34:42 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 24 Mar 2021 19:34:42 +0000
Subject: [issue41064] Specialise syntax error of **dict in f-string field
In-Reply-To: <1592742758.57.0.680300455155.issue41064@roundup.psfhosted.org>
Message-ID: <1616614482.62.0.561293308385.issue41064@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 8efad61963809d239cac986e3f3bc4cb505ab8fe by Pablo Galindo in branch 'master':
bpo-41064: Improve syntax error for invalid usage of '**' in f-strings (GH-25006)
https://github.com/python/cpython/commit/8efad61963809d239cac986e3f3bc4cb505ab8fe


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41064>
_______________________________________

From report at bugs.python.org  Wed Mar 24 15:42:11 2021
From: report at bugs.python.org (David Brochart)
Date: Wed, 24 Mar 2021 19:42:11 +0000
Subject: [issue22239] asyncio: nested event loop
In-Reply-To: <1408557830.66.0.604610139339.issue22239@psf.upfronthosting.co.za>
Message-ID: <1616614931.93.0.958305171354.issue22239@roundup.psfhosted.org>


David Brochart <david.brochart at gmail.com> added the comment:

Regarding the initial message in this issue, and enabling recursive event loops, this has proved to be very useful when an event loop is already running and some non-async code needs to run async code. This situation is very frequent when e.g. a library is designed to be async-first, and also provides a blocking API which just wraps the async code by running it until complete.
The nest-asyncio library (https://github.com/erdewit/nest_asyncio) allows that by patching asyncio's event loop, but obviously this doesn't work with other event loops such as uvloop. I was wondering if things had changed since the original post of this issue, and if such a feature had any chance to make it into the standard library.

----------
nosy: +davidbrochart

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22239>
_______________________________________

From report at bugs.python.org  Wed Mar 24 16:18:16 2021
From: report at bugs.python.org (Roman Valov)
Date: Wed, 24 Mar 2021 20:18:16 +0000
Subject: [issue43619] convenience of using create_datagram_endpoint (and
 friends)
Message-ID: <1616617096.39.0.431079880564.issue43619@roundup.psfhosted.org>


New submission from Roman Valov <reddot.rocks at gmail.com>:

Please check the attached source code.

I have to implement an UDP server listening on all interfaces and able to detect what is the local address is used to communicate with remote address. In order to do this I'm using a temporary socket connected to exact remote endpoint to retrieve it's sock name.

When I implement the solution in a pure `asyncio` fashion I faced pair of inconveniences:

ISSUE-1: there is no idiomatic way to sleep forever inside async function. The example of using `create_datagram_endpoint` in documentation uses `sleep(3600)` which is not so useful. I've used `loop.create_future()` but it's perceived to be kind of hack. Also I can't use `loop.run_forever` in this context.

Possible solutions:
 - `serve_forever` for a transport object
 - `asyncio.setup_and_run_forever(main())` -- function to setup file descriptors for an event loop and run forever.
 - `asyncio.sleep(None)` or `asyncio.pause()` -- special argument for sleep or dedicated `pause` function.


ISSUE-2: callbacks for `Protocol` class are assumed to be sync `def`s. Despite the class is designed to be used as a part of `asyncio`. So, in order to invoke async code from sync callback I have to add some boilerplate code. Compare with `start_server`. It's `client_connected_cb` argument maybe a plain callable or co-routine function. So it's proposed to let Protocol callbacks to be `async def`s.

----------
components: asyncio
files: async.py
messages: 389488
nosy: Roman.Valov, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: convenience of using create_datagram_endpoint (and friends)
type: enhancement
versions: Python 3.8
Added file: https://bugs.python.org/file49912/async.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43619>
_______________________________________

From report at bugs.python.org  Wed Mar 24 16:25:41 2021
From: report at bugs.python.org (Kamil Turek)
Date: Wed, 24 Mar 2021 20:25:41 +0000
Subject: [issue43614] Search is not beginner friendly
In-Reply-To: <1616584368.72.0.108883750732.issue43614@roundup.psfhosted.org>
Message-ID: <1616617541.14.0.78744636012.issue43614@roundup.psfhosted.org>


Change by Kamil Turek <kamil.turek at hotmail.com>:


----------
nosy: +kamilturek

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43614>
_______________________________________

From report at bugs.python.org  Wed Mar 24 16:35:52 2021
From: report at bugs.python.org (Jared Sutton)
Date: Wed, 24 Mar 2021 20:35:52 +0000
Subject: [issue43620] os.path.join does not use os.sep as documentation claims
Message-ID: <1616618152.23.0.688812989277.issue43620@roundup.psfhosted.org>


New submission from Jared Sutton <jpsutton at gmail.com>:

The behavior of os.path.join() does not match the documentation, in regards to the use of os.sep.  From the docs:

"""
The return value is the concatenation of path and any members of *paths with exactly one directory separator (os.sep) following each non-empty part except the last, meaning that the result will only end in a separator if the last part is empty.
"""

The documentation clearly states that the function uses the value of os.sep (which differs based on platform).  However, if you review the 2 implementations (ntpath.py and posixpath.py), the separator character used is clearly hard-coded and doesn't reference os.sep at all.

One could say that this is either a doc bug or an implementation bug, depending on what the intended behavior is. I submit that this is an implementation bug, as one might want to use os.path.join() to construct a path to be used on a platform other than the one currently running the application. For example, a person might be running Python on Windows, but calling a web API and constructing a path for use on a remote posix system.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 389489
nosy: docs at python, jpsutton
priority: normal
severity: normal
status: open
title: os.path.join does not use os.sep as documentation claims
type: behavior
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43620>
_______________________________________

From report at bugs.python.org  Wed Mar 24 17:44:06 2021
From: report at bugs.python.org (Thomas Wamm)
Date: Wed, 24 Mar 2021 21:44:06 +0000
Subject: [issue43511] tkinter with Tk 8.6.11 is slow on macOS
In-Reply-To: <1615875194.4.0.35991043769.issue43511@roundup.psfhosted.org>
Message-ID: <1616622246.16.0.2974059688.issue43511@roundup.psfhosted.org>


Thomas Wamm <thomaswamm at gmail.com> added the comment:

tkinter performance on Windows 10 looks okay, no obvious problems.

Attached is a transcript showing bench.py results for Pythons 3.8.2, 3.9.2, and 3.10.0a6 on Windows 10 on a Dell laptop with an Intel i5-8250U CPU (medium good speed, a good comparison to Apple M1 Mac).

I originally raised this Issue because my new M1 Mac Mini performed so poorly compared to my Windows laptop, only for tkinter-related code.

----------
Added file: https://bugs.python.org/file49913/results_tk-bench_Win10_i5-8250U.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43511>
_______________________________________

From report at bugs.python.org  Wed Mar 24 18:12:54 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 24 Mar 2021 22:12:54 +0000
Subject: [issue43618] random.shuffle loses most of the elements
In-Reply-To: <1616610646.13.0.165363579885.issue43618@roundup.psfhosted.org>
Message-ID: <1616623974.86.0.588191314012.issue43618@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/issue43618>
_______________________________________

From report at bugs.python.org  Wed Mar 24 18:14:18 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 24 Mar 2021 22:14:18 +0000
Subject: [issue43618] random.shuffle loses most of the elements
In-Reply-To: <1616610646.13.0.165363579885.issue43618@roundup.psfhosted.org>
Message-ID: <1616624058.01.0.342737935696.issue43618@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43618>
_______________________________________

From report at bugs.python.org  Wed Mar 24 18:33:36 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 24 Mar 2021 22:33:36 +0000
Subject: [issue43198] One operation on sets < 1/100th as efficient in 3.9 than
 before
In-Reply-To: <1613002507.49.0.48232719319.issue43198@roundup.psfhosted.org>
Message-ID: <1616625216.8.0.26228510437.issue43198@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 72789592a3491bab49f144bb292679b1484885d9 by Raymond Hettinger in branch 'master':
bpo-43198:  Revert 3dd2157 that removed freeslot tracking. (#25010)
https://github.com/python/cpython/commit/72789592a3491bab49f144bb292679b1484885d9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43198>
_______________________________________

From report at bugs.python.org  Wed Mar 24 18:33:57 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 24 Mar 2021 22:33:57 +0000
Subject: [issue43198] One operation on sets < 1/100th as efficient in 3.9 than
 before
In-Reply-To: <1613002507.49.0.48232719319.issue43198@roundup.psfhosted.org>
Message-ID: <1616625237.77.0.0792260321824.issue43198@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/issue43198>
_______________________________________

From report at bugs.python.org  Wed Mar 24 18:57:09 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Wed, 24 Mar 2021 22:57:09 +0000
Subject: [issue43454] [sqlite3] Add support for R*Tree callbacks
In-Reply-To: <1615326865.81.0.691983788342.issue43454@roundup.psfhosted.org>
Message-ID: <1616626629.74.0.847540143892.issue43454@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

Attached is a patch that auto-detects R*Tree support. Tested on macOS only, but I'd guess it should work fine on any OS.

----------
Added file: https://bugs.python.org/file49914/patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43454>
_______________________________________

From report at bugs.python.org  Wed Mar 24 20:32:15 2021
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 25 Mar 2021 00:32:15 +0000
Subject: [issue43620] os.path.join does not use os.sep as documentation claims
In-Reply-To: <1616618152.23.0.688812989277.issue43620@roundup.psfhosted.org>
Message-ID: <1616632335.54.0.552306125815.issue43620@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

The documentation of os.path.join() uses os.sep because it's written from the perspective of the platform's os.path, which is posixpath on a POSIX system and ntpath on a Windows system.

If you need to work with POSIX paths in Windows, then use posixpath. It will of course use '/' as the path separator, since using backslash (os.sep) in a POSIX path is wrong. Vice versa, if you need to work with Windows paths in POSIX, use ntpath.

----------
nosy: +eryksun
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43620>
_______________________________________

From report at bugs.python.org  Thu Mar 25 04:24:44 2021
From: report at bugs.python.org (Ruben Vorderman)
Date: Thu, 25 Mar 2021 08:24:44 +0000
Subject: [issue43621] gzip._GzipReader should only throw BadGzipFile errors
Message-ID: <1616660684.49.0.0404853053479.issue43621@roundup.psfhosted.org>


New submission from Ruben Vorderman <r.h.p.vorderman at lumc.nl>:

This is properly documented: https://docs.python.org/3/library/gzip.html#gzip.BadGzipFile . 

It now hrows EOFErrors when a stream is truncated. But this means that upstream both BadGzipFile and EOFError need to be catched in the exception handling when opening a gzip file for reading. When a gzip file is truncated it is also a "bad gzip file" in my opinion, so there is no reason to have an extra class of errors.
Also it throws zlib.error's when zlib craches for some reason. This means there is some corruption in the raw deflate block. Well that means it is a "bad gzip file" as well and the error message should reflect that. 

This won't break people's code. If they are already catching EOFError zlib.error and BadGzipFile it changes nothing. If they only catch BadGzipFile, they will have less annoying errors that pop through.

I can make the PR, but of course not without any feedback. I am curious what other people think.

----------
components: Library (Lib)
messages: 389494
nosy: rhpvorderman
priority: normal
severity: normal
status: open
title: gzip._GzipReader should only throw BadGzipFile errors
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43621>
_______________________________________

From report at bugs.python.org  Thu Mar 25 04:24:55 2021
From: report at bugs.python.org (Ruben Vorderman)
Date: Thu, 25 Mar 2021 08:24:55 +0000
Subject: [issue43612] zlib.compress should have a wbits argument
In-Reply-To: <1616565860.52.0.251244097489.issue43612@roundup.psfhosted.org>
Message-ID: <1616660695.17.0.943393706466.issue43612@roundup.psfhosted.org>


Change by Ruben Vorderman <r.h.p.vorderman at lumc.nl>:


----------
components: +Extension Modules -Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43612>
_______________________________________

From report at bugs.python.org  Thu Mar 25 04:25:21 2021
From: report at bugs.python.org (Ruben Vorderman)
Date: Thu, 25 Mar 2021 08:25:21 +0000
Subject: [issue43621] gzip._GzipReader should only throw BadGzipFile errors
In-Reply-To: <1616660684.49.0.0404853053479.issue43621@roundup.psfhosted.org>
Message-ID: <1616660721.79.0.147978601151.issue43621@roundup.psfhosted.org>


Change by Ruben Vorderman <r.h.p.vorderman at lumc.nl>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43621>
_______________________________________

From report at bugs.python.org  Thu Mar 25 04:27:13 2021
From: report at bugs.python.org (Ruben Vorderman)
Date: Thu, 25 Mar 2021 08:27:13 +0000
Subject: [issue43613] gzip.compress and gzip.decompress are sub-optimally
 implemented.
In-Reply-To: <1616567239.03.0.950381696666.issue43613@roundup.psfhosted.org>
Message-ID: <1616660833.81.0.402223764023.issue43613@roundup.psfhosted.org>


Ruben Vorderman <r.h.p.vorderman at lumc.nl> added the comment:

I created bpo-43621 for the error issue. There should only be BadGzipFile. Once that is fixed, having only one error type will make it easier to implement some functions that are shared across the gzip.py codebase.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43613>
_______________________________________

From report at bugs.python.org  Thu Mar 25 04:54:27 2021
From: report at bugs.python.org (gchauvel)
Date: Thu, 25 Mar 2021 08:54:27 +0000
Subject: [issue43622] TLS 1.3, client polling returns event without data
Message-ID: <1616662467.59.0.863199354761.issue43622@roundup.psfhosted.org>


New submission from gchauvel <guillaume.chauvel at gmail.com>:

A simple test in test_ssl.py [1][2] with following context:
- client connects and listens to data without sending any first
- traces to make sure no data is written at test level from server or client
- TLSv1.3 is allowed or not using "context.options |= ssl.OP_NO_TLSv1_3"

produces this result:

TLSv1.2:
- no event on FD, no issue

TLSv1.3:
- event on FD without any write at test level
- recv() blocks, even with setblocking(False)

[1] master: https://github.com/g-chauvel/cpython/commit/8c95c4f67367ea43c508ea62a0cdbe120a3fed9b
[2] 3.6: https://github.com/g-chauvel/cpython/commit/7cd4b4ac22efea7c61a9f8f57b6f2315567f5742

----------
assignee: christian.heimes
components: SSL
messages: 389496
nosy: christian.heimes, gchauvel
priority: normal
severity: normal
status: open
title: TLS 1.3, client polling returns event without data
type: behavior
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43622>
_______________________________________

From report at bugs.python.org  Thu Mar 25 05:45:14 2021
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 25 Mar 2021 09:45:14 +0000
Subject: [issue43622] TLS 1.3, client polling returns event without data
In-Reply-To: <1616662467.59.0.863199354761.issue43622@roundup.psfhosted.org>
Message-ID: <1616665514.42.0.955243555928.issue43622@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Could you please explain why you consider this a bug?

TLS 1.3 works differently than TLS 1.2. You must always assume that an application level read can result in a protocol level write operation and the other way around. This could happen with TLS 1.2, but it was less common to occur. With TLS 1.3 rekeying, client cert authentication with post handshake authentication, and sessions are most common examples.

----------
versions:  -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43622>
_______________________________________

From report at bugs.python.org  Thu Mar 25 06:11:06 2021
From: report at bugs.python.org (gchauvel)
Date: Thu, 25 Mar 2021 10:11:06 +0000
Subject: [issue43622] TLS 1.3, client polling returns event without data
In-Reply-To: <1616662467.59.0.863199354761.issue43622@roundup.psfhosted.org>
Message-ID: <1616667066.32.0.044494853391.issue43622@roundup.psfhosted.org>


gchauvel <guillaume.chauvel at gmail.com> added the comment:

that's not the polling in itself,
it's: polling returning event + setblocking(False) + recv() which blocks

note: the behavior is present for python3.6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43622>
_______________________________________

From report at bugs.python.org  Thu Mar 25 06:27:25 2021
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 25 Mar 2021 10:27:25 +0000
Subject: [issue43622] TLS 1.3, client polling returns event without data
In-Reply-To: <1616662467.59.0.863199354761.issue43622@roundup.psfhosted.org>
Message-ID: <1616668045.93.0.873271130756.issue43622@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

It looks like your code is treating a SSLSocket like an ordinary Kernel socket. SSLSocket are implemented in user space and behave differently. 
https://docs.python.org/3/library/ssl.html#ssl-nonblocking explains some of the aspects of non-blocking I/O for TLS connections. For non-blocking I/O it is generally easier to use sans-I/O approach and make use of MemoryBIO https://docs.python.org/3/library/ssl.html#memory-bio-support instead of SSLSocket.

3.6 and 3.7 only receive security updates and are out of scope anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43622>
_______________________________________

From report at bugs.python.org  Thu Mar 25 09:48:37 2021
From: report at bugs.python.org (Jared Sutton)
Date: Thu, 25 Mar 2021 13:48:37 +0000
Subject: [issue43620] os.path.join does not use os.sep as documentation claims
In-Reply-To: <1616618152.23.0.688812989277.issue43620@roundup.psfhosted.org>
Message-ID: <1616680117.41.0.567697767932.issue43620@roundup.psfhosted.org>


Jared Sutton <jpsutton at gmail.com> added the comment:

I can understand your suggestion to just utilize the posixpath library on Windows if needed. That's a reasonable work-around. But certainly you can see this is a doc bug, since the doc clearly states that os.sep is utilized to join the elements of the path, when it clearly isn't; right?

----------
components:  -Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43620>
_______________________________________

From report at bugs.python.org  Thu Mar 25 09:56:23 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Mar 2021 13:56:23 +0000
Subject: [issue43244] Move PyArena C API to the internal C API
In-Reply-To: <1613586690.19.0.383646964758.issue43244@roundup.psfhosted.org>
Message-ID: <1616680583.08.0.743737646765.issue43244@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

In short, this issue is a follow-up of bpo-40939.

These C API removal are related to the final step of the PEP 617 "New PEG parser for CPython": removal of the PyParser C API.

* The PyParser C API produced "node*" objects, like PyParser_SimpleParseFile(FILE*) => node*. This C API was removed in Python 3.10: bpo-40939 "Remove the old parser".

* The AST C API takes "node*" as input: PyAST_FromNode(node*) => mod_ty. I removed these APIs.

* symtable takes "mod_ty" as input.

* ASDL and PyArena API were only useful for the removed AST C APIs.

I searched for removed functions in the top PyPI 4000 projects, there is a single project on 4000: typed_ast. This typed_ast project is special, it copies directly code from CPython. Even after the C API removed, typed_ast can continue to use the internal C API, it only has to define the Py_BUILD_CORE_MODULE macro.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43244>
_______________________________________

From report at bugs.python.org  Thu Mar 25 10:43:07 2021
From: report at bugs.python.org (Petr Viktorin)
Date: Thu, 25 Mar 2021 14:43:07 +0000
Subject: [issue33164] Blake 2 module update
In-Reply-To: <1558585970.68.0.308420136648.issue33164@roundup.psfhosted.org>
Message-ID: <1616683387.24.0.859702336081.issue33164@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

This reverted commit 5940c535b06805960d008bcafec7260dae74d9b9

----------
nosy: +petr.viktorin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33164>
_______________________________________

From report at bugs.python.org  Thu Mar 25 10:53:35 2021
From: report at bugs.python.org (Emmanuel Miranda)
Date: Thu, 25 Mar 2021 14:53:35 +0000
Subject: =?utf-8?q?=5Bissue43623=5D_nouveaut=C3=A9_2021?=
Message-ID: <1616684015.38.0.262463023278.issue43623@roundup.psfhosted.org>


New submission from Emmanuel Miranda <webstar at gmx.fr>:

Avec un nouveau cycle de release annuel la communaut? Python ne cesse d?aller de l?avant h?te de voir ce qu?ils nous r?servent pour 2021 apr?s la version 3.10 ! En esp?rant que les applicatifs suivent pour supporter

https://webscre.com/

----------
components: Library (Lib)
messages: 389503
nosy: Yanis77
priority: normal
severity: normal
status: open
title: nouveaut? 2021

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43623>
_______________________________________

From report at bugs.python.org  Thu Mar 25 10:54:59 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Mar 2021 14:54:59 +0000
Subject: =?utf-8?q?=5Bissue43623=5D_nouveaut=C3=A9_2021?=
In-Reply-To: <1616684015.38.0.262463023278.issue43623@roundup.psfhosted.org>
Message-ID: <1616684099.2.0.543875415894.issue43623@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43623>
_______________________________________

From report at bugs.python.org  Thu Mar 25 10:55:15 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Mar 2021 14:55:15 +0000
Subject: =?utf-8?q?=5Bissue43623=5D_nouveaut=C3=A9_2021?=
Message-ID: <1616684115.66.0.0949990706036.issue43623@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
Removed message: https://bugs.python.org/msg389503

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43623>
_______________________________________

From report at bugs.python.org  Thu Mar 25 10:57:25 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Mar 2021 14:57:25 +0000
Subject: [issue33164] Blake 2 module update
In-Reply-To: <1558585970.68.0.308420136648.issue33164@roundup.psfhosted.org>
Message-ID: <1616684245.19.0.696212218016.issue33164@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> This reverted commit 5940c535b06805960d008bcafec7260dae74d9b9

Context of the memcpy/memove change: https://github.com/BLAKE2/BLAKE2/issues/32

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33164>
_______________________________________

From report at bugs.python.org  Thu Mar 25 11:07:11 2021
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 25 Mar 2021 15:07:11 +0000
Subject: [issue43620] os.path.join does not use os.sep as documentation claims
In-Reply-To: <1616618152.23.0.688812989277.issue43620@roundup.psfhosted.org>
Message-ID: <1616684831.57.0.609914158519.issue43620@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> certainly you can see this is a doc bug, since the doc clearly 
> states that os.sep is utilized to join the elements of the path,
> when it clearly isn't; right?

os.path is ntpath in Windows, which uses backslash as the path separator, which is the same as os.sep in Windows. os.path is posixpath in POSIX, which uses slash as the path separator, which is the same as os.sep in POSIX.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43620>
_______________________________________

From report at bugs.python.org  Thu Mar 25 11:07:47 2021
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 25 Mar 2021 15:07:47 +0000
Subject: [issue33164] Blake 2 module update
In-Reply-To: <1558585970.68.0.308420136648.issue33164@roundup.psfhosted.org>
Message-ID: <1616684867.81.0.949995972595.issue33164@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
resolution: fixed -> 
stage: resolved -> needs patch
status: closed -> open
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33164>
_______________________________________

From report at bugs.python.org  Thu Mar 25 11:46:48 2021
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 25 Mar 2021 15:46:48 +0000
Subject: [issue42136] [importlib] deprecate module_repr() methods
In-Reply-To: <1603495128.4.0.940710955069.issue42136@roundup.psfhosted.org>
Message-ID: <1616687208.04.0.0688693942363.issue42136@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
keywords: +patch
pull_requests: +23772
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25022

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42136>
_______________________________________

From report at bugs.python.org  Thu Mar 25 11:59:23 2021
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 25 Mar 2021 15:59:23 +0000
Subject: [issue33164] Blake 2 module update
In-Reply-To: <1558585970.68.0.308420136648.issue33164@roundup.psfhosted.org>
Message-ID: <1616687963.3.0.641936955722.issue33164@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/issue33164>
_______________________________________

From report at bugs.python.org  Thu Mar 25 12:06:55 2021
From: report at bugs.python.org (Andrew Dailey)
Date: Thu, 25 Mar 2021 16:06:55 +0000
Subject: [issue43582] SSLContext.sni_callback docs inaccurately describe
 available handshake info
In-Reply-To: <1616338437.57.0.677049840589.issue43582@roundup.psfhosted.org>
Message-ID: <1616688415.01.0.0547271649011.issue43582@roundup.psfhosted.org>


Andrew Dailey <steveday168 at gmail.com> added the comment:

Okay, that makes sense. I appreciate the overview! What do you feel is the best way to "solve" this issue, then? Should the docs be updated to reflect the fact that ALPN info isn't available in the sni_callback? Or should some code be modified to make the docs correct (even though that'd have to be a bit hacky since the OpenSSL handshake callback order seems fairly set in stone).

I've got the contributor agreement signed and ready to go. I can formalize my ideas for revising the docs into a patch if that would make sense and be helpful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43582>
_______________________________________

From report at bugs.python.org  Thu Mar 25 12:16:38 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Mar 2021 16:16:38 +0000
Subject: [issue43416] Add README files in Include/cpython and Include/internal
In-Reply-To: <1615020265.58.0.71326223935.issue43416@roundup.psfhosted.org>
Message-ID: <1616688998.99.0.903723455483.issue43416@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 929c9039fe0468cb37e0811ddfb7b67c98353ea8 by Erlend Egeberg Aasland in branch 'master':
bpo-43416: Add Include/README.rst (GH-24884)
https://github.com/python/cpython/commit/929c9039fe0468cb37e0811ddfb7b67c98353ea8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43416>
_______________________________________

From report at bugs.python.org  Thu Mar 25 12:35:39 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Mar 2021 16:35:39 +0000
Subject: [issue43416] Add README files in Include/cpython and Include/internal
In-Reply-To: <1615020265.58.0.71326223935.issue43416@roundup.psfhosted.org>
Message-ID: <1616690139.59.0.917921566578.issue43416@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/issue43416>
_______________________________________

From report at bugs.python.org  Thu Mar 25 13:19:07 2021
From: report at bugs.python.org (Terry Davis)
Date: Thu, 25 Mar 2021 17:19:07 +0000
Subject: [issue43624] Add underscore as a decimal separator for string
 formatting
Message-ID: <1616692747.49.0.677529428018.issue43624@roundup.psfhosted.org>


New submission from Terry Davis <terry.y.davis at gmail.com>:

Proposal:
Enable this
>>> format(12_34_56.12_34_56, '_._f')
'123_456.123_456'

Where now only this is possible
>>> format(12_34_56.12_34_56, '_.f')
'123_456.123456'


Based on the discussion in the Ideas forum, three core devs support this addition.
https://discuss.python.org/t/add-underscore-as-a-thousandths-separator-for-string-formatting/7407

I'm willing to give this a try if someone points me to where to add tests and where the float formatting code is. This would be my first CPython contribution.

The feature freeze for 3.10 is 2021-05-03.
https://www.python.org/dev/peps/pep-0619/#id5

----------
components: Interpreter Core
messages: 389508
nosy: Terry Davis
priority: normal
severity: normal
status: open
title: Add underscore as a decimal separator for string formatting
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43624>
_______________________________________

From report at bugs.python.org  Thu Mar 25 13:30:54 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 25 Mar 2021 17:30:54 +0000
Subject: [issue43618] random.shuffle loses most of the elements
In-Reply-To: <1616610646.13.0.165363579885.issue43618@roundup.psfhosted.org>
Message-ID: <1616693454.87.0.730946435261.issue43618@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The standard library isn't at fault here.  Please file this an an LXML bug.

Reproducer:

    from lxml.etree import Element

    root = Element('outer')
    root.append(Element('zero'))
    root.append(Element('one'))
    root.append(Element('two'))
    print([e.tag for e in root])
    root[1], root[0] = root[0], root[1]
    print([e.tag for e in root])

This outputs:

   ['zero', 'one', 'two']
   ['one', 'two']

Replacing the import with:

   from xml.etree.ElementTree import Element

Gives the expected result:

   ['zero', 'one', 'two']
   ['one', 'zero', 'two']

----------
nosy: +scoder -skrah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43618>
_______________________________________

From report at bugs.python.org  Thu Mar 25 13:31:35 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 25 Mar 2021 17:31:35 +0000
Subject: [issue43616] random.shuffle() crashes with Unhandled exception
In-Reply-To: <1616595371.88.0.389934384043.issue43616@roundup.psfhosted.org>
Message-ID: <1616693495.78.0.620843556074.issue43616@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +scoder -skrah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43616>
_______________________________________

From report at bugs.python.org  Thu Mar 25 13:45:04 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 25 Mar 2021 17:45:04 +0000
Subject: [issue43618] random.shuffle loses most of the elements
In-Reply-To: <1616610646.13.0.165363579885.issue43618@roundup.psfhosted.org>
Message-ID: <1616694304.02.0.76539643895.issue43618@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Interestingly, this isn't an LXML bug.  It is a documented difference from how the standard library works:

    https://lxml.de/tutorial.html#elements-are-lists

So, if you want use random.shuffle(), you need the standard library ElementTree instead of lxml.

This:

    from lxml.etree import Element

    root = Element('outer')
    root.append(Element('zero'))
    root.append(Element('one'))
    root.append(Element('two'))
    root[0] = root[1]
    print([e.tag for e in root])

Produces:

   ['one', 'two']

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43618>
_______________________________________

From report at bugs.python.org  Thu Mar 25 13:55:50 2021
From: report at bugs.python.org (Irit Katriel)
Date: Thu, 25 Mar 2021 17:55:50 +0000
Subject: [issue24605] segmentation fault at asciilib_split_char.lto_priv
In-Reply-To: <1436533786.75.0.912431898018.issue24605@psf.upfronthosting.co.za>
Message-ID: <1616694950.1.0.517406174458.issue24605@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

Is there anything we can do about this or should it be closed?

----------
nosy: +iritkatriel
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24605>
_______________________________________

From report at bugs.python.org  Thu Mar 25 13:56:02 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 25 Mar 2021 17:56:02 +0000
Subject: [issue43624] Add underscore as a decimal separator for string
 formatting
In-Reply-To: <1616692747.49.0.677529428018.issue43624@roundup.psfhosted.org>
Message-ID: <1616694962.62.0.169532230582.issue43624@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

IIRC there is ISO recommending that after the decimal point, digits be arranged in groups of five.  I think is also how printed reference tables are typically formatted.

----------
nosy: +mark.dickinson, rhettinger, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43624>
_______________________________________

From report at bugs.python.org  Thu Mar 25 14:11:33 2021
From: report at bugs.python.org (Dimitri Merejkowsky)
Date: Thu, 25 Mar 2021 18:11:33 +0000
Subject: [issue37745] 3.8b3 - windows install gui/ inconsistent options
In-Reply-To: <1564766468.14.0.320547199271.issue37745@roundup.psfhosted.org>
Message-ID: <1616695893.94.0.289460938663.issue37745@roundup.psfhosted.org>


Dimitri Merejkowsky <dimitri at dmerej.info> added the comment:

I know this is two years later so maybe this is not the best way to get answers, but Steve Dower said:

> We don't add Python to PATH by default (because it's bad), and people couldn't find the option

Could someone clarify this for me? Because my experience as a Python teacher tells me the exact opposite.

For context, I've been teaching Python to absolute beginners (some of them do not even know how to *use* Windows to begin with).

I do tell them repeatedly to make sure to tick the "add python to Path", but every time, one of them forgot.

This gets even worse when the course is done remotely because I have to *tell* the students what to do through a screen-sharing app ...

Here's what I had to tell one of the students to do this morning.

Step 1: Tick "Display Hidden Items" in the Display option of the Windows File Explorer

Step 2: Go into c:\users\AppData

Step 3: Type `python.exe` in the search bar

Step 4: Copy/paste the full path 

Step 5: Open "Edit environment variables for my account"

Step 6: Click on "Edit environment variables"

Step 7: Click on Path

Step 8: Copy/paste the full path, without "python.exe"

Step 9: Copy/paste the full path, adding `\Scripts\` at the end

Step 10: restart cmd.exe


In insight, I wonder if I should have just told him to just re-run the installer and tick the box ...

Some notes: 

Fixing #14302 would help for step 9, which is nice.

I know very well that writing a Windows installer is far for trivial, but I'm ready to try and make a PR anyway. That being said, I understand there may be good reasons to *not* add python to PATH that I don't know about.

----------
nosy: +Dimitri Merejkowsky

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37745>
_______________________________________

From report at bugs.python.org  Thu Mar 25 14:17:21 2021
From: report at bugs.python.org (Fred Drake)
Date: Thu, 25 Mar 2021 18:17:21 +0000
Subject: [issue43620] os.path.join does not use os.sep as documentation claims
In-Reply-To: <1616618152.23.0.688812989277.issue43620@roundup.psfhosted.org>
Message-ID: <1616696241.13.0.145926571795.issue43620@roundup.psfhosted.org>


Fred Drake <fdrake at gmail.com> added the comment:

Perhaps Jared was expecting that modifying os.sep would affect the functions in os.path?

os.sep was never intended to be updated.

Using the specific *path modules to work with "foreign" paths has long been advocated as the way to do this.  It isn't a work-around.

----------
nosy: +fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43620>
_______________________________________

From report at bugs.python.org  Thu Mar 25 14:18:35 2021
From: report at bugs.python.org (ejacq)
Date: Thu, 25 Mar 2021 18:18:35 +0000
Subject: [issue43625] CSV has_headers heuristic could be improved
Message-ID: <1616696315.22.0.477162760848.issue43625@roundup.psfhosted.org>


New submission from ejacq <0python3 at jesuislibre.net>:

Here is an sample of CSV input:

"time","forces"
0,0
0.5,0.9

when calling has_header() from csv.py on this sample, it returns false.
Why? because 0 and 0.5 don't belong to the same type and thus the column is discarded by the heuristic.

I think the heuristic will better work if rather than just comparing number types, it would also consider casting the values in this order int -> float -> complex. If the values are similar then consider this upgraded type as the type of the column.

In the end, this file would be considered float columns with headers.

----------
components: Library (Lib)
messages: 389515
nosy: ejacq
priority: normal
severity: normal
status: open
title: CSV has_headers heuristic could be improved
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43625>
_______________________________________

From report at bugs.python.org  Thu Mar 25 14:43:27 2021
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 25 Mar 2021 18:43:27 +0000
Subject: [issue43616] random.shuffle() crashes with Unhandled exception
In-Reply-To: <1616595371.88.0.389934384043.issue43616@roundup.psfhosted.org>
Message-ID: <1616697807.81.0.289569627448.issue43616@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

Almost certainly not a bug in CPython's stdlib.

Possibly something worth investigating in lxml, although, as stated in issue 43618, random.shuffle() simply does not work on lxml.etree Elements.

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43616>
_______________________________________

From report at bugs.python.org  Thu Mar 25 14:45:13 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 25 Mar 2021 18:45:13 +0000
Subject: [issue43624] Add underscore as a decimal separator for string
 formatting
In-Reply-To: <1616692747.49.0.677529428018.issue43624@roundup.psfhosted.org>
Message-ID: <1616697913.89.0.950061365093.issue43624@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Some brief research
===================

""" in numbers four or more digits long, use commas to set off groups of three digits, counting leftward from the decimal point, in the standard American style. For long decimal numbers, do not use any digit-group separators to the right of the decimal point."""
? Google Style Guide https://developers.google.com/style/numbers

The CRC math handbook uses groups of five after the decimal point.
See ?1.2.4 in 
http://dl.icdst.org/pdfs/files/2a2cbcfc89598fd83c315ce45c1ee663.pdf


NIST Guide for using SI units:  """The digits of numerical values having more than four digits on either side of the decimal marker are separated into groups of three using a thin, fixed space counting from both the left and right of the decimal marker. For example, 15 739.012 53 is highly preferred to 15739.01253. Commas are not used to separate digits into groups of three. (See Sec. 10.5.3.)"""
? page vi in https://physics.nist.gov/cuu/pdf/sp811.pdf#10.5.2

StackExchange question on the topic:
https://math.stackexchange.com/questions/182775/convention-of-digit-grouping-after-decimal-point

The important reference, ISO 80000:1 discusses this in section 7, "Printing rules", but the standard is not publicly available.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43624>
_______________________________________

From report at bugs.python.org  Thu Mar 25 14:45:21 2021
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 25 Mar 2021 18:45:21 +0000
Subject: [issue43618] random.shuffle loses most of the elements
In-Reply-To: <1616610646.13.0.165363579885.issue43618@roundup.psfhosted.org>
Message-ID: <1616697921.61.0.0919144068437.issue43618@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

Yes, this is neither a bug in CPython (or its stdlib) nor in lxml. It's how things work. Don't use these two together.

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43618>
_______________________________________

From report at bugs.python.org  Thu Mar 25 15:05:07 2021
From: report at bugs.python.org (Batuhan Taskaya)
Date: Thu, 25 Mar 2021 19:05:07 +0000
Subject: [issue43609] ast.unparse-ing a FunctionType gives ambiguous result
In-Reply-To: <1616552087.93.0.261462178392.issue43609@roundup.psfhosted.org>
Message-ID: <1616699107.58.0.832073396787.issue43609@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:

Hey @cleoold! Technically the second AST you gave is invalid (fun2), considering that the FunctionType is not an expression;

    mod = Module(stmt* body, type_ignore* type_ignores)
        | FunctionType(expr* argtypes, expr returns)

    expr = BoolOp(boolop op, expr* values)
         | NamedExpr(expr target, expr value)
         | BinOp(expr left, operator op, expr right)

Though I am curious about use case. How did you come with the fun2's AST?

----------
nosy: +BTaskaya -Batuhan Taskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43609>
_______________________________________

From report at bugs.python.org  Thu Mar 25 15:16:51 2021
From: report at bugs.python.org (Abraham Macias)
Date: Thu, 25 Mar 2021 19:16:51 +0000
Subject: [issue43626] SIGSEV in PyErr_SetObject
Message-ID: <1616699811.01.0.0992968553141.issue43626@roundup.psfhosted.org>


New submission from Abraham Macias <amacias at gruposolutia.com>:

Hi, I'm dealing with random crashes when using pymongo in Python 3.7.3 in a Debian Buster.

This is the python backtrace:
(gdb) thread apply all py-bt

Thread 2 (Thread 0x7f9817d95700 (LWP 221)):
Traceback (most recent call first):
  File "/usr/local/lib/python3.7/dist-packages/gevent/_threading.py", line 80, in wait
    waiter.acquire() # Block on the native lock
  File "/usr/local/lib/python3.7/dist-packages/gevent/_threading.py", line 162, in get
    self._not_empty.wait()
  File "/usr/local/lib/python3.7/dist-packages/gevent/threadpool.py", line 270, in _worker
    task = task_queue.get()
  File "/usr/local/lib/python3.7/dist-packages/gevent/threadpool.py", line 254, in __trampoline
    g.switch()

Thread 1 (Thread 0x7f981fdfd740 (LWP 216)):
Traceback (most recent call first):
  <built-in method decode_all of module object at remote 0x7f981d41ca48>
  File "/usr/local/lib/python3.7/dist-packages/bson/__init__.py", line 1089, in _decode_all_selective
    return decode_all(data, codec_options)
  File "/usr/local/lib/python3.7/dist-packages/pymongo/message.py", line 1616, in unpack_response
    self.payload_document, codec_options, user_fields)
  File "/usr/local/lib/python3.7/dist-packages/pymongo/cursor.py", line 1080, in _unpack_response
    legacy_response)
  File "/usr/local/lib/python3.7/dist-packages/pymongo/server.py", line 131, in run_operation_with_response
    user_fields=user_fields)
  File "/usr/local/lib/python3.7/dist-packages/pymongo/mongo_client.py", line 1366, in _cmd
    unpack_res)
  File "/usr/local/lib/python3.7/dist-packages/pymongo/mongo_client.py", line 1471, in _retryable_read
    return func(session, server, sock_info, slave_ok)
  File "/usr/local/lib/python3.7/dist-packages/pymongo/mongo_client.py", line 1372, in _run_operation_with_response
    exhaust=exhaust)
  File "/usr/local/lib/python3.7/dist-packages/pymongo/cursor.py", line 1001, in __send_message
    address=self.__address)
  File "/usr/local/lib/python3.7/dist-packages/pymongo/cursor.py", line 1124, in _refresh
    self.__send_message(q)
  File "/usr/local/lib/python3.7/dist-packages/pymongo/cursor.py", line 1207, in next
    if len(self.__data) or self._refresh():
  File "/usr/local/lib/python3.7/dist-packages/pymongo/collection.py", line 1319, in find_one
    for result in cursor.limit(-1):
  File "/usr/local/lib/python3.7/dist-packages/gecoscc/userdb.py", line 119, in create_user
    user = self.collection.find_one({'email': email})
  File "/usr/local/lib/python3.7/dist-packages/gecoscc/commands/create_adminuser.py", line 95, in command
    {'is_superuser': self.options.is_superuser}
  File "/usr/local/lib/python3.7/dist-packages/gecoscc/management.py", line 90, in __call__
    self.command()
  File "/usr/local/lib/python3.7/dist-packages/gecoscc/management.py", line 48, in main
    command()
  File "/usr/local/bin/pmanage", line 10, in <module>
    sys.exit(main())
(gdb) 

And this is the builtin-code backtrace:

Core was generated by `/usr/bin/python3 /usr/local/bin/pmanage /opt/gecosccui/gecoscc.ini create_admin'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  PyErr_SetObject (exception=0x7ff9c0 <_PyExc_AttributeError.lto_priv.2311>, value=0x7f1ab49cb098) at ../Python/errors.c:101
101	        Py_INCREF(exc_value);
[Current thread is 1 (Thread 0x7f1abc823740 (LWP 370))]
(gdb) bt
#0  PyErr_SetObject (exception=<type at remote 0x7ff9c0>, value="type object 'dict' has no attribute '_type_marker'") at ../Python/errors.c:101
#1  0x000000000052c23b in PyErr_FormatV (vargs=0x7ffedff77c40, format=<optimized out>, exception=<type at remote 0x7ff9c0>) at ../Python/errors.c:852
#2  PyErr_Format (exception=<type at remote 0x7ff9c0>, format=<optimized out>) at ../Python/errors.c:852
#3  0x000000000058717d in type_getattro (type=<optimized out>, name=<optimized out>) at ../Objects/typeobject.c:3223
#4  0x000000000054baae in _PyObject_LookupAttr (result=<synthetic pointer>, name=<optimized out>, v=<type at remote 0x81a240>) at ../Objects/object.c:949
#5  builtin_getattr (self=<optimized out>, args=<optimized out>, nargs=<optimized out>) at ../Python/bltinmodule.c:1121
#6  0x00000000005cccc3 in _PyMethodDef_RawFastCallKeywords (method=0x89d160 <builtin_methods+544>, self=<module at remote 0x7f1abc52bc28>, args=0x1237208, nargs=<optimized out>, kwnames=<optimized out>)
    at ../Objects/call.c:651
#7  0x00000000005463e3 in _PyCFunction_FastCallKeywords (kwnames=0x0, nargs=3, args=0x1237208, func=<built-in method getattr of module object at remote 0x7f1abc52bc28>) at ../Objects/call.c:730
#8  call_function (kwnames=0x0, oparg=3, pp_stack=<synthetic pointer>) at ../Python/ceval.c:4568
#9  _PyEval_EvalFrameDefault (f=<optimized out>, throwflag=<optimized out>) at ../Python/ceval.c:3124
#10 0x00000000005cd68c in PyEval_EvalFrameEx (throwflag=0, 
    f=Frame 0x1237088, for file /usr/local/lib/python3.7/dist-packages/bson/codec_options.py, line 35, in _raw_document_class (document_class=<type at remote 0x81a240>)) at ../Python/ceval.c:547
#11 function_code_fastcall (globals=<optimized out>, nargs=<optimized out>, args=<optimized out>, co=<optimized out>) at ../Objects/call.c:283
#12 _PyFunction_FastCallKeywords (func=<optimized out>, stack=<optimized out>, nargs=<optimized out>, kwnames=<optimized out>) at ../Objects/call.c:408
#13 0x000000000054207c in call_function (kwnames=0x0, oparg=<optimized out>, pp_stack=<synthetic pointer>) at ../Python/ceval.c:4616
#14 _PyEval_EvalFrameDefault (f=<optimized out>, throwflag=<optimized out>) at ../Python/ceval.c:3124
#15 0x000000000053f732 in PyEval_EvalFrameEx (throwflag=0, 
    f=Frame 0x17882e8, for file /usr/local/lib/python3.7/dist-packages/bson/__init__.py, line 1013, in decode_all (data=b'V\x00\x00\x00\x03cursor\x00=\x00\x00\x00\x04firstBatch\x00\x05\x00\x00\x00\x00\x12id\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02ns\x00\x13\x00\x00\x00gecoscc.adminusers\x00\x00\x01ok\x00\x00\x00\x00\x00\x00\x00\xf0?\x00', codec_options=<CodecOptions at remote 0x7f1ab4ac2208>, view=<memoryview at remote 0x7f1ab5375708>, data_len=86, docs=[], position=0, end=85)) at ../Python/ceval.c:547
#16 _PyEval_EvalCodeWithName (_co=<optimized out>, globals=<optimized out>, locals=<optimized out>, args=<optimized out>, argcount=<optimized out>, kwnames=0x0, kwargs=0x7f1ab49de978, kwcount=<optimized out>, 
    kwstep=1, defs=0x7f1ab9e42220, defcount=1, kwdefs=0x0, closure=0x0, name='decode_all', qualname='decode_all') at ../Python/ceval.c:3930
#17 0x00000000005cd982 in _PyFunction_FastCallKeywords (func=<optimized out>, stack=0x7f1ab49de968, nargs=2, kwnames=<optimized out>) at ../Objects/call.c:433
#18 0x000000000054207c in call_function (kwnames=0x0, oparg=<optimized out>, pp_stack=<synthetic pointer>) at ../Python/ceval.c:4616
#19 _PyEval_EvalFrameDefault (f=<optimized out>, throwflag=<optimized out>) at ../Python/ceval.c:3124
#20 0x00000000005cd68c in PyEval_EvalFrameEx (throwflag=0, 
    f=Frame 0x7f1ab49de7c8, for file /usr/local/lib/python3.7/dist-packages/bson/__init__.py, line 1089, in _decode_all_selective (data=b'V\x00\x00\x00\x03cursor\x00=\x00\x00\x00\x04firstBatch\x00\x05\x00\x00\x00\x00\x12id\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02ns\x00\x13\x00\x00\x00gecoscc.adminusers\x00\x00\x01ok\x00\x00\x00\x00\x00\x00\x00\xf0?\x00', codec_options=<CodecOptions at remote 0x7f1ab4ac2208>, fields={'cursor': {'firstBatch': 1, 'nextBatch': 1}})) at ../Python/ceval.c:547


As I understand the code is using "getattr" to ckeck if a dict contains an attribute called "_type_marker", and somehow when Python is formatting the exception finds that the stack has been corrupted.

What can be happening? How can I help to debug this?

Best regards!

----------
components: Interpreter Core
messages: 389520
nosy: amacias
priority: normal
severity: normal
status: open
title: SIGSEV in PyErr_SetObject
type: crash
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43626>
_______________________________________

From report at bugs.python.org  Thu Mar 25 15:20:59 2021
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 25 Mar 2021 19:20:59 +0000
Subject: [issue43620] os.path.join does not use os.sep as documentation claims
In-Reply-To: <1616618152.23.0.688812989277.issue43620@roundup.psfhosted.org>
Message-ID: <1616700059.46.0.215212408837.issue43620@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

Fred, do you think this needs to be reopened to clarify that os.sep and os.altsep are not parameters for the ntpath and posixpath modules? 

I would have thought that the note at the top (path name conventions, etc) would be sufficient to let someone know that os.path is meant for working with paths on the current platform. Working with Windows paths in POSIX, and vice versa, is not simply a matter of replacing os.sep. For example:

    >>> posixpath.join('C:/spam', '/eggs')
    '/eggs'
    >>> ntpath.join('C:/spam', '/eggs')
    'C:/eggs'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43620>
_______________________________________

From report at bugs.python.org  Thu Mar 25 15:22:38 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Mar 2021 19:22:38 +0000
Subject: [issue43626] SIGSEV in PyErr_SetObject
In-Reply-To: <1616699811.01.0.0992968553141.issue43626@roundup.psfhosted.org>
Message-ID: <1616700158.66.0.402271554062.issue43626@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> What can be happening? How can I help to debug this?

Try to run your application in the Python Debug Mode: https://docs.python.org/dev/library/devmode.html

The best is if you can run your application with a Python built in debug mode.

Usually, it's a bug in a 3rd party C extension.

See also: https://pythondev.readthedocs.io/debug_tools.html

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43626>
_______________________________________

From report at bugs.python.org  Thu Mar 25 15:22:50 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Mar 2021 19:22:50 +0000
Subject: [issue43624] Add underscore as a decimal separator for string
 formatting
In-Reply-To: <1616692747.49.0.677529428018.issue43624@roundup.psfhosted.org>
Message-ID: <1616700170.57.0.833649008862.issue43624@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43624>
_______________________________________

From report at bugs.python.org  Thu Mar 25 15:55:08 2021
From: report at bugs.python.org (midori)
Date: Thu, 25 Mar 2021 19:55:08 +0000
Subject: [issue43609] ast.unparse-ing a FunctionType gives ambiguous result
In-Reply-To: <1616552087.93.0.261462178392.issue43609@roundup.psfhosted.org>
Message-ID: <1616702108.58.0.14522470588.issue43609@roundup.psfhosted.org>


midori <cleoold at member.fsf.org> added the comment:

@BTaskaya I've seen this in third party ides and type checker. For example they are referring to "Union[Callable[[], Union[int, str]], None]" as "() -> (int | str) | None" where there are parentheses around the returns.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43609>
_______________________________________

From report at bugs.python.org  Thu Mar 25 16:03:45 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Mar 2021 20:03:45 +0000
Subject: [issue24605] segmentation fault at asciilib_split_char.lto_priv
In-Reply-To: <1436533786.75.0.912431898018.issue24605@psf.upfronthosting.co.za>
Message-ID: <1616702625.26.0.68445508446.issue24605@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

No activity for 6 years, the reporter didn't provide any way to reproduce the crash, I close the issue.

Note: Python 3.10 now dumps the list of third party C extensions on a fatal error, or when faulthandler handlers a crash ;-) Just enabled the Python Development Mode:
https://docs.python.org/dev/library/devmode.html

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24605>
_______________________________________

From report at bugs.python.org  Thu Mar 25 16:03:51 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Mar 2021 20:03:51 +0000
Subject: [issue24605] segmentation fault at asciilib_split_char.lto_priv
In-Reply-To: <1436533786.75.0.912431898018.issue24605@psf.upfronthosting.co.za>
Message-ID: <1616702631.0.0.877577402067.issue24605@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24605>
_______________________________________

From report at bugs.python.org  Thu Mar 25 16:27:36 2021
From: report at bugs.python.org (Christopher A. Chavez)
Date: Thu, 25 Mar 2021 20:27:36 +0000
Subject: [issue43511] tkinter with Tk 8.6.11 is slow on macOS
In-Reply-To: <1615875194.4.0.35991043769.issue43511@roundup.psfhosted.org>
Message-ID: <1616704056.21.0.793066125817.issue43511@roundup.psfhosted.org>


Change by Christopher A. Chavez <chrischavez at gmx.us>:


----------
nosy: +chrstphrchvz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43511>
_______________________________________

From report at bugs.python.org  Thu Mar 25 16:27:32 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 25 Mar 2021 20:27:32 +0000
Subject: [issue43625] CSV has_headers heuristic could be improved
In-Reply-To: <1616696315.22.0.477162760848.issue43625@roundup.psfhosted.org>
Message-ID: <1616704052.5.0.206102705285.issue43625@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43625>
_______________________________________

From report at bugs.python.org  Thu Mar 25 16:27:44 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 25 Mar 2021 20:27:44 +0000
Subject: [issue43625] CSV has_headers heuristic could be improved
In-Reply-To: <1616696315.22.0.477162760848.issue43625@roundup.psfhosted.org>
Message-ID: <1616704064.52.0.653712764565.issue43625@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/issue43625>
_______________________________________

From report at bugs.python.org  Thu Mar 25 16:32:32 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 25 Mar 2021 20:32:32 +0000
Subject: [issue40521] [subinterpreters] Make free lists and unicode caches
 per-interpreter
In-Reply-To: <1588693682.5.0.219755904926.issue40521@roundup.psfhosted.org>
Message-ID: <1616704352.66.0.543662627579.issue40521@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 3bb19873abd572879cc9a8810b1db9db1f704070 by Raymond Hettinger in branch 'master':
Revert "bpo-40521: Remove freelist from collections.deque() (GH-21073)" (GH-24944)
https://github.com/python/cpython/commit/3bb19873abd572879cc9a8810b1db9db1f704070


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40521>
_______________________________________

From report at bugs.python.org  Thu Mar 25 16:35:30 2021
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 25 Mar 2021 20:35:30 +0000
Subject: [issue43627] What are the requirements for a test_sunry-testable
 script in Tools/scripts?
Message-ID: <1616704530.06.0.307458133003.issue43627@roundup.psfhosted.org>


New submission from Skip Montanaro <skip.montanaro at gmail.com>:

In my fork of python/cpython I recently created a simple script to help me with my work (I am messing around in the internals and sometimes get blindsided by opcode changes). I stuck the script in Tools/script which caused test_tools.test_sundry to hang. (I suspect it's because my script reads from sys.stdin, but I'm not certain. The old Unix pipeline ways die hard.)

Looking around to see how I could modify my script to make it acceptable to test_sundry, I saw nothing about requirements. I tossed it in the TestSundryScripts.other list and now that test completes. Still, it seems there should be a bit written about what it takes for a script to be amenable to the minimal testing test_sundry.py performs.

----------
components: Tests
messages: 389526
nosy: skip.montanaro
priority: normal
severity: normal
status: open
title: What are the requirements for a test_sunry-testable script in Tools/scripts?
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43627>
_______________________________________

From report at bugs.python.org  Thu Mar 25 16:51:19 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Mar 2021 20:51:19 +0000
Subject: [issue40521] [subinterpreters] Make free lists and unicode caches
 per-interpreter
In-Reply-To: <1588693682.5.0.219755904926.issue40521@roundup.psfhosted.org>
Message-ID: <1616705479.86.0.428784235485.issue40521@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I reopen the issue to remind me that collections.deque() freelist is shared by all interpreters.

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40521>
_______________________________________

From report at bugs.python.org  Thu Mar 25 17:03:41 2021
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 25 Mar 2021 21:03:41 +0000
Subject: [issue43625] CSV has_headers heuristic could be improved
In-Reply-To: <1616696315.22.0.477162760848.issue43625@roundup.psfhosted.org>
Message-ID: <1616706221.48.0.554616358128.issue43625@roundup.psfhosted.org>


Skip Montanaro <skip.montanaro at gmail.com> added the comment:

I assume the OP is referring to this sort of usage:

>>> sniffer = csv.Sniffer()
>>> raw = open("mixed.csv").read()
>>> sniffer.has_header(raw)
False

*sigh*

I really wish the Sniffer class had never been added to the CSV module. I can't recall who wrote it (the author is long gone). Though I am responsible for the initial commits, it wasn't me or the main authors of csvmodule.c. As far as I know, it never really worked well. I can't recall ever using it.

A simpler heuristic would be if the first row contains a bunch of strings and the second row contains a bunch of numbers, then the file has a header. That assumes that CSV files consist mostly of numeric data.

Looking at has_header, I see this:

    for thisType in [int, float, complex]:

I think this particular problem would be solved if the order of those types were reversed. The attached diff suggests that as well. Note that the Sniffer class currently contains no test cases, so that the test I added failed before the change and passes after doesn't mean it doesn't break someone's mission critical Sniffer usage.

(Sorry, Raymond. My Github-foo is insufficient to allow me to fork, apply the diff and create a PR.)

----------
keywords: +patch
Added file: https://bugs.python.org/file49915/csv.diff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43625>
_______________________________________

From report at bugs.python.org  Thu Mar 25 17:04:49 2021
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 25 Mar 2021 21:04:49 +0000
Subject: [issue43627] What are the requirements for a test_sundry-testable
 script in Tools/scripts?
In-Reply-To: <1616704530.06.0.307458133003.issue43627@roundup.psfhosted.org>
Message-ID: <1616706289.42.0.428537696212.issue43627@roundup.psfhosted.org>


Change by Skip Montanaro <skip.montanaro at gmail.com>:


----------
title: What are the requirements for a test_sunry-testable script in Tools/scripts? -> What are the requirements for a test_sundry-testable script in Tools/scripts?

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43627>
_______________________________________

From report at bugs.python.org  Thu Mar 25 17:04:42 2021
From: report at bugs.python.org (Dominic Davis-Foster)
Date: Thu, 25 Mar 2021 21:04:42 +0000
Subject: [issue43624] Add underscore as a decimal separator for string
 formatting
In-Reply-To: <1616692747.49.0.677529428018.issue43624@roundup.psfhosted.org>
Message-ID: <1616706282.57.0.0498841138738.issue43624@roundup.psfhosted.org>


Dominic Davis-Foster <dominic at davis-foster.co.uk> added the comment:

ISO 80000-1:2009 recommends groups of three digits either side of the decimal sign.

----------
nosy: +domdfcoding

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43624>
_______________________________________

From report at bugs.python.org  Thu Mar 25 17:22:24 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 25 Mar 2021 21:22:24 +0000
Subject: [issue43618] random.shuffle loses most of the elements
In-Reply-To: <1616610646.13.0.165363579885.issue43618@roundup.psfhosted.org>
Message-ID: <1616707344.25.0.58519239401.issue43618@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

As an immediate fix to your problem, replace this line:

    random.shuffle(questions_element)

with:

    questions = list(questions_element)
    random.shuffle(questions)
    questions_element[:] = questions

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43618>
_______________________________________

From report at bugs.python.org  Thu Mar 25 18:59:07 2021
From: report at bugs.python.org (Irit Katriel)
Date: Thu, 25 Mar 2021 22:59:07 +0000
Subject: [issue35816] csv.DictReader, skipinitialspace does not ignore tabs
In-Reply-To: <1548325714.32.0.972508693176.issue35816@roundup.psfhosted.org>
Message-ID: <1616713147.43.0.576825222693.issue35816@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
components: +Library (Lib)
versions: +Python 3.10 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35816>
_______________________________________

From report at bugs.python.org  Thu Mar 25 18:59:21 2021
From: report at bugs.python.org (Irit Katriel)
Date: Thu, 25 Mar 2021 22:59:21 +0000
Subject: [issue21297] csv.skipinitialspace only skips spaces,
 not "whitespace" in general
In-Reply-To: <1397821941.61.0.706896478348.issue21297@psf.upfronthosting.co.za>
Message-ID: <1616713161.79.0.144315292226.issue21297@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.7, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21297>
_______________________________________

From report at bugs.python.org  Thu Mar 25 19:18:24 2021
From: report at bugs.python.org (Irit Katriel)
Date: Thu, 25 Mar 2021 23:18:24 +0000
Subject: [issue38241] doc: Pickle with protocol=0 in python 3 does not produce
 a 'human-readable' format
In-Reply-To: <1569019992.12.0.181360535458.issue38241@roundup.psfhosted.org>
Message-ID: <1616714304.1.0.795391932805.issue38241@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
title: Pickle with protocol=0 in python 3 does not produce a 'human-readable' format -> doc: Pickle with protocol=0 in python 3 does not produce a 'human-readable' format
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38241>
_______________________________________

From report at bugs.python.org  Thu Mar 25 20:22:32 2021
From: report at bugs.python.org (Irit Katriel)
Date: Fri, 26 Mar 2021 00:22:32 +0000
Subject: [issue39418] str.strip() should have a means of adding to the default
 behaviour
In-Reply-To: <1579695416.2.0.0994259543651.issue39418@roundup.psfhosted.org>
Message-ID: <1616718152.43.0.208965235748.issue39418@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

In python 3.9 there is also str.removeprefix:
https://docs.python.org/3/library/stdtypes.html#str.removeprefix
which you can apply in a loop.

----------
components: +Library (Lib)
nosy: +iritkatriel

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39418>
_______________________________________

From report at bugs.python.org  Thu Mar 25 20:28:23 2021
From: report at bugs.python.org (Irit Katriel)
Date: Fri, 26 Mar 2021 00:28:23 +0000
Subject: [issue40758] For 7.2.7. Code Examples,
 distinguish between the Tutorial and other documentation
In-Reply-To: <1590353365.14.0.907078183909.issue40758@roundup.psfhosted.org>
Message-ID: <1616718503.37.0.895659061917.issue40758@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
versions:  -Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40758>
_______________________________________

From report at bugs.python.org  Thu Mar 25 21:03:32 2021
From: report at bugs.python.org (Jared Sutton)
Date: Fri, 26 Mar 2021 01:03:32 +0000
Subject: [issue43620] os.path.join does not use os.sep as documentation claims
In-Reply-To: <1616618152.23.0.688812989277.issue43620@roundup.psfhosted.org>
Message-ID: <1616720612.94.0.986249656583.issue43620@roundup.psfhosted.org>


Jared Sutton <jpsutton at gmail.com> added the comment:

> Perhaps Jared was expecting that modifying os.sep would affect the functions in os.path?

This is precisely what I thought, because the documentation makes it sound like that variable named os.sep is read and used as the path delimiter when constructing something with join(). In fact, that variable isn't read *at all* because the path separator is hard-coded in both posixpath.py and ntpath.py. Since os.sep isn't used, I see no reason why it should be referenced in the documentation at all.

I'm not trying to be pedantic here (though we nerds are famous for that :) ), but what I see here is a disagreement between what is documented and what actually exists in the implementation. Yes the *value* of os.sep happens to be the same as the one hard-coded into either ntpath or posixpath, but since that variable is not referenced in the implementation, its presence in the doc only serves to confuse people who take the documentation at face value and then get an unexpected result.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43620>
_______________________________________

From report at bugs.python.org  Thu Mar 25 21:16:46 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 26 Mar 2021 01:16:46 +0000
Subject: [issue39418] str.strip() should have a means of adding to the default
 behaviour
In-Reply-To: <1579695416.2.0.0994259543651.issue39418@roundup.psfhosted.org>
Message-ID: <1616721406.05.0.215013591548.issue39418@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Marking this as closed because the issue doesn't seem to have gathered much interest.  If someone wants to move this forward, I recommend discussing it on python-ideas.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39418>
_______________________________________

From report at bugs.python.org  Thu Mar 25 21:38:46 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 26 Mar 2021 01:38:46 +0000
Subject: [issue43624] Add underscore as a decimal separator for string
 formatting
In-Reply-To: <1616692747.49.0.677529428018.issue43624@roundup.psfhosted.org>
Message-ID: <1616722726.15.0.633165617121.issue43624@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43624>
_______________________________________

From report at bugs.python.org  Thu Mar 25 21:40:45 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 26 Mar 2021 01:40:45 +0000
Subject: [issue43624] Add underscore as a decimal separator for string
 formatting
In-Reply-To: <1616692747.49.0.677529428018.issue43624@roundup.psfhosted.org>
Message-ID: <1616722845.93.0.727082873202.issue43624@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

If we do anything for float, we should do the same for decimal.Decimal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43624>
_______________________________________

From report at bugs.python.org  Thu Mar 25 21:58:53 2021
From: report at bugs.python.org (Yang Feng)
Date: Fri, 26 Mar 2021 01:58:53 +0000
Subject: [issue43628] Incorrect argument errors for random.getstate()
Message-ID: <1616723933.11.0.615757976736.issue43628@roundup.psfhosted.org>


New submission from Yang Feng <charles.fy at foxmail.com>:

In documentation of random.getstate(), it says:
?random.getstate()
Return an object capturing the current internal state of the generator. This object can be passed to setstate() to restore the state.?

random.getstate() takes 0 argument and return the current setting for the weekday to start each week. However, when I give one argument to random.getstate(), the interpreter reports the following error:
----------------------------------------------
>>> import random
>>> random.getstate(1)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: getstate() takes 1 positional argument but 2 were given
----------------------------------------------

Here I have two doubts about the reported errors:
1. Is the TypeError correct? This should be an inconsistent argument number error. There is nothing to do with Type. 
2. Is the detailed error correct? Doc says random.getstate() takes 0 argument, the reported error says getstate() take 1 positional argument. which is inconsistent. Besides, I pass one argument to random.getstate(), but the reported error says 2 were given.


Environment: Python 3.10, Ubuntu 16.04

----------
assignee: docs at python
components: Documentation
messages: 389535
nosy: CharlesFengY, docs at python
priority: normal
severity: normal
status: open
title: Incorrect argument errors for random.getstate()
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43628>
_______________________________________

From report at bugs.python.org  Thu Mar 25 22:44:49 2021
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 26 Mar 2021 02:44:49 +0000
Subject: [issue43628] Incorrect argument errors for random.getstate()
In-Reply-To: <1616723933.11.0.615757976736.issue43628@roundup.psfhosted.org>
Message-ID: <1616726689.35.0.358051849634.issue43628@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +mark.dickinson, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43628>
_______________________________________

From report at bugs.python.org  Thu Mar 25 23:00:23 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 26 Mar 2021 03:00:23 +0000
Subject: [issue43628] Incorrect argument errors for random.getstate()
In-Reply-To: <1616723933.11.0.615757976736.issue43628@roundup.psfhosted.org>
Message-ID: <1616727623.12.0.939918533135.issue43628@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Here's how to use getstate() and setstate():

>>> import random
>>> state = random.getstate()
>>> random.choices('ABCDE', k=8)
['E', 'A', 'B', 'B', 'A', 'A', 'E', 'D']
>>> # restore the previous state
>>> random.setstate(state)
>>> # now, replay the random selections
>>> random.choices('ABCDE', k=8)
['E', 'A', 'B', 'B', 'A', 'A', 'E', 'D']



> 1. Is the TypeError correct? This should be an inconsistent
> argument number error. There is nothing to do with Type. 

Yes, it is correct, but I agree that it is unintuitive.  It just happens to be the Python way to report an incorrect number of arguments as a TypeError.


> 2. Is the detailed error correct? Doc says random.getstate()
> takes 0 argument, the reported error says getstate() take 1
> positional argument. which is inconsistent. 

This is an artifact of how Python implements object orient programming.  No one really likes this, but at some level it can be viewed as being technically correct ? methods prepend an instance argument before calling an underlying function which reports on the number of arguments that it sees.  Presumably, if there were a straight-forward way of improving the error message, it would have been done long ago.

> Besides, I pass one argument to random.getstate(), 
> but the reported error says 2 were given.

Don't pass any arguments into getstate().


> random.getstate() takes 0 argument and return 
> the current setting for the weekday to start each week.

This part doesn't make sense to me.  Why do you think it accepts or returns a weekday?

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43628>
_______________________________________

From report at bugs.python.org  Thu Mar 25 23:23:38 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 26 Mar 2021 03:23:38 +0000
Subject: [issue40758] For 7.2.7. Code Examples,
 distinguish between the Tutorial and other documentation
In-Reply-To: <1590353365.14.0.907078183909.issue40758@roundup.psfhosted.org>
Message-ID: <1616729018.99.0.83694148272.issue40758@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I would think this would go without saying.  The word "tutorial" means example driven instruction.  Previous to now, no one has ever reported confusion about this.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40758>
_______________________________________

From report at bugs.python.org  Thu Mar 25 23:57:11 2021
From: report at bugs.python.org (junyixie)
Date: Fri, 26 Mar 2021 03:57:11 +0000
Subject: [issue43629] fix _PyRun_SimpleFileObject create __main__ module and
 cache. Call this function multiple times,
 the attributes stored in the module dict will affect eachother.
Message-ID: <1616731031.99.0.476866477615.issue43629@roundup.psfhosted.org>


New submission from junyixie <xie.junyi at outlook.com>:

fix _PyRun_SimpleFileObject create __main__ module and cache. Call this function multiple times, the attributes stored in the module dict will affect eachother.

create __main__ module, and cache it.

for example. 
if we run fileA, call _PyRun_SimpleFileObject will create __main__ module, fileA add some attribute in __main__ module dict.

now we run fileB. call _PyRun_SimpleFileObject will load cached __main__ module. now in __main__ module dict, we can get fileA's attribute.


dir(module), We got unexpected results
```
for name in dir(module):
    ...
```

in unittest, if we execute test, and don't exit. (unittest main.py TestProgram), set exit=False.
```
    def __init__(self, module='__main__', defaultTest=None, argv=None,
                    testRunner=None, testLoader=loader.defaultTestLoader,
                    exit=True, verbosity=1, failfast=None, catchbreak=None,
                    buffer=None, warnings=None, *, tb_locals=False):
```

then when unittest load tests. if we use _PyRun_SimpleFileObject to run unittest, it will Repeated load test cases
```
        for name in dir(module):
            obj = getattr(module, name)
            if isinstance(obj, type) and issubclass(obj, case.TestCase):
                tests.append(self.loadTestsFromTestCase(obj))
```


```
int
_PyRun_SimpleFileObject(FILE *fp, PyObject *filename, int closeit,
                        PyCompilerFlags *flags)
{
    PyObject *m, *d, *v;
    int set_file_name = 0, ret = -1;

    m = PyImport_AddModule("__main__");
    if (m == NULL)
        return -1;
    Py_INCREF(m);
    d = PyModule_GetDict(m);
```

----------
components: C API
messages: 389538
nosy: JunyiXie
priority: normal
severity: normal
status: open
title: fix _PyRun_SimpleFileObject create __main__ module and cache. Call this function multiple times, the attributes stored in the module dict will affect eachother.
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43629>
_______________________________________

From report at bugs.python.org  Fri Mar 26 00:01:35 2021
From: report at bugs.python.org (junyixie)
Date: Fri, 26 Mar 2021 04:01:35 +0000
Subject: [issue43629] fix _PyRun_SimpleFileObject create __main__ module and
 cache. Call this function multiple times,
 the attributes stored in the module dict will affect eachother.
In-Reply-To: <1616731031.99.0.476866477615.issue43629@roundup.psfhosted.org>
Message-ID: <1616731295.42.0.000119978023581.issue43629@roundup.psfhosted.org>


Change by junyixie <xie.junyi at outlook.com>:


----------
keywords: +patch
pull_requests: +23773
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25023

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43629>
_______________________________________

From report at bugs.python.org  Fri Mar 26 00:13:17 2021
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 26 Mar 2021 04:13:17 +0000
Subject: [issue40066] Enum: modify __repr__, __str__; update docs
In-Reply-To: <1585165738.23.0.618463548627.issue40066@roundup.psfhosted.org>
Message-ID: <1616731997.52.0.439978589371.issue40066@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
components: +Library (Lib)
title: Enum._convert should change __repr__ and/or __str__ to use module name instead of class name -> Enum: modify __repr__, __str__; update docs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40066>
_______________________________________

From report at bugs.python.org  Fri Mar 26 00:51:41 2021
From: report at bugs.python.org (Fred Drake)
Date: Fri, 26 Mar 2021 04:51:41 +0000
Subject: [issue43620] os.path.join does not use os.sep as documentation claims
In-Reply-To: <1616618152.23.0.688812989277.issue43620@roundup.psfhosted.org>
Message-ID: <1616734301.5.0.621532274463.issue43620@roundup.psfhosted.org>


Fred Drake <fdrake at gmail.com> added the comment:

Just reviewed the documentation for both os.sep and os.path.join().

The os.sep docs do not suggest it can be set, and the reference in the os.path.join() description is silent regarding that, so can be read as Jared did.  I don't recall this coming up before, but... there's a lot I don't remember at this point.  --sigh--

Removing the reference to os.sep from the os.path.join() description would not be confusing, IMO.  Clearly, the ambiguity can bite.

I'd be open to a patch to remove the reference to os.sep from the os.path.join() docs.  Reopening, but removing 3.6 and 3.7 since they're in security-fix-only mode.

----------
keywords: +easy
resolution: not a bug -> 
stage: resolved -> needs patch
status: closed -> open
versions:  -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43620>
_______________________________________

From report at bugs.python.org  Fri Mar 26 02:37:07 2021
From: report at bugs.python.org (junyixie)
Date: Fri, 26 Mar 2021 06:37:07 +0000
Subject: [issue43629] fix _PyRun_SimpleFileObject create __main__ module and
 cache. Call this function multiple times,
 the attributes stored in the module dict will affect eachother.
In-Reply-To: <1616731031.99.0.476866477615.issue43629@roundup.psfhosted.org>
Message-ID: <1616740627.9.0.148133411902.issue43629@roundup.psfhosted.org>


Change by junyixie <xie.junyi at outlook.com>:


----------
resolution:  -> wont fix

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43629>
_______________________________________

From report at bugs.python.org  Fri Mar 26 03:44:05 2021
From: report at bugs.python.org (junyixie)
Date: Fri, 26 Mar 2021 07:44:05 +0000
Subject: [issue43630] unittest use dir(module) to load test cases. Run
 unittest file by _PyRun_SimpleFileObject, have bug
Message-ID: <1616744645.89.0.654590841041.issue43630@roundup.psfhosted.org>


New submission from junyixie <xie.junyi at outlook.com>:

_PyRun_SimpleFileObject load __main__ module at cache. Call this function multiple times, the attributes stored in the module dict will affect eachother.


for example. 
if we run test_A.py, call _PyRun_SimpleFileObject will create __main__ module, test_A.py add some attribute in __main__ module dict.

now we run test_B.py. call _PyRun_SimpleFileObject will load cached __main__ module. now in __main__ module dict, we can get test_A's attribute.




in unittest, if we execute test, and don't exit. (unittest main.py TestProgram), set exit=False.
```
    def __init__(self, module='__main__', defaultTest=None, argv=None,
                    testRunner=None, testLoader=loader.defaultTestLoader,
                    exit=True, verbosity=1, failfast=None, catchbreak=None,
                    buffer=None, warnings=None, *, tb_locals=False):
```

dir(module), We got unexpected results
```
for name in dir(module):
    ...
```

then when unittest load tests. if we use _PyRun_SimpleFileObject to run unittest, it will Repeated load test cases
```
        for name in dir(module):
            obj = getattr(module, name)
            if isinstance(obj, type) and issubclass(obj, case.TestCase):
                tests.append(self.loadTestsFromTestCase(obj))
```


```
int
_PyRun_SimpleFileObject(FILE *fp, PyObject *filename, int closeit,
                        PyCompilerFlags *flags)
{
    PyObject *m, *d, *v;
    int set_file_name = 0, ret = -1;

    m = PyImport_AddModule("__main__");
    if (m == NULL)
        return -1;
    Py_INCREF(m);
    d = PyModule_GetDict(m);
```

----------
messages: 389540
nosy: JunyiXie
priority: normal
severity: normal
status: open
title: unittest use dir(module) to load test cases. Run unittest file by _PyRun_SimpleFileObject, have bug

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43630>
_______________________________________

From report at bugs.python.org  Fri Mar 26 04:15:38 2021
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 26 Mar 2021 08:15:38 +0000
Subject: [issue43631] Update to OpenSSL 1.1.1k
Message-ID: <1616746538.63.0.13329268116.issue43631@roundup.psfhosted.org>


New submission from Christian Heimes <lists at cheimes.de>:

OpenSSL 1.1.1k contains fixes for two high severity CVEs

https://www.openssl.org/news/vulnerabilities.html
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3450
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3449

----------
assignee: christian.heimes
components: SSL, Windows, macOS
messages: 389541
nosy: christian.heimes, ned.deily, paul.moore, ronaldoussoren, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Update to OpenSSL 1.1.1k
type: security
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43631>
_______________________________________

From report at bugs.python.org  Fri Mar 26 04:20:26 2021
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 26 Mar 2021 08:20:26 +0000
Subject: [issue43631] Update to OpenSSL 1.1.1k
In-Reply-To: <1616746538.63.0.13329268116.issue43631@roundup.psfhosted.org>
Message-ID: <1616746826.76.0.613440357726.issue43631@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
keywords: +patch
pull_requests: +23774
pull_request: https://github.com/python/cpython/pull/25024

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43631>
_______________________________________

From report at bugs.python.org  Fri Mar 26 04:48:37 2021
From: report at bugs.python.org (Abraham Macias)
Date: Fri, 26 Mar 2021 08:48:37 +0000
Subject: [issue43626] SIGSEV in PyErr_SetObject
In-Reply-To: <1616699811.01.0.0992968553141.issue43626@roundup.psfhosted.org>
Message-ID: <1616748517.37.0.115684483458.issue43626@roundup.psfhosted.org>


Abraham Macias <amacias at gruposolutia.com> added the comment:

Thank you Victor for your response.
I follow your advice but the output was an error in a different point of the code and I couldn't see any information about memory allocations.

But, I compiled Python 3.7 from source and modified the "Python/errors.c" code where the problem is detected in the following way:

void
PyErr_SetObject(PyObject *exception, PyObject *value)
{
    PyThreadState *tstate = PyThreadState_GET();
    PyObject *exc_value;
    PyObject *tb = NULL;
    _PyErr_StackItem *exc_info = NULL;


    if (exception != NULL &&
        !PyExceptionClass_Check(exception)) {
        PyErr_Format(PyExc_SystemError,
                     "exception %R not a BaseException subclass",
                     exception);
        return;
    }

    Py_XINCREF(value);
    exc_info = _PyErr_GetTopmostException(tstate);
    exc_value = exc_info->exc_value;
    if (exc_value != NULL && exc_value != Py_None) {
        /* Implicit exception chaining */
        printf("exc_value=%p\n", exc_value);
        printf("exc_info=%p\n", exc_info);
        printf("tstate=%p\n", tstate);
        printf("traceback=%p\n", exc_info->exc_traceback);
        printf("exc_value.ob_type=%p\n", exc_value->ob_type);
        Py_INCREF(exc_value);
       
In this way I had the pointer printed just before the error happening:

exc_value=0x73726573756e69
exc_info=0x7f83bfafacb8
tstate=0x5605dcd41330
traceback=0x6b6f0100
Segmentation fault (core dumped)

And by using gdb I printed the memory contents:

(gdb) x/32c 0x7f83bfafacb8
0x7f83bfafacb8:	111 'o'	115 's'	99 'c'	99 'c'	46 '.'	97 'a'	100 'd'	109 'm'
0x7f83bfafacc0:	105 'i'	110 'n'	117 'u'	115 's'	101 'e'	114 'r'	115 's'	0 '\000'
0x7f83bfafacc8:	0 '\000'	1 '\001'	111 'o'	107 'k'	0 '\000'	0 '\000'	0 '\000'	0 '\000'
0x7f83bfafacd0:	0 '\000'	0 '\000'	0 '\000'	-16 '\360'	63 '?'	0 '\000'	0 '\000'	0 '\000'

If you check the original post you will see:

#15 0x000000000053f732 in PyEval_EvalFrameEx (throwflag=0, 
    f=Frame 0x17882e8, for file /usr/local/lib/python3.7/dist-packages/bson/__init__.py, line 1013, in decode_all (data=b'V\x00\x00\x00\x03cursor\x00=\x00\x00\x00\x04firstBatch\x00\x05\x00\x00\x00\x00\x12id\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02ns\x00\x13\x00\x00\x00gecoscc.adminusers\x00\x00\x01ok\x00\x00\x00\x00\x00\x00\x00\xf0?\x00', codec_options=<CodecOptions at remote 0x7f1ab4ac2208>, view=<memoryview at remote 0x7f1ab5375708>, data_len=86, docs=[], position=0, end=85)) at ../Python/ceval.c:547

So, somehow the "oscc.adminusers\x00\x00\x01ok\x00" part of the message is written over the exc_info memory.

That makes me think that this is a problem in pymongo module. I will report this bug to them.

Thank you very much!

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43626>
_______________________________________

From report at bugs.python.org  Fri Mar 26 05:39:51 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Mar 2021 09:39:51 +0000
Subject: [issue43626] SIGSEV in PyErr_SetObject
In-Reply-To: <1616699811.01.0.0992968553141.issue43626@roundup.psfhosted.org>
Message-ID: <1616751591.52.0.836249732842.issue43626@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> That makes me think that this is a problem in pymongo module. I will report this bug to them.

Yeah, in 90% of cases, the bug comes from a third party C extensions. That's why Python 3.10 now dumps the list of 3rd party C extensions on a fatal error :-)

https://twitter.com/VictorStinner/status/1374736944022876169

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43626>
_______________________________________

From report at bugs.python.org  Fri Mar 26 06:28:07 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Fri, 26 Mar 2021 10:28:07 +0000
Subject: [issue43094] sqlite3 signature discrepancies between documentation
 and implementation
In-Reply-To: <1612210210.19.0.0751315887137.issue43094@roundup.psfhosted.org>
Message-ID: <1616754487.88.0.501299793222.issue43094@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

> I'd prefer writing a PEP and fix all modules once and for all.

Berker, I started drafting a PEP. Would you be interested in helping?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43094>
_______________________________________

From report at bugs.python.org  Fri Mar 26 07:02:12 2021
From: report at bugs.python.org (Irit Katriel)
Date: Fri, 26 Mar 2021 11:02:12 +0000
Subject: [issue24132] Direct sub-classing of pathlib.Path
In-Reply-To: <1430890013.04.0.304568332905.issue24132@psf.upfronthosting.co.za>
Message-ID: <1616756532.37.0.0458220792389.issue24132@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
components: +Library (Lib)
stage: patch review -> needs patch
type: behavior -> enhancement
versions: +Python 3.10 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24132>
_______________________________________

From report at bugs.python.org  Fri Mar 26 07:50:20 2021
From: report at bugs.python.org (=?utf-8?b?5rGf5p2J?=)
Date: Fri, 26 Mar 2021 11:50:20 +0000
Subject: [issue43632] an error in the documentation of descriptor
Message-ID: <1616759420.96.0.930885949934.issue43632@roundup.psfhosted.org>


New submission from ?? <2353381a at gmail.com>:

In this section 
 https://docs.python.org/3.8/howto/descriptor.html#functions-and-methods , there is an error:

the output of CMD 'd.f.__func__' should be same as the output of 'D.__dict__['f']'. Here the former should be '<function D.f at 0x00C45070>', but not '<function D.f at 0x1012e5ae8>'

----------
assignee: docs at python
components: Documentation
messages: 389545
nosy: 2353381a, docs at python
priority: normal
severity: normal
status: open
title: an error in the documentation of descriptor
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43632>
_______________________________________

From report at bugs.python.org  Fri Mar 26 07:58:04 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Mar 2021 11:58:04 +0000
Subject: [issue43624] Add underscore as a decimal separator for string
 formatting
In-Reply-To: <1616692747.49.0.677529428018.issue43624@roundup.psfhosted.org>
Message-ID: <1616759884.14.0.820887393287.issue43624@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> If we do anything for float, we should do the same for decimal.Decimal.

and complex ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43624>
_______________________________________

From report at bugs.python.org  Fri Mar 26 08:01:52 2021
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 26 Mar 2021 12:01:52 +0000
Subject: [issue43632] an error in the documentation of descriptor
In-Reply-To: <1616759420.96.0.930885949934.issue43632@roundup.psfhosted.org>
Message-ID: <1616760112.08.0.774287589896.issue43632@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/issue43632>
_______________________________________

From report at bugs.python.org  Fri Mar 26 08:09:26 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Mar 2021 12:09:26 +0000
Subject: [issue43624] Add underscore as a decimal separator for string
 formatting
In-Reply-To: <1616692747.49.0.677529428018.issue43624@roundup.psfhosted.org>
Message-ID: <1616760566.67.0.30286807868.issue43624@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

How backward incompatible and annoying would it be to modify the behavior of the existing "_f" format?

Do you see use cases which only want to group digits in the integer part but not the fractional part?

According to https://discuss.python.org/t/add-underscore-as-a-thousandths-separator-for-string-formatting/7407 discussion, grouping digits was first designed for integers, and the fractional part of floats was simply ignored/forgotten. I mean, it doesn't sound like a deliberate choice to not group digits in the fractional part.

The advantage of changing "_f" format is to keep backward compatibility: Python 3.9 and older would not group digits in the fractional part, but at least they don't fail with an error. If you write code with "_._f" format, you need a fallback code path for Python 3.9 and older:

if sys.version_info >= (3, 10):
   text = f"my {...} very {...} long {...} and {...} complex {...} format string: x={x:_._f}"
else:
   text = f"my {...} very {...} long {...} and {...} complex {...} format string: x={x:_f}"

Or:

text = f"my {...} very {...} long {...} and {...} complex {...} format string:" + (f"x={x:_f}" if sys.version_info >= (3, 10) else "x={x:_f}")

Or many other variants.

The main drawback is the risk to break tests relying on the exact output.

About the separator character and the number of digits per group, IMO there is no standard working in all countries and all languages. But since we have a strict rule of 3 digits with "_" separator, I am fine with doing the same for the fractional part. It's an "arbitrary" choice, but at least, it's consistent.

People wanting a different format per locale/language should write their own function. Once enough people will agree on such API, we can consider to add it to the stdlib. But for now, IMO 3 digits with "_" is good enough.

By the way, I agree that it's hard to read numbers with many digits in the decimal part ;-)

>>> f"{1/7:_.30f}"
'0.142857142857142849212692681249'

>>> f"{10**10+1/7:_.10f}"
'10_000_000_000.1428565979'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43624>
_______________________________________

From report at bugs.python.org  Fri Mar 26 08:27:57 2021
From: report at bugs.python.org (Irit Katriel)
Date: Fri, 26 Mar 2021 12:27:57 +0000
Subject: [issue12638] urllib.URLopener prematurely deletes files on cleanup
In-Reply-To: <1311608098.49.0.512505187556.issue12638@psf.upfronthosting.co.za>
Message-ID: <1616761677.61.0.240041792336.issue12638@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

I think this is out of date as this feature was deprecated in issue10050.

----------
components: +Library (Lib) -None
nosy: +iritkatriel
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12638>
_______________________________________

From report at bugs.python.org  Fri Mar 26 09:59:35 2021
From: report at bugs.python.org (Mario Corchero)
Date: Fri, 26 Mar 2021 13:59:35 +0000
Subject: [issue41906] logging.config.dictConfig does not work with callable
 filters
In-Reply-To: <1601599406.74.0.279190575587.issue41906@roundup.psfhosted.org>
Message-ID: <1616767175.47.0.333265682754.issue41906@roundup.psfhosted.org>


Mario Corchero <mariocj89 at gmail.com> added the comment:

Vinay would you consider a patch for logging where dictConfig allows taking objects directly in addition to the reference id?

That would allow the following:

```

def noErrorLogs(param):
    return 1 if param.levelno < 40 else 0

logconfig_dict = {
    "handlers": {
        "console": {
            "class": "logging.StreamHandler",
            "level": "DEBUG",
            "stream": "ext://sys.stdout",
            "filters": [noErrorLogs]
        }
    },
    "root": {"level": "DEBUG", "handlers": ["console"]},
    "version": 1,
}
dictConfig(logconfig_dict)
```

or alternatively passing them on declaration:

```
logconfig_dict = {
    'filters': {
        'myfilter': noErrorLogs,
    },
    "handlers": {
        "console": {
            "class": "logging.StreamHandler",
            "level": "DEBUG",
            "stream": "ext://sys.stdout",
            "filters": ["myfilter"]
        }
    },
    "root": {"level": "DEBUG", "handlers": ["console"]},
    "version": 1,
}
dictConfig(logconfig_dict)
```

I'm happy to put a patch together if that looks good to you.

----------
nosy: +mariocj89

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41906>
_______________________________________

From report at bugs.python.org  Fri Mar 26 10:03:55 2021
From: report at bugs.python.org (Jared Sutton)
Date: Fri, 26 Mar 2021 14:03:55 +0000
Subject: [issue43620] os.path.join does not use os.sep as documentation claims
In-Reply-To: <1616618152.23.0.688812989277.issue43620@roundup.psfhosted.org>
Message-ID: <1616767435.7.0.828459626028.issue43620@roundup.psfhosted.org>


Change by Jared Sutton <jpsutton at gmail.com>:


----------
keywords: +patch
pull_requests: +23775
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/25025

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43620>
_______________________________________

From report at bugs.python.org  Fri Mar 26 10:13:47 2021
From: report at bugs.python.org (Jared Sutton)
Date: Fri, 26 Mar 2021 14:13:47 +0000
Subject: [issue43620] os.path.join does not use os.sep as documentation claims
In-Reply-To: <1616618152.23.0.688812989277.issue43620@roundup.psfhosted.org>
Message-ID: <1616768027.68.0.511704919026.issue43620@roundup.psfhosted.org>


Jared Sutton <jpsutton at gmail.com> added the comment:

Thank you for understanding my position, Fred. I submitted a draft PR (25025) for this bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43620>
_______________________________________

From report at bugs.python.org  Fri Mar 26 10:25:25 2021
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 26 Mar 2021 14:25:25 +0000
Subject: [issue43094] sqlite3 signature discrepancies between documentation
 and implementation
In-Reply-To: <1612210210.19.0.0751315887137.issue43094@roundup.psfhosted.org>
Message-ID: <1616768725.43.0.106568478748.issue43094@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:

> Berker, I started drafting a PEP. Would you be interested in helping?

Of course! I may be not be able to respond to you quickly in the next few weeks, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43094>
_______________________________________

From report at bugs.python.org  Fri Mar 26 11:07:52 2021
From: report at bugs.python.org (Irit Katriel)
Date: Fri, 26 Mar 2021 15:07:52 +0000
Subject: [issue41506] Inclusion or documentation of extended with syntax in 3.9
In-Reply-To: <1596850320.21.0.142080709573.issue41506@roundup.psfhosted.org>
Message-ID: <1616771272.38.0.654538831712.issue41506@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
assignee:  -> docs at python
components: +Documentation, Interpreter Core
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41506>
_______________________________________

From report at bugs.python.org  Fri Mar 26 11:27:54 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 26 Mar 2021 15:27:54 +0000
Subject: [issue43632] an error in the documentation of descriptor
In-Reply-To: <1616759420.96.0.930885949934.issue43632@roundup.psfhosted.org>
Message-ID: <1616772474.43.0.948191049613.issue43632@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: docs at python -> rhettinger
priority: normal -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43632>
_______________________________________

From report at bugs.python.org  Fri Mar 26 11:33:41 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 26 Mar 2021 15:33:41 +0000
Subject: [issue43632] an error in the documentation of descriptor
In-Reply-To: <1616759420.96.0.930885949934.issue43632@roundup.psfhosted.org>
Message-ID: <1616772821.28.0.680393543433.issue43632@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks for the report.

This has already been fixed for the 3.9 release and later:

https://docs.python.org/3.9/howto/descriptor.html#functions-and-methods

It was minor enough to not warrant a backport to 3.8.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed
versions:  -Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43632>
_______________________________________

From report at bugs.python.org  Fri Mar 26 12:02:42 2021
From: report at bugs.python.org (Fred Drake)
Date: Fri, 26 Mar 2021 16:02:42 +0000
Subject: [issue43620] os.path.join does not use os.sep as documentation claims
In-Reply-To: <1616618152.23.0.688812989277.issue43620@roundup.psfhosted.org>
Message-ID: <1616774562.59.0.972256230208.issue43620@roundup.psfhosted.org>


Fred Drake <fdrake at gmail.com> added the comment:


New changeset 21a2cabb3795f5170c746ab8f29e9d25c7442550 by Jared Sutton in branch 'master':
bpo-43620: Remove reference to os.sep from os.path.join() doc (#25025)
https://github.com/python/cpython/commit/21a2cabb3795f5170c746ab8f29e9d25c7442550


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43620>
_______________________________________

From report at bugs.python.org  Fri Mar 26 12:03:30 2021
From: report at bugs.python.org (miss-islington)
Date: Fri, 26 Mar 2021 16:03:30 +0000
Subject: [issue43620] os.path.join does not use os.sep as documentation claims
In-Reply-To: <1616618152.23.0.688812989277.issue43620@roundup.psfhosted.org>
Message-ID: <1616774610.69.0.0654934573664.issue43620@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: +23777
pull_request: https://github.com/python/cpython/pull/25027

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43620>
_______________________________________

From report at bugs.python.org  Fri Mar 26 13:24:41 2021
From: report at bugs.python.org (Fred Drake)
Date: Fri, 26 Mar 2021 17:24:41 +0000
Subject: [issue43620] os.path.join does not use os.sep as documentation claims
In-Reply-To: <1616618152.23.0.688812989277.issue43620@roundup.psfhosted.org>
Message-ID: <1616779481.7.0.967216988116.issue43620@roundup.psfhosted.org>


Fred Drake <fdrake at gmail.com> added the comment:


New changeset f311290f091957653bba5ebfda28ad981bb78363 by Miss Islington (bot) in branch '3.9':
bpo-43620: Remove reference to os.sep from os.path.join() doc (GH-25025) (#25027)
https://github.com/python/cpython/commit/f311290f091957653bba5ebfda28ad981bb78363


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43620>
_______________________________________

From report at bugs.python.org  Fri Mar 26 13:34:40 2021
From: report at bugs.python.org (Maxime Mouchet)
Date: Fri, 26 Mar 2021 17:34:40 +0000
Subject: [issue43633] Improve the textual representation of IPv4-mapped IPv6
 addresses
Message-ID: <1616780080.54.0.443105360022.issue43633@roundup.psfhosted.org>


New submission from Maxime Mouchet <max at maxmouchet.com>:

Python supports IPv4-mapped IPv6 addresses as defined by RFC 4038:
 "the IPv6 address ::FFFF:x.y.z.w represents the IPv4 address x.y.z.w.?

The current behavior is as follows:

   from ipaddress import ip_address
   addr = ip_address('::ffff:8.8.4.4') # IPv6Address('::ffff:808:404')
   addr.ipv4_mapped # IPv4Address('8.8.4.4')

Note that the textual representation of the IPv6Address is *not* in IPv4-mapped format.
It prints ::ffff:808:404 instead of ::ffff:8.8.4.4.
This is technically correct, but it?s somewhat frustrating as it makes it harder to read IPv4s embedded in IPv6 addresses.

My proposal would be to check, in __str__, if an IPv6 is an IPv4-mapped, and to return the appropriate representation :

   from ipaddress import ip_address
   addr = ip_address('::ffff:8.8.4.4')

   # Current behavior
   str(addr)  # '::ffff:808:404'
   repr(addr) # IPv6Address('::ffff:808:404')

   # Proposed behavior
   str(addr)  # '::ffff:8.8.4.4'
   repr(addr) # IPv6Address('::ffff:8.8.4.4')

A few data points:
- Julia prints ::ffff:808:404 (current behavior)
- C (glibc) and ClickHouse prints ::ffff:8.8.4.4 (proposed behavior)

----------
components: Library (Lib)
messages: 389556
nosy: maxmouchet
priority: normal
severity: normal
status: open
title: Improve the textual representation of IPv4-mapped IPv6 addresses
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43633>
_______________________________________

From report at bugs.python.org  Fri Mar 26 14:42:14 2021
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 26 Mar 2021 18:42:14 +0000
Subject: [issue42136] [importlib] deprecate module_repr() methods
In-Reply-To: <1603495128.4.0.940710955069.issue42136@roundup.psfhosted.org>
Message-ID: <1616784134.37.0.851140856059.issue42136@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
assignee:  -> brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42136>
_______________________________________

From report at bugs.python.org  Fri Mar 26 14:46:08 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 26 Mar 2021 18:46:08 +0000
Subject: [issue43564] ftp tests in test_urllib2net fail instead of skipping on
 unreachable network
In-Reply-To: <1616188869.43.0.436044106244.issue43564@roundup.psfhosted.org>
Message-ID: <1616784368.27.0.685483938382.issue43564@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +giampaolo.rodola, orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43564>
_______________________________________

From report at bugs.python.org  Fri Mar 26 14:46:47 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 26 Mar 2021 18:46:47 +0000
Subject: [issue43564] ftp tests in test_urllib2net should skip on unreachable
 network
In-Reply-To: <1616188869.43.0.436044106244.issue43564@roundup.psfhosted.org>
Message-ID: <1616784407.59.0.722980036814.issue43564@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: ftp tests in test_urllib2net fail instead of skipping on unreachable network -> ftp tests in test_urllib2net should skip on unreachable network

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43564>
_______________________________________

From report at bugs.python.org  Fri Mar 26 14:47:55 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 26 Mar 2021 18:47:55 +0000
Subject: [issue43565] PyUnicode_KIND macro does not has specified return type
In-Reply-To: <1616202653.73.0.639291876959.issue43565@roundup.psfhosted.org>
Message-ID: <1616784475.35.0.298320596549.issue43565@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +benjamin.peterson, ezio.melotti, lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43565>
_______________________________________

From report at bugs.python.org  Fri Mar 26 14:48:57 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 26 Mar 2021 18:48:57 +0000
Subject: [issue43568] Drop support for Mac OS X < 10.3 module linking
In-Reply-To: <1616245702.65.0.278864424752.issue43568@roundup.psfhosted.org>
Message-ID: <1616784537.84.0.825604301085.issue43568@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43568>
_______________________________________

From report at bugs.python.org  Fri Mar 26 14:55:20 2021
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 26 Mar 2021 18:55:20 +0000
Subject: [issue42136] [importlib] deprecate module_repr() methods
In-Reply-To: <1603495128.4.0.940710955069.issue42136@roundup.psfhosted.org>
Message-ID: <1616784920.92.0.123723300645.issue42136@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:


New changeset 1899087b21119c5c64cd41619b542c0bf0ab5751 by Brett Cannon in branch 'master':
bpo-42136: Deprecate module_repr() as found in importlib (GH-25022)
https://github.com/python/cpython/commit/1899087b21119c5c64cd41619b542c0bf0ab5751


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42136>
_______________________________________

From report at bugs.python.org  Fri Mar 26 14:58:31 2021
From: report at bugs.python.org (JustAnotherArchivist)
Date: Fri, 26 Mar 2021 18:58:31 +0000
Subject: [issue43634] Extensions build does not respect --jobs setting
Message-ID: <1616785110.97.0.460566550998.issue43634@roundup.psfhosted.org>


New submission from JustAnotherArchivist <justanotherarchivist at riseup.net>:

The extension building does not respect the --jobs option passed to make. Specifically, in that step, `python setup.py build` always spawns as many gcc processes as there are CPU cores available regardless of that option. This caused problems for me because I have a VM that sees all host machine CPU cores but only has a limited amount of RAM. Despite running `make -j 4`, many more gcc processes are spawned, and this immediately causes memory starvation and a system freeze after a few seconds.

The reason for this is that setup.py blindly enables parallelism in the extension compilation if '-j' appears in the MAKEFLAGS at 3.9.2/setup.py:355. Later on, distutils uses os.cpu_count to set the worker count, i.e. the '-j' *value* is ignored. This behaviour was first introduced with #5309 as far as I can see, though I haven't tested anything other than version 3.9.2.

Hacky workaround: patching the above setup.py line to `self.parallel = 4`.

Cf. https://github.com/pyenv/pyenv/issues/1857

----------
components: Build
messages: 389558
nosy: JustAnotherArchivist
priority: normal
severity: normal
status: open
title: Extensions build does not respect --jobs setting
type: resource usage
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43634>
_______________________________________

From report at bugs.python.org  Fri Mar 26 15:06:39 2021
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 26 Mar 2021 19:06:39 +0000
Subject: [issue42136] [importlib] deprecate module_repr() methods
In-Reply-To: <1603495128.4.0.940710955069.issue42136@roundup.psfhosted.org>
Message-ID: <1616785599.33.0.228935408475.issue42136@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
assignee: brett.cannon -> 
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42136>
_______________________________________

From report at bugs.python.org  Fri Mar 26 15:08:50 2021
From: report at bugs.python.org (Batuhan Taskaya)
Date: Fri, 26 Mar 2021 19:08:50 +0000
Subject: [issue43609] ast.unparse-ing a FunctionType gives ambiguous result
In-Reply-To: <1616552087.93.0.261462178392.issue43609@roundup.psfhosted.org>
Message-ID: <1616785730.66.0.0641826988554.issue43609@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:

> @BTaskaya I've seen this in third party ides and type checker. For example they are referring to "Union[Callable[[], Union[int, str]], None]" as "() -> (int | str) | None" where there are parentheses around the returns.

Though you can not simple parse this and expect to get the AST you gave as an example (fun2). This would be parsed like
FunctionType(
    argtypes=[],
    returns=BinOp(
        left=BinOp(
            left=Name(id='int', ctx=Load()),
            op=BitOr(),
            right=Name(id='str', ctx=Load())),
        op=BitOr(),
        right=Constant(value=None)))

and we would roundtrip it;
>>> source = '() -> (int | str) | None'
>>> ast1 = ast.parse(source, mode='func_type')
>>> ast2 = ast.parse(ast.unparse(ast1), mode='func_type')
>>> ast.dump(ast1) == ast.dump(ast2)
True


I get what you mean (like 2 separate nodes connected with Union[]) though you can not simply parse the func_type syntax ( () -> ... ) with the normal parser, so you can't use it with binary or. It seems like this is not a bug on ourside, but rather a bug on the creator of this source (like union of func type and binary or).

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43609>
_______________________________________

From report at bugs.python.org  Fri Mar 26 15:09:18 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 26 Mar 2021 19:09:18 +0000
Subject: [issue43576] python3.6.4 os.environ error when write chinese to file
In-Reply-To: <1616302012.93.0.356074990603.issue43576@roundup.psfhosted.org>
Message-ID: <1616785758.29.0.0751561772413.issue43576@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

3.6 only gets security patches.  You or someone needs to show an unfixed bug in master.  Your code runs for me on Windows, whereas you appear to be using *nix.  Replacing job_name.encode() should have the same behavior.  Do you see the same with job_name="??" at the top instead?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43576>
_______________________________________

From report at bugs.python.org  Fri Mar 26 15:14:56 2021
From: report at bugs.python.org (Irit Katriel)
Date: Fri, 26 Mar 2021 19:14:56 +0000
Subject: [issue39231] Mistaken notion in tutorial
In-Reply-To: <1578334311.83.0.989380005846.issue39231@roundup.psfhosted.org>
Message-ID: <1616786096.35.0.738053141639.issue39231@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
keywords: +patch
nosy: +iritkatriel
nosy_count: 4.0 -> 5.0
pull_requests: +23778
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25029

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39231>
_______________________________________

From report at bugs.python.org  Fri Mar 26 15:17:28 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 26 Mar 2021 19:17:28 +0000
Subject: [issue43585] perf_counter() returns computers uptime
In-Reply-To: <1616344693.53.0.493745901493.issue43585@roundup.psfhosted.org>
Message-ID: <1616786248.45.0.0698216789066.issue43585@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Eryk, if I understand correctly, this should be closed as 'not a bug'.  Correct?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43585>
_______________________________________

From report at bugs.python.org  Fri Mar 26 15:25:36 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 26 Mar 2021 19:25:36 +0000
Subject: [issue43594] Subclass of both `ABC` and `ABCMeta` breaks on
 `__subclasscheck__`
In-Reply-To: <1616420520.96.0.331295909751.issue43594@roundup.psfhosted.org>
Message-ID: <1616786736.84.0.138558258345.issue43594@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Verified on Win10 for 3.8-3.10.  3.6 only gets security fixes.

Guido, is the above a bug?  (There is no listed abc or 'metaclass' expert and I don't know.)

----------
nosy: +gvanrossum, terry.reedy
title: A metaclass that inherits both `ABC`  and `ABCMeta` breaks on `__subclasscheck__` -> Subclass of  both `ABC`  and `ABCMeta` breaks on `__subclasscheck__`
versions: +Python 3.10, Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43594>
_______________________________________

From report at bugs.python.org  Fri Mar 26 15:36:05 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 26 Mar 2021 19:36:05 +0000
Subject: [issue43585] perf_counter() returns computers uptime
In-Reply-To: <1616344693.53.0.493745901493.issue43585@roundup.psfhosted.org>
Message-ID: <1616787365.72.0.653378151965.issue43585@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

I think so. But I'll mark it pending for now in case Tobi provides more information to explain why this is a problem. Making time.perf_counter() system-wide in Windows was fixing it to match the documented behavior. That this provides the system uptime is a natural consequence of how the system performance counter is implemented consistently for all processes for the entire uptime of the system.

----------
status: open -> pending
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43585>
_______________________________________

From report at bugs.python.org  Fri Mar 26 15:37:00 2021
From: report at bugs.python.org (Irit Katriel)
Date: Fri, 26 Mar 2021 19:37:00 +0000
Subject: [issue39369] Doc: Update mmap readline method documentation
In-Reply-To: <1579269327.81.0.0431905682961.issue39369@roundup.psfhosted.org>
Message-ID: <1616787420.23.0.326649598561.issue39369@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39369>
_______________________________________

From report at bugs.python.org  Fri Mar 26 15:42:39 2021
From: report at bugs.python.org (Irit Katriel)
Date: Fri, 26 Mar 2021 19:42:39 +0000
Subject: [issue39616] SSLContext.check_hostname description is inaccurate wrt
 match_hostname
In-Reply-To: <1581511027.29.0.201714121734.issue39616@roundup.psfhosted.org>
Message-ID: <1616787759.52.0.891863569614.issue39616@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
versions: +Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39616>
_______________________________________

From report at bugs.python.org  Fri Mar 26 15:47:45 2021
From: report at bugs.python.org (Jennie)
Date: Fri, 26 Mar 2021 19:47:45 +0000
Subject: [issue43635] Documentation needs to declare CalledProcessError as
 potentially resulting from subprocess.run()
Message-ID: <1616788065.3.0.472312141922.issue43635@roundup.psfhosted.org>


New submission from Jennie <sk8tr.girl at gmail.com>:

The documentation for subprocess says that run() can return CalledProcessError...

https://docs.python.org/3/library/subprocess.html#subprocess.run

...but when you click on the link (5th paragraph down) for CalledProcessError, it only lists check_call() and check_output() as methods that can return it.

My understanding is that check_call(), at least, is (becoming?) deprecated. So this section should definitely mention run():

https://docs.python.org/3/library/subprocess.html#subprocess.CalledProcessError

----------
assignee: docs at python
components: Documentation
messages: 389564
nosy: docs at python, jennievh
priority: normal
severity: normal
status: open
title: Documentation needs to declare CalledProcessError as potentially resulting from subprocess.run()
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43635>
_______________________________________

From report at bugs.python.org  Fri Mar 26 15:52:30 2021
From: report at bugs.python.org (miss-islington)
Date: Fri, 26 Mar 2021 19:52:30 +0000
Subject: [issue43620] os.path.join does not use os.sep as documentation claims
In-Reply-To: <1616618152.23.0.688812989277.issue43620@roundup.psfhosted.org>
Message-ID: <1616788350.58.0.760995749467.issue43620@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +23779
pull_request: https://github.com/python/cpython/pull/25030

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43620>
_______________________________________

From report at bugs.python.org  Fri Mar 26 16:04:46 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 26 Mar 2021 20:04:46 +0000
Subject: [issue43605] Eval/exec and comprehension scopes unclear in
 documentation
In-Reply-To: <1616520364.91.0.0936665126175.issue43605@roundup.psfhosted.org>
Message-ID: <1616789086.46.0.539040574613.issue43605@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This is not an execution bug.

https://docs.python.org/3/reference/expressions.html#displays-for-lists-sets-and-dictionaries

"However, aside from the iterable expression in the leftmost for clause, the comprehension is executed in a separate implicitly nested scope. This ensures that names assigned to in the target list don?t ?leak? into the enclosing scope."

So when the passed in locals is not the passed in globals, that means a separate local scope.

https://docs.python.org/3/reference/expressions.html#generator-expressions is a little less clear.

"Variables used in the generator expression are evaluated lazily when the __next__() method is called for the generator object (in the same fashion as normal generators). However, the iterable expression in the leftmost for clause is immediately evaluated, so that an error produced by it will be emitted at the point where the generator expression is defined, rather than at the point where the first value is retrieved. Subsequent for clauses and any filter condition in the leftmost for clause cannot be evaluated in the enclosing scope as they may depend on the values obtained from the leftmost iterable."

By implication, the value expressions are also not evaluated in the enclosing local scope.

I am thinking about adding something to the eval/exec doc, but this issue overlaps with another one about their doc.





https://docs.python.org/3/reference/expressions.html#generator-expressions

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, terry.reedy
stage:  -> needs patch
title: Issue of scopes unclear in documentation, or wrongly implemented -> Eval/exec and comprehension scopes unclear in documentation
versions: +Python 3.10 -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43605>
_______________________________________

From report at bugs.python.org  Fri Mar 26 16:07:07 2021
From: report at bugs.python.org (Fred Drake)
Date: Fri, 26 Mar 2021 20:07:07 +0000
Subject: [issue43620] os.path.join does not use os.sep as documentation claims
In-Reply-To: <1616618152.23.0.688812989277.issue43620@roundup.psfhosted.org>
Message-ID: <1616789227.82.0.25185996923.issue43620@roundup.psfhosted.org>


Fred Drake <fdrake at gmail.com> added the comment:


New changeset 455583b54aaec9a4266ff37dd438cbbd8ec6068a by Miss Islington (bot) in branch '3.8':
bpo-43620: Remove reference to os.sep from os.path.join() doc (GH-25025, GH-5030)
https://github.com/python/cpython/commit/455583b54aaec9a4266ff37dd438cbbd8ec6068a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43620>
_______________________________________

From report at bugs.python.org  Fri Mar 26 16:08:22 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 26 Mar 2021 20:08:22 +0000
Subject: [issue43606] tkinter: initial huge window & no widgets visible
In-Reply-To: <1616526375.72.0.973402567023.issue43606@roundup.psfhosted.org>
Message-ID: <1616789302.74.0.865040030627.issue43606@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy:  -paul.moore, steve.dower, tim.golden, zach.ware
title: PySimpleGUI: initial huge window & no widgets visible -> tkinter: initial huge window & no widgets visible

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43606>
_______________________________________

From report at bugs.python.org  Fri Mar 26 16:08:38 2021
From: report at bugs.python.org (Fred Drake)
Date: Fri, 26 Mar 2021 20:08:38 +0000
Subject: [issue43620] os.path.join does not use os.sep as documentation claims
In-Reply-To: <1616618152.23.0.688812989277.issue43620@roundup.psfhosted.org>
Message-ID: <1616789318.25.0.778400950956.issue43620@roundup.psfhosted.org>


Fred Drake <fdrake at gmail.com> added the comment:

PR applied and backported; closing this.

Thanks, Jared!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43620>
_______________________________________

From report at bugs.python.org  Fri Mar 26 16:45:35 2021
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 26 Mar 2021 20:45:35 +0000
Subject: [issue43576] python3.6.4 os.environ error when write chinese to file
In-Reply-To: <1616302012.93.0.356074990603.issue43576@roundup.psfhosted.org>
Message-ID: <1616791535.68.0.773848896633.issue43576@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

I think this is a locale configuration problem, in which the locale encoding doesn't match the terminal encoding. If so, it can be closed as not a bug.

> export a="??"

In POSIX, the shell reads "??" from the terminal as bytes encoded in the terminal encoding, which could be UTF-8 or some legacy encoding. The value of `a` is set directly as this encoded text. There is no intermediate decode/encode stage in the shell. For a child process that decodes the value of the environment variable, as Python does, the locale's LC_CTYPE encoding should be the same or compatible with the terminal encoding.

> job_name = os.environ['a']
> print(job_name)

In POSIX, sys.stdout.errors, as used by print(), will be "surrogateescape" if the default LC_CTYPE locale is a legacy locale -- which in 3.6 is the case for the "C" locale, since it's usually limited to 7-bit ASCII. "surrogateescape" is also the errors handler for decoding bytes os.environb (POSIX) as text os.environ. When decoding, "surrogateescape" handles non-ASCII byte values that can't be decoded by translating the value into the reserved surrogate range U+DC80 - U+DCFF. When encoding, it translates each surrogate code back to the original byte value in the range 0x80 - 0xFF. 

Given the above setup, byte sequences in os.environb that can't be decoded with the default LC_CTYPE locale encoding will be surrogate escaped in the decoded text  The surrogate-escaped values roundtrip back to bytes when printed, presumably as the terminal encoding.

> with open('name.txt', 'w', encoding='utf-8')as fw:
>    fw.write(job_name)

The default errors handler for open() is "strict" instead of "surrogateescape", so the surrogate-escaped values in job_name cause the encoding to fail.

> Your code runs for me on Windows

In Windows, Python uses the wide-character (16-bit wchar_t) environment of the process for os.environ, and, in 3.6+, it uses the console session's wide-character API for console files such as sys.std* when they aren't redirected to a pipe or disk file. Conventionally, wide-character strings should be valid UTF-16LE text. So getting "??" from os.environ and printing it should 'just work'. The output will even be displayed correctly if the console session uses a font that supports "??", or if it's a pseudoconsole (conpty) session that's attached to a terminal that supports automatic font fallback, such as Windows Terminal.

----------
components: +IO, Interpreter Core, Library (Lib), Unicode -C API
nosy: +eryksun, ezio.melotti, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43576>
_______________________________________

From report at bugs.python.org  Fri Mar 26 16:49:09 2021
From: report at bugs.python.org (Bruno Loff)
Date: Fri, 26 Mar 2021 20:49:09 +0000
Subject: [issue43605] Eval/exec and comprehension scopes unclear in
 documentation
In-Reply-To: <1616520364.91.0.0936665126175.issue43605@roundup.psfhosted.org>
Message-ID: <1616791749.9.0.407871204451.issue43605@roundup.psfhosted.org>


Bruno Loff <bruno.loff at gmail.com> added the comment:

Hmm... OK, if I understand correctly, the evaluation procedure for a (e.g.) list comprehension, as described in the documentation you linked in, is as follows:

* The generator in the leftmost for expression is evaluated in the current local scope. (doc: "The iterable expression in the leftmost for clause is evaluated directly in the enclosing scope and then passed as an argument to the implicitly nested scope.")
* A new nested scope is created, and the iterator object is passed to that new scope as an argument.
* The other for and if clauses are evaluated in the new scope.

As you mention, the documentation does not properly describe in which scope is evaluated the leftmost expression that generates each object (to be placed in the list).

You say that the leftmost expression is also not evaluated in the enclosing scope (which I take means that it is being evaluated in the new nested scope). But notice that sometimes it *seems to be*.

There are two inconsistent behaviors:

1) If evaluated outside of an eval, using local objects works just fine. It is then reasonable to assume that the leftmost expression has access to the locals() of the function it is in. (see the line with the comment `# works as expected` in the first post I made).

2) If evaluated inside an eval the leftmost expression cannot access the locals (see the example I gave). This happens even when locals() is passed to the __locals argument of the call to `eval`.

It seems reasonable that behavior (1) should happen in both cases. In fact, I think it is *very* reasonable to expect that calling eval() on a string should have the exact same effect as if the code that is inside the eval had been written as part of the source code. Don't you think? I believe that this is exactly what happens, e.g., in Lisp.

I would guess this is just a bug, but maybe there is some technical reason why this is not possible. If that is (sadly) the case, this should be explained in the documentation.

Currently I don't really have a mental model for what happens when I call `eval`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43605>
_______________________________________

From report at bugs.python.org  Fri Mar 26 17:09:17 2021
From: report at bugs.python.org (miss-islington)
Date: Fri, 26 Mar 2021 21:09:17 +0000
Subject: [issue43354] xmlrpc.client: Fault.faultCode erroneously documented to
 be a string, should be int
In-Reply-To: <1614606151.94.0.783784524766.issue43354@roundup.psfhosted.org>
Message-ID: <1616792957.87.0.457288539802.issue43354@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 027b6699276ed8d9f68425697ac89bf61e54e6b9 by J?rgen Gmach in branch 'master':
bpo-43354: xmlrpc: Fix type documentation for Fault.faultCode (GH-24707)
https://github.com/python/cpython/commit/027b6699276ed8d9f68425697ac89bf61e54e6b9


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43354>
_______________________________________

From report at bugs.python.org  Fri Mar 26 19:12:04 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Mar 2021 23:12:04 +0000
Subject: [issue43576] python3.6.4 os.environ error when write chinese to file
In-Reply-To: <1616302012.93.0.356074990603.issue43576@roundup.psfhosted.org>
Message-ID: <1616800324.51.0.386656629734.issue43576@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Python works as expected: the UTF-8 codec doesn't allow to encode surrogate characters.

Surrogate characters are coming from os.environ['a'] because this environment variable contains bytes which cannot be decoded from the sys.getfilesystemencoding().

You should fix your system setup, especially the locale encoding. The strings stored in the "a" environment variable was not encoded to the Python filesystem encoding:
https://docs.python.org/dev/glossary.html#term-filesystem-encoding-and-error-handler

If you are lost with locale encodings, you can attempt to encode everything in UTF-8 and enables the Python UTF-8 Mode:
https://docs.python.org/dev/library/os.html#python-utf-8-mode

Good luck with your setup ;-)

Hint: use print(ascii(job_name)) to dump the string content.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43576>
_______________________________________

From report at bugs.python.org  Fri Mar 26 19:13:42 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Mar 2021 23:13:42 +0000
Subject: [issue43576] python3.6.4 os.environ error when write chinese to file
In-Reply-To: <1616302012.93.0.356074990603.issue43576@roundup.psfhosted.org>
Message-ID: <1616800422.4.0.793647425398.issue43576@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Oh, I forgot to note that Windows is not affected by this issue, since Windows provides directly environment variables as Unicode, and so Python doesn't need to decode byte strings to read os.environ['a'] ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43576>
_______________________________________

From report at bugs.python.org  Fri Mar 26 19:17:05 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 26 Mar 2021 23:17:05 +0000
Subject: [issue43594] Subclass of both `ABC` and `ABCMeta` breaks on
 `__subclasscheck__`
In-Reply-To: <1616420520.96.0.331295909751.issue43594@roundup.psfhosted.org>
Message-ID: <1616800625.47.0.722339798443.issue43594@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

I think it's strange code -- the mixin wants to be a metaclass but also an ABC (which is not a meta class). Unless there's a serious use case I'm inclinded to reply "don't care".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43594>
_______________________________________

From report at bugs.python.org  Fri Mar 26 19:52:26 2021
From: report at bugs.python.org (Terry Davis)
Date: Fri, 26 Mar 2021 23:52:26 +0000
Subject: [issue43624] Add underscore as a decimal separator for string
 formatting
In-Reply-To: <1616692747.49.0.677529428018.issue43624@roundup.psfhosted.org>
Message-ID: <1616802746.48.0.863239779292.issue43624@roundup.psfhosted.org>


Terry Davis <terry.y.davis at gmail.com> added the comment:

Good point Victor, though I wonder how likely it is that a person using 3.10 would only use this particular new feature, and have an otherwise backwards-compatible codebase.

This isn't something that I asked about out of necessity, and there hasn't been any other discussion of this idea that anyone can remember.

On the other hand, I suppose it would be possible to have a feature flag that can be used to disable decimal underscores in 3.10 to prevent test failures. Just spitballing...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43624>
_______________________________________

From report at bugs.python.org  Fri Mar 26 19:53:55 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 26 Mar 2021 23:53:55 +0000
Subject: [issue43636] test_descr fails randomly when executed with -R :
Message-ID: <1616802835.56.0.699111570038.issue43636@roundup.psfhosted.org>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

? ./python -m test test_descr -m test_slots -R 3:3
0:00:00 load avg: 0.26 Run tests sequentially
0:00:00 load avg: 0.26 [1/1] test_descr
beginning 6 repetitions
123456
test test_descr failed -- Traceback (most recent call last):
  File "/home/pablogsal/github/cpython/Lib/test/test_descr.py", line 1201, in test_slots
    c.abc = 5
AttributeError: 'C' object has no attribute 'abc'

test_descr failed

== Tests result: FAILURE ==

1 test failed:
    test_descr

Total duration: 72 ms
Tests result: FAILURE

----------
components: Tests
messages: 389575
nosy: pablogsal, vstinner
priority: normal
severity: normal
status: open
title: test_descr fails randomly when executed with -R :
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43636>
_______________________________________

From report at bugs.python.org  Fri Mar 26 20:02:05 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 27 Mar 2021 00:02:05 +0000
Subject: [issue43636] test_descr fails randomly when executed with -R :
In-Reply-To: <1616802835.56.0.699111570038.issue43636@roundup.psfhosted.org>
Message-ID: <1616803325.06.0.66166503796.issue43636@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Bisecting points at:

commit ee48c7d54147ae906776b9f6f96e8920e097d0c4
Author: Dino Viehland <dinoviehland at fb.com>
Date:   Sat Mar 20 12:12:05 2021 -0700

    bpo-43452: Micro-optimizations to PyType_Lookup (GH-24804)

    The common case going through _PyType_Lookup is to have a cache hit. There are some small tweaks that can make this a little cheaper:

    * The name field identity is used for a cache hit and is kept alive by the cache. So there's no need to read the hash code o the name - instead, the address can be used as the hash.

    *  There's no need to check if the name is cachable on the lookup either, it probably is, and if it is, it'll be in the cache.

    *  If we clear the version tag when invalidating a type then we don't actually need to check for a valid version tag bit.

----------
nosy: +dino.viehland

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43636>
_______________________________________

From report at bugs.python.org  Fri Mar 26 20:02:33 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 27 Mar 2021 00:02:33 +0000
Subject: [issue43452] Microoptimize PyType_Lookup for cache hits
In-Reply-To: <1615317677.24.0.232039554227.issue43452@roundup.psfhosted.org>
Message-ID: <1616803353.13.0.129264916289.issue43452@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Seems that commit ee48c7d54147ae906776b9f6f96e8920e097d0c4  has introduced a regression:

https://bugs.python.org/issue43636

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43452>
_______________________________________

From report at bugs.python.org  Fri Mar 26 20:03:10 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 27 Mar 2021 00:03:10 +0000
Subject: [issue43636] test_descr fails randomly when executed with -R :
In-Reply-To: <1616802835.56.0.699111570038.issue43636@roundup.psfhosted.org>
Message-ID: <1616803390.97.0.820154110625.issue43636@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Dino, could you take a look?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43636>
_______________________________________

From report at bugs.python.org  Fri Mar 26 20:03:29 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 27 Mar 2021 00:03:29 +0000
Subject: [issue43636] test_descr fails randomly when executed with -R :
In-Reply-To: <1616802835.56.0.699111570038.issue43636@roundup.psfhosted.org>
Message-ID: <1616803409.7.0.0727284877131.issue43636@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
nosy: +methane

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43636>
_______________________________________

From report at bugs.python.org  Fri Mar 26 20:06:43 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 27 Mar 2021 00:06:43 +0000
Subject: [issue43576] python3.6.4 os.environ error when write chinese to file
In-Reply-To: <1616302012.93.0.356074990603.issue43576@roundup.psfhosted.org>
Message-ID: <1616803603.94.0.0904383954861.issue43576@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> If you are lost with locale encodings, you can attempt to encode
> everything in UTF-8 and enables the Python UTF-8 Mode:

rushant is using Python 3.6. UTF-8 mode was added in 3.7, so it's not an option without first upgrading to 3.7. Also, it's important to note that the suggestion to "attempt to encode everything in UTF-8" includes whatever terminal encoding or shell-script file encoding is used for `export a="??"`. If it's not using UTF-8, then setting the preferred encoding in Python to UTF-8 isn't going to help.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43576>
_______________________________________

From report at bugs.python.org  Fri Mar 26 20:20:27 2021
From: report at bugs.python.org (Dino Viehland)
Date: Sat, 27 Mar 2021 00:20:27 +0000
Subject: [issue43636] test_descr fails randomly when executed with -R :
In-Reply-To: <1616802835.56.0.699111570038.issue43636@roundup.psfhosted.org>
Message-ID: <1616804427.56.0.765906915228.issue43636@roundup.psfhosted.org>


Dino Viehland <dinoviehland at gmail.com> added the comment:

Looking!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43636>
_______________________________________

From report at bugs.python.org  Fri Mar 26 20:26:25 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 27 Mar 2021 00:26:25 +0000
Subject: [issue43636] test_descr fails randomly when executed with -R :
In-Reply-To: <1616802835.56.0.699111570038.issue43636@roundup.psfhosted.org>
Message-ID: <1616804785.24.0.216576662172.issue43636@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Seems that the problem is removing the check:

    if (MCACHE_CACHEABLE_NAME(name) &&
        _PyType_HasFeature(type, Py_TPFLAGS_VALID_VERSION_TAG)) {

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43636>
_______________________________________

From report at bugs.python.org  Fri Mar 26 21:10:53 2021
From: report at bugs.python.org (Dino Viehland)
Date: Sat, 27 Mar 2021 01:10:53 +0000
Subject: [issue43636] test_descr fails randomly when executed with -R :
In-Reply-To: <1616802835.56.0.699111570038.issue43636@roundup.psfhosted.org>
Message-ID: <1616807453.23.0.36521447658.issue43636@roundup.psfhosted.org>


Dino Viehland <dinoviehland at gmail.com> added the comment:

It's probably worth having an assert that the version tag is valid, that'll make it easier to see what's going wrong in the cache hit case.  We should have the version tag being 0 now when it's not valid.  I may not be able to debug it anymore tonight, but if no will look tomorrow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43636>
_______________________________________

From report at bugs.python.org  Fri Mar 26 21:26:40 2021
From: report at bugs.python.org (Dino Viehland)
Date: Sat, 27 Mar 2021 01:26:40 +0000
Subject: [issue43636] test_descr fails randomly when executed with -R :
In-Reply-To: <1616802835.56.0.699111570038.issue43636@roundup.psfhosted.org>
Message-ID: <1616808400.49.0.0688400358435.issue43636@roundup.psfhosted.org>


Dino Viehland <dinoviehland at gmail.com> added the comment:

And it looks like we have an entry with a 0 version, but with a valid name:

(type_cache_entry) $3 = {
  version = 0
  name = 0x0000000100ec44f0
  value = NULL
}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43636>
_______________________________________

From report at bugs.python.org  Fri Mar 26 21:34:15 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 27 Mar 2021 01:34:15 +0000
Subject: [issue43636] test_descr fails randomly when executed with -R :
In-Reply-To: <1616802835.56.0.699111570038.issue43636@roundup.psfhosted.org>
Message-ID: <1616808855.55.0.099836202351.issue43636@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +23780
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25032

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43636>
_______________________________________

From report at bugs.python.org  Fri Mar 26 21:34:56 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 27 Mar 2021 01:34:56 +0000
Subject: [issue43636] test_descr fails randomly when executed with -R :
In-Reply-To: <1616802835.56.0.699111570038.issue43636@roundup.psfhosted.org>
Message-ID: <1616808896.12.0.0659567348801.issue43636@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I think I have it, we still neet to validate that the version tag is correct. Can you take a look at https://github.com/python/cpython/pull/25032 ?

----------
stage: patch review -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43636>
_______________________________________

From report at bugs.python.org  Fri Mar 26 21:38:12 2021
From: report at bugs.python.org (Dino Viehland)
Date: Sat, 27 Mar 2021 01:38:12 +0000
Subject: [issue43636] test_descr fails randomly when executed with -R :
In-Reply-To: <1616802835.56.0.699111570038.issue43636@roundup.psfhosted.org>
Message-ID: <1616809092.04.0.856650702488.issue43636@roundup.psfhosted.org>


Dino Viehland <dinoviehland at gmail.com> added the comment:

I think the issue here is that in assign_version_tag there's this code:

    if (type->tp_version_tag == 0) {
        // Wrap-around or just starting Python - clear the whole cache
        type_cache_clear(cache, 1);
        return 1;
    }

the return 1 is incorrect, it should be return 0 as a valid version tag hasn't been assigned.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43636>
_______________________________________

From report at bugs.python.org  Fri Mar 26 21:43:06 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 27 Mar 2021 01:43:06 +0000
Subject: [issue43636] test_descr fails randomly when executed with -R :
In-Reply-To: <1616802835.56.0.699111570038.issue43636@roundup.psfhosted.org>
Message-ID: <1616809386.7.0.64725576948.issue43636@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Yup, that makes sense. Let me update the PR

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43636>
_______________________________________

From report at bugs.python.org  Fri Mar 26 23:51:57 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 27 Mar 2021 03:51:57 +0000
Subject: [issue43636] test_descr fails randomly when executed with -R :
In-Reply-To: <1616802835.56.0.699111570038.issue43636@roundup.psfhosted.org>
Message-ID: <1616817117.04.0.163781773189.issue43636@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43636>
_______________________________________

From report at bugs.python.org  Fri Mar 26 23:51:53 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 27 Mar 2021 03:51:53 +0000
Subject: [issue43636] test_descr fails randomly when executed with -R :
In-Reply-To: <1616802835.56.0.699111570038.issue43636@roundup.psfhosted.org>
Message-ID: <1616817113.69.0.844320157826.issue43636@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 11b85abbae8aaa8410b19f358abd7b401881bb1c by Pablo Galindo in branch 'master':
bpo-43636: Validate the version tag in _PyType_Lookup (GH-25032)
https://github.com/python/cpython/commit/11b85abbae8aaa8410b19f358abd7b401881bb1c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43636>
_______________________________________

From report at bugs.python.org  Sat Mar 27 00:15:08 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 27 Mar 2021 04:15:08 +0000
Subject: [issue38999] Python launcher on Windows does not detect active venv
In-Reply-To: <1575830943.65.0.538772164668.issue38999@roundup.psfhosted.org>
Message-ID: <1616818508.05.0.603243959113.issue38999@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> I realize one could interpret the python3 in the shebang as an 
> "explicit version specification", but a) that's not on the 
> command line, which seems the more natural reading and b) it's 
> only a partial specification, since it doesn't say which python3
> to use.

The wanted version is specified by the command line, else by the script shebang. The default version to use for `py -3` or a "python3" virtual command in a shebang (e.g. "#!/usr/bin/python3") is determined by the PY_PYTHON3 environment variable or the "python3" setting in "py.ini". If a default 3.x version isn't configured, the launcher uses the latest-version installation of 3.x, of which the 64-bit version is preferred (e.g. 3.10 is preferred over 3.10-32, which is preferred over 3.9).

For just `py` or a "python" virtual command in a shebang -- i.e. when no version is specified -- an active virtual environment is preferred. Else it uses the default that's set in PY_PYTHON environment variable or the "python" setting in py.ini. If no default is set, and there's no shebang, the launcher prefers the latest-version 3.x that's installed. If there's a shebang, the launcher prefers the latest-version 2.x that's installed.

Originally, the non-versioned "/usr/bin/env python" virtual command was handled the same as all other non-versioned "python" virtual commands. But later on the "env" form was changed to first try a path search for "python.exe" via WinAPI SearchPathW() before falling back on the common behavior. In most cases this search will find an active virtual environment. But it could be that another directory with "python.exe" is added to the front of PATH after a virtual environment is activated.

---

How about generalizing "/usr/bin/env python*" to support virtual environments by getting the "version" (venv) or "version_info" (virtualenv) value from "%VIRTUAL_ENV%\pyvenv.cfg"? I'd prefer to get that value in locate_venv_python(). It can still set the `version` string to "venv", but extend the INSTALLED_PYTHON record with a `venv_version` string that can be checked in the result of find_python_by_version(L"venv").

Extend locate_python() with a `search` parameter. If `search` is true, then do a path search [1] for `wanted_ver`, with the searched "python*.exe" executable name set depending on the launcher build (i.e. py[w][_d].exe). If searching is skipped or doesn't find a match, then run an active virtual environment if either `wanted_ver` is empty or `search` is true and `wanted_ver` is compatible with the virtual environment. Otherwise locate a registered Python installation based on `wanted_ver` and `from_shebang`.

---

For GUI and debug builds, the PYTHON_EXECUTABLE macro could be split into a base "python[w]" name and an extension "[_d].exe" name, which makes it easy to construct the name to search for given a valid version string. For example, with a pyw_d.exe debug build, "python3" would be searched for as "pythonw3_d.exe".

---

[1] I'd prefer to expand the path search to also check the user and machine "App Paths", which are like "$HOME/.local/bin" and "/usr/bin" for the Windows shell.

----------
versions: +Python 3.10 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38999>
_______________________________________

From report at bugs.python.org  Sat Mar 27 00:46:58 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 27 Mar 2021 04:46:58 +0000
Subject: [issue37769] Windows Store installer should warn user about MAX_PATH
In-Reply-To: <1565042568.26.0.835015396911.issue37769@roundup.psfhosted.org>
Message-ID: <1616820418.72.0.465300604508.issue37769@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
versions: +Python 3.10 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37769>
_______________________________________

From report at bugs.python.org  Sat Mar 27 00:50:19 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 27 Mar 2021 04:50:19 +0000
Subject: [issue34142] Windows launcher version lookup flawed
In-Reply-To: <1531879775.21.0.56676864532.issue34142@psf.upfronthosting.co.za>
Message-ID: <1616820619.78.0.829221371807.issue34142@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
type: behavior -> enhancement
versions: +Python 3.10 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34142>
_______________________________________

From report at bugs.python.org  Sat Mar 27 00:56:08 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 27 Mar 2021 04:56:08 +0000
Subject: [issue41661] os.path.relpath does not document ValueError on Windows
 with different drives
In-Reply-To: <1598681705.55.0.359436315051.issue41661@roundup.psfhosted.org>
Message-ID: <1616820968.01.0.400608311913.issue41661@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

The suggested documentation change looks good to me.

----------
type: behavior -> enhancement
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41661>
_______________________________________

From report at bugs.python.org  Sat Mar 27 01:08:43 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 27 Mar 2021 05:08:43 +0000
Subject: [issue35306] OSError [WinError 123] when testing if pathlib.Path('*')
 (asterisks) exists
In-Reply-To: <1543038959.25.0.788709270274.issue35306@psf.upfronthosting.co.za>
Message-ID: <1616821723.11.0.825230400713.issue35306@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
Removed message: https://bugs.python.org/msg333746

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35306>
_______________________________________

From report at bugs.python.org  Sat Mar 27 01:12:15 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 27 Mar 2021 05:12:15 +0000
Subject: [issue35306] [Windows] OSError when testing whether pathlib.Path('*')
 exists
In-Reply-To: <1543038959.25.0.788709270274.issue35306@psf.upfronthosting.co.za>
Message-ID: <1616821935.71.0.544937031997.issue35306@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
title: OSError [WinError 123] when testing if pathlib.Path('*') (asterisks) exists -> [Windows] OSError when testing whether pathlib.Path('*') exists
type:  -> behavior
versions: +Python 3.10 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35306>
_______________________________________

From report at bugs.python.org  Sat Mar 27 01:12:40 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 27 Mar 2021 05:12:40 +0000
Subject: [issue42855] pathlib.exists on Windows raises an exception on URL
 like/bad input
In-Reply-To: <1610011401.69.0.814272139734.issue42855@roundup.psfhosted.org>
Message-ID: <1616821960.78.0.387600023668.issue42855@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> [Windows] OSError when testing whether pathlib.Path('*') exists

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42855>
_______________________________________

From report at bugs.python.org  Sat Mar 27 01:23:41 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 27 Mar 2021 05:23:41 +0000
Subject: [issue36792] [Windows] time: crash on formatting time with de_DE
 locale
In-Reply-To: <1556973198.72.0.765243261905.issue36792@roundup.psfhosted.org>
Message-ID: <1616822621.2.0.0659334969755.issue36792@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
Removed message: https://bugs.python.org/msg361476

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36792>
_______________________________________

From report at bugs.python.org  Sat Mar 27 01:48:25 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 27 Mar 2021 05:48:25 +0000
Subject: [issue36792] [Windows] time: crash on formatting time with de_DE
 locale
In-Reply-To: <1556973198.72.0.765243261905.issue36792@roundup.psfhosted.org>
Message-ID: <1616824105.98.0.96638418501.issue36792@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

ucrt in Windows 10 v2004 uses an internal wide-character version of the time-zone name, which gets updated by _tzset() and kept in sync with the _tzname encoded strings. Also, note that the current implementation uses the locale's ANSI code page for both "de-DE" and "de_DE". UTF-8 has to be requested explicitly when using a BCP-47 locale name, such as "de_DE.UTF-8" or "de-DE.UTF-8", and UTF-8 is the only explicit codeset that's allowed in this case.

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36792>
_______________________________________

From report at bugs.python.org  Sat Mar 27 01:49:35 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 27 Mar 2021 05:49:35 +0000
Subject: [issue36319] Erro 0xC0000374 on windows 10
In-Reply-To: <1552761804.37.0.212876301752.issue36319@roundup.psfhosted.org>
Message-ID: <1616824175.23.0.501244827136.issue36319@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> [Windows] time: crash on formatting time with de_DE locale

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36319>
_______________________________________

From report at bugs.python.org  Sat Mar 27 04:16:31 2021
From: report at bugs.python.org (=?utf-8?q?Ondrej_Baranovi=C4=8D?=)
Date: Sat, 27 Mar 2021 08:16:31 +0000
Subject: [issue43637] winreg: SetValueEx leaks memory if PySys_Audit fails
Message-ID: <1616832991.07.0.159084299457.issue43637@roundup.psfhosted.org>


New submission from Ondrej Baranovi? <nulano at nulano.eu>:

The function `winreg_SetValueEx_impl` in `winreg.c`:

1) Allocates memory by calling `Py2Reg`,
2) calls `PySys_Audit` and immediately returns if it indicates an error,
3) calls `RegSetValueExW`,
4) frees memory allocated in (1) and returns.

The if-block in (2) should free the memory allocated in (1) if an audit hook raises.

Introduced in PR17541.

----------
components: Windows
messages: 389591
nosy: nulano, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: winreg: SetValueEx leaks memory if PySys_Audit fails
type: resource usage
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43637>
_______________________________________

From report at bugs.python.org  Sat Mar 27 04:26:26 2021
From: report at bugs.python.org (Cong Ma)
Date: Sat, 27 Mar 2021 08:26:26 +0000
Subject: [issue43605] Eval/exec and comprehension scopes unclear in
 documentation
In-Reply-To: <1616520364.91.0.0936665126175.issue43605@roundup.psfhosted.org>
Message-ID: <1616833586.92.0.513445243868.issue43605@roundup.psfhosted.org>


Cong Ma <m.cong at protonmail.ch> added the comment:

> I think it is *very* reasonable to expect that calling eval() on a string should have the exact same effect as if the code that is inside the eval had been written as part of the source code.

I don't think Python's execution model is defined this way. The documentation on execution model says:

> The eval() and exec() functions do not have access to the full environment for resolving names. Names may be resolved in the local and global namespaces of the caller. Free variables are not resolved in the nearest enclosing namespace, but in the global namespace.
> footnote: This limitation occurs because the code that is executed by these operations is not available at the time the module is compiled.

https://docs.python.org/3/reference/executionmodel.html#interaction-with-dynamic-features

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43605>
_______________________________________

From report at bugs.python.org  Sat Mar 27 04:32:19 2021
From: report at bugs.python.org (Cong Ma)
Date: Sat, 27 Mar 2021 08:32:19 +0000
Subject: [issue43605] Eval/exec and comprehension scopes unclear in
 documentation
In-Reply-To: <1616520364.91.0.0936665126175.issue43605@roundup.psfhosted.org>
Message-ID: <1616833939.75.0.424352410451.issue43605@roundup.psfhosted.org>


Cong Ma <m.cong at protonmail.ch> added the comment:

I'm preparing an update to the documentation of eval/exec. There are several issues, but chiefly I'll link to the appropriate sections in the Language Reference, and clean up some other inaccuracies. When it's ready I'll submit a PR for core devs to review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43605>
_______________________________________

From report at bugs.python.org  Sat Mar 27 06:11:53 2021
From: report at bugs.python.org (=?utf-8?q?J=C3=B6rn_Heissler?=)
Date: Sat, 27 Mar 2021 10:11:53 +0000
Subject: [issue37773] ValueError: I/O operation on closed file. in ZipFile
 destructor
In-Reply-To: <1565084150.95.0.74829896398.issue37773@roundup.psfhosted.org>
Message-ID: <1616839913.79.0.918298634843.issue37773@roundup.psfhosted.org>


J?rn Heissler <launchpad2019 at tutnicht.de> added the comment:

Still reproducible in cpython 3.10.0a3 (debian unstable) and 3.10.0a6 (pyenv).

----------
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37773>
_______________________________________

From report at bugs.python.org  Sat Mar 27 06:25:29 2021
From: report at bugs.python.org (Bruno Loff)
Date: Sat, 27 Mar 2021 10:25:29 +0000
Subject: [issue43605] Eval/exec and comprehension scopes unclear in
 documentation
In-Reply-To: <1616520364.91.0.0936665126175.issue43605@roundup.psfhosted.org>
Message-ID: <1616840729.75.0.117754377347.issue43605@roundup.psfhosted.org>


Bruno Loff <bruno.loff at gmail.com> added the comment:

Hmm yes, some more words in the documentation might help.

Does anyone understand why it happens, though?

Specifically, note that

sum(get(i) for i in range(len(l)))

or

eval("get(0) + get(1) + get(2) + get(3)")

or

eval("sum(get(i) for i in range(len(l)))", locals())

work just fine, but

eval("sum(get(i) for i in range(len(l)))")

fails, which is really confusing. I have no mental model of what is happening that allows for the first thing to work, but disallows for the second thing. I understand it has something to do with the creation of a new subscope when the comprehension is run, but other than that, I don't really understand.

Also, ideally, the last thing should work, too.

I am teaching programming to college students and I could not explain to them why the first three worked but the last one failed. There was simply nothing I could say that would give them a good mental model for the execution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43605>
_______________________________________

From report at bugs.python.org  Sat Mar 27 06:36:42 2021
From: report at bugs.python.org (Sander)
Date: Sat, 27 Mar 2021 10:36:42 +0000
Subject: [issue43638] MacOS os.statvfs() has rollover for >4TB disks at each
 4TB (32bit counter overflow?)
Message-ID: <1616841402.66.0.531178179964.issue43638@roundup.psfhosted.org>


New submission from Sander <sander.jonkers+github at gmail.com>:

MacOS BigSur (and older), python 3.9.2 (and older)

For disks >4TB, os.statvfs() shows a wrong value for available space: too low, and always rollover at each 4TB. 
As 4TB = 2^42, hypothesis: rollover in 32bit counter (with 10bit blocksize)

Example:

"df -m" does show the correct available space

df -m /Volumes/Frank/
Filesystem                                    1M-blocks    Used Available Capacity    iused       ifree %iused  Mounted on
//frank at SynologyBlabla._smb._tcp.local/Frank  21963360 2527744  19435615    12% 2588410474 19902070164   12%   /Volumes/Frank

So available space 19902070164 MB, so about 18.5 TB. Good.

Now python's os.statvfs():

>>> s = os.statvfs("/Volumes/Frank")
>>> s.f_bavail * s.f_frsize / 1024**2
2658399.39453125

So 2.5TB, and thus wrong

The difference is 16777216 MB which is exactly 4 times 4TB.

Problem seems to be in MacOS statvfs() itself; reproducable with a few lines of C code.

We have implemented a workaround in our python program SABnzbd to directly use MacOS' libc statfs() call (not statvfs() ). A solution / workaround in python itself would be much nicer.


No problem with python on Linux with >4TB drives.

----------
components: macOS
messages: 389596
nosy: ned.deily, ronaldoussoren, sanderjo
priority: normal
severity: normal
status: open
title: MacOS os.statvfs() has rollover for >4TB disks at each 4TB (32bit counter overflow?)
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43638>
_______________________________________

From report at bugs.python.org  Sat Mar 27 06:39:51 2021
From: report at bugs.python.org (Safihre)
Date: Sat, 27 Mar 2021 10:39:51 +0000
Subject: [issue43638] MacOS os.statvfs() has rollover for >4TB disks at each
 4TB (32bit counter overflow?)
In-Reply-To: <1616841402.66.0.531178179964.issue43638@roundup.psfhosted.org>
Message-ID: <1616841591.79.0.277396812197.issue43638@roundup.psfhosted.org>


Change by Safihre <safihre at sabnzbd.org>:


----------
nosy: +Safihre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43638>
_______________________________________

From report at bugs.python.org  Sat Mar 27 07:18:04 2021
From: report at bugs.python.org (Cong Ma)
Date: Sat, 27 Mar 2021 11:18:04 +0000
Subject: [issue43605] Eval/exec and comprehension scopes unclear in
 documentation
In-Reply-To: <1616520364.91.0.0936665126175.issue43605@roundup.psfhosted.org>
Message-ID: <1616843884.18.0.658667425584.issue43605@roundup.psfhosted.org>


Cong Ma <m.cong at protonmail.ch> added the comment:

> sum(get(i) for i in range(len(l)))

This expression inside the body of ``func()`` references the name "get" and "l" (ell), both are local to the scope introduced by ``func()``. More specifically, these two names are referenced in the unnamed inner scope introduced by the generator-expression ``(get(i) for i in range(len(l)))``. It's as if you've passed into that inner scope the locals already introduced in func() by argument passing, e.g.

```
def func(...):
    get = ...
    ell = ...
    def genexpr(a, b):
        return <expression using a and b>
    sum(genexpr(get, ell))
```

> eval("get(0) + get(1) + get(2) + get(3)")

The expression in the string doesn't introduce its own scope. The name "get" is resolved because without additional arguments, eval() gets the locals from the calling scope's locals, which is where the name "get" came.

> eval("sum(get(i) for i in range(len(l)))", locals())

This tells eval() to use the calling scope's locals (the value returned by the call ``locals()``) as the globals for the evaluation of the expression in the string. When eval() executes the compiled code, it's as if that piece of code lives in an environment where names like "gets" and "l" (ell) are top-level. Therefore these names are resolved.

> eval("sum(get(i) for i in range(len(l)))")

Without explicitly telling eval() which globals/locals namespaces to use, eval() uses the current calling scope's. This is as if it were called like

eval("sum(get(i) for i in range(len(l)))", globals(), locals())

A problem arises. The generator expression in the string introduces an anonymous inner scope (let's call that scope "the box"). Inside the box, the name "i" is a local, there's no problem. But for the name "get", it's not local to the box, and it's not a global. Unlike other kinds of enclosed scope (for example, one introduced by an inner ``def`` block), "the box" has no way to look up names in enclosing scopes. This is the limitation referred to by the Language Reference's section on dynamic execution.

These are my attempts to explain why something works while others don't, based on my own understanding. I hope this helps somewhat, and if I made a mistake anywhere please correct them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43605>
_______________________________________

From report at bugs.python.org  Sat Mar 27 08:40:32 2021
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sat, 27 Mar 2021 12:40:32 +0000
Subject: [issue43639] Do not raise AttributeError on instance attribute
 update/deletion if data descriptor with missing __set__/__delete__ method
 found on its type
Message-ID: <1616848832.19.0.971517857631.issue43639@roundup.psfhosted.org>


New submission from G?ry <gery.ogam at gmail.com>:

Currently, the `object.__setattr__` and `type.__setattr__` methods raise an `AttributeError` during attribute *update* on an instance if its type has an attribute which is a *data* descriptor without a `__set__` method. Likewise, the `object.__delattr__` and `type.__delattr__` methods raise an `AttributeError` during attribute *deletion* on an instance if its type has an attribute which is a *data* descriptor without a `__delete__` method.

This should not be the case. When update/deletion is impossible through a data descriptor found on the type, update/deletion should carry its process on the instance, like when there is no data descriptor found on the type. And this is what the `object.__getattribute__` and `type.__getattribute__` methods already do: they do *not* raise an `AttributeError` during attribute *lookup* on an instance if its type has an attribute which is a *data* descriptor without a `__get__` method. See [the discussion on Python Discuss](https://discuss.python.org/t/why-do-setattr-and-delattr-raise-an-attributeerror-in-this-case/7836?u=maggyero).

Here is a simple program illustrating the differences between attribute lookup by `object.__getattribute__` on the one hand (`AttributeError` is not raised), and attribute update by `object.__setattr__` and attribute deletion by `object.__delattr__` on the other hand (`AttributeError` is raised):

```python
class DataDescriptor1:  # missing __get__
    def __set__(self, instance, value): pass
    def __delete__(self, instance): pass

class DataDescriptor2:  # missing __set__
    def __get__(self, instance, owner=None): pass
    def __delete__(self, instance): pass

class DataDescriptor3:  # missing __delete__
    def __get__(self, instance, owner=None): pass
    def __set__(self, instance, value): pass

class A:
    x = DataDescriptor1()
    y = DataDescriptor2()
    z = DataDescriptor3()

a = A()
vars(a).update({'x': 'foo', 'y': 'bar', 'z': 'baz'})

a.x
# actual: returns 'foo'
# expected: returns 'foo'

a.y = 'qux'
# actual: raises AttributeError: __set__
# expected: vars(a)['y'] == 'qux'

del a.z
# actual: raises AttributeError: __delete__
# expected: 'z' not in vars(a)
```

Here is another simple program illustrating the differences between attribute lookup by `type.__getattribute__` on the one hand (`AttributeError` is not raised), and attribute update by `type.__setattr__` and attribute deletion by `type.__delattr__` on the other hand (`AttributeError` is raised):

```python
class DataDescriptor1:  # missing __get__
    def __set__(self, instance, value): pass
    def __delete__(self, instance): pass

class DataDescriptor2:  # missing __set__
    def __get__(self, instance, owner=None): pass
    def __delete__(self, instance): pass

class DataDescriptor3:  # missing __delete__
    def __get__(self, instance, owner=None): pass
    def __set__(self, instance, value): pass

class M(type):
    x = DataDescriptor1()
    y = DataDescriptor2()
    z = DataDescriptor3()

class A(metaclass=M):
    x = 'foo'
    y = 'bar'
    z = 'baz'

A.x
# actual: returns 'foo'
# expected: returns 'foo'

A.y = 'qux'
# actual: raises AttributeError: __set__
# expected: vars(A)['y'] == 'qux'

del A.z
# actual: raises AttributeError: __delete__
# expected: 'z' not in vars(A)
```

----------
components: Interpreter Core
messages: 389598
nosy: maggyero
priority: normal
severity: normal
status: open
title: Do not raise AttributeError on instance attribute update/deletion if data descriptor with missing __set__/__delete__ method found on its type
type: behavior
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43639>
_______________________________________

From report at bugs.python.org  Sat Mar 27 09:15:48 2021
From: report at bugs.python.org (Cong Ma)
Date: Sat, 27 Mar 2021 13:15:48 +0000
Subject: [issue43605] Eval/exec and comprehension scopes unclear in
 documentation
In-Reply-To: <1616520364.91.0.0936665126175.issue43605@roundup.psfhosted.org>
Message-ID: <1616850948.17.0.158809129462.issue43605@roundup.psfhosted.org>


Cong Ma <m.cong at protonmail.ch> added the comment:

Some more context: Issue 37646. The demo in that one was "eval inside list-comprehension-scope", while this one is the other way around.

Perhaps another example may better illustrate the interplay between eval and the execution environment:

```
def f():
    x = 1
    def g():
        return eval("x")
    return g
enc = f()
enc()
```

We get ``NameError: name 'x' is not defined``.

The reason is that, during compilation the compiler doesn't and cannot care about what the string "x" means as an argument to eval(). To the compiler it's just a string constant passed to a function, and it's not much different from
```
        return print("x")
```
The compiler decides that the enclosed function g() has no locals in its block. And since there's no global with the name ``x`` either, when the dynamic expression is evaluated in eval() in that environment, the name doesn't resolve, because "eval() doesn't have access to the enclosing scope".

But the following is different:

```
def f():
    x = 1
    def g():
        x  # <----- 
        return eval("x")
    return g
enc = f()
enc()  # return value: 1
```

The marked line introduces name ``x`` as a local by virtue of merely having it in an expression-statement. Inside the function block of g(), we can imagine that the name resolution "goes up one level" into the enclosing block of f() where it is bound to the int object. When eval() is called there, the name does resolve.

I'm trying to think up a mental model but I'm afraid I can't find a simple one, except "once compiled, it's compiled, and eval() must learn to work with the already-compiled code". A much more in-depth description of name binding and execution in CPython is given here:

https://tenthousandmeters.com/blog/python-behind-the-scenes-5-how-variables-are-implemented-in-cpython/

especially in the section "``LOAD_DEREF`` and ``STORE_DEREF``".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43605>
_______________________________________

From report at bugs.python.org  Sat Mar 27 09:38:26 2021
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sat, 27 Mar 2021 13:38:26 +0000
Subject: [issue43639] Do not raise AttributeError on instance attribute
 update/deletion if data descriptor with missing __set__/__delete__ method
 found on its type
In-Reply-To: <1616848832.19.0.971517857631.issue43639@roundup.psfhosted.org>
Message-ID: <1616852306.21.0.958469544289.issue43639@roundup.psfhosted.org>


Change by G?ry <gery.ogam at gmail.com>:


----------
keywords: +patch
pull_requests: +23781
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25033

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43639>
_______________________________________

From report at bugs.python.org  Sat Mar 27 09:44:13 2021
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 27 Mar 2021 13:44:13 +0000
Subject: [issue43617] Missing definition in configure.ac causing autoreconf to
 create damaged configure script
In-Reply-To: <1616597538.33.0.0386305243834.issue43617@roundup.psfhosted.org>
Message-ID: <1616852653.52.0.931249967138.issue43617@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset 5d6e8c1c1a5f667cdce99cb3c563ac922198678d by Christian Heimes in branch 'master':
bpo-43617: Check autoconf-archive package in configure.ac (GH-25016)
https://github.com/python/cpython/commit/5d6e8c1c1a5f667cdce99cb3c563ac922198678d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43617>
_______________________________________

From report at bugs.python.org  Sat Mar 27 09:51:03 2021
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 27 Mar 2021 13:51:03 +0000
Subject: [issue43617] Missing definition in configure.ac causing autoreconf to
 create damaged configure script
In-Reply-To: <1616597538.33.0.0386305243834.issue43617@roundup.psfhosted.org>
Message-ID: <1616853063.09.0.740330066395.issue43617@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +23782
pull_request: https://github.com/python/cpython/pull/25034

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43617>
_______________________________________

From report at bugs.python.org  Sat Mar 27 09:53:30 2021
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 27 Mar 2021 13:53:30 +0000
Subject: [issue43617] Missing definition in configure.ac causing autoreconf to
 create damaged configure script
In-Reply-To: <1616597538.33.0.0386305243834.issue43617@roundup.psfhosted.org>
Message-ID: <1616853210.28.0.583119524703.issue43617@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +23783
pull_request: https://github.com/python/cpython/pull/25035

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43617>
_______________________________________

From report at bugs.python.org  Sat Mar 27 09:55:10 2021
From: report at bugs.python.org (miss-islington)
Date: Sat, 27 Mar 2021 13:55:10 +0000
Subject: [issue40645] Use OpenSSL's HMAC API
In-Reply-To: <1589641291.33.0.635001105595.issue40645@roundup.psfhosted.org>
Message-ID: <1616853310.65.0.963411119823.issue40645@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 933dfd7504e521a27fd8b94d02b79f9ed08f4631 by Christian Heimes in branch 'master':
bpo-40645: use C implementation of HMAC (GH-24920)
https://github.com/python/cpython/commit/933dfd7504e521a27fd8b94d02b79f9ed08f4631


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40645>
_______________________________________

From report at bugs.python.org  Sat Mar 27 10:20:17 2021
From: report at bugs.python.org (miss-islington)
Date: Sat, 27 Mar 2021 14:20:17 +0000
Subject: [issue39616] SSLContext.check_hostname description is inaccurate wrt
 match_hostname
In-Reply-To: <1581511027.29.0.201714121734.issue39616@roundup.psfhosted.org>
Message-ID: <1616854817.53.0.708596582511.issue39616@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 9798cef92b882cd82a338d3368eaf3c4a32f5c2d by Ville Skytt? in branch 'master':
bpo-39616: clarify SSLContext.check_hostname effect (GH-18484)
https://github.com/python/cpython/commit/9798cef92b882cd82a338d3368eaf3c4a32f5c2d


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39616>
_______________________________________

From report at bugs.python.org  Sat Mar 27 10:20:24 2021
From: report at bugs.python.org (miss-islington)
Date: Sat, 27 Mar 2021 14:20:24 +0000
Subject: [issue39616] SSLContext.check_hostname description is inaccurate wrt
 match_hostname
In-Reply-To: <1581511027.29.0.201714121734.issue39616@roundup.psfhosted.org>
Message-ID: <1616854824.18.0.18457993154.issue39616@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +23784
pull_request: https://github.com/python/cpython/pull/25036

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39616>
_______________________________________

From report at bugs.python.org  Sat Mar 27 10:20:33 2021
From: report at bugs.python.org (miss-islington)
Date: Sat, 27 Mar 2021 14:20:33 +0000
Subject: [issue39616] SSLContext.check_hostname description is inaccurate wrt
 match_hostname
In-Reply-To: <1581511027.29.0.201714121734.issue39616@roundup.psfhosted.org>
Message-ID: <1616854833.3.0.187817049522.issue39616@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +23785
pull_request: https://github.com/python/cpython/pull/25037

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39616>
_______________________________________

From report at bugs.python.org  Sat Mar 27 10:30:05 2021
From: report at bugs.python.org (miss-islington)
Date: Sat, 27 Mar 2021 14:30:05 +0000
Subject: [issue39616] SSLContext.check_hostname description is inaccurate wrt
 match_hostname
In-Reply-To: <1581511027.29.0.201714121734.issue39616@roundup.psfhosted.org>
Message-ID: <1616855405.97.0.124217623714.issue39616@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 9de6451558c38537b2335d6e04e3bf8743c30576 by Miss Islington (bot) in branch '3.8':
bpo-39616: clarify SSLContext.check_hostname effect (GH-18484)
https://github.com/python/cpython/commit/9de6451558c38537b2335d6e04e3bf8743c30576


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39616>
_______________________________________

From report at bugs.python.org  Sat Mar 27 10:42:54 2021
From: report at bugs.python.org (miss-islington)
Date: Sat, 27 Mar 2021 14:42:54 +0000
Subject: [issue39616] SSLContext.check_hostname description is inaccurate wrt
 match_hostname
In-Reply-To: <1581511027.29.0.201714121734.issue39616@roundup.psfhosted.org>
Message-ID: <1616856174.15.0.464140964901.issue39616@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c84e769c2b4108e1218e09652cb3bce34c541f8a by Miss Islington (bot) in branch '3.9':
bpo-39616: clarify SSLContext.check_hostname effect (GH-18484)
https://github.com/python/cpython/commit/c84e769c2b4108e1218e09652cb3bce34c541f8a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39616>
_______________________________________

From report at bugs.python.org  Sat Mar 27 10:44:40 2021
From: report at bugs.python.org (Zackery Spytz)
Date: Sat, 27 Mar 2021 14:44:40 +0000
Subject: [issue43637] winreg: SetValueEx leaks memory if PySys_Audit fails
In-Reply-To: <1616832991.07.0.159084299457.issue43637@roundup.psfhosted.org>
Message-ID: <1616856280.1.0.941418356565.issue43637@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 5.0 -> 6.0
pull_requests: +23786
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25038

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43637>
_______________________________________

From report at bugs.python.org  Sat Mar 27 11:06:53 2021
From: report at bugs.python.org (Cong Ma)
Date: Sat, 27 Mar 2021 15:06:53 +0000
Subject: [issue43605] Eval/exec and comprehension scopes unclear in
 documentation
In-Reply-To: <1616520364.91.0.0936665126175.issue43605@roundup.psfhosted.org>
Message-ID: <1616857613.89.0.993544886922.issue43605@roundup.psfhosted.org>


Change by Cong Ma <m.cong at protonmail.ch>:


----------
keywords: +patch
pull_requests: +23787
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/25039

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43605>
_______________________________________

From report at bugs.python.org  Sat Mar 27 11:28:19 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 27 Mar 2021 15:28:19 +0000
Subject: [issue37773] ValueError: I/O operation on closed file. in ZipFile
 destructor
In-Reply-To: <1565084150.95.0.74829896398.issue37773@roundup.psfhosted.org>
Message-ID: <1616858899.46.0.221172447213.issue37773@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

That's what happened. Function foo creates a reference loop. It has reference to the module dict, and the dict has reference to the function. The dict has also references to BytesIO and ZipFile objects. At shutdown stage the garbage collector is called. It founds the reference loop which contains the module dict, function foo and BytesIO and ZipFile objects. It tries to break the loop by calling the destructor of arbitrary object in the loop. In that case it is the BytesIO object. It does not help, but finally the destructor of the ZipFile object is called (either directly or after breaking the loop and destroying the module dict). The ZipFile destructor tries to close the BytesIO object, but it is already closed in its destructor.

It is a dangerous situation which potentially can cause data corruption (if the underlying stream is closed before flushing buffers). Clearing the module dict before invoking garbage collecting would solve this issue. Making the garbage collector more clever and and avoid destroying objects if it does not break the loop would help too, but it is more complex problem and such change could not be backported to 3.8.

Victor, were there any changes in the garbage collector or interpreter shutdown code in 3.8?

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37773>
_______________________________________

From report at bugs.python.org  Sat Mar 27 11:40:09 2021
From: report at bugs.python.org (Illia Volochii)
Date: Sat, 27 Mar 2021 15:40:09 +0000
Subject: [issue43640] Add warnings to ssl.PROTOCOL_TLSv1 and
 ssl.PROTOCOL_TLSv1_1 docs
Message-ID: <1616859609.98.0.745339520317.issue43640@roundup.psfhosted.org>


New submission from Illia Volochii <illia.volochii at gmail.com>:

TLS versions 1.0 and 1.1 have recently been deprecated. [1]

ssl.PROTOCOL_SSLv2 and ssl.PROTOCOL_SSLv3 have such warnings "SSL version 2 is insecure. Its use is highly discouraged." [2]

We have to add such warnings to ssl.PROTOCOL_TLSv1 and ssl.PROTOCOL_TLSv1_1 too.

[1] https://datatracker.ietf.org/doc/rfc8996/
[2] https://docs.python.org/3.10/library/ssl.html#ssl.PROTOCOL_SSLv2

----------
assignee: docs at python
components: Documentation
messages: 389606
nosy: docs at python, illia-v
priority: normal
severity: normal
status: open
title: Add warnings to ssl.PROTOCOL_TLSv1 and ssl.PROTOCOL_TLSv1_1 docs
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43640>
_______________________________________

From report at bugs.python.org  Sat Mar 27 11:44:10 2021
From: report at bugs.python.org (Illia Volochii)
Date: Sat, 27 Mar 2021 15:44:10 +0000
Subject: [issue43640] Add warnings to ssl.PROTOCOL_TLSv1 and
 ssl.PROTOCOL_TLSv1_1 docs
In-Reply-To: <1616859609.98.0.745339520317.issue43640@roundup.psfhosted.org>
Message-ID: <1616859850.7.0.4822156733.issue43640@roundup.psfhosted.org>


Change by Illia Volochii <illia.volochii at gmail.com>:


----------
keywords: +patch
pull_requests: +23788
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25040

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43640>
_______________________________________

From report at bugs.python.org  Sat Mar 27 11:46:03 2021
From: report at bugs.python.org (Sander)
Date: Sat, 27 Mar 2021 15:46:03 +0000
Subject: [issue43638] MacOS os.statvfs() has rollover for >4TB disks at each
 4TB (32bit counter overflow?)
In-Reply-To: <1616841402.66.0.531178179964.issue43638@roundup.psfhosted.org>
Message-ID: <1616859963.55.0.254900343507.issue43638@roundup.psfhosted.org>


Sander <sander.jonkers+github at gmail.com> added the comment:

Correction on typo in original post / to be clear:

>From the "df -m /Volumes/Frank/", Available is 19435615 in unity of 1MB blocks, so 19435615 MB. Which is 18.5 TB. All correctly reported by "df -m". But not by os.statvfs()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43638>
_______________________________________

From report at bugs.python.org  Sat Mar 27 11:50:13 2021
From: report at bugs.python.org (Illia Volochii)
Date: Sat, 27 Mar 2021 15:50:13 +0000
Subject: [issue43641] Update `ssl.PROTOCOL_TLSv1_2` docs since it is not the
 newest TLS version
Message-ID: <1616860213.53.0.619119120608.issue43641@roundup.psfhosted.org>


New submission from Illia Volochii <illia.volochii at gmail.com>:

Docs say that TLS 1.2 is the most modern version, and probably the best choice for maximum protection, but TLS 1.3 exists.

https://docs.python.org/3.10/library/ssl.html#ssl.PROTOCOL_TLSv1_2

----------
assignee: docs at python
components: Documentation
messages: 389608
nosy: docs at python, illia-v
priority: normal
severity: normal
status: open
title: Update `ssl.PROTOCOL_TLSv1_2` docs since it is not the newest TLS version
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43641>
_______________________________________

From report at bugs.python.org  Sat Mar 27 11:54:09 2021
From: report at bugs.python.org (An1c0de)
Date: Sat, 27 Mar 2021 15:54:09 +0000
Subject: [issue43642] ctypes.util.find_library can't find the lib on Alpine
Message-ID: <1616860449.08.0.544658772631.issue43642@roundup.psfhosted.org>


New submission from An1c0de <anvk.ddd1 at gmail.com>:

Hi!

ctypes.util.find_library can't find the lib on Alpine. I think this is because the logic is not cover the  digital suffixes.

Docker example:

```
docker run --rm -it python:3.9-alpine sh

apk add libuuid build-base

ls /lib/libuuid*
# /lib/libuuid.so.1
# /lib/libuuid.so.1.3.0

python -c 'from ctypes.util import find_library; print(find_library("uuid"))'
# None


## Workaround:

cd /lib && ln -s libuuid.so.1 libuuid.so

python -c 'from ctypes.util import find_library; print(find_library("uuid"))'
# libuuid.so.1
```

Thanks!

----------
components: ctypes
messages: 389609
nosy: An1c0de
priority: normal
severity: normal
status: open
title: ctypes.util.find_library can't find the lib on Alpine
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43642>
_______________________________________

From report at bugs.python.org  Sat Mar 27 11:55:53 2021
From: report at bugs.python.org (Illia Volochii)
Date: Sat, 27 Mar 2021 15:55:53 +0000
Subject: [issue43641] Update `ssl.PROTOCOL_TLSv1_2` docs since it is not the
 newest TLS version
In-Reply-To: <1616860213.53.0.619119120608.issue43641@roundup.psfhosted.org>
Message-ID: <1616860553.52.0.786887502668.issue43641@roundup.psfhosted.org>


Change by Illia Volochii <illia.volochii at gmail.com>:


----------
keywords: +patch
pull_requests: +23789
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25041

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43641>
_______________________________________

From report at bugs.python.org  Sat Mar 27 13:04:05 2021
From: report at bugs.python.org (miss-islington)
Date: Sat, 27 Mar 2021 17:04:05 +0000
Subject: [issue43466] ssl/hashlib: Add configure option to set or auto-detect
 rpath to OpenSSL libs
In-Reply-To: <1615418043.46.0.229114131093.issue43466@roundup.psfhosted.org>
Message-ID: <1616864645.99.0.957948259759.issue43466@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset bacefbf41461ab703b8d561f0e3d766427eab367 by Christian Heimes in branch 'master':
bpo-43466: Unsupported static build hack (GH-25002)
https://github.com/python/cpython/commit/bacefbf41461ab703b8d561f0e3d766427eab367


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43466>
_______________________________________

From report at bugs.python.org  Sat Mar 27 13:16:45 2021
From: report at bugs.python.org (=?utf-8?q?J=C3=B6rn_Heissler?=)
Date: Sat, 27 Mar 2021 17:16:45 +0000
Subject: [issue37773] ValueError: I/O operation on closed file. in ZipFile
 destructor
In-Reply-To: <1565084150.95.0.74829896398.issue37773@roundup.psfhosted.org>
Message-ID: <1616865405.16.0.25513413593.issue37773@roundup.psfhosted.org>


J?rn Heissler <launchpad2019 at tutnicht.de> added the comment:

Thanks Serhiy for the explanation, it's making sense now.

Guess whatever I did back then (no idea what I was working on) was basically a mistake; I should have closed my ZipFile properly, e.g. by using context managers. So maybe it's not really a cpython bug.

I ran a git-bisect back then and came up with https://hg.python.org/lookup/ada319bb6d0ebcc68d3e0ef2b4279ea061877ac8 as cause.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37773>
_______________________________________

From report at bugs.python.org  Sat Mar 27 13:21:14 2021
From: report at bugs.python.org (miss-islington)
Date: Sat, 27 Mar 2021 17:21:14 +0000
Subject: [issue39231] Mistaken notion in tutorial
In-Reply-To: <1578334311.83.0.989380005846.issue39231@roundup.psfhosted.org>
Message-ID: <1616865674.55.0.503397790912.issue39231@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: +23790
pull_request: https://github.com/python/cpython/pull/25042

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39231>
_______________________________________

From report at bugs.python.org  Sat Mar 27 13:21:12 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 27 Mar 2021 17:21:12 +0000
Subject: [issue39231] Mistaken notion in tutorial
In-Reply-To: <1578334311.83.0.989380005846.issue39231@roundup.psfhosted.org>
Message-ID: <1616865672.72.0.122639876233.issue39231@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset a53e9a7cf5912a44c5143e353912e44cfcfca7dc by Irit Katriel in branch 'master':
bpo-39231: correct tutorial annotations section (GH-25029)
https://github.com/python/cpython/commit/a53e9a7cf5912a44c5143e353912e44cfcfca7dc


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39231>
_______________________________________

From report at bugs.python.org  Sat Mar 27 13:21:25 2021
From: report at bugs.python.org (miss-islington)
Date: Sat, 27 Mar 2021 17:21:25 +0000
Subject: [issue39231] Mistaken notion in tutorial
In-Reply-To: <1578334311.83.0.989380005846.issue39231@roundup.psfhosted.org>
Message-ID: <1616865685.32.0.639634008828.issue39231@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +23791
pull_request: https://github.com/python/cpython/pull/25043

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39231>
_______________________________________

From report at bugs.python.org  Sat Mar 27 13:31:03 2021
From: report at bugs.python.org (miss-islington)
Date: Sat, 27 Mar 2021 17:31:03 +0000
Subject: [issue39231] Mistaken notion in tutorial
In-Reply-To: <1578334311.83.0.989380005846.issue39231@roundup.psfhosted.org>
Message-ID: <1616866263.89.0.288548314109.issue39231@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 6fcebbb5a8cea25717804f5be9b6878104748ea5 by Miss Islington (bot) in branch '3.8':
bpo-39231: correct tutorial annotations section (GH-25029)
https://github.com/python/cpython/commit/6fcebbb5a8cea25717804f5be9b6878104748ea5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39231>
_______________________________________

From report at bugs.python.org  Sat Mar 27 13:43:14 2021
From: report at bugs.python.org (miss-islington)
Date: Sat, 27 Mar 2021 17:43:14 +0000
Subject: [issue39231] Mistaken notion in tutorial
In-Reply-To: <1578334311.83.0.989380005846.issue39231@roundup.psfhosted.org>
Message-ID: <1616866994.8.0.135005504426.issue39231@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 7990072999b7e9b4ef6b1f6bb376d441a5a41d74 by Miss Islington (bot) in branch '3.9':
bpo-39231: correct tutorial annotations section (GH-25029)
https://github.com/python/cpython/commit/7990072999b7e9b4ef6b1f6bb376d441a5a41d74


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39231>
_______________________________________

From report at bugs.python.org  Sat Mar 27 13:48:56 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 27 Mar 2021 17:48:56 +0000
Subject: [issue39231] Mistaken notion in tutorial
In-Reply-To: <1578334311.83.0.989380005846.issue39231@roundup.psfhosted.org>
Message-ID: <1616867336.86.0.982847708387.issue39231@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type: enhancement -> behavior
versions: +Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39231>
_______________________________________

From report at bugs.python.org  Sat Mar 27 14:21:54 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 27 Mar 2021 18:21:54 +0000
Subject: [issue43639] Do not raise AttributeError on instance attribute
 update/deletion if data descriptor with missing __set__/__delete__ method
 found on its type
In-Reply-To: <1616848832.19.0.971517857631.issue43639@roundup.psfhosted.org>
Message-ID: <1616869314.39.0.0708024872301.issue43639@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +rhettinger
versions:  -Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43639>
_______________________________________

From report at bugs.python.org  Sat Mar 27 14:45:11 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 27 Mar 2021 18:45:11 +0000
Subject: [issue42041] venv subprocess call to python resolves to wrong
 interpreter
In-Reply-To: <1602741057.44.0.746329954435.issue42041@roundup.psfhosted.org>
Message-ID: <1616870711.83.0.193124332483.issue42041@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42041>
_______________________________________

From report at bugs.python.org  Sat Mar 27 14:50:39 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 27 Mar 2021 18:50:39 +0000
Subject: [issue37339] Document that os.path.ismount() returns true for nested
 btrfs subvolumes
In-Reply-To: <1560939042.69.0.683071795623.issue37339@roundup.psfhosted.org>
Message-ID: <1616871039.85.0.0891919038022.issue37339@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
title: os.path.ismount returns true on nested btrfs subvolumes -> Document that os.path.ismount() returns true for nested btrfs subvolumes
type: behavior -> enhancement
versions: +Python 3.10 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37339>
_______________________________________

From report at bugs.python.org  Sat Mar 27 15:14:14 2021
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 27 Mar 2021 19:14:14 +0000
Subject: [issue42134] Raise ImportWarning when falling back to find_module()
In-Reply-To: <1603494610.04.0.950789467246.issue42134@roundup.psfhosted.org>
Message-ID: <1616872454.45.0.023743092873.issue42134@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
keywords: +patch
pull_requests: +23792
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25044

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42134>
_______________________________________

From report at bugs.python.org  Sat Mar 27 16:58:48 2021
From: report at bugs.python.org (Siddharth Chabra)
Date: Sat, 27 Mar 2021 20:58:48 +0000
Subject: [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1616878728.8.0.614104238084.issue22790@roundup.psfhosted.org>


Change by Siddharth Chabra <siddharthchabra at gmail.com>:


----------
nosy: +siddharthchabra
versions:  -Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22790>
_______________________________________

From report at bugs.python.org  Sat Mar 27 17:21:46 2021
From: report at bugs.python.org (Andreas Poehlmann)
Date: Sat, 27 Mar 2021 21:21:46 +0000
Subject: [issue43643] importlib.readers.MultiplexedPath.name is not a property
Message-ID: <1616880106.57.0.50019170707.issue43643@roundup.psfhosted.org>


New submission from Andreas Poehlmann <andreas at poehlmann.io>:

Hello,

I was using the `importlib_resources` backport and encountered this issue, which is also present in cpython:

`importlib.readers.MultiplexedPath.name` is not a property as required by `importlib.abc.Traversable` 


I can prepare a pull request if it helps.

Cheers,
Andreas

----------
components: Library (Lib)
messages: 389615
nosy: ap--, jaraco
priority: normal
severity: normal
status: open
title: importlib.readers.MultiplexedPath.name is not a property
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43643>
_______________________________________

From report at bugs.python.org  Sat Mar 27 17:22:06 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 27 Mar 2021 21:22:06 +0000
Subject: [issue1634034] Show "expected" token on syntax error
Message-ID: <1616880126.52.0.873178300331.issue1634034@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Closing as per above

----------
resolution:  -> out of date
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1634034>
_______________________________________

From report at bugs.python.org  Sat Mar 27 17:36:01 2021
From: report at bugs.python.org (florian-rathgeber)
Date: Sat, 27 Mar 2021 21:36:01 +0000
Subject: [issue38038] Remove urllib.parse._splittype from xmlrpc.client
In-Reply-To: <1567693191.9.0.654396049137.issue38038@roundup.psfhosted.org>
Message-ID: <1616880961.26.0.0417214298554.issue38038@roundup.psfhosted.org>


florian-rathgeber <florian.rathgeber at gmail.com> added the comment:

This change caused an (I presume unintended) behavior change that breaks some xmlrpc users: previously, the XLMRPC handler was everything after the host part of the URI (https://github.com/python/cpython/blame/32f825393e5836ab71de843596379fa3f9e23c7a/Lib/xmlrpc/client.py#L1428), but now the query string is *discarded* (https://github.com/python/cpython/blame/63298930fb531ba2bb4f23bc3b915dbf1e17e9e1/Lib/xmlrpc/client.py#L1424).

This is known to break the XMLRPC for DokuWiki (https://www.dokuwiki.org/devel:xmlrpc), which uses query parameters for authentication: https://github.com/kynan/dokuwikixmlrpc/issues/8

----------
nosy: +florian-rathgeber

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38038>
_______________________________________

From report at bugs.python.org  Sat Mar 27 17:46:34 2021
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 27 Mar 2021 21:46:34 +0000
Subject: [issue38038] Remove urllib.parse._splittype from xmlrpc.client
In-Reply-To: <1567693191.9.0.654396049137.issue38038@roundup.psfhosted.org>
Message-ID: <1616881594.22.0.44449873113.issue38038@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Please open a new bug and include a reference to this issue.

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38038>
_______________________________________

From report at bugs.python.org  Sat Mar 27 17:46:47 2021
From: report at bugs.python.org (Chris Angelico)
Date: Sat, 27 Mar 2021 21:46:47 +0000
Subject: [issue43433] xmlrpc.client ignores query in URI ("?action=xmlrpc2")
 since python-3.9
In-Reply-To: <1615206556.6.0.195752820504.issue43433@roundup.psfhosted.org>
Message-ID: <1616881607.84.0.306289574518.issue43433@roundup.psfhosted.org>


Change by Chris Angelico <rosuav at gmail.com>:


----------
keywords: +patch
nosy: +Rosuav
nosy_count: 3.0 -> 4.0
pull_requests: +23793
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25045

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43433>
_______________________________________

From report at bugs.python.org  Sat Mar 27 17:47:09 2021
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 27 Mar 2021 21:47:09 +0000
Subject: [issue43617] Missing definition in configure.ac causing autoreconf to
 create damaged configure script
In-Reply-To: <1616597538.33.0.0386305243834.issue43617@roundup.psfhosted.org>
Message-ID: <1616881629.27.0.130100457925.issue43617@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset 064bc07f241dceec2fc577cbf5c31fa6d63fe320 by Christian Heimes in branch '3.9':
[3.9] bpo-43617: Check autoconf-archive package in configure.ac (GH-25016) (GH-25034)
https://github.com/python/cpython/commit/064bc07f241dceec2fc577cbf5c31fa6d63fe320


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43617>
_______________________________________

From report at bugs.python.org  Sat Mar 27 17:47:18 2021
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 27 Mar 2021 21:47:18 +0000
Subject: [issue43617] Missing definition in configure.ac causing autoreconf to
 create damaged configure script
In-Reply-To: <1616597538.33.0.0386305243834.issue43617@roundup.psfhosted.org>
Message-ID: <1616881638.76.0.215814132551.issue43617@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset e516290976626cf8535b88a14b1b34e37f88a78a by Christian Heimes in branch '3.8':
[3.8] bpo-43617: Check autoconf-archive package in configure.ac (GH-25016) (GH-25035)
https://github.com/python/cpython/commit/e516290976626cf8535b88a14b1b34e37f88a78a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43617>
_______________________________________

From report at bugs.python.org  Sat Mar 27 17:48:25 2021
From: report at bugs.python.org (Chris Angelico)
Date: Sat, 27 Mar 2021 21:48:25 +0000
Subject: [issue43433] xmlrpc.client ignores query in URI ("?action=xmlrpc2")
 since python-3.9
In-Reply-To: <1615206556.6.0.195752820504.issue43433@roundup.psfhosted.org>
Message-ID: <1616881705.54.0.843839846211.issue43433@roundup.psfhosted.org>


Chris Angelico <rosuav at gmail.com> added the comment:

Can confirm. This changed in bpo-38038 and the fix isn't too difficult.

Adding 3.10 in case it's decided that this shouldn't be patched onto 3.9.

----------
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43433>
_______________________________________

From report at bugs.python.org  Sat Mar 27 17:48:36 2021
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 27 Mar 2021 21:48:36 +0000
Subject: [issue43617] Missing definition in configure.ac causing autoreconf to
 create damaged configure script
In-Reply-To: <1616597538.33.0.0386305243834.issue43617@roundup.psfhosted.org>
Message-ID: <1616881716.19.0.441473328193.issue43617@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Thanks for the bug report! I ran into the issue a couple of weeks ago on one machine that had autoconf but not the archive package installed.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43617>
_______________________________________

From report at bugs.python.org  Sat Mar 27 17:52:36 2021
From: report at bugs.python.org (miss-islington)
Date: Sat, 27 Mar 2021 21:52:36 +0000
Subject: [issue43562] test_ssl.NetworkedTests.test_timeout_connect_ex fails if
 network is unreachable
In-Reply-To: <1616187447.7.0.603298479381.issue43562@roundup.psfhosted.org>
Message-ID: <1616881956.09.0.00683121740635.issue43562@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 29c451c6989c3c94fa0a9facf187c24f3cbf2420 by Carl Meyer in branch 'master':
bpo-43562: fix test_ssl to skip on unreachable network (GH-24937)
https://github.com/python/cpython/commit/29c451c6989c3c94fa0a9facf187c24f3cbf2420


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43562>
_______________________________________

From report at bugs.python.org  Sat Mar 27 17:53:13 2021
From: report at bugs.python.org (miss-islington)
Date: Sat, 27 Mar 2021 21:53:13 +0000
Subject: [issue43562] test_ssl.NetworkedTests.test_timeout_connect_ex fails if
 network is unreachable
In-Reply-To: <1616187447.7.0.603298479381.issue43562@roundup.psfhosted.org>
Message-ID: <1616881993.67.0.879427184739.issue43562@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +23794
pull_request: https://github.com/python/cpython/pull/25046

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43562>
_______________________________________

From report at bugs.python.org  Sat Mar 27 17:53:25 2021
From: report at bugs.python.org (miss-islington)
Date: Sat, 27 Mar 2021 21:53:25 +0000
Subject: [issue43562] test_ssl.NetworkedTests.test_timeout_connect_ex fails if
 network is unreachable
In-Reply-To: <1616187447.7.0.603298479381.issue43562@roundup.psfhosted.org>
Message-ID: <1616882005.53.0.619820250883.issue43562@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +23795
pull_request: https://github.com/python/cpython/pull/25047

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43562>
_______________________________________

From report at bugs.python.org  Sat Mar 27 18:10:40 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 27 Mar 2021 22:10:40 +0000
Subject: [issue43644] importlib.resources.as_file undocumented
Message-ID: <1616883040.71.0.873625132004.issue43644@roundup.psfhosted.org>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

As reported in https://github.com/python/importlib_resources/issues/210, the `as_file` function of importlib.resources is undocumented in CPython.

----------
messages: 389624
nosy: jaraco
priority: normal
severity: normal
status: open
title: importlib.resources.as_file undocumented

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43644>
_______________________________________

From report at bugs.python.org  Sat Mar 27 19:08:53 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 27 Mar 2021 23:08:53 +0000
Subject: [issue43644] importlib.resources.as_file undocumented
In-Reply-To: <1616883040.71.0.873625132004.issue43644@roundup.psfhosted.org>
Message-ID: <1616886533.05.0.234562522445.issue43644@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
assignee:  -> jaraco
components: +Documentation
type:  -> enhancement
versions: +Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43644>
_______________________________________

From report at bugs.python.org  Sat Mar 27 19:36:42 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 27 Mar 2021 23:36:42 +0000
Subject: [issue43644] importlib.resources.as_file undocumented
In-Reply-To: <1616883040.71.0.873625132004.issue43644@roundup.psfhosted.org>
Message-ID: <1616888202.06.0.42179281666.issue43644@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
keywords: +patch
pull_requests: +23796
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25048

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43644>
_______________________________________

From report at bugs.python.org  Sat Mar 27 19:57:28 2021
From: report at bugs.python.org (Chris Angelico)
Date: Sat, 27 Mar 2021 23:57:28 +0000
Subject: [issue43614] Search is not beginner friendly
In-Reply-To: <1616584368.72.0.108883750732.issue43614@roundup.psfhosted.org>
Message-ID: <1616889448.47.0.888963312646.issue43614@roundup.psfhosted.org>


Change by Chris Angelico <rosuav at gmail.com>:


----------
keywords: +patch
nosy: +Rosuav
nosy_count: 5.0 -> 6.0
pull_requests: +23797
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25045

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43614>
_______________________________________

From report at bugs.python.org  Sat Mar 27 20:25:59 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 28 Mar 2021 00:25:59 +0000
Subject: [issue43644] importlib.resources.as_file undocumented
In-Reply-To: <1616883040.71.0.873625132004.issue43644@roundup.psfhosted.org>
Message-ID: <1616891159.97.0.495828807441.issue43644@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:


New changeset af50c84643ce21cfbdfdabbdfae6bd5e1368c542 by Jason R. Coombs in branch 'master':
bpo-43644: Add docs for importlib.resources.as_file. (#25048)
https://github.com/python/cpython/commit/af50c84643ce21cfbdfdabbdfae6bd5e1368c542


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43644>
_______________________________________

From report at bugs.python.org  Sat Mar 27 20:26:20 2021
From: report at bugs.python.org (miss-islington)
Date: Sun, 28 Mar 2021 00:26:20 +0000
Subject: [issue43644] importlib.resources.as_file undocumented
In-Reply-To: <1616883040.71.0.873625132004.issue43644@roundup.psfhosted.org>
Message-ID: <1616891180.24.0.289947359544.issue43644@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: +23798
pull_request: https://github.com/python/cpython/pull/25049

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43644>
_______________________________________

From report at bugs.python.org  Sat Mar 27 20:48:59 2021
From: report at bugs.python.org (miss-islington)
Date: Sun, 28 Mar 2021 00:48:59 +0000
Subject: [issue43644] importlib.resources.as_file undocumented
In-Reply-To: <1616883040.71.0.873625132004.issue43644@roundup.psfhosted.org>
Message-ID: <1616892539.72.0.485589385097.issue43644@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 138e039ff9e5330709643b1bfe623eeac8fdc681 by Miss Islington (bot) in branch '3.9':
bpo-43644: Add docs for importlib.resources.as_file. (GH-25048)
https://github.com/python/cpython/commit/138e039ff9e5330709643b1bfe623eeac8fdc681


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43644>
_______________________________________

From report at bugs.python.org  Sat Mar 27 20:49:47 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 28 Mar 2021 00:49:47 +0000
Subject: [issue43644] importlib.resources.as_file undocumented
In-Reply-To: <1616883040.71.0.873625132004.issue43644@roundup.psfhosted.org>
Message-ID: <1616892587.92.0.863132426422.issue43644@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43644>
_______________________________________

From report at bugs.python.org  Sat Mar 27 21:19:55 2021
From: report at bugs.python.org (Anthony Flury)
Date: Sun, 28 Mar 2021 01:19:55 +0000
Subject: [issue43614] Search is not beginner friendly
In-Reply-To: <1616584368.72.0.108883750732.issue43614@roundup.psfhosted.org>
Message-ID: <1616894395.98.0.420029199903.issue43614@roundup.psfhosted.org>


Anthony Flury <anthony.flury at btinternet.com> added the comment:

Is PR 25045 the correct Pull request - this Issue is a documentation change - the linked PR is related to Issue 43433 (a change to xmlrpc.client ?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43614>
_______________________________________

From report at bugs.python.org  Sat Mar 27 21:41:39 2021
From: report at bugs.python.org (Oliver Newman)
Date: Sun, 28 Mar 2021 01:41:39 +0000
Subject: [issue32146] multiprocessing freeze_support needed outside win32
In-Reply-To: <1511778835.66.0.213398074469.issue32146@psf.upfronthosting.co.za>
Message-ID: <1616895699.4.0.847218586199.issue32146@roundup.psfhosted.org>


Change by Oliver Newman <oliver at whmsi.com>:


----------
nosy: +onew

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32146>
_______________________________________

From report at bugs.python.org  Sat Mar 27 22:09:36 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 28 Mar 2021 02:09:36 +0000
Subject: [issue38948] [Windows] require an existing directory and suport
 junctions in ntpath.ismount()
In-Reply-To: <1575196854.18.0.0543230038393.issue38948@roundup.psfhosted.org>
Message-ID: <1616897376.16.0.500281736523.issue38948@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

Here's a concrete implementation of the above discussion. 

    _is_windows = (sys.platform == 'win32')

    def ismount(path):
        """Test whether a path is a mount point"""
        path = os.fspath(path)
        if isinstance(path, bytes):
            sep = b'\\'
            extended_devices = b'\\\\?\\'
            normal_devices = b'\\\\.\\'
            global_link = b'GLOBAL'
            unc_device = b'UNC'
        else:
            sep = '\\'
            extended_devices = '\\\\?\\'
            normal_devices = '\\\\.\\'
            global_link = 'GLOBAL'
            unc_device = 'UNC'
        # In Windows, require an existing, accessible directory.
        if _is_windows:
            if not isdir(path):
                return False
            try:
                s = os.lstat(path)
                if s.st_reparse_tag == stat.IO_REPARSE_TAG_MOUNT_POINT:
                    # isdir() verified the target directory.
                    return True
            except (OSError, ValueError):
                return False
        path = abspath(path)
        drive, drive_path = splitdrive(path)
        if not drive:
            return False
        # A drive root is a mount point.
        if drive_path == sep:
            return True
        # A root path is not required for a UNC drive.
        if not drive_path and drive[0] in sep:
            if not drive.startswith((extended_devices, normal_devices)):
                return True
            # Check for \\?\[Global]\UNC. Ignore repeated "Global" links.
            comps = [c.upper() for c in drive[4:].split(sep)]
            for c in comps:
                if c != global_link:
                    break
            if c == unc_device:
                return True
        return False

Removing the dependency on GetVolumePathNameW() also eliminates buggy behavior with substitute drives. For example, if substitute drive "W:" maps to r"C:\Windows", GetVolumePathNameW() mistakenly claims r"W:\System32" is a volume mount point.

In principle, this implementation also supports "\\?\[Global]\UNC\server\share" mount points on the "UNC" device, but it depends on fixing bpo-37609. The suggested rewrite for the latter issue also includes support for repeated slashes in a UNC drive, e.g. r"\\server\\\share" and r"\\?\\\Global\\\UNC\\\server\\\share" are valid.

For POSIX, ntpath._abspath_fallback() has to be fixed to correctly resolve drive-relative paths. For example:

    def _abspath_fallback(path):
        """Return the absolute version of a path."""
        path = os.fspath(path)
        if isinstance(path, bytes):
            sep = b'\\'
            colon = b':'
            cwd = os.getcwdb()
        else:
            sep = '\\'
            colon = ':'
            cwd = os.getcwd()
        if not isabs(path):
            # For a drive-relative path, default to the root directory
            # on the drive if the process working directory is on a
            # different drive.
            if path[1:2] == colon and path[:2].upper() != cwd[:2].upper():
                path = path[:2] + sep + path[2:]
            else:
                path = join(cwd, path)
        return normpath(path)

Since _abspath_fallback() is no longer needed in any version of Windows, maybe it should simply assume that the working drive is "C:" and the working directory on all drives is the root directory.

----------
components: +Library (Lib)
dependencies: +support "UNC" device paths in ntpath.splitdrive
title: os.path.ismount() returns False for current working drive -> [Windows] require an existing directory and suport junctions in ntpath.ismount()
versions: +Python 3.10 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38948>
_______________________________________

From report at bugs.python.org  Sat Mar 27 22:30:06 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 28 Mar 2021 02:30:06 +0000
Subject: [issue35026] Winreg's documentation lacks mentioning required
 permission at some points
In-Reply-To: <1539940450.92.0.788709270274.issue35026@psf.upfronthosting.co.za>
Message-ID: <1616898606.78.0.486404470394.issue35026@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35026>
_______________________________________

From report at bugs.python.org  Sat Mar 27 23:03:27 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 28 Mar 2021 03:03:27 +0000
Subject: [issue34816] raise AttributeError if loading fails in
 ctypes.LibraryLoader.__getattr__
In-Reply-To: <1538032457.9.0.545547206417.issue34816@psf.upfronthosting.co.za>
Message-ID: <1616900607.1.0.933910576325.issue34816@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> __getattr__ method of LibraryLoader catches the OSError and 
> raises an AttributeError 

Yes. It seems no one was keen to work on this. I think it's relatively easy, so I'll add that flag in case someone is looking for an easy issue.

----------
keywords: +easy
title: ctypes + hasattr -> raise AttributeError if loading fails in ctypes.LibraryLoader.__getattr__
versions: +Python 3.10, Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34816>
_______________________________________

From report at bugs.python.org  Sat Mar 27 23:07:14 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 28 Mar 2021 03:07:14 +0000
Subject: [issue33406] [ctypes] increase the refcount of a callback function
In-Reply-To: <1525243145.23.0.682650639539.issue33406@psf.upfronthosting.co.za>
Message-ID: <1616900834.77.0.310848738015.issue33406@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
versions: +Python 3.10 -Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33406>
_______________________________________

From report at bugs.python.org  Sat Mar 27 23:18:40 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 28 Mar 2021 03:18:40 +0000
Subject: [issue35440] Setup failed 0x80072f7d - Unspecified error
In-Reply-To: <1544259957.98.0.788709270274.issue35440@psf.upfronthosting.co.za>
Message-ID: <1616901520.37.0.36884136298.issue35440@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35440>
_______________________________________

From report at bugs.python.org  Sat Mar 27 23:23:15 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 28 Mar 2021 03:23:15 +0000
Subject: [issue37756] Error 0x80070643 when installing
In-Reply-To: <1564932178.65.0.171539834023.issue37756@roundup.psfhosted.org>
Message-ID: <1616901795.35.0.258437483732.issue37756@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37756>
_______________________________________

From report at bugs.python.org  Sat Mar 27 23:26:49 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 28 Mar 2021 03:26:49 +0000
Subject: [issue26227] Windows: socket.gethostbyaddr(name) fails for non-ASCII
 hostname
In-Reply-To: <1453942730.98.0.111965775649.issue26227@psf.upfronthosting.co.za>
Message-ID: <1616902009.94.0.856207669689.issue26227@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
components: +Library (Lib)
keywords: +3.10regression, 3.6regression, 3.7regression, 3.8regression, 3.9regression -patch
stage: test needed -> needs patch
type: crash -> behavior
versions: +Python 3.10 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26227>
_______________________________________

From report at bugs.python.org  Sat Mar 27 23:32:22 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 28 Mar 2021 03:32:22 +0000
Subject: [issue37801] Compilation on MINGW64 fails (CODESET,wcstok,...)
In-Reply-To: <1565351601.24.0.515340331062.issue37801@roundup.psfhosted.org>
Message-ID: <1616902342.33.0.0495314350173.issue37801@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
versions: +Python 3.10, Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37801>
_______________________________________

From report at bugs.python.org  Sat Mar 27 23:36:06 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 28 Mar 2021 03:36:06 +0000
Subject: [issue39318] NamedTemporaryFile could cause double-close on an fd if
 _TemporaryFileWrapper throws
In-Reply-To: <1578891407.19.0.452054572225.issue39318@roundup.psfhosted.org>
Message-ID: <1616902566.4.0.330672953671.issue39318@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
Removed message: https://bugs.python.org/msg359981

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39318>
_______________________________________

From report at bugs.python.org  Sat Mar 27 23:37:24 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 28 Mar 2021 03:37:24 +0000
Subject: [issue39318] NamedTemporaryFile could cause double-close on an fd if
 _TemporaryFileWrapper throws
In-Reply-To: <1578891407.19.0.452054572225.issue39318@roundup.psfhosted.org>
Message-ID: <1616902644.92.0.44008959614.issue39318@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
versions: +Python 3.10 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39318>
_______________________________________

From report at bugs.python.org  Sun Mar 28 00:12:55 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 28 Mar 2021 04:12:55 +0000
Subject: [issue25643] Python tokenizer rewriting
In-Reply-To: <1447723653.14.0.424824913135.issue25643@psf.upfronthosting.co.za>
Message-ID: <1616904775.32.0.684566433189.issue25643@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
nosy: +pablogsal
nosy_count: 7.0 -> 8.0
pull_requests: +23799
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25050

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25643>
_______________________________________

From report at bugs.python.org  Sun Mar 28 01:34:18 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 28 Mar 2021 05:34:18 +0000
Subject: [issue22121] Start IDLE from icon in a better place.
In-Reply-To: <1406966032.01.0.548285467026.issue22121@psf.upfronthosting.co.za>
Message-ID: <1616909658.62.0.767475372175.issue22121@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> if sys.stdout is None and no file in sys.argv

With the app distribution from the Microsoft Store, "idle3.x.exe" is a GUI executable that runs idlelib. There isn't a console version. Also, GUI scripts are usually run with the pyw.exe launcher or pythonw.exe, e.g. `pyw -m idlelib`, to ensure it's not attached to a console session. Otherwise the shell waits for a console app such as py.exe, which blocks the console. Moreover, when a console session is closed, all processes attached to it have 5 seconds to exit before they get terminated. I generally don't want either behavior with a GUI app, except for the case of debugging an application that writes debug output to standard error or standard output. On the other hand, I generally do want to inherit the working directory of the parent process, such as a command-line shell. 

I think the problem would be adequately addressed by blacklisting directories that are known to be inappropriate and a common problem, such as sys.prefix and Windows system directories. I agree with the suggestion to automatically change the working directory in such cases to the user's "Documents" directory, i.e. FOLDERID_Documents.

----------
versions: +Python 3.10 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22121>
_______________________________________

From report at bugs.python.org  Sun Mar 28 02:19:49 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 28 Mar 2021 06:19:49 +0000
Subject: [issue22121] Start IDLE from icon in a better place.
In-Reply-To: <1406966032.01.0.548285467026.issue22121@psf.upfronthosting.co.za>
Message-ID: <1616912389.13.0.930753337734.issue22121@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> blacklisting directories 

Ensure that filepaths in sys.argv are resolved before changing out of a blacklisted directory. Also, for file open/save dialogs, as opposed to the working directory of the Python subprocess (e.g. os.getcwd() in the REPL), it's typical to default to the user profile directory or the last-accessed directory instead of the process working directory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22121>
_______________________________________

From report at bugs.python.org  Sun Mar 28 03:31:28 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 28 Mar 2021 07:31:28 +0000
Subject: [issue35144] TemporaryDirectory clean-up fails with unsearchable
 directories
In-Reply-To: <1541148008.66.0.788709270274.issue35144@psf.upfronthosting.co.za>
Message-ID: <1616916688.31.0.461202331719.issue35144@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35144>
_______________________________________

From report at bugs.python.org  Sun Mar 28 05:21:24 2021
From: report at bugs.python.org (frathgeber)
Date: Sun, 28 Mar 2021 09:21:24 +0000
Subject: [issue43645] xmlrpc.client.ServerProxy silently drops query string
 from URI
Message-ID: <1616923284.46.0.0991006696827.issue43645@roundup.psfhosted.org>


New submission from frathgeber <florian.rathgeber at gmail.com>:

The change introduced in https://github.com/python/cpython/pull/15703 (bpo-38038) caused an (I presume unintended) behavior change that breaks some xmlrpc users: previously, the XLMRPC handler was everything after the host part of the URI (https://github.com/python/cpython/blame/32f825393e5836ab71de843596379fa3f9e23c7a/Lib/xmlrpc/client.py#L1428), but now the query string is *discarded* (https://github.com/python/cpython/blame/63298930fb531ba2bb4f23bc3b915dbf1e17e9e1/Lib/xmlrpc/client.py#L1424).

This is known to break the XMLRPC for DokuWiki (https://www.dokuwiki.org/devel:xmlrpc), which uses query parameters for authentication: https://github.com/kynan/dokuwikixmlrpc/issues/8

----------
components: Library (Lib)
messages: 389632
nosy: christian.heimes, kynan
priority: normal
severity: normal
status: open
title: xmlrpc.client.ServerProxy silently drops query string from URI
type: behavior
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43645>
_______________________________________

From report at bugs.python.org  Sun Mar 28 05:22:04 2021
From: report at bugs.python.org (frathgeber)
Date: Sun, 28 Mar 2021 09:22:04 +0000
Subject: [issue38038] Remove urllib.parse._splittype from xmlrpc.client
In-Reply-To: <1567693191.9.0.654396049137.issue38038@roundup.psfhosted.org>
Message-ID: <1616923324.03.0.740734055521.issue38038@roundup.psfhosted.org>


frathgeber <florian.rathgeber at gmail.com> added the comment:

Filed bpo-43645

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38038>
_______________________________________

From report at bugs.python.org  Sun Mar 28 05:28:19 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 28 Mar 2021 09:28:19 +0000
Subject: [issue43645] xmlrpc.client.ServerProxy silently drops query string
 from URI
In-Reply-To: <1616923284.46.0.0991006696827.issue43645@roundup.psfhosted.org>
Message-ID: <1616923699.85.0.987165863914.issue43645@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> xmlrpc.client ignores query in URI ("?action=xmlrpc2") since python-3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43645>
_______________________________________

From report at bugs.python.org  Sun Mar 28 05:33:23 2021
From: report at bugs.python.org (frathgeber)
Date: Sun, 28 Mar 2021 09:33:23 +0000
Subject: [issue43433] xmlrpc.client ignores query in URI ("?action=xmlrpc2")
 since python-3.9
In-Reply-To: <1615206556.6.0.195752820504.issue43433@roundup.psfhosted.org>
Message-ID: <1616924003.44.0.916491646388.issue43433@roundup.psfhosted.org>


Change by frathgeber <florian.rathgeber at gmail.com>:


----------
nosy: +kynan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43433>
_______________________________________

From report at bugs.python.org  Sun Mar 28 05:52:49 2021
From: report at bugs.python.org (Christodoulos Tsoulloftas)
Date: Sun, 28 Mar 2021 09:52:49 +0000
Subject: [issue43646] ForwardRef name conflict during evaluation
Message-ID: <1616925169.4.0.788953716536.issue43646@roundup.psfhosted.org>


New submission from Christodoulos Tsoulloftas <chris at komposta.net>:

Consider two modules with the same name forward references with the same type construct


./a.py


```
from typing import Optional


class Root:
    a: Optional["Person"]


class Person:
    value: str

```


./b.py

```
from typing import Optional


class Root:
    b: Optional["Person"]


class Person:
    value: str

```

There is a naming conflict, I think due to caching, and the type hint of the second property points to the first one.


```
>>> from typing import get_type_hints, Optional
>>> from a import Root as RootA, Person as PersonA
>>> from b import Root as RootB, Person as PersonB
>>> 
>>> roota_hints = get_type_hints(RootA)
>>> rootb_hints = get_type_hints(RootB)
>>> 
>>> print(roota_hints)
{'a': typing.Optional[a.Person]}
>>> print(rootb_hints)
{'b': typing.Optional[a.Person]}
>>> 
>>> assert roota_hints["a"] == Optional[PersonA]
>>> assert rootb_hints["b"] == Optional[PersonB]  # fails, points to PersonA
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AssertionError
>", line 1, in <module>
AssertionError
>>> 

```


The behavior started in python 3.10, I am not sure which alpha version, I am using 3.10.0a6+

----------
components: Library (Lib)
messages: 389634
nosy: tefra
priority: normal
severity: normal
status: open
title: ForwardRef name conflict during evaluation
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43646>
_______________________________________

From report at bugs.python.org  Sun Mar 28 10:11:01 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 28 Mar 2021 14:11:01 +0000
Subject: [issue43433] xmlrpc.client ignores query in URI ("?action=xmlrpc2")
 since python-3.9
In-Reply-To: <1615206556.6.0.195752820504.issue43433@roundup.psfhosted.org>
Message-ID: <1616940661.79.0.419485147834.issue43433@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43433>
_______________________________________

From report at bugs.python.org  Sun Mar 28 11:26:40 2021
From: report at bugs.python.org (Mikhail)
Date: Sun, 28 Mar 2021 15:26:40 +0000
Subject: [issue43647] Sudden crash on print() of some characters
Message-ID: <1616945200.88.0.69202252104.issue43647@roundup.psfhosted.org>


New submission from Mikhail <tetelev99 at mail.ru>:

Hi! I'm not sure if it's an IDLE, library, Xserver or font error, but either way, IDLE is behaving incorrectly. I have installed 3.8 and 3.9 versions, and on both it works, I do not know about the others, but I suspect that on the others, this error also occurs.

The error occurs in the following way: if you type any of the characters '\u270(5-f)' in IDLE, its work will stop unexpectedly. I suspect that for many other symbols there will be the same error, but so far noticed only on these. 

This is what the output to the terminal says:
```
X Error of failed request:  BadLength (poly request too large or internal Xlib length error)
  Major opcode of failed request:  139 (RENDER)
  Minor opcode of failed request:  20 (RenderAddGlyphs)
  Serial number of failed request:  2131
  Current serial number in output stream:  2131
```

I think the error is somewhere in the system error handler or in the incorrect behavior of the fonts display (or both :) ), it would be more correct to catch the error and display it in the output, rather than suddenly terminate.

My system is Ubuntu 20.04, KDE 5.

----------
assignee: terry.reedy
components: IDLE
messages: 389635
nosy: terry.reedy, tetelevm
priority: normal
severity: normal
status: open
title: Sudden crash on print() of some characters
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43647>
_______________________________________

From report at bugs.python.org  Sun Mar 28 12:32:16 2021
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 28 Mar 2021 16:32:16 +0000
Subject: [issue43647] Sudden crash on print() of some characters
In-Reply-To: <1616945200.88.0.69202252104.issue43647@roundup.psfhosted.org>
Message-ID: <1616949136.24.0.631334438578.issue43647@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

I cannot reproduce the issue on Fedora 33 with KDE 5 and libX11-1.6.12:

Python 3.9.2 (default, Feb 20 2021, 00:00:00) 
[GCC 10.2.1 20201125 (Red Hat 10.2.1-9)] on linux
Type "help", "copyright", "credits" or "license()" for more information.
>>> '\u2705'
'?'
>>> '\u270f'
'?'

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43647>
_______________________________________

From report at bugs.python.org  Sun Mar 28 12:47:52 2021
From: report at bugs.python.org (Harry)
Date: Sun, 28 Mar 2021 16:47:52 +0000
Subject: [issue43648] Remove redundant datefmt option in logging file config
Message-ID: <1616950072.91.0.715870512234.issue43648@roundup.psfhosted.org>


New submission from Harry <harry.lees at gmail.com>:

In the logging.conf section of the docs, there is a redundant datefmt option

https://docs.python.org/3.10/howto/logging.html#configuring-logging

----------
assignee: docs at python
components: Documentation
messages: 389637
nosy: Harry-Lees, docs at python
priority: normal
severity: normal
status: open
title: Remove redundant datefmt option in logging file config
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43648>
_______________________________________

From report at bugs.python.org  Sun Mar 28 12:50:07 2021
From: report at bugs.python.org (Harry)
Date: Sun, 28 Mar 2021 16:50:07 +0000
Subject: [issue43648] Remove redundant datefmt option in logging file config
In-Reply-To: <1616950072.91.0.715870512234.issue43648@roundup.psfhosted.org>
Message-ID: <1616950207.78.0.619808180123.issue43648@roundup.psfhosted.org>


Change by Harry <harry.lees at gmail.com>:


----------
keywords: +patch
pull_requests: +23800
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25051

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43648>
_______________________________________

From report at bugs.python.org  Sun Mar 28 13:57:13 2021
From: report at bugs.python.org (Monix)
Date: Sun, 28 Mar 2021 17:57:13 +0000
Subject: [issue42938] [security][CVE-2021-3177] ctypes double representation
 BoF
In-Reply-To: <1610784207.02.0.722384660803.issue42938@roundup.psfhosted.org>
Message-ID: <1616954233.81.0.160779874289.issue42938@roundup.psfhosted.org>


Monix <milanjugessur1404 at gmail.com> added the comment:

Hope everyone has a nice day

----------
nosy: +milanjugessur1404

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42938>
_______________________________________

From report at bugs.python.org  Sun Mar 28 13:57:58 2021
From: report at bugs.python.org (Monix)
Date: Sun, 28 Mar 2021 17:57:58 +0000
Subject: [issue42938] [security][CVE-2021-3177] ctypes double representation
 BoF
In-Reply-To: <1610784207.02.0.722384660803.issue42938@roundup.psfhosted.org>
Message-ID: <1616954278.44.0.823084123361.issue42938@roundup.psfhosted.org>


Monix <milanjugessur1404 at gmail.com> added the comment:

Hope everyone has a nice day

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42938>
_______________________________________

From report at bugs.python.org  Sun Mar 28 14:10:49 2021
From: report at bugs.python.org (Nathaniel Manista)
Date: Sun, 28 Mar 2021 18:10:49 +0000
Subject: [issue17519] unittest should not try to run abstract classes
In-Reply-To: <1363951466.19.0.505441528041.issue17519@psf.upfronthosting.co.za>
Message-ID: <1616955049.89.0.0652123932375.issue17519@roundup.psfhosted.org>


Nathaniel Manista <nathaniel at google.com> added the comment:

michael.foord: I am now persuaded that the feature requested here ought be reconsidered (since my last comment there's been a lot of chatter about it behind closed doors at work, but I can at least cite https://github.com/abseil/abseil-py/issues/166 as a public example of the question coming up).

Would it be appropriate to file a new issue? My issue tracker training brought me up to believe that it's better to reopen an existing closed issue in a circumstance like this, but I respect that that may not be the custom in this issue tracker, and besides I lack the permission in this issue tracker to reopen this issue. ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17519>
_______________________________________

From report at bugs.python.org  Sun Mar 28 14:23:17 2021
From: report at bugs.python.org (Patrick Storz)
Date: Sun, 28 Mar 2021 18:23:17 +0000
Subject: =?utf-8?b?W2lzc3VlNDM2NDldIHRpbWUuc3RyZnRpbWUoJyV6JykgZG9lc24ndCByZXR1?=
 =?utf-8?q?rn_UTC_offset_in_the_form_=C2=B1HHMM?=
Message-ID: <1616955797.13.0.901128004161.issue43649@roundup.psfhosted.org>


New submission from Patrick Storz <Eduard.Braun2 at gmx.de>:

This is a follow-up to https://bugs.python.org/issue20010

I'm seeing this very issue in a recent gcc build of Python 3.8 (mingw-w64-x86_64-python 3.8.8-2 from MSYS2 project):

Python 3.8.8 (default, Feb 20 2021, 07:16:03)  [GCC 10.2.0 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.strftime('%z', time.localtime(time.time()))
'Mitteleurop?ische Sommerzeit'
>>> time.strftime('%Z', time.localtime(time.time()))
'Mitteleurop?ische Sommerzeit'


If this is indeed fixed in MSVCRT, it seems behavior is still not guaranteed when compiling with mingw-w64 gcc.

----------
components: Library (Lib), Windows
messages: 389641
nosy: Aaron.Meurer, Ede123, V?clav Dvo??k, civalin, docs at python, eryksun, ezio.melotti, kepkin, martin-t, paul.moore, r.david.murray, steve.dower, tim.golden, vstinner, zach.ware
priority: normal
severity: normal
status: open
title: time.strftime('%z') doesn't return UTC offset in the form ?HHMM
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43649>
_______________________________________

From report at bugs.python.org  Sun Mar 28 14:23:58 2021
From: report at bugs.python.org (Patrick Storz)
Date: Sun, 28 Mar 2021 18:23:58 +0000
Subject: =?utf-8?b?W2lzc3VlNDM2NDldIHRpbWUuc3RyZnRpbWUoJyV6JykgZG9lc24ndCByZXR1?=
 =?utf-8?q?rn_UTC_offset_in_the_form_=C2=B1HHMM?=
In-Reply-To: <1616955797.13.0.901128004161.issue43649@roundup.psfhosted.org>
Message-ID: <1616955838.9.0.172334603463.issue43649@roundup.psfhosted.org>


Change by Patrick Storz <Eduard.Braun2 at gmx.de>:


_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43649>
_______________________________________

From report at bugs.python.org  Sun Mar 28 14:46:14 2021
From: report at bugs.python.org (mickey695)
Date: Sun, 28 Mar 2021 18:46:14 +0000
Subject: [issue31907] doc: Clarify error message when attempting to call
 function via str.format()
In-Reply-To: <1509410120.18.0.213398074469.issue31907@psf.upfronthosting.co.za>
Message-ID: <1616957174.01.0.63378909672.issue31907@roundup.psfhosted.org>


mickey695 <mickey695 at gmail.com> added the comment:

Happy passover Irit(and/or anyone else celebrating)!

While your suggestion is accurate, I can't say whether it's enough or not.
This is up to you and the other python language development forum to decide :)

----------
versions:  -Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31907>
_______________________________________

From report at bugs.python.org  Sun Mar 28 14:47:36 2021
From: report at bugs.python.org (mickey695)
Date: Sun, 28 Mar 2021 18:47:36 +0000
Subject: [issue31907] doc: Clarify error message when attempting to call
 function via str.format()
In-Reply-To: <1509410120.18.0.213398074469.issue31907@psf.upfronthosting.co.za>
Message-ID: <1616957256.91.0.688638897817.issue31907@roundup.psfhosted.org>


Change by mickey695 <mickey695 at gmail.com>:


----------
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31907>
_______________________________________

From report at bugs.python.org  Sun Mar 28 14:51:20 2021
From: report at bugs.python.org (Ken Jin)
Date: Sun, 28 Mar 2021 18:51:20 +0000
Subject: [issue43646] ForwardRef name conflict during evaluation
In-Reply-To: <1616925169.4.0.788953716536.issue43646@roundup.psfhosted.org>
Message-ID: <1616957480.84.0.38852437208.issue43646@roundup.psfhosted.org>


Ken Jin <kenjin4096 at gmail.com> added the comment:

Wow, thank you for the excellent bug report! Surprisingly, issue42904 's patch fixes this problem as well. I've spent a few hours trying to debug this, and here's some findings:

TLDR:
3.9.1 - 3.10 added ForwardRef recursive evaluation. A guess is that since get_type_hints has always been passing the wrong locals() for classes as mentioned in issue42904, that may cause nested ForwardRefs to be resolved incorrectly.

Observations:

a.py:
```
class Root:
    a: List["Person"]
```

On first call of get_type_hints(Root), _eval_type evals in the following order:

```
# These print the repr, globals['__name__'], locals['__name__'], and code object (only for ForwardRef __forward_code__)

ForwardRef: ForwardRef("List['Person']"), a, None, <code object <module> at 0x0503A7A8, file "<string>", line 1>
GenericAlias: typing.List[ForwardRef('Person')], a, a
ForwardRef: ForwardRef('Person'), a, a, <code object <module> at 0x0503AAF0, file "<string>", line 1>
NA: <class 'a.Person'>
```

Then on a second repeated call of get_type_hints(Root), _eval_type does:

```
ForwardRef: ForwardRef("List['Person']"), a, None, <code object <module> at 0x0503A7A8, file "<string>", line 1>
GenericAlias: typing.List[ForwardRef('Person')], a, a
ForwardRef: ForwardRef('Person'), a, a, <code object <module> at 0x0503AAF0, file "<string>", line 1>
```

It's skipping the last evaluation of <class 'a.Person'>. This also occurs if I call it with RootB after Root.

I managed to reproduce this in 3.9.1-2 as well. The only requirement is to change the example to
```
class Root:
    a: 'List["Person"]'
```

----------
nosy: +gvanrossum, kj, levkivskyi
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43646>
_______________________________________

From report at bugs.python.org  Sun Mar 28 14:59:08 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 28 Mar 2021 18:59:08 +0000
Subject: [issue31907] doc: Clarify error message when attempting to call
 function via str.format()
In-Reply-To: <1509410120.18.0.213398074469.issue31907@psf.upfronthosting.co.za>
Message-ID: <1616957948.12.0.0175718398227.issue31907@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

> The syntax is related to that of formatted string literals, but it is less sophisticated and, in particular, does not support arbitrary expressions.

That seems fine to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31907>
_______________________________________

From report at bugs.python.org  Sun Mar 28 15:11:55 2021
From: report at bugs.python.org (Irit Katriel)
Date: Sun, 28 Mar 2021 19:11:55 +0000
Subject: [issue31907] doc: Clarify error message when attempting to call
 function via str.format()
In-Reply-To: <1509410120.18.0.213398074469.issue31907@psf.upfronthosting.co.za>
Message-ID: <1616958715.7.0.00259870572765.issue31907@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
keywords: +patch
pull_requests: +23801
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25053

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31907>
_______________________________________

From report at bugs.python.org  Sun Mar 28 15:24:26 2021
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 28 Mar 2021 19:24:26 +0000
Subject: =?utf-8?b?W2lzc3VlNDM2NDldIHRpbWUuc3RyZnRpbWUoJyV6JykgZG9lc24ndCByZXR1?=
 =?utf-8?q?rn_UTC_offset_in_the_form_=C2=B1HHMM?=
In-Reply-To: <1616955797.13.0.901128004161.issue43649@roundup.psfhosted.org>
Message-ID: <1616959466.42.0.551141230107.issue43649@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

I closed bpo-20010 because the official PSF distributions of Python 3.5+ for Windows use the Universal CRT (ucrt), the system C runtime library for applications. ucrt does not have this problem with the "%z" format code. For example, using ctypes:

    >>> import ctypes
    >>> timeptr = (ctypes.c_int * 9)()
    >>> dest = (ctypes.c_char * 100)()

    >>> ucrt = ctypes.CDLL('ucrtbase', use_errno=True)
    >>> ucrt.strftime(dest, 100, b"%z", timeptr)
    5
    >>> dest.value
    b'+0100'

Mingw-w64 probably links against msvcrt.dll, the private CRT that's used by some system components. For example:

    >>> msvcrt = ctypes.CDLL('msvcrt', use_errno=True)
    >>> msvcrt.strftime(dest, 100, b"%z", timeptr)
    22
    >>> dest.value
    b'Mitteleurop\xe4ische Zeit'

This a third-party problem since Python is simply calling C strftime(). I'll leave this open for a core developer to consider, but I don't think a workaround is likely at this level. IIRC, compiling Python with Mingw-w64 requires extensive patching, so a workaround is more likely to be applied at that level.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43649>
_______________________________________

From report at bugs.python.org  Sun Mar 28 16:06:40 2021
From: report at bugs.python.org (Mikhail)
Date: Sun, 28 Mar 2021 20:06:40 +0000
Subject: [issue43647] Sudden crash on print() of some characters
In-Reply-To: <1616945200.88.0.69202252104.issue43647@roundup.psfhosted.org>
Message-ID: <1616962000.88.0.740779914128.issue43647@roundup.psfhosted.org>


Mikhail <tetelev99 at mail.ru> added the comment:

I checked the behavior, and found out that it depends on the font. I have "Noto Sans Mono", and if I enter, for example, '\u2709', IDLE crashes. But if I put another font, for example 'Dejavu Mono', just a blank line is displayed. Also, if I output the characters to "dejavu" and then switch to "noto", the bug disappears until I restart IDLE.

P.S. I've played around, and crashes don't always happen when I change font, but, personally, it always happens when I open IDLE with "Noto Sans Mono" font. Also, if needed, I can check tomorrow on other laptops with other systems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43647>
_______________________________________

From report at bugs.python.org  Sun Mar 28 16:19:54 2021
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 28 Mar 2021 20:19:54 +0000
Subject: [issue43647] Sudden crash on print() of some characters
In-Reply-To: <1616945200.88.0.69202252104.issue43647@roundup.psfhosted.org>
Message-ID: <1616962794.16.0.583728011168.issue43647@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Excellent investigation!

Idle automatically picked Dejavu Sans Mono as default font. I have also several fonts for e.g. unicode symbols and emojis installed. Noto Sans Mono CJK fonts are working fine, too. However when I select the Noto Emoji font in the font selector, Idle immediately crashes with a very similar Xlib error

X Error of failed request:  BadLength (poly request too large or internal Xlib length error)
  Major opcode of failed request:  139 (RENDER)
  Minor opcode of failed request:  20 (RenderAddGlyphs)
  Serial number of failed request:  12760
  Current serial number in output stream:  12769

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43647>
_______________________________________

From report at bugs.python.org  Sun Mar 28 16:47:47 2021
From: report at bugs.python.org (miss-islington)
Date: Sun, 28 Mar 2021 20:47:47 +0000
Subject: [issue31907] doc: Clarify error message when attempting to call
 function via str.format()
In-Reply-To: <1509410120.18.0.213398074469.issue31907@psf.upfronthosting.co.za>
Message-ID: <1616964467.99.0.0669823994275.issue31907@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: +23802
pull_request: https://github.com/python/cpython/pull/25055

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31907>
_______________________________________

From report at bugs.python.org  Sun Mar 28 16:47:39 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 28 Mar 2021 20:47:39 +0000
Subject: [issue31907] doc: Clarify error message when attempting to call
 function via str.format()
In-Reply-To: <1509410120.18.0.213398074469.issue31907@psf.upfronthosting.co.za>
Message-ID: <1616964459.69.0.737732364661.issue31907@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:


New changeset fb1d01b9630b5069fe975f16e07a027d90b89434 by Irit Katriel in branch 'master':
bpo-31907: [doc] clarify that str.format() does not support arbitrary expressions (#25053)
https://github.com/python/cpython/commit/fb1d01b9630b5069fe975f16e07a027d90b89434


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31907>
_______________________________________

From report at bugs.python.org  Sun Mar 28 16:47:54 2021
From: report at bugs.python.org (miss-islington)
Date: Sun, 28 Mar 2021 20:47:54 +0000
Subject: [issue31907] doc: Clarify error message when attempting to call
 function via str.format()
In-Reply-To: <1509410120.18.0.213398074469.issue31907@psf.upfronthosting.co.za>
Message-ID: <1616964474.33.0.147833021005.issue31907@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +23803
pull_request: https://github.com/python/cpython/pull/25056

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31907>
_______________________________________

From report at bugs.python.org  Sun Mar 28 16:52:36 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 28 Mar 2021 20:52:36 +0000
Subject: [issue43433] xmlrpc.client ignores query in URI ("?action=xmlrpc2")
 since python-3.9
In-Reply-To: <1615206556.6.0.195752820504.issue43433@roundup.psfhosted.org>
Message-ID: <1616964756.55.0.693591702912.issue43433@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +23804
pull_request: https://github.com/python/cpython/pull/25057

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43433>
_______________________________________

From report at bugs.python.org  Sun Mar 28 16:57:21 2021
From: report at bugs.python.org (miss-islington)
Date: Sun, 28 Mar 2021 20:57:21 +0000
Subject: [issue31907] doc: Clarify error message when attempting to call
 function via str.format()
In-Reply-To: <1509410120.18.0.213398074469.issue31907@psf.upfronthosting.co.za>
Message-ID: <1616965041.75.0.114776613494.issue31907@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 24ba0ea9e0160cc85e0fa24f32b1651c8b3a24b0 by Miss Islington (bot) in branch '3.8':
[3.8] bpo-31907: [doc] clarify that str.format() does not support arbitrary expressions (GH-25053) (GH-25056)
https://github.com/python/cpython/commit/24ba0ea9e0160cc85e0fa24f32b1651c8b3a24b0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31907>
_______________________________________

From report at bugs.python.org  Sun Mar 28 16:58:54 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 28 Mar 2021 20:58:54 +0000
Subject: [issue31907] doc: Clarify error message when attempting to call
 function via str.format()
In-Reply-To: <1509410120.18.0.213398074469.issue31907@psf.upfronthosting.co.za>
Message-ID: <1616965134.09.0.609027625582.issue31907@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31907>
_______________________________________

From report at bugs.python.org  Sun Mar 28 17:05:16 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 28 Mar 2021 21:05:16 +0000
Subject: [issue31907] doc: Clarify error message when attempting to call
 function via str.format()
In-Reply-To: <1509410120.18.0.213398074469.issue31907@psf.upfronthosting.co.za>
Message-ID: <1616965516.38.0.841600849864.issue31907@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:


New changeset 9a8e0780247acb256dd8b04c15b3dd0f59ef2fe1 by Miss Islington (bot) in branch '3.9':
bpo-31907: [doc] clarify that str.format() does not support arbitrary expressions (GH-25053) (GH-25055)
https://github.com/python/cpython/commit/9a8e0780247acb256dd8b04c15b3dd0f59ef2fe1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31907>
_______________________________________

From report at bugs.python.org  Sun Mar 28 17:07:22 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Sun, 28 Mar 2021 21:07:22 +0000
Subject: [issue43094] sqlite3 signature discrepancies between documentation
 and implementation
In-Reply-To: <1612210210.19.0.0751315887137.issue43094@roundup.psfhosted.org>
Message-ID: <1616965642.37.0.141005900774.issue43094@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

> Of course! I may be not be able to respond to you quickly in the next few weeks, though.

Thank you! I'll send you a preliminary version sometime this week.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43094>
_______________________________________

From report at bugs.python.org  Sun Mar 28 17:21:23 2021
From: report at bugs.python.org (igor voltaic)
Date: Sun, 28 Mar 2021 21:21:23 +0000
Subject: [issue43650] MemoryError on zip.read in shutil._unpack_zipfile
Message-ID: <1616966483.79.0.479664444023.issue43650@roundup.psfhosted.org>


New submission from igor voltaic <ibolsch at gmail.com>:

MemoryError: null
  ...
  File "....", line 13, in repack__file
    shutil.unpack_archive(local_file_path, local_dir)
  File "python3.6/shutil.py", line 983, in unpack_archive
    func(filename, extract_dir, **kwargs)
  File "python3.6/shutil.py", line 901, in _unpack_zipfile
    data = zip.read(info.filename)
  File "python3.6/zipfile.py", line 1338, in read
    return fp.read()
  File "python3.6/zipfile.py", line 858, in read
    buf += self._read1(self.MAX_N)
  File "python3.6/zipfile.py", line 948, in _read1
    data = self._decompressor.decompress(data, n)

shutil.unpack_archive tries to read the whole file into memory, making use of any buffer at all. Python crashes for really large files. In my case ? archive: ~1.7G, unpacked: ~10G. Interestingly zipfile.ZipFile.extractall handles this case more effective.

----------
components: Library (Lib)
messages: 389652
nosy: igorvoltaic
priority: normal
severity: normal
status: open
title: MemoryError on zip.read in shutil._unpack_zipfile
type: crash
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43650>
_______________________________________

From report at bugs.python.org  Sun Mar 28 18:13:55 2021
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 28 Mar 2021 22:13:55 +0000
Subject: [issue43650] MemoryError on zip.read in shutil._unpack_zipfile
In-Reply-To: <1616966483.79.0.479664444023.issue43650@roundup.psfhosted.org>
Message-ID: <1616969635.38.0.495826586273.issue43650@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: +23805
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25058

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43650>
_______________________________________

From report at bugs.python.org  Sun Mar 28 18:47:18 2021
From: report at bugs.python.org (Irit Katriel)
Date: Sun, 28 Mar 2021 22:47:18 +0000
Subject: [issue26702] A better assert statement
In-Reply-To: <1459953817.06.0.108745447257.issue26702@psf.upfronthosting.co.za>
Message-ID: <1616971638.49.0.47507085483.issue26702@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

Maybe we could use the walrus operator for this: make assert display the reprs of all named sub-expressions.

----------
nosy: +iritkatriel
type:  -> enhancement
versions: +Python 3.10 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26702>
_______________________________________

From report at bugs.python.org  Sun Mar 28 18:48:13 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 28 Mar 2021 22:48:13 +0000
Subject: [issue25643] Python tokenizer rewriting
In-Reply-To: <1447723653.14.0.424824913135.issue25643@psf.upfronthosting.co.za>
Message-ID: <1616971693.47.0.41266488636.issue25643@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 261a452a1300eeeae1428ffd6e6623329c085e2c by Pablo Galindo in branch 'master':
bpo-25643: Refactor the C tokenizer into smaller, logical units (GH-25050)
https://github.com/python/cpython/commit/261a452a1300eeeae1428ffd6e6623329c085e2c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25643>
_______________________________________

From report at bugs.python.org  Sun Mar 28 18:49:06 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 28 Mar 2021 22:49:06 +0000
Subject: [issue25643] Python tokenizer rewriting
In-Reply-To: <1447723653.14.0.424824913135.issue25643@psf.upfronthosting.co.za>
Message-ID: <1616971746.59.0.515649431883.issue25643@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/issue25643>
_______________________________________

From report at bugs.python.org  Sun Mar 28 18:54:36 2021
From: report at bugs.python.org (Irit Katriel)
Date: Sun, 28 Mar 2021 22:54:36 +0000
Subject: [issue21254] doc: PropertyMock refuses to raise AttributeErrror as a
 side effect
In-Reply-To: <1397664917.5.0.84660783066.issue21254@psf.upfronthosting.co.za>
Message-ID: <1616972076.9.0.207491020741.issue21254@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
components: +Documentation, Library (Lib)
stage: test needed -> needs patch
title: PropertyMock refuses to raise AttributeErrror as a side effect -> doc: PropertyMock refuses to raise AttributeErrror as a side effect
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21254>
_______________________________________

From report at bugs.python.org  Sun Mar 28 18:56:29 2021
From: report at bugs.python.org (Zackery Spytz)
Date: Sun, 28 Mar 2021 22:56:29 +0000
Subject: [issue31956] Add start and stop parameters to the array.index()
In-Reply-To: <1509966827.68.0.213398074469.issue31956@psf.upfronthosting.co.za>
Message-ID: <1616972189.96.0.355135564745.issue31956@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
nosy: +ZackerySpytz
nosy_count: 8.0 -> 9.0
pull_requests: +23807
pull_request: https://github.com/python/cpython/pull/25059

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31956>
_______________________________________

From report at bugs.python.org  Sun Mar 28 23:22:25 2021
From: report at bugs.python.org (Ammar Askar)
Date: Mon, 29 Mar 2021 03:22:25 +0000
Subject: [issue26702] A better assert statement
In-Reply-To: <1459953817.06.0.108745447257.issue26702@psf.upfronthosting.co.za>
Message-ID: <1616988145.97.0.220351542156.issue26702@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Just a note and possible design inspiration, pytest has pretty assertions like this to allowing you to write unit tests purely with the assert statement and not unittest's special `assert...` methods: https://docs.pytest.org/en/stable/example/reportingdemo.html#tbreportdemo

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26702>
_______________________________________

From report at bugs.python.org  Sun Mar 28 23:25:49 2021
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 29 Mar 2021 03:25:49 +0000
Subject: [issue33164] Blake 2 module update
In-Reply-To: <1558585970.68.0.308420136648.issue33164@roundup.psfhosted.org>
Message-ID: <1616988349.44.0.575509100051.issue33164@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +23808
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/25060

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33164>
_______________________________________

From report at bugs.python.org  Sun Mar 28 23:28:22 2021
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 29 Mar 2021 03:28:22 +0000
Subject: [issue43510] PEP 597: Implemente encoding="locale" option and
 EncodingWarning
In-Reply-To: <1615868389.17.0.260147645451.issue43510@roundup.psfhosted.org>
Message-ID: <1616988502.48.0.694491939782.issue43510@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset 4827483f47906fecee6b5d9097df2a69a293a85c by Inada Naoki in branch 'master':
bpo-43510: Implement PEP 597 opt-in EncodingWarning. (GH-19481)
https://github.com/python/cpython/commit/4827483f47906fecee6b5d9097df2a69a293a85c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43510>
_______________________________________

From report at bugs.python.org  Mon Mar 29 00:30:27 2021
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 29 Mar 2021 04:30:27 +0000
Subject: [issue43651] PEP 597: Fix EncodingError
Message-ID: <1616992227.89.0.174128182891.issue43651@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
nosy: methane
priority: normal
severity: normal
status: open
title: PEP 597: Fix EncodingError
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43651>
_______________________________________

From report at bugs.python.org  Mon Mar 29 00:36:38 2021
From: report at bugs.python.org (David Bolen)
Date: Mon, 29 Mar 2021 04:36:38 +0000
Subject: [issue37945] [Windows]
 test_locale.TestMiscellaneous.test_getsetlocale_issue1813() fails
In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org>
Message-ID: <1616992598.27.0.0329160454895.issue37945@roundup.psfhosted.org>


David Bolen <db3l.net at gmail.com> added the comment:

The test has also begun failing on the Win10 buildbot (after updating to 20H2 from an older 1803).

----------
nosy: +db3l

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37945>
_______________________________________

From report at bugs.python.org  Mon Mar 29 00:40:06 2021
From: report at bugs.python.org (Jeremy Kloth)
Date: Mon, 29 Mar 2021 04:40:06 +0000
Subject: [issue37945] [Windows]
 test_locale.TestMiscellaneous.test_getsetlocale_issue1813() fails
In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org>
Message-ID: <1616992806.92.0.777575037753.issue37945@roundup.psfhosted.org>


Change by Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com>:


----------
nosy: +jkloth

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37945>
_______________________________________

From report at bugs.python.org  Mon Mar 29 01:13:21 2021
From: report at bugs.python.org (Kevin Geller)
Date: Mon, 29 Mar 2021 05:13:21 +0000
Subject: [issue32545] Unable to install Python 3.7.0a4 on Windows 10 - Error
 0x80070643: Failed to install MSI package.
In-Reply-To: <1515875653.34.0.467229070634.issue32545@psf.upfronthosting.co.za>
Message-ID: <1616994801.07.0.538902137522.issue32545@roundup.psfhosted.org>


Kevin Geller <kevingeller416 at gmail.com> added the comment:

I was also facing the similar issue. But I got it fixed by following the steps provided on https://enhau.com/

----------
nosy: +kevingeller

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32545>
_______________________________________

From report at bugs.python.org  Mon Mar 29 01:46:57 2021
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 29 Mar 2021 05:46:57 +0000
Subject: [issue37945] [Windows]
 test_locale.TestMiscellaneous.test_getsetlocale_issue1813() fails
In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org>
Message-ID: <1616996817.12.0.288134252603.issue37945@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
keywords: +patch
nosy: +methane
nosy_count: 13.0 -> 14.0
pull_requests: +23809
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/19481

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37945>
_______________________________________

From report at bugs.python.org  Mon Mar 29 02:21:17 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 29 Mar 2021 06:21:17 +0000
Subject: [issue43647] Sudden crash displaying certain characters in tk widget
In-Reply-To: <1616945200.88.0.69202252104.issue43647@roundup.psfhosted.org>
Message-ID: <1616998877.71.0.720066778775.issue43647@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This is actually a tk and tkinter issue rather than IDLE issue as such.  Python code can only catch Python exceptions, and I believe that the Xserver crash does not result in one.  These crashes were reported on a different issue and the conclusion there is that there is nothing we know to do.

IDLE uses the default tkFixedFont unless the user selects another one.  If tk selects a font that crashes, that is not IDLE's fault, or even tkinter's.  If there were a font that was always available on every *nix system and that never crashed for any unicode char, then IDLE could select that on *nix systems.  But I have no idea of such.  (Courier serves that purpose on Windows, and it is the tkFixedFont font on Windows.)

In the meanwhile, users can select a different font upon startup, which only uses ascii chars (if one starts with Shell and no editor).  Select Options => Configure IDLE.  Possible use the font sample box to try out the problematic chars but pasting or otherwise inserting.  If IDLE crashes, try again.  The resolution of this issue might be to say something more in the doc about this problem, as people seem to be using non-ascii more often, or maybe more ofter loading fonts that do not work.

Serhiy, can you say any more?  You know much more about tk/tkinter default font choices and Xserver font crashes than I do.

----------
components: +Tkinter -IDLE
nosy: +serhiy.storchaka
title: Sudden crash on print() of some characters -> Sudden crash displaying certain characters in tk widget
type:  -> crash
versions: +Python 3.10 -Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43647>
_______________________________________

From report at bugs.python.org  Mon Mar 29 02:32:13 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 29 Mar 2021 06:32:13 +0000
Subject: [issue43647] Sudden crash displaying certain characters in tk widget
In-Reply-To: <1616945200.88.0.69202252104.issue43647@roundup.psfhosted.org>
Message-ID: <1616999533.63.0.0133560392947.issue43647@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Looks like a duplicate of issue42225. It happens with colored fonts. In any case it is a Tk issue and it should be fixed in the latest Tk bugfix release (8.6.11).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43647>
_______________________________________

From report at bugs.python.org  Mon Mar 29 02:33:38 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 29 Mar 2021 06:33:38 +0000
Subject: [issue37945] [Windows]
 test_locale.TestMiscellaneous.test_getsetlocale_issue1813() fails
In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org>
Message-ID: <1616999618.37.0.0395100999487.issue37945@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

So, can we delete it?

PR 19781 is for #43510 and is listed here above only because this issue is mentioned.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37945>
_______________________________________

From report at bugs.python.org  Mon Mar 29 03:07:11 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 29 Mar 2021 07:07:11 +0000
Subject: [issue43652] Upgrade Windows tcl/tk to 8.6.11
Message-ID: <1617001631.71.0.115330422511.issue43652@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

#39017, PR 22405 was too late for 3.9, but the new Mac installer is already using 8.6.11.  Serhiy, do you know any reason not to upgrade the Windows installer to 8.6.11 also?

Steve, should a new PR with '10' replaced with '11, where '9' was replaced with '10' before, be sufficient?  I presumt the 'v14' for VC13 should be left alone.  To test, would 8.6.11 be built on my system, or is it fetched externally?

----------
components: Tkinter, Windows
messages: 389662
nosy: paul.moore, serhiy.storchaka, steve.dower, terry.reedy, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Upgrade Windows tcl/tk to 8.6.11
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43652>
_______________________________________

From report at bugs.python.org  Mon Mar 29 03:07:51 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 29 Mar 2021 07:07:51 +0000
Subject: [issue39107] Upgrade Windows tcl/tk to 8.6.10
In-Reply-To: <1576838540.23.0.689551930127.issue39107@roundup.psfhosted.org>
Message-ID: <1617001671.93.0.53440700377.issue39107@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

#43652 is for 8.6.11.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39107>
_______________________________________

From report at bugs.python.org  Mon Mar 29 03:11:06 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 29 Mar 2021 07:11:06 +0000
Subject: [issue43647] Sudden crash displaying certain characters in tk widget
In-Reply-To: <1616945200.88.0.69202252104.issue43647@roundup.psfhosted.org>
Message-ID: <1617001866.4.0.648334849515.issue43647@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Closing as a duplicate.  What's new here is that BMP chars can be affected also.

I opened #43652 to upgrade Windows installer to 8.6.11 (though not needed for this) but I guess Linux users have to bug their distributor or learn to upgrade themselves.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Tkinter hangs or crashes when displaying astral chars

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43647>
_______________________________________

From report at bugs.python.org  Mon Mar 29 03:16:02 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 29 Mar 2021 07:16:02 +0000
Subject: [issue42225] Tkinter hangs or crashes when displaying astral chars
In-Reply-To: <1604200632.47.0.347759375724.issue42225@roundup.psfhosted.org>
Message-ID: <1617002162.25.0.151941445337.issue42225@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I closed #43647 as a duplicate of this.  It reported that BMP chars can fail also.  For instance, with "Noto Sans Mono", but not 'Dejavu Mono', the following crash.
>>> '\u2705'
'?'
>>> '\u270f'
'?'

Unfortunately, as least on some *nix, the default tkFixedFont resolves to Noto Sans Mono.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42225>
_______________________________________

From report at bugs.python.org  Mon Mar 29 03:35:39 2021
From: report at bugs.python.org (Mikhail)
Date: Mon, 29 Mar 2021 07:35:39 +0000
Subject: [issue43647] Sudden crash displaying certain characters in tk widget
In-Reply-To: <1616945200.88.0.69202252104.issue43647@roundup.psfhosted.org>
Message-ID: <1617003339.87.0.45944789908.issue43647@roundup.psfhosted.org>


Mikhail <tetelev99 at mail.ru> added the comment:

Yes, this is exactly the same problem as `issue42225`. I suspected it was a Tkinter problem, and also thought that Python might be under the hood catching C method call errors. 

But since you know about this problem, and in more detail than I have written here, this issue can be closed.

P.S. By the way, while I was doing my little investigation with fonts, here's another little bug I found :) 
When I start to write any word in IDLE and press Tab, the autocomplete box is shown (or auto-complete if the only mapping). But if I was doing something in "Configure IDLE" and pressed "Ok" to close the configure window, then pressing Tab just causes tab to appear at the cursor instead of auto-complete.

You probably know about it, but You know, I'm something of a developer myself, so it's better to report a bug than not report it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43647>
_______________________________________

From report at bugs.python.org  Mon Mar 29 03:48:06 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 29 Mar 2021 07:48:06 +0000
Subject: [issue42225] Tkinter hangs or crashes when displaying astral chars
In-Reply-To: <1604200632.47.0.347759375724.issue42225@roundup.psfhosted.org>
Message-ID: <1617004086.13.0.129095400192.issue42225@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

At least it is not a regression caused by support of astral characters (issue13153).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42225>
_______________________________________

From report at bugs.python.org  Mon Mar 29 03:55:02 2021
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 29 Mar 2021 07:55:02 +0000
Subject: [issue43638] MacOS os.statvfs() has rollover for >4TB disks at each
 4TB (32bit counter overflow?)
In-Reply-To: <1616841402.66.0.531178179964.issue43638@roundup.psfhosted.org>
Message-ID: <1617004502.28.0.809326476426.issue43638@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

As you note in the title this is a 32-bit overflow in the statvfs system API, the struct it uses contains 32-bit values.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43638>
_______________________________________

From report at bugs.python.org  Mon Mar 29 03:57:52 2021
From: report at bugs.python.org (Matteo Bertucci)
Date: Mon, 29 Mar 2021 07:57:52 +0000
Subject: [issue43653] Typo in the random.shuffle docs
Message-ID: <1617004672.48.0.32476010858.issue43653@roundup.psfhosted.org>


New submission from Matteo Bertucci <matteobertucci2004 at gmail.com>:

Hello!

The current documentation for random.shuffle reads:
> The optional argument random is a 0-argument function returning a random float in [0.0, 1.0); by default, this is the function random().

I believe the range here should use matching symbols, unless I am missing something.

----------
assignee: docs at python
components: Documentation
messages: 389669
nosy: Akarys, docs at python
priority: normal
severity: normal
status: open
title: Typo in the random.shuffle docs
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43653>
_______________________________________

From report at bugs.python.org  Mon Mar 29 04:01:30 2021
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 29 Mar 2021 08:01:30 +0000
Subject: [issue43653] Typo in the random.shuffle docs
In-Reply-To: <1617004672.48.0.32476010858.issue43653@roundup.psfhosted.org>
Message-ID: <1617004890.85.0.462924483187.issue43653@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

https://en.wikipedia.org/wiki/Interval_(mathematics)

See "Notations for intervals" section in the Wikipedia page.

----------
nosy: +methane

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43653>
_______________________________________

From report at bugs.python.org  Mon Mar 29 04:02:29 2021
From: report at bugs.python.org (Zhipeng Xie)
Date: Mon, 29 Mar 2021 08:02:29 +0000
Subject: [issue37788] fix for bpo-36402 (threading._shutdown() race condition)
 causes reference leak
In-Reply-To: <1565194972.64.0.065323919799.issue37788@roundup.psfhosted.org>
Message-ID: <1617004949.67.0.474680601397.issue37788@roundup.psfhosted.org>


Zhipeng Xie <775350901 at qq.com> added the comment:

ping

I also encountered this problem. Is there a fix now?

----------
nosy: +Zhipeng Xie

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37788>
_______________________________________

From report at bugs.python.org  Mon Mar 29 04:03:44 2021
From: report at bugs.python.org (Matteo Bertucci)
Date: Mon, 29 Mar 2021 08:03:44 +0000
Subject: [issue43653] Typo in the random.shuffle docs
In-Reply-To: <1617004672.48.0.32476010858.issue43653@roundup.psfhosted.org>
Message-ID: <1617005024.21.0.0269550103572.issue43653@roundup.psfhosted.org>


Matteo Bertucci <matteobertucci2004 at gmail.com> added the comment:

Oh I see, I was used to seeing open intervals using ]a, b[. All good then!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43653>
_______________________________________

From report at bugs.python.org  Mon Mar 29 04:03:57 2021
From: report at bugs.python.org (Matteo Bertucci)
Date: Mon, 29 Mar 2021 08:03:57 +0000
Subject: [issue43653] Typo in the random.shuffle docs
In-Reply-To: <1617004672.48.0.32476010858.issue43653@roundup.psfhosted.org>
Message-ID: <1617005037.38.0.302748578366.issue43653@roundup.psfhosted.org>


Change by Matteo Bertucci <matteobertucci2004 at gmail.com>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43653>
_______________________________________

From report at bugs.python.org  Mon Mar 29 04:40:35 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 29 Mar 2021 08:40:35 +0000
Subject: [issue43654] IDLE: Applying settings disables tab completion
Message-ID: <1617007235.89.0.0831829954955.issue43654@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

(Original report by Mikhail on #43647, running 3.9 on Linux; verified and extended by me running 3.10 on Windows.)

Normally, "i<tab>" brings up a completion window with 'id', 'if', 'import', etc.  Opening a Settings windows with Options => Configure IDLE and closing with Apply and Cancel or OK (which also applies) disables tab completion.  Other completions (forced with ^<space> or auto with '.' or '/' and waits seem not affected.  The only way to restore is to close and reopen each window.

Tab completions are enabled in editor.py with these two lines.
        text.event_add('<<autocomplete>>', '<Key-Tab>')
        text.bind("<<autocomplete>>", autocomplete.autocomplete_event) 
Attribute and path completions, not affected, are enabled with these.
        text.event_add('<<try-open-completions>>', '<KeyRelease-period>',
                       '<KeyRelease-slash>', '<KeyRelease-backslash>
        text.bind("<<try-open-completions>>",
                  autocomplete.try_open_completions_event)
Similarly for some other things.

In configdialog, the relevant method is (179) def apply, who relevant calls are (219) deactivate_current_config and (230) activate_current_config.  The former removes key bindings and the latter rebinds and makes other changes.

What is different about Tab versus '.' is that is tab also used for indents and the indent space is reset by 'activate...'.  I will later add some debug prints to console based on the clues above.

----------
assignee: terry.reedy
components: IDLE
messages: 389673
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: IDLE: Applying settings disables tab completion
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43654>
_______________________________________

From report at bugs.python.org  Mon Mar 29 04:41:43 2021
From: report at bugs.python.org (Sander)
Date: Mon, 29 Mar 2021 08:41:43 +0000
Subject: [issue43638] MacOS os.statvfs() has rollover for >4TB disks at each
 4TB (32bit counter overflow?)
In-Reply-To: <1616841402.66.0.531178179964.issue43638@roundup.psfhosted.org>
Message-ID: <1617007303.61.0.654893433089.issue43638@roundup.psfhosted.org>


Sander <sander.jonkers+github at gmail.com> added the comment:

OK. What would be a solution from/for Python to get the correct available space on a MacOS system?

In SABnzbd we implemented a workaround with a direct call to MacOS C lib's statfs(). See https://github.com/sabnzbd/sabnzbd/blob/develop/sabnzbd/filesystem.py#L948-L989

IMHO not a great solution for a python programmer. Could python's os.statvfs() use the correct (64bit) info from statfs()?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43638>
_______________________________________

From report at bugs.python.org  Mon Mar 29 04:43:17 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 29 Mar 2021 08:43:17 +0000
Subject: [issue43647] Sudden crash displaying certain characters in tk widget
In-Reply-To: <1616945200.88.0.69202252104.issue43647@roundup.psfhosted.org>
Message-ID: <1617007397.83.0.489995546912.issue43647@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Thank you for reporting. While I may have had tab not work after the dialog, I had never connected the two.  Nor, AFAIK, was there an existing report. I verified, investigated more, and opened #43654.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43647>
_______________________________________

From report at bugs.python.org  Mon Mar 29 04:53:43 2021
From: report at bugs.python.org (Patrick Melix)
Date: Mon, 29 Mar 2021 08:53:43 +0000
Subject: [issue43655] Tkinter: Not setting _NET_WM_WINDOW_TYPE on FileDialog
Message-ID: <1617008023.65.0.620967294098.issue43655@roundup.psfhosted.org>


New submission from Patrick Melix <github at melix.me>:

While trying to fix window behaviour in a python project (ASE: https://wiki.fysik.dtu.dk/ase/), I came across this problem:

Tkinter does not set the _NET_WM_WINDOW_TYPE when using the FileDialog class or it's derivatives. I could not find a reason for this and it leads to my window manager (i3) not automatically recognising the window as a dialogue (and thus not enabling floating). I think the window types are there exactly for that purpose, so I don't see why not to set this as the default for the FileDialog class.

I was able to change this by adding the line
```self.top.wm_attributes('-type', 'dialog')```
to the initialization of the FileDialog class. See also MR on GitHub.

Since I am an absolute beginner at this please do forgive if I missed something.

----------
components: Tkinter
messages: 389676
nosy: patrickmelix
priority: normal
severity: normal
status: open
title: Tkinter: Not setting _NET_WM_WINDOW_TYPE on FileDialog
type: enhancement
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43655>
_______________________________________

From report at bugs.python.org  Mon Mar 29 04:55:09 2021
From: report at bugs.python.org (Patrick Melix)
Date: Mon, 29 Mar 2021 08:55:09 +0000
Subject: [issue43655] Tkinter: Not setting _NET_WM_WINDOW_TYPE on FileDialog
In-Reply-To: <1617008023.65.0.620967294098.issue43655@roundup.psfhosted.org>
Message-ID: <1617008109.77.0.0401123583115.issue43655@roundup.psfhosted.org>


Change by Patrick Melix <github at melix.me>:


----------
keywords: +patch
pull_requests: +23810
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25061

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43655>
_______________________________________

From report at bugs.python.org  Mon Mar 29 05:00:02 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 29 Mar 2021 09:00:02 +0000
Subject: [issue42225] Tkinter hangs or crashes when displaying astral chars
In-Reply-To: <1604200632.47.0.347759375724.issue42225@roundup.psfhosted.org>
Message-ID: <1617008402.03.0.546148954147.issue42225@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

No, seems strictly a matter of complicated color, which is perhaps becoming more common.  Firefox colors the checkbox (white checkmark on green field in a largish black square) but not the (smaller) pencil.  I did not recognize either the FF or tk Windows pencil as a pencil without any color (so I searched), so I won't be surprised if FF upgrades its pencil too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42225>
_______________________________________

From report at bugs.python.org  Mon Mar 29 05:04:45 2021
From: report at bugs.python.org (Mikhail)
Date: Mon, 29 Mar 2021 09:04:45 +0000
Subject: [issue43654] IDLE: Applying settings disables tab completion
In-Reply-To: <1617007235.89.0.0831829954955.issue43654@roundup.psfhosted.org>
Message-ID: <1617008685.9.0.251164988314.issue43654@roundup.psfhosted.org>


Change by Mikhail <tetelev99 at mail.ru>:


----------
nosy: +tetelevm

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43654>
_______________________________________

From report at bugs.python.org  Mon Mar 29 05:33:16 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 29 Mar 2021 09:33:16 +0000
Subject: [issue43433] xmlrpc.client ignores query in URI ("?action=xmlrpc2")
 since python-3.9
In-Reply-To: <1615206556.6.0.195752820504.issue43433@roundup.psfhosted.org>
Message-ID: <1617010396.88.0.601888467946.issue43433@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you for your reports OndrejPtak and frathgeber.

Indeed, the behavior change was unintended. PR 25057 tries to to restore the old behavior. Query and fragment are now preserved in the server URL.

But there are still minor differences. Empty query and fragment are stripped from the URL, so "http://example.org/RPC2?", "http://example.org/RPC2#" and "http://example.org/RPC2" refer to the same connection point. I am not sure that it is important. It would be not easy to preserve the old behavior in these corner cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43433>
_______________________________________

From report at bugs.python.org  Mon Mar 29 05:36:49 2021
From: report at bugs.python.org (Martin)
Date: Mon, 29 Mar 2021 09:36:49 +0000
Subject: [issue43656] StackSummary.format fails if str(value) fails
Message-ID: <1617010609.77.0.749976985588.issue43656@roundup.psfhosted.org>


New submission from Martin <martin.schroeder at nerdluecht.de>:

With `capture_locals=True`, `StackSummary.format` prints the local variables for every frame:
https://github.com/python/cpython/blob/4827483f47906fecee6b5d9097df2a69a293a85c/Lib/traceback.py#L440

This will fail, however, if string conversion fails.

StackSummary.format should be robust towards such possibilities.


An easy fix would be a utility function:

```
def try_str(x):
  try:
    return str(x)
  except:
    return "<some sensible hint>"
```

----------
messages: 389679
nosy: moi90
priority: normal
severity: normal
status: open
title: StackSummary.format fails if str(value) fails
type: enhancement
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43656>
_______________________________________

From report at bugs.python.org  Mon Mar 29 05:46:03 2021
From: report at bugs.python.org (Martin)
Date: Mon, 29 Mar 2021 09:46:03 +0000
Subject: [issue43656] StackSummary.format fails if str(value) fails
In-Reply-To: <1617010609.77.0.749976985588.issue43656@roundup.psfhosted.org>
Message-ID: <1617011163.36.0.207518173402.issue43656@roundup.psfhosted.org>


Martin <martin.schroeder at nerdluecht.de> added the comment:

I have to correct myself: The conversion to string already happens during construction, in `FrameSummary.__init__`:

https://github.com/python/cpython/blob/4827483f47906fecee6b5d9097df2a69a293a85c/Lib/traceback.py#L273

The issue remains as severe and the fix remains as easy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43656>
_______________________________________

From report at bugs.python.org  Mon Mar 29 05:48:53 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 29 Mar 2021 09:48:53 +0000
Subject: [issue43655] Tkinter: Not setting _NET_WM_WINDOW_TYPE on FileDialog
In-Reply-To: <1617008023.65.0.620967294098.issue43655@roundup.psfhosted.org>
Message-ID: <1617011333.2.0.838324458881.issue43655@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you for your report and PR Patrick.

I agree, it would be better to to set the "type" attribute to "dialog" for the FileDialog window. Tk does it for its dialog windows. But it is more complex.

* It should be set not only for FileDialog, but for other dialog windows implemented in Python too (including dialog windows specific for IDLE). I am in process of working on making dialog windows implemented in Python looking and behaving closer to dialog windows implemented in Tk. The hardest part is writing tests for this.

* This code should be executed only on X Window. On macOS and Windows different code is needed. From Tk sources of ::tk::dialog::file::Create and ::tk::dialog::color:: :

    if {[tk windowingsystem] eq "x11"} {wm attributes $w -type dialog}

And in ::tk_dialog and ::tk::MessageBox :

    if {$windowingsystem eq "aqua"} {
        ::tk::unsupported::MacWindowStyle style $w moveableModal {}
    } elseif {$windowingsystem eq "x11"} {
        wm attributes $w -type dialog
    }

And ::tk::dialog::error::bgerror uses moveableAlert instead of moveableModal.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43655>
_______________________________________

From report at bugs.python.org  Mon Mar 29 06:07:29 2021
From: report at bugs.python.org (Martin)
Date: Mon, 29 Mar 2021 10:07:29 +0000
Subject: [issue43656] StackSummary.format fails if str(value) fails
In-Reply-To: <1617010609.77.0.749976985588.issue43656@roundup.psfhosted.org>
Message-ID: <1617012449.83.0.785432176827.issue43656@roundup.psfhosted.org>


Change by Martin <martin.schroeder at nerdluecht.de>:


----------
keywords: +patch
pull_requests: +23812
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25062

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43656>
_______________________________________

From report at bugs.python.org  Mon Mar 29 06:28:07 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 29 Mar 2021 10:28:07 +0000
Subject: [issue40645] Use OpenSSL's HMAC API
In-Reply-To: <1589641291.33.0.635001105595.issue40645@roundup.psfhosted.org>
Message-ID: <1617013687.56.0.0307102899661.issue40645@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Seems that commit 933dfd7504e521a27fd8b94d02b79f9ed08f4631 introduced some reference leaks:


commit 933dfd7504e521a27fd8b94d02b79f9ed08f4631
Author: Christian Heimes <christian at python.org>
Date:   Sat Mar 27 14:55:03 2021 +0100

    bpo-40645: use C implementation of HMAC (GH-24920)



? ./python.exe -m test test_hashlib -R 3:3
0:00:00 load avg: 5.67 Run tests sequentially
0:00:00 load avg: 5.67 [1/1] test_hashlib
beginning 6 repetitions
123456
......
test_hashlib leaked [1, 1, 1] references, sum=3
test_hashlib failed

== Tests result: FAILURE ==

1 test failed:
    test_hashlib

Total duration: 8.7 sec
Tests result: FAILURE


    - [x] fix tests
    - [ ] add test scenarios for old/new code.

    Signed-off-by: Christian Heimes <christian at python.org>

 Lib/hashlib.py                                     |   1 +
 Lib/hmac.py                                        |  86 +++++++-----
 Lib/test/test_hmac.py                              | 114 +++++++++-------
 .../2021-03-19-10-22-17.bpo-40645.5pXhb-.rst       |   2 +
 Modules/_hashopenssl.c                             | 150 +++++++++++++++++++--
 Modules/clinic/_hashopenssl.c.h                    |  38 +-----
 6 files changed, 267 insertions(+), 124 deletions(-)
 create mode 100644 Misc/NEWS.d/next/Library/2021-03-19-10-22-17.bpo-40645.5pXhb-.rst

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40645>
_______________________________________

From report at bugs.python.org  Mon Mar 29 06:33:45 2021
From: report at bugs.python.org (Patrick Melix)
Date: Mon, 29 Mar 2021 10:33:45 +0000
Subject: [issue43655] Tkinter: Not setting _NET_WM_WINDOW_TYPE on FileDialog
In-Reply-To: <1617008023.65.0.620967294098.issue43655@roundup.psfhosted.org>
Message-ID: <1617014025.39.0.582208654179.issue43655@roundup.psfhosted.org>


Patrick Melix <github at melix.me> added the comment:

Thank you for your feedback Serhiy!

I obviously totally forgot about compatibility issues with other OS... If you are already aware of this and working on a solution even better. Did I miss this during my search or is it not public anywhere yet?

For now one can easily avoid the issue by always setting the type manually, will have to see how to avoid the OS issue you mention then.

Perhaps you can point me to the place to watch for your progress on the matter so I can keep track of this?
Thanks again!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43655>
_______________________________________

From report at bugs.python.org  Mon Mar 29 06:36:49 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 29 Mar 2021 10:36:49 +0000
Subject: [issue40645] Use OpenSSL's HMAC API
In-Reply-To: <1589641291.33.0.635001105595.issue40645@roundup.psfhosted.org>
Message-ID: <1617014209.45.0.538116432921.issue40645@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

See for instance: https://buildbot.python.org/all/#/builders/75/builds/224

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40645>
_______________________________________

From report at bugs.python.org  Mon Mar 29 06:55:32 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 29 Mar 2021 10:55:32 +0000
Subject: [issue40645] Use OpenSSL's HMAC API
In-Reply-To: <1589641291.33.0.635001105595.issue40645@roundup.psfhosted.org>
Message-ID: <1617015332.13.0.0154945234834.issue40645@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +23813
pull_request: https://github.com/python/cpython/pull/25063

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40645>
_______________________________________

From report at bugs.python.org  Mon Mar 29 07:53:04 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Mar 2021 11:53:04 +0000
Subject: [issue43510] PEP 597: Implemente encoding="locale" option and
 EncodingWarning
In-Reply-To: <1615868389.17.0.260147645451.issue43510@roundup.psfhosted.org>
Message-ID: <1617018784.23.0.55346171613.issue43510@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Yeah! Congrats INADA-san for implementing your PEP!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43510>
_______________________________________

From report at bugs.python.org  Mon Mar 29 07:59:55 2021
From: report at bugs.python.org (ggardet)
Date: Mon, 29 Mar 2021 11:59:55 +0000
Subject: [issue43593] pymalloc is not aware of Memory Tagging Extension (MTE)
 and crashes
In-Reply-To: <1616419787.13.0.506382582675.issue43593@roundup.psfhosted.org>
Message-ID: <1617019195.86.0.656333760847.issue43593@roundup.psfhosted.org>


ggardet <guillaume.gardet at arm.com> added the comment:

With PYTHONMALLOC=malloc, gdb is not crashing anymore. Thanks for the workaround.

pymalloc is not aware of MTE, so a SegFault occurs on any access to the memory since the check fails.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43593>
_______________________________________

From report at bugs.python.org  Mon Mar 29 08:06:58 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Mar 2021 12:06:58 +0000
Subject: [issue43624] Add underscore as a decimal separator for string
 formatting
In-Reply-To: <1616692747.49.0.677529428018.issue43624@roundup.psfhosted.org>
Message-ID: <1617019618.07.0.292605169445.issue43624@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> On the other hand, I suppose it would be possible to have a feature flag that can be used to disable decimal underscores in 3.10 to prevent test failures. Just spitballing...

I wrote PEP 606 -- Python Compatibility Version https://www.python.org/dev/peps/pep-0606/ and it was rejected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43624>
_______________________________________

From report at bugs.python.org  Mon Mar 29 08:09:19 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Mar 2021 12:09:19 +0000
Subject: [issue43636] test_descr fails randomly when executed with -R :
In-Reply-To: <1616802835.56.0.699111570038.issue43636@roundup.psfhosted.org>
Message-ID: <1617019759.49.0.245844662257.issue43636@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Is _PyType_Lookup() still faster after the fix? The optimization is mentioned at:
https://docs.python.org/dev/whatsnew/3.10.html#optimizations

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43636>
_______________________________________

From report at bugs.python.org  Mon Mar 29 08:18:11 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Mar 2021 12:18:11 +0000
Subject: [issue37773] ValueError: I/O operation on closed file. in ZipFile
 destructor
In-Reply-To: <1565084150.95.0.74829896398.issue37773@roundup.psfhosted.org>
Message-ID: <1617020291.15.0.213328242733.issue37773@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Victor, were there any changes in the garbage collector or interpreter shutdown code in 3.8?

I took some notes there: https://pythondev.readthedocs.io/finalization.html

I proposed bpo-42671 "Make the Python finalization more deterministic" but it will break some use cases, so I'm not comfortable with this idea yet :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37773>
_______________________________________

From report at bugs.python.org  Mon Mar 29 08:19:54 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Mar 2021 12:19:54 +0000
Subject: [issue37773] ValueError: I/O operation on closed file. in ZipFile
 destructor
In-Reply-To: <1565084150.95.0.74829896398.issue37773@roundup.psfhosted.org>
Message-ID: <1617020394.32.0.257560013248.issue37773@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

IMO ZipFile destructor should emit a ResourceWarning if it's not closed explicitly.

Nothing in the Python specification gives you any warranty that destructors will be ever called... Depending on the Python implementation and depending on many things, you never know when a destructor is called.

Just call the close() method explicitly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37773>
_______________________________________

From report at bugs.python.org  Mon Mar 29 08:22:42 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Mar 2021 12:22:42 +0000
Subject: [issue37773] ValueError: I/O operation on closed file. in ZipFile
 destructor
In-Reply-To: <1565084150.95.0.74829896398.issue37773@roundup.psfhosted.org>
Message-ID: <1617020562.94.0.748322501751.issue37773@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

FYI TextIOWrapper has a similar issue: bpo-17852. There was an attempt to fix the issue in 2017, but it had to be reverted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37773>
_______________________________________

From report at bugs.python.org  Mon Mar 29 08:28:05 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Mar 2021 12:28:05 +0000
Subject: [issue25643] Python tokenizer rewriting
In-Reply-To: <1447723653.14.0.424824913135.issue25643@psf.upfronthosting.co.za>
Message-ID: <1617020885.75.0.298243467264.issue25643@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Oh, 6 years to fix this bug. Better late than never ;-) Thanks for reporting and for fixing it!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25643>
_______________________________________

From report at bugs.python.org  Mon Mar 29 08:28:37 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Mar 2021 12:28:37 +0000
Subject: [issue43593] pymalloc is not aware of Memory Tagging Extension (MTE)
 and crashes
In-Reply-To: <1616419787.13.0.506382582675.issue43593@roundup.psfhosted.org>
Message-ID: <1617020917.38.0.807571737534.issue43593@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Can you please test if https://github.com/python/cpython/pull/14474 fix your issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43593>
_______________________________________

From report at bugs.python.org  Mon Mar 29 08:29:05 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Mar 2021 12:29:05 +0000
Subject: [issue37448] obmalloc: radix tree for tracking arena address ranges
In-Reply-To: <1561849702.35.0.724599328196.issue37448@roundup.psfhosted.org>
Message-ID: <1617020945.69.0.640327571077.issue37448@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

See also bpo-43593 "pymalloc is not aware of Memory Tagging Extension (MTE) and crashes".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37448>
_______________________________________

From report at bugs.python.org  Mon Mar 29 08:32:06 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Mar 2021 12:32:06 +0000
Subject: [issue42938] [security][CVE-2021-3177] ctypes double representation
 BoF
In-Reply-To: <1610784207.02.0.722384660803.issue42938@roundup.psfhosted.org>
Message-ID: <1617021126.01.0.721459328914.issue42938@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
Removed message: https://bugs.python.org/msg389639

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42938>
_______________________________________

From report at bugs.python.org  Mon Mar 29 08:32:05 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Mar 2021 12:32:05 +0000
Subject: [issue42938] [security][CVE-2021-3177] ctypes double representation
 BoF
In-Reply-To: <1610784207.02.0.722384660803.issue42938@roundup.psfhosted.org>
Message-ID: <1617021125.85.0.778188330752.issue42938@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
Removed message: https://bugs.python.org/msg389638

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42938>
_______________________________________

From report at bugs.python.org  Mon Mar 29 08:33:11 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Mar 2021 12:33:11 +0000
Subject: [issue26227] Windows: socket.gethostbyaddr(name) fails for non-ASCII
 hostname
In-Reply-To: <1453942730.98.0.111965775649.issue26227@psf.upfronthosting.co.za>
Message-ID: <1617021191.4.0.77557512939.issue26227@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26227>
_______________________________________

From report at bugs.python.org  Mon Mar 29 08:34:42 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Mar 2021 12:34:42 +0000
Subject: [issue32146] multiprocessing freeze_support needed outside win32
In-Reply-To: <1511778835.66.0.213398074469.issue32146@psf.upfronthosting.co.za>
Message-ID: <1617021282.69.0.465761342141.issue32146@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32146>
_______________________________________

From report at bugs.python.org  Mon Mar 29 08:41:02 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 29 Mar 2021 12:41:02 +0000
Subject: [issue42988] [security] CVE-2021-3426: Information disclosure via
 pydoc -p: /getfile?key=path allows to read arbitrary file on the filesystem
In-Reply-To: <1611231517.86.0.296188996897.issue42988@roundup.psfhosted.org>
Message-ID: <1617021662.81.0.120896853629.issue42988@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: +23814
pull_request: https://github.com/python/cpython/pull/25064

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42988>
_______________________________________

From report at bugs.python.org  Mon Mar 29 08:41:10 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 29 Mar 2021 12:41:10 +0000
Subject: [issue42988] [security] CVE-2021-3426: Information disclosure via
 pydoc -p: /getfile?key=path allows to read arbitrary file on the filesystem
In-Reply-To: <1611231517.86.0.296188996897.issue42988@roundup.psfhosted.org>
Message-ID: <1617021670.67.0.934091916753.issue42988@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +23815
pull_request: https://github.com/python/cpython/pull/25065

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42988>
_______________________________________

From report at bugs.python.org  Mon Mar 29 08:41:00 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Mar 2021 12:41:00 +0000
Subject: [issue42988] [security] CVE-2021-3426: Information disclosure via
 pydoc -p: /getfile?key=path allows to read arbitrary file on the filesystem
In-Reply-To: <1611231517.86.0.296188996897.issue42988@roundup.psfhosted.org>
Message-ID: <1617021660.2.0.266704103893.issue42988@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 9b999479c0022edfc9835a8a1f06e046f3881048 by Victor Stinner in branch 'master':
bpo-42988: Remove the pydoc getfile feature (GH-25015)
https://github.com/python/cpython/commit/9b999479c0022edfc9835a8a1f06e046f3881048


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42988>
_______________________________________

From report at bugs.python.org  Mon Mar 29 08:41:17 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 29 Mar 2021 12:41:17 +0000
Subject: [issue42988] [security] CVE-2021-3426: Information disclosure via
 pydoc -p: /getfile?key=path allows to read arbitrary file on the filesystem
In-Reply-To: <1611231517.86.0.296188996897.issue42988@roundup.psfhosted.org>
Message-ID: <1617021677.89.0.916360753788.issue42988@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +23816
pull_request: https://github.com/python/cpython/pull/25066

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42988>
_______________________________________

From report at bugs.python.org  Mon Mar 29 08:41:28 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 29 Mar 2021 12:41:28 +0000
Subject: [issue42988] [security] CVE-2021-3426: Information disclosure via
 pydoc -p: /getfile?key=path allows to read arbitrary file on the filesystem
In-Reply-To: <1611231517.86.0.296188996897.issue42988@roundup.psfhosted.org>
Message-ID: <1617021688.98.0.277652308894.issue42988@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +23817
pull_request: https://github.com/python/cpython/pull/25067

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42988>
_______________________________________

From report at bugs.python.org  Mon Mar 29 08:50:07 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 29 Mar 2021 12:50:07 +0000
Subject: [issue37788] fix for bpo-36402 (threading._shutdown() race condition)
 causes reference leak
In-Reply-To: <1565194972.64.0.065323919799.issue37788@roundup.psfhosted.org>
Message-ID: <1617022207.82.0.746953664274.issue37788@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

No. The issue remains open.

----------
stage:  -> needs patch
versions:  -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37788>
_______________________________________

From report at bugs.python.org  Mon Mar 29 08:52:29 2021
From: report at bugs.python.org (Walter White)
Date: Mon, 29 Mar 2021 12:52:29 +0000
Subject: [issue43657] shutil.rmtree fails on readonly files in Windows,
 onerror not called
Message-ID: <1617022349.59.0.0395025567771.issue43657@roundup.psfhosted.org>


New submission from Walter White <homerun4711 at gmail.com>:

shutil.rmtree fails on readonly files in Windows.

Usually people are using the onerror callback to handle file permissions and retry, but that is not possible in this case because it is not triggerd.

onerror is only triggered if a OSError is found. 
In my case the unlink throws a PermissionError

Code shutil.rmdir():

try:
    os.unlink(fullname)
except OSError:
    onerror(os.unlink, fullname, sys.exc_info())


Traceback:


Traceback (most recent call last):

  File "c:\Users\user\test.py", line 121, in <module>
    shutil.rmtree(shutil.rmtree(working_dir),
  File "C:\python-3.9.1.amd64\lib\shutil.py", line 740, in rmtree
    return _rmtree_unsafe(path, onerror)
  File "C:\python-3.9.1.amd64\lib\shutil.py", line 613, in _rmtree_unsafe
    _rmtree_unsafe(fullname, onerror)
  File "C:\python-3.9.1.amd64\lib\shutil.py", line 613, in _rmtree_unsafe
    _rmtree_unsafe(fullname, onerror)
  File "C:\python-3.9.1.amd64\lib\shutil.py", line 618, in _rmtree_unsafe
    onerror(os.unlink, fullname, sys.exc_info())
  File "C:\python-3.9.1.amd64\lib\shutil.py", line 616, in _rmtree_unsafe
    os.unlink(fullname)
	
PermissionError: [WinError 5] Access denied: 'C:\\Users\\user\\somefile.txt'

os.stat:

st_mode=33060
st_ino=34621422136837665
st_dev=3929268297
st_nlink=1
st_uid=0
st_gid=0

----------
components: Library (Lib)
messages: 389697
nosy: homerun4711
priority: normal
severity: normal
status: open
title: shutil.rmtree fails on readonly files in Windows, onerror not called
type: crash
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43657>
_______________________________________

From report at bugs.python.org  Mon Mar 29 09:01:38 2021
From: report at bugs.python.org (Walter White)
Date: Mon, 29 Mar 2021 13:01:38 +0000
Subject: [issue43657] shutil.rmtree fails on readonly files in Windows,
 onerror not called
In-Reply-To: <1617022349.59.0.0395025567771.issue43657@roundup.psfhosted.org>
Message-ID: <1617022898.26.0.412209185103.issue43657@roundup.psfhosted.org>


Walter White <homerun4711 at gmail.com> added the comment:

Just saw:

    class PermissionError(OSError)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43657>
_______________________________________

From report at bugs.python.org  Mon Mar 29 09:01:44 2021
From: report at bugs.python.org (Walter White)
Date: Mon, 29 Mar 2021 13:01:44 +0000
Subject: [issue43657] shutil.rmtree fails on readonly files in Windows,
 onerror not called
In-Reply-To: <1617022349.59.0.0395025567771.issue43657@roundup.psfhosted.org>
Message-ID: <1617022904.84.0.842336536674.issue43657@roundup.psfhosted.org>


Change by Walter White <homerun4711 at gmail.com>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43657>
_______________________________________

From report at bugs.python.org  Mon Mar 29 09:02:56 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 29 Mar 2021 13:02:56 +0000
Subject: [issue42988] [security] CVE-2021-3426: Information disclosure via
 pydoc -p: /getfile?key=path allows to read arbitrary file on the filesystem
In-Reply-To: <1611231517.86.0.296188996897.issue42988@roundup.psfhosted.org>
Message-ID: <1617022976.45.0.982172022829.issue42988@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 7e38d3309e0a5a7b9e23ef933aef0079c6e317f7 by Miss Islington (bot) in branch '3.8':
bpo-42988: Remove the pydoc getfile feature (GH-25015)
https://github.com/python/cpython/commit/7e38d3309e0a5a7b9e23ef933aef0079c6e317f7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42988>
_______________________________________

From report at bugs.python.org  Mon Mar 29 09:08:09 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 29 Mar 2021 13:08:09 +0000
Subject: [issue42988] [security] CVE-2021-3426: Information disclosure via
 pydoc -p: /getfile?key=path allows to read arbitrary file on the filesystem
In-Reply-To: <1611231517.86.0.296188996897.issue42988@roundup.psfhosted.org>
Message-ID: <1617023289.3.0.726757653617.issue42988@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ed753d94856213ae9fc028195f670e66a24e2334 by Miss Islington (bot) in branch '3.9':
bpo-42988: Remove the pydoc getfile feature (GH-25015)
https://github.com/python/cpython/commit/ed753d94856213ae9fc028195f670e66a24e2334


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42988>
_______________________________________

From report at bugs.python.org  Mon Mar 29 09:17:44 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 29 Mar 2021 13:17:44 +0000
Subject: [issue40645] Use OpenSSL's HMAC API
In-Reply-To: <1589641291.33.0.635001105595.issue40645@roundup.psfhosted.org>
Message-ID: <1617023864.43.0.73685460798.issue40645@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 70cdf1812cf479c6b1cd7435a6fc0679ec1fb0da by Pablo Galindo in branch 'master':
bpo-40645: Fix reference leak in the _hashopenssl extension (GH-25063)
https://github.com/python/cpython/commit/70cdf1812cf479c6b1cd7435a6fc0679ec1fb0da


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40645>
_______________________________________

From report at bugs.python.org  Mon Mar 29 09:34:51 2021
From: report at bugs.python.org (Walter White)
Date: Mon, 29 Mar 2021 13:34:51 +0000
Subject: [issue43657] shutil.rmtree fails on readonly files in Windows,
 onerror not called
In-Reply-To: <1617022349.59.0.0395025567771.issue43657@roundup.psfhosted.org>
Message-ID: <1617024891.33.0.119047512479.issue43657@roundup.psfhosted.org>


Walter White <homerun4711 at gmail.com> added the comment:

I tried to add a try/except that handles a PermissionError to
my onerror function. But that did not work.

The doc on rmtree states 

Exceptions raised by onerror will not be caught.

Does this mean I can't use try/exept inside of onerror?

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43657>
_______________________________________

From report at bugs.python.org  Mon Mar 29 09:39:35 2021
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 29 Mar 2021 13:39:35 +0000
Subject: [issue43433] xmlrpc.client ignores query in URI ("?action=xmlrpc2")
 since python-3.9
In-Reply-To: <1615206556.6.0.195752820504.issue43433@roundup.psfhosted.org>
Message-ID: <1617025175.72.0.395376081435.issue43433@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:


New changeset c1b073a630bb731de18bb17afb2b8b1388b92a72 by Serhiy Storchaka in branch 'master':
bpo-43433: Preserve query and fragment in the URL of the server in ServerProxy. (GH-25057)
https://github.com/python/cpython/commit/c1b073a630bb731de18bb17afb2b8b1388b92a72


----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43433>
_______________________________________

From report at bugs.python.org  Mon Mar 29 09:39:51 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 29 Mar 2021 13:39:51 +0000
Subject: [issue43433] xmlrpc.client ignores query in URI ("?action=xmlrpc2")
 since python-3.9
In-Reply-To: <1615206556.6.0.195752820504.issue43433@roundup.psfhosted.org>
Message-ID: <1617025191.45.0.649272194981.issue43433@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: +23818
pull_request: https://github.com/python/cpython/pull/25068

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43433>
_______________________________________

From report at bugs.python.org  Mon Mar 29 10:16:30 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 29 Mar 2021 14:16:30 +0000
Subject: [issue43648] Remove redundant datefmt option in logging file config
In-Reply-To: <1616950072.91.0.715870512234.issue43648@roundup.psfhosted.org>
Message-ID: <1617027390.97.0.0808818711461.issue43648@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 7bfd65eba73d013eee8789f2009c09c61c31b800 by Harry in branch 'master':
bpo-43648: Remove redundant datefmt option in logging file config (GH-25051)
https://github.com/python/cpython/commit/7bfd65eba73d013eee8789f2009c09c61c31b800


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43648>
_______________________________________

From report at bugs.python.org  Mon Mar 29 10:17:41 2021
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 29 Mar 2021 14:17:41 +0000
Subject: [issue43648] Remove redundant datefmt option in logging file config
In-Reply-To: <1616950072.91.0.715870512234.issue43648@roundup.psfhosted.org>
Message-ID: <1617027461.43.0.171733846256.issue43648@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43648>
_______________________________________

From report at bugs.python.org  Mon Mar 29 10:43:10 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 29 Mar 2021 14:43:10 +0000
Subject: [issue43433] xmlrpc.client ignores query in URI ("?action=xmlrpc2")
 since python-3.9
In-Reply-To: <1615206556.6.0.195752820504.issue43433@roundup.psfhosted.org>
Message-ID: <1617028990.57.0.689258786221.issue43433@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 5334605035d38139a04189ecb3899f36702517b2 by Miss Islington (bot) in branch '3.9':
bpo-43433: Preserve query and fragment in the URL of the server in ServerProxy. (GH-25057)
https://github.com/python/cpython/commit/5334605035d38139a04189ecb3899f36702517b2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43433>
_______________________________________

From report at bugs.python.org  Mon Mar 29 10:57:07 2021
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 29 Mar 2021 14:57:07 +0000
Subject: [issue26300] "unpacked" bytecode
In-Reply-To: <1454710664.23.0.316699327961.issue26300@psf.upfronthosting.co.za>
Message-ID: <1617029827.89.0.427419359642.issue26300@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

PEP 511 was rejected.
The "peephole" optimizer now operates on the internal IR, not the bytecode.

----------
nosy: +Mark.Shannon
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26300>
_______________________________________

From report at bugs.python.org  Mon Mar 29 11:03:37 2021
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 29 Mar 2021 15:03:37 +0000
Subject: [issue27129] Wordcode, part 2
In-Reply-To: <1464268387.83.0.862540030058.issue27129@psf.upfronthosting.co.za>
Message-ID: <1617030217.04.0.57083317095.issue27129@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

frame.f_lasti and traceback.tb_lasti are best left as byte offsets.
There is no guarantee that we won't go back to variable length instructions.
For example, a "LONG_JUMP" instruction which is 4 bytes long and takes a 3 byte offset might well be a worthwhile extension.

However, changing bytecode offsets and the internal representation of frame.f_lasti will reduce the number of "EXTENDED_ARG"s by 60% or more and makes interpreter dispatch a tad more efficient.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27129>
_______________________________________

From report at bugs.python.org  Mon Mar 29 11:17:29 2021
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 29 Mar 2021 15:17:29 +0000
Subject: [issue27129] Wordcode, part 2
In-Reply-To: <1464268387.83.0.862540030058.issue27129@psf.upfronthosting.co.za>
Message-ID: <1617031049.88.0.893259183576.issue27129@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
pull_requests: +23819
pull_request: https://github.com/python/cpython/pull/25069

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27129>
_______________________________________

From report at bugs.python.org  Mon Mar 29 11:34:44 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 29 Mar 2021 15:34:44 +0000
Subject: [issue43624] Add underscore as a decimal separator for string
 formatting
In-Reply-To: <1616692747.49.0.677529428018.issue43624@roundup.psfhosted.org>
Message-ID: <1617032084.94.0.934192479595.issue43624@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I prefer Terry's original proposal which is backwards compatible and gives the user control over whether separator is to be applied to the fractional component.   

>>> format(12_34_56.12_34_56, '_._f')   # Whole and fractional
'123_456.123_456'
>>> format(12_34_56.12_34_56, '_.f')    # Fractional component only   
'123_456.123456'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43624>
_______________________________________

From report at bugs.python.org  Mon Mar 29 11:37:48 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 29 Mar 2021 15:37:48 +0000
Subject: [issue43624] Add underscore as a decimal separator for string
 formatting
In-Reply-To: <1616692747.49.0.677529428018.issue43624@roundup.psfhosted.org>
Message-ID: <1617032268.71.0.469200492435.issue43624@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I agree with Raymond. We can't make a change that would modify existing program output. Which is unfortunate, but such is life.

And I'd prefer to see groupings of 5 on the right, but I realize I might be in the minority.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43624>
_______________________________________

From report at bugs.python.org  Mon Mar 29 11:39:15 2021
From: report at bugs.python.org (Ned Deily)
Date: Mon, 29 Mar 2021 15:39:15 +0000
Subject: [issue42988] [security] CVE-2021-3426: Information disclosure via
 pydoc -p: /getfile?key=path allows to read arbitrary file on the filesystem
In-Reply-To: <1611231517.86.0.296188996897.issue42988@roundup.psfhosted.org>
Message-ID: <1617032355.68.0.638644887117.issue42988@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 7c2284f97d140c4e4a85382bfb3a42440be2464d by Miss Islington (bot) in branch '3.7':
bpo-42988: Remove the pydoc getfile feature (GH-25015) (#25066)
https://github.com/python/cpython/commit/7c2284f97d140c4e4a85382bfb3a42440be2464d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42988>
_______________________________________

From report at bugs.python.org  Mon Mar 29 11:41:02 2021
From: report at bugs.python.org (Ned Deily)
Date: Mon, 29 Mar 2021 15:41:02 +0000
Subject: [issue42988] [security] CVE-2021-3426: Information disclosure via
 pydoc -p: /getfile?key=path allows to read arbitrary file on the filesystem
In-Reply-To: <1611231517.86.0.296188996897.issue42988@roundup.psfhosted.org>
Message-ID: <1617032462.25.0.075168589135.issue42988@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 5b1e50256b6532667b6d31debc350f6c7d3f30aa by Miss Islington (bot) in branch '3.6':
bpo-42988: Remove the pydoc getfile feature (GH-25015) (GH-25067)
https://github.com/python/cpython/commit/5b1e50256b6532667b6d31debc350f6c7d3f30aa


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42988>
_______________________________________

From report at bugs.python.org  Mon Mar 29 11:56:13 2021
From: report at bugs.python.org (William Woodruff)
Date: Mon, 29 Mar 2021 15:56:13 +0000
Subject: [issue38794] Setup: support linking openssl statically
In-Reply-To: <1573734613.61.0.712380405287.issue38794@roundup.psfhosted.org>
Message-ID: <1617033373.76.0.0230503127516.issue38794@roundup.psfhosted.org>


William Woodruff <william at yossarian.net> added the comment:

Not to butt in too much, but I have a related use case that would benefit from being able to statically link to OpenSSL: I have an environment in which dynamic modules are acceptable, but where the entire Python install benefits from being relocatable and used on different hosts with the same *basic* state (same glibc, etc). OpenSSL isn't one of those pieces of basic state (for bad reasons, but ones that I can't control), so having a Python distribution that links it statically would save me some amount of complexity.

I realize this introduces a significant support burden, and that dealing with myraid OpenSSL configurations is already a pain. So I'm content to shoulder this as my own local build patch -- I'm only following up to note another use case that might benefit from a full-fledged `configure` option, should this ever get re-visited.

----------
nosy: +yossarian

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38794>
_______________________________________

From report at bugs.python.org  Mon Mar 29 12:53:01 2021
From: report at bugs.python.org (kale-smoothie)
Date: Mon, 29 Mar 2021 16:53:01 +0000
Subject: [issue43658] implementations of the deprecated load_module import
 loader API, as prescribed by the documentation, are not thread safe
Message-ID: <1617036781.07.0.980162704543.issue43658@roundup.psfhosted.org>


New submission from kale-smoothie <suraj-patel-95 at outlook.com>:

Unless I've misread or misunderstood, the documentation at https://docs.python.org/3/reference/import.html#loaders for the deprecated `load_module` method doesn't indicate any requirements or caveats for thread safe importing. As it stands, I think it is not thread-safe, since the module is not protected against concurrent imports by the internal implementation marker `__spec__._initializing = True`.

Additionally, the deprecated function decorator, `importlib.util.module_for_loader` seems to implement the marker incorrectly (sets `__initializing__` directly on the module).

I think this behaviour should either be documented as a major caveat, or internal details exposed to allow thread-safe implementations, or the old API removed entirely.

----------
assignee: docs at python
components: Documentation
files: thread_unsafe_import.py
messages: 389713
nosy: docs at python, kale-smoothie
priority: normal
severity: normal
status: open
title: implementations of the deprecated load_module import loader API, as prescribed by the documentation, are not thread safe
type: behavior
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49916/thread_unsafe_import.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43658>
_______________________________________

From report at bugs.python.org  Mon Mar 29 13:02:31 2021
From: report at bugs.python.org (Walter White)
Date: Mon, 29 Mar 2021 17:02:31 +0000
Subject: [issue43657] shutil.rmtree fails on readonly files in Windows,
 onerror not called
In-Reply-To: <1617022349.59.0.0395025567771.issue43657@roundup.psfhosted.org>
Message-ID: <1617037351.68.0.778427696895.issue43657@roundup.psfhosted.org>


Change by Walter White <homerun4711 at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43657>
_______________________________________

From report at bugs.python.org  Mon Mar 29 13:22:28 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 29 Mar 2021 17:22:28 +0000
Subject: [issue35930] Raising an exception raised in a "future" instance will
 create reference cycles
In-Reply-To: <1549549530.21.0.398741964575.issue35930@roundup.psfhosted.org>
Message-ID: <1617038548.65.0.0626269040366.issue35930@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: +23820
pull_request: https://github.com/python/cpython/pull/25070

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35930>
_______________________________________

From report at bugs.python.org  Mon Mar 29 13:22:44 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 29 Mar 2021 17:22:44 +0000
Subject: [issue35930] Raising an exception raised in a "future" instance will
 create reference cycles
In-Reply-To: <1549549530.21.0.398741964575.issue35930@roundup.psfhosted.org>
Message-ID: <1617038564.38.0.530505096911.issue35930@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +23822
pull_request: https://github.com/python/cpython/pull/25072

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35930>
_______________________________________

From report at bugs.python.org  Mon Mar 29 13:22:49 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 29 Mar 2021 17:22:49 +0000
Subject: [issue35930] Raising an exception raised in a "future" instance will
 create reference cycles
In-Reply-To: <1549549530.21.0.398741964575.issue35930@roundup.psfhosted.org>
Message-ID: <1617038569.69.0.434584605457.issue35930@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +23823
pull_request: https://github.com/python/cpython/pull/25073

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35930>
_______________________________________

From report at bugs.python.org  Mon Mar 29 13:22:37 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 29 Mar 2021 17:22:37 +0000
Subject: [issue35930] Raising an exception raised in a "future" instance will
 create reference cycles
In-Reply-To: <1549549530.21.0.398741964575.issue35930@roundup.psfhosted.org>
Message-ID: <1617038557.92.0.461742294159.issue35930@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +23821
pull_request: https://github.com/python/cpython/pull/25071

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35930>
_______________________________________

From report at bugs.python.org  Mon Mar 29 13:22:42 2021
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 29 Mar 2021 17:22:42 +0000
Subject: [issue35930] Raising an exception raised in a "future" instance will
 create reference cycles
In-Reply-To: <1549549530.21.0.398741964575.issue35930@roundup.psfhosted.org>
Message-ID: <1617038562.92.0.640070980243.issue35930@roundup.psfhosted.org>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:


New changeset 32430aadadf6e012e39167d3c18a24e49fb84874 by Jes?s Cea in branch 'master':
bpo-35930: Raising an exception raised in a "future" instance will create reference cycles (#24995)
https://github.com/python/cpython/commit/32430aadadf6e012e39167d3c18a24e49fb84874


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35930>
_______________________________________

From report at bugs.python.org  Mon Mar 29 13:46:19 2021
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 29 Mar 2021 17:46:19 +0000
Subject: [issue43466] ssl/hashlib: Add configure option to set or auto-detect
 rpath to OpenSSL libs
In-Reply-To: <1615418043.46.0.229114131093.issue43466@roundup.psfhosted.org>
Message-ID: <1617039979.8.0.473207768026.issue43466@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

There are now multiple ways to build Python with a custom OpenSSL build on Linux and BSD-like platforms:

1) Tools/ssl/multissltest.py
2) ./configure --with-openssl=/path/to/openssl --with-openssl-rpath=auto
3) undocumented hack from commit bacefbf41461ab703b8d561f0e3d766427eab367
4) static extension modules with a custom "Modules/Setup.local" like this:

OPENSSL=/home/heimes/dev/python/multissl/openssl/1.1.1j-static
_ssl _ssl.c \
    -I$(OPENSSL)/include -L$(OPENSSL)/lib \
    -l:libssl.a -Wl,--exclude-libs,libssl.a \
    -l:libcrypto.a -Wl,--exclude-libs,libcrypto.a
_hashlib _hashopenssl.c \
    -I$(OPENSSL)/include -L$(OPENSSL)/lib \
    -l:libcrypto.a -Wl,--exclude-libs,libcrypto.a

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43466>
_______________________________________

From report at bugs.python.org  Mon Mar 29 13:51:13 2021
From: report at bugs.python.org (Michael Felt)
Date: Mon, 29 Mar 2021 17:51:13 +0000
Subject: [issue43659] AIX: test_curses crashes buildbot
Message-ID: <1617040273.92.0.487968447995.issue43659@roundup.psfhosted.org>


New submission from Michael Felt <aixtools at felt.demon.nl>:

Since issue42789 the AIX bot's have crashed - to the extent that the bot's did not even return results.

Part of this has been resolved, for now, by using:

$ export TERM=unknown
$ buildbot start buildarea

However, the test still crash because AIX default libcurses.a does not include support for update_lines_cols().

This patch should allow test_curses.py to pass in the buildbot.

When run from command-line as:

$ TERM=unknown ./python Lib/test/test_curses.py
.ss......ssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss
----------------------------------------------------------------------
Ran 71 tests in 0.121s

OK (skipped=64)
aixtools at cpython2:[/home/aixtools/py3a-10.0]

(When TERM is defined - a core dump still occurs - that will be a new issue and a new PR).

----------
components: Tests
messages: 389716
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: AIX: test_curses crashes buildbot
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43659>
_______________________________________

From report at bugs.python.org  Mon Mar 29 13:53:21 2021
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 29 Mar 2021 17:53:21 +0000
Subject: [issue35930] Raising an exception raised in a "future" instance will
 create reference cycles
In-Reply-To: <1549549530.21.0.398741964575.issue35930@roundup.psfhosted.org>
Message-ID: <1617040401.7.0.863699366845.issue35930@roundup.psfhosted.org>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:


New changeset dae1963cf38f730291126b7dadfda89ffb21cefd by Miss Islington (bot) in branch '3.8':
bpo-35930: Raising an exception raised in a "future" instance will create reference cycles (GH-24995) (#25071)
https://github.com/python/cpython/commit/dae1963cf38f730291126b7dadfda89ffb21cefd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35930>
_______________________________________

From report at bugs.python.org  Mon Mar 29 13:53:59 2021
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 29 Mar 2021 17:53:59 +0000
Subject: [issue35930] Raising an exception raised in a "future" instance will
 create reference cycles
In-Reply-To: <1549549530.21.0.398741964575.issue35930@roundup.psfhosted.org>
Message-ID: <1617040439.14.0.283543912668.issue35930@roundup.psfhosted.org>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:


New changeset d914813a7a9cee3b42e9c91f91ac491f3bbfe118 by Miss Islington (bot) in branch '3.9':
bpo-35930: Raising an exception raised in a "future" instance will create reference cycles (GH-24995) (#25070)
https://github.com/python/cpython/commit/d914813a7a9cee3b42e9c91f91ac491f3bbfe118


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35930>
_______________________________________

From report at bugs.python.org  Mon Mar 29 13:55:16 2021
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 29 Mar 2021 17:55:16 +0000
Subject: [issue35930] Raising an exception raised in a "future" instance will
 create reference cycles
In-Reply-To: <1549549530.21.0.398741964575.issue35930@roundup.psfhosted.org>
Message-ID: <1617040516.68.0.484569456558.issue35930@roundup.psfhosted.org>


Change by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35930>
_______________________________________

From report at bugs.python.org  Mon Mar 29 14:02:23 2021
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 29 Mar 2021 18:02:23 +0000
Subject: [issue38794] Setup: support linking openssl statically
In-Reply-To: <1573734613.61.0.712380405287.issue38794@roundup.psfhosted.org>
Message-ID: <1617040943.44.0.731670985771.issue38794@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

I introduced several build improvements for better support of custom OpenSSL builds in bpo-43466. The issue mentions a new, undocumented, and unsupported hack to create a shared extension modules with statically linked OpenSSL. The Modules/Setup.local trick works with current Python versions, too. Both the hack and the trick hide symbols, too.

I vetoed against official support for static linking because I simply don't have capacity to test and support another build flavor.

William, I recommend that you do NOT read commit bacefbf41461ab703b8d561f0e3d766427eab367 and do NOT use the undocumented hack. Have fun! :)

----------
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed
superseder:  -> ssl/hashlib: Add configure option to set or auto-detect rpath to OpenSSL libs
versions: +Python 3.10 -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38794>
_______________________________________

From report at bugs.python.org  Mon Mar 29 14:03:01 2021
From: report at bugs.python.org (Michael Felt)
Date: Mon, 29 Mar 2021 18:03:01 +0000
Subject: [issue43659] AIX: test_curses crashes buildbot
In-Reply-To: <1617040273.92.0.487968447995.issue43659@roundup.psfhosted.org>
Message-ID: <1617040981.52.0.491517586241.issue43659@roundup.psfhosted.org>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
keywords: +patch
pull_requests: +23824
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25074

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43659>
_______________________________________

From report at bugs.python.org  Mon Mar 29 14:05:14 2021
From: report at bugs.python.org (Michael Felt)
Date: Mon, 29 Mar 2021 18:05:14 +0000
Subject: [issue43659] AIX: test_curses crashes buildbot
In-Reply-To: <1617040273.92.0.487968447995.issue43659@roundup.psfhosted.org>
Message-ID: <1617041114.99.0.623916504063.issue43659@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

backports needed for 3.8 and 3.9

----------
versions: +Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43659>
_______________________________________

From report at bugs.python.org  Mon Mar 29 14:24:57 2021
From: report at bugs.python.org (William Woodruff)
Date: Mon, 29 Mar 2021 18:24:57 +0000
Subject: [issue38794] Setup: support linking openssl statically
In-Reply-To: <1573734613.61.0.712380405287.issue38794@roundup.psfhosted.org>
Message-ID: <1617042297.99.0.522575518461.issue38794@roundup.psfhosted.org>


William Woodruff <william at yossarian.net> added the comment:

Cheers! No promises about not using the hack, but I *will* promise not to complain if it doesn't work for me :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38794>
_______________________________________

From report at bugs.python.org  Mon Mar 29 14:33:22 2021
From: report at bugs.python.org (=?utf-8?b?TMOhc3psw7MgS2lzcyBLb2xsw6Fy?=)
Date: Mon, 29 Mar 2021 18:33:22 +0000
Subject: [issue41906] logging.config.dictConfig does not work with callable
 filters
In-Reply-To: <1601599406.74.0.279190575587.issue41906@roundup.psfhosted.org>
Message-ID: <1617042802.28.0.140230708766.issue41906@roundup.psfhosted.org>


Change by L?szl? Kiss Koll?r <kiss.kollar.laszlo at gmail.com>:


----------
nosy: +lkollar

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41906>
_______________________________________

From report at bugs.python.org  Mon Mar 29 14:42:46 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 29 Mar 2021 18:42:46 +0000
Subject: [issue43660] Segmentation fault when overriding sys.stderr
Message-ID: <1617043366.54.0.823715047816.issue43660@roundup.psfhosted.org>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

This code crashes (reported by the one and only Matt Wozniski):

import sys
class MyStderr:
    def write(self, s):
        sys.stderr = None
sys.stderr = MyStderr()
1/0

[1]    34112 segmentation fault  ./python.exe lel.py

----------
components: Interpreter Core
messages: 389722
nosy: pablogsal, vstinner
priority: normal
severity: normal
status: open
title: Segmentation fault when overriding sys.stderr
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43660>
_______________________________________

From report at bugs.python.org  Mon Mar 29 14:43:40 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 29 Mar 2021 18:43:40 +0000
Subject: [issue43660] Segmentation fault when overriding sys.stderr
In-Reply-To: <1617043366.54.0.823715047816.issue43660@roundup.psfhosted.org>
Message-ID: <1617043420.29.0.57027958768.issue43660@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

The problem is that https://github.com/python/cpython/blob/master/Python/pythonrun.c#L1074 doesn't take a strong reference to sys.stderr but code underneath can potentially release the GIL and remove the reference that keeps the object alive.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43660>
_______________________________________

From report at bugs.python.org  Mon Mar 29 14:50:25 2021
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 29 Mar 2021 18:50:25 +0000
Subject: [issue43657] shutil.rmtree fails on readonly files in Windows,
 onerror not called
In-Reply-To: <1617022349.59.0.0395025567771.issue43657@roundup.psfhosted.org>
Message-ID: <1617043825.92.0.771903702799.issue43657@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> The doc on rmtree states 
> Exceptions raised by onerror will not be caught.
> Does this mean I can't use try/exept inside of onerro

rmtree() does not call onerror() in a try/except statement. An exception raised in onerror() will propagate to the scope that called rmtree().

The documentation has an example onerror() handler for Windows readonly files:

    import os, stat
    import shutil

    def remove_readonly(func, path, _):
        "Clear the readonly bit and reattempt the removal"
        os.chmod(path, stat.S_IWRITE)
        func(path)

    shutil.rmtree(directory, onerror=remove_readonly)

I'd check whether the exception and function are expected values. For example:

    import os, stat
    import shutil

    def remove_readonly(func, path, exc_info):
        "Clear the readonly bit and reattempt the removal"
        # ERROR_ACCESS_DENIED = 5
        if func not in (os.unlink, os.rmdir) or exc_info[1].winerror != 5:
            raise exc_info[1]
        os.chmod(path, stat.S_IWRITE)
        func(path)

    shutil.rmtree(directory, onerror=remove_readonly)

----------
nosy: +eryksun
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43657>
_______________________________________

From report at bugs.python.org  Mon Mar 29 14:52:46 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 29 Mar 2021 18:52:46 +0000
Subject: [issue43660] Segmentation fault when overriding sys.stderr
In-Reply-To: <1617043366.54.0.823715047816.issue43660@roundup.psfhosted.org>
Message-ID: <1617043966.61.0.769610935709.issue43660@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +23825
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25075

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43660>
_______________________________________

From report at bugs.python.org  Mon Mar 29 14:55:55 2021
From: report at bugs.python.org (Dino Viehland)
Date: Mon, 29 Mar 2021 18:55:55 +0000
Subject: [issue43636] test_descr fails randomly when executed with -R :
In-Reply-To: <1616802835.56.0.699111570038.issue43636@roundup.psfhosted.org>
Message-ID: <1617044155.46.0.720611772123.issue43636@roundup.psfhosted.org>


Dino Viehland <dinoviehland at gmail.com> added the comment:

@vstinner - The fix doesn't change the behavior of _PyType_Lookup and instead just fixes a previous unrelated bug.  The condition will typically ever be hit once (at startup) as it's very unlikely that versions will wrap, so there should be no performance difference after the fix.

----------
resolution: fixed -> 
stage: resolved -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43636>
_______________________________________

From report at bugs.python.org  Mon Mar 29 15:04:03 2021
From: report at bugs.python.org (Brad Warren)
Date: Mon, 29 Mar 2021 19:04:03 +0000
Subject: [issue43631] Update to OpenSSL 1.1.1k
In-Reply-To: <1616746538.63.0.13329268116.issue43631@roundup.psfhosted.org>
Message-ID: <1617044643.01.0.210375764878.issue43631@roundup.psfhosted.org>


Change by Brad Warren <bradmwarren at gmail.com>:


----------
nosy: +bmw

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43631>
_______________________________________

From report at bugs.python.org  Mon Mar 29 15:06:41 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 29 Mar 2021 19:06:41 +0000
Subject: [issue43659] AIX: test_curses crashes buildbot
In-Reply-To: <1617040273.92.0.487968447995.issue43659@roundup.psfhosted.org>
Message-ID: <1617044801.58.0.879169879863.issue43659@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset c8b5738810516df5722caf049003e9b319427bec by Michael Felt in branch 'master':
bpo-43659:  Fix test_curses on AIX (GH-25074)
https://github.com/python/cpython/commit/c8b5738810516df5722caf049003e9b319427bec


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43659>
_______________________________________

From report at bugs.python.org  Mon Mar 29 15:07:14 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 29 Mar 2021 19:07:14 +0000
Subject: [issue43659] AIX: test_curses crashes buildbot
In-Reply-To: <1617040273.92.0.487968447995.issue43659@roundup.psfhosted.org>
Message-ID: <1617044834.1.0.846204431313.issue43659@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +23827
pull_request: https://github.com/python/cpython/pull/25077

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43659>
_______________________________________

From report at bugs.python.org  Mon Mar 29 15:07:06 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 29 Mar 2021 19:07:06 +0000
Subject: [issue43659] AIX: test_curses crashes buildbot
In-Reply-To: <1617040273.92.0.487968447995.issue43659@roundup.psfhosted.org>
Message-ID: <1617044826.85.0.201138609292.issue43659@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: +23826
pull_request: https://github.com/python/cpython/pull/25076

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43659>
_______________________________________

From report at bugs.python.org  Mon Mar 29 15:08:04 2021
From: report at bugs.python.org (Tom Kacvinsky)
Date: Mon, 29 Mar 2021 19:08:04 +0000
Subject: [issue43661] api-ms-win-core-path-l1-1.0.dll,
 redux of 40740 (which has since been closed)
Message-ID: <1617044884.9.0.569070921495.issue43661@roundup.psfhosted.org>


New submission from Tom Kacvinsky <tkacvins at gmail.com>:

Even though bpo#40740 has been closed, I wanted to re-raise the issue as this affects me.  There are only two functions that come from this missing DLL:

PathCchCombineEx
PathCchCanonicalizeEx

Would there be a way of rewriting join/canonicalize in getpathp.c (each of which uses one of the above functions) to _not_ rely on functions from a missing DLL on Windows 7 SP1?  Or has the ship truly sailed on this matter?

----------
components: C API
messages: 389727
nosy: tkacvinsky
priority: normal
severity: normal
status: open
title: api-ms-win-core-path-l1-1.0.dll, redux of 40740 (which has since been closed)
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43661>
_______________________________________

From report at bugs.python.org  Mon Mar 29 15:18:19 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 29 Mar 2021 19:18:19 +0000
Subject: [issue43659] AIX: test_curses crashes buildbot
In-Reply-To: <1617040273.92.0.487968447995.issue43659@roundup.psfhosted.org>
Message-ID: <1617045499.07.0.458249288279.issue43659@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Minor correction. update_lines_cols() is not provided by the underlying curses library, it is a helper defined in Python wrapper. But it is optional, snd skipping test is the correct solution. Thank you.

As for the core dump, could you please run the test in verbose mode with redirected stdout and stderr and show the result?

    ./python -m test -vuall test_curses 2>test.err >test.out

What is the default value of TERM? Does the result differ if set TERM=xterm?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43659>
_______________________________________

From report at bugs.python.org  Mon Mar 29 15:26:46 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 29 Mar 2021 19:26:46 +0000
Subject: [issue43659] AIX: test_curses crashes buildbot
In-Reply-To: <1617040273.92.0.487968447995.issue43659@roundup.psfhosted.org>
Message-ID: <1617046006.87.0.810738464914.issue43659@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e9092b221d4951609827e437178a557fd07353af by Miss Islington (bot) in branch '3.8':
bpo-43659:  Fix test_curses on AIX (GH-25074)
https://github.com/python/cpython/commit/e9092b221d4951609827e437178a557fd07353af


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43659>
_______________________________________

From report at bugs.python.org  Mon Mar 29 15:27:07 2021
From: report at bugs.python.org (frathgeber)
Date: Mon, 29 Mar 2021 19:27:07 +0000
Subject: [issue43433] xmlrpc.client ignores query in URI ("?action=xmlrpc2")
 since python-3.9
In-Reply-To: <1615206556.6.0.195752820504.issue43433@roundup.psfhosted.org>
Message-ID: <1617046027.15.0.590396966359.issue43433@roundup.psfhosted.org>


frathgeber <florian.rathgeber at gmail.com> added the comment:

Thanks Serhiy for the very quick fix! I believe handling these corner cases is not worth the effort and I really hope no one relies on these being differentiated. This change will go into a future 3.9 release?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43433>
_______________________________________

From report at bugs.python.org  Mon Mar 29 15:31:10 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 29 Mar 2021 19:31:10 +0000
Subject: [issue43659] AIX: test_curses crashes buildbot
In-Reply-To: <1617040273.92.0.487968447995.issue43659@roundup.psfhosted.org>
Message-ID: <1617046270.65.0.776714376076.issue43659@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset f1d53bcd536036c0a0c39962fbc0f465b5865492 by Miss Islington (bot) in branch '3.9':
bpo-43659:  Fix test_curses on AIX (GH-25074)
https://github.com/python/cpython/commit/f1d53bcd536036c0a0c39962fbc0f465b5865492


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43659>
_______________________________________

From report at bugs.python.org  Mon Mar 29 15:36:55 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Mar 2021 19:36:55 +0000
Subject: [issue35883] Python startup fails with a fatal error if a command
 line argument contains an invalid Unicode character
In-Reply-To: <1549040138.25.0.646545491344.issue35883@roundup.psfhosted.org>
Message-ID: <1617046615.31.0.332477678781.issue35883@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 3b6e61ee0812359029cac176042d9c835c60f185 by Miss Islington (bot) in branch '3.8':
bpo-35883: Py_DecodeLocale() escapes invalid Unicode characters (GH-24843) (GH-24906)
https://github.com/python/cpython/commit/3b6e61ee0812359029cac176042d9c835c60f185


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35883>
_______________________________________

From report at bugs.python.org  Mon Mar 29 15:37:40 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Mar 2021 19:37:40 +0000
Subject: [issue43562] test_ssl.NetworkedTests.test_timeout_connect_ex fails if
 network is unreachable
In-Reply-To: <1616187447.7.0.603298479381.issue43562@roundup.psfhosted.org>
Message-ID: <1617046660.58.0.0956028537344.issue43562@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset acb584958e215aff8fc8f5e2eb3fef481b662f69 by Miss Islington (bot) in branch '3.9':
bpo-43562: fix test_ssl to skip on unreachable network (GH-24937) (GH-25046)
https://github.com/python/cpython/commit/acb584958e215aff8fc8f5e2eb3fef481b662f69


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43562>
_______________________________________

From report at bugs.python.org  Mon Mar 29 15:37:42 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Mar 2021 19:37:42 +0000
Subject: [issue43562] test_ssl.NetworkedTests.test_timeout_connect_ex fails if
 network is unreachable
In-Reply-To: <1616187447.7.0.603298479381.issue43562@roundup.psfhosted.org>
Message-ID: <1617046662.47.0.520353855068.issue43562@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 20b2f2bfc2e72c6d9ed983d1f0aa7a141e9b3fc3 by Miss Islington (bot) in branch '3.8':
bpo-43562: fix test_ssl to skip on unreachable network (GH-24937) (GH-25047)
https://github.com/python/cpython/commit/20b2f2bfc2e72c6d9ed983d1f0aa7a141e9b3fc3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43562>
_______________________________________

From report at bugs.python.org  Mon Mar 29 15:37:49 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Mar 2021 19:37:49 +0000
Subject: [issue43562] test_ssl.NetworkedTests.test_timeout_connect_ex fails if
 network is unreachable
In-Reply-To: <1616187447.7.0.603298479381.issue43562@roundup.psfhosted.org>
Message-ID: <1617046669.94.0.224089767628.issue43562@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/issue43562>
_______________________________________

From report at bugs.python.org  Mon Mar 29 15:39:54 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Mar 2021 19:39:54 +0000
Subject: [issue42988] [security] CVE-2021-3426: Information disclosure via
 pydoc -p: /getfile?key=path allows to read arbitrary file on the filesystem
In-Reply-To: <1611231517.86.0.296188996897.issue42988@roundup.psfhosted.org>
Message-ID: <1617046794.15.0.675260164672.issue42988@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/issue42988>
_______________________________________

From report at bugs.python.org  Mon Mar 29 16:16:46 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Mar 2021 20:16:46 +0000
Subject: [issue43624] Add underscore as a decimal separator for string
 formatting
In-Reply-To: <1616692747.49.0.677529428018.issue43624@roundup.psfhosted.org>
Message-ID: <1617049006.91.0.576801450971.issue43624@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

'_.f' would be the same as '_f'?

Should "._f" be allowed to only add underscores in the fractional part? (for consistency?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43624>
_______________________________________

From report at bugs.python.org  Mon Mar 29 16:18:27 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Mar 2021 20:18:27 +0000
Subject: [issue43624] Add underscore as a decimal separator for string
 formatting
In-Reply-To: <1616692747.49.0.677529428018.issue43624@roundup.psfhosted.org>
Message-ID: <1617049107.55.0.616243354371.issue43624@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Raymond:
> I prefer Terry's original proposal which is backwards compatible (...)

Well ok, that's what I expected. Backward compatibility usually wins all other arguments in Python :-) But I had to ask the question :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43624>
_______________________________________

From report at bugs.python.org  Mon Mar 29 16:24:56 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 29 Mar 2021 20:24:56 +0000
Subject: [issue42225] Tkinter hangs or crashes when displaying astral chars
In-Reply-To: <1604200632.47.0.347759375724.issue42225@roundup.psfhosted.org>
Message-ID: <1617049496.16.0.170885781429.issue42225@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
keywords: +patch
pull_requests: +23828
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/25078

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42225>
_______________________________________

From report at bugs.python.org  Mon Mar 29 16:26:17 2021
From: report at bugs.python.org (Steve Dower)
Date: Mon, 29 Mar 2021 20:26:17 +0000
Subject: [issue19124] os.execv executes in background on Windows
In-Reply-To: <1380451602.11.0.517013085188.issue19124@psf.upfronthosting.co.za>
Message-ID: <1617049577.74.0.283443787419.issue19124@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> nt.spawnv[e](), nt.waitpid(), and nt.system() could also be implemented with subprocess.

I like the idea, but we shouldn't invert the dependencies like that. nt/os is a lower-level library, and should provide its own implementation (that perhaps subprocess could then use).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19124>
_______________________________________

From report at bugs.python.org  Mon Mar 29 16:26:45 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Mar 2021 20:26:45 +0000
Subject: [issue26300] "unpacked" bytecode
In-Reply-To: <1454710664.23.0.316699327961.issue26300@psf.upfronthosting.co.za>
Message-ID: <1617049605.5.0.517304440581.issue26300@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> The "peephole" optimizer now operates on the internal IR, not the bytecode.

Python/ast_opt.c is cool ;-) Thanks INADA-san for creating it!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26300>
_______________________________________

From report at bugs.python.org  Mon Mar 29 16:26:56 2021
From: report at bugs.python.org (Steve Dower)
Date: Mon, 29 Mar 2021 20:26:56 +0000
Subject: [issue43567] regen.vcxproj cannot regenerate some necessary files
In-Reply-To: <1616238138.44.0.687655765468.issue43567@roundup.psfhosted.org>
Message-ID: <1617049616.17.0.112645480912.issue43567@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
nosy: +anthonypjshaw, gvanrossum, lys.nikolaou, pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43567>
_______________________________________

From report at bugs.python.org  Mon Mar 29 16:32:53 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Mar 2021 20:32:53 +0000
Subject: [issue43662] test_tools: test_reindent_file_with_bad_encoding() fails
 on s390x RHEL7 LTO + PGO 3.x
Message-ID: <1617049973.14.0.713223722429.issue43662@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

https://buildbot.python.org/all/#/builders/244/builds/931
At commit 9b999479c0022edfc9835a8a1f06e046f3881048

(...)
test_reindent_file_with_bad_encoding (test.test_tools.test_reindent.ReindentTests) ... FAIL
(...)

======================================================================
FAIL: test_reindent_file_with_bad_encoding (test.test_tools.test_reindent.ReindentTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z.lto-pgo/build/Lib/test/test_tools/test_reindent.py", line 29, in test_reindent_file_with_bad_encoding
    rc, out, err = assert_python_ok(self.script, '-r', bad_coding_path)
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z.lto-pgo/build/Lib/test/support/script_helper.py", line 160, in assert_python_ok
    return _assert_python(True, *args, **env_vars)
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z.lto-pgo/build/Lib/test/support/script_helper.py", line 145, in _assert_python
    res.fail(cmd_line)
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z.lto-pgo/build/Lib/test/support/script_helper.py", line 72, in fail
    raise AssertionError("Process return code is %d\n"
AssertionError: Process return code is 1
command line: ['/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z.lto-pgo/build/python', '-X', 'faulthandler', '-I', '/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z.lto-pgo/build/Tools/scripts/reindent.py', '-r', '/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z.lto-pgo/build/Lib/test/bad_coding.py']

stdout:
---

---

stderr:
---
SyntaxError: encoding problem: encoding
---




Can it be related to the following change?

commit 261a452a1300eeeae1428ffd6e6623329c085e2c
Author: Pablo Galindo <Pablogsal at gmail.com>
Date:   Sun Mar 28 23:48:05 2021 +0100

    bpo-25643: Refactor the C tokenizer into smaller, logical units (GH-25050)

----------
components: Tests
messages: 389739
nosy: pablogsal, vstinner
priority: normal
severity: normal
status: open
title: test_tools: test_reindent_file_with_bad_encoding() fails on s390x RHEL7 LTO + PGO 3.x
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43662>
_______________________________________

From report at bugs.python.org  Mon Mar 29 16:35:44 2021
From: report at bugs.python.org (Steve Dower)
Date: Mon, 29 Mar 2021 20:35:44 +0000
Subject: [issue38905] venv python reports wrong sys.executable in a subprocess
 on Windows
In-Reply-To: <1574583460.3.0.94905817038.issue38905@roundup.psfhosted.org>
Message-ID: <1617050144.74.0.000877797432833.issue38905@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

The main motivator for the redirector was to support the Store package, which can only be *executed* from outside its container (we can't load the DLL directly). Given we want the two distributions to be interchangeable from a code POV, it made the most sense to switch both over. That said, there were other issues with the previous system that were worth fixing, it just happens that a new one was introduced (though it definitely already existed for some users - IPC is a complex pattern to get right even when you fully control the processes).

I still haven't been able to come up with a viable workaround that doesn't break more cases than it helps. Passing the internal environment variable around might help, but I don't want to fully support it because then that would prevent us fixing this properly!

PEP 582 (or otherwise getting away from virtual environments in favour of some other way of having project-specific package installation) may be our best hope.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38905>
_______________________________________

From report at bugs.python.org  Mon Mar 29 16:35:34 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Mar 2021 20:35:34 +0000
Subject: [issue43433] xmlrpc.client ignores query in URI ("?action=xmlrpc2")
 since python-3.9
In-Reply-To: <1615206556.6.0.195752820504.issue43433@roundup.psfhosted.org>
Message-ID: <1617050134.84.0.709665568727.issue43433@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

It seems like the issue is now fixed. Thanks Serhiy for the fix and thanks OndrejPtak for the report!

> This change will go into a future 3.9 release?

Yes, sure. Python 3.9 Release Schedule:
https://www.python.org/dev/peps/pep-0596/

Next expected release: Python 3.9.3: Monday, 2021-05-03.

----------
nosy: +vstinner
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43433>
_______________________________________

From report at bugs.python.org  Mon Mar 29 16:37:08 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Mar 2021 20:37:08 +0000
Subject: [issue43662] test_tools: test_reindent_file_with_bad_encoding() fails
 on s390x RHEL7 LTO + PGO 3.x
In-Reply-To: <1617049973.14.0.713223722429.issue43662@roundup.psfhosted.org>
Message-ID: <1617050228.47.0.560554357051.issue43662@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Oh. Or maybe it's related to:

commit 4827483f47906fecee6b5d9097df2a69a293a85c
Author: Inada Naoki <songofacandy at gmail.com>
Date:   Mon Mar 29 12:28:14 2021 +0900

    bpo-43510: Implement PEP 597 opt-in EncodingWarning. (GH-19481)
    
    See [PEP 597](https://www.python.org/dev/peps/pep-0597/).
    
    * Add `-X warn_default_encoding` and `PYTHONWARNDEFAULTENCODING`.
    * Add EncodingWarning
    * Add io.text_encoding()
    * open(), TextIOWrapper() emits EncodingWarning when encoding is omitted and warn_default_encoding is enabled.
    * _pyio.TextIOWrapper() uses UTF-8 as fallback default encoding used when failed to import locale module. (used during building Python)
    * bz2, configparser, gzip, lzma, pathlib, tempfile modules use io.text_encoding().
    * What's new entry

----------
nosy: +methane

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43662>
_______________________________________

From report at bugs.python.org  Mon Mar 29 16:37:21 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 29 Mar 2021 20:37:21 +0000
Subject: [issue43567] regen.vcxproj cannot regenerate some necessary files
In-Reply-To: <1616238138.44.0.687655765468.issue43567@roundup.psfhosted.org>
Message-ID: <1617050241.3.0.366351614575.issue43567@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Steve: let's talk about this in person today.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43567>
_______________________________________

From report at bugs.python.org  Mon Mar 29 16:39:49 2021
From: report at bugs.python.org (Terry Davis)
Date: Mon, 29 Mar 2021 20:39:49 +0000
Subject: [issue43624] Add underscore as a decimal separator for string
 formatting
In-Reply-To: <1616692747.49.0.677529428018.issue43624@roundup.psfhosted.org>
Message-ID: <1617050389.37.0.784355727196.issue43624@roundup.psfhosted.org>


Terry Davis <terry.y.davis at gmail.com> added the comment:

Victor,
> '_.f' would be the same as '_f'?
No, the example in my original post is wrong, '_.f' isn't allowed now.
The proposal should use '_f' to describe the current behavior.

> Should "._f" be allowed to only add underscores in the fractional part? (for consistency?)

Yes, but not for consistency with the above usage, instead it's so both fractional and integral underscores can be specified on their own.

Here is my attempt at updating the format spec. The only problem I have with it is that it allows a naked '.'; I don't know how to specify "dot must be followed by one or both of 'float_grouping' and 'precision'".

Current:
format_spec     ::=  [[fill]align][sign][#][0][width][grouping_option][.precision][type]

Proposed:
format_spec     ::=  [[fill]align][sign][#][0][width][grouping_option][.[float_grouping][precision]][type]
fill            ::=  <any character>
align           ::=  "<" | ">" | "=" | "^"
sign            ::=  "+" | "-" | " "
width           ::=  digit+
grouping_option ::=  "_" | ","
float_grouping  ::=  "_"
precision       ::=  digit+
type            ::=  "b" | "c" | "d" | "e" | "E" | "f" | "F" | "g" | "G" | "n" | "o" | "s" | "x" | "X" | "%"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43624>
_______________________________________

From report at bugs.python.org  Mon Mar 29 16:39:55 2021
From: report at bugs.python.org (Tzu-ping Chung)
Date: Mon, 29 Mar 2021 20:39:55 +0000
Subject: [issue43312] Interface to select preferred "user" or "home" sysconfig
 scheme for an environment
In-Reply-To: <1614158800.84.0.101101658017.issue43312@roundup.psfhosted.org>
Message-ID: <1617050395.44.0.409161313584.issue43312@roundup.psfhosted.org>


Tzu-ping Chung <uranusjr at gmail.com> added the comment:

Gentle ping again :) I?ve also created a PR for this.

> The Debian/Ubuntu packages have a local patch for distutils/setuptools introducing an --install-layout option.  Maybe have the same for pip?

Pip already has a similar mechanism. The default layout is `prefix` and you can change the installation prefix with `--prefix`; `home` and `user` layouts can be specified with `--home={base}` and `--user`.

> So the problem to solve is
>
>  - let a "sudo pip install" fail by default on the real system
>  - let the same install succeed in a docker environment, or any other "image".

These need to be done in pip, so we?ll have a separate discussion on them elsewhere.

>  - behave transparently on venv and virtualenv installations.

This is what this issue tries to address. A distribution can overwrite `sysconfig.get_default_scheme()` and `sysconfig.get_preferred_scheme(variant)` to return the correct scheme based on whether the current Python is in a virtual environment (by detecting `sys.prefix` and `sys.base_prefix`, I think).

When in a virtual environment, it can return the same scheme as the upstream. Outside of a virtual environment, it can do whatever the platform sees fit, and pip (or whatever calls sysconfig) will install things into wherever it?s told to by the two functions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43312>
_______________________________________

From report at bugs.python.org  Mon Mar 29 16:40:17 2021
From: report at bugs.python.org (Steve Dower)
Date: Mon, 29 Mar 2021 20:40:17 +0000
Subject: [issue37745] 3.8b3 - windows install gui/ inconsistent options
In-Reply-To: <1564766468.14.0.320547199271.issue37745@roundup.psfhosted.org>
Message-ID: <1617050417.57.0.654728252394.issue37745@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

The main problem with adding Python to PATH is interfering with other application's DLL and executable resolution order, as well as the inevitable confusion when multiple PATH updates do not play well together (which they don't).

The best thing you can do with your students (those on Windows 10, at least) is get Python from the Microsoft Store, which is able to do the PATH updates property (and you can modify them through the built-in "Manage App Execution Aliases" control panel if you have multiple).

Any other solution that is reliable, maintainable (for users) and usable is going to require significantly more development (and will break many existing users' workflows, but hopefully not too badly) than just flipping the checkbox. But some of us are thinking about it (me in particular, since I'm sick to death of being abused over this issue but would rather find a good way to fix it than just quit).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37745>
_______________________________________

From report at bugs.python.org  Mon Mar 29 16:40:44 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Mar 2021 20:40:44 +0000
Subject: [issue43662] test_tools: test_reindent_file_with_bad_encoding() fails
 on s390x RHEL7 LTO + PGO 3.x
In-Reply-To: <1617049973.14.0.713223722429.issue43662@roundup.psfhosted.org>
Message-ID: <1617050444.61.0.998755256201.issue43662@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> https://buildbot.python.org/all/#/builders/244/builds/931

test.pythoninfo:

config[filesystem_encoding]: 'utf-8'
config[filesystem_errors]: 'surrogateescape'
config[stdio_encoding]: 'utf-8'
config[stdio_errors]: 'strict'
config[use_environment]: 1
config[warn_default_encoding]: 0

locale.encoding: UTF-8

os.environ[LANG]: en_US.UTF-8

os.uname: posix.uname_result(sysname='Linux', nodename='ztcpip3.pok.ibm.com', release='3.10.0-1160.11.1.el7.s390x', version='#1 SMP Mon Nov 30 13:07:00 EST 2020', machine='s390x')

platform.libc_ver: glibc 2.17
platform.platform: Linux-3.10.0-1160.11.1.el7.s390x-s390x-with-glibc2.17

pre_config[coerce_c_locale]: 0
pre_config[coerce_c_locale_warn]: 0
pre_config[configure_locale]: 1
pre_config[isolated]: 0
pre_config[utf8_mode]: 0

sys.filesystem_encoding: utf-8/surrogateescape

sys.stderr.encoding: utf-8/backslashreplace
sys.stdin.encoding: utf-8/strict
sys.stdout.encoding: utf-8/strict

sys.version: 3.10.0a6+ (heads/master:9b99947, Mar 29 2021, 08:53:44) [GCC 4.8.5 20150623 (Red Hat 4.8.5-44)]

sysconfig[CONFIG_ARGS]: '--prefix' '/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z.lto-pgo/build/target' '--with-lto' '--enable-optimizations'

sysconfig[PY_CFLAGS]: -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall
sysconfig[PY_CFLAGS_NODIST]: -flto -fuse-linker-plugin -ffat-lto-objects -flto-partition=none -g -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -fvisibility=hidden -fprofile-use -fprofile-correction -I./Include/internal

sysconfig[PY_CORE_LDFLAGS]: -flto -fuse-linker-plugin -ffat-lto-objects -flto-partition=none -g
sysconfig[PY_LDFLAGS_NODIST]: -flto -fuse-linker-plugin -ffat-lto-objects -flto-partition=none -g

sysconfig[Py_DEBUG]: 0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43662>
_______________________________________

From report at bugs.python.org  Mon Mar 29 16:48:51 2021
From: report at bugs.python.org (Brad Warren)
Date: Mon, 29 Mar 2021 20:48:51 +0000
Subject: [issue43631] Update to OpenSSL 1.1.1k
In-Reply-To: <1616746538.63.0.13329268116.issue43631@roundup.psfhosted.org>
Message-ID: <1617050931.12.0.507607279689.issue43631@roundup.psfhosted.org>


Brad Warren <bradmwarren at gmail.com> added the comment:

When do you expect there will be new macOS and Windows downloads available at https://www.python.org/downloads/ that use OpenSSL 1.1.1k?

One of my projects is relying on these files and I wasn't sure the ETA here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43631>
_______________________________________

From report at bugs.python.org  Mon Mar 29 16:52:05 2021
From: report at bugs.python.org (Steve Dower)
Date: Mon, 29 Mar 2021 20:52:05 +0000
Subject: [issue43631] Update to OpenSSL 1.1.1k
In-Reply-To: <1616746538.63.0.13329268116.issue43631@roundup.psfhosted.org>
Message-ID: <1617051125.91.0.131821553246.issue43631@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Assume it'll be the next scheduled release (though I haven't looked at the details of the vulnerabilities yet, so we may decide that they're more urgent for CPython users).

I'm starting the Windows build process now, but that only gets us far enough to do the integration, it's not a release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43631>
_______________________________________

From report at bugs.python.org  Mon Mar 29 16:55:15 2021
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 29 Mar 2021 20:55:15 +0000
Subject: [issue43631] Update to OpenSSL 1.1.1k
In-Reply-To: <1616746538.63.0.13329268116.issue43631@roundup.psfhosted.org>
Message-ID: <1617051315.63.0.696821487705.issue43631@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Thanks!

My mail https://mail.python.org/archives/list/python-dev at python.org/thread/2GULUR43MNEW3IJM44LS5ZY2TOUANPNT/ contains a first analysis of the CVEs. I'm pretty sure any server application with server-side TLS socket is vulnerable to CVE-2021-3449.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43631>
_______________________________________

From report at bugs.python.org  Mon Mar 29 16:56:29 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Mar 2021 20:56:29 +0000
Subject: [issue43662] test_tools: test_reindent_file_with_bad_encoding() fails
 on s390x RHEL7 LTO + PGO 3.x
In-Reply-To: <1617049973.14.0.713223722429.issue43662@roundup.psfhosted.org>
Message-ID: <1617051389.41.0.227144307155.issue43662@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> SyntaxError: encoding problem: encoding

This "encoding problem: %s" error message comes from check_coding_spec() of Parser/tokenizer.c. The "%s" argument is the cs variable which is initialized by get_coding_spec().

test_tools.test_reindent_file_with_bad_encoding() uses Lib/test/bad_coding.py which contains a single line:

# -*- coding: uft-8 -*-

The expected encoding name is "uft-8", not "encoding".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43662>
_______________________________________

From report at bugs.python.org  Mon Mar 29 17:02:59 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Mar 2021 21:02:59 +0000
Subject: [issue43662] test_tools: test_reindent_file_with_bad_encoding() fails
 on s390x RHEL7 LTO + PGO 3.x
In-Reply-To: <1617049973.14.0.713223722429.issue43662@roundup.psfhosted.org>
Message-ID: <1617051779.14.0.727696490367.issue43662@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

test_tools.test_reindent_file_with_bad_encoding() runs Tools/scripts/reindent.py.

The check() function of this script calls:

    with open(file, 'rb') as f:
        try:
            encoding, _ = tokenize.detect_encoding(f.readline)
        except SyntaxError as se:
            errprint("%s: SyntaxError: %s" % (file, str(se)))

But I don't think that the buildbot reached this line since the stderr message doesn't start with the input filename. For example, locally, I get the expected error:

$ ./python Tools/scripts/reindent.py -r Lib/test/bad_coding.py; echo $?
Lib/test/bad_coding.py: SyntaxError: unknown encoding for 'Lib/test/bad_coding.py': uft-8
0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43662>
_______________________________________

From report at bugs.python.org  Mon Mar 29 17:07:27 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Mar 2021 21:07:27 +0000
Subject: [issue43662] test_tools: test_reindent_file_with_bad_encoding() fails
 on s390x RHEL7 LTO + PGO 3.x
In-Reply-To: <1617049973.14.0.713223722429.issue43662@roundup.psfhosted.org>
Message-ID: <1617052047.93.0.439239847579.issue43662@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Oh. The failure is random:

* 934 green
* 933 red: test_reindent_file_with_bad_encoding failed
* 932 green
* 931 red: test_reindent_file_with_bad_encoding failed
* 930 green
* 929 red: test_reindent_file_with_bad_encoding failed
* 928 green
* (... older builds are all green ...)
* 775 orange
* 774 green
* (... more green builds ...)

This buildbot uses PGO+LTO optimization on RHEL7 with "gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44)". Can it be a compiler issue? Are other buildbots affected?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43662>
_______________________________________

From report at bugs.python.org  Mon Mar 29 17:08:44 2021
From: report at bugs.python.org (Shane Harvey)
Date: Mon, 29 Mar 2021 21:08:44 +0000
Subject: [issue34932] Add macOS TCP_KEEPALIVE to available socket options
In-Reply-To: <1539005890.42.0.545547206417.issue34932@psf.upfronthosting.co.za>
Message-ID: <1617052124.01.0.160921809439.issue34932@roundup.psfhosted.org>


Change by Shane Harvey <shnhrv at gmail.com>:


----------
nosy: +ShaneHarvey
nosy_count: 3.0 -> 4.0
pull_requests: +23829
pull_request: https://github.com/python/cpython/pull/25079

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34932>
_______________________________________

From report at bugs.python.org  Mon Mar 29 17:12:30 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Mar 2021 21:12:30 +0000
Subject: [issue43624] Add underscore as a decimal separator for string
 formatting
In-Reply-To: <1616692747.49.0.677529428018.issue43624@roundup.psfhosted.org>
Message-ID: <1617052350.26.0.529812489852.issue43624@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I'm now confused. Would you mind to give examples of all proposed formats and the expected output?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43624>
_______________________________________

From report at bugs.python.org  Mon Mar 29 17:16:44 2021
From: report at bugs.python.org (Kartik Subbarao)
Date: Mon, 29 Mar 2021 21:16:44 +0000
Subject: [issue43498] "dictionary changed size during iteration" error in
 _ExecutorManagerThread
In-Reply-To: <1615796616.26.0.51182574064.issue43498@roundup.psfhosted.org>
Message-ID: <1617052604.11.0.449485452169.issue43498@roundup.psfhosted.org>


Kartik Subbarao <subbarao at computer.org> added the comment:

I'm seeing the same error with Python 3.9.2 on Fedora 33, with a script that uses ProcessPoolExecutor.

----------
nosy: +kartiksubbarao

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43498>
_______________________________________

From report at bugs.python.org  Mon Mar 29 17:17:00 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Mar 2021 21:17:00 +0000
Subject: [issue43662] test_tools: test_reindent_file_with_bad_encoding() fails
 on s390x RHEL7 LTO + PGO 3.x
In-Reply-To: <1617049973.14.0.713223722429.issue43662@roundup.psfhosted.org>
Message-ID: <1617052620.43.0.454744881621.issue43662@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

We have 4 buildbot workers running RHEL7 and using LTO+PGO optimizations: aarch64, amd64, ppc64le, s390x.

I saw random failures on amd64 and s390x. amd64 failed builds:

* 910: test_reindent_file_with_bad_encoding() failed
* 911: test_reindent_file_with_bad_encoding() failed
* 914: test_reindent_file_with_bad_encoding() failed

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43662>
_______________________________________

From report at bugs.python.org  Mon Mar 29 17:20:23 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Mar 2021 21:20:23 +0000
Subject: [issue43662] test_tools: test_reindent_file_with_bad_encoding() fails
 RHEL7 with LTO
In-Reply-To: <1617049973.14.0.713223722429.issue43662@roundup.psfhosted.org>
Message-ID: <1617052823.19.0.842157524994.issue43662@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

AMD64 RHEL7 LTO 3.x: builds 896 and 900 failed with test_reindent_file_with_bad_encoding(). This worker only uses LTO, it doesn't use PGO.

----------
title: test_tools: test_reindent_file_with_bad_encoding() fails on s390x RHEL7 LTO + PGO 3.x -> test_tools: test_reindent_file_with_bad_encoding() fails RHEL7 with LTO

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43662>
_______________________________________

From report at bugs.python.org  Mon Mar 29 17:24:42 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Mar 2021 21:24:42 +0000
Subject: [issue43662] test_tools: test_reindent_file_with_bad_encoding() fails
 RHEL7 on x86-64 and s390x with GCC 4.8.5 and LTO
In-Reply-To: <1617049973.14.0.713223722429.issue43662@roundup.psfhosted.org>
Message-ID: <1617053082.15.0.2004767623.issue43662@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

s390x RHEL7 LTO 3.x: builds 921, 924 and 925 failed with test_reindent_file_with_bad_encoding().

----------
title: test_tools: test_reindent_file_with_bad_encoding() fails RHEL7 with LTO -> test_tools: test_reindent_file_with_bad_encoding() fails RHEL7 on x86-64 and s390x with GCC 4.8.5 and LTO

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43662>
_______________________________________

From report at bugs.python.org  Mon Mar 29 17:43:18 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Mar 2021 21:43:18 +0000
Subject: [issue43662] test_tools: test_reindent_file_with_bad_encoding() fails
 RHEL7 on x86-64 and s390x with GCC 4.8.5 and LTO
In-Reply-To: <1617049973.14.0.713223722429.issue43662@roundup.psfhosted.org>
Message-ID: <1617054198.42.0.230905006577.issue43662@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

vstinner at python-builder-rhel7$ echo|PYTHONMALLOC=malloc valgrind ./python Tools/scripts/reindent.py 
==26374== Memcheck, a memory error detector
==26374== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==26374== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==26374== Command: ./python Tools/scripts/reindent.py
==26374== 
==26374== Conditional jump or move depends on uninitialised value(s)
==26374==    at 0x4C305ED: __memcmp_sse4_1 (vg_replace_strmem.c:1112)
==26374==    by 0x5D0BCF: get_coding_spec.100964 (tokenizer.c:165)
==26374==    by 0x5D4C1B: check_coding_spec.part.6.100980 (tokenizer.c:214)
==26374==    by 0x5D213A: check_coding_spec (tokenizer.c:212)
==26374==    by 0x5D213A: tok_underflow_file.101007 (tokenizer.c:966)
==26374==    by 0x5D248D: tok_nextc.101010 (tokenizer.c:1031)
==26374==    by 0x5D2C80: tok_get.101023 (tokenizer.c:1213)
==26374==    by 0x5D4632: PyTokenizer_Get (tokenizer.c:1872)
==26374==    by 0x648E4C: _PyPegen_fill_token (pegen.c:633)
==26374==    by 0x6494D9: _PyPegen_expect_token (pegen.c:832)
==26374==    by 0x667497: _tmp_15_rule.137241 (parser.c:19552)
==26374==    by 0x649488: _PyPegen_lookahead (pegen.c:823)
==26374==    by 0x64EC04: compound_stmt_rule.138437 (parser.c:2008)
==26374== 
==26374== Conditional jump or move depends on uninitialised value(s)
==26374==    at 0x5D0BD2: get_coding_spec.100964 (tokenizer.c:165)
==26374==    by 0x5D4C1B: check_coding_spec.part.6.100980 (tokenizer.c:214)
==26374==    by 0x5D213A: check_coding_spec (tokenizer.c:212)
==26374==    by 0x5D213A: tok_underflow_file.101007 (tokenizer.c:966)
==26374==    by 0x5D248D: tok_nextc.101010 (tokenizer.c:1031)
==26374==    by 0x5D2C80: tok_get.101023 (tokenizer.c:1213)
==26374==    by 0x5D4632: PyTokenizer_Get (tokenizer.c:1872)
==26374==    by 0x648E4C: _PyPegen_fill_token (pegen.c:633)
==26374==    by 0x6494D9: _PyPegen_expect_token (pegen.c:832)
==26374==    by 0x667497: _tmp_15_rule.137241 (parser.c:19552)
==26374==    by 0x649488: _PyPegen_lookahead (pegen.c:823)
==26374==    by 0x64EC04: compound_stmt_rule.138437 (parser.c:2008)
==26374==    by 0x64DE4A: statement_rule.138374 (parser.c:1365)
==26374== 
==26374== 
==26374== HEAP SUMMARY:
==26374==     in use at exit: 406,507 bytes in 4,293 blocks
==26374==   total heap usage: 63,558 allocs, 59,265 frees, 9,156,496 bytes allocated
==26374== 
==26374== LEAK SUMMARY:
==26374==    definitely lost: 0 bytes in 0 blocks
==26374==    indirectly lost: 0 bytes in 0 blocks
==26374==      possibly lost: 390,522 bytes in 4,213 blocks
==26374==    still reachable: 15,985 bytes in 80 blocks
==26374==         suppressed: 0 bytes in 0 blocks
==26374== Rerun with --leak-check=full to see details of leaked memory
==26374== 
==26374== Use --track-origins=yes to see where uninitialised values come from
==26374== For lists of detected and suppressed errors, rerun with: -s
==26374== ERROR SUMMARY: 16322 errors from 2 contexts (suppressed: 0 from 0)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43662>
_______________________________________

From report at bugs.python.org  Mon Mar 29 17:53:38 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 29 Mar 2021 21:53:38 +0000
Subject: [issue25643] Python tokenizer rewriting
In-Reply-To: <1447723653.14.0.424824913135.issue25643@psf.upfronthosting.co.za>
Message-ID: <1617054818.61.0.385582710545.issue25643@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +23830
pull_request: https://github.com/python/cpython/pull/25080

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25643>
_______________________________________

From report at bugs.python.org  Mon Mar 29 18:13:28 2021
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 29 Mar 2021 22:13:28 +0000
Subject: [issue38905] venv python reports wrong sys.executable in a subprocess
 on Windows
In-Reply-To: <1574583460.3.0.94905817038.issue38905@roundup.psfhosted.org>
Message-ID: <1617056008.27.0.15484326196.issue38905@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> the Store package, which can only be *executed* from outside its 
> container (we can't load the DLL directly).

The idea I was pondering was to create "python.exe" in the virtual environment as an appexec link to "C:\Program Files\WindowsApps\venvlauncher.exe" and reverse engineer whatever is needed to make CreateProcessW() build the required access token. For example, if it simply checks for the existence of "venvlauncher.exe" in the user's "WindowsApps" directory, then set that as an appexec alias as well.

However, it can't work for a simple reason. For an appexec link, CreateProcessW() reads and executes the target of the link. The original appexec link path is not retained, so there's no way for the "venvlauncher.exe" process to know about the virtual environment.

> PEP 582

"__pypackages__" doesn't seem like a drop-in replacement for virtual environments. The current directory (in the REPL) and script directory have always had precedence over the standard library, except in isolated mode, so "__pypackages__" seems more about providing a directory for Python packages that's neatly separated from the script directory. I presume also that "__pypackages__" would be added to sys.path even in isolated mode, though the PEP makes no mention of it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38905>
_______________________________________

From report at bugs.python.org  Mon Mar 29 18:21:31 2021
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 29 Mar 2021 22:21:31 +0000
Subject: [issue38905] venv python reports wrong sys.executable in a subprocess
 on Windows
In-Reply-To: <1574583460.3.0.94905817038.issue38905@roundup.psfhosted.org>
Message-ID: <1617056491.08.0.778358087955.issue38905@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> "C:\Program Files\WindowsApps\venvlauncher.exe"

The above was supposed to be "C:\Program Files\WindowsApps\Python...\venvlauncher.exe", where "Python..." is the elided name of the package directory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38905>
_______________________________________

From report at bugs.python.org  Mon Mar 29 18:24:52 2021
From: report at bugs.python.org (Terry Davis)
Date: Mon, 29 Mar 2021 22:24:52 +0000
Subject: [issue43624] Add underscore as a decimal separator for string
 formatting
In-Reply-To: <1616692747.49.0.677529428018.issue43624@roundup.psfhosted.org>
Message-ID: <1617056692.32.0.0863086282745.issue43624@roundup.psfhosted.org>


Terry Davis <terry.y.davis at gmail.com> added the comment:

Current behavior:

>>> format(1234.1234, '_f')
'1_234.123400'
>>> format(1234.1234, ',f')
'1,234.123400'

New behavior:
>>> format(1234.1234, ',._f')
'1,234.123_400'
>>> format(1234.1234, '_._f')
'1_234.123_400'
>>> format(1234.1234, '._f')
'1234.123_400'
>>> format(1234.1234, '._4f')
'1234.123_4'
>>> format(1234.1234, '.f')  # still not allowed
'1234.123_4'
>>> format(1234.1234, '_.f')  # still not allowed

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43624>
_______________________________________

From report at bugs.python.org  Mon Mar 29 18:25:43 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Mar 2021 22:25:43 +0000
Subject: [issue43662] test_tools: test_reindent_file_with_bad_encoding() fails
 RHEL7 on x86-64 and s390x with GCC 4.8.5 and LTO
In-Reply-To: <1617049973.14.0.713223722429.issue43662@roundup.psfhosted.org>
Message-ID: <1617056743.96.0.521743842806.issue43662@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

It's a buffer overflow, or at least a crash related to uninitialized bytes. See:
https://github.com/python/cpython/pull/25080#issuecomment-809752737

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43662>
_______________________________________

From report at bugs.python.org  Mon Mar 29 18:38:59 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 29 Mar 2021 22:38:59 +0000
Subject: [issue43660] Segmentation fault when overriding sys.stderr
In-Reply-To: <1617043366.54.0.823715047816.issue43660@roundup.psfhosted.org>
Message-ID: <1617057539.38.0.63650881646.issue43660@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 09b90a037d18f5d4acdf1b14082e57bda78e85d3 by Pablo Galindo in branch 'master':
bpo-43660: Fix crash when displaying exceptions with custom values for sys.stderr (GH-25075)
https://github.com/python/cpython/commit/09b90a037d18f5d4acdf1b14082e57bda78e85d3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43660>
_______________________________________

From report at bugs.python.org  Mon Mar 29 18:39:13 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 29 Mar 2021 22:39:13 +0000
Subject: [issue43660] Segmentation fault when overriding sys.stderr
In-Reply-To: <1617043366.54.0.823715047816.issue43660@roundup.psfhosted.org>
Message-ID: <1617057553.13.0.577907660622.issue43660@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: +23831
pull_request: https://github.com/python/cpython/pull/25083

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43660>
_______________________________________

From report at bugs.python.org  Mon Mar 29 18:39:22 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 29 Mar 2021 22:39:22 +0000
Subject: [issue43660] Segmentation fault when overriding sys.stderr
In-Reply-To: <1617043366.54.0.823715047816.issue43660@roundup.psfhosted.org>
Message-ID: <1617057562.86.0.133649815921.issue43660@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +23832
pull_request: https://github.com/python/cpython/pull/25084

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43660>
_______________________________________

From report at bugs.python.org  Mon Mar 29 18:41:04 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 29 Mar 2021 22:41:04 +0000
Subject: [issue43567] regen.vcxproj cannot regenerate some necessary files
In-Reply-To: <1616238138.44.0.687655765468.issue43567@roundup.psfhosted.org>
Message-ID: <1617057664.46.0.654679231335.issue43567@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> regen.vcxproj is now not capable for the new PEG parse

Hummmm, that file should handle the peg parser already:

https://github.com/python/cpython/blob/09b90a037d18f5d4acdf1b14082e57bda78e85d3/PCbuild/regen.vcxproj#L156-L163

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43567>
_______________________________________

From report at bugs.python.org  Mon Mar 29 18:43:44 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Mar 2021 22:43:44 +0000
Subject: [issue43567] regen.vcxproj cannot regenerate some necessary files
In-Reply-To: <1616238138.44.0.687655765468.issue43567@roundup.psfhosted.org>
Message-ID: <1617057824.91.0.491887814773.issue43567@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

By the way, it would be nice if someone could review my change in this project related to pycore_ast.h ;-) (commit 94faa0724f8cbae6867c491c8e465e35f4fdbfbb) I mean checking if pycore_ast.h is updated as expected.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43567>
_______________________________________

From report at bugs.python.org  Mon Mar 29 18:45:22 2021
From: report at bugs.python.org (Steve Dower)
Date: Mon, 29 Mar 2021 22:45:22 +0000
Subject: [issue43631] Update to OpenSSL 1.1.1k
In-Reply-To: <1616746538.63.0.13329268116.issue43631@roundup.psfhosted.org>
Message-ID: <1617057922.4.0.812517390442.issue43631@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I published the Windows OpenSSL builds and retriggered your PR builds, Christian.

It looks like we should probably bring up the next release for this, if only because that will cause server users to do rebuilds/updates that they may otherwise not. I doubt there are many public-facing servers running on Windows or macOS (most Windows ones let IIS handle TLS anyway, rather than doing it in Python), though Brad may be an exception here ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43631>
_______________________________________

From report at bugs.python.org  Mon Mar 29 18:53:17 2021
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 29 Mar 2021 22:53:17 +0000
Subject: [issue42134] Raise ImportWarning when falling back to find_module()
In-Reply-To: <1603494610.04.0.950789467246.issue42134@roundup.psfhosted.org>
Message-ID: <1617058397.19.0.616775013956.issue42134@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
assignee:  -> brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42134>
_______________________________________

From report at bugs.python.org  Mon Mar 29 18:53:56 2021
From: report at bugs.python.org (Steve Dower)
Date: Mon, 29 Mar 2021 22:53:56 +0000
Subject: [issue38905] venv python reports wrong sys.executable in a subprocess
 on Windows
In-Reply-To: <1617056008.27.0.15484326196.issue38905@roundup.psfhosted.org>
Message-ID: <a8d551f8-d690-7007-6206-8b880d781e66@python.org>


Steve Dower <steve.dower at python.org> added the comment:

> "__pypackages__" doesn't seem like a drop-in replacement for virtual environments.
Right, it's not. But if enough people adapt their workflows to use 
[something like] it rather than relying on having a local copy of 
python.exe in order to launch, apps that currently assume that their 
subprocesses don't have their own children would be correct again.

If it was a drop-in replacement, we'd have dropped it in already. All 
the drop in replacements come with similar issues, which is why we need 
to change things more broadly in order to handle all the use cases that 
exist.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38905>
_______________________________________

From report at bugs.python.org  Mon Mar 29 19:03:24 2021
From: report at bugs.python.org (miss-islington)
Date: Mon, 29 Mar 2021 23:03:24 +0000
Subject: [issue43660] Segmentation fault when overriding sys.stderr
In-Reply-To: <1617043366.54.0.823715047816.issue43660@roundup.psfhosted.org>
Message-ID: <1617059004.46.0.124080870989.issue43660@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ba7f8638f93b5d999b25d8556ca19bdc2e12f359 by Miss Islington (bot) in branch '3.8':
bpo-43660: Fix crash when displaying exceptions with custom values for sys.stderr (GH-25075)
https://github.com/python/cpython/commit/ba7f8638f93b5d999b25d8556ca19bdc2e12f359


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43660>
_______________________________________

From report at bugs.python.org  Mon Mar 29 19:05:01 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 29 Mar 2021 23:05:01 +0000
Subject: [issue43660] Segmentation fault when overriding sys.stderr
In-Reply-To: <1617043366.54.0.823715047816.issue43660@roundup.psfhosted.org>
Message-ID: <1617059101.18.0.739380322936.issue43660@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +23833
pull_request: https://github.com/python/cpython/pull/25085

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43660>
_______________________________________

From report at bugs.python.org  Mon Mar 29 19:22:30 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 29 Mar 2021 23:22:30 +0000
Subject: [issue43567] regen.vcxproj cannot regenerate some necessary files
In-Reply-To: <1616238138.44.0.687655765468.issue43567@roundup.psfhosted.org>
Message-ID: <1617060150.04.0.457320787535.issue43567@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

I've found build.bat --regen unreliable myself. I went over it with Steve and one issue that came up is that it uses the python.exe that is built to run the code generation scripts; OTOH on Linux/Mac these scripts are run using a suitable pre-existing Python binary, e.g. a recent enough system Python. (However, the frozen files require a binary (_freeze_importlib).

It will take some time to refactor things so that this is more usable.

Perhaps instead of (or in addition to) doing everything via .vcxproj files, we could have a simple(r) regen.bat script that runs all the regen scripts (or at least the non-freeze ones) using the system Python?

FWIW my own issues weren't with the parser, they were with regenerating opcode.h and opcode_targets.h.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43567>
_______________________________________

From report at bugs.python.org  Mon Mar 29 19:24:24 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 29 Mar 2021 23:24:24 +0000
Subject: [issue43660] Segmentation fault when overriding sys.stderr
In-Reply-To: <1617043366.54.0.823715047816.issue43660@roundup.psfhosted.org>
Message-ID: <1617060264.14.0.456140531854.issue43660@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 2f01c562be913004e1d46fc02705c51b81638d67 by Pablo Galindo in branch '3.7':
[3.7] bpo-43660: Fix crash when displaying exceptions with custom values for sys.stderr (GH-25075). (GH-25085)
https://github.com/python/cpython/commit/2f01c562be913004e1d46fc02705c51b81638d67


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43660>
_______________________________________

From report at bugs.python.org  Mon Mar 29 19:24:37 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 29 Mar 2021 23:24:37 +0000
Subject: [issue43660] Segmentation fault when overriding sys.stderr
In-Reply-To: <1617043366.54.0.823715047816.issue43660@roundup.psfhosted.org>
Message-ID: <1617060277.13.0.110271885044.issue43660@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset ff4715a7332123713de9920e724bb6c412d8ccef by Miss Islington (bot) in branch '3.9':
bpo-43660: Fix crash when displaying exceptions with custom values for sys.stderr (GH-25075) (GH-25083)
https://github.com/python/cpython/commit/ff4715a7332123713de9920e724bb6c412d8ccef


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43660>
_______________________________________

From report at bugs.python.org  Mon Mar 29 19:32:53 2021
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 29 Mar 2021 23:32:53 +0000
Subject: [issue43631] Update to OpenSSL 1.1.1k
In-Reply-To: <1616746538.63.0.13329268116.issue43631@roundup.psfhosted.org>
Message-ID: <1617060773.97.0.716428316415.issue43631@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Thanks!

All tests are passing, but macOS is still using OpenSSL 1.1.1j.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43631>
_______________________________________

From report at bugs.python.org  Mon Mar 29 19:45:00 2021
From: report at bugs.python.org (Steve Dower)
Date: Mon, 29 Mar 2021 23:45:00 +0000
Subject: [issue43652] Upgrade Windows tcl/tk to 8.6.11
In-Reply-To: <1617001631.71.0.115330422511.issue43652@roundup.psfhosted.org>
Message-ID: <1617061500.94.0.498816305214.issue43652@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I also need to pull the Tcl and Tk sources into our cpython-source-deps repository, run a signed build, and put the binaries into the cpython-bin-deps repository. I'll get that started tonight, but probably won't finish it until tomorrow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43652>
_______________________________________

From report at bugs.python.org  Mon Mar 29 19:50:17 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 29 Mar 2021 23:50:17 +0000
Subject: [issue43660] Segmentation fault when overriding sys.stderr
In-Reply-To: <1617043366.54.0.823715047816.issue43660@roundup.psfhosted.org>
Message-ID: <1617061817.71.0.935300265263.issue43660@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/issue43660>
_______________________________________

From report at bugs.python.org  Mon Mar 29 20:00:40 2021
From: report at bugs.python.org (miss-islington)
Date: Tue, 30 Mar 2021 00:00:40 +0000
Subject: [issue43631] Update to OpenSSL 1.1.1k
In-Reply-To: <1616746538.63.0.13329268116.issue43631@roundup.psfhosted.org>
Message-ID: <1617062440.98.0.823113985055.issue43631@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a54fc683f237d8f0b6e999a63aa9b8c0a45b7fef by Christian Heimes in branch 'master':
bpo-43631: Update to OpenSSL 1.1.1k (GH-25024)
https://github.com/python/cpython/commit/a54fc683f237d8f0b6e999a63aa9b8c0a45b7fef


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43631>
_______________________________________

From report at bugs.python.org  Mon Mar 29 20:03:35 2021
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 30 Mar 2021 00:03:35 +0000
Subject: [issue43631] Update to OpenSSL 1.1.1k
In-Reply-To: <1616746538.63.0.13329268116.issue43631@roundup.psfhosted.org>
Message-ID: <1617062615.11.0.298196421636.issue43631@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +23834
pull_request: https://github.com/python/cpython/pull/25088

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43631>
_______________________________________

From report at bugs.python.org  Mon Mar 29 20:06:11 2021
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 30 Mar 2021 00:06:11 +0000
Subject: [issue43631] Update to OpenSSL 1.1.1k
In-Reply-To: <1616746538.63.0.13329268116.issue43631@roundup.psfhosted.org>
Message-ID: <1617062771.88.0.67221518205.issue43631@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +23835
pull_request: https://github.com/python/cpython/pull/25089

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43631>
_______________________________________

From report at bugs.python.org  Mon Mar 29 20:08:11 2021
From: report at bugs.python.org (Steve Dower)
Date: Tue, 30 Mar 2021 00:08:11 +0000
Subject: [issue43652] Upgrade Windows tcl/tk to 8.6.11
In-Reply-To: <1617001631.71.0.115330422511.issue43652@roundup.psfhosted.org>
Message-ID: <1617062891.23.0.0742234768944.issue43652@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Turns out I did get it done, so you should be able to update the references you find in the PCbuild directory and get a build.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43652>
_______________________________________

From report at bugs.python.org  Mon Mar 29 20:20:12 2021
From: report at bugs.python.org (William Pickard)
Date: Tue, 30 Mar 2021 00:20:12 +0000
Subject: [issue43661] api-ms-win-core-path-l1-1.0.dll,
 redux of 40740 (which has since been closed)
In-Reply-To: <1617044884.9.0.569070921495.issue43661@roundup.psfhosted.org>
Message-ID: <1617063612.17.0.85676844853.issue43661@roundup.psfhosted.org>


William Pickard <lollol222gg at gmail.com> added the comment:

Python 3.9 does not support Windows 7, it's explicitly stated in the release notes of 3.9.0

----------
nosy: +WildCard65

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43661>
_______________________________________

From report at bugs.python.org  Mon Mar 29 20:23:55 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 30 Mar 2021 00:23:55 +0000
Subject: [issue43567] regen.vcxproj cannot regenerate some necessary files
In-Reply-To: <1617060150.04.0.457320787535.issue43567@roundup.psfhosted.org>
Message-ID: <CAP7+vJK95c+Q92WyDDxCk9ztGwohjyxSUecM3ZTnW22JSTkPGg@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

Workaround:

For opcode.py changes, I can probably use the following strategy:

- build.bat
- Add new opcode to opcode.py
- build.bat --regen
- build.bat
- Make changes to compile.c and ceval.c to implement new opcode
- build.bat

For the parser perhaps you can adopt a similar strategy, where you first
add new tokens and get the code generation working?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43567>
_______________________________________

From report at bugs.python.org  Mon Mar 29 20:43:44 2021
From: report at bugs.python.org (Ned Deily)
Date: Tue, 30 Mar 2021 00:43:44 +0000
Subject: [issue35930] Raising an exception raised in a "future" instance will
 create reference cycles
In-Reply-To: <1549549530.21.0.398741964575.issue35930@roundup.psfhosted.org>
Message-ID: <1617065024.09.0.744846410209.issue35930@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

@jcea, I see you have created backports for 3.7 and 3.6 as well. Those release as in their security-fix-only phase of their life cycles. This doesn't seem like a security issue but am I missing something?

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35930>
_______________________________________

From report at bugs.python.org  Mon Mar 29 20:44:27 2021
From: report at bugs.python.org (Ned Deily)
Date: Tue, 30 Mar 2021 00:44:27 +0000
Subject: [issue35930] Raising an exception raised in a "future" instance will
 create reference cycles
In-Reply-To: <1549549530.21.0.398741964575.issue35930@roundup.psfhosted.org>
Message-ID: <1617065067.24.0.292022756854.issue35930@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

"Those releases are in their"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35930>
_______________________________________

From report at bugs.python.org  Mon Mar 29 20:55:31 2021
From: report at bugs.python.org (Jiaxin Peng)
Date: Tue, 30 Mar 2021 00:55:31 +0000
Subject: [issue43567] regen.vcxproj cannot regenerate some necessary files
In-Reply-To: <1616238138.44.0.687655765468.issue43567@roundup.psfhosted.org>
Message-ID: <1617065731.38.0.195508263322.issue43567@roundup.psfhosted.org>


Jiaxin Peng <pjx206 at 163.com> added the comment:

I did:
- modified Grammar/python.gram
    - added new operator to compare_op_bitwise_or_pair
- added corresponding token to Grammer/Tokens
- build.bar --regen
- not having Include/Python-ast.h and Python/Python-ast.c

I agree that a regen.bat that using a system python is better solution. regen.vcxproj is confusing.

----------
nosy:  -anthonypjshaw, lys.nikolaou, pablogsal, paul.moore, steve.dower, tim.golden, vstinner, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43567>
_______________________________________

From report at bugs.python.org  Mon Mar 29 22:51:39 2021
From: report at bugs.python.org (Neil Schemenauer)
Date: Tue, 30 Mar 2021 02:51:39 +0000
Subject: [issue37448] obmalloc: radix tree for tracking arena address ranges
In-Reply-To: <1561849702.35.0.724599328196.issue37448@roundup.psfhosted.org>
Message-ID: <1617072699.81.0.5506382949.issue37448@roundup.psfhosted.org>


Neil Schemenauer <nas-python at arctrix.com> added the comment:


New changeset 85b6b70589c187639aeebc560d67e9cc04abb4d8 by Neil Schemenauer in branch 'master':
bpo-37448: Use radix tree for pymalloc address_in_range(). (GH-14474)
https://github.com/python/cpython/commit/85b6b70589c187639aeebc560d67e9cc04abb4d8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37448>
_______________________________________

From report at bugs.python.org  Mon Mar 29 22:53:53 2021
From: report at bugs.python.org (Neil Schemenauer)
Date: Tue, 30 Mar 2021 02:53:53 +0000
Subject: [issue37448] obmalloc: radix tree for tracking arena address ranges
In-Reply-To: <1561849702.35.0.724599328196.issue37448@roundup.psfhosted.org>
Message-ID: <1617072833.24.0.1543990378.issue37448@roundup.psfhosted.org>


Change by Neil Schemenauer <nas-python at arctrix.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37448>
_______________________________________

From report at bugs.python.org  Mon Mar 29 22:55:43 2021
From: report at bugs.python.org (Neil Schemenauer)
Date: Tue, 30 Mar 2021 02:55:43 +0000
Subject: [issue43593] pymalloc is not aware of Memory Tagging Extension (MTE)
 and crashes
In-Reply-To: <1616419787.13.0.506382582675.issue43593@roundup.psfhosted.org>
Message-ID: <1617072943.48.0.717001836088.issue43593@roundup.psfhosted.org>


Neil Schemenauer <nas-python at arctrix.com> added the comment:

I've merged PR 14474 so you can just test with an up-to-date "main" branch and see if that fixes the problem.  I would expect it should fix the problem since with the radix tree arena tracking, no memory unsanitary behaviour remains.

----------
nosy: +nascheme

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43593>
_______________________________________

From report at bugs.python.org  Mon Mar 29 23:04:22 2021
From: report at bugs.python.org (David Bolen)
Date: Tue, 30 Mar 2021 03:04:22 +0000
Subject: [issue37945] [Windows]
 test_locale.TestMiscellaneous.test_getsetlocale_issue1813() fails
In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org>
Message-ID: <1617073462.63.0.253599328856.issue37945@roundup.psfhosted.org>


David Bolen <db3l.net at gmail.com> added the comment:

I don't have much of a horse in the race, but since the test has historically been skipped on Windows, and the test hasn't and doesn't work on Windows, modifications to restore the skip behavior seem reasonable to me.  The trigger for this issue was Windows adding support for underscore in locale names (like tr_TR) so the test began executing.  But it's not a regression or new issue, it's just existing reality becoming exposed.

The user machine and buildbot discrepancy can be attributed to version differences, as the buildbot hadn't yet received the same underscore locale name support.

I'd be fine with removing the test entirely - always skipping on a failure just seems pointless.  Then again, issue1813 created the test for a purpose on other systems, though even back then it appears it was complicated.  Leaving the test but skipping known failing systems (I guess at least Windows and OpenBSD) might be slightly less intrusive of a change, assuming the test is still serving a purpose elsewhere.

Separately, there's a lot of useful/interesting detail here which could inform any eventual normalization changes on Windows, should the underlying issue be deemed worthy of addressing.  But that seems like something that could be a distinct operation from clearing up the test issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37945>
_______________________________________

From report at bugs.python.org  Mon Mar 29 23:13:14 2021
From: report at bugs.python.org (Doug Richardson)
Date: Tue, 30 Mar 2021 03:13:14 +0000
Subject: [issue37945] [Windows]
 test_locale.TestMiscellaneous.test_getsetlocale_issue1813() fails
In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org>
Message-ID: <1617073994.68.0.586095022364.issue37945@roundup.psfhosted.org>


Change by Doug Richardson <git at rekt.email>:


----------
nosy:  -drichardson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37945>
_______________________________________

From report at bugs.python.org  Mon Mar 29 23:25:05 2021
From: report at bugs.python.org (Neil Schemenauer)
Date: Tue, 30 Mar 2021 03:25:05 +0000
Subject: [issue37368] test_asyncio: test_create_server_ssl_match_failed()
 failed on s390x SLES 3.x and logged an unraisable exception
In-Reply-To: <1561151330.27.0.514257001535.issue37368@roundup.psfhosted.org>
Message-ID: <1617074705.32.0.539953619372.issue37368@roundup.psfhosted.org>


Neil Schemenauer <nas-python at arctrix.com> added the comment:

Seems this failure might be back.  At least, the traceback looks quite similar to me.

The buildbot failed with this:

heads/master:85b6b70589, Mar 29 2021, 22:53:15

0:05:26 load avg: 3.95 [426/427] test_tokenize passed (56.0 sec) -- running: test_asyncio (44.8 sec)
0:05:35 load avg: 3.34 [427/427/1] test_asyncio failed (env changed) (54.1 sec)
Warning -- Unraisable exception
Exception ignored in: <function _SSLProtocolTransport.__del__ at 0x3ffa8ecedb0>
Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel8-z/build/Lib/asyncio/sslproto.py", line 321, in __del__
    self.close()
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel8-z/build/Lib/asyncio/sslproto.py", line 316, in close
    self._ssl_protocol._start_shutdown()
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel8-z/build/Lib/asyncio/sslproto.py", line 590, in _start_shutdown
    self._abort()
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel8-z/build/Lib/asyncio/sslproto.py", line 731, in _abort
    self._transport.abort()
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel8-z/build/Lib/asyncio/selector_events.py", line 680, in abort
    self._force_close(None)
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel8-z/build/Lib/asyncio/selector_events.py", line 731, in _force_close
    self._loop.call_soon(self._call_connection_lost, exc)
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel8-z/build/Lib/asyncio/base_events.py", line 745, in call_soon
    self._check_closed()
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel8-z/build/Lib/asyncio/base_events.py", line 510, in _check_closed
    raise RuntimeError('Event loop is closed')
RuntimeError: Event loop is closed

----------
nosy: +nascheme
resolution: out of date -> 
stage: resolved -> 
status: closed -> open
versions: +Python 3.10 -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37368>
_______________________________________

From report at bugs.python.org  Mon Mar 29 23:25:36 2021
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 30 Mar 2021 03:25:36 +0000
Subject: [issue33164] Blake 2 module update
In-Reply-To: <1558585970.68.0.308420136648.issue33164@roundup.psfhosted.org>
Message-ID: <1617074736.93.0.419417894932.issue33164@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset 068ebf9729d440cef03e4c57e3db83c851146172 by Inada Naoki in branch 'master':
bpo-33164: blake2: Fix Coverity scan (GH-25060)
https://github.com/python/cpython/commit/068ebf9729d440cef03e4c57e3db83c851146172


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33164>
_______________________________________

From report at bugs.python.org  Mon Mar 29 23:25:54 2021
From: report at bugs.python.org (miss-islington)
Date: Tue, 30 Mar 2021 03:25:54 +0000
Subject: [issue33164] Blake 2 module update
In-Reply-To: <1558585970.68.0.308420136648.issue33164@roundup.psfhosted.org>
Message-ID: <1617074754.32.0.694485199678.issue33164@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: +23836
pull_request: https://github.com/python/cpython/pull/25091

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33164>
_______________________________________

From report at bugs.python.org  Mon Mar 29 23:47:15 2021
From: report at bugs.python.org (miss-islington)
Date: Tue, 30 Mar 2021 03:47:15 +0000
Subject: [issue33164] Blake 2 module update
In-Reply-To: <1558585970.68.0.308420136648.issue33164@roundup.psfhosted.org>
Message-ID: <1617076035.1.0.978548107613.issue33164@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 6af3a940ca827d9a59e34271e4c97d7ec7b56584 by Miss Islington (bot) in branch '3.8':
bpo-33164: blake2: Fix Coverity scan (GH-25060)
https://github.com/python/cpython/commit/6af3a940ca827d9a59e34271e4c97d7ec7b56584


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33164>
_______________________________________

From report at bugs.python.org  Tue Mar 30 00:14:38 2021
From: report at bugs.python.org (miss-islington)
Date: Tue, 30 Mar 2021 04:14:38 +0000
Subject: [issue33164] Blake 2 module update
In-Reply-To: <1558585970.68.0.308420136648.issue33164@roundup.psfhosted.org>
Message-ID: <1617077678.58.0.0074641035102.issue33164@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +23837
pull_request: https://github.com/python/cpython/pull/25092

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33164>
_______________________________________

From report at bugs.python.org  Tue Mar 30 00:34:43 2021
From: report at bugs.python.org (Xinmeng Xia)
Date: Tue, 30 Mar 2021 04:34:43 +0000
Subject: [issue43663] Python interpreter works abnormally after interrupting
 logging.config.fileConfig()
Message-ID: <1617078883.29.0.318397860885.issue43663@roundup.psfhosted.org>


New submission from Xinmeng Xia <xiaxm at smail.nju.edu.cn>:

Python interpreter cannot work well and report errors  after interrupting logging.config.fileConfig()

Reproduce step:
1. type  python3 in console
2. type  import logging.config; logging.config.fileConfig({2,2,'sdf'},'') 
3. ctrl C
4. type 1/0 

-------------------------------------------------------------------------------
Python 3.9.2 (default, Mar 12 2021, 15:08:35) 
[GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 1/0
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ZeroDivisionError: division by zero
>>> import logging.config
>>> logging.config.fileConfig({2,2,'sdf'},'') 
^C>>> 1/0
>>> 
--------------------------------------------------------------------------------


Expected result: 1/0 will return a ZeroDivisionError after interrupting " logging.config.fileConfig({2,2,'sdf'},'') "
Actual result: Nothing output

Python 3.9.2, Ubuntu 16.04

----------
components: Library (Lib)
messages: 389788
nosy: xxm
priority: normal
severity: normal
status: open
title: Python interpreter works abnormally after interrupting logging.config.fileConfig()
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43663>
_______________________________________

From report at bugs.python.org  Tue Mar 30 00:35:44 2021
From: report at bugs.python.org (Xinmeng Xia)
Date: Tue, 30 Mar 2021 04:35:44 +0000
Subject: [issue43664] Long computations in pdb.run() lead to segfault
Message-ID: <1617078944.41.0.741182615703.issue43664@roundup.psfhosted.org>


New submission from Xinmeng Xia <xiaxm at smail.nju.edu.cn>:

Long computations in pdb.run() lead to interpreter crashes.

Crash example
=======================================================
Python 3.9.2 (default, Mar 12 2021, 15:08:35) 
[GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pdb
>>> pdb.run("1+2"*1000000)
Segmentation fault (core dumped)
=======================================================

Environment:
Ubuntu 16.04, Python 3.9.2, Python 3.10.0a6
Mac OS Big Sur 11.2.3, Python 3.91, Python 3.10.0a2

----------
components: Library (Lib)
messages: 389789
nosy: xxm
priority: normal
severity: normal
status: open
title: Long computations in pdb.run() lead to segfault
type: crash
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43664>
_______________________________________

From report at bugs.python.org  Tue Mar 30 00:36:47 2021
From: report at bugs.python.org (miss-islington)
Date: Tue, 30 Mar 2021 04:36:47 +0000
Subject: [issue33164] Blake 2 module update
In-Reply-To: <1558585970.68.0.308420136648.issue33164@roundup.psfhosted.org>
Message-ID: <1617079007.36.0.000868016192007.issue33164@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 05429c917c23f735b07ac4c60af20e57aad742fc by Miss Islington (bot) in branch '3.9':
bpo-33164: blake2: Fix Coverity scan (GH-25060)
https://github.com/python/cpython/commit/05429c917c23f735b07ac4c60af20e57aad742fc


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33164>
_______________________________________

From report at bugs.python.org  Tue Mar 30 01:04:14 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 30 Mar 2021 05:04:14 +0000
Subject: [issue43654] IDLE: Applying settings disables tab completion
In-Reply-To: <1617007235.89.0.0831829954955.issue43654@roundup.psfhosted.org>
Message-ID: <1617080654.19.0.835694241816.issue43654@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Investigation of this issue is complicated by the fact that the editor test widgets are wrapped by multicall.MulticallCreator.  It intercepts bind and event method calls (other than event_generate) for user pseudoevents.  It keeps its own map of pseudoevent names to handler and key sequences instead of passing the information on to tk.

The custom entry for "<<autocomplete>>" is the same,
 [<bound method AutoComplete.autocomplete_event of <idlelib.autocomplete.AutoComplete object at 0x00000209DA4FBD20>>, [(0, 0, 'Tab')]]
both before deactivate_... and after activate_... .

I determined this by adding calls like the following
          print('ei5 ', instance.text.event_info('<<autocomplete>>'))
and adding the following to the event_info(virtual) override.
          print('mei', virtual, self.__eventinfo.get(virtual))

I will next look at the custom binding data that should map keys to event handlers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43654>
_______________________________________

From report at bugs.python.org  Tue Mar 30 02:22:51 2021
From: report at bugs.python.org (miss-islington)
Date: Tue, 30 Mar 2021 06:22:51 +0000
Subject: [issue43637] winreg: SetValueEx leaks memory if PySys_Audit fails
In-Reply-To: <1616832991.07.0.159084299457.issue43637@roundup.psfhosted.org>
Message-ID: <1617085371.86.0.0881512244854.issue43637@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: +23838
pull_request: https://github.com/python/cpython/pull/25093

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43637>
_______________________________________

From report at bugs.python.org  Tue Mar 30 02:22:43 2021
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 30 Mar 2021 06:22:43 +0000
Subject: [issue43637] winreg: SetValueEx leaks memory if PySys_Audit fails
In-Reply-To: <1616832991.07.0.159084299457.issue43637@roundup.psfhosted.org>
Message-ID: <1617085363.8.0.31088381429.issue43637@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:


New changeset dfeec347f21b86879ba8f27f567bb275b243f1bc by Zackery Spytz in branch 'master':
bpo-43637: Fix a possible memory leak in winreg.SetValueEx() (GH-25038)
https://github.com/python/cpython/commit/dfeec347f21b86879ba8f27f567bb275b243f1bc


----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43637>
_______________________________________

From report at bugs.python.org  Tue Mar 30 02:23:01 2021
From: report at bugs.python.org (miss-islington)
Date: Tue, 30 Mar 2021 06:23:01 +0000
Subject: [issue43637] winreg: SetValueEx leaks memory if PySys_Audit fails
In-Reply-To: <1616832991.07.0.159084299457.issue43637@roundup.psfhosted.org>
Message-ID: <1617085381.6.0.0967330808987.issue43637@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +23839
pull_request: https://github.com/python/cpython/pull/25094

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43637>
_______________________________________

From report at bugs.python.org  Tue Mar 30 03:07:59 2021
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 30 Mar 2021 07:07:59 +0000
Subject: [issue33164] Blake 2 module update
In-Reply-To: <1558585970.68.0.308420136648.issue33164@roundup.psfhosted.org>
Message-ID: <1617088079.42.0.703802170236.issue33164@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/issue33164>
_______________________________________

From report at bugs.python.org  Tue Mar 30 03:12:48 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Mar 2021 07:12:48 +0000
Subject: [issue43662] test_tools: test_reindent_file_with_bad_encoding() fails
 RHEL7 on x86-64 and s390x with GCC 4.8.5 and LTO
In-Reply-To: <1617049973.14.0.713223722429.issue43662@roundup.psfhosted.org>
Message-ID: <1617088368.45.0.0773358575587.issue43662@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

This issue should be fixed by:

commit 92a02c1f7e2dcdc62913a4236589e7e5d96172b9
Author: Pablo Galindo <Pablogsal at gmail.com>
Date:   Tue Mar 30 00:24:49 2021 +0100

    Fix tokenizer error when raw decoding null bytes (GH-25080)

The fix is the usage of strlen() instead of "tok->end - tok->cur" to compute the line length.

> https://buildbot.python.org/all/#/builders/244/builds/931

The latest 6 builds are successful. I close the issue.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43662>
_______________________________________

From report at bugs.python.org  Tue Mar 30 03:17:59 2021
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 30 Mar 2021 07:17:59 +0000
Subject: [issue43656] StackSummary.format fails if str(value) fails
In-Reply-To: <1617010609.77.0.749976985588.issue43656@roundup.psfhosted.org>
Message-ID: <1617088679.43.0.986348402145.issue43656@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
nosy: +iritkatriel

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43656>
_______________________________________

From report at bugs.python.org  Tue Mar 30 03:20:32 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 30 Mar 2021 07:20:32 +0000
Subject: [issue43656] StackSummary.format fails if str(value) fails
In-Reply-To: <1617010609.77.0.749976985588.issue43656@roundup.psfhosted.org>
Message-ID: <1617088832.73.0.304701602136.issue43656@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Why str() is called at all? Would not be better to use repr()?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43656>
_______________________________________

From report at bugs.python.org  Tue Mar 30 03:24:01 2021
From: report at bugs.python.org (Michael Felt)
Date: Tue, 30 Mar 2021 07:24:01 +0000
Subject: [issue43659] AIX: test_curses crashes buildbot
In-Reply-To: <1617040273.92.0.487968447995.issue43659@roundup.psfhosted.org>
Message-ID: <1617089041.44.0.686546650478.issue43659@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

my default TERM=xterm

I'll also use 'ansi'

The filenames will be ${TERM}.err and ${TERM}.out

for TERM in xterm ansi; do
./python -m test -vuall test_curses 2>${TERM}.err >${TERM}.out
done

After TERM=ansi - my terminal is in raw mode (i.e.,
$ stty sane ^J

needed).

----------
Added file: https://bugs.python.org/file49917/issue43659.zip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43659>
_______________________________________

From report at bugs.python.org  Tue Mar 30 03:25:41 2021
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 30 Mar 2021 07:25:41 +0000
Subject: [issue43510] PEP 597: Implemente encoding="locale" option and
 EncodingWarning
In-Reply-To: <1615868389.17.0.260147645451.issue43510@roundup.psfhosted.org>
Message-ID: <1617089141.72.0.718604037668.issue43510@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

I created bpo-43651 to track fixing EncodingError in Python stdlibs.
I close this issue for now.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43510>
_______________________________________

From report at bugs.python.org  Tue Mar 30 03:26:30 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Mar 2021 07:26:30 +0000
Subject: [issue43651] PEP 597: Fix EncodingError
Message-ID: <1617089190.12.0.248832009238.issue43651@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43651>
_______________________________________

From report at bugs.python.org  Tue Mar 30 03:26:54 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Mar 2021 07:26:54 +0000
Subject: [issue43651] PEP 597: Fix EncodingWarning warnings in the Python
 stdlib
Message-ID: <1617089214.14.0.707049454525.issue43651@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: PEP 597: Fix EncodingError -> PEP 597: Fix EncodingWarning warnings in the Python stdlib

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43651>
_______________________________________

From report at bugs.python.org  Tue Mar 30 03:30:31 2021
From: report at bugs.python.org (Michael Felt)
Date: Tue, 30 Mar 2021 07:30:31 +0000
Subject: [issue43665] AIX: test_importlib regression (ENV change)
Message-ID: <1617089431.51.0.0013168061581.issue43665@roundup.psfhosted.org>


New submission from Michael Felt <aixtools at felt.demon.nl>:

Since issue43517 test_importlib 'fails' (bot status) with ENV_CHANGED.

The core dump is caused by SIGTRAP. I need help to learn how to stop the core dump from being cleaned up so I can load it into dbx and hopefully understand/learn with sub-test is actually having issues.

e.g., see https://buildbot.python.org/all/#/builders/438/builds/1031/steps/5/logs/stdio for current bot exit status

Thx for assistance.

----------
components: Tests
messages: 389797
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: AIX: test_importlib regression (ENV change)
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43665>
_______________________________________

From report at bugs.python.org  Tue Mar 30 03:40:06 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Mar 2021 07:40:06 +0000
Subject: [issue43665] AIX: test_importlib regression (ENV change)
In-Reply-To: <1617089431.51.0.0013168061581.issue43665@roundup.psfhosted.org>
Message-ID: <1617090006.69.0.157120669533.issue43665@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

A core dump is a very bad sign of health.

Can you please try to bisect which test is causing the segfault using bisect_cmd? Try the command:

./python -m test.bisect_cmd -o bisect --fail-env-changed test_importlib

The command should takes 10-60 minutes, and you should see the number of tests decreasing. I hope that at the end, the command will identify a single method triggering the crash.

At the end, the create "bisect" file contains the test methods causing the bug.

Then you can re-run tests with:

./python -m test --fail-env-changed test_importlib --matchfile=bisect


> The core dump is caused by SIGTRAP. I need help to learn how to stop the core dump from being cleaned up so I can load it into dbx and hopefully understand/learn with sub-test is actually having issues.

You can re-run the test without libregrtest by running it directly. Example:

./python -m test.test_importlib test_spec.Frozen_ModuleSpecMethodsTests.test_reload -v

It should create a core dump in the current directory, or you run the command in your favorite debugger.


My notes on debugging a Python crash: https://pythondev.readthedocs.io/debug_tools.html#core-dump

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43665>
_______________________________________

From report at bugs.python.org  Tue Mar 30 03:49:32 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 30 Mar 2021 07:49:32 +0000
Subject: [issue43659] AIX: test_curses crashes buildbot
In-Reply-To: <1617040273.92.0.487968447995.issue43659@roundup.psfhosted.org>
Message-ID: <1617090572.56.0.998044107269.issue43659@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/issue43659>
_______________________________________

From report at bugs.python.org  Tue Mar 30 03:50:28 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 30 Mar 2021 07:50:28 +0000
Subject: [issue43659] AIX: test_curses crashes buildbot
In-Reply-To: <1617040273.92.0.487968447995.issue43659@roundup.psfhosted.org>
Message-ID: <1617090628.91.0.77627162441.issue43659@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution: fixed -> 
stage: resolved -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43659>
_______________________________________

From report at bugs.python.org  Tue Mar 30 03:52:23 2021
From: report at bugs.python.org (miss-islington)
Date: Tue, 30 Mar 2021 07:52:23 +0000
Subject: [issue43637] winreg: SetValueEx leaks memory if PySys_Audit fails
In-Reply-To: <1616832991.07.0.159084299457.issue43637@roundup.psfhosted.org>
Message-ID: <1617090743.7.0.539272350823.issue43637@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset f79577ddbd7c87b6cc1810e98ee4eaca7ae50699 by Miss Islington (bot) in branch '3.9':
bpo-43637: Fix a possible memory leak in winreg.SetValueEx() (GH-25038)
https://github.com/python/cpython/commit/f79577ddbd7c87b6cc1810e98ee4eaca7ae50699


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43637>
_______________________________________

From report at bugs.python.org  Tue Mar 30 03:52:23 2021
From: report at bugs.python.org (miss-islington)
Date: Tue, 30 Mar 2021 07:52:23 +0000
Subject: [issue43637] winreg: SetValueEx leaks memory if PySys_Audit fails
In-Reply-To: <1616832991.07.0.159084299457.issue43637@roundup.psfhosted.org>
Message-ID: <1617090743.81.0.0578670439884.issue43637@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 5486b105a4c5de840c24776c726eeac2a8dc973c by Miss Islington (bot) in branch '3.8':
bpo-43637: Fix a possible memory leak in winreg.SetValueEx() (GH-25038)
https://github.com/python/cpython/commit/5486b105a4c5de840c24776c726eeac2a8dc973c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43637>
_______________________________________

From report at bugs.python.org  Tue Mar 30 03:52:23 2021
From: report at bugs.python.org (miss-islington)
Date: Tue, 30 Mar 2021 07:52:23 +0000
Subject: [issue43637] winreg: SetValueEx leaks memory if PySys_Audit fails
In-Reply-To: <1616832991.07.0.159084299457.issue43637@roundup.psfhosted.org>
Message-ID: <1617090743.7.0.539272350823.issue43637@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset f79577ddbd7c87b6cc1810e98ee4eaca7ae50699 by Miss Islington (bot) in branch '3.9':
bpo-43637: Fix a possible memory leak in winreg.SetValueEx() (GH-25038)
https://github.com/python/cpython/commit/f79577ddbd7c87b6cc1810e98ee4eaca7ae50699


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43637>
_______________________________________

From report at bugs.python.org  Tue Mar 30 03:52:34 2021
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 30 Mar 2021 07:52:34 +0000
Subject: [issue43637] winreg: SetValueEx leaks memory if PySys_Audit fails
In-Reply-To: <1616832991.07.0.159084299457.issue43637@roundup.psfhosted.org>
Message-ID: <1617090754.08.0.683009260434.issue43637@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43637>
_______________________________________

From report at bugs.python.org  Tue Mar 30 04:03:44 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 30 Mar 2021 08:03:44 +0000
Subject: [issue43659] AIX: test_curses crashes buildbot
In-Reply-To: <1617040273.92.0.487968447995.issue43659@roundup.psfhosted.org>
Message-ID: <1617091424.75.0.692642671318.issue43659@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you. I see that 7 tests are failed (test_background, test_color_attrs, test_color_content, test_getch, test_getstr, test_init_pair, test_insert_delete) and test_output_string perhaps crashes.

Could you please run tests with test_insert_delete skipped (option -i test_insert_delete or just skip in code)? If it crashes on other tests, skip them as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43659>
_______________________________________

From report at bugs.python.org  Tue Mar 30 04:05:02 2021
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 30 Mar 2021 08:05:02 +0000
Subject: [issue19124] os.execv executes in background on Windows
In-Reply-To: <1380451602.11.0.517013085188.issue19124@psf.upfronthosting.co.za>
Message-ID: <1617091502.5.0.971581239971.issue19124@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

Steve, what do you think about os.exec*()? Should it be emulated better or deprecated? 

We can't hide the reality that it's a new process with a different process ID and parent process ID -- against what POSIX requires. But emulating exec() is probably good enough for most cases, especially if code expects to work in Windows.

> I like the idea, but we shouldn't invert the dependencies like that. 
> nt/os is a lower-level library, and should provide its own 
> implementation (that perhaps subprocess could then use).

The precedent I had in mind is os.popen(), which uses subprocess.

There wouldn't be much need to implement system() and spawnv[e] if ucrt used PROC_THREAD_ATTRIBUTE_HANDLE_LIST in the common spawn code (exec\spawnv.cpp). Any chance that's in development or planned?

If Python implements its own system() and spawnv[e]() functions, support for inheritable file descriptors [1] would probably have to be dropped. That's not a great loss, IMO, but I'm sure someone will be unhappy about it. The problem is that the flags for an open fd (e.g. FDEV, FPIPE, FAPPEND, FTEXT, FNOINHERIT), which the CRT copies to the STARTUPINFO.lpReserved2 buffer, are not public data. In particular, the FAPPEND flag for an O_APPEND open can't be determined or inferred.

---

[1] Making an fd inheritable currently requires two steps in Windows Python: fd2 = os.dup(fd); os.set_inheritable(fd2, True). os.dup(fd) creates a duplicate fd that's not flagged FNOINHERIT, but the underlying OS handle isn't inheritable. os.set_inheritable(fd, True) makes the OS handle inheritable, but it can't remove the FNOINHERIT fd flag.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19124>
_______________________________________

From report at bugs.python.org  Tue Mar 30 04:31:11 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 30 Mar 2021 08:31:11 +0000
Subject: [issue43659] AIX: test_curses crashes buildbot
In-Reply-To: <1617040273.92.0.487968447995.issue43659@roundup.psfhosted.org>
Message-ID: <1617093071.54.0.679185821253.issue43659@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Please also try to comment out the following line in test_output_string. Does it help?

                s = '\u0661\u0662\u0663\u0664'
                try:
                    func(s, 3)
                except UnicodeEncodeError:
                    self.assertRaises(UnicodeEncodeError, s.encode, encoding)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43659>
_______________________________________

From report at bugs.python.org  Tue Mar 30 04:37:28 2021
From: report at bugs.python.org (Michael Felt)
Date: Tue, 30 Mar 2021 08:37:28 +0000
Subject: [issue43666] AIX: Lib/_aix_support.py may break in a WPAR environment
Message-ID: <1617093448.54.0.678139047472.issue43666@roundup.psfhosted.org>


New submission from Michael Felt <aixtools at felt.demon.nl>:

When working in a WPAR (workload partition) the routines supporting aix_platform() may fail if there is no related builddate for bos.mp64.

a) the fileset queried is changed to `bos.rte`
b) an extreme value (9988) is returned for any similar (unexpected) situations - so that, in any case, the build of Python can proceed.

----------
components: Library (Lib)
messages: 389804
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: AIX: Lib/_aix_support.py may break in a WPAR environment
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43666>
_______________________________________

From report at bugs.python.org  Tue Mar 30 04:37:32 2021
From: report at bugs.python.org (Takumi Kato)
Date: Tue, 30 Mar 2021 08:37:32 +0000
Subject: [issue24234] Should we define complex.__complex__ and bytes.__bytes__?
In-Reply-To: <1431985055.48.0.760233282847.issue24234@psf.upfronthosting.co.za>
Message-ID: <1617093452.14.0.705897968145.issue24234@roundup.psfhosted.org>


Takumi Kato <takumi.kt+github at gmail.com> added the comment:

Recently, the situation has changed. We should consider this issue again.

typing.SupportsComplex is an ABC with one abstract method __complex__.
Thus, isinstance(complex, typing.SupportsComplex) is False.
typing.SupportsBytes also.

It is nonsense.

----------
nosy: +gyu-don

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24234>
_______________________________________

From report at bugs.python.org  Tue Mar 30 04:37:44 2021
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 30 Mar 2021 08:37:44 +0000
Subject: [issue43125] Trying To Concatenate Bytes and String in SMTPLIB
In-Reply-To: <1612445008.73.0.955251739992.issue43125@roundup.psfhosted.org>
Message-ID: <1617093464.98.0.713944930916.issue43125@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:


New changeset cf35e05f89bb008d6f4553f9875e0fe87fc02406 by Gr?gory Starck in branch 'master':
bpo-43125: Fix: return expected type (str), not original value (bytes) in email/base64mime.py::body_encode (GH-24476)
https://github.com/python/cpython/commit/cf35e05f89bb008d6f4553f9875e0fe87fc02406


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43125>
_______________________________________

From report at bugs.python.org  Tue Mar 30 04:38:10 2021
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 30 Mar 2021 08:38:10 +0000
Subject: [issue43125] Trying To Concatenate Bytes and String in SMTPLIB
In-Reply-To: <1612445008.73.0.955251739992.issue43125@roundup.psfhosted.org>
Message-ID: <1617093490.83.0.100381079604.issue43125@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10 -Python 3.6, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43125>
_______________________________________

From report at bugs.python.org  Tue Mar 30 04:40:23 2021
From: report at bugs.python.org (gchauvel)
Date: Tue, 30 Mar 2021 08:40:23 +0000
Subject: [issue43622] TLS 1.3, client polling returns event without data
In-Reply-To: <1616662467.59.0.863199354761.issue43622@roundup.psfhosted.org>
Message-ID: <1617093623.29.0.705847641545.issue43622@roundup.psfhosted.org>


gchauvel <guillaume.chauvel at gmail.com> added the comment:

Based on your first comment, poll returning an event and recv not able to read data is a behavior to expect with TLSv1.2/TLSv1.3 (or ...)
So in order to use SSLContext in a polling loop with multiple file descriptors, a non-blocking mode (to avoid an fd event and not being able to read data) is mandatory. Do you agree with this statement ?

Furthermore, I looked at [1], the other tests in test_ssl.py and also set a few traces in _ssl.c

- without non blocking mode: even with a fd event, the test blocks on SSL_read
- with non blocking mode: SSL_read returns a negative value, PySSL_SetError throws PySSLWantWriteErrorObject, but:

    nothing is printed on the console, a thread is blocked at PyThread_acquire_lock_timed, so the test hangs forever.

- with non blocking mode + try/except ssl.SSLWantReadError [2], the test is ok

[1] https://docs.python.org/3/library/ssl.html#ssl-nonblocking
[2] https://github.com/g-chauvel/cpython/commit/dc57cbea3558ff7b3c040326709d9b759214584a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43622>
_______________________________________

From report at bugs.python.org  Tue Mar 30 04:55:17 2021
From: report at bugs.python.org (Michael Felt)
Date: Tue, 30 Mar 2021 08:55:17 +0000
Subject: [issue43659] AIX: test_curses crashes buildbot
In-Reply-To: <1617040273.92.0.487968447995.issue43659@roundup.psfhosted.org>
Message-ID: <1617094517.7.0.542153128171.issue43659@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

./python -m test -vuall -i test_output_string -i test_insert_delete test_curses 2>test.err 1>test.out

returns four failures: see attached

'-i test_output_string' stops the crash

----------
Added file: https://bugs.python.org/file49918/test.out

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43659>
_______________________________________

From report at bugs.python.org  Tue Mar 30 04:58:19 2021
From: report at bugs.python.org (miss-islington)
Date: Tue, 30 Mar 2021 08:58:19 +0000
Subject: [issue43631] Update to OpenSSL 1.1.1k
In-Reply-To: <1616746538.63.0.13329268116.issue43631@roundup.psfhosted.org>
Message-ID: <1617094699.28.0.701705859393.issue43631@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 9ac263091db4a8c7dedb577d01f544622a448744 by Christian Heimes in branch '3.8':
[3.8] bpo-43631: Update to OpenSSL 1.1.1k (GH-25024) (GH-25089)
https://github.com/python/cpython/commit/9ac263091db4a8c7dedb577d01f544622a448744


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43631>
_______________________________________

From report at bugs.python.org  Tue Mar 30 04:58:19 2021
From: report at bugs.python.org (miss-islington)
Date: Tue, 30 Mar 2021 08:58:19 +0000
Subject: [issue43631] Update to OpenSSL 1.1.1k
In-Reply-To: <1616746538.63.0.13329268116.issue43631@roundup.psfhosted.org>
Message-ID: <1617094699.28.0.701705859393.issue43631@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 9ac263091db4a8c7dedb577d01f544622a448744 by Christian Heimes in branch '3.8':
[3.8] bpo-43631: Update to OpenSSL 1.1.1k (GH-25024) (GH-25089)
https://github.com/python/cpython/commit/9ac263091db4a8c7dedb577d01f544622a448744


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43631>
_______________________________________

From report at bugs.python.org  Tue Mar 30 04:58:19 2021
From: report at bugs.python.org (miss-islington)
Date: Tue, 30 Mar 2021 08:58:19 +0000
Subject: [issue43631] Update to OpenSSL 1.1.1k
In-Reply-To: <1616746538.63.0.13329268116.issue43631@roundup.psfhosted.org>
Message-ID: <1617094699.42.0.293413721229.issue43631@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset cd82d592063aa03dcc238dcc5222bd47ee0eb438 by Christian Heimes in branch '3.9':
[3.9] bpo-43631: Update to OpenSSL 1.1.1k (GH-25024) (GH-25088)
https://github.com/python/cpython/commit/cd82d592063aa03dcc238dcc5222bd47ee0eb438


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43631>
_______________________________________

From report at bugs.python.org  Tue Mar 30 05:01:22 2021
From: report at bugs.python.org (Dimitri Merejkowsky)
Date: Tue, 30 Mar 2021 09:01:22 +0000
Subject: [issue37745] 3.8b3 - windows install gui/ inconsistent options
In-Reply-To: <1564766468.14.0.320547199271.issue37745@roundup.psfhosted.org>
Message-ID: <1617094882.48.0.686977307897.issue37745@roundup.psfhosted.org>


Dimitri Merejkowsky <dimitri at dmerej.info> added the comment:

> the inevitable confusion when multiple PATH updates do not play well together (which they don't).

Oh I see. Did not think about that. I can see a scenario where you install 3.9, PATH is set, you install 3.10, the PATH update fails for some reason and then you get stuck because PATH was not updated correctly... and then you're back to manually setting PATH which was the thing we were trying to prevent ...

> you can modify [Python installations coming from the Windows store] through the built-in "Manage App Execution Aliases" control panel if you have multiple)

Good to know, thanks. That was one of my concerns actually.

> I'm sick to death of being abused over this issue

I'm sorry to hear that and I apologize - I was simply trying to get answers.

Well, now that I know why the box is not ticked, I can say I'm happy with the state of the installer, and I guess I'll continue to teach my students about PATH - after all, it's a useful skill to have ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37745>
_______________________________________

From report at bugs.python.org  Tue Mar 30 05:10:27 2021
From: report at bugs.python.org (gchauvel)
Date: Tue, 30 Mar 2021 09:10:27 +0000
Subject: [issue43622] TLS 1.3, client polling returns event without data
In-Reply-To: <1616662467.59.0.863199354761.issue43622@roundup.psfhosted.org>
Message-ID: <1617095427.35.0.411266058996.issue43622@roundup.psfhosted.org>


gchauvel <guillaume.chauvel at gmail.com> added the comment:

err: second item: copy/paste error, the exception is PySSLWantReadErrorObject

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43622>
_______________________________________

From report at bugs.python.org  Tue Mar 30 06:11:34 2021
From: report at bugs.python.org (Jakub Kulik)
Date: Tue, 30 Mar 2021 10:11:34 +0000
Subject: [issue43667] Solaris: Fix broken Unicode encoding in non-UTF locales
Message-ID: <1617099094.43.0.768783655635.issue43667@roundup.psfhosted.org>


New submission from Jakub Kulik <kulikjak at gmail.com>:

On Linux, wchar_t values are mapped to their UTF-8 counterparts; however, that does not have to be the case as the standard allows any arbitrary representation to be used, and this is the case for Solaris.

In Oracle Solaris, the internal form of wchar_t is specific to a locale; in the Unicode locales, wchar_t has the UTF-32 Unicode encoding form, and other locales have different representations [1].

This is an issue because Python expects wchar_t to correspond with Unicode, which on Oracle Solaris with non-UTF locale results either in errors (values are outside the Unicode range) or in output with different symbols.

Unicode locales work as expected, but they are not an acceptable workaround for some Oracle Solaris users that cannot use Unicode encoding for various reasons.


Because of that, we fixed it a few months ago with a patch to `PyUnicode_FromWideChar`, which handles conversion to unicode (attached in PR). It was tested over the last half a year, and we didn't see any related issues since.

Is something like this acceptable or should it be fixed on a different place/in a different way? All comments are appreciated.

[1] https://docs.oracle.com/cd/E36784_01/html/E39536/gmwkm.html

----------
components: Unicode
messages: 389813
nosy: ezio.melotti, kulikjak, vstinner
priority: normal
severity: normal
status: open
title: Solaris: Fix broken Unicode encoding in non-UTF locales
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43667>
_______________________________________

From report at bugs.python.org  Tue Mar 30 06:12:23 2021
From: report at bugs.python.org (Jakub Kulik)
Date: Tue, 30 Mar 2021 10:12:23 +0000
Subject: [issue43667] Solaris: Fix broken Unicode encoding in non-UTF locales
In-Reply-To: <1617099094.43.0.768783655635.issue43667@roundup.psfhosted.org>
Message-ID: <1617099143.44.0.643044289035.issue43667@roundup.psfhosted.org>


Change by Jakub Kulik <kulikjak at gmail.com>:


----------
keywords: +patch
pull_requests: +23840
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25096

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43667>
_______________________________________

From report at bugs.python.org  Tue Mar 30 06:12:51 2021
From: report at bugs.python.org (Jakub Kulik)
Date: Tue, 30 Mar 2021 10:12:51 +0000
Subject: [issue43667] Solaris: Fix broken Unicode encoding in non-UTF locales
In-Reply-To: <1617099094.43.0.768783655635.issue43667@roundup.psfhosted.org>
Message-ID: <1617099171.12.0.60018679663.issue43667@roundup.psfhosted.org>


Jakub Kulik <kulikjak at gmail.com> added the comment:

I forgot to mention: this affects Oracle Solaris. I tested this on SmartOS, and I cannot reproduce it there as it seems that they are using Unicode representation for all locales. Based on the documentation, this might also affect other systems as well (e.g. HP UIX specifically says: 'These values may not be compatible with values obtained by specifying other locales that are supported'), but it's hard to tell without testing that.

This one liner breaks with ValueError: character U+30000069 is not in range [U+0000; U+10ffff] if the issue is present:
python3.7 -c 'import datetime; import locale; locale.setlocale(locale.LC_ALL,"es_ES.ISO8859-1"); datetime.date(2001, 1, 3).strftime("%a")'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43667>
_______________________________________

From report at bugs.python.org  Tue Mar 30 06:27:32 2021
From: report at bugs.python.org (Martin)
Date: Tue, 30 Mar 2021 10:27:32 +0000
Subject: [issue43656] StackSummary.format fails if str(value) fails
In-Reply-To: <1617010609.77.0.749976985588.issue43656@roundup.psfhosted.org>
Message-ID: <1617100052.22.0.225274734723.issue43656@roundup.psfhosted.org>


Martin <martin.schroeder at nerdluecht.de> added the comment:

Yes, it is repr in FrameSummary.__init__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43656>
_______________________________________

From report at bugs.python.org  Tue Mar 30 06:55:17 2021
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 30 Mar 2021 10:55:17 +0000
Subject: [issue43651] PEP 597: Fix EncodingWarning warnings in the Python
 stdlib
Message-ID: <1617101717.78.0.302876859898.issue43651@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
keywords: +patch
pull_requests: +23841
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25097

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43651>
_______________________________________

From report at bugs.python.org  Tue Mar 30 07:05:31 2021
From: report at bugs.python.org (axel)
Date: Tue, 30 Mar 2021 11:05:31 +0000
Subject: [issue43668] Segfault with for fresh ubuntu 20.04 install
Message-ID: <1617102331.02.0.538346172049.issue43668@roundup.psfhosted.org>


New submission from axel <axel.goteman at mindified.com>:

The python interpreter segfaults when running in a miniconda environment on a fresh install of ubuntu 20.04.2. This seems to happen intermittently, both while running "pip" during the conda setup of an environment and during the execution of code like below. The issue is most have mostly been reproduced with conda, but seems to happen regardless, which is why I suspect it is a python bug. It is very odd that I can't seem to find anyone else with the same issue.

The segfault always occurs when running the following code, which reads texts from files and tokenizes the result. The segfault location changes from run to run. Also the exact same code can run on another computer with the same conda environment on a ubuntu 18.04.

The core dumps always points to some function in the unicodeobject.c file in python but the exact function changes from crash to crash. At least one crash has a clear dereferenced pointer 0x0 where the "unicode object" should be.

My guess is that something causes the python interpreter to throw away the pointed to unicode object while it is still being worked on causing a segfault. But any bug in the interpreter or NLTK should have been noticed by more users, and I cannot find anyone with similar issues. 

Things tried that didn't fix the issue:
1. Reformatting and reinstalling ubuntu
2. Switched to ubuntu 18.04 (on this computer, another computer with 18.04 can run the code just fine)
3. Replacing hardware, to ensure that RAM, or SSD disk isn't broken
4. Changing to python versions 3.8.6, 3.8.8, 3.9.2
5. Cloning the conda environment from a working computer to the broken one

Attached is one stacktrace of the fault handler along with it's corresponding core dump stack trace from gdb.

```
(eo) axel at minimind:~/test$ python tokenizer_mini.py 
2021-03-30 11:10:15.588399: W tensorflow/stream_executor/platform/default/dso_loader.cc:60] Could not load dynamic library 'libcudart.so.11.0'; dlerror: libcudart.so.11.0: cannot open shared object file: No such file or directory
2021-03-30 11:10:15.588426: I tensorflow/stream_executor/cuda/cudart_stub.cc:29] Ignore above cudart dlerror if you do not have a GPU set up on your machine.
Fatal Python error: Segmentation fault

Current thread 0x00007faa73bbe740 (most recent call first):
  File "tokenizer_mini.py", line 36 in preprocess_string
  File "tokenizer_mini.py", line 51 in <module>
Segmentation fault (core dumped)
```

```
#0  raise (sig=<optimized out>) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  <signal handler called>
#2  find_maxchar_surrogates (num_surrogates=<synthetic pointer>, maxchar=<synthetic pointer>, 
    end=0x4 <error: Cannot access memory at address 0x4>, begin=0x0)
    at /home/conda/feedstock_root/build_artifacts/python-split_1613835706476/work/Objects/unicodeobject.c:1703
#3  _PyUnicode_Ready (unicode=0x7f7e4e04d7f0)
    at /home/conda/feedstock_root/build_artifacts/python-split_1613835706476/work/Objects/unicodeobject.c:1742
#4  0x000055cd65f6df6a in PyUnicode_RichCompare (left=0x7f7e4cf43fb0, right=<optimized out>, op=2)
    at /home/conda/feedstock_root/build_artifacts/python-split_1613835706476/work/Objects/unicodeobject.c:11205
#5  0x000055cd6601712a in do_richcompare (op=2, w=0x7f7e4e04d7f0, v=0x7f7e4cf43fb0)
    at /home/conda/feedstock_root/build_artifacts/python-split_1613835706476/work/Objects/object.c:726
#6  PyObject_RichCompare (op=2, w=0x7f7e4e04d7f0, v=0x7f7e4cf43fb0)
    at /home/conda/feedstock_root/build_artifacts/python-split_1613835706476/work/Objects/object.c:774
#7  PyObject_RichCompareBool (op=2, w=0x7f7e4e04d7f0, v=0x7f7e4cf43fb0)
    at /home/conda/feedstock_root/build_artifacts/python-split_1613835706476/work/Objects/object.c:796
#8  list_contains (a=0x7f7e4e04b4c0, el=0x7f7e4cf43fb0)
    at /home/conda/feedstock_root/build_artifacts/python-split_1613835706476/work/Objects/listobject.c:455
#9  0x000055cd660be41b in PySequence_Contains (ob=0x7f7e4cf43fb0, seq=0x7f7e4e04b4c0)
    at /home/conda/feedstock_root/build_artifacts/python-split_1613835706476/work/Objects/abstract.c:2083
#10 cmp_outcome (w=0x7f7e4e04b4c0, v=0x7f7e4cf43fb0, op=<optimized out>, tstate=<optimized out>)
    at /home/conda/feedstock_root/build_artifacts/python-split_1613835706476/work/Python/ceval.c:5082
#11 _PyEval_EvalFrameDefault (f=<optimized out>, throwflag=<optimized out>)
    at /home/conda/feedstock_root/build_artifacts/python-split_1613835706476/work/Python/ceval.c:2977
#12 0x000055cd6609f706 in PyEval_EvalFrameEx (throwflag=0, f=0x7f7e4f4d3c40)
    at /home/conda/feedstock_root/build_artifacts/python-split_1613835706476/work/Python/ceval.c:738
#13 function_code_fastcall (globals=<optimized out>, nargs=<optimized out>, args=<optimized out>, co=<optimized out>)
    at /home/conda/feedstock_root/build_artifacts/python-split_1613835706476/work/Objects/call.c:284
#14 _PyFunction_Vectorcall (func=<optimized out>, stack=<optimized out>, nargsf=<optimized out>, kwnames=<optimized out>)
    at /home/conda/feedstock_root/build_artifacts/python-split_1613835706476/work/Objects/call.c:411
#15 0x000055cd660be54f in _PyObject_Vectorcall (kwnames=0x0, nargsf=<optimized out>, args=0x7f7f391985b8, callable=0x7f7f39084160)
    at /home/conda/feedstock_root/build_artifacts/python-split_1613835706476/work/Include/cpython/abstract.h:115
#16 call_function (kwnames=0x0, oparg=<optimized out>, pp_stack=<synthetic pointer>, tstate=0x55cd66c2e880)
    at /home/conda/feedstock_root/build_artifacts/python-split_1613835706476/work/Python/ceval.c:4963
#17 _PyEval_EvalFrameDefault (f=<optimized out>, throwflag=<optimized out>)
    at /home/conda/feedstock_root/build_artifacts/python-split_1613835706476/work/Python/ceval.c:3500
#18 0x000055cd6609e503 in PyEval_EvalFrameEx (throwflag=0, f=0x7f7f39198440)
    at /home/conda/feedstock_root/build_artifacts/python-split_1613835706476/work/Python/ceval.c:4298
#19 _PyEval_EvalCodeWithName (_co=<optimized out>, globals=<optimized out>, locals=<optimized out>, args=<optimized out>, 
    argcount=<optimized out>, kwnames=<optimized out>, kwargs=<optimized out>, kwcount=<optimized out>, kwstep=<optimized out>, 
    defs=<optimized out>, defcount=<optimized out>, kwdefs=<optimized out>, closure=<optimized out>, name=<optimized out>, 
    qualname=<optimized out>) at /home/conda/feedstock_root/build_artifacts/python-split_1613835706476/work/Python/ceval.c:4298
#20 0x000055cd6609f559 in PyEval_EvalCodeEx (_co=<optimized out>, globals=<optimized out>, locals=<optimized out>, 
    args=<optimized out>, argcount=<optimized out>, kws=<optimized out>, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0)
    at /home/conda/feedstock_root/build_artifacts/python-split_1613835706476/work/Python/ceval.c:4327
#21 0x000055cd661429ab in PyEval_EvalCode (co=<optimized out>, globals=<optimized out>, locals=<optimized out>)
    at /home/conda/feedstock_root/build_artifacts/python-split_1613835706476/work/Python/ceval.c:718
#22 0x000055cd66142a43 in run_eval_code_obj (co=0x7f7f3910f240, globals=0x7f7f391fad80, locals=0x7f7f391fad80)
    at /home/conda/feedstock_root/build_artifacts/python-split_1613835706476/work/Python/pythonrun.c:1165
#23 0x000055cd6615c6b3 in run_mod (mod=<optimized out>, filename=<optimized out>, globals=0x7f7f391fad80, locals=0x7f7f391fad80, 
    flags=<optimized out>, arena=<optimized out>)
    at /home/conda/feedstock_root/build_artifacts/python-split_1613835706476/work/Python/pythonrun.c:1187
--Type <RET> for more, q to quit, c to continue without paging--
#24 0x000055cd661615b2 in pyrun_file (fp=0x55cd66c2cdf0, filename=0x7f7f391bbee0, start=<optimized out>, globals=0x7f7f391fad80, 
    locals=0x7f7f391fad80, closeit=1, flags=0x7ffe3ee6f8e8)
    at /home/conda/feedstock_root/build_artifacts/python-split_1613835706476/work/Python/pythonrun.c:1084
#25 0x000055cd66161792 in pyrun_simple_file (flags=0x7ffe3ee6f8e8, closeit=1, filename=0x7f7f391bbee0, fp=0x55cd66c2cdf0)
    at /home/conda/feedstock_root/build_artifacts/python-split_1613835706476/work/Python/pythonrun.c:439
#26 PyRun_SimpleFileExFlags (fp=0x55cd66c2cdf0, filename=<optimized out>, closeit=1, flags=0x7ffe3ee6f8e8)
    at /home/conda/feedstock_root/build_artifacts/python-split_1613835706476/work/Python/pythonrun.c:472
#27 0x000055cd66161d0d in pymain_run_file (cf=0x7ffe3ee6f8e8, config=0x55cd66c2da70)
    at /home/conda/feedstock_root/build_artifacts/python-split_1613835706476/work/Modules/main.c:391
#28 pymain_run_python (exitcode=0x7ffe3ee6f8e0)
    at /home/conda/feedstock_root/build_artifacts/python-split_1613835706476/work/Modules/main.c:616
#29 Py_RunMain () at /home/conda/feedstock_root/build_artifacts/python-split_1613835706476/work/Modules/main.c:695
#30 0x000055cd66161ec9 in Py_BytesMain (argc=<optimized out>, argv=<optimized out>)
    at /home/conda/feedstock_root/build_artifacts/python-split_1613835706476/work/Modules/main.c:1127
#31 0x00007f7f3a3620b3 in __libc_start_main (main=0x55cd65fe3490 <main>, argc=2, argv=0x7ffe3ee6fae8, init=<optimized out>, 
    fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffe3ee6fad8) at ../csu/libc-start.c:308
#32 0x000055cd660d7369 in _start () at /home/conda/feedstock_root/build_artifacts/python-split_1613835706476/work/Python/ast.c:937
```

The conda environment used is below, using Miniconda3-py38_4.9.2-Linux-x86_64.sh (note that the segfault does sometimes occur during the setup of a conda environment so it's probably not related to the env)
```
name: eo
channels:
  - conda-forge
  - defaults
dependencies:
  - python=3.8.8
  - pip=20.3.1
  - pip:
    - transformers==4.3.2
    - tensorflow_gpu==2.4.0
    - scikit-learn==0.23.2
    - nltk==3.5
    - matplotlib==3.2.1
    - seaborn==0.11.0
    - tensorflow-addons==0.11.2
    - tf-models-official==2.4.0
    - gspread==3.6.0
    - oauth2client==4.1.3
    - ipykernel==5.4.2
    - autopep8==1.5.4
    - torch==1.7.1
```


The code below consistently reproduces the problem, the files read are simple text files containing unicode text:

```python
from nltk.tokenize import wordpunct_tokenize
from tensorflow.keras.preprocessing.text import Tokenizer
from nltk.stem.snowball import SnowballStemmer
from nltk.corpus import stopwords
import pickle
from pathlib import Path
import faulthandler
faulthandler.enable()


def load_data(root_path, feature, index):
    feature_root = root_path / feature
    dir1 = str(index // 10_000)
    base_path = feature_root / dir1 / str(index)
    full_path = base_path.with_suffix('.txt')
    data = None
    with open(full_path, 'r', encoding='utf-8') as f:
        data = f.read()
    return data


def preprocess_string(text, stemmer, stop_words):
    word_tokens = wordpunct_tokenize(text.lower())
    alpha_tokens = []
    for w in word_tokens:
        try:
            if (w.isalpha() and w not in stop_words):
                alpha_tokens.append(w)
        except:
            print("Something went wrong when handling the word: ", w)

    clean_tokens = []
    for w in alpha_tokens:
        try:
            word = stemmer.stem(w)
            clean_tokens.append(word)
        except:
            print("Something went wrong when stemming the word: ", w)
            clean_tokens.append(w)
    return clean_tokens


stop_words = stopwords.words('english')
stemmer = SnowballStemmer(language='english')
tokenizer = Tokenizer()

root_path = '/srv/patent/EbbaOtto/E'
for idx in range(0, 57454):
    print(f'Processed {idx}/57454', end='\r')
    desc = str(load_data(Path(root_path), 'clean_description', idx))
    desc = preprocess_string(desc, stemmer, stop_words)
    tokenizer.fit_on_texts([desc])

```

For more readable formatting read the stackoverflow post regarding the same issue:
https://stackoverflow.com/questions/66868753/segfault-with-for-fresh-ubuntu-20-04-install-using-conda

----------
components: Interpreter Core
messages: 389816
nosy: axel_1234
priority: normal
severity: normal
status: open
title: Segfault with for fresh ubuntu 20.04 install
type: crash
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43668>
_______________________________________

From report at bugs.python.org  Tue Mar 30 07:12:31 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Mar 2021 11:12:31 +0000
Subject: [issue43668] Segfault with for fresh ubuntu 20.04 install
In-Reply-To: <1617102331.02.0.538346172049.issue43668@roundup.psfhosted.org>
Message-ID: <1617102751.91.0.580872510164.issue43668@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

This is very likely a crash in a 3rd party C extensions. You should try to write a simpler reproducer and report it to the C extensions causing the crash. You can try to enable the Python Development Mode to see if it provides you more information:
https://docs.python.org/dev/library/devmode.html

See also my notes on debugging a Python crash:
https://pythondev.readthedocs.io/debug_tools.html


#2  find_maxchar_surrogates (num_surrogates=<synthetic pointer>, maxchar=<synthetic pointer>, 
    end=0x4 <error: Cannot access memory at address 0x4>, begin=0x0)
    at /home/conda/feedstock_root/build_artifacts/python-split_1613835706476/work/Objects/unicodeobject.c:1703
#3  _PyUnicode_Ready (unicode=0x7f7e4e04d7f0)
    at /home/conda/feedstock_root/build_artifacts/python-split_1613835706476/work/Objects/unicodeobject.c:1742

Python no longer create "not ready" strings: _PyUnicode_Ready() is called to convert strings created with the deprecated legacy C API. It is likely a string created by a 3rd party C extension.

"begin=0x0 and end=0x4" sounds like the string is corrupted: in _PyUnicode_Ready(), _PyUnicode_WSTR(unicode) must not be NULL (begin=0x0).

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43668>
_______________________________________

From report at bugs.python.org  Tue Mar 30 07:15:53 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Mar 2021 11:15:53 +0000
Subject: [issue43668] Segfault with for fresh ubuntu 20.04 install
In-Reply-To: <1617102331.02.0.538346172049.issue43668@roundup.psfhosted.org>
Message-ID: <1617102953.54.0.938055422153.issue43668@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Also, it would help a lot to use a Python built in debug mode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43668>
_______________________________________

From report at bugs.python.org  Tue Mar 30 07:30:23 2021
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 30 Mar 2021 11:30:23 +0000
Subject: [issue43656] StackSummary.format fails if str(value) fails
In-Reply-To: <1617010609.77.0.749976985588.issue43656@roundup.psfhosted.org>
Message-ID: <1617103823.72.0.605720518963.issue43656@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

See issue39228.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43656>
_______________________________________

From report at bugs.python.org  Tue Mar 30 07:49:54 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Mar 2021 11:49:54 +0000
Subject: [issue43668] Segfault with for fresh ubuntu 20.04 install
In-Reply-To: <1617102331.02.0.538346172049.issue43668@roundup.psfhosted.org>
Message-ID: <1617104994.05.0.563508694646.issue43668@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Also, it would help a lot to use a Python built in debug mode.

See: https://pythondev.readthedocs.io/builds.html#pydebug

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43668>
_______________________________________

From report at bugs.python.org  Tue Mar 30 08:04:44 2021
From: report at bugs.python.org (axel)
Date: Tue, 30 Mar 2021 12:04:44 +0000
Subject: [issue43668] Segfault with for fresh ubuntu 20.04 install
In-Reply-To: <1617102331.02.0.538346172049.issue43668@roundup.psfhosted.org>
Message-ID: <1617105884.1.0.880976028008.issue43668@roundup.psfhosted.org>


axel <axel.goteman at mindified.com> added the comment:

Thanks for the reply, I don't know exactly what you mean by making a simpler reproducer, but as I wrote in the original post, just using pip will cause this issue to happen from time to time, which is why I find it unlikely to be caused by third party libs. 

I will try to cause a reproduction without 3rd party libs but since I don't have a good idea of what is causing it, I'm not really sure where to start.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43668>
_______________________________________

From report at bugs.python.org  Tue Mar 30 08:07:35 2021
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 30 Mar 2021 12:07:35 +0000
Subject: [issue43510] PEP 597: Implemente encoding="locale" option and
 EncodingWarning
In-Reply-To: <1615868389.17.0.260147645451.issue43510@roundup.psfhosted.org>
Message-ID: <1617106055.65.0.114999374922.issue43510@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

In bpo-43651, I found code pattern that it's difficult to use io.text_encoding():

    class OpenWrapper:
        def __new__(cls, *args, **kwargs):
            return open(*args, **kwargs)

`kwargs["encoding"] = text_encoding(kwargs.get("encoding)` doesn't work because `open(filename, "b", encoding="locale")` raises `ValueError: binary mode doesn't take an encoding argument`.

I think we should accept `encoding="locale"` even in binary mode. It makes easy to use `text_encoding()` and `encoding="locale"`.

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43510>
_______________________________________

From report at bugs.python.org  Tue Mar 30 08:10:46 2021
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 30 Mar 2021 12:10:46 +0000
Subject: [issue43669] PEP 644: Require OpenSSL 1.1.1 or newer
Message-ID: <1617106246.37.0.0210118077092.issue43669@roundup.psfhosted.org>


New submission from Christian Heimes <lists at cheimes.de>:

Tracker ticket for PEP 644, https://www.python.org/dev/peps/pep-0644/

This PEP proposes for CPython?s standard library to support only OpenSSL 1.1.1 LTS or newer. Support for OpenSSL versions past end-of-lifetime, incompatible forks, and other TLS libraries are dropped.

----------
assignee: christian.heimes
components: SSL
messages: 389823
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: PEP 644: Require OpenSSL 1.1.1 or newer
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43669>
_______________________________________

From report at bugs.python.org  Tue Mar 30 08:20:26 2021
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 30 Mar 2021 12:20:26 +0000
Subject: [issue43669] PEP 644: Require OpenSSL 1.1.1 or newer
In-Reply-To: <1617106246.37.0.0210118077092.issue43669@roundup.psfhosted.org>
Message-ID: <1617106826.29.0.083829458068.issue43669@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
keywords: +patch
pull_requests: +23842
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23014

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43669>
_______________________________________

From report at bugs.python.org  Tue Mar 30 08:46:31 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Mar 2021 12:46:31 +0000
Subject: [issue43668] Segfault with for fresh ubuntu 20.04 install
In-Reply-To: <1617102331.02.0.538346172049.issue43668@roundup.psfhosted.org>
Message-ID: <1617108391.1.0.193642928379.issue43668@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Thanks for the reply, I don't know exactly what you mean by making a simpler reproducer

Script with less lines and less imports.

> just using pip will cause this issue to happen from time to time, which is why I find it unlikely to be caused by third party libs. 

pip is a 3rd party project using 3rd party C extensions.

"3rd party" means "not maintained by python.org" (not part of the stdlib). See also:
https://docs.python.org/dev/library/sys.html#sys.stdlib_module_names

> I'm not really sure where to start.

Set PYTHONDEVMODE=1 in your ~/.bashrc, to run all Python applications with the Python Development Mode enabled :-D

Try to reproduce your pip crash with PYTHONDEVMODE=1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43668>
_______________________________________

From report at bugs.python.org  Tue Mar 30 09:10:44 2021
From: report at bugs.python.org (Ilya Gruzinov)
Date: Tue, 30 Mar 2021 13:10:44 +0000
Subject: [issue43670] Typo in 3.10 changelog
Message-ID: <1617109844.58.0.922515260201.issue43670@roundup.psfhosted.org>


New submission from Ilya Gruzinov <shagren at gmail.com>:

In next lines typo in function `load`:

# BUG: "rb" mode or encoding="utf-8" should be used.
with open("data.json") as f:
    data = json.laod(f)

----------
assignee: docs at python
components: Documentation
messages: 389825
nosy: docs at python, shagren
priority: normal
pull_requests: 23843
severity: normal
status: open
title: Typo in 3.10 changelog
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43670>
_______________________________________

From report at bugs.python.org  Tue Mar 30 10:23:11 2021
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 30 Mar 2021 14:23:11 +0000
Subject: [issue36384] ipaddress Should not reject IPv4 addresses with leading
 zeroes as ambiguously octal
In-Reply-To: <1553125209.55.0.0358803413865.issue36384@roundup.psfhosted.org>
Message-ID: <1617114191.27.0.130588410785.issue36384@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Serhiy was right, this is a security issue.

The patch should not have landed in 3.8. At a bare minimum the patch should have been postponed until documentation was updated. Since 3.8 the ipaddresss does not behave as documented. A similar security issue in NPM was published two days ago, CVE-2021-28918.

I proposed to not only revert the change, but also tighten the check for leading zeros so it behaves like glibc's inet_pton(). It refuses any IPv4 string with a leading zero.

>>> socket.inet_pton(socket.AF_INET, "01.1.1.1")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: illegal IP address string passed to inet_pton
>>> socket.inet_pton(socket.AF_INET, "1.1.1.01")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: illegal IP address string passed to inet_pton

----------
components: +Library (Lib)
keywords: +3.8regression, 3.9regression -3.2regression
nosy: +christian.heimes
priority: normal -> critical
type: behavior -> security
versions: +Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36384>
_______________________________________

From report at bugs.python.org  Tue Mar 30 10:34:47 2021
From: report at bugs.python.org (Samuel Kirwin)
Date: Tue, 30 Mar 2021 14:34:47 +0000
Subject: [issue43671] segfault when using tkinter + pygame for ~5 minutes
Message-ID: <1617114887.1.0.547947822619.issue43671@roundup.psfhosted.org>


New submission from Samuel Kirwin <samueljkirwin at gmail.com>:

Per the attached file, when testing an adapted version of pygame's alien script as part of research. Python segfaulted.

This has occured twice about 5 minutes in.

I had console running all messages at the time if more logs needed.

MacOS Big Sur 11.2.3 on MacBook Air (Retina, 13-inch, 2018) with 1.6 GHz Dual-Core Intel Core i5 & 8 GB 2133 MHz LPDDR3 Memory

----------
components: Tkinter
files: segfault.rtf
messages: 389827
nosy: Pycryptor10
priority: normal
severity: normal
status: open
title: segfault when using tkinter + pygame for ~5 minutes
type: crash
versions: Python 3.9
Added file: https://bugs.python.org/file49919/segfault.rtf

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43671>
_______________________________________

From report at bugs.python.org  Tue Mar 30 10:38:08 2021
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 30 Mar 2021 14:38:08 +0000
Subject: [issue43510] PEP 597: Implemente encoding="locale" option and
 EncodingWarning
In-Reply-To: <1615868389.17.0.260147645451.issue43510@roundup.psfhosted.org>
Message-ID: <1617115088.02.0.0325231997017.issue43510@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> I think we should accept `encoding="locale"` even in binary mode.

That's a good idea. It means the same as passing None, except it avoids a warning.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43510>
_______________________________________

From report at bugs.python.org  Tue Mar 30 10:49:14 2021
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 30 Mar 2021 14:49:14 +0000
Subject: [issue31956] Add start and stop parameters to the array.index()
In-Reply-To: <1509966827.68.0.213398074469.issue31956@psf.upfronthosting.co.za>
Message-ID: <1617115754.59.0.0319932872502.issue31956@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/issue31956>
_______________________________________

From report at bugs.python.org  Tue Mar 30 10:51:56 2021
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 30 Mar 2021 14:51:56 +0000
Subject: [issue36384] ipaddress Should not reject IPv4 addresses with leading
 zeroes as ambiguously octal
In-Reply-To: <1553125209.55.0.0358803413865.issue36384@roundup.psfhosted.org>
Message-ID: <1617115916.52.0.181617137468.issue36384@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
keywords: +patch
pull_requests: +23844
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/25099

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36384>
_______________________________________

From report at bugs.python.org  Tue Mar 30 11:08:43 2021
From: report at bugs.python.org (Michael Felt)
Date: Tue, 30 Mar 2021 15:08:43 +0000
Subject: [issue43666] AIX: Lib/_aix_support.py may break in a WPAR environment
In-Reply-To: <1617093448.54.0.678139047472.issue43666@roundup.psfhosted.org>
Message-ID: <1617116923.34.0.219645661905.issue43666@roundup.psfhosted.org>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
keywords: +patch
pull_requests: +23845
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25095

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43666>
_______________________________________

From report at bugs.python.org  Tue Mar 30 11:19:00 2021
From: report at bugs.python.org (Pycrytor10)
Date: Tue, 30 Mar 2021 15:19:00 +0000
Subject: [issue43671] segfault when using tkinter + pygame for ~5 minutes
In-Reply-To: <1617114887.1.0.547947822619.issue43671@roundup.psfhosted.org>
Message-ID: <1617117540.62.0.0475943314936.issue43671@roundup.psfhosted.org>


Pycrytor10 <samueljkirwin at gmail.com> added the comment:

Can reproduce with a modified pygame.examples.alien to run in a loop after a similar time.

----------
Added file: https://bugs.python.org/file49920/aliens.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43671>
_______________________________________

From report at bugs.python.org  Tue Mar 30 11:19:12 2021
From: report at bugs.python.org (Pycrytor10)
Date: Tue, 30 Mar 2021 15:19:12 +0000
Subject: [issue43671] segfault when using tkinter + pygame for ~5 minutes
In-Reply-To: <1617114887.1.0.547947822619.issue43671@roundup.psfhosted.org>
Message-ID: <1617117552.9.0.454364574392.issue43671@roundup.psfhosted.org>


Change by Pycrytor10 <samueljkirwin at gmail.com>:


Added file: https://bugs.python.org/file49921/segfaultpygame.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43671>
_______________________________________

From report at bugs.python.org  Tue Mar 30 11:20:15 2021
From: report at bugs.python.org (Alex)
Date: Tue, 30 Mar 2021 15:20:15 +0000
Subject: [issue43399] xml.etree.ElementTree.extend does not work with
 iterators when using the Python implementation
In-Reply-To: <1614873561.76.0.875762243403.issue43399@roundup.psfhosted.org>
Message-ID: <1617117615.59.0.932005309799.issue43399@roundup.psfhosted.org>


Alex <alexprengere at gmail.com> added the comment:

Is there anything else I should be doing, in order to get this merged in time for 3.10? (the PR is "awaiting merge")
For the record, the equivalent PR for PyPy is now merged in the py3.7 branch: https://foss.heptapod.net/pypy/pypy/-/merge_requests/807.

Regarding the backporting, I understand from the devguide this is done automatically from GitHub labels (nice!), but it does not look like I have the rights to add those to my PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43399>
_______________________________________

From report at bugs.python.org  Tue Mar 30 11:34:07 2021
From: report at bugs.python.org (Pycrytor10)
Date: Tue, 30 Mar 2021 15:34:07 +0000
Subject: [issue43671] segfault when using tkinter + pygame for ~5 minutes
In-Reply-To: <1617114887.1.0.547947822619.issue43671@roundup.psfhosted.org>
Message-ID: <1617118447.23.0.802478499809.issue43671@roundup.psfhosted.org>


Pycrytor10 <samueljkirwin at gmail.com> added the comment:

Also filed https://github.com/pygame/pygame/issues/2543 as not sure where issue comes from

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43671>
_______________________________________

From report at bugs.python.org  Tue Mar 30 11:36:07 2021
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 30 Mar 2021 15:36:07 +0000
Subject: [issue38263] [Windows] multiprocessing: DupHandle.detach() race
 condition on DuplicateHandle(DUPLICATE_CLOSE_SOURCE)
In-Reply-To: <1569321399.19.0.207011593125.issue38263@roundup.psfhosted.org>
Message-ID: <1617118567.77.0.665186783881.issue38263@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

spawn_main() could handle a PermissionError by checking the exit code. If the parent has terminated already, then simply exit quietly. _winapi.PROCESS_QUERY_LIMITED_INFORMATION would need to be defined. For example:

    def spawn_main(pipe_handle, parent_pid=None, tracker_fd=None):
        """Run code specified by data received over a pipe."""
        assert is_forking(sys.argv), "Not forking"

        if sys.platform == 'win32':
            import msvcrt
            import _winapi

            if parent_pid is not None:
                source_process = _winapi.OpenProcess(
                    _winapi.SYNCHRONIZE |
                    _winapi.PROCESS_DUP_HANDLE |
                    _winapi.PROCESS_QUERY_LIMITED_INFORMATION,
                    False, parent_pid)
            else:
                source_process = None
            try:
                new_handle = reduction.duplicate(
                    pipe_handle, source_process=source_process)
                fd = msvcrt.open_osfhandle(new_handle, os.O_RDONLY)
                exitcode = _main(fd, source_process)
            except PermissionError:
                if (source_process is None or
                      _winapi.GetExitCodeProcess(source_process) ==
                      _winapi.STILL_ACTIVE):
                    raise
                exitcode = 1
        else:
            from . import resource_tracker
            resource_tracker._resource_tracker._fd = tracker_fd
            exitcode = _main(pipe_handle, os.dup(pipe_handle))

        sys.exit(exitcode)

----------
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.10 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38263>
_______________________________________

From report at bugs.python.org  Tue Mar 30 11:43:21 2021
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 30 Mar 2021 15:43:21 +0000
Subject: [issue42134] Raise ImportWarning when falling back to find_module()
In-Reply-To: <1603494610.04.0.950789467246.issue42134@roundup.psfhosted.org>
Message-ID: <1617119001.29.0.725602899886.issue42134@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:


New changeset a7ff6df60c05e1b69fca743573b1e118bebf121d by Brett Cannon in branch 'master':
bpo-42134: Raise ImportWarning when calling find_module() in the import system (GH-25044)
https://github.com/python/cpython/commit/a7ff6df60c05e1b69fca743573b1e118bebf121d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42134>
_______________________________________

From report at bugs.python.org  Tue Mar 30 11:44:53 2021
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 30 Mar 2021 15:44:53 +0000
Subject: [issue43672] Raise ImportWarning when calling find_loader()
Message-ID: <1617119093.18.0.759506550026.issue43672@roundup.psfhosted.org>


New submission from Brett Cannon <brett at python.org>:

Using find_loader() in the import system should raise ImportWarning to start transitioning people over to find_spec() who haven't migrated since Python 3.4.

----------
assignee: brett.cannon
components: Interpreter Core
messages: 389834
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Raise ImportWarning when calling find_loader()
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43672>
_______________________________________

From report at bugs.python.org  Tue Mar 30 12:04:59 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Mar 2021 16:04:59 +0000
Subject: [issue38263] [Windows] multiprocessing: DupHandle.detach() race
 condition on DuplicateHandle(DUPLICATE_CLOSE_SOURCE)
In-Reply-To: <1569321399.19.0.207011593125.issue38263@roundup.psfhosted.org>
Message-ID: <1617120299.98.0.108001009549.issue38263@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38263>
_______________________________________

From report at bugs.python.org  Tue Mar 30 12:05:37 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 30 Mar 2021 16:05:37 +0000
Subject: [issue43567] regen.vcxproj cannot regenerate some necessary files
In-Reply-To: <1616238138.44.0.687655765468.issue43567@roundup.psfhosted.org>
Message-ID: <1617120337.38.0.181218007397.issue43567@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Can you past the full output from your command?

Also, try making a dummy change (e.g. add a blank line) to each of the input files -- this will trigger the rebuild.

PS. Please don't remove nosy folks unless they request so.

----------
nosy: +anthonypjshaw, lys.nikolaou, pablogsal, paul.moore, steve.dower, tim.golden, vstinner, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43567>
_______________________________________

From report at bugs.python.org  Tue Mar 30 12:11:29 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 30 Mar 2021 16:11:29 +0000
Subject: [issue41369] Update to libmpdec-2.5.1
In-Reply-To: <1595446041.62.0.150992911256.issue41369@roundup.psfhosted.org>
Message-ID: <1617120689.64.0.128419776976.issue41369@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:


New changeset 73b20ae2fb7a5c1374aa5c3719f64c53d29fa0d2 by Antoine Pitrou in branch 'master':
bpo-41369: Finish updating the vendored libmpdec to version 2.5.1 (GH-24962)
https://github.com/python/cpython/commit/73b20ae2fb7a5c1374aa5c3719f64c53d29fa0d2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41369>
_______________________________________

From report at bugs.python.org  Tue Mar 30 12:12:11 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 30 Mar 2021 16:12:11 +0000
Subject: [issue41369] Update to libmpdec-2.5.1
In-Reply-To: <1595446041.62.0.150992911256.issue41369@roundup.psfhosted.org>
Message-ID: <1617120731.82.0.27728014024.issue41369@roundup.psfhosted.org>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41369>
_______________________________________

From report at bugs.python.org  Tue Mar 30 12:45:41 2021
From: report at bugs.python.org (Steve Dower)
Date: Tue, 30 Mar 2021 16:45:41 +0000
Subject: [issue33125] Windows 10 ARM64 platform support
In-Reply-To: <1521767011.97.0.467229070634.issue33125@psf.upfronthosting.co.za>
Message-ID: <1617122741.27.0.0707505162516.issue33125@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Our builds are fine, so there's no need for an issue on our side. The decision to release is based on the ecosystem catching up.

If you're able to help projects like setuptools, pip, and the core parts of the data science stack (which will need the most help) be able to support ARM64 builds (despite the current lack of CI/CD support, which I'm working on separately), that will accelerate us being able to make the ARM64 releases available/supported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33125>
_______________________________________

From report at bugs.python.org  Tue Mar 30 13:07:07 2021
From: report at bugs.python.org (Steve Dower)
Date: Tue, 30 Mar 2021 17:07:07 +0000
Subject: [issue19124] os.execv executes in background on Windows
In-Reply-To: <1380451602.11.0.517013085188.issue19124@psf.upfronthosting.co.za>
Message-ID: <1617124027.51.0.325049037867.issue19124@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> emulating exec() is probably good enough for most cases, especially if code expects to work in Windows.

I think good-enough emulation is fine, but we should update the docs to clarify that non-Unix platforms may create a subprocess with a new PID, and callers should avoid relying on POSIX semantics if they may run on non-compliant platforms.

> If Python implements its own system() and spawnv[e]() functions, support for inheritable file descriptors [1] would probably have to be dropped

I don't see how its behaviour would change at all, unless we're going well out of our way to override the CRT. Which I wouldn't want to see us do.

So let's at least fix the current issue of having the child process break away immediately, by waiting for it and then exiting. Even if that's just swapping the execv call for spawnv(_P_WAIT) and then exiting, that's fine by me (all the CRT calls go through the same path, so they'll launch it consistently regardless of mode).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19124>
_______________________________________

From report at bugs.python.org  Tue Mar 30 13:09:19 2021
From: report at bugs.python.org (Steve Dower)
Date: Tue, 30 Mar 2021 17:09:19 +0000
Subject: [issue37945] [Windows]
 test_locale.TestMiscellaneous.test_getsetlocale_issue1813() fails
In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org>
Message-ID: <1617124159.9.0.809693172512.issue37945@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

This is now holding up some security releases (due to a couple of CVEs). Can we get the test skipped or fixed asap, please?

----------
nosy: +lukasz.langa, ned.deily
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37945>
_______________________________________

From report at bugs.python.org  Tue Mar 30 13:24:17 2021
From: report at bugs.python.org (Martin)
Date: Tue, 30 Mar 2021 17:24:17 +0000
Subject: [issue43656] StackSummary.format fails if str(value) fails
In-Reply-To: <1617010609.77.0.749976985588.issue43656@roundup.psfhosted.org>
Message-ID: <1617125057.25.0.369487299427.issue43656@roundup.psfhosted.org>


Martin <martin.schroeder at nerdluecht.de> added the comment:

I didn't know repr is supposed to always succeed. Does the documentation mention this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43656>
_______________________________________

From report at bugs.python.org  Tue Mar 30 13:30:45 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 30 Mar 2021 17:30:45 +0000
Subject: [issue43567] regen.vcxproj cannot regenerate some necessary files
In-Reply-To: <1616238138.44.0.687655765468.issue43567@roundup.psfhosted.org>
Message-ID: <1617125445.26.0.284128242127.issue43567@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

@Steve, Anthony: I am now in a state where I have *no* changes anywhere, build.bat completes without errors, but build.bat --regen produces this error (after first doing a regular build):

C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\VC\VCTargets\Microsoft.Cpp.Platform.targets(67,5): error MSB8020: The build to
ols for v142 (Platform Toolset = 'v142') cannot be found. To build using the v142 build tools, please install v142 build tools.  Alternatively, you may u 
pgrade to the current Visual Studio tools by selecting the Project menu or right-click the solution, and then selecting "Retarget solution". [C:\Users\gv 
anrossum\cpython\PCbuild\regen.vcxproj]

Help!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43567>
_______________________________________

From report at bugs.python.org  Tue Mar 30 13:31:36 2021
From: report at bugs.python.org (Martin)
Date: Tue, 30 Mar 2021 17:31:36 +0000
Subject: [issue43656] StackSummary.format fails if str(value) fails
In-Reply-To: <1617010609.77.0.749976985588.issue43656@roundup.psfhosted.org>
Message-ID: <1617125496.85.0.222157096055.issue43656@roundup.psfhosted.org>


Martin <martin.schroeder at nerdluecht.de> added the comment:

I can't find any mention of this in the documentation:

https://docs.python.org/3/reference/datamodel.html#object.__repr__

https://docs.python.org/3/library/functions.html#repr

I think this should be mentioned somewhere.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43656>
_______________________________________

From report at bugs.python.org  Tue Mar 30 13:42:28 2021
From: report at bugs.python.org (William (David) Wilcox)
Date: Tue, 30 Mar 2021 17:42:28 +0000
Subject: [issue43673] Missing stub for logging attribute manager
Message-ID: <1617126148.6.0.590806825017.issue43673@roundup.psfhosted.org>


Change by William (David) Wilcox <wdwilcox at doctorondemand.com>:


----------
components: Library (Lib)
nosy: wdwilcox
priority: normal
severity: normal
status: open
title: Missing stub for logging attribute manager
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43673>
_______________________________________

From report at bugs.python.org  Tue Mar 30 14:18:06 2021
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 30 Mar 2021 18:18:06 +0000
Subject: [issue19124] os.execv executes in background on Windows
In-Reply-To: <1380451602.11.0.517013085188.issue19124@psf.upfronthosting.co.za>
Message-ID: <1617128286.77.0.208583507969.issue19124@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> Even if that's just swapping the execv call for spawnv(_P_WAIT) 
> and then exiting, that's fine by me

Maybe call SuspendThread() on other threads, at least the ones that can be enumerated with the threading module.

> I don't see how its behaviour would change at all, unless we're going
> well out of our way to override the CRT. Which I wouldn't want to see 
> us do.

The suggestion was for Python to implement system() and spawnv[e]() using subprocess or _winapi. That would eliminate the problem of leaked handles when subprocess.Popen() is called concurrently with os.system() and os.spawn*(). However, inheritance of file descriptors cannot be reasonably implemented in that case, not without accessing private CRT data (i.e. the internal flags of each file descriptor). 

If os.spawn*() has to continue supporting inheritance of file descriptors, then the idea is probably a non-starter. All we can do is hope that the CRT's common spawn code will eventually use PROC_THREAD_ATTRIBUTE_HANDLE_LIST. This feature only protects against leaked handles (particularly important for pipes) if it's used by all concurrent CreateProcessW() calls that inherit handles.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19124>
_______________________________________

From report at bugs.python.org  Tue Mar 30 14:28:59 2021
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 30 Mar 2021 18:28:59 +0000
Subject: [issue36534] tarfile and zipfile: handling Windows (path) illegal
 characters in archive member names
In-Reply-To: <1554458671.74.0.11308540457.issue36534@roundup.psfhosted.org>
Message-ID: <1617128939.02.0.917264727914.issue36534@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
versions: +Python 3.10 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36534>
_______________________________________

From report at bugs.python.org  Tue Mar 30 14:31:06 2021
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 30 Mar 2021 18:31:06 +0000
Subject: [issue42968] [Windows] multiprocessing handle leak when child process
 is killed during startup/unpickling
In-Reply-To: <1611080656.89.0.981627513492.issue42968@roundup.psfhosted.org>
Message-ID: <1617129066.72.0.877739147949.issue42968@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
title: multiprocessing handle leak on Windows when child process is killed during startup/unpickling -> [Windows] multiprocessing handle leak when child process is killed during startup/unpickling
versions:  -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42968>
_______________________________________

From report at bugs.python.org  Tue Mar 30 14:33:12 2021
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 30 Mar 2021 18:33:12 +0000
Subject: [issue38822] [Windows] Inconsistent os.stat behavior for directory
 with Access Denied
In-Reply-To: <1573928094.88.0.209131085868.issue38822@roundup.psfhosted.org>
Message-ID: <1617129192.42.0.991000190252.issue38822@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
components: +Extension Modules
title: Inconsistent os.stat behavior for directory with Access Denied -> [Windows] Inconsistent os.stat behavior for directory with Access Denied
versions: +Python 3.10 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38822>
_______________________________________

From report at bugs.python.org  Tue Mar 30 14:36:51 2021
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 30 Mar 2021 18:36:51 +0000
Subject: [issue43105] [Windows] Can't import extension modules resolved via
 relative paths in sys.path
In-Reply-To: <1612285380.24.0.495785451269.issue43105@roundup.psfhosted.org>
Message-ID: <1617129411.98.0.451003297666.issue43105@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
components: +Interpreter Core, Library (Lib) -Extension Modules
title: Can't import extension modules resolved via relative paths in sys.path on Windows -> [Windows] Can't import extension modules resolved via relative paths in sys.path
versions:  -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43105>
_______________________________________

From report at bugs.python.org  Tue Mar 30 14:38:27 2021
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 30 Mar 2021 18:38:27 +0000
Subject: [issue29753] [Linux] ctypes packs bitfields Incorrectly
In-Reply-To: <1488933400.56.0.160685455632.issue29753@psf.upfronthosting.co.za>
Message-ID: <1617129507.33.0.863685726699.issue29753@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
title: Ctypes Packing Bitfields Incorrectly - Linux -> [Linux] ctypes packs bitfields Incorrectly
versions: +Python 3.10 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29753>
_______________________________________

From report at bugs.python.org  Tue Mar 30 14:42:22 2021
From: report at bugs.python.org (William (David) Wilcox)
Date: Tue, 30 Mar 2021 18:42:22 +0000
Subject: [issue43673] Missing stub for logging attribute manager
Message-ID: <1617129742.37.0.288626384398.issue43673@roundup.psfhosted.org>


Change by William (David) Wilcox <wdwilcox at doctorondemand.com>:


----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43673>
_______________________________________

From report at bugs.python.org  Tue Mar 30 14:57:45 2021
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 30 Mar 2021 18:57:45 +0000
Subject: [issue43431] Subprocess timeout causes output to be returned as bytes
 in text mode
In-Reply-To: <1615182106.34.0.569482281722.issue43431@roundup.psfhosted.org>
Message-ID: <1617130665.25.0.654606787672.issue43431@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
versions:  -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43431>
_______________________________________

From report at bugs.python.org  Tue Mar 30 15:08:31 2021
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 30 Mar 2021 19:08:31 +0000
Subject: [issue32671] redesign Windows  os.getlogin, and add os.getuser
In-Reply-To: <1516929444.23.0.467229070634.issue32671@psf.upfronthosting.co.za>
Message-ID: <1617131311.17.0.68276491443.issue32671@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
resolution:  -> rejected
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32671>
_______________________________________

From report at bugs.python.org  Tue Mar 30 15:08:43 2021
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 30 Mar 2021 19:08:43 +0000
Subject: [issue42134] Raise ImportWarning when falling back to find_module()
In-Reply-To: <1603494610.04.0.950789467246.issue42134@roundup.psfhosted.org>
Message-ID: <1617131323.31.0.587886816878.issue42134@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/issue42134>
_______________________________________

From report at bugs.python.org  Tue Mar 30 15:08:51 2021
From: report at bugs.python.org (Martin)
Date: Tue, 30 Mar 2021 19:08:51 +0000
Subject: [issue39228] traceback.FrameSummary does not handle exceptions from
 `repr()`
In-Reply-To: <1578284065.37.0.657086816746.issue39228@roundup.psfhosted.org>
Message-ID: <1617131331.18.0.60501483766.issue39228@roundup.psfhosted.org>


Martin <martin.schroeder at nerdluecht.de> added the comment:

> As is true for most special methods, it is a bug for __repr__ methods to raise.

Is this codified anywhere? I only learned about that in this bug report.

----------
nosy: +moi90

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39228>
_______________________________________

From report at bugs.python.org  Tue Mar 30 15:20:34 2021
From: report at bugs.python.org (E. Paine)
Date: Tue, 30 Mar 2021 19:20:34 +0000
Subject: [issue43671] segfault when using tkinter + pygame for ~5 minutes
In-Reply-To: <1617114887.1.0.547947822619.issue43671@roundup.psfhosted.org>
Message-ID: <1617132034.58.0.324122492538.issue43671@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

Not sure why this was marked as a problem with tkinter (neither Pygame nor the example use it). I would be very surprised if this wasn't an issue with Pygame, as the Python is just requesting a dictionary deallocation which is then handled by Pygame's `font.cpython-39-darwin.so`.

----------
nosy: +epaine, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43671>
_______________________________________

From report at bugs.python.org  Tue Mar 30 15:33:12 2021
From: report at bugs.python.org (Pycrytor10)
Date: Tue, 30 Mar 2021 19:33:12 +0000
Subject: [issue43671] segfault when using tkinter + pygame for ~5 minutes
In-Reply-To: <1617114887.1.0.547947822619.issue43671@roundup.psfhosted.org>
Message-ID: <1617132792.67.0.00964356425321.issue43671@roundup.psfhosted.org>


Pycrytor10 <samueljkirwin at gmail.com> added the comment:

My original script has tkinter used as well. I wasn't entirely sure where it was when I filed the bug at first and just saw a tk/tcl mentioned in the logs. It does look now I've managed to investigate further to be something in pygame. I've never had to debug a segfault before.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43671>
_______________________________________

From report at bugs.python.org  Tue Mar 30 15:35:23 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Mar 2021 19:35:23 +0000
Subject: [issue36384] ipaddress Should not reject IPv4 addresses with leading
 zeroes as ambiguously octal
In-Reply-To: <1553125209.55.0.0358803413865.issue36384@roundup.psfhosted.org>
Message-ID: <1617132923.38.0.818679738861.issue36384@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> The patch should not have landed in 3.8. At a bare minimum the patch should have been postponed until documentation was updated. Since 3.8 the ipaddresss does not behave as documented. A similar security issue in NPM was published two days ago, CVE-2021-28918.

Link: https://sick.codes/sick-2021-011

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36384>
_______________________________________

From report at bugs.python.org  Tue Mar 30 15:37:29 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Mar 2021 19:37:29 +0000
Subject: [issue36534] tarfile and zipfile: handling Windows (path) illegal
 characters in archive member names
In-Reply-To: <1554458671.74.0.11308540457.issue36534@roundup.psfhosted.org>
Message-ID: <1617133049.31.0.841418895506.issue36534@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36534>
_______________________________________

From report at bugs.python.org  Tue Mar 30 15:50:29 2021
From: report at bugs.python.org (TW)
Date: Tue, 30 Mar 2021 19:50:29 +0000
Subject: [issue43674] strange effect at recursion limit
Message-ID: <1617133829.55.0.126108093558.issue43674@roundup.psfhosted.org>


New submission from TW <tw at waldmann-edv.de>:

user at development:~$ python3
Python 3.7.3 (default, Jan 22 2021, 20:04:44) 
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

def recurse(n):
    print(n)
    try:
        recurse(n+1)
    except RecursionError:
        print("recursion error")
    print(n)


Please note that there are 2 print(n) on the same level.

>>> recurse(0)
0
1
2
...
994
995
recursion error
994
993
...
2
1
0

Why is there no 2nd 995 after the recursion error?

Same happens for python 3.8.8 and 3.9.2.

Related question:

I also tried to set sys.setrecursionlimit(100000) and ran recurse(0), but at a bit beyond 21800, it just segfaulted.

Is there a way to determine the practically working maximum it can do?

----------
components: Interpreter Core
messages: 389848
nosy: ThomasWaldmann2
priority: normal
severity: normal
status: open
title: strange effect at recursion limit
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43674>
_______________________________________

From report at bugs.python.org  Tue Mar 30 16:09:12 2021
From: report at bugs.python.org (Michael Osipov)
Date: Tue, 30 Mar 2021 20:09:12 +0000
Subject: [issue30511] shutil.make_archive should not need to chdir
 (alternatively: make shutil.make_archive thread-safe)
In-Reply-To: <1496151978.87.0.20600653197.issue30511@psf.upfronthosting.co.za>
Message-ID: <1617134952.1.0.370169713371.issue30511@roundup.psfhosted.org>


Michael Osipov <1983-01-06 at gmx.net> added the comment:

Just wasted two hours for this. Can someone really update the documentation of it if this is not going to change.

----------
nosy: +michael-o

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30511>
_______________________________________

From report at bugs.python.org  Tue Mar 30 16:27:22 2021
From: report at bugs.python.org (Neil Schemenauer)
Date: Tue, 30 Mar 2021 20:27:22 +0000
Subject: [issue37368] test_asyncio: test_create_server_ssl_match_failed()
 failed on s390x SLES 3.x and logged an unraisable exception
In-Reply-To: <1561151330.27.0.514257001535.issue37368@roundup.psfhosted.org>
Message-ID: <1617136042.77.0.736383271179.issue37368@roundup.psfhosted.org>


Neil Schemenauer <nas-python at arctrix.com> added the comment:

It seems to not be specific to S390, same kind of failure on the PPC64LE RHEL8 LTO + PGE 3.x tester:

Exception ignored in: <function _SSLProtocolTransport.__del__ at 0x7fff83777520>
Traceback (most recent call last):                                              
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-ppc64le.lto-pgo/build/Lib/asyncio/sslproto.py", line 321, in __del__
    self.close()                                                                
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-ppc64le.lto-pgo/build/Lib/asyncio/sslproto.py", line 316, in close
    self._ssl_protocol._start_shutdown()                                        
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-ppc64le.lto-pgo/build/Lib/asyncio/sslproto.py", line 590, in _start_shutdown
    self._abort()                                                               
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-ppc64le.lto-pgo/build/Lib/asyncio/sslproto.py", line 731, in _abort
    self._transport.abort()                                                     
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-ppc64le.lto-pgo/build/Lib/asyncio/selector_events.py", line 680, in abort
    self._force_close(None)                                                     
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-ppc64le.lto-pgo/build/Lib/asyncio/selector_events.py", line 731, in _force_close
    self._loop.call_soon(self._call_connection_lost, exc)                       
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-ppc64le.lto-pgo/build/Lib/asyncio/base_events.py", line 745, in call_soon
    self._check_closed()                                                        
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-ppc64le.lto-pgo/build/Lib/asyncio/base_events.py", line 510, in _check_closed
    raise RuntimeError('Event loop is closed')                                  
RuntimeError: Event loop is closed

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37368>
_______________________________________

From report at bugs.python.org  Tue Mar 30 16:49:50 2021
From: report at bugs.python.org (Zveinn)
Date: Tue, 30 Mar 2021 20:49:50 +0000
Subject: [issue43332] Make http.client._tunnel send one byte string over the
 network
In-Reply-To: <1614370680.1.0.103129903648.issue43332@roundup.psfhosted.org>
Message-ID: <1617137390.22.0.947307969155.issue43332@roundup.psfhosted.org>


Zveinn <sveinn at zkynet.io> added the comment:

No problem, 

Hopefully this will improve the performance on some network devices and proxy services.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43332>
_______________________________________

From report at bugs.python.org  Tue Mar 30 17:10:19 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 30 Mar 2021 21:10:19 +0000
Subject: [issue39228] traceback.FrameSummary does not handle exceptions from
 `repr()`
In-Reply-To: <1578284065.37.0.657086816746.issue39228@roundup.psfhosted.org>
Message-ID: <1617138619.32.0.148726358242.issue39228@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

__repr__() and repr() can raise exceptions. Silencing arbitrary exception is usually a bad idea. Even correctly raised code can raise exceptions such as MemoryError, RecursionError and KeybordInterrupt.

For this reason I think that the proposed change should not be made.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39228>
_______________________________________

From report at bugs.python.org  Tue Mar 30 17:11:49 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 30 Mar 2021 21:11:49 +0000
Subject: [issue43399] xml.etree.ElementTree.extend does not work with
 iterators when using the Python implementation
In-Reply-To: <1614873561.76.0.875762243403.issue43399@roundup.psfhosted.org>
Message-ID: <1617138709.63.0.352333919121.issue43399@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 51a85ddce8b336addcb61b96f04c9c5edef07296 by Alex Preng?re in branch 'master':
bpo-43399: Fix ElementTree.extend not working on iterators (GH-24751)
https://github.com/python/cpython/commit/51a85ddce8b336addcb61b96f04c9c5edef07296


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43399>
_______________________________________

From report at bugs.python.org  Tue Mar 30 17:12:35 2021
From: report at bugs.python.org (miss-islington)
Date: Tue, 30 Mar 2021 21:12:35 +0000
Subject: [issue43399] xml.etree.ElementTree.extend does not work with
 iterators when using the Python implementation
In-Reply-To: <1614873561.76.0.875762243403.issue43399@roundup.psfhosted.org>
Message-ID: <1617138755.73.0.651413329342.issue43399@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: +23846
pull_request: https://github.com/python/cpython/pull/25101

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43399>
_______________________________________

From report at bugs.python.org  Tue Mar 30 17:12:46 2021
From: report at bugs.python.org (miss-islington)
Date: Tue, 30 Mar 2021 21:12:46 +0000
Subject: [issue43399] xml.etree.ElementTree.extend does not work with
 iterators when using the Python implementation
In-Reply-To: <1614873561.76.0.875762243403.issue43399@roundup.psfhosted.org>
Message-ID: <1617138766.45.0.477594510985.issue43399@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +23847
pull_request: https://github.com/python/cpython/pull/25102

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43399>
_______________________________________

From report at bugs.python.org  Tue Mar 30 17:20:31 2021
From: report at bugs.python.org (Aysal Marandian)
Date: Tue, 30 Mar 2021 21:20:31 +0000
Subject: [issue43675] test
Message-ID: <1617139231.76.0.428039980824.issue43675@roundup.psfhosted.org>


Change by Aysal Marandian <aysal.marandian at gmail.com>:


----------
nosy: aysal.marandian
priority: normal
severity: normal
status: open
title: test

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43675>
_______________________________________

From report at bugs.python.org  Tue Mar 30 17:20:55 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 30 Mar 2021 21:20:55 +0000
Subject: [issue28276] test_loading.py - false positive result for "def
 test_find" when find_library() is not functional or the (shared) library does
 not exist
In-Reply-To: <1474887883.6.0.275550575314.issue28276@psf.upfronthosting.co.za>
Message-ID: <1617139255.9.0.499463560565.issue28276@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Concur. Also you can add "ssl" to the list of tested names if both "c" and "m" fail on AIX.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28276>
_______________________________________

From report at bugs.python.org  Tue Mar 30 17:21:26 2021
From: report at bugs.python.org (Aysal Marandian)
Date: Tue, 30 Mar 2021 21:21:26 +0000
Subject: [issue43675] test
Message-ID: <1617139286.08.0.448947694351.issue43675@roundup.psfhosted.org>


New submission from Aysal Marandian <aysal.marandian at gmail.com>:

test out python

----------
resolution:  -> not a bug
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43675>
_______________________________________

From report at bugs.python.org  Tue Mar 30 17:23:22 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 30 Mar 2021 21:23:22 +0000
Subject: [issue43399] xml.etree.ElementTree.extend does not work with
 iterators when using the Python implementation
In-Reply-To: <1614873561.76.0.875762243403.issue43399@roundup.psfhosted.org>
Message-ID: <1617139402.97.0.408942923043.issue43399@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Pinging us was the only action needed. Thank you for your contribution Alex.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43399>
_______________________________________

From report at bugs.python.org  Tue Mar 30 17:23:39 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 30 Mar 2021 21:23:39 +0000
Subject: [issue43675] test
In-Reply-To: <1617139286.08.0.448947694351.issue43675@roundup.psfhosted.org>
Message-ID: <1617139419.65.0.495997230023.issue43675@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43675>
_______________________________________

From report at bugs.python.org  Tue Mar 30 17:33:03 2021
From: report at bugs.python.org (miss-islington)
Date: Tue, 30 Mar 2021 21:33:03 +0000
Subject: [issue43399] xml.etree.ElementTree.extend does not work with
 iterators when using the Python implementation
In-Reply-To: <1614873561.76.0.875762243403.issue43399@roundup.psfhosted.org>
Message-ID: <1617139983.08.0.216849348809.issue43399@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c1079cde2a7676892a9b98703903206b7d26ed1f by Miss Islington (bot) in branch '3.8':
bpo-43399: Fix ElementTree.extend not working on iterators (GH-24751)
https://github.com/python/cpython/commit/c1079cde2a7676892a9b98703903206b7d26ed1f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43399>
_______________________________________

From report at bugs.python.org  Tue Mar 30 17:36:33 2021
From: report at bugs.python.org (miss-islington)
Date: Tue, 30 Mar 2021 21:36:33 +0000
Subject: [issue43399] xml.etree.ElementTree.extend does not work with
 iterators when using the Python implementation
In-Reply-To: <1614873561.76.0.875762243403.issue43399@roundup.psfhosted.org>
Message-ID: <1617140193.11.0.356349146665.issue43399@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b500bd8e672d15c6dfa24568a3264fdc0f3e0c01 by Miss Islington (bot) in branch '3.9':
bpo-43399: Fix ElementTree.extend not working on iterators (GH-24751)
https://github.com/python/cpython/commit/b500bd8e672d15c6dfa24568a3264fdc0f3e0c01


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43399>
_______________________________________

From report at bugs.python.org  Tue Mar 30 17:38:26 2021
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 30 Mar 2021 21:38:26 +0000
Subject: [issue39228] traceback.FrameSummary does not handle exceptions from
 `repr()`
In-Reply-To: <1578284065.37.0.657086816746.issue39228@roundup.psfhosted.org>
Message-ID: <1617140306.63.0.838136555228.issue39228@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

If we decide to reject this then we should add unit tests that show this state of affairs is deliberate.

----------
nosy: +iritkatriel

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39228>
_______________________________________

From report at bugs.python.org  Tue Mar 30 17:42:43 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 30 Mar 2021 21:42:43 +0000
Subject: [issue41461] test_pathlib assumes underlying filesystem permits
 creation with world-write permissions
In-Reply-To: <1596438406.32.0.128608739111.issue41461@roundup.psfhosted.org>
Message-ID: <1617140563.1.0.139299848677.issue41461@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

umask(0o002) looks good idea (and perhaps umask(0o026) instead of umask(0o022)). Please add also a short explanation comment.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41461>
_______________________________________

From report at bugs.python.org  Tue Mar 30 17:46:40 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 30 Mar 2021 21:46:40 +0000
Subject: [issue39228] traceback.FrameSummary does not handle exceptions from
 `repr()`
In-Reply-To: <1578284065.37.0.657086816746.issue39228@roundup.psfhosted.org>
Message-ID: <1617140800.51.0.17792996788.issue39228@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

See also issue43656.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39228>
_______________________________________

From report at bugs.python.org  Tue Mar 30 17:53:33 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 30 Mar 2021 21:53:33 +0000
Subject: [issue43655] Tkinter: Not setting _NET_WM_WINDOW_TYPE on FileDialog
In-Reply-To: <1617008023.65.0.620967294098.issue43655@roundup.psfhosted.org>
Message-ID: <1617141213.3.0.111428441467.issue43655@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

No, it is not ready for publishing yet. I'll try to work on it on the next weekend. Since it is a large change, there is a risk of breaking user code, so perhaps it would be worth to separate changes related to this issue which can be backported.

----------
versions:  -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43655>
_______________________________________

From report at bugs.python.org  Tue Mar 30 18:36:59 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 30 Mar 2021 22:36:59 +0000
Subject: [issue43567] regen.vcxproj cannot regenerate some necessary files
In-Reply-To: <1617125445.26.0.284128242127.issue43567@roundup.psfhosted.org>
Message-ID: <CAP7+vJJ8jjyLhN03c4Z9qd=LxEnWdd7y+cpirHZUWKz_VPOkLQ@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

FWIW, could this issue recently merged by Victor be related?
bpo-43244: Remove ast.h, asdl.h, Python-ast.h headers (GH-24933)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43567>
_______________________________________

From report at bugs.python.org  Tue Mar 30 19:06:32 2021
From: report at bugs.python.org (Brad Warren)
Date: Tue, 30 Mar 2021 23:06:32 +0000
Subject: [issue43631] Update to OpenSSL 1.1.1k
In-Reply-To: <1616746538.63.0.13329268116.issue43631@roundup.psfhosted.org>
Message-ID: <1617145592.04.0.719155904546.issue43631@roundup.psfhosted.org>


Brad Warren <bradmwarren at gmail.com> added the comment:

To be fair, I doubt my project is affected by the CVEs. I was just looking to upgrade instead of trying to verify that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43631>
_______________________________________

From report at bugs.python.org  Tue Mar 30 20:35:09 2021
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 31 Mar 2021 00:35:09 +0000
Subject: [issue43674] strange effect at recursion limit
In-Reply-To: <1617133829.55.0.126108093558.issue43674@roundup.psfhosted.org>
Message-ID: <1617150909.93.0.688623939152.issue43674@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> Why is there no 2nd 995 after the recursion error?

print(s) calls sys.stdout.write(s) and sys.stdout.write("\n"). The I/O stack consists of a text I/O wrapper, buffered writer, and a raw file object. What happens in this case is that writing "\n" causes the text wrapper to flush the buffer, which flushes to the raw file. Calling the latter's write() method raises a RecursionError. But "995\n" is still buffered and gets written out later on when the exception handler prints "recursion error".

Try replacing print() with low-level os.write(1, bytes_text). For example:

    import os

    def recurse(n):
        os.write(1, f'{n}\n'.encode())
        try:
            recurse(n + 1)
        except RecursionError:
            os.write(1, b'recursion error\n')
        os.write(1, f'{n}\n'.encode())

> Is there a way to determine the practically working maximum it can do?

The size of a C stack frame varies depending on the C function call, compiler optimizations, and the platform.

If you need to increase the recursion limit (not recommended) by a given factor, I suggest calling the recursive function in a new thread that has a stack size that's increased by the same factor over the default limit (depends on the platform). The stack size for new threads is set via old_size = threading.stack_size(new_size). Make sure that the already running threads (e.g. the main thread) that use the default stack size are executing code that stays well below the original recursion limit, else this could crash the interpreter.

In Windows, the default stack size is 2 MiB, and the maximum size that Python allows is one byte less than 256 MiB (268,435,455), which is about 128 times the default size. The largest size should safely (conservatively) support a recursion limit of 128,000 frames. With the above recurse() function, I tested that the maximum stack size crashes with a stack overflow at about 325,000 frames.

----------
nosy: +eryksun
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
versions: +Python 3.10 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43674>
_______________________________________

From report at bugs.python.org  Tue Mar 30 20:37:01 2021
From: report at bugs.python.org (Jiaxin Peng)
Date: Wed, 31 Mar 2021 00:37:01 +0000
Subject: [issue43567] regen.vcxproj cannot regenerate some necessary files
In-Reply-To: <1616238138.44.0.687655765468.issue43567@roundup.psfhosted.org>
Message-ID: <1617151021.13.0.828010600094.issue43567@roundup.psfhosted.org>


Change by Jiaxin Peng <pjx206 at 163.com>:


----------
nosy:  -anthonypjshaw, lys.nikolaou, pablogsal, paul.moore, pjx206, steve.dower, tim.golden, vstinner, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43567>
_______________________________________

From report at bugs.python.org  Tue Mar 30 20:42:35 2021
From: report at bugs.python.org (Jiaxin Peng)
Date: Wed, 31 Mar 2021 00:42:35 +0000
Subject: [issue43567] regen.vcxproj cannot regenerate some necessary files
In-Reply-To: <1616238138.44.0.687655765468.issue43567@roundup.psfhosted.org>
Message-ID: <1617151355.24.0.36774267954.issue43567@roundup.psfhosted.org>


Jiaxin Peng <pjx206 at 163.com> added the comment:

`build.bat --regen` produces such error because it uses build tool from visual studio to build regen.vcxproj, and you do not have v142 toolset. I'm using vs2019 and have v142 toolset installed and regen.vcxproj workd, just cannot actually regenerate files needed completely.

----------
nosy: +pjx206

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43567>
_______________________________________

From report at bugs.python.org  Tue Mar 30 23:09:40 2021
From: report at bugs.python.org (David Bolen)
Date: Wed, 31 Mar 2021 03:09:40 +0000
Subject: [issue37945] [Windows]
 test_locale.TestMiscellaneous.test_getsetlocale_issue1813() fails
In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org>
Message-ID: <1617160180.39.0.326277669728.issue37945@roundup.psfhosted.org>


David Bolen <db3l.net at gmail.com> added the comment:

In lieu of the patch in #25191, what about a pair of skips to deal with the issues at hand without killing the test entirely?  I'm including OpenBSD since those issues were closed in favor of this one, and am assuming that skipping there is also appropriate.

--- a/Lib/test/test_locale.py
+++ b/Lib/test/test_locale.py
@@ -552,6 +552,10 @@ def test_setlocale_category(self):
         # crasher from bug #7419
         self.assertRaises(locale.Error, locale.setlocale, 12345)
 
+    @unittest.skipIf(sys.platform == 'win32',
+                     "Test broken on Windows (issue #37945)")
+    @unittest.skipIf(sys.platform.startswith('openbsd'),
+                     "Test broken on OpenBSD (issues #31636 and #25191)")
     def test_getsetlocale_issue1813(self):
         # Issue #1813: setting and getting the locale under a Turkish locale
         oldlocale = locale.setlocale(locale.LC_CTYPE)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37945>
_______________________________________

From report at bugs.python.org  Tue Mar 30 23:49:08 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 31 Mar 2021 03:49:08 +0000
Subject: [issue43567] regen.vcxproj cannot regenerate some necessary files
In-Reply-To: <1616238138.44.0.687655765468.issue43567@roundup.psfhosted.org>
Message-ID: <1617162548.65.0.571679290017.issue43567@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

So is there a bug in regen.vcxproj, or in https://devguide.python.org/setup/#windows-compiling ? The latter says VS 2017.

@pjx206: please stop clearing out the nosy list. You've done that twice now. If you do it again, I'll close this issue.

----------
nosy: +steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43567>
_______________________________________

From report at bugs.python.org  Wed Mar 31 00:17:40 2021
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 31 Mar 2021 04:17:40 +0000
Subject: [issue40066] Enum: modify __repr__, __str__; update docs
In-Reply-To: <1585165738.23.0.618463548627.issue40066@roundup.psfhosted.org>
Message-ID: <1617164260.63.0.783640870332.issue40066@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:


New changeset b775106d940e3d77c8af7967545bb9a5b7b162df by Ethan Furman in branch 'master':
bpo-40066: Enum: modify `repr()` and `str()` (GH-22392)
https://github.com/python/cpython/commit/b775106d940e3d77c8af7967545bb9a5b7b162df


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40066>
_______________________________________

From report at bugs.python.org  Wed Mar 31 00:20:19 2021
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 31 Mar 2021 04:20:19 +0000
Subject: [issue43651] PEP 597: Fix EncodingWarning warnings in the Python
 stdlib
Message-ID: <1617164419.66.0.739984723997.issue43651@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
superseder:  -> PEP 597: Implemente encoding="locale" option and EncodingWarning

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43651>
_______________________________________

From report at bugs.python.org  Wed Mar 31 00:21:53 2021
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 31 Mar 2021 04:21:53 +0000
Subject: [issue43510] PEP 597: Implemente encoding="locale" option and
 EncodingWarning
In-Reply-To: <1615868389.17.0.260147645451.issue43510@roundup.psfhosted.org>
Message-ID: <1617164513.69.0.88988824713.issue43510@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +23848
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/25103

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43510>
_______________________________________

From report at bugs.python.org  Wed Mar 31 00:24:10 2021
From: report at bugs.python.org (Jiaxin Peng)
Date: Wed, 31 Mar 2021 04:24:10 +0000
Subject: [issue43567] regen.vcxproj cannot regenerate some necessary files
In-Reply-To: <1616238138.44.0.687655765468.issue43567@roundup.psfhosted.org>
Message-ID: <1617164650.37.0.563077240876.issue43567@roundup.psfhosted.org>


Jiaxin Peng <pjx206 at 163.com> added the comment:

The regen.vcxproj was modified but not test well. In the first version of regen.vcxproj there were such build targets:

_RegenGrammar(BeforeTargets="Build") -> _RegenAST_H -> _RegenAST_C -> _RegenOpcodes -> _RegenTokens -> _RegenKeywords -> _RegenSymbols

In commit 1ed83ad: bpo-40939: Remove the old parser (GH-20768),
"_RegenGrammar" was removed, but there's still "_RegenAST_H" as AfterTargets of "_RegenGrammar".

@gvanrossum sorry about removing nosy folks, This website displays in my language so I did not realize what is "nosy list".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43567>
_______________________________________

From report at bugs.python.org  Wed Mar 31 00:57:59 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 31 Mar 2021 04:57:59 +0000
Subject: [issue43567] regen.vcxproj cannot regenerate some necessary files
In-Reply-To: <1616238138.44.0.687655765468.issue43567@roundup.psfhosted.org>
Message-ID: <1617166679.52.0.695559782169.issue43567@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
nosy: +pablogsal, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43567>
_______________________________________

From report at bugs.python.org  Wed Mar 31 01:19:47 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 31 Mar 2021 05:19:47 +0000
Subject: [issue42225] Tkinter hangs or crashes when displaying astral chars
In-Reply-To: <1604200632.47.0.347759375724.issue42225@roundup.psfhosted.org>
Message-ID: <1617167987.57.0.956458283451.issue42225@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 1b4a9c7956d5dc64f8002f62bf0faae2d1892f90 by Terry Jan Reedy in branch 'master':
bpo-42225: IDLE - document two unix-related problems. (#25078)
https://github.com/python/cpython/commit/1b4a9c7956d5dc64f8002f62bf0faae2d1892f90


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42225>
_______________________________________

From report at bugs.python.org  Wed Mar 31 01:19:58 2021
From: report at bugs.python.org (miss-islington)
Date: Wed, 31 Mar 2021 05:19:58 +0000
Subject: [issue42225] Tkinter hangs or crashes when displaying astral chars
In-Reply-To: <1604200632.47.0.347759375724.issue42225@roundup.psfhosted.org>
Message-ID: <1617167998.57.0.256350517002.issue42225@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: +23849
pull_request: https://github.com/python/cpython/pull/25105

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42225>
_______________________________________

From report at bugs.python.org  Wed Mar 31 01:20:08 2021
From: report at bugs.python.org (miss-islington)
Date: Wed, 31 Mar 2021 05:20:08 +0000
Subject: [issue42225] Tkinter hangs or crashes when displaying astral chars
In-Reply-To: <1604200632.47.0.347759375724.issue42225@roundup.psfhosted.org>
Message-ID: <1617168008.36.0.775548315894.issue42225@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +23850
pull_request: https://github.com/python/cpython/pull/25106

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42225>
_______________________________________

From report at bugs.python.org  Wed Mar 31 01:21:48 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 31 Mar 2021 05:21:48 +0000
Subject: [issue42225] Tkinter hangs or crashes when displaying astral chars
In-Reply-To: <1604200632.47.0.347759375724.issue42225@roundup.psfhosted.org>
Message-ID: <1617168108.41.0.995197868436.issue42225@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

On macOS with 3.10.0a, 8.6.11 appears to fix this issue.
>>> chr(128516)
"?"

For IDLE, I am adding a paragraph to the doc.  I will then close this issue as 'fixed' (insofar as we can for what is a 3rd party failure).

----------
stage: patch review -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42225>
_______________________________________

From report at bugs.python.org  Wed Mar 31 01:26:15 2021
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 31 Mar 2021 05:26:15 +0000
Subject: [issue43510] PEP 597: Implemente encoding="locale" option and
 EncodingWarning
In-Reply-To: <1615868389.17.0.260147645451.issue43510@roundup.psfhosted.org>
Message-ID: <1617168375.27.0.696239204238.issue43510@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset ff3c9739bd69aa8b58007e63c9e40e6708b4761e by Inada Naoki in branch 'master':
bpo-43510: PEP 597: Accept `encoding="locale"` in binary mode (GH-25103)
https://github.com/python/cpython/commit/ff3c9739bd69aa8b58007e63c9e40e6708b4761e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43510>
_______________________________________

From report at bugs.python.org  Wed Mar 31 01:31:48 2021
From: report at bugs.python.org (Tim Hatch)
Date: Wed, 31 Mar 2021 05:31:48 +0000
Subject: [issue43676] Doctest ELLIPSIS explanation hard to follow when they're
 missing
Message-ID: <1617168708.15.0.0628240300897.issue43676@roundup.psfhosted.org>


New submission from Tim Hatch <tshatch at gmail.com>:

The doctest docs try to explain directives like ELLIPSIS but those directives are absent from the rendered html.

Where?

Most of the code blocks in the Directives section, and https://docs.python.org/3/library/doctest.html#directives and the one introduced by "nice approach" subsequently are missing their directive comments.

The docs today say they go with Python 3.9.2 generated by Sphinx 2.4.4.  I haven't tried generating them manually, but it appears the `pycon` lexer for Pygments handles these fine, so I assume it's a problem in reST.

----------
assignee: docs at python
components: Documentation
messages: 389874
nosy: Tim.Hatch, docs at python
priority: normal
severity: normal
status: open
title: Doctest ELLIPSIS explanation hard to follow when they're missing
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43676>
_______________________________________

From report at bugs.python.org  Wed Mar 31 01:40:21 2021
From: report at bugs.python.org (miss-islington)
Date: Wed, 31 Mar 2021 05:40:21 +0000
Subject: [issue42225] Tkinter hangs or crashes when displaying astral chars
In-Reply-To: <1604200632.47.0.347759375724.issue42225@roundup.psfhosted.org>
Message-ID: <1617169221.23.0.405968403787.issue42225@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e92923b028024290a0e621b6b90e3221767d14d4 by Miss Islington (bot) in branch '3.8':
bpo-42225: IDLE - document two unix-related problems. (GH-25078)
https://github.com/python/cpython/commit/e92923b028024290a0e621b6b90e3221767d14d4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42225>
_______________________________________

From report at bugs.python.org  Wed Mar 31 01:44:34 2021
From: report at bugs.python.org (miss-islington)
Date: Wed, 31 Mar 2021 05:44:34 +0000
Subject: [issue42225] Tkinter hangs or crashes when displaying astral chars
In-Reply-To: <1604200632.47.0.347759375724.issue42225@roundup.psfhosted.org>
Message-ID: <1617169474.74.0.403179979698.issue42225@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 84694c3e7adadc97d7d8cee938fe84bbeb961387 by Miss Islington (bot) in branch '3.9':
bpo-42225: IDLE - document two unix-related problems. (GH-25078)
https://github.com/python/cpython/commit/84694c3e7adadc97d7d8cee938fe84bbeb961387


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42225>
_______________________________________

From report at bugs.python.org  Wed Mar 31 01:53:00 2021
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 31 Mar 2021 05:53:00 +0000
Subject: [issue43510] PEP 597: Implemente encoding="locale" option and
 EncodingWarning
In-Reply-To: <1615868389.17.0.260147645451.issue43510@roundup.psfhosted.org>
Message-ID: <1617169980.19.0.00010002471577.issue43510@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +23851
pull_request: https://github.com/python/cpython/pull/25107

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43510>
_______________________________________

From report at bugs.python.org  Wed Mar 31 02:23:33 2021
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 31 Mar 2021 06:23:33 +0000
Subject: [issue43510] PEP 597: Implemente encoding="locale" option and
 EncodingWarning
In-Reply-To: <1615868389.17.0.260147645451.issue43510@roundup.psfhosted.org>
Message-ID: <1617171813.33.0.779372662254.issue43510@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

I'm sorry, I was wrong. Allowing `encoding="locale"` didn't help OpenWrapper. See GH-25107.

If we use `encoding = text_encoding(encoding)` in binary mode, `open(filename, "rb")` will be warned. This doesn't make sense at all.

Adding `mode` parameter to the `text_encoding()` doesn't make sense too. Because it is used for functions wrapping not only open(), but also TextIOWrapper().

So we must not call `text_encoding()` in binary mode. Allowing `encoding="locale"` in binary mode doesn't make it easy. I will revert GH-25103.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43510>
_______________________________________

From report at bugs.python.org  Wed Mar 31 02:24:20 2021
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 31 Mar 2021 06:24:20 +0000
Subject: [issue43510] PEP 597: Implemente encoding="locale" option and
 EncodingWarning
In-Reply-To: <1615868389.17.0.260147645451.issue43510@roundup.psfhosted.org>
Message-ID: <1617171860.04.0.9458449353.issue43510@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +23852
pull_request: https://github.com/python/cpython/pull/25108

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43510>
_______________________________________

From report at bugs.python.org  Wed Mar 31 03:11:56 2021
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 31 Mar 2021 07:11:56 +0000
Subject: [issue43510] PEP 597: Implemente encoding="locale" option and
 EncodingWarning
In-Reply-To: <1615868389.17.0.260147645451.issue43510@roundup.psfhosted.org>
Message-ID: <1617174716.46.0.398280115374.issue43510@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
Removed message: https://bugs.python.org/msg389828

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43510>
_______________________________________

From report at bugs.python.org  Wed Mar 31 04:05:44 2021
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 31 Mar 2021 08:05:44 +0000
Subject: [issue43651] PEP 597: Fix EncodingWarning warnings in the Python
 stdlib
Message-ID: <1617177944.75.0.08427214982.issue43651@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +23853
pull_request: https://github.com/python/cpython/pull/25109

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43651>
_______________________________________

From report at bugs.python.org  Wed Mar 31 04:54:04 2021
From: report at bugs.python.org (=?utf-8?q?George-Cristian_B=C3=AErzan?=)
Date: Wed, 31 Mar 2021 08:54:04 +0000
Subject: [issue36384] ipaddress Should not reject IPv4 addresses with leading
 zeroes as ambiguously octal
In-Reply-To: <1553125209.55.0.0358803413865.issue36384@roundup.psfhosted.org>
Message-ID: <1617180844.93.0.354513820951.issue36384@roundup.psfhosted.org>


Change by George-Cristian B?rzan <gc at birzan.org>:


----------
nosy: +gc2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36384>
_______________________________________

From report at bugs.python.org  Wed Mar 31 04:58:05 2021
From: report at bugs.python.org (Daniel Torres)
Date: Wed, 31 Mar 2021 08:58:05 +0000
Subject: [issue43677] Documentation
Message-ID: <1617181085.74.0.392624279534.issue43677@roundup.psfhosted.org>


New submission from Daniel Torres <dto at fastmail.com>:

https://github.com/python/cpython/blob/master/Doc/howto/descriptor.rst

Section 'Functions and methods' 

The provided example contains comment 'Emulate Py_MethodType in Objects/classobject.c'

But Py_MethodType is nowhere to be found under 'Objects/classobject.c'

----------
assignee: docs at python
components: Documentation
messages: 389878
nosy: danielcft, docs at python
priority: normal
severity: normal
status: open
title: Documentation
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43677>
_______________________________________

From report at bugs.python.org  Wed Mar 31 05:24:55 2021
From: report at bugs.python.org (Daniel Torres)
Date: Wed, 31 Mar 2021 09:24:55 +0000
Subject: [issue43677] Descriptor Documentation - Reference to Py_MethodType is
 not up to date
In-Reply-To: <1617181085.74.0.392624279534.issue43677@roundup.psfhosted.org>
Message-ID: <1617182695.94.0.184844636335.issue43677@roundup.psfhosted.org>


Change by Daniel Torres <dto at fastmail.com>:


----------
title: Documentation -> Descriptor Documentation - Reference to Py_MethodType is not up to date

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43677>
_______________________________________

From report at bugs.python.org  Wed Mar 31 05:25:57 2021
From: report at bugs.python.org (Daniel Torres)
Date: Wed, 31 Mar 2021 09:25:57 +0000
Subject: [issue43677] Descriptor.rst - Reference to Py_MethodType is not up to
 date
In-Reply-To: <1617181085.74.0.392624279534.issue43677@roundup.psfhosted.org>
Message-ID: <1617182757.3.0.0831717822952.issue43677@roundup.psfhosted.org>


Change by Daniel Torres <dto at fastmail.com>:


----------
title: Descriptor Documentation - Reference to Py_MethodType is not up to date -> Descriptor.rst - Reference to Py_MethodType is not up to date

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43677>
_______________________________________

From report at bugs.python.org  Wed Mar 31 05:30:53 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 31 Mar 2021 09:30:53 +0000
Subject: [issue43510] PEP 597: Implemente encoding="locale" option and
 EncodingWarning
In-Reply-To: <1615868389.17.0.260147645451.issue43510@roundup.psfhosted.org>
Message-ID: <1617183053.61.0.856018243719.issue43510@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

To me, it sounds really weird to accept an encoding when a file is opened in binary mode. open(filename, "rb", encoding="locale") looks like a bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43510>
_______________________________________

From report at bugs.python.org  Wed Mar 31 05:33:05 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 31 Mar 2021 09:33:05 +0000
Subject: [issue43567] regen.vcxproj cannot regenerate some necessary files
In-Reply-To: <1616238138.44.0.687655765468.issue43567@roundup.psfhosted.org>
Message-ID: <1617183185.38.0.0432733402107.issue43567@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> not having Include/Python-ast.h and Python/Python-ast.c

FYI Include/Python-ast.h was renamed to Include/internal/pycore_ast.h.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43567>
_______________________________________

From mal at egenix.com  Wed Mar 31 05:36:28 2021
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 31 Mar 2021 11:36:28 +0200
Subject: [issue43510] PEP 597: Implemente encoding="locale" option and
 EncodingWarning
In-Reply-To: <1617183053.61.0.856018243719.issue43510@roundup.psfhosted.org>
References: <1617183053.61.0.856018243719.issue43510@roundup.psfhosted.org>
Message-ID: <2792baf8-4bbb-4243-9247-3cd826a6cd9e@egenix.com>

On 31.03.2021 11:30, STINNER Victor wrote:
> 
> To me, it sounds really weird to accept an encoding when a file is opened in binary mode. open(filename, "rb", encoding="locale") looks like a bug.

Same here.

If encoding is used as an argument and then not used, this is a bug,
not a feature :-)

-- 
Marc-Andre Lemburg
eGenix.com


From report at bugs.python.org  Wed Mar 31 05:36:33 2021
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 31 Mar 2021 09:36:33 +0000
Subject: [issue43510] PEP 597: Implemente encoding="locale" option and
 EncodingWarning
In-Reply-To: <1617183053.61.0.856018243719.issue43510@roundup.psfhosted.org>
Message-ID: <2792baf8-4bbb-4243-9247-3cd826a6cd9e@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 31.03.2021 11:30, STINNER Victor wrote:
> 
> To me, it sounds really weird to accept an encoding when a file is opened in binary mode. open(filename, "rb", encoding="locale") looks like a bug.

Same here.

If encoding is used as an argument and then not used, this is a bug,
not a feature :-)

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43510>
_______________________________________

From report at bugs.python.org  Wed Mar 31 05:49:47 2021
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 31 Mar 2021 09:49:47 +0000
Subject: [issue43510] PEP 597: Implemente encoding="locale" option and
 EncodingWarning
In-Reply-To: <1615868389.17.0.260147645451.issue43510@roundup.psfhosted.org>
Message-ID: <1617184187.87.0.298714187182.issue43510@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset cfa176685a5e788bafc7749d7a93f43ea3e4de9f by Inada Naoki in branch 'master':
Revert "bpo-43510: PEP 597: Accept `encoding="locale"` in binary mode (GH-25103)" (#25108)
https://github.com/python/cpython/commit/cfa176685a5e788bafc7749d7a93f43ea3e4de9f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43510>
_______________________________________

From report at bugs.python.org  Wed Mar 31 05:52:47 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 31 Mar 2021 09:52:47 +0000
Subject: [issue37945] [Windows]
 test_locale.TestMiscellaneous.test_getsetlocale_issue1813() fails
In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org>
Message-ID: <1617184367.35.0.0458608217785.issue37945@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

On Windows 10 build 1903,

vstinner at WIN C:\vstinner\python\master>python -m test test_locale -m test_getsetlocale_issue1813 -v
== CPython 3.10.0a6+ (heads/master:ff3c9739bd, Mar 31 2021, 12:43:26) [MSC v.1916 64 bit (AMD64)]
== Windows-10-10.0.18362-SP0 little-endian
(...)
======================================================================
ERROR: test_getsetlocale_issue1813 (test.test_locale.TestMiscellaneous)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\vstinner\python\master\lib\test\test_locale.py", line 567, in test_getsetlocale_issue1813
    locale.setlocale(locale.LC_CTYPE, loc)
  File "C:\vstinner\python\master\lib\locale.py", line 610, in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting


It's a bug in the weird locale.getlocale() function which produces a locale name which doesn't exist:

vstinner at WIN C:\vstinner\python\master>python
>>> import locale
>>> locale.setlocale(locale.LC_CTYPE, "tr_TR") 
'tr_TR'
>>> locale.setlocale(locale.LC_CTYPE, None)
'tr_TR'
>>> locale.getlocale(locale.LC_CTYPE)           
('tr_TR', 'ISO8859-9')


>>> locale.setlocale(locale.LC_CTYPE, ('tr_TR', 'ISO8859-9'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\vstinner\python\master\lib\locale.py", line 610, in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting

>>> locale.setlocale(locale.LC_CTYPE, 'tr_TR')
'tr_TR'


If you use setlocale(LC_CTYPE, None) to get the locale, it works as expected.

IMO the getlocale() function is dangerous and should be removed: see bpo-43557 "Deprecate getdefaultlocale(), getlocale() and normalize() functions".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37945>
_______________________________________

From report at bugs.python.org  Wed Mar 31 05:54:04 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 31 Mar 2021 09:54:04 +0000
Subject: [issue37945] [Windows]
 test_locale.TestMiscellaneous.test_getsetlocale_issue1813() fails
In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org>
Message-ID: <1617184444.76.0.309080896115.issue37945@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +23854
pull_request: https://github.com/python/cpython/pull/25110

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37945>
_______________________________________

From report at bugs.python.org  Wed Mar 31 05:55:49 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 31 Mar 2021 09:55:49 +0000
Subject: [issue37945] [Windows]
 test_locale.TestMiscellaneous.test_getsetlocale_issue1813() fails
In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org>
Message-ID: <1617184549.1.0.603229786593.issue37945@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests:  -23809

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37945>
_______________________________________

From report at bugs.python.org  Wed Mar 31 05:56:57 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 31 Mar 2021 09:56:57 +0000
Subject: [issue37945] [Windows]
 test_locale.TestMiscellaneous.test_getsetlocale_issue1813() fails
In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org>
Message-ID: <1617184617.22.0.930972214875.issue37945@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I wrote PR 25110 to simply skip the test if setlocale() fails. It fix the issue on Windows (I tested manually, see my comment on my PR), but it should also fix the issue on OpenBSD and any platform where getlocale() returns a locale not accepted by setlocale().

Again, don't ust getlocale(category) but setlocale(category, None).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37945>
_______________________________________

From report at bugs.python.org  Wed Mar 31 06:01:33 2021
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 31 Mar 2021 10:01:33 +0000
Subject: [issue37945] [Windows]
 test_locale.TestMiscellaneous.test_getsetlocale_issue1813() fails
In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org>
Message-ID: <1617184893.01.0.242505191912.issue37945@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

Yeah, I'm making the change David suggested. It applies to 3.8 as well.

----------
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37945>
_______________________________________

From report at bugs.python.org  Wed Mar 31 06:02:49 2021
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 31 Mar 2021 10:02:49 +0000
Subject: [issue37945] [Windows]
 test_locale.TestMiscellaneous.test_getsetlocale_issue1813() fails
In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org>
Message-ID: <1617184969.07.0.226071480982.issue37945@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

Oh, Victor's solution is fine as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37945>
_______________________________________

From report at bugs.python.org  Wed Mar 31 06:10:50 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 31 Mar 2021 10:10:50 +0000
Subject: [issue42225] Tkinter hangs or crashes when displaying astral chars
In-Reply-To: <1604200632.47.0.347759375724.issue42225@roundup.psfhosted.org>
Message-ID: <1617185450.26.0.913406842466.issue42225@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> fixed
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42225>
_______________________________________

From report at bugs.python.org  Wed Mar 31 06:11:24 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 31 Mar 2021 10:11:24 +0000
Subject: [issue42225] Tkinter hangs or crashes when displaying astral chars
In-Reply-To: <1604200632.47.0.347759375724.issue42225@roundup.psfhosted.org>
Message-ID: <1617185484.77.0.227075423138.issue42225@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42225>
_______________________________________

From report at bugs.python.org  Wed Mar 31 06:11:55 2021
From: report at bugs.python.org (Jessica Clarke)
Date: Wed, 31 Mar 2021 10:11:55 +0000
Subject: [issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu
 triplet)
In-Reply-To: <1612870873.59.0.718960539942.issue43179@roundup.psfhosted.org>
Message-ID: <1617185515.23.0.0784839980624.issue43179@roundup.psfhosted.org>


Change by Jessica Clarke <jrtc27 at jrtc27.com>:


----------
nosy: +jrtc27
nosy_count: 7.0 -> 8.0
pull_requests: +23855
pull_request: https://github.com/python/cpython/pull/24624

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43179>
_______________________________________

From report at bugs.python.org  Wed Mar 31 06:12:43 2021
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 31 Mar 2021 10:12:43 +0000
Subject: [issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu
 triplet)
In-Reply-To: <1612870873.59.0.718960539942.issue43179@roundup.psfhosted.org>
Message-ID: <1617185563.14.0.578012430258.issue43179@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:


New changeset dec075754960dd85972ce5170df76e862f966132 by Jessica Clarke in branch 'master':
bpo-43179: Generalise alignment for optimised string routines (GH-24624)
https://github.com/python/cpython/commit/dec075754960dd85972ce5170df76e862f966132


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43179>
_______________________________________

From report at bugs.python.org  Wed Mar 31 07:02:03 2021
From: report at bugs.python.org (miss-islington)
Date: Wed, 31 Mar 2021 11:02:03 +0000
Subject: [issue37945] [Windows]
 test_locale.TestMiscellaneous.test_getsetlocale_issue1813() fails
In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org>
Message-ID: <1617188523.23.0.422042801426.issue37945@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 15.0 -> 16.0
pull_requests: +23856
pull_request: https://github.com/python/cpython/pull/25112

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37945>
_______________________________________

From report at bugs.python.org  Wed Mar 31 07:01:54 2021
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 31 Mar 2021 11:01:54 +0000
Subject: [issue37945] [Windows]
 test_locale.TestMiscellaneous.test_getsetlocale_issue1813() fails
In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org>
Message-ID: <1617188514.35.0.480582531349.issue37945@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:


New changeset f3ab670fea75ebe177e3412a5ebe39263cd428e3 by Victor Stinner in branch 'master':
bpo-37945: Fix test_locale.test_getsetlocale_issue1813() (#25110)
https://github.com/python/cpython/commit/f3ab670fea75ebe177e3412a5ebe39263cd428e3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37945>
_______________________________________

From report at bugs.python.org  Wed Mar 31 07:02:14 2021
From: report at bugs.python.org (miss-islington)
Date: Wed, 31 Mar 2021 11:02:14 +0000
Subject: [issue37945] [Windows]
 test_locale.TestMiscellaneous.test_getsetlocale_issue1813() fails
In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org>
Message-ID: <1617188534.64.0.370473934089.issue37945@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +23857
pull_request: https://github.com/python/cpython/pull/25113

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37945>
_______________________________________

From report at bugs.python.org  Wed Mar 31 07:05:45 2021
From: report at bugs.python.org (Muzahid Hussain)
Date: Wed, 31 Mar 2021 11:05:45 +0000
Subject: [issue43678] TypeError: get() got an unexpected keyword argument
 'vars'
Message-ID: <1617188745.77.0.411349429246.issue43678@roundup.psfhosted.org>


Change by Muzahid Hussain <muzahid.h at cisinlabs.com>:


----------
components: 2to3 (2.x to 3.x conversion tool)
nosy: cis-muzahid
priority: normal
severity: normal
status: open
title: TypeError: get() got an unexpected keyword argument 'vars'
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43678>
_______________________________________

From report at bugs.python.org  Wed Mar 31 07:32:19 2021
From: report at bugs.python.org (Martin)
Date: Wed, 31 Mar 2021 11:32:19 +0000
Subject: [issue39228] traceback.FrameSummary does not handle exceptions from
 `repr()`
In-Reply-To: <1578284065.37.0.657086816746.issue39228@roundup.psfhosted.org>
Message-ID: <1617190339.05.0.582876572038.issue39228@roundup.psfhosted.org>


Martin <martin.schroeder at nerdluecht.de> added the comment:

> Even correctly raised code can raise exceptions such as MemoryError, RecursionError and KeybordInterrupt.

For me, this is an argument in favor of the change (although KeybordInterrupt and probably a couple more should not be caught).

traceback is used in contexts where an error already occured and it should do its best to help the user find the cause for it. It does not help much if itself then fails because some values are not repr'eable.

What does pdb do in this case?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39228>
_______________________________________

From report at bugs.python.org  Wed Mar 31 07:52:22 2021
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 31 Mar 2021 11:52:22 +0000
Subject: [issue37945] [Windows]
 test_locale.TestMiscellaneous.test_getsetlocale_issue1813() fails
In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org>
Message-ID: <1617191542.76.0.0887847095945.issue37945@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:


New changeset fabdd25fe505c08da064425ea4d099fd2cef39d3 by Miss Islington (bot) in branch '3.9':
bpo-37945: Fix test_locale.test_getsetlocale_issue1813() (GH-25110) (GH-25112)
https://github.com/python/cpython/commit/fabdd25fe505c08da064425ea4d099fd2cef39d3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37945>
_______________________________________

From report at bugs.python.org  Wed Mar 31 07:52:34 2021
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 31 Mar 2021 11:52:34 +0000
Subject: [issue37945] [Windows]
 test_locale.TestMiscellaneous.test_getsetlocale_issue1813() fails
In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org>
Message-ID: <1617191554.77.0.0636197299941.issue37945@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:


New changeset e143eea4b56ac7ae611e5bcc41eedbc572aa41c3 by Miss Islington (bot) in branch '3.8':
bpo-37945: Fix test_locale.test_getsetlocale_issue1813() (GH-25110) (GH-25113)
https://github.com/python/cpython/commit/e143eea4b56ac7ae611e5bcc41eedbc572aa41c3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37945>
_______________________________________

From report at bugs.python.org  Wed Mar 31 08:08:34 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 31 Mar 2021 12:08:34 +0000
Subject: [issue37945] [Windows]
 test_locale.TestMiscellaneous.test_getsetlocale_issue1813() fails
In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org>
Message-ID: <1617192514.11.0.912366157668.issue37945@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Ok, the initial issue has been fixed: test_locale pass again on Windows.

Let's continue the discussion on getlocale() in bpo-43557 "Deprecate getdefaultlocale(), getlocale() and normalize() functions" ;-)

----------
priority: release blocker -> 
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37945>
_______________________________________

From report at bugs.python.org  Wed Mar 31 08:26:06 2021
From: report at bugs.python.org (MikeS)
Date: Wed, 31 Mar 2021 12:26:06 +0000
Subject: [issue43679] ttk.Sizegrip disappears under Windows 10 UI Scaling,
 with dpiAware set true and >1 scaling
Message-ID: <1617193566.44.0.678288943132.issue43679@roundup.psfhosted.org>


New submission from MikeS <mikesmithpanda at protonmail.com>:

When using tkinter on Windows (10) with a >1 HiDpi screen the sizegrip disappear with dpiawareness is on. A minimal example is as follows:

import tkinter as tk
import tkinter.ttk as ttk
from ctypes import windll, pointer, wintypes
windll.shcore.SetProcessDpiAwareness(1)

root = tk.Tk()
btn1 = tk.Button(root, text='btn1').pack(side=tk.LEFT)
sg = ttk.Sizegrip(root).pack(side=tk.LEFT)
btn2 = tk.Button(root, text='btn2').pack(side=tk.LEFT, fill=tk.BOTH, expand=1)
root.mainloop()

Works fine with commented "SetProcessDpiAwareness", but not when using it. This might be related to the tk issues with hidpi and small radio/checkboxes https://bugs.python.org/issue41969

----------
components: Tkinter
messages: 389893
nosy: msmith
priority: normal
severity: normal
status: open
title: ttk.Sizegrip disappears under Windows 10 UI Scaling, with dpiAware set true and >1 scaling
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43679>
_______________________________________

From report at bugs.python.org  Wed Mar 31 08:37:06 2021
From: report at bugs.python.org (Martin)
Date: Wed, 31 Mar 2021 12:37:06 +0000
Subject: [issue39228] traceback.FrameSummary does not handle exceptions from
 `repr()`
In-Reply-To: <1578284065.37.0.657086816746.issue39228@roundup.psfhosted.org>
Message-ID: <1617194226.98.0.924684363596.issue39228@roundup.psfhosted.org>


Martin <martin.schroeder at nerdluecht.de> added the comment:

pdb uses vanilla repr as well:

https://github.com/python/cpython/blob/f3ab670fea75ebe177e3412a5ebe39263cd428e3/Lib/pdb.py#L1180

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39228>
_______________________________________

From report at bugs.python.org  Wed Mar 31 08:45:00 2021
From: report at bugs.python.org (TW)
Date: Wed, 31 Mar 2021 12:45:00 +0000
Subject: [issue43674] strange effect at recursion limit
In-Reply-To: <1617133829.55.0.126108093558.issue43674@roundup.psfhosted.org>
Message-ID: <1617194700.13.0.746001192045.issue43674@roundup.psfhosted.org>


TW <tw at waldmann-edv.de> added the comment:

Eryk, thanks much for your detailled and clear explaining!

Can confirm that using os.write makes it raise the RecursionError where I expected it to be. Also print() raising the RecursionError explains the behaviour I have seen.

Sadly, this also shows that handling RecursionError is not as easy as one would wish it to be, because the usual place for the exception handler is still too close to it triggering (again) and every other usually harmless call could also trigger it on that level.

So maybe a better solution is voluntarily stopping recursion at a safe distance from the recursion limit (== not going deeper, avoiding the exception).

Or doing some tricky construction of first going upwards to a safe distance from the limit when handling this exception.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43674>
_______________________________________

From report at bugs.python.org  Wed Mar 31 08:59:21 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 31 Mar 2021 12:59:21 +0000
Subject: [issue43680] Remove undocumented io.OpenWrapper and _pyio.OpenWrapper
Message-ID: <1617195561.83.0.0407283597649.issue43680@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

The OpenWrapper function of io and _pyio is an undocumented hack allowing to use the builtin open() function as a method:

class MyClass:
    method = open

MyClass.method(...)    # class method
MyClass().method(...)  # instance method

It is only needed by the _pyio module: the pure Python implementation of the io module:
---
class DocDescriptor:
    """Helper for builtins.open.__doc__
    """
    def __get__(self, obj, typ=None):
        return (
            "open(file, mode='r', buffering=-1, encoding=None, "
                 "errors=None, newline=None, closefd=True)\n\n" +
            open.__doc__)

class OpenWrapper:
    """Wrapper for builtins.open

    Trick so that open won't become a bound method when stored
    as a class variable (as dbm.dumb does).

    See initstdio() in Python/pylifecycle.c.
    """
    __doc__ = DocDescriptor()

    def __new__(cls, *args, **kwargs):
        return open(*args, **kwargs)
---

The io module simply uses an alias to open:
---
OpenWrapper = _io.open # for compatibility with _pyio
---

No wrapper is needed since built-in functions can be used directly as methods. Example:
---
class MyClass:
    method = len  # built-in function

print(MyClass.method("abc"))
print(MyClass().method("abc"))
---

This example works as expected, it displays "3" two times.


I propose to simply remove io.OpenWrapper and force developers to explicitly use staticmethod:

class MyClass:
    method = staticmethod(open)

io.OpenWrapper is not documented.

I don't understand the remark about dbm.dumb: I fail to see where the built-in open() function is used as a method.

----------
components: Library (Lib)
messages: 389896
nosy: vstinner
priority: normal
severity: normal
status: open
title: Remove undocumented io.OpenWrapper and _pyio.OpenWrapper
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43680>
_______________________________________

From report at bugs.python.org  Wed Mar 31 09:13:51 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 31 Mar 2021 13:13:51 +0000
Subject: [issue43680] Remove undocumented io.OpenWrapper and _pyio.OpenWrapper
In-Reply-To: <1617195561.83.0.0407283597649.issue43680@roundup.psfhosted.org>
Message-ID: <1617196431.52.0.657298270445.issue43680@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +23858
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25114

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43680>
_______________________________________

From report at bugs.python.org  Wed Mar 31 09:14:11 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 31 Mar 2021 13:14:11 +0000
Subject: [issue43680] Remove undocumented io.OpenWrapper and _pyio.OpenWrapper
In-Reply-To: <1617195561.83.0.0407283597649.issue43680@roundup.psfhosted.org>
Message-ID: <1617196451.85.0.135871748407.issue43680@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +methane

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43680>
_______________________________________

From report at bugs.python.org  Wed Mar 31 09:19:54 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 31 Mar 2021 13:19:54 +0000
Subject: [issue43680] Remove undocumented io.OpenWrapper and _pyio.OpenWrapper
In-Reply-To: <1617195561.83.0.0407283597649.issue43680@roundup.psfhosted.org>
Message-ID: <1617196794.77.0.799953814229.issue43680@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I also opened a discussion on python-dev about OpenWrapper and staticmethod:
https://mail.python.org/archives/list/python-dev at python.org/thread/QZ7SFW3IW3S2C5RMRJZOOUFSHHUINNME/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43680>
_______________________________________

From report at bugs.python.org  Wed Mar 31 09:48:45 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 31 Mar 2021 13:48:45 +0000
Subject: [issue43677] Descriptor.rst - Reference to Py_MethodType is not up to
 date
In-Reply-To: <1617181085.74.0.392624279534.issue43677@roundup.psfhosted.org>
Message-ID: <1617198525.2.0.406989294221.issue43677@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I think it's PyMethod_Type.

----------
nosy: +eric.smith, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43677>
_______________________________________

From report at bugs.python.org  Wed Mar 31 09:51:03 2021
From: report at bugs.python.org (hai shi)
Date: Wed, 31 Mar 2021 13:51:03 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1617198663.93.0.80805862676.issue4111@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
nosy: +shihai1991
nosy_count: 25.0 -> 26.0
pull_requests: +23859
pull_request: https://github.com/python/cpython/pull/25115

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Wed Mar 31 10:09:41 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 31 Mar 2021 14:09:41 +0000
Subject: [issue43680] Remove undocumented io.OpenWrapper and _pyio.OpenWrapper
In-Reply-To: <1617195561.83.0.0407283597649.issue43680@roundup.psfhosted.org>
Message-ID: <1617199781.4.0.266226385257.issue43680@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

As for dbm.dumb, it was an attempt to make _Database._commit() working at the shutdown stage (it is indirectly called from __del__()). See issue723231. Although in Python 2 __builtin__.open != io.open, and in Python 3.0 the code already uses io.open directly.

I afraid that this code is not reliable (and never was reliable), because modules os and io can be cleared before calling it, so os.unlink and io.open would not work. But this is a different issue.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43680>
_______________________________________

From report at bugs.python.org  Wed Mar 31 10:15:34 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 31 Mar 2021 14:15:34 +0000
Subject: [issue43678] TypeError: get() got an unexpected keyword argument
 'vars'
Message-ID: <1617200134.2.0.498319587361.issue43678@roundup.psfhosted.org>


New submission from Eric V. Smith <eric at trueblade.com>:

Please provide example code that we can run which demonstrates the problem.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43678>
_______________________________________

From report at bugs.python.org  Wed Mar 31 10:22:26 2021
From: report at bugs.python.org (Michael Felt)
Date: Wed, 31 Mar 2021 14:22:26 +0000
Subject: [issue43659] AIX: test_curses crashes buildbot
In-Reply-To: <1617040273.92.0.487968447995.issue43659@roundup.psfhosted.org>
Message-ID: <1617200546.34.0.174081371116.issue43659@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

FYI: from a core dump - top of where is:

Segmentation fault in winsnstr at 0xd3ebc050
0xd3ebc050 (winsnstr+0x190) a4190002           lhzu   r0,0x2(r25)
(dbx) where
winsnstr(??, ??, ??) at 0xd3ebc050
unnamed block in IPRA.$_curses_window_insstr_impl(self = 0x100fd954, group_left_1 = -739652824, y = 804382672, x = 804382676, str = 0x2ff1e7dc, group_right_1 = -739620304, attr = 0), line 1855 in "_cursesmodule.c"
IPRA.$_curses_window_insstr_impl(self = 0x100fd954, group_left_1 = -739652824, y = 804382672, x = 804382676, str = 0x2ff1e7dc, group_right_1 = -739620304, attr = 0), line 1855 in "_cursesmodule.c"
_curses_window_insstr(self = 0x100a96ec, args = 0x20088288), line 1160 in "_cursesmodule.c.h"
cfunction_call(func = 0x305337d0, args = 0x20088288, kwargs = 0x2ff1e8b0), line 567 in "methodobject.c"
_PyObject_MakeTpCall(tstate = (nil), callable = 0x20088288, args = 0x2ff1e930, nargs = 131, keywords = 0x10167b48), line 215 in "call.c"
_PyEval_EvalFrameDefault(tstate = 0x100b2a6c, f = 0x303a1268, throwflag = 806335952), line 1429 in "abstract.h"
_PyEval_Vector(tstate = 0x100ef278, con = 0x300fd59a, locals = 0x2ff1ea90, args = 0x20045994, argcount = 806339296, kwnames = 0x300ff6a0), line 46 in "pycore_ceval.h"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43659>
_______________________________________

From report at bugs.python.org  Wed Mar 31 10:23:48 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 31 Mar 2021 14:23:48 +0000
Subject: [issue43680] Remove undocumented io.OpenWrapper and _pyio.OpenWrapper
In-Reply-To: <1617195561.83.0.0407283597649.issue43680@roundup.psfhosted.org>
Message-ID: <1617200628.87.0.339457608393.issue43680@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

OpenWrapper was added in ce3a72aec6eaa0293c397c8d0407f7afe0072b2f (issue1267) and was only used to set __builtin__.open (I suppose that at thet moment dumbdbm.py still set open as a class attribute).

It is still can be set as a class attribute in user code, so I think that removing OpenWrapper needs a deprecated period.

----------
nosy: +christian.heimes, gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43680>
_______________________________________

From report at bugs.python.org  Wed Mar 31 10:25:05 2021
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 31 Mar 2021 14:25:05 +0000
Subject: [issue43681] doctest forgets previous imports
Message-ID: <1617200705.39.0.678751580159.issue43681@roundup.psfhosted.org>


New submission from Ethan Furman <ethan at stoneleaf.us>:

In the Python 3.10 Doc/library/enum.rst file was the following:

.. class:: FlagBoundary

   *FlagBoundary* controls how out-of-range values are handled in *Flag* and its
   subclasses.

   .. attribute:: STRICT

      Out-of-range values cause a :exc:`ValueError` to be raised.  This is the
      default for :class:`Flag`::

         >>> from enum import STRICT
         >>> class StrictFlag(Flag, boundary=STRICT):
         ...     RED = auto()
         ...     GREEN = auto()
         ...     BLUE = auto()
         >>> StrictFlag(2**2 + 2**4)
         Traceback (most recent call last):
         ...
         ValueError: StrictFlag: invalid value: 20
             given 0b0 10100
           allowed 0b0 00111

   .. attribute:: CONFORM

      Out-of-range values have invalid values removed, leaving a valid *Flag*
      value::

         >>> from enum import CONFORM
         >>> class ConformFlag(Flag, boundary=CONFORM):
         ...     RED = auto()
         ...     GREEN = auto()
         ...     BLUE = auto()
         >>> ConformFlag(2**2 + 2**4)
         ConformFlag.BLUE

   .. attribute:: EJECT

      Out-of-range values lose their *Flag* membership and revert to :class:`int`.
      This is the default for :class:`IntFlag`::

         >>> from enum import EJECT
         >>> class EjectFlag(Flag, boundary=EJECT):
         ...     RED = auto()
         ...     GREEN = auto()
         ...     BLUE = auto()
         >>> EjectFlag(2**2 + 2**4)
         20

   .. attribute:: KEEP

      Out-of-range values are kept, and the *Flag* membership is kept.  This is
      used for some stdlib flags:

         >>> from enum import KEEP
         >>> class KeepFlag(Flag, boundary=KEEP):
         ...     RED = auto()
         ...     GREEN = auto()
         ...     BLUE = auto()
         >>> KeepFlag(2**2 + 2**4)
         KeepFlag.BLUE|0x10


All four tests are relying on a previous `from enum import Flag`, but only the three tests pass -- the fourth raises:

    Traceback (most recent call last):
      File "/home/runner/work/cpython/cpython/Lib/doctest.py", line 1337, in __run
        exec(compile(example.source, filename, "single",
      File "<doctest default[1]>", line 1, in <module>
        class KeepFlag(Flag, boundary=KEEP):
    NameError: name 'Flag' is not defined

----------
components: Library (Lib)
messages: 389903
nosy: ethan.furman
priority: normal
severity: normal
stage: test needed
status: open
title: doctest forgets previous imports
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43681>
_______________________________________

From report at bugs.python.org  Wed Mar 31 10:27:31 2021
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 31 Mar 2021 14:27:31 +0000
Subject: [issue43681] doctest forgets previous imports
In-Reply-To: <1617200705.39.0.678751580159.issue43681@roundup.psfhosted.org>
Message-ID: <1617200851.88.0.597737490744.issue43681@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

Note that this only appears to be a problem under CI.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43681>
_______________________________________

From report at bugs.python.org  Wed Mar 31 10:31:21 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 31 Mar 2021 14:31:21 +0000
Subject: [issue43682] Make function wrapped by staticmethod callable
Message-ID: <1617201081.91.0.895015962683.issue43682@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Currently, static methods created by the @staticmethod decorator are not callable as regular function. Example:
---
@staticmethod
def func():
    print("my func")

class MyClass:
    method = func

func() # A: regular function
MyClass.method() # B: class method
MyClass().method() # C: instance method
---

The func() call raises TypeError('staticmethod' object is not callable) exception.

I propose to make staticmethod objects callable to get a similar to built-in function:
---
func = len

class MyClass:
    method = func

func("abc") # A: regular function
MyClass.method("abc") # B: class method
MyClass().method("abc") # C: instance method
---

The 3 variants (A, B, C) to call the built-in len() function work just as expected.

If static method objects become callable, the 3 variants (A, B, C) will just work.

It would avoid the hack like _pyio.Wrapper:
---
class DocDescriptor:
    """Helper for builtins.open.__doc__
    """
    def __get__(self, obj, typ=None):
        return (
            "open(file, mode='r', buffering=-1, encoding=None, "
                 "errors=None, newline=None, closefd=True)\n\n" +
            open.__doc__)

class OpenWrapper:
    """Wrapper for builtins.open

    Trick so that open won't become a bound method when stored
    as a class variable (as dbm.dumb does).

    See initstdio() in Python/pylifecycle.c.
    """
    __doc__ = DocDescriptor()

    def __new__(cls, *args, **kwargs):
        return open(*args, **kwargs)
---

Currently, it's not possible possible to use directly _pyio.open as a method:
---
class MyClass:
    method = _pyio.open
---

whereas "method = io.open" just works because io.open() is a built-in function.


See also bpo-43680 "Remove undocumented io.OpenWrapper and _pyio.OpenWrapper" and my thread on python-dev:

"Weird io.OpenWrapper hack to use a function as method"
https://mail.python.org/archives/list/python-dev at python.org/thread/QZ7SFW3IW3S2C5RMRJZOOUFSHHUINNME/

----------
components: Library (Lib)
messages: 389905
nosy: vstinner
priority: normal
severity: normal
status: open
title: Make function wrapped by staticmethod callable
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43682>
_______________________________________

From report at bugs.python.org  Wed Mar 31 10:35:50 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 31 Mar 2021 14:35:50 +0000
Subject: [issue43682] Make function wrapped by staticmethod callable
In-Reply-To: <1617201081.91.0.895015962683.issue43682@roundup.psfhosted.org>
Message-ID: <1617201350.74.0.1084344353.issue43682@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Seems like a duplicate of #20309.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43682>
_______________________________________

From report at bugs.python.org  Wed Mar 31 10:37:54 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 31 Mar 2021 14:37:54 +0000
Subject: [issue43682] Make function wrapped by staticmethod callable
In-Reply-To: <1617201081.91.0.895015962683.issue43682@roundup.psfhosted.org>
Message-ID: <1617201474.67.0.858184345432.issue43682@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +23860
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25117

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43682>
_______________________________________

From report at bugs.python.org  Wed Mar 31 10:38:55 2021
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 31 Mar 2021 14:38:55 +0000
Subject: [issue43681] doctest forgets previous imports
In-Reply-To: <1617200705.39.0.678751580159.issue43681@roundup.psfhosted.org>
Message-ID: <1617201535.43.0.930859394282.issue43681@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/issue43681>
_______________________________________

From report at bugs.python.org  Wed Mar 31 10:44:15 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 31 Mar 2021 14:44:15 +0000
Subject: [issue43682] Make function wrapped by staticmethod callable
In-Reply-To: <1617201081.91.0.895015962683.issue43682@roundup.psfhosted.org>
Message-ID: <1617201855.54.0.564755127224.issue43682@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Seems like a duplicate of #20309.

My usecase is to avoid any behavior difference between io.open and _pyio.open functions: PEP 399 "Pure Python/C Accelerator Module Compatibility Requirements". Currently, this is a very subtle difference when it's used to define a method.

I dislike the current _pyio.OpenWrapper "hack". I would prefer that _pyio.open would be directly usable to define a method. I propose to use @staticmethod, but I am open to other ideas. It could be a new decorator: @staticmethod_or_function.

Is it worth it to introduce a new @staticmethod_or_function decorator just to leave @staticmethod unchanged?

Note: The PEP 570 "Python Positional-Only Parameters" (implemented in Python 3.8) removed another subtle difference between functions implemented in C and functions implemented in Python. Now functions implemented in Python can only have positional only parameters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43682>
_______________________________________

From report at bugs.python.org  Wed Mar 31 10:44:37 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 31 Mar 2021 14:44:37 +0000
Subject: [issue43682] Make static methods created by @staticmethod callable
In-Reply-To: <1617201081.91.0.895015962683.issue43682@roundup.psfhosted.org>
Message-ID: <1617201877.15.0.720226338603.issue43682@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: Make function wrapped by staticmethod callable -> Make static methods created by @staticmethod callable

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43682>
_______________________________________

From report at bugs.python.org  Wed Mar 31 10:45:13 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 31 Mar 2021 14:45:13 +0000
Subject: [issue20309] Not all method descriptors are callable
In-Reply-To: <1390200218.06.0.45732778516.issue20309@psf.upfronthosting.co.za>
Message-ID: <1617201913.14.0.805094899795.issue20309@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I proposed again a similar idea, but only for @staticmethod: bpo-43682.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20309>
_______________________________________

From report at bugs.python.org  Wed Mar 31 10:46:24 2021
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 31 Mar 2021 14:46:24 +0000
Subject: [issue43682] Make function wrapped by staticmethod callable
In-Reply-To: <1617201081.91.0.895015962683.issue43682@roundup.psfhosted.org>
Message-ID: <1617201984.29.0.690671315001.issue43682@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

I don't understand what the problem is. _pyio.open is a function not a static method.

>>> import _pyio
>>> _pyio.open
<function open at 0x7f184cf33a10>

----------
nosy: +Mark.Shannon
title: Make static methods created by @staticmethod callable -> Make function wrapped by staticmethod callable

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43682>
_______________________________________

From report at bugs.python.org  Wed Mar 31 10:50:45 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 31 Mar 2021 14:50:45 +0000
Subject: [issue43682] Make function wrapped by staticmethod callable
In-Reply-To: <1617201081.91.0.895015962683.issue43682@roundup.psfhosted.org>
Message-ID: <1617202245.15.0.800735868102.issue43682@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> I don't understand what the problem is. _pyio.open is a function not a static method.

The problem is that _pyio.open doesn't behave exactly as io.open when it's used to define a method:
---
#from io import open
from _pyio import open

class MyClass:
   my_open = open

MyClass().my_open("document.txt", "w")
---

This code currently fails with a TypeError, whereas it works with io.open.

The problem is that I failed to find a way to create a function in Python which behaves exactly as built-in functions like len() or io.open().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43682>
_______________________________________

From report at bugs.python.org  Wed Mar 31 10:51:06 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 31 Mar 2021 14:51:06 +0000
Subject: [issue43682] Make static methods created by @staticmethod callable
In-Reply-To: <1617201081.91.0.895015962683.issue43682@roundup.psfhosted.org>
Message-ID: <1617202266.23.0.450798224128.issue43682@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: Make function wrapped by staticmethod callable -> Make static methods created by @staticmethod callable

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43682>
_______________________________________

From report at bugs.python.org  Wed Mar 31 10:56:09 2021
From: report at bugs.python.org (Michael Felt)
Date: Wed, 31 Mar 2021 14:56:09 +0000
Subject: [issue43665] AIX: test_importlib regression (ENV change)
In-Reply-To: <1617090006.69.0.157120669533.issue43665@roundup.psfhosted.org>
Message-ID: <1b1c38fc-18cf-2f61-df77-21d96ff97c8a@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

On 30/03/2021 09:40, STINNER Victor wrote:
> STINNER Victor <vstinner at python.org> added the comment:
>
> A core dump is a very bad sign of health.
>
> Can you please try to bisect which test is causing the segfault using bisect_cmd? Try the command:
>
> ./python -m test.bisect_cmd -o bisect --fail-env-changed test_importlib
>
> The command should takes 10-60 minutes, and you should see the number of tests decreasing. I hope that at the end, the command will identify a single method triggering the crash.
>
> At the end, the create "bisect" file contains the test methods causing the bug.
>
> Then you can re-run tests with:
>
> ./python -m test --fail-env-changed test_importlib --matchfile=bisect
I like this!:

Fortunately, it did not take 10? minutes:

Writing 1 tests into bisect

Tests (1):
* 
test.test_importlib.test_threaded_import.ThreadedImportTests.test_multiprocessing_pool_circular_import

Output written into bisect
Bisection completed in 34 iterations and 0:00:28

>
>
>> The core dump is caused by SIGTRAP. I need help to learn how to stop the core dump from being cleaned up so I can load it into dbx and hopefully understand/learn with sub-test is actually having issues.
> You can re-run the test without libregrtest by running it directly. Example:
>
> ./python -m test.test_importlib test_spec.Frozen_ModuleSpecMethodsTests.test_reload -v

While - to use your example - using the normal verbose test syntax I do 
see the test you reference:

* test_reload 
(test.test_importlib.test_spec.Frozen_ModuleSpecMethodsTests) ... ok

but, when I run your example (and many variations) I always get 
something such as:

So, still - closer - but not quite there with:

+++++

./python -m test.test_importlib 
test_spec.Frozen_ModuleSpecMethodsTests.test_reload -v
test_spec (unittest.loader._FailedTest) ... ERROR

======================================================================
ERROR: test_spec (unittest.loader._FailedTest)
----------------------------------------------------------------------
AttributeError: module '__main__' has no attribute 'test_spec'

----------------------------------------------------------------------
Ran 1 test in 0.000s

FAILED (errors=1)
+++++

> It should create a core dump in the current directory, or you run the command in your favorite debugger.
>
>
> My notes on debugging a Python crash: https://pythondev.readthedocs.io/debug_tools.html#core-dump
>
> ----------
> nosy: +vstinner
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue43665>
> _______________________________________
>

----------
Added file: https://bugs.python.org/file49922/OpenPGP_0x722BFDB61F396FC2.asc

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43665>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x722BFDB61F396FC2.asc
Type: application/pgp-keys
Size: 1761 bytes
Desc: not available
URL: <https://mail.python.org/pipermail/python-bugs-list/attachments/20210331/4007e34d/attachment.key>

From report at bugs.python.org  Wed Mar 31 10:57:06 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 31 Mar 2021 14:57:06 +0000
Subject: [issue43680] Remove undocumented io.OpenWrapper and _pyio.OpenWrapper
In-Reply-To: <1617195561.83.0.0407283597649.issue43680@roundup.psfhosted.org>
Message-ID: <1617202626.86.0.983635586522.issue43680@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> OpenWrapper was added in ce3a72aec6eaa0293c397c8d0407f7afe0072b2f (issue1267) and was only used to set __builtin__.open

It is useless in CPython, since CPython always use the C implementation of the io module, and in the io module, io.OpenWrapper is just an alias to io.open.

$ python3
Python 3.9.2 (default, Feb 20 2021, 00:00:00) 
>>> import io
>>> io.OpenWrapper is io.open
True


> (I suppose that at thet moment dumbdbm.py still set open as a class attribute).

I failed to find where in Lib/dbm/dumb.py the open() function is used to define a method. Maybe the code changed since OpenWrapper was added?

At commit ce3a72aec6eaa0293c397c8d0407f7afe0072b2f, the io module was only implemented in Python (Lib/io.py, _io exist didn't exist). It was reimplemented in C in Python 3.1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43680>
_______________________________________

From report at bugs.python.org  Wed Mar 31 10:59:02 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 31 Mar 2021 14:59:02 +0000
Subject: [issue43680] Remove undocumented io.OpenWrapper and _pyio.OpenWrapper
In-Reply-To: <1617195561.83.0.0407283597649.issue43680@roundup.psfhosted.org>
Message-ID: <1617202742.43.0.290311062937.issue43680@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> It is still can be set as a class attribute in user code, so I think that removing OpenWrapper needs a deprecated period.

I'm fine with deprecating the function by defining a __getattr__() function in io.py and _pyio.py. But only if it doesn't block the implementation of the PEP 597 ;-) The PEP 597 implementation issue is discussed at:
https://bugs.python.org/issue43510#msg389822

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43680>
_______________________________________

From report at bugs.python.org  Wed Mar 31 11:10:51 2021
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 31 Mar 2021 15:10:51 +0000
Subject: [issue40066] Enum: modify __repr__, __str__; update docs
In-Reply-To: <1585165738.23.0.618463548627.issue40066@roundup.psfhosted.org>
Message-ID: <1617203451.69.0.560542717229.issue40066@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
pull_requests: +23861
pull_request: https://github.com/python/cpython/pull/25116

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40066>
_______________________________________

From report at bugs.python.org  Wed Mar 31 11:36:39 2021
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 31 Mar 2021 15:36:39 +0000
Subject: [issue40066] Enum: modify __repr__, __str__; update docs
In-Reply-To: <1585165738.23.0.618463548627.issue40066@roundup.psfhosted.org>
Message-ID: <1617204999.1.0.660747101744.issue40066@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
pull_requests: +23862
pull_request: https://github.com/python/cpython/pull/25118

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40066>
_______________________________________

From report at bugs.python.org  Wed Mar 31 11:56:11 2021
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 31 Mar 2021 15:56:11 +0000
Subject: [issue43682] Make static methods created by @staticmethod callable
In-Reply-To: <1617201081.91.0.895015962683.issue43682@roundup.psfhosted.org>
Message-ID: <1617206171.8.0.0795274784968.issue43682@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

Isn't the problem that Python functions are (non-overriding) descriptors, but builtin-functions are not descriptors?
Changing static methods is not going to fix that.

How about adding wrappers to make Python functions behave like builtin functions and vice versa?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43682>
_______________________________________

From report at bugs.python.org  Wed Mar 31 12:12:26 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 31 Mar 2021 16:12:26 +0000
Subject: [issue43682] Make static methods created by @staticmethod callable
In-Reply-To: <1617201081.91.0.895015962683.issue43682@roundup.psfhosted.org>
Message-ID: <1617207146.29.0.210421200024.issue43682@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43682>
_______________________________________

From report at bugs.python.org  Wed Mar 31 12:18:35 2021
From: report at bugs.python.org (Hunor Portik)
Date: Wed, 31 Mar 2021 16:18:35 +0000
Subject: [issue4928] tempfile.NamedTemporaryFile: automatic cleanup by OS
In-Reply-To: <1231838566.25.0.143957228078.issue4928@psf.upfronthosting.co.za>
Message-ID: <1617207515.41.0.911002553183.issue4928@roundup.psfhosted.org>


Hunor Portik <portikhun at gmail.com> added the comment:

Hello

I would really appreciate and I think many of us if every time I havent have to remember everything. Im not a Sys admin, devops, or who has in his mind every low level step and just shakes out of his little finger...
Why do I have to take care at the high level where I stand with using Python? I think  mustn't.

So yes, as just a little noticement would be really helpful for us to remember we should look forward if we want to make sure. That's why Im here, and not reading the docs instead...

----------
nosy: +portikhun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4928>
_______________________________________

From report at bugs.python.org  Wed Mar 31 12:19:22 2021
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 31 Mar 2021 16:19:22 +0000
Subject: [issue43672] Raise ImportWarning when calling find_loader()
In-Reply-To: <1617119093.18.0.759506550026.issue43672@roundup.psfhosted.org>
Message-ID: <1617207562.16.0.615286956779.issue43672@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
keywords: +patch
pull_requests: +23863
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25119

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43672>
_______________________________________

From report at bugs.python.org  Wed Mar 31 12:33:05 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 31 Mar 2021 16:33:05 +0000
Subject: [issue43682] Make static methods created by @staticmethod callable
In-Reply-To: <1617201081.91.0.895015962683.issue43682@roundup.psfhosted.org>
Message-ID: <1617208385.0.0.49597113018.issue43682@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Changing static methods is not going to fix that.

My plan for the _pyio module is:

(1) Make static methods callable
(2) Decorate _pyio.open() with @staticmethod

That would only fix the very specific case of _pyio.open(). But open() use case seems to be common enough to became the example in the @staticmethod documentation!
https://docs.python.org/dev/library/functions.html#staticmethod

Example added in bpo-31567 "Inconsistent documentation around decorators" by:

commit 03b9537dc515d10528f83c920d38910b95755aff
Author: ?ric Araujo <merwok at users.noreply.github.com>
Date:   Thu Oct 12 12:28:55 2017 -0400

    bpo-31567: more decorator markup fixes in docs (GH-3959) (#3966)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43682>
_______________________________________

From report at bugs.python.org  Wed Mar 31 12:42:18 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 31 Mar 2021 16:42:18 +0000
Subject: [issue43682] Make static methods created by @staticmethod callable
In-Reply-To: <1617201081.91.0.895015962683.issue43682@roundup.psfhosted.org>
Message-ID: <1617208938.91.0.98799520952.issue43682@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Isn't the problem that Python functions are (non-overriding) descriptors, but builtin-functions are not descriptors?
> Changing static methods is not going to fix that.
> How about adding wrappers to make Python functions behave like builtin functions and vice versa?

I would love consistency, but is that possible without breaking almost all Python projects?

Honestly, I'm annoying by the having to use staticmethod(), or at least the fact that built-in functions and functions implemented in Python don't behave the same. It's hard to remind if a stdlib function requires staticmethod() or not. Moreover, maybe staticmethod() is not needed today, but it would become required tomorrow if the built-in function becomes a Python function somehow.

So yeah, I would prefer consistency. But backward compatibility may enter into the game as usual. PR 25117 tries to minimize the risk of backward compatibility issues.

For example, if we add __get__() to built-in methods and a bound method is created on the following example, it means that all code relying on the current behavior of built-in functions (don't use staticmethod) would break :-(
---
class MyClass:
    # built-in function currently converted to a method
    # magically without having to use staticmethod()
    method = len
---

Would it be possible to remove __get__() from FunctionType to allow using a Python function as a method? How much code would it break? :-) What would create the bound method on a method call?
---
def func():
    ...

class MyClass:
    method = func

# magic happens here!
bound_method = MyClass().method
---

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43682>
_______________________________________

From report at bugs.python.org  Wed Mar 31 12:44:25 2021
From: report at bugs.python.org (Michael Felt)
Date: Wed, 31 Mar 2021 16:44:25 +0000
Subject: [issue28276] test_loading.py - false positive result for "def
 test_find" when find_library() is not functional or the (shared) library does
 not exist
In-Reply-To: <1474887883.6.0.275550575314.issue28276@psf.upfronthosting.co.za>
Message-ID: <1617209065.34.0.798328591423.issue28276@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Sure. Probably have to rebase first.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28276>
_______________________________________

From report at bugs.python.org  Wed Mar 31 12:45:03 2021
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 31 Mar 2021 16:45:03 +0000
Subject: [issue43683] Handle generator (and coroutine) state in the bytecode.
Message-ID: <1617209103.34.0.926095267338.issue43683@roundup.psfhosted.org>


New submission from Mark Shannon <mark at hotpy.org>:

Every time we send, or throw, to a generator, the C code in genobject.c needs to check what state the generator is in. 
This is inefficient and couples the generator code, which should just be a thin wrapper around the interpreter, to the internals of the interpreter.

The state of the generator is known to the compiler. It should emit appropriate bytecodes to handle the different behavior for the different states.

While the main reason this is robustness and maintainability, removing the complex C code between Python caller and Python callee also opens up the possibility of some worthwhile optimizations.

There are three changes I want to make:

1. Add a new bytecode to handle starting a generator. This `GEN_START` bytecode would pop TOS, raising an exception if it is not None.
This adds some overhead for the first call to iter()/send() but speeds up all the others.

2. Handle the case of exhausted generators. This is a bit more fiddly, and involves putting an infinite loop at the end of the generator. Something like:

   CLEAR_FRAME
label:
   GEN_RETURN (Like RETURN_VALUE None, but does not discard the frame)
   JUMP label


This removes a lot of special case code for corner cases of exhausted generators and coroutines.

3. Handle throw() on `YIELD_FROM`. The problem here is that we need to differentiate between exceptions triggered by throw, which must call throw() on sub-generators, and exceptions propagating out of sub-generators which should be passed up the stack. By splitting the opcode into two (or more), it is clear which case is being handled in the interpreter without complicated logic in genobject.c

----------
messages: 389919
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: Handle generator (and coroutine) state in the bytecode.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43683>
_______________________________________

From report at bugs.python.org  Wed Mar 31 12:46:22 2021
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 31 Mar 2021 16:46:22 +0000
Subject: [issue42823] Incorrect frame.f_lineno when frame.f_trace is set
In-Reply-To: <1609777965.06.0.667792191004.issue42823@roundup.psfhosted.org>
Message-ID: <1617209182.74.0.937788169667.issue42823@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

Ned, can I close this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42823>
_______________________________________

From report at bugs.python.org  Wed Mar 31 12:46:58 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 31 Mar 2021 16:46:58 +0000
Subject: [issue43665] AIX: test_importlib regression (ENV change)
In-Reply-To: <1617089431.51.0.0013168061581.issue43665@roundup.psfhosted.org>
Message-ID: <1617209218.8.0.948065429298.issue43665@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

test.test_importlib.test_threaded_import.ThreadedImportTests.test_multiprocessing_pool_circular_import

This test comes from bpo-41567 and it simply runs a script. You can run the script directly:

./python -X dev Lib/test/test_importlib/partial/pool_in_threads.py ; echo $?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43665>
_______________________________________

From report at bugs.python.org  Wed Mar 31 12:47:38 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 31 Mar 2021 16:47:38 +0000
Subject: [issue43665] [AIX] test_importlib:
 test_multiprocessing_pool_circular_import() killed by SIGTRAP (coredump)
In-Reply-To: <1617089431.51.0.0013168061581.issue43665@roundup.psfhosted.org>
Message-ID: <1617209258.26.0.567755437296.issue43665@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: AIX: test_importlib regression (ENV change) -> [AIX] test_importlib: test_multiprocessing_pool_circular_import() killed by SIGTRAP (coredump)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43665>
_______________________________________

From report at bugs.python.org  Wed Mar 31 12:50:06 2021
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 31 Mar 2021 16:50:06 +0000
Subject: [issue43683] Handle generator (and coroutine) state in the bytecode.
In-Reply-To: <1617209103.34.0.926095267338.issue43683@roundup.psfhosted.org>
Message-ID: <1617209406.72.0.153410436758.issue43683@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
assignee:  -> Mark.Shannon
stage:  -> needs patch
type:  -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43683>
_______________________________________

From report at bugs.python.org  Wed Mar 31 12:56:56 2021
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 31 Mar 2021 16:56:56 +0000
Subject: [issue29988] with statements are not ensuring that __exit__ is called
 if __enter__ succeeds
In-Reply-To: <1491349378.03.0.0671954460373.issue29988@psf.upfronthosting.co.za>
Message-ID: <1617209816.54.0.803497075199.issue29988@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

The bytecode instruction set has changed a lot since 3.6, so I think a backport would be impractical.

3.6 is in security fix only mode, so you'd need to take this up with Red Hat.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29988>
_______________________________________

From report at bugs.python.org  Wed Mar 31 13:20:44 2021
From: report at bugs.python.org (Michael Felt)
Date: Wed, 31 Mar 2021 17:20:44 +0000
Subject: [issue43665] AIX: test_importlib regression (ENV change)
In-Reply-To: <1617209218.8.0.948065429298.issue43665@roundup.psfhosted.org>
Message-ID: <32081792-8eb4-4828-2ffa-8bb2905a780f@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

On 31/03/2021 18:46, STINNER Victor wrote:
> STINNER Victor <vstinner at python.org> added the comment:
>
> test.test_importlib.test_threaded_import.ThreadedImportTests.test_multiprocessing_pool_circular_import
>
> This test comes from bpo-41567 and it simply runs a script. You can run 
the script directly:
>
> ./python -X dev Lib/test/test_importlib/partial/pool_in_threads.py ; echo $?

Status is zero -0 but I get a core dump!

aixtools at cpython2:[/home/aixtools/py3a-10.0]./python -X dev 
Lib/test/test_importlib/partial/pool_in_threads.py ; echo $?
0
aixtools at cpython2:[/home/aixtools/py3a-10.0]ls -ltr core
-rw-r--r--??? 1 aixtools staff???? 129435720 Mar 31 16:58 core

+++++++++++++++
Looking at the core dump - part 1.
+++++++++++++++

The address (0xd118ff80) hints at a shared library (pthread?)

I'll try to find it - but maybe you can just remind me - the CLI 
arguments to make Python more verbose about what it is doing.
Note: all addresses beginning with 0x1 (as in 0x101ca238) are program 
code addresses. 0x3 (0x30163ad8) imply a shared memory segment being 
created and used by the application.

Perhaps more relevant aree all these?lines with what appear to be 
extreme argcount values, e.g., from the bottom:

_PyEval_Vector(tstate = 0x30187038, con = 0x20107b40, locals = 
0x30111768, args = 0x301219b8, argcount = 806560272, kwnames = 
0x301314d8), line 46 in "pycore_ceval.h"
_PyFunction_Vectorcall(func = (nil), stack = (nil), nargsf = 570570720, 
kwnames = (nil)), line 361 in "call.c"
_PyEval_EvalFrameDefault(tstate = (nil), f = 0x40000000, throwflag = 

-257396708), line 1431 in "abstract.h"
_PyEval_Vector(tstate = 0x22023cf0, con = 0x2000120c, locals = 
0x22023960, args = 0x220239f0, argcount = 3508213100, kwnames = 
0x22023cf0), line 46 in "pycore_ceval.h"
_PyFunction_Vectorcall(func = 0x220239f0, stack = (nil), nargsf = 
570572016, kwnames = 0x220239f0), line 361 in "call.c"
method_vectorcall(method = 0x10103bdc, args = (nil), nargsf = 0, kwnames 
= 0x20045994), line 119 in "abstract.h"
PyVectorcall_Call(callable = 0xdddddddd, tuple = 0xdddddddd, kwargs = 

0xdddddddd), line 255 in "call.c"
_PyObject_Call(tstate = (nil), callable = (nil), args = (nil), kwargs = 
(nil)), line 298 in "call.c"
thread_run(boot_raw = (nil)), line 1076 in "_threadmodule.c"

pythread_wrapper(arg = (nil)), line 240 in "thread_pthread.h"

+++++++++++++++++++++++++++++++++++++++++++
Looking at the core dump - the complete 'where' results:
+++++++++++++++++++++++++++++++++++++++++++

aixtools at cpython2:[/home/aixtools/py3a-10.0]dbx ./python core
Type 'help' for help.
[using memory image in core]
reading symbolic information ...

Trace/BPT trap in _internal_error at 0xd118ff80 ($t1)
0xd118ff80 (_internal_error+0x80) 80410014??????????? lwz r2,0x14(r1)
(dbx) where
_internal_error(??, ??, ??) at 0xd118ff80
pth_usched._usched_dispatch_front._event_notify_locked at AF34_24(??, ??, 
??, ??, ??) at 0xd119fc2c
_event_notify(??, ??, ??) at 0xd119ee38
_cond_broadcast(??, ??, ??) at 0xd11af588
pthread_cond_signal at AF29_12(??, ??) at 0xd11b1568
pthread_cond_signal(??) at 0xd11afc88
PyThread_release_lock(lock = 0x10119354), line 692 in "thread_pthread.h"
release_sentinel(wr_raw = 0x10118f14), line 1289 in "_threadmodule.c"
PyThreadState_Clear(tstate = 0x101ca238), line 873 in "pystate.c"
_PyThreadState_DeleteExcept(runtime = 0xd5c234d0, tstate = 0x22021d30), 
line 987 in "pystate.c"
_PyEval_ReInitThreads(tstate = 0x30163ad8), line 506 in "ceval.c"
PyOS_AfterFork_Child(), line 600 in "posixmodule.c"
os_fork_impl(module = 0x3033a030), line 6659 in "posixmodule.c"
cfunction_vectorcall_NOARGS(func = 0x30337330, args = 0x302ec7d0, nargsf 
= 570564304, kwnames = 0x30337328), line 485 in "methodobject.c"
_PyEval_EvalFrameDefault(tstate = 0x302e058c, f = 0x302e847a, throwflag 
= 0), line 1431 in "abstract.h"
_PyEval_Vector(tstate = 0x302f2350, con = 0x20107b40, locals = 
0x302e8478, args = 0x302e79b8, argcount = 808016112, kwnames = 
0x302cd898), line 46 in "pycore_ceval.h"
_PyFunction_Vectorcall(func = 0x00000008, stack = 0x3004d6e8, nargsf = 
570564752, kwnames = 0x302f6030), line 361 in "call.c"
_PyEval_EvalFrameDefault(tstate = 0x101c9554, f = 0x20107b40, throwflag 
= 570565024), line 1431 in "abstract.h"
_PyEval_Vector(tstate = 0x00000018, con = 0x200084a0, locals = 
0x220221f0, args = 0x88000284, argcount = 269576140, kwnames = 
0x2007a390), line 46 in "pycore_ceval.h"
_PyFunction_Vectorcall(func = 0x2007a4e0, stack = 0x20107b40, nargsf = 
570565168, kwnames = 0x20045994), line 361 in "call.c"
_PyObject_FastCallDictTstate(tstate = 0x100a7e84, callable = 0x302ed780, 
args = 0x220222b0, nargsf = 537155988, kwargs = 0x100a8a54), line 142 in 
"call.c"
_PyObject_Call_Prepend(tstate = 0x1001fa24, callable = 0x302ce5d0, obj = 
0x22022320, args = 0x20045994, kwargs = 0x100feffc), line 431 in "call.c"
slot_tp_init(self = 0x302e06f0, args = 0x30122e76, kwds = 0x30122e70), 
line 7097 in "typeobject.c"
unnamed block in type_call(type = 0x10105284, args = 0x20107b40, kwds 
= 
0x220223e0), line 1058 in "typeobject.c"
type_call(type = 0x10105284, args = 0x20107b40, kwds = 0x220223e0), 
line 
1058 in "typeobject.c"
_PyObject_MakeTpCall(tstate = 0x101194f4, callable = 0x20107b40, args 
= 
0x22022460, nargs = 537155988, keywords = 0x10167b60), line 215 in "call.c"
_PyEval_EvalFrameDefault(tstate = 0x3030e870, f = 0x3013007e, throwflag 
= 806551608), line 1429 in "abstract.h"
_PyEval_Vector(tstate = (nil), con = 0x303384a0, locals = 0x30130038, 
args = 0x3012e0d8, argcount = 806421984, kwnames = 0x301385c8), line 46 
in "pycore_ceval.h"
_PyFunction_Vectorcall(func = 0x1004067c, stack = 0x20107b40, nargsf = 
570566176, kwnames = 0x00000001), line 361 in "call.c"
_PyEval_EvalFrameDefault(tstate = 0x100feffc, f = 0x3003ad12, throwflag 
= 805547256), line 1431 in "abstract.h"
_PyEval_Vector(tstate = 0x30299248, con = 0x00000002, locals = 
0x3003acf8, args = 0x3023b570, argcount = 807246344, kwnames = 
0x3023e5c8), line 46 in "pycore_ceval.h"
_PyFunction_Vectorcall(func = 0x302d2ca0, stack = 0x3012dd18, nargsf = 
570566624, kwnames = 0x300426a0), line 361 in "call.c"
_PyEval_EvalFrameDefault(tstate = 0x10146304, f = 0x20107b40, throwflag 
= 0), line 1431 in "abstract.h"
_PyEval_Vector(tstate = 0x30324334, con = 0x20107b40, locals = 
0x30205cb8, args = 0x30215fd0, argcount = 807427328, kwnames = 
0x3023e550), line 46 in "pycore_ceval.h"
_PyFunction_Vectorcall(func = 0x10144378, stack = 0x20107b40, nargsf = 
570567072, kwnames = 0x20045994), line 361 in "call.c"
_PyEval_EvalFrameDefault(tstate = 0x200405e8, f = 0x20107b40, throwflag 
= 537971048), line 1431 in "abstract.h"
_PyEval_Vector(tstate = 0x00000052, con = 0x2010c9a8, locals = 
0x2010c968, args = 0x301d9c90, argcount = 806702304, kwnames = 
0x3023e208), line 46 in "pycore_ceval.h"
_PyFunction_Vectorcall(func = 0x00000008, stack = 0x3023c4a8, nargsf = 
570567520, kwnames = 0x30237e30), line 361 in "call.c"
_PyEval_EvalFrameDefault(tstate = 0x101c9554, f = (nil), throwflag = 

807029456), line 1431 in "abstract.h"
_PyEval_Vector(tstate = 0x300f9e98, con = 0x30237d18, locals = (nil), 
args = 0x302968d0, argcount = 537134568, kwnames = 0x30124a78), line 46 
in "pycore_ceval.h"
_PyFunction_Vectorcall(func = 0x2007a4e0, stack = 0x20107b40, nargsf = 
570567936, kwnames = 0x20045994), line 361 in "call.c"
unnamed block in _PyObject_FastCallDictTstate(tstate = 0x10167bb8, 
callable = 0x30233d50, args = 0x22022d80, nargsf = 1, kwargs = (nil)), 
line 153 in "call.c"
_PyObject_FastCallDictTstate(tstate = 0x10167bb8, callable = 0x30233d50, 
args = 0x22022d80, nargsf = 1, kwargs = (nil)), line 153 in "call.c"
_PyObject_Call_Prepend(tstate = 0x1001fa24, callable = 0x302968d0, obj = 
0x22022df0, args = 0x20045994, kwargs = 0x100feffc), line 431 in "call.c"
slot_tp_init(self = 0x3021a8d0, args = 0x20107b40, kwds = 0x22022e70), 
line 7097 in "typeobject.c"
unnamed block in type_call(type = 0x100a8684, args = 0x30206db0, kwds 
= 
0x22022eb0), line 1058 in "typeobject.c"
type_call(type = 0x100a8684, args = 0x30206db0, kwds = 0x22022eb0), 
line 
1058 in "typeobject.c"
_PyObject_MakeTpCall(tstate = 0x10119354, callable = 0x200c8404, args 
= 
0x22022f30, nargs = 537155988, keywords = 0x10167b60), line 215 in "call.c"
_PyEval_EvalFrameDefault(tstate = 0x2007a4e0, f = 0x20107b40, throwflag 
= 570568752), line 1429 in "abstract.h"
_PyEval_Vector(tstate = 0x100aa6fc, con = 0x200084a0, locals = 
0x220230a0, args = 0x20045994, argcount = 269575348, kwnames = 
0x20036690), line 46 in "pycore_ceval.h"
_PyFunction_Vectorcall(func = 0x302bc760, stack = 0x20107b40, nargsf = 
570568944, kwnames = 0x10458e60), line 361 in "call.c"
method_vectorcall(method = 0x30126e68, args = 0x30239030, nargsf = 
570569072, kwnames = 0x20045994), line 119 in "abstract.h"
_PyEval_EvalFrameDefault(tstate = (nil), f = 0x3012c898, throwflag = 
0), 
line 1431 in "abstract.h"
_PyEval_Vector(tstate = 0x30123bb0, con = 0x200084a0, locals = 
0x220232d0, args = 0x00000008, argcount = 352, kwnames = 0x20036690), 
line 46 in "pycore_ceval.h"
_PyFunction_Vectorcall(func = 0x3012ddd8, stack = 0x30232f80, nargsf = 
570569504, kwnames = 0x20045994), line 361 in "call.c"
PyVectorcall_Call(callable = 0x100a7e84, tuple = 0x3012c898, kwargs = 

0x22023370), line 255 in "call.c"
_PyObject_Call(tstate = 0x100aa6fc, callable = 0x20107b40, args = (nil), 
kwargs = 0x20045994), line 298 in "call.c"
do_call_core(tstate = 0x302c03b0, trace_info = 0x200084a0, func = 
0x22023460, callargs = (nil), kwdict = 0x10167b60), line 5974 in "ceval.c"
_PyEval_EvalFrameDefault(tstate = 0x302bb478, f = 0x3005d44c, throwflag 
= 805688288), line 4324 in "ceval.c"
_PyEval_Vector(tstate = 0x30187198, con = 0x3005d428, locals = 
0x3005d3e0, args = 0x301219b8, argcount = 806048208, kwnames = 
0x301316b8), line 46 in "pycore_ceval.h"
_PyFunction_Vectorcall(func = (nil), stack = (nil), nargsf = 570570272, 
kwnames = (nil)), line 361 in "call.c"
_PyEval_EvalFrameDefault(tstate = (nil), f = (nil), throwflag = 
806556888), line 1431 in "abstract.h"
_PyEval_Vector(tstate = 0x30187038, con = 0x20107b40, locals = 
0x30111768, args = 0x301219b8, argcount = 806560272, kwnames = 
0x301314d8), line 46 in "pycore_ceval.h"
_PyFunction_Vectorcall(func = (nil), stack = (nil), nargsf = 570570720, 
kwnames = (nil)), line 361 in "call.c"
_PyEval_EvalFrameDefault(tstate = (nil), f = 0x40000000, throwflag = 

-257396708), line 1431 in "abstract.h"
_PyEval_Vector(tstate = 0x22023cf0, con = 0x2000120c, locals = 
0x22023960, args = 0x220239f0, argcount = 3508213100, kwnames = 
0x22023cf0), line 46 in "pycore_ceval.h"
_PyFunction_Vectorcall(func = 0x220239f0, stack = (nil), nargsf = 
570572016, kwnames = 0x220239f0), line 361 in "call.c"
method_vectorcall(method = 0x10103bdc, args = (nil), nargsf = 0, kwnames 
= 0x20045994), line 119 in "abstract.h"
PyVectorcall_Call(callable = 0xdddddddd, tuple = 0xdddddddd, kwargs = 

0xdddddddd), line 255 in "call.c"
_PyObject_Call(tstate = (nil), callable = (nil), args = (nil), kwargs = 
(nil)), line 298 in "call.c"
thread_run(boot_raw = (nil)), line 1076 in "_threadmodule.c"
pythread_wrapper(arg = (nil)), line 240 in "thread_pthread.h"
(dbx)

>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue43665>
> _______________________________________
>

----------
title: [AIX] test_importlib: test_multiprocessing_pool_circular_import() killed by SIGTRAP (coredump) -> AIX: test_importlib regression (ENV change)
Added file: https://bugs.python.org/file49923/OpenPGP_0x722BFDB61F396FC2.asc

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43665>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x722BFDB61F396FC2.asc
Type: application/pgp-keys
Size: 1761 bytes
Desc: not available
URL: <https://mail.python.org/pipermail/python-bugs-list/attachments/20210331/c0d1a91b/attachment.key>

From report at bugs.python.org  Wed Mar 31 13:24:11 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 31 Mar 2021 17:24:11 +0000
Subject: [issue43567] regen.vcxproj cannot regenerate some necessary files
In-Reply-To: <1616238138.44.0.687655765468.issue43567@roundup.psfhosted.org>
Message-ID: <1617211451.74.0.391943092838.issue43567@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Anthony, can you help us out here? Is there a problem with regen.vcsproj, either by depending on VS 2019 (which we don't officially support yet) or by missing the changes in the names of some generated files?

----------
nosy: +anthonypjshaw

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43567>
_______________________________________

From report at bugs.python.org  Wed Mar 31 13:24:49 2021
From: report at bugs.python.org (hai shi)
Date: Wed, 31 Mar 2021 17:24:49 +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: <1617211489.75.0.146692367814.issue41111@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
keywords: +patch
pull_requests: +23864
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25115

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41111>
_______________________________________

From report at bugs.python.org  Wed Mar 31 13:25:21 2021
From: report at bugs.python.org (hai shi)
Date: Wed, 31 Mar 2021 17:25:21 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1617211521.37.0.675391738167.issue4111@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
pull_requests:  -23859

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Wed Mar 31 13:28:05 2021
From: report at bugs.python.org (hai shi)
Date: Wed, 31 Mar 2021 17:28:05 +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: <1617211685.05.0.612941400299.issue41111@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

> By the way, maybe Py_LIMITED_API should be defined in xxlimited.c, rather than in setup.py.

+1. Defining Py_LIMITED_API in xxlimited.c is more direct than in setup.py. so I created the PR-25115.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41111>
_______________________________________

From report at bugs.python.org  Wed Mar 31 13:30:14 2021
From: report at bugs.python.org (hai shi)
Date: Wed, 31 Mar 2021 17:30:14 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1617211814.43.0.81269770469.issue4111@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
pull_requests: +23865
pull_request: https://github.com/python/cpython/pull/25115

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Wed Mar 31 14:16:48 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Wed, 31 Mar 2021 18:16:48 +0000
Subject: [issue43492] Upgrade to SQLite 3.35.4 in macOS and Windows
In-Reply-To: <1615752732.27.0.278073347477.issue43492@roundup.psfhosted.org>
Message-ID: <1617214608.66.0.217612456491.issue43492@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

Quoting Dr. R. Hipp: "There will be a fix called version 3.35.4"

https://sqlite.org/forum/forumpost/7dbf046041519a07a0a083b8346a7d0ecb7d6fc4eca5ca23605eeb4452109d91

----------
title: Upgrade to SQLite 3.35.3 in macOS and Windows -> Upgrade to SQLite 3.35.4 in macOS and Windows

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43492>
_______________________________________

From report at bugs.python.org  Wed Mar 31 14:52:19 2021
From: report at bugs.python.org (Steve Dower)
Date: Wed, 31 Mar 2021 18:52:19 +0000
Subject: [issue43567] regen.vcxproj cannot regenerate some necessary files
In-Reply-To: <1616238138.44.0.687655765468.issue43567@roundup.psfhosted.org>
Message-ID: <1617216739.5.0.986195340504.issue43567@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch
pull_requests: +23866
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/25120

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43567>
_______________________________________

From report at bugs.python.org  Wed Mar 31 14:53:13 2021
From: report at bugs.python.org (Steve Dower)
Date: Wed, 31 Mar 2021 18:53:13 +0000
Subject: [issue43567] regen.vcxproj cannot regenerate some necessary files
In-Reply-To: <1616238138.44.0.687655765468.issue43567@roundup.psfhosted.org>
Message-ID: <1617216793.79.0.349630980142.issue43567@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I've attached my PR that streamlines this, it should be good (as in, reliable/fast) to do the regen on every build, but the "build.bat --regen" command is retained to force it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43567>
_______________________________________

From report at bugs.python.org  Wed Mar 31 15:11:29 2021
From: report at bugs.python.org (Tim Peters)
Date: Wed, 31 Mar 2021 19:11:29 +0000
Subject: [issue43593] pymalloc is not aware of Memory Tagging Extension (MTE)
 and crashes
In-Reply-To: <1616419787.13.0.506382582675.issue43593@roundup.psfhosted.org>
Message-ID: <1617217889.92.0.163403571869.issue43593@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

I'm skeptical ;-) If MTE is actually being used, system software assigns "random" values to 4 of the higher-order bits. When obmalloc punts to the system malloc, presumably those bits will be randomized in the addresses returned by malloc. Then it's just not possible that obmalloc's

    assert(HIGH_BITS(p) == HIGH_BITS(&arena_map_root));

can always succeed - we're insisting there that _all_ the high-order bits are exactly the same as in the `&arena_map_root` file static.  If `p` was actually obtained from the system `malloc()`, it should fail about 15 times out of 16 (and regardless of which of the 16 bit patterns the platform C assigns to &arena_map_root).

But, of course, that failure would only be seen in a debug build.

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43593>
_______________________________________

From report at bugs.python.org  Wed Mar 31 15:18:05 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 31 Mar 2021 19:18:05 +0000
Subject: [issue43567] regen.vcxproj cannot regenerate some necessary files
In-Reply-To: <1616238138.44.0.687655765468.issue43567@roundup.psfhosted.org>
Message-ID: <1617218285.97.0.299314940236.issue43567@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

@Jiaxin Please test steve's PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43567>
_______________________________________

From report at bugs.python.org  Wed Mar 31 15:36:16 2021
From: report at bugs.python.org (Steve Dower)
Date: Wed, 31 Mar 2021 19:36:16 +0000
Subject: [issue43105] [Windows] Can't import extension modules resolved via
 relative paths in sys.path
In-Reply-To: <1612285380.24.0.495785451269.issue43105@roundup.psfhosted.org>
Message-ID: <1617219376.66.0.901606737266.issue43105@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch
pull_requests: +23867
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25121

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43105>
_______________________________________

From report at bugs.python.org  Wed Mar 31 15:37:06 2021
From: report at bugs.python.org (Steve Dower)
Date: Wed, 31 Mar 2021 19:37:06 +0000
Subject: [issue43105] [Windows] Can't import extension modules resolved via
 relative paths in sys.path
In-Reply-To: <1612285380.24.0.495785451269.issue43105@roundup.psfhosted.org>
Message-ID: <1617219426.35.0.445964641375.issue43105@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Added one possible change as a PR, but will need the importlib folk to weigh in on whether it's the best place.

I also need to write a test (and possibly fix any tests that currently check that relative paths are _not_ resolved... letting CI handle that for me)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43105>
_______________________________________

From report at bugs.python.org  Wed Mar 31 15:58:35 2021
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 31 Mar 2021 19:58:35 +0000
Subject: [issue43124] [security] smtplib multiple CRLF injection
In-Reply-To: <1612443934.09.0.696762333019.issue43124@roundup.psfhosted.org>
Message-ID: <1617220715.54.0.074337915825.issue43124@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
nosy: +christian.heimes, lukasz.langa, ned.deily
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43124>
_______________________________________

From report at bugs.python.org  Wed Mar 31 15:59:03 2021
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 31 Mar 2021 19:59:03 +0000
Subject: [issue43223] [security] http.server: Open Redirection if the URL path
 starts with //
In-Reply-To: <1613302956.91.0.878390782912.issue43223@roundup.psfhosted.org>
Message-ID: <1617220743.89.0.649595313607.issue43223@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
nosy: +christian.heimes, lukasz.langa, ned.deily
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43223>
_______________________________________

From report at bugs.python.org  Wed Mar 31 15:59:14 2021
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 31 Mar 2021 19:59:14 +0000
Subject: [issue36384] ipaddress Should not reject IPv4 addresses with leading
 zeroes as ambiguously octal
In-Reply-To: <1553125209.55.0.0358803413865.issue36384@roundup.psfhosted.org>
Message-ID: <1617220754.34.0.00734195941591.issue36384@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
nosy: +lukasz.langa
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36384>
_______________________________________

From report at bugs.python.org  Wed Mar 31 16:00:15 2021
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 31 Mar 2021 20:00:15 +0000
Subject: [issue36997] Document that spwd is considered harmful
In-Reply-To: <1558458009.82.0.580344483538.issue36997@roundup.psfhosted.org>
Message-ID: <1617220815.35.0.690044396856.issue36997@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
priority: high -> normal
type: security -> enhancement
versions: +Python 3.10 -Python 2.7, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36997>
_______________________________________

From report at bugs.python.org  Wed Mar 31 16:00:43 2021
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 31 Mar 2021 20:00:43 +0000
Subject: [issue17305] IDNA2008 encoding is missing
In-Reply-To: <1361928766.42.0.728949411958.issue17305@psf.upfronthosting.co.za>
Message-ID: <1617220843.06.0.199477303021.issue17305@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
priority: critical -> high
type: security -> enhancement
versions: +Python 3.10 -Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17305>
_______________________________________

From report at bugs.python.org  Wed Mar 31 16:01:45 2021
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 31 Mar 2021 20:01:45 +0000
Subject: [issue43631] Update to OpenSSL 1.1.1k
In-Reply-To: <1616746538.63.0.13329268116.issue43631@roundup.psfhosted.org>
Message-ID: <1617220905.12.0.0252349382666.issue43631@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

CI, macOS and Windows infrastructure have been updated.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43631>
_______________________________________

From report at bugs.python.org  Wed Mar 31 16:51:11 2021
From: report at bugs.python.org (Derek Wilson)
Date: Wed, 31 Mar 2021 20:51:11 +0000
Subject: [issue17305] IDNA2008 encoding is missing
In-Reply-To: <1361928766.42.0.728949411958.issue17305@psf.upfronthosting.co.za>
Message-ID: <1617223871.13.0.918525451733.issue17305@roundup.psfhosted.org>


Derek Wilson <jderekwilson at gmail.com> added the comment:

why the downgrade from security to enhancement and critical to high?

this is a significant issue that can impact everything from phishing to TLS certificate domain validation and SNI.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17305>
_______________________________________

From report at bugs.python.org  Wed Mar 31 17:12:54 2021
From: report at bugs.python.org (Jim Jewett)
Date: Wed, 31 Mar 2021 21:12:54 +0000
Subject: [issue24275] lookdict_* give up too soon
In-Reply-To: <1432444109.96.0.971324850141.issue24275@psf.upfronthosting.co.za>
Message-ID: <1617225174.35.0.533432452979.issue24275@roundup.psfhosted.org>


Jim Jewett <jimjjewett at gmail.com> added the comment:

What is the status on this?  If you are losing interest, would you like someone else to turn your patch into a pull request?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24275>
_______________________________________

From report at bugs.python.org  Wed Mar 31 17:15:15 2021
From: report at bugs.python.org (Hristo Venev)
Date: Wed, 31 Mar 2021 21:15:15 +0000
Subject: [issue24275] lookdict_* give up too soon
In-Reply-To: <1432444109.96.0.971324850141.issue24275@psf.upfronthosting.co.za>
Message-ID: <1617225315.31.0.88362579521.issue24275@roundup.psfhosted.org>


Hristo Venev <hristo at venev.name> added the comment:

Sorry, I must have missed Inada Naoki's reply. I will try to send a pull request this weekend.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24275>
_______________________________________

From report at bugs.python.org  Wed Mar 31 18:10:19 2021
From: report at bugs.python.org (anthony shaw)
Date: Wed, 31 Mar 2021 22:10:19 +0000
Subject: [issue43567] regen.vcxproj cannot regenerate some necessary files
In-Reply-To: <1616238138.44.0.687655765468.issue43567@roundup.psfhosted.org>
Message-ID: <1617228619.81.0.162832660912.issue43567@roundup.psfhosted.org>


anthony shaw <anthony.p.shaw at gmail.com> added the comment:

Guido, regen.vcxproj targets 142 as the SDK version, which is most likely a mistake.
The other projects are part of the main PCBuild.sln solution, which has a variable for the base SDK version.

If you need to change it quickly, you can either open it in VS and right click on the project and change the properties to an older SDK, or edit the vcxproj file itself.

I can make this change in a patch, but because its a standalone project, it doesn't share the base SDK version with the others.

I've reviewed Steve's patch and it would fix this because it changes regen into a build target instead of a build project, so it doesn't specify the SDK version at all.
Steve's implementation is also much, much cleaner!

----------
nosy: +anthony shaw

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43567>
_______________________________________

From report at bugs.python.org  Wed Mar 31 18:16:14 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 31 Mar 2021 22:16:14 +0000
Subject: [issue43567] regen.vcxproj cannot regenerate some necessary files
In-Reply-To: <1616238138.44.0.687655765468.issue43567@roundup.psfhosted.org>
Message-ID: <1617228974.03.0.709717498498.issue43567@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43567>
_______________________________________

From report at bugs.python.org  Wed Mar 31 18:20:23 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 31 Mar 2021 22:20:23 +0000
Subject: [issue43665] AIX: test_importlib regression (ENV change)
In-Reply-To: <1617089431.51.0.0013168061581.issue43665@roundup.psfhosted.org>
Message-ID: <1617229223.62.0.791138492504.issue43665@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Interesting part of the traceback:

pthread_cond_signal at AF29_12(??, ??) at 0xd11b1568
...
release_sentinel
...
_PyThreadState_DeleteExcept
...
PyOS_AfterFork_Child(), line 600 in "posixmodule.c"

It sounds like a variant of bpo-40092: "Crash in _PyThreadState_DeleteExcept() at fork in the process child".

See also the parent issue: https://bugs.python.org/issue40068#msg365031

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43665>
_______________________________________

From report at bugs.python.org  Wed Mar 31 18:20:40 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 31 Mar 2021 22:20:40 +0000
Subject: [issue43665] AIX: test_importlib regression (ENV change)
In-Reply-To: <1617089431.51.0.0013168061581.issue43665@roundup.psfhosted.org>
Message-ID: <1617229240.09.0.364584793899.issue43665@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Crash in _PyThreadState_DeleteExcept() at fork in the process child

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43665>
_______________________________________

From report at bugs.python.org  Wed Mar 31 18:21:37 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 31 Mar 2021 22:21:37 +0000
Subject: [issue40092] Crash in _PyThreadState_DeleteExcept() at fork in the
 process child
In-Reply-To: <1585329415.65.0.534969367772.issue40092@roundup.psfhosted.org>
Message-ID: <1617229297.44.0.13526419425.issue40092@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I marked bpo-43665 "AIX: test_importlib regression (ENV change)" as a duplicate of this issue.

test_multiprocessing_pool_circular_import() of test_importlib now triggers this crash as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40092>
_______________________________________

From report at bugs.python.org  Wed Mar 31 18:40:08 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 31 Mar 2021 22:40:08 +0000
Subject: [issue37945] [Windows]
 test_locale.TestMiscellaneous.test_getsetlocale_issue1813() fails
In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org>
Message-ID: <1617230408.81.3.79116783978e-05.issue37945@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Great!  For the first time in over 2 years, the test suite passes on a Windows repository build on my machine.  I will test installed 3.10 after the next alpha release.  (3.10.0a7 has other failures as well.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37945>
_______________________________________

From report at bugs.python.org  Wed Mar 31 18:40:32 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 31 Mar 2021 22:40:32 +0000
Subject: [issue43684] Add combined opcodes
Message-ID: <1617230432.54.0.49540913796.issue43684@roundup.psfhosted.org>


New submission from Guido van Rossum <guido at python.org>:

I'm lining up some PRs (inspired by some of Mark Shannon's ideas) that add new opcodes which are straightforward combinations of existing opcodes. For example, ADD_INT is equivalent to LOAD_CONST + BINARY_ADD, for certain small (common) integer constants.

Each of these adds only a minor speedup, but after a dozen or so of these the speedup is (hopefully) significant enough to warrant the opcode churn.

----------
messages: 389939
nosy: Mark.Shannon, eric.snow, gvanrossum, pablogsal
priority: normal
severity: normal
status: open
title: Add combined opcodes
type: performance
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43684>
_______________________________________

From report at bugs.python.org  Wed Mar 31 18:40:57 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 31 Mar 2021 22:40:57 +0000
Subject: [issue43684] Add combined opcodes
In-Reply-To: <1617230432.54.0.49540913796.issue43684@roundup.psfhosted.org>
Message-ID: <1617230457.23.0.574130334183.issue43684@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
keywords: +patch
pull_requests: +23868
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25090

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43684>
_______________________________________

From report at bugs.python.org  Wed Mar 31 18:47:06 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 31 Mar 2021 22:47:06 +0000
Subject: [issue37945] [Windows]
 test_locale.TestMiscellaneous.test_getsetlocale_issue1813() fails
In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org>
Message-ID: <1617230826.67.0.732861525024.issue37945@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Great!  For the first time in over 2 years, the test suite passes on a Windows repository build on my machine. 

Nice :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37945>
_______________________________________

From report at bugs.python.org  Wed Mar 31 19:03:30 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 31 Mar 2021 23:03:30 +0000
Subject: [issue42955] Add sys.stdlib_module_names: list of stdlib module names
 (Python and extension modules)
In-Reply-To: <1610964514.06.0.696047252341.issue42955@roundup.psfhosted.org>
Message-ID: <1617231810.45.0.821480164207.issue42955@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +23869
pull_request: https://github.com/python/cpython/pull/25122

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42955>
_______________________________________

From report at bugs.python.org  Wed Mar 31 19:48:20 2021
From: report at bugs.python.org (Zackery Spytz)
Date: Wed, 31 Mar 2021 23:48:20 +0000
Subject: [issue43677] Descriptor.rst - Reference to Py_MethodType is not up to
 date
In-Reply-To: <1617181085.74.0.392624279534.issue43677@roundup.psfhosted.org>
Message-ID: <1617234500.09.0.967157829406.issue43677@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 4.0 -> 5.0
pull_requests: +23870
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25123

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43677>
_______________________________________

From report at bugs.python.org  Wed Mar 31 20:10:39 2021
From: report at bugs.python.org (miss-islington)
Date: Thu, 01 Apr 2021 00:10:39 +0000
Subject: [issue42840] `type` takes **kwargs for __init_subclass__
In-Reply-To: <1609946481.51.0.225785046936.issue42840@roundup.psfhosted.org>
Message-ID: <1617235839.77.0.811907033105.issue42840@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b3c1e2c493e67f84b1034ac6c49492a459b0736d by Miss Islington (bot) in branch '3.9':
bpo-42840: Document providing kwargs to type. (GH-24173)
https://github.com/python/cpython/commit/b3c1e2c493e67f84b1034ac6c49492a459b0736d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42840>
_______________________________________

From report at bugs.python.org  Wed Mar 31 20:28:36 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Apr 2021 00:28:36 +0000
Subject: [issue42955] Add sys.stdlib_module_names: list of stdlib module names
 (Python and extension modules)
In-Reply-To: <1610964514.06.0.696047252341.issue42955@roundup.psfhosted.org>
Message-ID: <1617236916.07.0.927865985014.issue42955@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset ad493edf5791e7abb2588852e876b8584945c653 by Victor Stinner in branch 'master':
bpo-42955: Add _overlapped to sys.stdlib_module_names (GH-25122)
https://github.com/python/cpython/commit/ad493edf5791e7abb2588852e876b8584945c653


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42955>
_______________________________________

From report at bugs.python.org  Wed Mar 31 20:56:53 2021
From: report at bugs.python.org (Neil Schemenauer)
Date: Thu, 01 Apr 2021 00:56:53 +0000
Subject: [issue43593] pymalloc is not aware of Memory Tagging Extension (MTE)
 and crashes
In-Reply-To: <1616419787.13.0.506382582675.issue43593@roundup.psfhosted.org>
Message-ID: <1617238613.04.0.53352811335.issue43593@roundup.psfhosted.org>


Neil Schemenauer <nas-python at arctrix.com> added the comment:

> If MTE is actually being used, system software assigns "random" values to 4 of the higher-order bits.

Oh, interesting.

Two ideas about handling that: we could change our assertion check to be different on ARM platforms that we know have a certain size physical address space.  Probably just turn off that high-bits check.

Second idea, we could change the radix tree to not assume high address bits are unused.  That's trickier to do without performance or memory usage degradations.  I have a work-in-progress patch that adds a cache on top of the radix tree lookup.  It looks like that cache can be made to have a pretty high hit rate.  Based on a small amount of testing, the radix tree lookup for address_in_range() only happens about 1% of the time.  If that approach works, we could add another layer to the tree and handle the full 64-bit address space.

Based on my wip testing, my benchmark was showing about equal performance with the cache to without.  So, no benefit to offset the increase in code complexity.  Handling the MTE high bits tricks might enough to justify the cache addition.

----------
versions: +Python 3.9 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43593>
_______________________________________

From report at bugs.python.org  Wed Mar 31 20:57:31 2021
From: report at bugs.python.org (Julien Castiaux)
Date: Thu, 01 Apr 2021 00:57:31 +0000
Subject: [issue43330] xmlrpc.Server URI query and fragment are discarded from
 HTTP query since py3
In-Reply-To: <1614358939.96.0.184711772416.issue43330@roundup.psfhosted.org>
Message-ID: <1617238651.5.0.976897869077.issue43330@roundup.psfhosted.org>


Julien Castiaux <julien.castiaux at gmail.com> added the comment:

Duplicate of 43433

----------
message_count: 1.0 -> 2.0
pull_requests: +23871
resolution:  -> duplicate
status: open -> closed
pull_request: https://github.com/python/cpython/pull/25057

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43330>
_______________________________________

From report at bugs.python.org  Wed Mar 31 21:30:12 2021
From: report at bugs.python.org (Wm. Keith van der Meulen)
Date: Thu, 01 Apr 2021 01:30:12 +0000
Subject: [issue42914] pprint numbers with underscore
In-Reply-To: <1610493681.29.0.683565759752.issue42914@roundup.psfhosted.org>
Message-ID: <1617240612.08.0.559252893798.issue42914@roundup.psfhosted.org>


Change by Wm. Keith van der Meulen <keith at wkeithvan.com>:


----------
nosy: +wkeithvan
nosy_count: 7.0 -> 8.0
pull_requests: +23872
pull_request: https://github.com/python/cpython/pull/25124

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42914>
_______________________________________

From report at bugs.python.org  Wed Mar 31 22:23:22 2021
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 01 Apr 2021 02:23:22 +0000
Subject: [issue43651] PEP 597: Fix EncodingWarning warnings in the Python
 stdlib
Message-ID: <1617243802.32.0.330769768422.issue43651@roundup.psfhosted.org>


New submission from Inada Naoki <songofacandy at gmail.com>:


New changeset 55f31be44b7e3ee24a67134f99543512a9b630e4 by Inada Naoki in branch 'master':
bpo-43651: Fix EncodingWarning in test_file and test_file_eintr (GH-25109)
https://github.com/python/cpython/commit/55f31be44b7e3ee24a67134f99543512a9b630e4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43651>
_______________________________________

From report at bugs.python.org  Wed Mar 31 22:25:10 2021
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 01 Apr 2021 02:25:10 +0000
Subject: [issue43651] PEP 597: Fix EncodingWarning warnings in the Python
 stdlib
In-Reply-To: <1617243802.32.0.330769768422.issue43651@roundup.psfhosted.org>
Message-ID: <1617243910.39.0.575537129121.issue43651@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset 58cffba1874f0e9a9731b25a3e11a011bfbbf95f by Inada Naoki in branch 'master':
bpo-43651: Fix EncodingWarning in test_io (GH-25097)
https://github.com/python/cpython/commit/58cffba1874f0e9a9731b25a3e11a011bfbbf95f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43651>
_______________________________________

From report at bugs.python.org  Wed Mar 31 22:37:08 2021
From: report at bugs.python.org (=?utf-8?q?Jo=C3=ABl_Larose?=)
Date: Thu, 01 Apr 2021 02:37:08 +0000
Subject: [issue43685] __call__ not being called on metaclass
Message-ID: <1617244628.3.0.903633823298.issue43685@roundup.psfhosted.org>


New submission from Jo?l Larose <joel.larose at gmail.com>:

Hi,

I'm trying to implement a metaclass for the singleton pattern, with the intent of creating type-appropriate sentinels.  After trying several approaches, I've come up with what I thought would be an elegant solution.  

However, I've run into a bit of a snag.  Whenever I "call" the class to get the instance, the machinery behind the scenes always calls __init__.  To bypass this, I tried overriding type.__call__ in my metaclass.  Contrary to all the documentation I've read, metaclass.__call__ is not being used.  The call sequence goes straight to class.__new__ and class.__init__.

=====================================================
M = TypeVar("M")

class SingletonMeta(type):
    """Metaclass for single value classes."""
    def __call__(cls: Type[M], *args: Any, **kwargs: Any) -> M:

        ### Never see this line of output
        print(f"{cls.__name__}.__call__({args=}, {kwargs=}")

        it: Optional[M] = cast(Optional[M], cls.__dict__.get("__it__"))
        if it is not None:
            return it

        try:
            it = cls.__new__(*args, **kwargs)
            it.__init__(*args, **kwargs)
        except TypeError:
            it = cls.__new__()
            it.__init__()

        # cls.__it__ = it
        return it

    def __new__(mcs, name: str, bases: th.Bases, namespace: th.DictStrAny,
                **kwargs: Any) -> SingletonMeta:
        print(f"{mcs.__name__}.__new__({name=}, {bases=}, {namespace=}, {kwargs=}")
        new_cls: SingletonMeta = cast(SingletonMeta, type(name, bases, namespace))
        print(f"{new_cls=}")
        print(f"{new_cls.__call__}")

        ### Both of these lines ignore the __call__ defined in this metaclass
        ### They produce TypeError if the class doesn't define __new__ or __init__ accepting arguments
        # new_cls.__it__ = new_cls(new_cls, **kwargs)
        # new_cls.__it__ = new_cls.__call__(new_cls, **kwargs)

        return new_cls


Here's the output I get after defining the metaclass and try to use it:
>>> class S(metaclass=SingletonMeta):
...    pass
SingletonMeta.__new__(name='S', bases=(), namespace={'__module__': '__main__', '__qualname__': 'S'}, kwargs={}
new_cls=<class '__main__.S'>
<method-wrapper '__call__' of type object at 0x000002C1283BF1D0>
>>> S()
<__main__.S object at 0x000002C128AE5940>
>>> S()
<__main__.S object at 0x000002C128AE56A0>


If SingletonMeta.__call__ was being used, I would see the output from that call, and consecutive calls to S() would yield the same object (with the same address).  As you can see, that is not the case.


Environment: 
Python 3.9.0 (tags/v3.9.0:9cf6752, Oct  5 2020, 15:34:40) [MSC v.1927 64 bit (AMD64)] on win32

Is this a bug?  Or am I misunderstanding how/when __call__ gets called?

----------
components: Interpreter Core
messages: 389947
nosy: joel.larose
priority: normal
severity: normal
status: open
title: __call__ not being called on metaclass
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43685>
_______________________________________

From report at bugs.python.org  Wed Mar 31 22:45:25 2021
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 01 Apr 2021 02:45:25 +0000
Subject: [issue43651] PEP 597: Fix EncodingWarning warnings in the Python
 stdlib
In-Reply-To: <1617243802.32.0.330769768422.issue43651@roundup.psfhosted.org>
Message-ID: <1617245125.13.0.0537689692174.issue43651@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +23873
pull_request: https://github.com/python/cpython/pull/25126

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43651>
_______________________________________

From report at bugs.python.org  Wed Mar 31 22:54:00 2021
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 01 Apr 2021 02:54:00 +0000
Subject: [issue43651] PEP 597: Fix EncodingWarning warnings in the Python
 stdlib
In-Reply-To: <1617243802.32.0.330769768422.issue43651@roundup.psfhosted.org>
Message-ID: <1617245640.13.0.796580976939.issue43651@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +23874
pull_request: https://github.com/python/cpython/pull/25127

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43651>
_______________________________________

From report at bugs.python.org  Wed Mar 31 23:10:13 2021
From: report at bugs.python.org (William Pickard)
Date: Thu, 01 Apr 2021 03:10:13 +0000
Subject: [issue43685] __call__ not being called on metaclass
In-Reply-To: <1617244628.3.0.903633823298.issue43685@roundup.psfhosted.org>
Message-ID: <1617246613.6.0.436566686429.issue43685@roundup.psfhosted.org>


William Pickard <lollol222gg at gmail.com> added the comment:

This line is the cause of your issue: "new_cls: SingletonMeta = cast(SingletonMeta, type(name, bases, namespace))"

More specifically, your call to type() actually erases all information about your meta class. If you did "type(S)", you would've seen "type" returned.

Replace it with: "new_cls: SingletonMeta = super().__new__(name, bases, namespace)"

----------
nosy: +WildCard65

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43685>
_______________________________________

From report at bugs.python.org  Wed Mar 31 23:11:36 2021
From: report at bugs.python.org (Alexander Grigoriev)
Date: Thu, 01 Apr 2021 03:11:36 +0000
Subject: [issue43686] re.match appears to hang with certain combinations of
 pattern and string
Message-ID: <1617246696.22.0.947636964181.issue43686@roundup.psfhosted.org>


New submission from Alexander Grigoriev <alegrigoriev at gmail.com>:

Certain patterns and input strings cause re.match to take exponentially longer time. This can be expected because of recursive nature of matching some patterns, but it can take surprisingly long time with some combination of a pattern and input data of moderate length. For example:

import re
import time

t1 = time.monotonic()
re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define EVENT_ {\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n')
t2 = time.monotonic()
print(r"re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define EVENT_ {\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n'): %s s" % (t2-t1))
t1 = time.monotonic()
re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define EVENT_D {\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n')
t2 = time.monotonic()
print(r"re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define EVENT_D {\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n'): %s s" % (t2-t1))
t1 = time.monotonic()
re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define EVENT_DI {\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n')
t2 = time.monotonic()
print(r"re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define EVENT_DI {\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n'): %s s" % (t2-t1))
t1 = time.monotonic()
re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define EVENT_DIS {\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n')
t2 = time.monotonic()
print(r"re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define EVENT_DIS {\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n'): %s s" % (t2-t1))
t1 = time.monotonic()
re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define EVENT_DISP {\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n')
t2 = time.monotonic()
print(r"re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define EVENT_DISP {\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n'): %s s" % (t2-t1))
t1 = time.monotonic()
re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define EVENT_DISPL {\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n')
t2 = time.monotonic()
print(r"re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define EVENT_DISPL {\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n'): %s s" % (t2-t1))
t1 = time.monotonic()
re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define EVENT_DISPLA {\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n')
t2 = time.monotonic()
print(r"re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define EVENT_DISPLA {\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n'): %s s" % (t2-t1))
t1 = time.monotonic()
re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define EVENT_DISPLAY {\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n')
t2 = time.monotonic()
print(r"re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define EVENT_DISPLAY {\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n'): %s s" % (t2-t1))


Does:

re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define EVENT_ {\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n'): 0.2190000000409782 s
re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define EVENT_D {\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n'): 0.4529999999795109 s
re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define EVENT_DI {\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n'): 0.9529999999795109 s
re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define EVENT_DIS {\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n'): 1.797000000020489 s
re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define EVENT_DISP {\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n'): 3.6090000001713634 s
re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define EVENT_DISPL {\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n'): 7.125 s
re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define EVENT_DISPLA {\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n'): 14.890999999828637 s
re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define EVENT_DISPLAY {\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n'): 29.688000000081956 s


Perhaps re.match needs to be optimized and/or rewritten in low level language (C)

----------
components: Library (Lib)
messages: 389949
nosy: alegrigoriev
priority: normal
severity: normal
status: open
title: re.match appears to hang with certain combinations of pattern and string
type: performance
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43686>
_______________________________________

From report at bugs.python.org  Wed Mar 31 23:14:36 2021
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 01 Apr 2021 03:14:36 +0000
Subject: [issue43651] PEP 597: Fix EncodingWarning warnings in the Python
 stdlib
In-Reply-To: <1617243802.32.0.330769768422.issue43651@roundup.psfhosted.org>
Message-ID: <1617246876.45.0.479301539007.issue43651@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +23875
pull_request: https://github.com/python/cpython/pull/25128

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43651>
_______________________________________

From report at bugs.python.org  Wed Mar 31 23:39:21 2021
From: report at bugs.python.org (junyixie)
Date: Thu, 01 Apr 2021 03:39:21 +0000
Subject: [issue43687] use unicode_state empty string before unicode_init.
 without define WITH_DOC_STRINGS
Message-ID: <1617248361.55.0.452091252277.issue43687@roundup.psfhosted.org>


New submission from junyixie <xie.junyi at outlook.com>:

use unicode_state empty string before unicode_init. without define WITH_DOC_STRINGS.

PyType_Ready call PyUnicode_FromString, if doc string striped, cause crash.

unicode_get_empty() must not be called before _PyUnicode_Init() or after _PyUnicode_Fini()

PyType_Ready
```
const char *old_doc = _PyType_DocWithoutSignature(type->tp_name,type->tp_doc);
PyObject *doc = PyUnicode_FromString(old_doc);
```

----------
messages: 389950
nosy: JunyiXie
priority: normal
severity: normal
status: open
title: use unicode_state empty string before unicode_init. without define WITH_DOC_STRINGS
type: crash
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43687>
_______________________________________

From report at bugs.python.org  Wed Mar 31 23:41:08 2021
From: report at bugs.python.org (junyixie)
Date: Thu, 01 Apr 2021 03:41:08 +0000
Subject: [issue43687] use unicode_state empty string before unicode_init.
 without define WITH_DOC_STRINGS
In-Reply-To: <1617248361.55.0.452091252277.issue43687@roundup.psfhosted.org>
Message-ID: <1617248468.28.0.910511056834.issue43687@roundup.psfhosted.org>


Change by junyixie <xie.junyi at outlook.com>:


----------
keywords: +patch
pull_requests: +23876
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25129

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43687>
_______________________________________

From report at bugs.python.org  Wed Mar 31 23:49:20 2021
From: report at bugs.python.org (Dennis Sweeney)
Date: Thu, 01 Apr 2021 03:49:20 +0000
Subject: [issue43685] __call__ not being called on metaclass
In-Reply-To: <1617244628.3.0.903633823298.issue43685@roundup.psfhosted.org>
Message-ID: <1617248960.31.0.226452954868.issue43685@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

typing.cast doesn't actually do anything, it only exists as a hint for type-checkers.

As William noted, using the 3-argument type(...) as you showed will only return a type, not a mcs.

I think you may want super().__new__(mcs, name, bases, namespace), which will return an instance of mcs. You could also write type.__new__(mcs, name, bases, namespace), but that would make multiple inheritance harder should you ever want to do that. 

Another note: x(*args) translates to type(x).__call__(x, *args), so whether or not I am callable depends not on whether I have a __call__ attribute, but rather on whether my type has a __call__ attribute

See also: https://stackoverflow.com/q/6760685/11461120

----------
nosy: +Dennis Sweeney

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43685>
_______________________________________