From report at bugs.python.org  Wed Dec  1 00:08:15 2021
From: report at bugs.python.org (Collin Anderson)
Date: Wed, 01 Dec 2021 05:08:15 +0000
Subject: [New-bugs-announce] [issue45944] Avoid calling isatty() for most
 open() calls
Message-ID: <1638335295.8.0.118316980587.issue45944@roundup.psfhosted.org>


Change by Collin Anderson <cmawebsite at gmail.com>:


----------
components: IO
nosy: collinanderson
priority: normal
severity: normal
status: open
title: Avoid calling isatty() for most open() calls
type: performance
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Dec  1 03:58:16 2021
From: report at bugs.python.org (Alexander Kanavin)
Date: Wed, 01 Dec 2021 08:58:16 +0000
Subject: [New-bugs-announce] [issue45945] compileall.py throws a traceback
 when using -j0 and thus 'make install' locks up
Message-ID: <1638349096.96.0.35958886089.issue45945@roundup.psfhosted.org>


New submission from Alexander Kanavin <alex.kanavin at gmail.com>:

Hello, Yocto project has had to disable -j0 for compileall, so that it runs serially. If it doesn't, then 'make install' locks up sporadically, with hanging processes:
```
3837320 ?        SN     0:00                  \_ make -j 16 -l 52 STAGING_LIBDIR=/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280438/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/recipe-sysroot/usr/lib STAGING_INCDIR=/
 157523 ?        SNl    0:02                      \_ python3.10 -Wi -OO /home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280438/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10/compileall.py -j0 -d /u
 160673 ?        SN     0:00                          \_ python3.10 -Wi -OO /home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280438/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10/compileall.py -j0 -
 160677 ?        SN     0:00                          \_ python3.10 -Wi -OO /home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280438/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10/compileall.py -j0 -
 160682 ?        SN     0:00                          \_ python3.10 -Wi -OO /home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280438/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10/compileall.py -j0 -
 160697 ?        SN     0:00                          \_ python3.10 -Wi -OO /home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280438/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10/compileall.py -j0 -
 160759 ?        SN     0:00                          \_ python3.10 -Wi -OO /home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280438/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10/compileall.py -j0 -
 160816 ?        SN     0:00                          \_ python3.10 -Wi -OO /home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280438/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10/compileall.py -j0 -
...
```

and installation log reveals:
```
poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10/compileall.py \
        -j0 -d /usr/lib/python3.10 -f \
        -x 'bad_coding|badsyntax|site-packages|lib2to3/tests/data' \
        /home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280388/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10
Listing '/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280388/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10'...
Listing '/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280388/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10/asyncio'...
Listing '/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280388/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10/collections'...
Listing '/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280388/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10/concurrent'...
Listing '/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280388/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10/concurrent/futures'...
Listing '/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280388/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10/config-3.10-x86_64-linux-gnu'...
Listing '/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280388/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10/ctypes'...
Listing '/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280388/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10/ctypes/macholib'...
...
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280388/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10/threading.py", line 1009, in _bootstrap_inner
    self.run()
  File "/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280388/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10/concurrent/futures/process.py", line 317, in run
    result_item, is_broken, cause = self.wait_result_broken_or_wakeup()
  File "/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280388/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10/concurrent/futures/process.py", line 376, in wait_result_broken_or_wakeup
    worker_sentinels = [p.sentinel for p in self.processes.values()]
  File "/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280388/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10/concurrent/futures/process.py", line 376, in <listcomp>
    worker_sentinels = [p.sentinel for p in self.processes.values()]
RuntimeError: dictionary changed size during iteration
```

----------
components: Library (Lib)
messages: 407431
nosy: Alexander Kanavin
priority: normal
severity: normal
status: open
title: compileall.py throws a traceback when using -j0 and thus 'make install' locks up
versions: Python 3.10

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

From report at bugs.python.org  Wed Dec  1 05:19:19 2021
From: report at bugs.python.org (Gobot1234)
Date: Wed, 01 Dec 2021 10:19:19 +0000
Subject: [New-bugs-announce] [issue45946] RecursionError when annotating a
 field with the same name as a field
Message-ID: <1638353959.47.0.043888744355.issue45946@roundup.psfhosted.org>


New submission from Gobot1234 <gobot1234yt at gmail.com>:

Small snippet to reproduce:
```
from dataclasses import dataclass, field

@dataclass
class Foo:
    bool: bool = field()
```
Raises
```
---------------------------------------------------------------------------
RecursionError                            Traceback (most recent call last)
<ipython-input-1-dce9c97e78ae> in <module>
      2 
      3 @dataclass
----> 4 class Foo:
      5     bool: bool = field()
      6 

/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/dataclasses.py in dataclass(cls, init, repr, eq, order, unsafe_hash, frozen, match_args, kw_only, slots)
   1176 
   1177     # We're called as @dataclass without parens.
-> 1178     return wrap(cls)
   1179 
   1180 

/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/dataclasses.py in wrap(cls)
   1167 
   1168     def wrap(cls):
-> 1169         return _process_class(cls, init, repr, eq, order, unsafe_hash,
   1170                               frozen, match_args, kw_only, slots)
   1171 

/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/dataclasses.py in _process_class(cls, init, repr, eq, order, unsafe_hash, frozen, match_args, kw_only, slots)
   1085         # Create a class doc-string.
   1086         cls.__doc__ = (cls.__name__ +
-> 1087                        str(inspect.signature(cls)).replace(' -> None', ''))
   1088 
   1089     if match_args:

/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/inspect.py in __str__(self)
   3200         render_kw_only_separator = True
   3201         for param in self.parameters.values():
-> 3202             formatted = str(param)
   3203 
   3204             kind = param.kind

/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/inspect.py in __str__(self)
   2717         if self._annotation is not _empty:
   2718             formatted = '{}: {}'.format(formatted,
-> 2719                                        formatannotation(self._annotation))
   2720 
   2721         if self._default is not _empty:

/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/inspect.py in formatannotation(annotation, base_module)
   1362             return annotation.__qualname__
   1363         return annotation.__module__+'.'+annotation.__qualname__
-> 1364     return repr(annotation)
   1365 
   1366 def formatannotationrelativeto(object):

/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/dataclasses.py in __repr__(self)
    281 
    282     def __repr__(self):
--> 283         return ('Field('
    284                 f'name={self.name!r},'
    285                 f'type={self.type!r},'

... last 1 frames repeated, from the frame below ...

/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/dataclasses.py in __repr__(self)
    281 
    282     def __repr__(self):
--> 283         return ('Field('
    284                 f'name={self.name!r},'
    285                 f'type={self.type!r},'

RecursionError: maximum recursion depth exceeded while getting the repr of an object
```
This is due to the self.type being the field itself as the annotation is evaluated using the class namespace.

----------
components: Library (Lib)
messages: 407438
nosy: Gobot1234, eric.smith
priority: normal
severity: normal
status: open
title: RecursionError when annotating a field with the same name as a field
type: crash
versions: Python 3.11

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

From report at bugs.python.org  Wed Dec  1 08:30:48 2021
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 01 Dec 2021 13:30:48 +0000
Subject: [New-bugs-announce] [issue45947] Place dict (and values) pointers
 at a fixed (negative) offset from the base of the object.
Message-ID: <1638365448.99.0.213832334161.issue45947@roundup.psfhosted.org>


New submission from Mark Shannon <mark at hotpy.org>:

To get to the dict (or values array) of an object, we currently need 3 dependent loads.
By placing the dict at a fixed offset, this can be reduced to one.

What was `obj[obj->type->dictoffset]` becomes `obj[FIXED_OFFSET]`

See https://github.com/faster-cpython/ideas/issues/80, specifically
https://github.com/faster-cpython/ideas/issues/80#issuecomment-931504847 for more details.

----------
assignee: Mark.Shannon
components: Interpreter Core
messages: 407457
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: Place dict (and values) pointers at a fixed (negative) offset from the base of the object.
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Wed Dec  1 09:07:52 2021
From: report at bugs.python.org (Robert Steed)
Date: Wed, 01 Dec 2021 14:07:52 +0000
Subject: [New-bugs-announce] [issue45948] Unexpected instantiation behavior
 for xml.etree.ElementTree.XMLParser(target=None)
Message-ID: <1638367672.95.0.357017255599.issue45948@roundup.psfhosted.org>


New submission from Robert Steed <rdsteed at steeds.us>:

Expected instantiation of xml.etree.ElementTree.XMLParser(target=None) to create a parser using default TreeBuilder

----------
components: XML
files: XMLParserFail.py
messages: 407458
nosy: rdsteed
priority: normal
severity: normal
status: open
title: Unexpected instantiation behavior for xml.etree.ElementTree.XMLParser(target=None)
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file50465/XMLParserFail.py

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

From report at bugs.python.org  Wed Dec  1 10:34:28 2021
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 01 Dec 2021 15:34:28 +0000
Subject: [New-bugs-announce] [issue45949] Provide pure-Python implementation
 of Programs/_freeze_module for cross building
Message-ID: <1638372868.47.0.982140813893.issue45949@roundup.psfhosted.org>


New submission from Christian Heimes <lists at cheimes.de>:

As of today 3.11-dev requires Programs/_freeze_module to compile Python code to byte code. The dependency on an extra and special tool makes cross building more complicated. The _freeze_module is trivial and can be easily implemented in pure Python code. The re-introduction of _bootstrap_python helper would allow us to use a pure Python freeze_module for all modules except two importlib bootstrap modules. I have a proof of concept implementation that works for me.

Proposal for standard builds:
- Use Programs/_freeze_module to create Python/frozen_modules/importlib._bootstrap.h and Python/frozen_modules/importlib._bootstrap_external.h
- build _bootstrap_python
- use new tool "./_bootstrap_python Tools/scripts/freezemodule.py" to create remaining Python/frozen_modules/*.h

Proposal for cross builds:
- use user-provider Python interpreter (./configure --with-build-python) to generate all Python/frozen_modules/*.h with new freezemodule.py tool.

When cross building the user must already provide a Python interpreter with same version and bytecode version as the build target. Users would no longer need to provide a _freeze_module binary with ./configure --with-freeze-module.

----------
assignee: christian.heimes
components: Build, Cross-Build
messages: 407459
nosy: Alex.Willmer, christian.heimes, gvanrossum
priority: normal
severity: normal
status: open
title: Provide pure-Python implementation of Programs/_freeze_module for cross building
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Wed Dec  1 11:26:37 2021
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 01 Dec 2021 16:26:37 +0000
Subject: [New-bugs-announce] [issue45950] Reintroduce bootstrap_python for
 freezing
Message-ID: <1638375997.48.0.12074215987.issue45950@roundup.psfhosted.org>


New submission from Christian Heimes <lists at cheimes.de>:

bpo-45696 introduced a _bootstrap_python interpreter, which was used to create frozen and deepfrozen module files. bpo-45873 dropped the _bootstrap_python interpreter again. Instead Python used an existing Python installation to bootstrap the build.

After some internal discussion we agreed that the approach is flawed and puts too much of a burden on users. Users have to install a fairly recent Python interpreter in order to build 3.11. This makes it harder to build Python on platforms with no or a too old Python version. It also complicated things for container builds and pyenv.

Let's re-introduce a _bootstrap_python interpreter. Cross compiling will still require a build Python interpreter.

----------
components: Build
messages: 407467
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: Reintroduce bootstrap_python for freezing
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Wed Dec  1 12:48:23 2021
From: report at bugs.python.org (Ben)
Date: Wed, 01 Dec 2021 17:48:23 +0000
Subject: [New-bugs-announce] [issue45951] Debugger cannot be resolved
Message-ID: <1638380903.59.0.519590962782.issue45951@roundup.psfhosted.org>


New submission from Ben <benboettcher at rocketmail.com>:

First, I am not a programmer by any stretch of the imagination, and I am just trying to get this error solved.

I attempted to highlight and comment out a section of code, maybe 20 lines, and the program froze, greyed out, and gave me a spinning wheel mouse.

I closed & reopened program, attempted with one line of code and it worked, attempted again with 5 lines and same issue occurred.

I have attached a screenshot of the error message and didn't seen how the associated error related.  

https://bugs.python.org/issue1180193

The screen was greyed out yes, but I didn't change anything or close the program.  I left the night before and when I attempted it this morning it started behaving in this manner.

----------
files: Python error.png
messages: 407473
nosy: boett1
priority: normal
severity: normal
status: open
title: Debugger cannot be resolved
versions: Python 3.7
Added file: https://bugs.python.org/file50468/Python error.png

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

From report at bugs.python.org  Wed Dec  1 12:49:22 2021
From: report at bugs.python.org (Eric Snow)
Date: Wed, 01 Dec 2021 17:49:22 +0000
Subject: [New-bugs-announce] [issue45952] Tools/c-analyzer is out-of-date.
Message-ID: <1638380962.78.0.734744265271.issue45952@roundup.psfhosted.org>


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

Some relatively recent changes broke "./python Tools/c-analyzer/c-analyzer.py ...".  Also, Tools/c-analyzer/TODO is a bit out of date.

----------
assignee: eric.snow
components: Demos and Tools
messages: 407474
nosy: eric.snow
priority: normal
pull_requests: 28108
severity: normal
stage: patch review
status: open
title: Tools/c-analyzer is out-of-date.
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Wed Dec  1 13:50:39 2021
From: report at bugs.python.org (Eric Snow)
Date: Wed, 01 Dec 2021 18:50:39 +0000
Subject: [New-bugs-announce] [issue45953] Statically allocate interpreter
 states as much as possible.
Message-ID: <1638384639.14.0.97360024283.issue45953@roundup.psfhosted.org>


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

Currently we allocate each new PyInterpreterState in PyInterpreterState_New().  Furthermore, PyInterpreterState is full of pointers which are almost all allocated on the heap during runtime init.  We can statically allocate (and initialize?) most of what goes into PyInterpreterState, as well as the main interpreter itself (as part of _PyRuntimeState).  This includes each interpreter's initial PyThreadState.

TODO:

* [ ] add `PyInterpreterState main;` to _PyRuntimeState.interpreters and use it
* [ ] change references from the pointer to the value
* [ ] add `PyThreadState _main;` to PyInterpreterState.threads and use it
* [ ] change references from the pointer to the value
* [ ] change PyInterpreterState pointer fields to values (as much as possible)
* [ ] change PyThreadState pointer fields to values (as much as possible)


benefits:

* fewer possible failures (no memory) during runtime/interpreter/thread init
* improved memory locality for pointers looked up relative to interpreter/thread state


There is one non-trivial bit: embedding the various PyObject values in PyInterpreterState and PyThreadState means hard-coding the various pieces of the object there (e.g. for dict, its keys/values; for list, its array), as well as adding necessary init code to PyInterpreterState_New() and PyThreadState_New().  The resulting added complexity can be mitigated somewhat with macros or even code generation.  (In fact, there is probably significant overlap with Guido's deepfreeze tool.)  Regardless, we'll probably need to factor out init funcs for a number of object types, where currently there are only "Py*_New()" funcs that combine allocation and init.

----------
assignee: eric.snow
components: Interpreter Core
messages: 407476
nosy: Mark.Shannon, eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: Statically allocate interpreter states as much as possible.
versions: Python 3.11

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

From report at bugs.python.org  Wed Dec  1 13:54:08 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Dec 2021 18:54:08 +0000
Subject: [New-bugs-announce] [issue45954] Rename PyConfig.no_debug_ranges to
 PyConfig.code_debug_ranges
Message-ID: <1638384848.75.0.0549104552795.issue45954@roundup.psfhosted.org>


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

In the PyConfig, I tried to avoid double negative, so "no_debug_ranges" should be "debug_ranges". I propose to rename it to "code_debug_ranges" to make it more specific.

If there is an agreement on the member name, I can write a PR.

----------
components: C API
messages: 407478
nosy: pablogsal, vstinner
priority: normal
severity: normal
status: open
title: Rename PyConfig.no_debug_ranges to PyConfig.code_debug_ranges
versions: Python 3.11

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

From report at bugs.python.org  Wed Dec  1 14:12:05 2021
From: report at bugs.python.org (Matt Martz)
Date: Wed, 01 Dec 2021 19:12:05 +0000
Subject: [New-bugs-announce] [issue45955] Calling read() on HTTPError may
 cause KeyError in tempfile
Message-ID: <1638385925.39.0.609829377944.issue45955@roundup.psfhosted.org>


New submission from Matt Martz <matt at sivel.net>:

HTTPError may not be fully initialized in some scenarios leading to an inconsistent interface.  This is documented in code at:

https://github.com/python/cpython/blob/55fe1ae9708d81b902b6fe8f6590e2a24b1bd4b0/Lib/urllib/error.py#L45-L50

Unfortunately the way this is implemented creates an inconsistent interface, and opaque code, without a number of inline comments explaining the behavior of HTTPError.

Additionally, the way that it currently works, will cause a KeyError to be raised from tempfile, which is rather confusing.

Instead of "partially initializing" the HTTPError object, I'd propose that when fp is None, that we provide it with something like io.BytesIO to fulfill the interface.  There may be other recommended solutions, I've not thought through this extensively yet.

I think I just prefer always calling self.__super_init but passing in something like io.BytesIO if fp is None

I'm willing to create the PR once I know which direction seems to make the most sense.

>>> from urllib.error import HTTPError
>>> from urllib.request import HTTPDigestAuthHandler, HTTPPasswordMgrWithDefaultRealm, build_opener
>>> passman = HTTPPasswordMgrWithDefaultRealm()
>>> passman.add_password(None, 'httpbin.org', 'user', 'wrong')
>>> opener = build_opener(HTTPDigestAuthHandler(passman))
>>> try:
...     opener.open('https://httpbin.org/digest-auth/auth/user/passwd')
... except HTTPError as e:
...     e.read()
...
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
  File ".../3.10.0/lib/python3.10/urllib/request.py", line 525, in open
    response = meth(req, response)
  File ".../3.10.0/lib/python3.10/urllib/request.py", line 634, in http_response
    response = self.parent.error(
  File ".../3.10.0/lib/python3.10/urllib/request.py", line 557, in error
    result = self._call_chain(*args)
  File ".../3.10.0/lib/python3.10/urllib/request.py", line 496, in _call_chain
    result = func(*args)
  File ".../3.10.0/lib/python3.10/urllib/request.py", line 1238, in http_error_401
    retry = self.http_error_auth_reqed('www-authenticate',
  File ".../3.10.0/lib/python3.10/urllib/request.py", line 1111, in http_error_auth_reqed
    raise HTTPError(req.full_url, 401, "digest auth failed",


During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 4, in <module>
  File ".../3.10.0/lib/python3.10/tempfile.py", line 473, in __getattr__
    file = self.__dict__['file']
KeyError: 'file'

----------
components: Library (Lib)
messages: 407482
nosy: sivel
priority: normal
severity: normal
status: open
title: Calling read() on HTTPError may cause KeyError in tempfile
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Dec  1 16:37:32 2021
From: report at bugs.python.org (Maxwell Bernstein)
Date: Wed, 01 Dec 2021 21:37:32 +0000
Subject: [New-bugs-announce] [issue45956] Add scanf regular expressions to re
Message-ID: <1638394652.04.0.59126527646.issue45956@roundup.psfhosted.org>


New submission from Maxwell Bernstein <tekk.nolagi at gmail.com>:

The documentation for the `re` module suggests several regular expressions for use in simulating `scanf()`. Provide these directly in the `re` module.

----------
components: Library (Lib)
messages: 407491
nosy: tekknolagi
priority: normal
severity: normal
status: open
title: Add scanf regular expressions to re
versions: Python 3.11

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

From report at bugs.python.org  Wed Dec  1 16:54:38 2021
From: report at bugs.python.org (Ali Amin-Nejad)
Date: Wed, 01 Dec 2021 21:54:38 +0000
Subject: [New-bugs-announce] [issue45957] _tkinter.TclError: expected
 boolean value but got ""
Message-ID: <1638395678.26.0.142189706167.issue45957@roundup.psfhosted.org>


New submission from Ali Amin-Nejad <aanejad at hotmail.co.uk>:

On macOS, the following minimal example:

```
import tkinter as tk

root = tk.Tk()
button = tk.Button(root, text="Exit", command=root.destroy)
button.pack()
root.wm_overrideredirect(True)

root.mainloop()
```

yields the following stack trace:

```
Traceback (most recent call last):
  File "blah.py", line 6, in <module>
    root.wm_overrideredirect(True)
  File "/Users/ali/miniconda3/envs/bitfount/lib/python3.8/tkinter/__init__.py", line 2176, in wm_overrideredirect
    return self._getboolean(self.tk.call(
  File "/Users/ali/miniconda3/envs/bitfount/lib/python3.8/tkinter/__init__.py", line 1448, in _getboolean
    return self.tk.getboolean(string)
_tkinter.TclError: expected boolean value but got ""
```

----------
components: Tkinter, macOS
messages: 407494
nosy: amin-nejad, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: _tkinter.TclError: expected boolean value but got ""
type: crash
versions: Python 3.8

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

From report at bugs.python.org  Wed Dec  1 21:45:07 2021
From: report at bugs.python.org (Hian-Kun Tenn)
Date: Thu, 02 Dec 2021 02:45:07 +0000
Subject: [New-bugs-announce] [issue45958] Document typo in unpack_from()
Message-ID: <1638413107.8.0.703943462848.issue45958@roundup.psfhosted.org>


New submission from Hian-Kun Tenn <hiankun at gmail.com>:

In the document of "struct" (https://docs.python.org/3.9/library/struct.html#struct.unpack_from), there's typo in it.

The document read
`struct.unpack_from(format, /, buffer, offset=0)`
and I believe it should be
`struct.unpack_from(format, buffer, offset=0)`.

Documents before Python 3.9 has no this typo.

----------
assignee: docs at python
components: Documentation
messages: 407510
nosy: docs at python, hiankun
priority: normal
severity: normal
status: open
title: Document typo in unpack_from()
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Thu Dec  2 02:06:56 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 02 Dec 2021 07:06:56 +0000
Subject: [New-bugs-announce] [issue45959] Teach pprint about dict views
Message-ID: <1638428816.23.0.206050902249.issue45959@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

The pprint() code has a number of type or protocol specific handlers but doesn't have one for dict views.  So, we don't get pretty printing for the key(), values(), and items():

d = {i:i for i in range(100)}
pprint(d)             # This is handled correctly
pprint(d.keys())      # Printed on one line
pprint(d.values())    # Printed on one line
pprint(d.items())     # Printed on one line

----------
components: Library (Lib)
keywords: easy
messages: 407513
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Teach pprint about dict views
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Thu Dec  2 03:42:21 2021
From: report at bugs.python.org (Sascha Hesse)
Date: Thu, 02 Dec 2021 08:42:21 +0000
Subject: [New-bugs-announce] [issue45960] bullseye arm/v7 time.time()
 Operation not permitted
Message-ID: <1638434541.68.0.574461669418.issue45960@roundup.psfhosted.org>


New submission from Sascha Hesse <py at mnm-solutions.de>:

Given a docker container on raspbian 10.11
based on bullseye:

docker run --rm -it --entrypoint sh python:3.10-slim

time.time() fails with error

# python
Python 3.10.0 (default, Nov 18 2021, 00:56:34) [GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.time()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
PermissionError: [Errno 1] Operation not permitted

based on buster:

docker run --rm -it --entrypoint sh python:3.10-slim-buster

# python
Python 3.10.0 (default, Nov 18 2021, 02:00:41) [GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.time()
1638433441.9555993
>>> exit()
#

works as expected

----------
components: Interpreter Core
messages: 407515
nosy: SaschaJohn
priority: normal
severity: normal
status: open
title: bullseye arm/v7 time.time() Operation not permitted
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Thu Dec  2 03:59:29 2021
From: report at bugs.python.org (Alex)
Date: Thu, 02 Dec 2021 08:59:29 +0000
Subject: [New-bugs-announce] [issue45961] [doc] Missing documentation for
 wait_for module
Message-ID: <1638435569.2.0.657271084148.issue45961@roundup.psfhosted.org>


New submission from Alex <aizquier at redhat.com>:

I wondering why there is no documentation for the synchronous module "wait_for":

site-packages/wait_for/__init__.py

It's just missing or there are some reason? I didn't see any deprecation info about this module.

----------
messages: 407516
nosy: Alex-Izquierdo
priority: normal
severity: normal
status: open
title: [doc] Missing documentation for wait_for module
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/issue45961>
_______________________________________

From report at bugs.python.org  Thu Dec  2 04:15:17 2021
From: report at bugs.python.org (Antony Lee)
Date: Thu, 02 Dec 2021 09:15:17 +0000
Subject: [New-bugs-announce] [issue45962] Clarify that
 PyModule_AddString{Constant, Macro} use utf-8
Message-ID: <1638436517.15.0.508323988448.issue45962@roundup.psfhosted.org>


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

The documentation for PyModule_AddString{Constant,Macro} does not specify the encoding used.  Checking the source shows that these simply call PyUnicode_FromString and thus use utf8, but perhaps this could be made explicit.

----------
assignee: docs at python
components: C API, Documentation
messages: 407518
nosy: Antony.Lee, docs at python
priority: normal
severity: normal
status: open
title: Clarify that PyModule_AddString{Constant,Macro} use utf-8
versions: Python 3.11

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

From report at bugs.python.org  Thu Dec  2 07:27:40 2021
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 02 Dec 2021 12:27:40 +0000
Subject: [New-bugs-announce] [issue45963] Embed interpreter frame in
 generator.
Message-ID: <1638448060.39.0.766103367856.issue45963@roundup.psfhosted.org>


New submission from Mark Shannon <mark at hotpy.org>:

Currently, the InterpreterFrame for a generator is allocated on the heap separately from the generator.
This means that 2 allocations are needed to create a generator, and an extra indirection is needed to get from the generator to the frame.

By embedding the frame in the generator, we only need one alloaction, we save an indirection *and* the code gets simpler: transferring the frame from generator to frame object is just a single memcpy.

----------
assignee: Mark.Shannon
components: Interpreter Core
messages: 407526
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: Embed interpreter frame in generator.
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Thu Dec  2 08:50:38 2021
From: report at bugs.python.org (Matej Cepl)
Date: Thu, 02 Dec 2021 13:50:38 +0000
Subject: [New-bugs-announce] [issue45964] 3.10.0 tests fail in
 test_pdb_breakpoints_preserved_across_interactive_sessions
Message-ID: <1638453038.24.0.528506960629.issue45964@roundup.psfhosted.org>


New submission from Matej Cepl <mcepl at cepl.eu>:

When running tests with 3.10.0 test_pdb_breakpoints_preserved_across_interactive_sessions test fails:

[  842s] ======================================================================
[  842s] FAIL: test_pdb_breakpoints_preserved_across_interactive_sessions (test.test_pdb)
[  842s] Doctest: test.test_pdb.test_pdb_breakpoints_preserved_across_interactive_sessions
[  842s] ----------------------------------------------------------------------
[  842s] Traceback (most recent call last):
[  842s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/doctest.py", line 2216, in runTest
[  842s]     raise self.failureException(self.format_failure(new.getvalue()))
[  842s] AssertionError: Failed doctest test for test.test_pdb.test_pdb_breakpoints_preserved_across_interactive_sessions
[  842s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_pdb.py", line 327, in test_pdb_breakpoints_preserved_across_interactive_sessions
[  842s] 
[  842s] ----------------------------------------------------------------------
[  842s] File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_pdb.py", line 351, in test.test_pdb.test_pdb_breakpoints_preserved_across_interactive_sessions
[  842s] Failed example:
[  842s]     with PdbTestInput([  # doctest: +ELLIPSIS, +NORMALIZE_WHITESPACE
[  842s]        'break',
[  842s]        'break pdb.find_function',
[  842s]        'break',
[  842s]        'clear 1',
[  842s]        'continue',
[  842s]     ]):
[  842s]        pdb.run('print()')
[  842s] Expected:
[  842s]     > <string>(1)<module>()...
[  842s]     (Pdb) break
[  842s]     Num Type         Disp Enb   Where
[  842s]     1   breakpoint   keep yes   at ...test_pdb.py:...
[  842s]     2   breakpoint   keep yes   at ...test_pdb.py:...
[  842s]     (Pdb) break pdb.find_function
[  842s]     Breakpoint 3 at ...pdb.py:94
[  842s]     (Pdb) break
[  842s]     Num Type         Disp Enb   Where
[  842s]     1   breakpoint   keep yes   at ...test_pdb.py:...
[  842s]     2   breakpoint   keep yes   at ...test_pdb.py:...
[  842s]     3   breakpoint   keep yes   at ...pdb.py:...
[  842s]     (Pdb) clear 1
[  842s]     Deleted breakpoint 1 at ...test_pdb.py:...
[  842s]     (Pdb) continue
[  842s] Got:
[  842s]     > <string>(1)<module>()
[  842s]     (Pdb) break
[  842s]     Num Type         Disp Enb   Where
[  842s]     1   breakpoint   keep yes   at /home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_pdb.py:425
[  842s]     2   breakpoint   keep yes   at /home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_pdb.py:422
[  842s]     (Pdb) break pdb.find_function
[  842s]     Breakpoint 3 at /home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/pdb.py:93
[  842s]     (Pdb) break
[  842s]     Num Type         Disp Enb   Where
[  842s]     1   breakpoint   keep yes   at /home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_pdb.py:425
[  842s]     2   breakpoint   keep yes   at /home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_pdb.py:422
[  842s]     3   breakpoint   keep yes   at /home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/pdb.py:93
[  842s]     (Pdb) clear 1
[  842s]     Deleted breakpoint 1 at /home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_pdb.py:425
[  842s]     (Pdb) continue
[  842s]     <BLANKLINE>
[  842s] 
[  842s] 
[  842s] ----------------------------------------------------------------------
[  842s] Ran 1 test in 0.005s
[  842s] 
[  842s] FAILED (failures=1)
[  842s] 1 test failed again:
[  842s]     test_pdb
[  842s] 
[  842s] == Tests result: FAILURE then FAILURE ==

The problem is completely trivial and the attached patch fixes it (wrong line number in one expected result).

----------
components: Demos and Tools
files: pdb_adjust_breakpoints.patch
keywords: patch
messages: 407527
nosy: mcepl
priority: normal
severity: normal
status: open
title: 3.10.0 tests fail in test_pdb_breakpoints_preserved_across_interactive_sessions
versions: Python 3.10, Python 3.11
Added file: https://bugs.python.org/file50470/pdb_adjust_breakpoints.patch

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

From report at bugs.python.org  Thu Dec  2 10:46:59 2021
From: report at bugs.python.org (Jamil Raichouni)
Date: Thu, 02 Dec 2021 15:46:59 +0000
Subject: [New-bugs-announce] [issue45965] fileinput.input(path,
 inplace=True) crashes for valid filename with 252-255 characters
Message-ID: <1638460019.0.0.188953265928.issue45965@roundup.psfhosted.org>


New submission from Jamil Raichouni <raichouni at gmail.com>:

import fileinput
from pathlib import Path
path = Path(252 * "x")
path.write_text("")
for line in fileinput.input(path, inplace=True):
    pass

raises an

OSError: [Errno 63] File name too long

for perfectly valid (yes, quite long) file names.

Reason:

Internally the fileinput library creates a backup file when we pass 'inplace=True' to fileinput.input() and that backup file gets a file name that is longer than the name for the file of interest.

Enhancement idea:

Work with a backup file name that is sth like GUID.bak or remove some chars from the original file name.

Hint:

vim /path/to/my/file creates a .swp file and can handle very long file names with 252-255 chars.

----------
components: Library (Lib)
files: long_filename_passed_to_fileinput.ipynb
messages: 407534
nosy: jamil.raichouni
priority: normal
severity: normal
status: open
title: fileinput.input(path, inplace=True) crashes for valid filename with 252-255 characters
type: enhancement
versions: Python 3.10
Added file: https://bugs.python.org/file50471/long_filename_passed_to_fileinput.ipynb

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

From report at bugs.python.org  Thu Dec  2 11:39:50 2021
From: report at bugs.python.org (Mukesh)
Date: Thu, 02 Dec 2021 16:39:50 +0000
Subject: [New-bugs-announce] [issue45966] Error in Multiplication
Message-ID: <1638463190.07.0.716534365359.issue45966@roundup.psfhosted.org>


New submission from Mukesh <mikebon007 at gmail.com>:

I've tried various methods to multiply some numbers but every time I get an unsatisfying result when I try to evaluate 48*1.2 or 41*1.2 or 51*1.4 etc. For example if I run

import math
NUM3 = eval(input("Your Input: "))
print(NUM3)

Output:
Your Input: 51*1.4
71.39999999999999

Now it should give me a straight 71.4 but instead it's giving 71.39999999999999

It's not an issue with the version of python that I'm using cause I've already tried it on various versions.

----------
components: Interpreter Core
messages: 407537
nosy: M1kE
priority: normal
severity: normal
status: open
title: Error in Multiplication
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Thu Dec  2 15:58:32 2021
From: report at bugs.python.org (Harold Meneley)
Date: Thu, 02 Dec 2021 20:58:32 +0000
Subject: [New-bugs-announce] [issue45967] treeview
Message-ID: <1638478712.78.0.334069010053.issue45967@roundup.psfhosted.org>


New submission from Harold Meneley <hmeneley at gmail.com>:

treeview does not clear after opening and reopening another using same code block, You can see leftover treeview after clear and reopen. Simply clikc on file > view all, clear > clear, and then search > author and you should see problem

----------
components: Tkinter
files: MyBooks.py
messages: 407547
nosy: hmeneley
priority: normal
severity: normal
status: open
title: treeview
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file50472/MyBooks.py

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

From report at bugs.python.org  Thu Dec  2 17:23:07 2021
From: report at bugs.python.org (Luca)
Date: Thu, 02 Dec 2021 22:23:07 +0000
Subject: [New-bugs-announce] [issue45968] Windows installer should add also
 "%USERPROFILE%\AppData\Roaming\Python\Python3x\Scripts" folder to the PATH
 environment variable
Message-ID: <1638483787.98.0.55945714586.issue45968@roundup.psfhosted.org>


New submission from Luca <lucatrv at hotmail.com>:

This issue is related to https://bugs.python.org/issue3561

When installing Python under Windows, if the "Add Python 3.x to PATH" option is flagged, the following two folders are added to the PATH environment variable:
%USERPROFILE%\AppData\Local\Programs\Python\Python3x\
%USERPROFILE%\AppData\Local\Programs\Python\Python3x\Scripts\

However also the following folder should be added, which is where scripts reside when packages are installed with "pip install --user":
%USERPROFILE%\AppData\Roaming\Python\Python3x\Scripts\

----------
components: Installation, Windows
messages: 407550
nosy: lucatrv, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows installer should add also "%USERPROFILE%\AppData\Roaming\Python\Python3x\Scripts" folder to the PATH environment variable
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Thu Dec  2 17:36:06 2021
From: report at bugs.python.org (Luca)
Date: Thu, 02 Dec 2021 22:36:06 +0000
Subject: [New-bugs-announce] [issue45969] When uninstalling Python under
 Windows the "Scripts" folders should be removed from the PATH environment
 variable
Message-ID: <1638484566.06.0.085894454168.issue45969@roundup.psfhosted.org>


New submission from Luca <lucatrv at hotmail.com>:

This issue is related to:
  https://bugs.python.org/issue3561
and:
  https://bugs.python.org/issue45968

When installing Python under Windows, if the "Add Python 3.x to PATH" option is flagged, the following two folders are added to the PATH environment variable:
  %USERPROFILE%\AppData\Local\Programs\Python\Python3x\
  %USERPROFILE%\AppData\Local\Programs\Python\Python3x\Scripts\

However when uninstalling Pyhton only the former folder is removed from the PATH environment variable, and not the latter one.

Moreover if also the following folder will be added to the PATH environment variable in future (see issue #45968):
  %USERPROFILE%\AppData\Roaming\Python\Python3x\Scripts\
then the same would apply to it.

----------
components: Installation, Windows
messages: 407551
nosy: lucatrv, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: When uninstalling Python under Windows the "Scripts" folders should be removed from the PATH environment variable
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Fri Dec  3 00:35:05 2021
From: report at bugs.python.org (Jason Haslam)
Date: Fri, 03 Dec 2021 05:35:05 +0000
Subject: [New-bugs-announce] [issue45970] Py_NewInterpreter causes bogus
 fatal error along the failure path
Message-ID: <1638509705.87.0.0666625525238.issue45970@roundup.psfhosted.org>


New submission from Jason Haslam <jason.haslam at gmail.com>:

The failure cleanup of `Py_NewInterpreter` causes a bogus fatal error on the call to `PyThreadState_Delete`. The error is about deleting the current thread state. The saved thread state should be swapped back in *before* deleting the new thread state.

----------
components: C API
messages: 407566
nosy: jason.haslam
priority: normal
severity: normal
status: open
title: Py_NewInterpreter causes bogus fatal error along the failure path
type: crash
versions: Python 3.11

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

From report at bugs.python.org  Fri Dec  3 02:26:06 2021
From: report at bugs.python.org (Venkata Raman S S V)
Date: Fri, 03 Dec 2021 07:26:06 +0000
Subject: [New-bugs-announce] [issue45971] calendar module issue
Message-ID: <1638516366.75.0.743197554563.issue45971@roundup.psfhosted.org>


New submission from Venkata Raman S S V <ssv5088 at gmail.com>:

In Ubuntu 20.04.3 LTS  -  OS Type: 64-bit.

$ cal sep 1752
   September 1752     
Su Mo Tu We Th Fr Sa  
       1  2 14 15 16  
17 18 19 20 21 22 23  
24 25 26 27 28 29 30  

--------------------------------

$ python3
Python 3.8.10 (default, Sep 28 2021, 16:10:42) 
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

import calendar as cl
yy=1752
mm=9

print(cl.month(yy,mm))
   September 1752
Mo Tu We Th Fr Sa Su
             1  2  3
 4  5  6  7  8  9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 

Note: Sep. 1752 had only 19 days. ( 11 days skipped )

----------
components: Extension Modules
messages: 407567
nosy: ssv5088
priority: normal
severity: normal
status: open
title: calendar module issue
versions: Python 3.8

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

From report at bugs.python.org  Fri Dec  3 03:45:38 2021
From: report at bugs.python.org (Erik Montnemery)
Date: Fri, 03 Dec 2021 08:45:38 +0000
Subject: [New-bugs-announce] [issue45972] typing.NamedTuple with default
 arguments without type annotations is falsy
Message-ID: <1638521138.51.0.177788503063.issue45972@roundup.psfhosted.org>


New submission from Erik Montnemery <erik at montnemery.com>:

typing.NamedTuple behaves in surprising ways when it has default arguments which lack type annotations:

>>> from typing import NamedTuple
>>> class MyTuple(NamedTuple):
...     a = 1000
...
>>> tmp = MyTuple()
>>> tmp.a
1000
>>> len(tmp)
0
>>> bool(tmp)
False

Tested in Python 3.8 and 3.9

----------
messages: 407570
nosy: emontnemery
priority: normal
severity: normal
status: open
title: typing.NamedTuple with default arguments without type annotations is falsy
type: behavior
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Dec  3 09:11:14 2021
From: report at bugs.python.org (Daniel)
Date: Fri, 03 Dec 2021 14:11:14 +0000
Subject: [New-bugs-announce] [issue45973] Not possible to clear
 PyImport_Inittab after PyImport_AppendInittab
Message-ID: <1638540674.64.0.96956184479.issue45973@roundup.psfhosted.org>


New submission from Daniel <danielfa at fixedit.ai>:

Hello,

When embedding Python into a C application and not using Py_RunMain it is not possible to remove a module added to PyImport_Inittab even if the interpreter is finalized and a new is created.

One reason for not using Py_RunMain is to use python as a subprocessor to my primary C application by initializing an interpreter, run some python code, then go back to execute some C code and again execute some python code in the same interpreter. After a while I might want to finalize the interpreter and create a new one without the module added to inittab, still being in the same process.

See example:

#include <Python.h>


/*
 * Create a python interpreter, run a command and delete the interpreter
 */
void run_in_new_interpreter(char *cmd) {
    Py_Initialize();

    PyRun_SimpleString(cmd);

    if (Py_FinalizeEx() < 0) {
        exit(120);
    }
}

/*
 * Create a module "my_spam" but do not append it to inittab
 */
static PyModuleDef EmbModule = {
      PyModuleDef_HEAD_INIT, "my_spam", NULL, -1,
      NULL,
      NULL, NULL, NULL, NULL
};

static PyObject* PyInit_emb(void) {
    return PyModule_Create(&EmbModule);
}

/*
 * Main program
 */
char *LIST_MODULES_CMD="try:\n import my_spam; print('SPAM!');\nexcept:\n print('no mod my_spam')";

int main(int argc, char *argv[]) {
    // Run with no "my_spam" module
    run_in_new_interpreter(LIST_MODULES_CMD);

    // Run with "my_spam" module
    PyImport_AppendInittab("my_spam", &PyInit_emb);
    run_in_new_interpreter(LIST_MODULES_CMD);

    // How to run without my_spam? The module is still in the PyImport_Inittab
    // despite the Py_FinalizeEx() call. This list is not reset until
    // _PyImport_Fini2() is called, but that is never exposed in anyi public header,
    // only in Include/internal/pycore_pylifecycle.h
    run_in_new_interpreter(LIST_MODULES_CMD);
    return 0;
}



The output of the program is:

>>> gcc test_embed.c `pkg-config --cflags --libs python-3.6` && ./a.out
no mod my_spam
SPAM!
SPAM!

----------
components: C API
messages: 407590
nosy: daniel-falk
priority: normal
severity: normal
status: open
title: Not possible to clear PyImport_Inittab after PyImport_AppendInittab
type: behavior

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

From report at bugs.python.org  Fri Dec  3 17:07:41 2021
From: report at bugs.python.org (Fatih Kilic)
Date: Fri, 03 Dec 2021 22:07:41 +0000
Subject: [New-bugs-announce] [issue45974] Using walrus produces
 different/unoptimized bytecode
Message-ID: <1638569261.56.0.379053627232.issue45974@roundup.psfhosted.org>


New submission from Fatih Kilic <me at fklc.dev>:

So, what I mean by unoptimized bytecode is, for example when you type `a = 10 * 10`, the resulting bytecode is the following: 
```
LOAD_CONST 0 (100)
STORE_NAME 0 (a)
...
```

However, when you type, `(a := 10 * 10) == None`, the resulting bytecode is the following:
```
LOAD_CONST 0 (10)
LOAD_CONST 0 (10)
BINARY_MULTIPLY
DUP_TOP
STORE_NAME 0 (a)
...
```

I don't know if this is intentional, but shouldn't the resulting bytecode be the following:
```
LOAD_CONST 0 (100)
DUP_TOP
STORE_NAME 0 (a)
...
```

----------
components: Parser
messages: 407610
nosy: FKLC, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Using walrus produces different/unoptimized bytecode
type: behavior
versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Dec  3 18:15:50 2021
From: report at bugs.python.org (Nick Drozd)
Date: Fri, 03 Dec 2021 23:15:50 +0000
Subject: [New-bugs-announce] [issue45975] Simplify some while-loops with
 walrus operator
Message-ID: <1638573350.23.0.80297686747.issue45975@roundup.psfhosted.org>


New submission from Nick Drozd <nicholasdrozd at gmail.com>:

The following pattern occurs a few times in the codebase:

  while 1:
      data = conn.recv(blocksize)
      if not data:
          break
      ...

There is an unbounded while loop in which some kind of input is read. If the input is there, it is processed and the loop is continued; otherwise the loop is broken.

This can be expressed more cleanly with the walrus operator:

  while data := conn.recv(blocksize):
     ...

Some of this code goes back to the days of Python 1. I assume that the original authors would have used the walrus idiom if it had been available, which it wasn't. But now it is.

Rewriting the instances of this pattern shaves off 148 lines from the codebase. Removing the manual break statements makes the logic more straightforward.

This should not change the behavior of anything. I'm assuming that this code is all under test and that any deviations from the existing behavior will be caught. Anything that isn't tested shouldn't be changed (and should be tested).

----------
components: Library (Lib)
messages: 407615
nosy: nickdrozd
priority: normal
pull_requests: 28133
severity: normal
status: open
title: Simplify some while-loops with walrus operator
versions: Python 3.11

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

From report at bugs.python.org  Fri Dec  3 21:20:56 2021
From: report at bugs.python.org (Andrew Lin)
Date: Sat, 04 Dec 2021 02:20:56 +0000
Subject: [New-bugs-announce] [issue45976] Random._randbelow() loses time by
 caching an attribute lookup
Message-ID: <1638584456.65.0.012587553781.issue45976@roundup.psfhosted.org>


New submission from Andrew Lin <onethreeseven at gmail.com>:

This PR obtains a performance improvement in the random module by removing a cached attribute lookup in Random._randbelow_with_getrandbits() that costs time on average.  In the best cases (on my machine) I get 10% improvement for randrange(), 7% for shuffle(), and 11% for sample(), with no change in the worst cases.

To elaborate...  If n is slightly less than a power of 2, _randbelow_with_getrandbits(n) almost always makes just one call to getrandbits(), so caching the attribute lookup never pays for itself.  Even in the worst case, when n is exactly a power of 2, the expected number of calls to getrandbits() is still only 2, and on my machine caching just breaks even.  (A friend ran it on ARM and got even more favorable results.)

I included a similar change to _randbelow_without_getrandbits() on similar grounds, although I didn't benchmark it.

(Brand new here; let me know if I've left anything out!)

----------
components: Library (Lib)
messages: 407625
nosy: onethreeseven
priority: normal
severity: normal
status: open
title: Random._randbelow() loses time by caching an attribute lookup
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Fri Dec  3 22:58:31 2021
From: report at bugs.python.org (Andrei Kulakov)
Date: Sat, 04 Dec 2021 03:58:31 +0000
Subject: [New-bugs-announce] [issue45977] Unexpected effect of
 sys.pycache_prefix = ""
Message-ID: <1638590311.18.0.778355816492.issue45977@roundup.psfhosted.org>


New submission from Andrei Kulakov <andrei.avk at gmail.com>:

Setting sys.pycache_prefix = "", re-creates CWD structure under current directory, e.g. if run from /Users/foo/test, will create /Users/foo/test/Users/foo/test/myfile.pyc . Is that intentional? It seems a little weird. At least it might be good to document it.

----------
components: Interpreter Core
messages: 407632
nosy: andrei.avk
priority: low
severity: normal
status: open
title: Unexpected effect of sys.pycache_prefix = ""
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Sat Dec  4 04:47:09 2021
From: report at bugs.python.org (Dennis Sweeney)
Date: Sat, 04 Dec 2021 09:47:09 +0000
Subject: [New-bugs-announce] [issue45978] deepfreeze opaquely fails on
 Windows when building from Visual Studio
Message-ID: <1638611229.31.0.384123662554.issue45978@roundup.psfhosted.org>


New submission from Dennis Sweeney <sweeney.dennis650 at gmail.com>:

I'd love to know if there is something I'm doing wrong, but with recent deepfreeze changes, my Visual Studio 2019 setup has been having trouble build things. It seems PCBuild/build.bat works perfectly and all tests pass and everything, but using the GUI in Visual Studio 2019 to build with the "Local Windows Debugger" green play button leads to a build failure. It gives the following output:

Build started...
1>------ Build started: Project: _freeze_module, Configuration: Debug x64 ------
1>_freeze_module.vcxproj -> C:\Users\sween\Source\Repos\temp\cpython\PCbuild\amd64\_freeze_module_d.exe
1>C:\Users\sween\Source\Repos\temp\cpython\PCbuild\_freeze_module.vcxproj(413,5): error MSB3073: The command " "C:\Users\sween\Source\Repos\temp\cpython\Tools\scripts\deepfreeze.py" "C:\Users\sween\Source\Repos\temp\cpython\Python\frozen_modules\importlib._bootstrap.h" "-m" "importlib._bootstrap" -o "C:\Users\sween\Source\Repos\temp\cpython\PCbuild\obj\311amd64_Debug\_freeze_module\importlib._bootstrap.g.h"" exited with code 103.
1>Done building project "_freeze_module.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 3 up-to-date, 0 skipped ==========

I wonder if it has something to do with how .py files are set to open? (shouldn't that be made not to matter?)

Attached are my more detailed steps to reproduce the failure.

----------
components: Build, Windows
files: reproducer.txt
messages: 407648
nosy: Dennis Sweeney, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: deepfreeze opaquely fails on Windows when building from Visual Studio
type: compile error
versions: Python 3.11
Added file: https://bugs.python.org/file50474/reproducer.txt

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

From report at bugs.python.org  Sat Dec  4 06:38:47 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 04 Dec 2021 11:38:47 +0000
Subject: [New-bugs-announce] [issue45979] Fix Tkinter tests with old Tk
Message-ID: <1638617927.57.0.610724634525.issue45979@roundup.psfhosted.org>


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

Some recently added tests are not compatible with old Tk versions. I have build all 8.5 and 8.6 versions and build and test Tkinter against them. The proposed PR makes tests passes on Tk versions 8.5.4 to 8.5.19 and 8.6.0 to 8.6.12. There are some issues with running the pure Tk shell for versions < 8.5.4 so I skipped them.

----------
components: Tests, Tkinter
messages: 407661
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Fix Tkinter tests with old Tk
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Sat Dec  4 08:12:15 2021
From: report at bugs.python.org (chen-y0y0)
Date: Sat, 04 Dec 2021 13:12:15 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue45980=5D_Why_there_isn=27t?=
 =?utf-8?b?IGEg4oCcUHl0aG9uIDIuMuKAnSBmb3IgUHlQSSdzIGNsYXNzaWZpZXJzPw==?=
Message-ID: <1638623535.66.0.141979014031.issue45980@roundup.psfhosted.org>


New submission from chen-y0y0 <cyy144881 at icloud.com>:

The output:
Upload failed (400): Invalid value for classifiers. Error: Classifier ' Programming Language :: Python :: 2.2' is not a valid classifier.
error: Upload failed (400): Invalid value for classifiers. Error: Classifier ' Programming Language :: Python :: 2.2' is not a valid classifier.
So, why is there no Python 2.2? Is it because it is outdated or because it is discriminated against?

----------
components: Distutils
messages: 407663
nosy: dstufft, eric.araujo, prasechen
priority: normal
severity: normal
status: open
title: Why there isn't a ?Python 2.2? for PyPI's classifiers?
type: performance
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Dec  4 08:39:26 2021
From: report at bugs.python.org (Devourer Station)
Date: Sat, 04 Dec 2021 13:39:26 +0000
Subject: [New-bugs-announce] [issue45981] Get raw file name in bytes from
 ZipFile
Message-ID: <1638625166.93.0.299659631229.issue45981@roundup.psfhosted.org>


New submission from Devourer Station <accelerator0099 at gmail.com>:

It's quite annoying that ZipFile corrupts the filename by simply replacing '\\' with '/', not providing the raw file name in bytes to us.

----------
components: Library (Lib)
messages: 407665
nosy: accelerator0099
priority: normal
severity: normal
status: open
title: Get raw file name in bytes from ZipFile
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Sat Dec  4 09:55:58 2021
From: report at bugs.python.org (UnknownLITE)
Date: Sat, 04 Dec 2021 14:55:58 +0000
Subject: [New-bugs-announce] [issue45982] Bug in Error messages
Message-ID: <1638629758.22.0.232820967453.issue45982@roundup.psfhosted.org>


New submission from UnknownLITE <unknownlite20 at gmail.com>:

A dot is missing between `now()` and `strftime` but it is suggesting that most probably a comma is missing.

----------
components: Interpreter Core
files: Screenshot 2021-12-04 202054.png
messages: 407670
nosy: UnknownLITE
priority: normal
severity: normal
status: open
title: Bug in Error messages
type: enhancement
versions: Python 3.10
Added file: https://bugs.python.org/file50475/Screenshot 2021-12-04 202054.png

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

From report at bugs.python.org  Sat Dec  4 11:32:04 2021
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 04 Dec 2021 16:32:04 +0000
Subject: [New-bugs-announce] [issue45983] PyType_Spec.name must remain valid
 after PyType_FromSpec
Message-ID: <1638635524.2.0.650786330944.issue45983@roundup.psfhosted.org>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

The documentation for PyType_Spec and the related functions is not clear about the required lifetime of fields of PyType_Spec. 

In particular, PyType_Spec.name must remain valid for the entire lifetime of types created with PyType_FromSpec*.  The documentation doesn't mention this.

I ran into this with code that calculates the name as needed an cleans up the memory used for the type spec after creating the type. The type appears to work fine when looking at it in Python scripts, but the tp_name slot is wrong.

----------
assignee: docs at python
components: Documentation
messages: 407676
nosy: docs at python, ronaldoussoren
priority: normal
severity: normal
status: open
title: PyType_Spec.name must remain valid after PyType_FromSpec
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Sat Dec  4 17:08:32 2021
From: report at bugs.python.org (theeshallnotknowethme)
Date: Sat, 04 Dec 2021 22:08:32 +0000
Subject: [New-bugs-announce] [issue45984] Error messages for invalid string
 prefixes and potential attribute accesses
Message-ID: <1638655712.59.0.26828555414.issue45984@roundup.psfhosted.org>


New submission from theeshallnotknowethme <nohackingofkrowten at gmail.com>:

In the current version of CPython, this code:

if datetime.now()strftime(...) != "19:50:00": return

produces this error:

  File "<stdin>", line 4
    if datetime.now()strftime(...) != "19:50:00": return
                     ^^^^^^^^
SyntaxError: invalid syntax

This is a potential attribute access, and this bug report proposes it would produce this error instead:

  File "<stdin>", line 4
    if datetime.now()strftime(...) != "19:50:00": return
       ^^^^^^^^^^^^^^^^^^^^^^
SyntaxError: invalid syntax. Perhaps you forgot a dot?

Also, for string prefixes, this is the current error:

>>> kf'dsdsfddsf'
  File "<stdin>", line 1
    kf'dsdsfddsf'
      ^^^^^^^^^^^
SyntaxError: invalid syntax

This bug report proposes this error instead:

>>> kf'dsdsfddsf'
  File "<stdin>", line 1
    kf'dsdsfddsf'
    ^^
SyntaxError: invalid string prefix 'kf'

----------
components: Parser
messages: 407687
nosy: February291948, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Error messages for invalid string prefixes and potential attribute accesses
versions: Python 3.11

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

From report at bugs.python.org  Sun Dec  5 06:02:26 2021
From: report at bugs.python.org (Ofer Koren)
Date: Sun, 05 Dec 2021 11:02:26 +0000
Subject: [New-bugs-announce] [issue45985] AttributeError from @property
 inadvertantly flows into __getattr__
Message-ID: <1638702146.56.0.573091484317.issue45985@roundup.psfhosted.org>


New submission from Ofer Koren <koreno at gmail.com>:

There's For quite a long time I've been seeing this bug:

>>> class A():

...     @property
...     def foo(self):
...         return self.bar  # <---- this is where it all starts ('bar' isn't found)
... 
...     def __getattr__(self, attr):
...         raise AttributeError(attr)  # <--- let's pretend our getattr couldn't find the attr


>>> A().foo


Traceback (most recent call last):
  File "t.py", line 13, in <module>
    A().foo
  File "t.py", line 10, in __getattr__
    raise AttributeError(attr)
AttributeError: foo


So an AttributeError spawned by `self.bar` caused us to "fallback" on __getattr__ with attr='foo', leading the naive code there to produce a very confusing error message.


My workaround was to use a @safe_property decorator, one that catches AttributeError exceptions and converts them to RuntimeErrors instead, so that they don't flow into the unsuspecting __getattr__.
I believe python should adopt this behavior into the built-in property decorator, perhaps with a more appropriate exception type.

----------
messages: 407701
nosy: koreno
priority: normal
severity: normal
status: open
title: AttributeError from @property inadvertantly flows into __getattr__
type: behavior
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Dec  5 07:06:49 2021
From: report at bugs.python.org (Athanasius)
Date: Sun, 05 Dec 2021 12:06:49 +0000
Subject: [New-bugs-announce] [issue45986] 3.10.0 ships with older tcl/tk
 DLLs than 3.9.9 causing Windows Installer problems
Message-ID: <1638706009.9.0.557448740254.issue45986@roundup.psfhosted.org>


New submission from Athanasius <github at miggy.org>:

Python 3.10.0 ships with version 8.6.2.10 of both tcl86t.dll and tk86t.dll.

Python 3.9.9, released after 3.10.0, ships with the later version 8.6.2.12 of both files.

Releasing a project using py2exe and WiX to build a windows MSI installer file means that upgrading Python we use from 3.9.9 to 3.10.0 then refuses to install the files tcl86t.dll and tk86t.dll because their versions are older than the already installed files (but for some reason it *does* remove those older versions).

For the user this then means the application crashes on startup when import of _tkinter.pyd fails due to the missing DLLs.  There are two workarounds of: 1) Do a subsequent repair install of the MSI, 2) Manually uninstall the application before installing our version based on Python 3.10.  Neither of these are attractive given the often non-technical backgrounds of our users.

How soon is a 3.10.1 expected that will address this ?  In the meantime I'm either going to have to special-case things and pull in the Python 3.9.9 versions of the files, or just not upgrade the project to Python 3.10.

----------
components: Tkinter
messages: 407703
nosy: Athanasius
priority: normal
severity: normal
status: open
title: 3.10.0 ships with older tcl/tk DLLs than 3.9.9 causing Windows Installer problems
versions: Python 3.10

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

From report at bugs.python.org  Sun Dec  5 09:25:09 2021
From: report at bugs.python.org (Toshihiro Kamiya)
Date: Sun, 05 Dec 2021 14:25:09 +0000
Subject: [New-bugs-announce] [issue45987] os.chdir in unittest's test case
 causes RecursionError on Windows
Message-ID: <1638714309.05.0.538480655841.issue45987@roundup.psfhosted.org>


New submission from Toshihiro Kamiya <kamiya at mbj.nifty.com>:

When I was writing unit tests, I noticed that os.chdir in the unittest test case failed with RecursionError.

It seems to work fine on Ubuntu 20.04, but fails on Windows 10 (might fail on macOS).

The attached file is a minimal code to reproduce this.

When I run it, I got an error message as follows

```
PS C:\Users\toshihiro\tmp> python .\test_chdir_fails.py
Traceback (most recent call last):
  File "C:\Users\toshihiro\tmp\test_chdir_fails.py", line 11, in <module>
    unittest.main()
  File "C:\Users\toshihiro\AppData\Local\Programs\Python\Python39\lib\unittest\main.py", line 101, in __init__
    self.runTests()
(snip)
  File "C:\Users\toshihiro\AppData\Local\Programs\Python\Python39\lib\traceback.py", line 493, in __init__
    context = TracebackException(
  [Previous line repeated 487 more times]
RecursionError: maximum recursion depth exceeded
PS C:\Users\toshihiro\tmp>
```

The version of python was:
Python 3.9.5 (tags/v3.9.5:0a7dcbd, May  3 2021, 17:27:52) [MSC v.1928 64 bit (AMD64)] on win32

Regards,

----------
components: Library (Lib)
files: test_chdir_fails.py
messages: 407711
nosy: tos-kamiya
priority: normal
severity: normal
status: open
title: os.chdir in unittest's test case causes RecursionError on Windows
type: crash
versions: Python 3.9
Added file: https://bugs.python.org/file50476/test_chdir_fails.py

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

From report at bugs.python.org  Sun Dec  5 11:07:11 2021
From: report at bugs.python.org (Filippo Vicentini)
Date: Sun, 05 Dec 2021 16:07:11 +0000
Subject: [New-bugs-announce] [issue45988] inspect.signature fails on a
 @staticmethod
Message-ID: <1638720431.62.0.74657433322.issue45988@roundup.psfhosted.org>


New submission from Filippo Vicentini <filippovicentini at gmail.com>:

Attempting to inspect the signature of a method marked as @staticmethod during class construction fails.
This happens in 3.8, 3.9.

A MWE is given here:
```python
from typing import signature

def decorator(fun):
	print(signature(fun))
	return fun

class Test2:
	@decorator
	@staticmethod
	def test(arg):
		return arg
```
which fails with error
```python
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 4, in Test
  File "<stdin>", line 2, in decorator
  File "/Users/filippovicentini/.pyenv/versions/3.9.7/lib/python3.9/inspect.py", line 3111, in signature
    return Signature.from_callable(obj, follow_wrapped=follow_wrapped)
  File "/Users/filippovicentini/.pyenv/versions/3.9.7/lib/python3.9/inspect.py", line 2860, in from_callable
    return _signature_from_callable(obj, sigcls=cls,
  File "/Users/filippovicentini/.pyenv/versions/3.9.7/lib/python3.9/inspect.py", line 2259, in _signature_from_callable
    raise TypeError('{!r} is not a callable object'.format(obj))
TypeError: <staticmethod object at 0x108865250> is not a callable object
```

----------
components: Library (Lib)
messages: 407715
nosy: PhilipVinc
priority: normal
severity: normal
status: open
title: inspect.signature fails on a @staticmethod
versions: Python 3.8

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

From report at bugs.python.org  Sun Dec  5 12:37:28 2021
From: report at bugs.python.org (Masoud Azizi)
Date: Sun, 05 Dec 2021 17:37:28 +0000
Subject: [New-bugs-announce] [issue45989] Getting key of max value of dict
 really dose not sense
Message-ID: <1638725848.56.0.191951522901.issue45989@roundup.psfhosted.org>


New submission from Masoud Azizi <mablue92 at gmail.com>:

Maximum_signal_key=max(collective_signals,key=collective_signals.get)
This code is really hard to learn and remember.
Please change it to something that more sense.

----------
messages: 407719
nosy: mablue
priority: normal
severity: normal
status: open
title: Getting key of max value of dict really dose not sense
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Dec  5 12:49:09 2021
From: report at bugs.python.org (Ram Rachum)
Date: Sun, 05 Dec 2021 17:49:09 +0000
Subject: [New-bugs-announce] [issue45990] Exception notes need more
 documentation
Message-ID: <1638726549.23.0.192280798069.issue45990@roundup.psfhosted.org>


New submission from Ram Rachum <ram at rachum.com>:

The new __note__ feature for exception could be useful, but the documentation (and the section in "What's new") aren't good enough:

"__note__: A mutable field which is :const:`None` by default and can be set to a string. If it is not :const:`None`, it is included in the traceback. This field can be used to enrich exceptions after they have been caught."

This is more of a definition than an explanation. If this is solving a problem, there should be an explanation that starts from the problem being solved, hopefully with 2-3 examples where this is useful. If people start using this feature without some guidance, they might put things in the note that should have been in the message.

----------
assignee: docs at python
components: Documentation
messages: 407722
nosy: cool-RR, docs at python, iritkatriel
priority: normal
severity: normal
status: open
title: Exception notes need more documentation
versions: Python 3.11

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

From report at bugs.python.org  Sun Dec  5 13:56:47 2021
From: report at bugs.python.org (Kevin Hock)
Date: Sun, 05 Dec 2021 18:56:47 +0000
Subject: [New-bugs-announce] [issue45991] Improve ambiguous docstrings in
 pkgutil
Message-ID: <1638730607.25.0.754715317111.issue45991@roundup.psfhosted.org>


New submission from Kevin Hock <khock at pinterest.com>:

# Issue

If you search for "list of paths" in https://github.com/KevinHock/cpython/blob/main/Lib/pkgutil.py

A lot of people mistake this as `PosixPath`. You can see an example here: https://github.com/duo-labs/parliament/pull/207 that references other OSS repositories.

# Solution

We can
- Change the wording. e.g. "list of strings of the paths" or some variation of that.

and perhaps additionally

- Throw a ValueError similar to: https://github.com/python/cpython/blob/628abe4463ed40cd54ca952a2b4cc2d6e74073f7/Lib/pkgutil.py#L122

----------
assignee: docs at python
components: Documentation
messages: 407727
nosy: docs at python, khock
priority: normal
severity: normal
status: open
title: Improve ambiguous docstrings in pkgutil
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Dec  6 02:00:11 2021
From: report at bugs.python.org (Tzu-ping Chung)
Date: Mon, 06 Dec 2021 07:00:11 +0000
Subject: [New-bugs-announce] [issue45992] distutils paths are scattered
 between PythonXY and PythonXY-32 on WoW64
Message-ID: <1638774011.75.0.410629931242.issue45992@roundup.psfhosted.org>


New submission from Tzu-ping Chung <uranusjr at gmail.com>:

Should be reproducible with a 32-bit Python 3.10 running on 64-bit Windows.

    $ py -3.10-32 -q
    >>> from distutils.command.install import install
    <stdin>:1: 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.dist import Distribution
    >>> c = install(Distribution())
    >>> c.user = 1
    >>> c.finalize_options()
    >>> for k in ('purelib', 'platlib', 'headers', 'scripts', 'data'):
    ...  print(f'{k}\t{getattr(c, "install_" + k)}')
    ...
    purelib C:\Users\uranusjr\AppData\Roaming\Python\Python310-32\site-packages
    platlib C:\Users\uranusjr\AppData\Roaming\Python\Python310-32\site-packages
    headers C:\Users\uranusjr\AppData\Roaming\Python\Python310\Include\UNKNOWN
    scripts C:\Users\uranusjr\AppData\Roaming\Python\Python310\Scripts
    data    C:\Users\uranusjr\AppData\Roaming\Python

This is different from sysconfig, where all files are placed in the *-32 suffix:

    >>> import sysconfig
    >>> for k in ('purelib', 'platlib', 'include', 'scripts', 'data'):
    ...  print(f'{k}\t{paths[k]}')
    ...
    purelib C:\Users\uranusjr\AppData\Roaming\Python\Python310-32\site-packages
    platlib C:\Users\uranusjr\AppData\Roaming\Python\Python310-32\site-packages
    include C:\Users\uranusjr\AppData\Roaming\Python\Python310-32\Include
    scripts C:\Users\uranusjr\AppData\Roaming\Python\Python310-32\Scripts
    data    C:\Users\uranusjr\AppData\Roaming\Python

And also different from Python 3.9 (and prior), which does not use the *-32 prefix:

    $ py -3.9-32 -q
    >>> from distutils.command.install import install
    >>> from distutils.dist import Distribution
    >>> c = install(Distribution())
    >>> c.user = 1
    >>> c.finalize_options()
    >>> for k in ('purelib', 'platlib', 'headers', 'scripts', 'data'):
    ...  print(f'{k}\t{getattr(c, "install_" + k)}')
    ...
    purelib C:\Users\uranusjr\AppData\Roaming\Python\Python39\site-packages
    platlib C:\Users\uranusjr\AppData\Roaming\Python\Python39\site-packages
    headers C:\Users\uranusjr\AppData\Roaming\Python\Python39\Include\UNKNOWN
    scripts C:\Users\uranusjr\AppData\Roaming\Python\Python39\Scripts
    data    C:\Users\uranusjr\AppData\Roaming\Python

It?s of course not a problem to change the prefix and add the *-32 suffix on 3.10 (since the only thing that?s important is to have a consistent prefix for a given version), but the change should likely need to be applied consistently. I think we should fix distutils to match sysconfig?

----------
components: Distutils, Windows
messages: 407769
nosy: dstufft, eric.araujo, paul.moore, steve.dower, tim.golden, uranusjr, zach.ware
priority: normal
severity: normal
status: open
title: distutils paths are scattered between PythonXY and PythonXY-32 on WoW64
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Mon Dec  6 03:00:18 2021
From: report at bugs.python.org (Nikita Sobolev)
Date: Mon, 06 Dec 2021 08:00:18 +0000
Subject: [New-bugs-announce] [issue45993] Main branch of CPython does not
 build anymore on macOS
Message-ID: <1638777618.8.0.921239379718.issue45993@roundup.psfhosted.org>


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

New version of `main` branch does not build for me anymore.

Command: `make -j`
System information: 
- macOS 10.14.6
- Apple clang version 11.0.0 (clang-1100.0.33.16)

I am also attaching resulting Makefile.

Output:

```
? make -j
gcc -L/usr/local/opt/openssl/lib -L/usr/local/opt/openssl/lib   -o Programs/_freeze_module Programs/_freeze_module.o Modules/getpath_noop.o Modules/getbuildinfo.o Parser/token.o  Parser/pegen.o Parser/pegen_errors.o Parser/action_helpers.o Parser/parser.o Parser/string_parser.o Parser/peg_api.o Parser/myreadline.o Parser/tokenizer.o Objects/abstract.o Objects/accu.o Objects/boolobject.o Objects/bytes_methods.o Objects/bytearrayobject.o Objects/bytesobject.o Objects/call.o Objects/capsule.o Objects/cellobject.o Objects/classobject.o Objects/codeobject.o Objects/complexobject.o Objects/descrobject.o Objects/enumobject.o Objects/exceptions.o Objects/genericaliasobject.o Objects/genobject.o Objects/fileobject.o Objects/floatobject.o Objects/frameobject.o Objects/funcobject.o Objects/interpreteridobject.o Objects/iterobject.o Objects/listobject.o Objects/longobject.o Objects/dictobject.o Objects/odictobject.o Objects/memoryobject.o Objects/methodobject.o Objects/moduleobject.o Objects/namespaceobject.o Objects/object.o Objects/obmalloc.o Objects/picklebufobject.o Objects/rangeobject.o Objects/setobject.o Objects/sliceobject.o Objects/structseq.o Objects/tupleobject.o Objects/typeobject.o Objects/unicodeobject.o Objects/unicodectype.o Objects/unionobject.o Objects/weakrefobject.o Python/_warnings.o Python/Python-ast.o Python/Python-tokenize.o Python/asdl.o Python/ast.o Python/ast_opt.o Python/ast_unparse.o Python/bltinmodule.o Python/ceval.o Python/codecs.o Python/compile.o Python/context.o Python/dynamic_annotations.o Python/errors.o Python/frame.o Python/frozenmain.o Python/future.o Python/getargs.o Python/getcompiler.o Python/getcopyright.o Python/getplatform.o Python/getversion.o Python/hamt.o Python/hashtable.o Python/import.o Python/importdl.o Python/initconfig.o Python/marshal.o Python/modsupport.o Python/mysnprintf.o Python/mystrtoul.o Python/pathconfig.o Python/preconfig.o Python/pyarena.o Python/pyctype.o Python/pyfpe.o Python/pyhash.o Python/pylifecycle.o Python/pymath.o Python/pystate.o Python/pythonrun.o Python/pytime.o Python/bootstrap_hash.o Python/specialize.o Python/structmember.o Python/symtable.o Python/sysmodule.o Python/thread.o Python/traceback.o Python/getopt.o Python/pystrcmp.o Python/pystrtod.o Python/pystrhex.o Python/dtoa.o Python/formatter_unicode.o Python/fileutils.o Python/suggestions.o Python/dynload_shlib.o    Modules/config.o Modules/main.o Modules/gcmodule.o Modules/xxsubtype.o -lintl -ldl  -framework CoreFoundation    
Undefined symbols for architecture x86_64:
  "_PyErr_CheckSignals", referenced from:
      _my_fgets in myreadline.o
      _long_to_decimal_string_internal in longobject.o
      _x_mul in longobject.o
      _x_divrem in longobject.o
      _PyObject_Print in object.o
      _PyObject_Str in object.o
      _PyObject_Repr in object.o
      ...
  "_PyOS_FSPath", referenced from:
      _PyUnicode_FSConverter in unicodeobject.o
      _PyUnicode_FSDecoder in unicodeobject.o
  "__PyAtExit_Call", referenced from:
      _Py_FinalizeEx in pylifecycle.o
      _Py_EndInterpreter in pylifecycle.o
  "__PyAtExit_Fini", referenced from:
      _interpreter_clear in pystate.o
  "__PyAtExit_Init", referenced from:
      _pycore_interp_init in pylifecycle.o
  "__PyErr_CheckSignalsTstate", referenced from:
      _handle_signals in ceval.o
  "__PyFaulthandler_Fini", referenced from:
      _Py_FinalizeEx in pylifecycle.o
      _fatal_error in pylifecycle.o
  "__PyFaulthandler_Init", referenced from:
      _init_interp_main in pylifecycle.o
  "__PyMem_DumpTraceback", referenced from:
      __PyObject_AssertFailed in object.o
      __PyObject_DebugDumpAddress in obmalloc.o
  "__PyOS_InterruptOccurred", referenced from:
      _my_fgets in myreadline.o
  "__PySignal_Fini", referenced from:
      _Py_FinalizeEx in pylifecycle.o
  "__PySignal_Init", referenced from:
      _init_interp_main in pylifecycle.o
  "__PyTraceMalloc_Fini", referenced from:
      _Py_FinalizeEx in pylifecycle.o
  "__PyTraceMalloc_Init", referenced from:
      _init_interp_main in pylifecycle.o
  "__PyTraceMalloc_NewReference", referenced from:
      __Py_NewReference in object.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [Programs/_freeze_module] Error 1
```

----------
components: Build
files: Makefile
messages: 407773
nosy: sobolevn
priority: normal
severity: normal
status: open
title: Main branch of CPython does not build anymore on macOS
type: compile error
versions: Python 3.11
Added file: https://bugs.python.org/file50479/Makefile

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

From report at bugs.python.org  Mon Dec  6 05:44:20 2021
From: report at bugs.python.org (Taiga Katarao)
Date: Mon, 06 Dec 2021 10:44:20 +0000
Subject: [New-bugs-announce] [issue45994] Add simple usage to email module
Message-ID: <1638787460.4.0.146511552632.issue45994@roundup.psfhosted.org>


Change by Taiga Katarao <taiga4562 at gmail.com>:


----------
assignee: docs at python
components: Documentation
nosy: docs at python, tarao1006
priority: normal
severity: normal
status: open
title: Add simple usage to email module
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Mon Dec  6 07:03:46 2021
From: report at bugs.python.org (John Belmonte)
Date: Mon, 06 Dec 2021 12:03:46 +0000
Subject: [New-bugs-announce] [issue45995] string formatting: normalize
 negative zero
Message-ID: <1638792226.95.0.292604366656.issue45995@roundup.psfhosted.org>


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

proposal: add a string formatting option to normalize negative 0 values to 0

use case:  rounded display of a float that is nominally 0, where the distraction of a flashing minus sign from minute changes around 0 is unwanted

example:
>>> '%~5.1f' % -.00001
'  0.0'

format spec before:
  format_spec     ::=  [[fill]align][sign][#][0][width][grouping_option][.precision][type]
after:
  format_spec     ::=  [[fill]align][sign][~][#][0][width][grouping_option][.precision][type]
  where '~' is only allowed for number types

implementation: if '~' is present in the spec, add 0 to the value after applying precision

----------
components: Library (Lib)
messages: 407792
nosy: John Belmonte
priority: normal
severity: normal
status: open
title: string formatting: normalize negative zero
type: enhancement

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

From report at bugs.python.org  Mon Dec  6 08:24:19 2021
From: report at bugs.python.org (Dima Tisnek)
Date: Mon, 06 Dec 2021 13:24:19 +0000
Subject: [New-bugs-announce] [issue45996] Worse error from
 asynccontextmanager in Python 3.10
Message-ID: <1638797059.87.0.372415243632.issue45996@roundup.psfhosted.org>


New submission from Dima Tisnek <dimaqq at gmail.com>:

Consider this illegal code:



import logging
from asyncio import sleep, gather, run
from contextlib import asynccontextmanager

@asynccontextmanager
async def foo():
    await sleep(1)
    yield


async def test():
    f = foo()
    await gather(f.__aenter__(), f.__aenter__())

run(test())



If it's ran with Python 3.9, user gets a sensible error:


  File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/contextlib.py", line 175, in __aenter__
    return await self.gen.__anext__()
RuntimeError: anext(): asynchronous generator is already running



However, if it's ran with Python 3.10, user gets a cryptic error:


  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/contextlib.py", line 197, in __aenter__
    del self.args, self.kwds, self.func
AttributeError: args



Which makes it harder to pinpoint what's wrong when the stack is complex.
I've hit this with fastapi/starlette/mangum combo and a custom middleware.

----------
components: asyncio
messages: 407799
nosy: Dima.Tisnek, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Worse error from asynccontextmanager in Python 3.10
type: behavior
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Mon Dec  6 09:04:23 2021
From: report at bugs.python.org (Yevhenii Hyzyla)
Date: Mon, 06 Dec 2021 14:04:23 +0000
Subject: [New-bugs-announce] [issue45997] asyncio.Semaphore waiters deqeueu
 doesn't work
Message-ID: <1638799463.93.0.445533986487.issue45997@roundup.psfhosted.org>


New submission from Yevhenii Hyzyla <hyzyla at gmail.com>:

Class `asyncio.Semaphore` has dequeue in implementation for waiters of semaphore and seems like the intention of this dequeue is to maintain FIFO queue of waiters. But it doesn't work, coroutine that releases semaphore can acquire semaphore again. Below is reproducible example:

```python
import asyncio


async def process(idx: int, semaphore: asyncio.Semaphore) -> None:
    while True:
        async with semaphore:
            print(f'ACQUIRE {idx}')
            await asyncio.sleep(1)


async def main() -> None:
    semaphore = asyncio.Semaphore(5)
    await asyncio.gather(*[process(idx, semaphore) for idx in range(20)])

asyncio.run(main())
```

In console:
```
/home/y.hyzyla/Work/asynciosemaphorebug/venv/bin/python /home/y.hyzyla/Work/asynciosemaphorebug/main.py
ACQUIRE 0
ACQUIRE 1
ACQUIRE 2
ACQUIRE 3
ACQUIRE 4
ACQUIRE 0
ACQUIRE 1
ACQUIRE 2
ACQUIRE 3
ACQUIRE 4
ACQUIRE 0
ACQUIRE 1
ACQUIRE 2
ACQUIRE 3
ACQUIRE 4
....
```

Ugly fix, is to add asyncio.sleep right before semaphore.
```python
    while True:
        await asyncio.sleep(0)
        async with semaphore:
            ...
```

Also, I found a comment on Stack Overflow about race condition in Semaphore implementation, but I don't know about the quality of that comment:

https://stackoverflow.com/questions/55951233/does-pythons-asyncio-lock-acquire-maintain-order#comment112978366_55951304

----------
components: asyncio
messages: 407809
nosy: asvetlov, hyzyla, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.Semaphore waiters deqeueu doesn't work
versions: Python 3.8

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

From report at bugs.python.org  Mon Dec  6 10:00:33 2021
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 06 Dec 2021 15:00:33 +0000
Subject: [New-bugs-announce] [issue45998] Document best practice for
 including and linking python framework
Message-ID: <1638802833.35.0.414122287903.issue45998@roundup.psfhosted.org>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

There are two ways to develop against a Python.framework on MacOS:

1. Use the regular Unix pattern with "#include "Python.h", using compiler flags to select the right headers and libraries.

2. Using the native framework pattern with "#import <Python/Python.h>" and "-framework Python"

Both works, but the latter has the disadvantage of loosing control over which version of Python is used when multiple versions are installed.  The version is selected by the "Current" link in the framework, which is overwritten to point to whatever version was last installed or updated.

IMHO we should document this pitfall in the C API documentation.

----------
assignee: docs at python
components: Documentation, macOS
messages: 407821
nosy: docs at python, ned.deily, ronaldoussoren
priority: normal
severity: normal
stage: needs patch
status: open
title: Document best practice for including and linking python framework
type: enhancement
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Mon Dec  6 10:55:03 2021
From: report at bugs.python.org (Douglas Wright)
Date: Mon, 06 Dec 2021 15:55:03 +0000
Subject: [New-bugs-announce] [issue45999] Links to packaging broken
Message-ID: <1638806103.81.0.408526409699.issue45999@roundup.psfhosted.org>


New submission from Douglas Wright <douglas277 at gmail.com>:

Links in this section from the docs from 3.9 and newer are currently broken.

https://docs.python.org/3.9/distributing/index.html#reading-the-python-packaging-user-guide

They are currently leading to a "page not found" error.

----------
assignee: docs at python
components: Documentation
messages: 407824
nosy: docs at python, douglas277
priority: normal
severity: normal
status: open
title: Links to packaging broken
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Mon Dec  6 11:11:52 2021
From: report at bugs.python.org (Thomas Klausner)
Date: Mon, 06 Dec 2021 16:11:52 +0000
Subject: [New-bugs-announce] [issue46000] NetBSD curses compatibility
Message-ID: <1638807112.42.0.171377770564.issue46000@roundup.psfhosted.org>


New submission from Thomas Klausner <tk at giga.or.at>:

The code in Modules/_cursesmodule.c has an assumption on ncurses.
The attached simple patch fixes this and works with both NetBSD curses and ncurses.

----------
components: Extension Modules
files: patch-Modules___cursesmodule.c
messages: 407825
nosy: wiz
priority: normal
severity: normal
status: open
title: NetBSD curses compatibility
type: behavior
versions: Python 3.10
Added file: https://bugs.python.org/file50480/patch-Modules___cursesmodule.c

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

From report at bugs.python.org  Mon Dec  6 11:45:46 2021
From: report at bugs.python.org (James Gerity)
Date: Mon, 06 Dec 2021 16:45:46 +0000
Subject: [New-bugs-announce] [issue46001] JSON module documentation mentions
 OverflowError for case that raises RecursionError
Message-ID: <1638809146.18.0.0478648187504.issue46001@roundup.psfhosted.org>


New submission from James Gerity <snoop.jedi at gmail.com>:

The docstrings for `json.JSONEncoder, json.dump(), json.dumps()` all refer to `OverflowError` when describing the behavior of the `check_circular` parameter, but the module's test of this parameter catches a `RecursionError` and the documentation does make reference to recursion.

Since the fix for bpo-43225 (7b78d43) the string-escaping machinery in `_json.c` is capable of raising OverflowError, but the reference in the documentation predates this addition by quite a long time.

----------
assignee: docs at python
components: Documentation
messages: 407837
nosy: SnoopJeDi, docs at python
priority: normal
severity: normal
status: open
title: JSON module documentation mentions OverflowError for case that raises RecursionError
versions: Python 3.11

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

From report at bugs.python.org  Mon Dec  6 11:56:27 2021
From: report at bugs.python.org (Tze Chian Kam)
Date: Mon, 06 Dec 2021 16:56:27 +0000
Subject: [New-bugs-announce] [issue46002] py Launcher for Windows with MSYS2
Message-ID: <1638809787.4.0.667501971988.issue46002@roundup.psfhosted.org>


New submission from Tze Chian Kam <tze.chian.kam at gmail.com>:

Using "pyenv" for python installations. "py" launcher detects all installed python versions from "pyenv". When using the shebang feature, if the following shebang is specified, "#!/usr/bin/env python -V", it will detect python version of "3.9.9" from MSYS2 (where the latest version is "3.9.9"). But MSYS2 python is not in registered in registry so it should not be detecting it.

----------
components: Windows
messages: 407840
nosy: Zernoxi, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: py Launcher for Windows with MSYS2
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Mon Dec  6 16:20:05 2021
From: report at bugs.python.org (nobody)
Date: Mon, 06 Dec 2021 21:20:05 +0000
Subject: [New-bugs-announce] [issue46003] os.replace is not cross-platform:
 at least improve documentation
Message-ID: <1638825605.8.0.77974659196.issue46003@roundup.psfhosted.org>


New submission from nobody <peterpm at xs4all.nl>:

When using threads, os.replace gives no errors on Linux. On Windows however you get PermissionErrors like: '[WinError 5] Access is denied' for os.replace and '[Errno 13] Permission denied' when reading the os.replace file.
The only way I could get this to work was to add retries with delay.
At least the documentation should be improved.

----------
messages: 407864
nosy: hancos
priority: normal
severity: normal
status: open
title: os.replace is not cross-platform: at least improve documentation
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Tue Dec  7 01:11:16 2021
From: report at bugs.python.org (Andre Roberge)
Date: Tue, 07 Dec 2021 06:11:16 +0000
Subject: [New-bugs-announce] [issue46004] Incorrect bad token identified in
 3.10.1
Message-ID: <1638857476.78.0.83967741356.issue46004@roundup.psfhosted.org>


New submission from Andre Roberge <andre.roberge at gmail.com>:

In Python 3.10.1, a change occurred compared with 3.10.0 so that an incorrect token is flagged for a SyntaxError.  Also, in 3.11.0a2, the suggestion made about having forgotten a comma is incorrect.


Python 3.10.1
    for x range(4):
                  ^
SyntaxError: invalid syntax

(I no longer have 3.10.0 available but I know from my tests that it was identifying correctly the wrong token.)


Python 3.11.0a2
    for x range(4):
        ^^^^^^^^^^
SyntaxError: invalid syntax. Perhaps you forgot a comma?

Python 3.9.5
    for x range(4):
          ^
SyntaxError: invalid syntax

Python 3.8.10
    for x range(4):
          ^
SyntaxError: invalid syntax

Python 3.7.8
    for x range(4):
              ^
SyntaxError: invalid syntax

Python 3.6.8
    for x range(4):
              ^
SyntaxError: invalid syntax

----------
components: Parser
messages: 407894
nosy: aroberge, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Incorrect bad token identified in 3.10.1
versions: Python 3.10

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

From report at bugs.python.org  Tue Dec  7 03:08:57 2021
From: report at bugs.python.org (Elmir)
Date: Tue, 07 Dec 2021 08:08:57 +0000
Subject: [New-bugs-announce] [issue46005] [doc] replace 'distutils' examples
 with 'setuptools'
Message-ID: <1638864537.57.0.967787312853.issue46005@roundup.psfhosted.org>


New submission from Elmir <elmir.jagudin at maxiv.lu.se>:

As the distutils have been deprecated, the documentation on building C/C++ extension modules should be updated to use more future proof tool.

I guess the section:

'Building C and C++ Extensions with distutils'

should be replaced with:

'Building C and C++ Extensions with setuptools'

Here is link to the section that needs to be updated/replaced:

https://docs.python.org/3/extending/building.html#building-c-and-c-extensions-with-distutils

----------
assignee: docs at python
components: Documentation
messages: 407896
nosy: docs at python, elmjag
priority: normal
severity: normal
status: open
title: [doc] replace 'distutils' examples with 'setuptools'
type: enhancement
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Tue Dec  7 12:12:26 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Dec 2021 17:12:26 +0000
Subject: [New-bugs-announce] [issue46006] [subinterpreter]
 _PyUnicode_EqualToASCIIId() issue with subinterpreters
Message-ID: <1638897146.48.0.478621354755.issue46006@roundup.psfhosted.org>


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

_PyUnicode_EqualToASCIIId() seems to be incompatible with subinterpreter: it makes the assumption that if direct pointer comparison fails and the string is interned, the two strings are not equal.

--

super_init_without_args() of Objects/typeobject.c calls _PyUnicode_EqualToASCIIId(name, &PyId___class__) to test if the Unicode string 'name' is equal to "__class__".

int
_PyUnicode_EqualToASCIIId(PyObject *left, _Py_Identifier *right)
{
    right_uni = _PyUnicode_FromId(right);
    ...
    if (left == right_uni)
        return 1;
    if (PyUnicode_CHECK_INTERNED(left))
        return 0;
    ...
    return unicode_compare_eq(left, right_uni);
}

_PyUnicode_EqualToASCIIId() makes the assumption that left and right are not equal if left and _PyUnicode_FromId(right) pointers are not equal and left is an interned string.

In the reproducer, left object is abc.ABCMeta.__new__.__code__.co_freevars[0].

Depending on how the stdlib abc.py file was loaded (in the main interpreter and in the subinterpreter), __code__.co_freevars[0] may or may not be an interned string.

If __code__.co_freevars[0] is an interned string, _PyUnicode_EqualToASCIIId() fails in a subinterpreter if the direct pointer comparison fails (if left and right_uni pointers are not equal).

--

Reproducer from: https://github.com/ninia/jep/issues/358#issuecomment-988090696

* Build Python 3.10 with "./configure --enable-shared --prefix /opt/py310" and install it.
* Download attached reproducer.c.
* Build the reproducer with: 
  gcc -o reproducer reproducer.c $(/opt/py310/bin/python3.10-config --embed --cflags --ldflags)
* Remove all stdlib .pyc files:
  find /opt/py310 -type d -name __pycache__|xargs rm -rf
* Run the reproducer with:
  LD_LIBRARY_PATH=/opt/py310/lib ./reproducer

Output:
---
Before creating sub interpreter
Traceback (most recent call last):
  File "/opt/py310/lib/python3.10/io.py", line 52, in <module>
  File "/opt/py310/lib/python3.10/abc.py", line 184, in <module>
  File "/opt/py310/lib/python3.10/abc.py", line 106, in __new__
RuntimeError: super(): __class__ cell not found
Fatal Python error: _PyThreadState_Delete: tstate 0x7f9f2001c710 is still current
Python runtime state: initialized

Current thread 0x00007f9f27c99640 (most recent call first):
  <no Python frame>
Abandon (core dumped)
---

py-bt command in gdb:
---
(gdb) py-bt
Traceback (most recent call first):
  File "/opt/py310/lib/python3.10/abc.py", line 106, in __new__
    cls = super().__new__(mcls, name, bases, namespace, **kwargs)
  <built-in method __build_class__ of module object at remote 0x7fffea0b4cc0>
  File "/opt/py310/lib/python3.10/abc.py", line 184, in <module>
    class ABC(metaclass=ABCMeta):
  <built-in method exec of module object at remote 0x7fffea0b4cc0>
  File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 883, in exec_module
  File "<frozen importlib._bootstrap>", line 688, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 1006, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
  File "/opt/py310/lib/python3.10/io.py", line 52, in <module>
    import abc
  <built-in method exec of module object at remote 0x7fffea0b4cc0>
  File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 883, in exec_module
  File "<frozen importlib._bootstrap>", line 688, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 1006, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
  <built-in method __import__ of module object at remote 0x7fffea0b4cc0>
---

----------
components: C API, Subinterpreters
files: reproducer.c
messages: 407950
nosy: corona10, erlendaasland, vstinner
priority: normal
severity: normal
status: open
title: [subinterpreter] _PyUnicode_EqualToASCIIId() issue with subinterpreters
versions: Python 3.10, Python 3.11
Added file: https://bugs.python.org/file50482/reproducer.c

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

From report at bugs.python.org  Tue Dec  7 12:34:25 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Dec 2021 17:34:25 +0000
Subject: [New-bugs-announce] [issue46007] [C API] PyUnicode_CHECK_INTERNED()
 doesn't work in the limited C API
Message-ID: <1638898465.89.0.178243976292.issue46007@roundup.psfhosted.org>


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

The PyUnicode_CHECK_INTERNED() macro uses the PyASCIIObject structure which is *excluded* from the limited C API:

/* Use only if you know it's a string */
#define PyUnicode_CHECK_INTERNED(op) \
    (((PyASCIIObject *)(op))->state.interned)

Using this macro in the limited C API doesn't work.

I propose to remove it from the limited C API.

IMO it's not a good idea to fix the function in the limited C API by converting it to a regular function hiding the implementation details and so working at the ABI level. We should not expose such "implementation detail" (if a string is "interned or not") in the *limited* C API.

----------
components: C API
messages: 407955
nosy: vstinner
priority: normal
severity: normal
status: open
title: [C API] PyUnicode_CHECK_INTERNED() doesn't work in the limited C API
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Tue Dec  7 15:24:26 2021
From: report at bugs.python.org (Eric Snow)
Date: Tue, 07 Dec 2021 20:24:26 +0000
Subject: [New-bugs-announce] [issue46008] Prepare runtime/interp/thread
 state and init for upcoming changes.
Message-ID: <1638908666.73.0.306470014114.issue46008@roundup.psfhosted.org>


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

There are a few things in `_PyRuntimeState`, `PyInterpreterState`, `PyThreadState`, and there initialization (Python/pystate.c & Python/pylifecycle.c) that would benefit from some minor cleanup.  Normally I wouldn't bother (due to the cost of churn), but such cleanup would help with other changes I'm working on.

The cleanup includes:

* move thread related interpreter state to `PyInterpreterState.threads`
* return void from `_PyEval_InitState()`
* separate Py*State initialization from creation
* distinguish between initialized-to-safe-state and ready-to-use
* separate init for global types/objects into phases: object state vs. global objects vs. global types

----------
assignee: eric.snow
components: Interpreter Core
messages: 407963
nosy: eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: Prepare runtime/interp/thread state and init for upcoming changes.
versions: Python 3.11

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

From report at bugs.python.org  Tue Dec  7 16:53:29 2021
From: report at bugs.python.org (Stanislav Syekirin)
Date: Tue, 07 Dec 2021 21:53:29 +0000
Subject: [New-bugs-announce] [issue46009] sending non-None values makes
 generator raise StopIteration on next access
Message-ID: <1638914009.53.0.916939757704.issue46009@roundup.psfhosted.org>


New submission from Stanislav Syekirin <syekirin at gmail.com>:

Tested with Python 3.10.1 on Linux and Python 3.10.0 on Windows.

The following code prints None in 3.9 and raises StopIteration without any additional information in 3.10:

    def f():
        yield
    
    x = f()
    
    try:
        x.send(0)
    except TypeError as e:
        print(e) # can't send non-None value to a just-started generator
    
    print(next(x))

----------
messages: 407975
nosy: Zabolekar
priority: normal
severity: normal
status: open
title: sending non-None values makes generator raise StopIteration on next access
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Tue Dec  7 17:44:55 2021
From: report at bugs.python.org (Francisco Orozco)
Date: Tue, 07 Dec 2021 22:44:55 +0000
Subject: [New-bugs-announce] [issue46010] Cookie cutter templates to allow
 variable fields and data transfer proposal before system merge
Message-ID: <1638917095.16.0.187106370804.issue46010@roundup.psfhosted.org>


New submission from Francisco Orozco <forozco at email.com>:

Not featuring templates to allow variable fields and data record creation when converting projects to new platform projects for purpose to confirm, verify record creation, might be helpful, in addition of only viewing/editing project development and structure.

For purpose of data analysis, future data merging, data financial reservations or data eligibility or feasibility or recalls.

----------
components: Build
messages: 407980
nosy: Francisco
priority: normal
severity: normal
status: open
title: Cookie cutter templates to allow variable fields and data transfer proposal before system merge
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Tue Dec  7 23:32:57 2021
From: report at bugs.python.org (Mark Sapiro)
Date: Wed, 08 Dec 2021 04:32:57 +0000
Subject: [New-bugs-announce] [issue46011] Python 3.10 email returns invalid
 Date: header unchanged.
Message-ID: <1638937977.72.0.569168452456.issue46011@roundup.psfhosted.org>


New submission from Mark Sapiro <mark at msapiro.net>:

Here is an interactive Python session
```
Python 3.10.1 (main, Dec  7 2021, 15:44:39) [GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from email import message_from_bytes, policy
>>> msg_raw = b"""Return-Path: <owner-mailman-users at python.org>
... Delivered-To: mailman-users at dinsdale.python.org
... From: user at example.com
... Message-Id: <msg1>
... Date: Tue, 30 Nov 1999 23:56:33 -3000 (CST)
... To: mailman-users at python.org
... 
... msg1
... """
>>> message = message_from_bytes(msg_raw, policy=policy.default)
>>> message.get('date')
'Tue, 30 Nov 1999 23:56:33 -3000 (CST)'
>>> message.defects
[]
>>> 
```
The same session in Python 3.9 throws ValueError: offset must be a timedelta strictly between -timedelta(hours=24) and timedelta(hours=24), not datetime.timedelta(days=-2, seconds=64800).

At first I thought this was related to https://bugs.python.org/issue30681 but that seems to not be the case as utils.parsedate_to_datetime('Tue, 30 Nov 1999 23:56:33 -3000 (CST)') throws the same exception In Python 3.10.1.

I think getting the Date: header which has an invalid timezone should either throw the exception as before or return None, but not return the invalid date header.

----------
components: email
keywords: 3.10regression
messages: 407997
nosy: barry, msapiro, r.david.murray
priority: normal
severity: normal
status: open
title: Python 3.10 email returns invalid Date: header unchanged.
versions: Python 3.10

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

From report at bugs.python.org  Wed Dec  8 01:52:00 2021
From: report at bugs.python.org (David Shiko)
Date: Wed, 08 Dec 2021 06:52:00 +0000
Subject: [New-bugs-announce] [issue46012] unittest AsyncConnection not
 described
Message-ID: <1638946320.75.0.503190940676.issue46012@roundup.psfhosted.org>


New submission from David Shiko <dsb321mp at gmail.com>:

AsyncConnection mentioned only one at this docs but not imported or presented somehow else.
https://docs.python.org/3/library/unittest.html.

----------
components: Tests
messages: 408000
nosy: dsb321mp
priority: normal
severity: normal
status: open
title: unittest AsyncConnection not described
versions: Python 3.10

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

From report at bugs.python.org  Wed Dec  8 07:37:28 2021
From: report at bugs.python.org (JMcB)
Date: Wed, 08 Dec 2021 12:37:28 +0000
Subject: [New-bugs-announce] [issue46013] Confusing period in
 object.__hash__ doc
Message-ID: <1638967048.9.0.598691354052.issue46013@roundup.psfhosted.org>


New submission from JMcB <joel.mcbride1 at live.com>:

At https://docs.python.org/3/reference/datamodel.html#object.__hash__
It says:
Called by built-in function hash() and for operations on members of hashed collections including set, frozenset, and dict. __hash__() should return an integer.

How it's rendered there, the kerning made it confusing to me on a first read because dict. [new sentence]__hash__() looked like dict.__hash__().

I think a line break should be added, which I'll open a pr to do.

----------
assignee: docs at python
components: Documentation
messages: 408014
nosy: JMcB17, docs at python
priority: normal
severity: normal
status: open
title: Confusing period in object.__hash__ doc
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Wed Dec  8 08:34:12 2021
From: report at bugs.python.org (Dave Evans)
Date: Wed, 08 Dec 2021 13:34:12 +0000
Subject: [New-bugs-announce] [issue46014] functools.singledispatch does not
 support Union types
Message-ID: <1638970452.65.0.012237534186.issue46014@roundup.psfhosted.org>


New submission from Dave Evans <dave at evans.io>:

It's not currently possible to use `singledispatch` with a function annotated with a Union type, although the desired behaviour is clear.

Example:
```
    from functools import singledispatch
    from typing import Union

    @singledispatch
    def test(arg):
        raise ValueError(arg)

    @test.register
    def _(arg: Union[int, float]):
        print(f"{arg} is a number")

    test(1)
```

This dies with:

    TypeError: Invalid annotation for 'arg'. typing.Union[int, float] is not a class.

I've implemented a workaround which digs the types out of the union and registers them one-by-one:
```
    from functools import singledispatch
    from typing import Union, get_type_hints

    def register_for_union_type(target_fn):
        def decorator(fn):
            arg_type = list(get_type_hints(fn).values())[0]
            assert arg_type.__origin__ is Union
            for type_ in arg_type.__args__:
                fn = target_fn.register(type_)(fn)
            return fn

        return decorator

    @singledispatch
    def test(arg):
        raise ValueError(arg)

    @register_for_union_type(test)
    def _(arg: Union[int, float]):
        print(f"{arg} is a number")

    test(1)

```

Looking at the source for `singledispatch` is doesn't look like it would *too* difficult to add support for something like this, though of course there may be subtleties I've missed. Would you be open to a patch?

The only other mentions I've found of this online are:
https://mail.python.org/archives/list/python-ideas at python.org/thread/HF5HDXQ2SXZHO3TWODIRQATTE4TCAWPL/
https://stackoverflow.com/questions/61721761/type-hints-and-singledispatch-how-do-i-include-union-in-an-extensible-w

----------
components: Library (Lib)
messages: 408018
nosy: evansd
priority: normal
severity: normal
status: open
title: functools.singledispatch does not support Union types
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Dec  8 11:18:46 2021
From: report at bugs.python.org (Steve Dower)
Date: Wed, 08 Dec 2021 16:18:46 +0000
Subject: [New-bugs-announce] [issue46015] Windows venvs do not include DLLs
 directory
Message-ID: <1638980326.73.0.477270049092.issue46015@roundup.psfhosted.org>


New submission from Steve Dower <steve.dower at python.org>:

Before, a venv would include the DLLs directory in sys.path. Since issue45582, it does not, and so anything that relies on a standard library native module cannot run.

----------
assignee: steve.dower
components: Windows
messages: 408033
nosy: paul.moore, steve.dower, tim.golden, vinay.sajip, zach.ware
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Windows venvs do not include DLLs directory
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Wed Dec  8 14:13:05 2021
From: report at bugs.python.org (David CARLIER)
Date: Wed, 08 Dec 2021 19:13:05 +0000
Subject: [New-bugs-announce] [issue46016] fcntl module add F_DUP2FD_CLOEXEC
Message-ID: <1638990785.71.0.738290193352.issue46016@roundup.psfhosted.org>


Change by David CARLIER <devnexen at gmail.com>:


----------
components: FreeBSD
nosy: devnexen, koobs
priority: normal
pull_requests: 28216
severity: normal
status: open
title: fcntl module add F_DUP2FD_CLOEXEC
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Wed Dec  8 17:23:06 2021
From: report at bugs.python.org (Ben Ricketts)
Date: Wed, 08 Dec 2021 22:23:06 +0000
Subject: [New-bugs-announce] [issue46017] Tutorial incorrectly refers to
 skits rather than sketches.
Message-ID: <1639002186.7.0.719126864665.issue46017@roundup.psfhosted.org>


New submission from Ben Ricketts <benricketts77 at gmail.com>:

https://docs.python.org/3/tutorial/appetite.html

4th paragraph from bottom refers to "skits" where as Monty Python in fact perform sketch comedy.It is a minor but important differentiation.

----------
assignee: docs at python
components: Documentation
messages: 408049
nosy: benricketts77, docs at python
priority: normal
severity: normal
status: open
title: Tutorial incorrectly refers to skits rather than sketches.
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Dec  8 19:43:56 2021
From: report at bugs.python.org (Steve Dower)
Date: Thu, 09 Dec 2021 00:43:56 +0000
Subject: [New-bugs-announce] [issue46018] expm1 may incorrectly raise
 OverflowError on underflow
Message-ID: <1639010636.16.0.465988709351.issue46018@roundup.psfhosted.org>


New submission from Steve Dower <steve.dower at python.org>:

If a C runtime's math functions set errno to ERANGE, we assume it is a valid underflow if fabs(result) < 1.0.

However, because expm1 includes a -1.0, it underflows towards -1.0. This fails the above check, and so if a runtime's expm1() sets ERANGE we will raise a spurious OverflowError.

----------
assignee: steve.dower
components: Library (Lib)
messages: 408059
nosy: steve.dower
priority: normal
severity: normal
status: open
title: expm1 may incorrectly raise OverflowError on underflow
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Wed Dec  8 20:52:20 2021
From: report at bugs.python.org (Rahul Gupta)
Date: Thu, 09 Dec 2021 01:52:20 +0000
Subject: [New-bugs-announce] [issue46019] collections.Counter - Cast list of
 keys into set to remove iteration over duplicate elements for __le__,
 __ge__ and __eq__
Message-ID: <1639014740.35.0.724814360021.issue46019@roundup.psfhosted.org>


New submission from Rahul Gupta <rg119 at ic.ac.uk>:

On lines 725, 737 and 749 there is the following code:

'''for c in (self, other) for e in c''' which generates an iterable with all the keys in self and other - casting c to a set will remove duplicates and allow faster iteration - some minor benchmarks I ran seem to agree.

----------
components: Library (Lib)
messages: 408063
nosy: argoop1728
priority: normal
severity: normal
status: open
title: collections.Counter - Cast list of keys into set to remove iteration over duplicate elements for __le__,__ge__ and __eq__
type: performance
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Dec  9 01:32:23 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 09 Dec 2021 06:32:23 +0000
Subject: [New-bugs-announce] [issue46020] Optimize long_pow for the common
 case
Message-ID: <1639031543.32.0.0830001202943.issue46020@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

The expression 'x * x' is faster than 'x ** 2'.

In Python3.10, the speed difference was enormous.  Due to ceval optimizations, the difference in Python3.11 is tighter; however, there is still room for improvement.

The code for long_pow() doesn't currently have a fast path for squaring which is by far the most important case.

$ python3.10 -m timeit -r 11 -s 'x = 10' 'x ** 2'
1000000 loops, best of 11: 201 nsec per loop
$ python3.10 -m timeit -r 11 -s 'x = 10' 'x * x'
10000000 loops, best of 11: 21.9 nsec per loop

$ python3.11 -m timeit -r 11 -s 'x = 10' 'x ** 2'
10000000 loops, best of 11: 32 nsec per loop
$ python3.11 -m timeit -r 11 -s 'x = 10' 'x * x'
20000000 loops, best of 11: 17.6 nsec per loop

----------
components: Interpreter Core
messages: 408076
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Optimize long_pow for the common case
type: performance

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

From report at bugs.python.org  Thu Dec  9 04:11:35 2021
From: report at bugs.python.org (David CARLIER)
Date: Thu, 09 Dec 2021 09:11:35 +0000
Subject: [New-bugs-announce] [issue46021] fcntl module update supports
 FreeBSD F_KINFO flag
Message-ID: <1639041095.56.0.579209436021.issue46021@roundup.psfhosted.org>


New submission from David CARLIER <devnexen at gmail.com>:

- Enabling new F_KINFO flag.
- Returning a subset of practical data from it.

----------
components: FreeBSD
messages: 408088
nosy: devnexen, koobs
priority: normal
pull_requests: 28224
severity: normal
status: open
title: fcntl module update supports FreeBSD F_KINFO flag

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

From report at bugs.python.org  Thu Dec  9 04:19:49 2021
From: report at bugs.python.org (Bar Harel)
Date: Thu, 09 Dec 2021 09:19:49 +0000
Subject: [New-bugs-announce] [issue46022]
 Multiprocessing.Server.serve_forever runs sys.exit()
Message-ID: <1639041589.61.0.824516720423.issue46022@roundup.psfhosted.org>


New submission from Bar Harel <bzvi7919 at gmail.com>:

The Python docs recommends using `.serve_forever()` for running a multiprocessing manager.

The problem is, that unlike any equivalent `.serve_forever()`, this specific one calls `sys.exit()` and exits the program. This in turn may cause issues if that's not the only use of the Python program, as seen here:
https://stackoverflow.com/questions/70284538/overriding-a-built-in-class-method-that-another-class-i-want-to-inherit-from-rel

3 possible solutions:

1. Remove `sys.exit()`: This will cause `shutdown()` to not actually shut down. The function counts on the `.accepter()` daemon thread to close, but if other code is preventing that process from closing, it will continue uninterrupted.

2. Remove `sys.exit()` and check the `stop_event` inside the `.accepter()` daemon thread: This will only partially shut down. The socket will still listen and will only close when the listener receives a command. An option to solve it would be to dispatch a shutdown command, or close the Listener forcibly using `.close()`. All in all, I believe this is the best option.

3. Discourage the use of `serve_forever()`: Right now the way it looks, server is not implemented too well. Its `serve_forever()` function is endorsed by the docs, but the class itself is completely undocumented, with no documentation on any of its functions, and it shuts down the process calling the function when it finishes which is dubious at best. There are plenty more issues scattered around the bug tracker, one of them about its finalization due to the use of daemon threads. Everything can be implemented using start() together with an event. The only reason I don't like this option, is because `serve_forever()` does seem convenient and can be fixed per option 2.

I'll start implementing option 2 in the background, together with adding documentation, but I would enjoy gathering more feedback.

----------
messages: 408090
nosy: bar.harel, davin, pitrou
priority: normal
severity: normal
status: open
title: Multiprocessing.Server.serve_forever runs sys.exit()
versions: Python 3.11

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

From report at bugs.python.org  Thu Dec  9 04:23:50 2021
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 09 Dec 2021 09:23:50 +0000
Subject: [New-bugs-announce] [issue46023] Modules/makesetup generated rules
 ignore *disabled*
Message-ID: <1639041830.9.0.701619101169.issue46023@roundup.psfhosted.org>


New submission from Christian Heimes <lists at cheimes.de>:

Modules/Setup can disable a module. However makesetup does not take *disabled* into account when it generated Makefile.

Example:

---Modules/Setup.local

*disabled*
pwd
---

makesetup generates a Makefile with "pwd" in MODDISABLED_NAMES and MODBUILT_NAMES. Because "pwd" is in MODBUILT_NAMES the module is built and included in python binary.

Expected result:
"pwd" module should not be built.

----------
components: Build
messages: 408091
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: Modules/makesetup generated rules ignore *disabled*
versions: Python 3.11

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

From report at bugs.python.org  Thu Dec  9 05:19:15 2021
From: report at bugs.python.org (flvn.dev)
Date: Thu, 09 Dec 2021 10:19:15 +0000
Subject: [New-bugs-announce] [issue46024] Different behaviour with zipfile
Message-ID: <1639045155.54.0.671926991121.issue46024@roundup.psfhosted.org>


New submission from flvn.dev <flvn.dev at protonmail.com>:

Given the this directory structure:

```
logs
??? 2020
?  ??? 2020101.zip
|  ??? ...
??? 2021
?  ??? 2021101.zip
|  ??? ...
```

The following piece of code:

```python
from pathlib import Path
from zipfile import Path as ZipPath

for item in Path("logs").iterdir():
    if item.is_dir():
        path = next(item.iterdir())
        print(ZipPath(path).name)

```

gives different results between Python 3.9.7 (empty strings) and 3.10.0 (the zip files name)

----------
messages: 408104
nosy: flvn.dev
priority: normal
severity: normal
status: open
title: Different behaviour with zipfile
type: behavior
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Thu Dec  9 06:20:52 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 09 Dec 2021 11:20:52 +0000
Subject: [New-bugs-announce] [issue46025] Raising in an atexit function in
 dev mode crashes
Message-ID: <1639048852.81.0.201272717703.issue46025@roundup.psfhosted.org>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

Issue found by Matt Wozniski:

Running this with python3.10 -X dev segfaults:

import atexit
def func():
    atexit.unregister(func)
    1/0
atexit.register(func)

----------
keywords: 3.10regression, 3.11regression
messages: 408106
nosy: pablogsal
priority: normal
severity: normal
status: open
title: Raising in an atexit function in dev mode crashes
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Thu Dec  9 06:22:12 2021
From: report at bugs.python.org (Zac Hatfield-Dodds)
Date: Thu, 09 Dec 2021 11:22:12 +0000
Subject: [New-bugs-announce] [issue46026] importlib.resources.read_text()
 raises FileNotFound
Message-ID: <1639048932.34.0.580414106772.issue46026@roundup.psfhosted.org>


New submission from Zac Hatfield-Dodds <zac.hatfield.dodds at gmail.com>:

Testing Hypothesis with Python 3.11.0a3, I've triggered a frustrating regression in importlib.resources:


# Both work in Python 3.9 and 3.10, but both fail in 3.11.0a3
from importlib.resources import files, read_text
read_text("hypothesis.vendor", "tlds-alpha-by-domain.txt")
files("hypothesis.vendor").joinpath("tlds-alpha-by-domain.txt").read_text()


Traceback (most recent call last):
  ...
  File "example.py", line 4, in <module>
    read_text("hypothesis.vendor", "tlds-alpha-by-domain.txt")
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "python3.11/importlib/_legacy.py", line 25, in wrapper
    return func(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^
  File "python3.11/importlib/_legacy.py", line 67, in read_text
    with open_text(package, resource, encoding, errors) as fp:
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "python3.11/importlib/_legacy.py", line 25, in wrapper
    return func(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^
  File "python3.11/importlib/_legacy.py", line 50, in open_text
    return (_common.files(package) / _common.normalize_path(resource)).open(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "python3.11/importlib/_adapters.py", line 141, in open
    raise FileNotFoundError("Can't open orphan path")
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
FileNotFoundError: Can't open orphan path


At first I thought this was just a problem with the _legacy shims, but since it also affects the new files() API it might be more serious.

----------
components: Library (Lib)
messages: 408107
nosy: Zac Hatfield-Dodds, barry
priority: normal
severity: normal
status: open
title: importlib.resources.read_text() raises FileNotFound
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Thu Dec  9 13:12:25 2021
From: report at bugs.python.org (Fred Drake)
Date: Thu, 09 Dec 2021 18:12:25 +0000
Subject: [New-bugs-announce] [issue46027]
 email.utils.parsedate_to_datetime() handling of -0000 offset
Message-ID: <1639073545.99.0.633545342091.issue46027@roundup.psfhosted.org>


New submission from Fred Drake <fdrake at gmail.com>:

A local time offset of '-0000' is not handled the same way as an offset of '+0000', but I'd expect it would be:

>>> import email.utils
>>> 
>>> email.utils.parsedate_to_datetime('9 Dec 2021 08:52:04 -0000')
datetime.datetime(2021, 12, 9, 8, 52, 4)
>>> email.utils.parsedate_to_datetime('9 Dec 2021 08:52:04 +0000')
datetime.datetime(2021, 12, 9, 8, 52, 4, tzinfo=datetime.timezone.utc)

I observe the same behavior on Python 3.9.9 and 3.10.1.

----------
components: email
messages: 408149
nosy: barry, fdrake, r.david.murray
priority: normal
severity: normal
status: open
title: email.utils.parsedate_to_datetime() handling of -0000 offset
type: behavior
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Thu Dec  9 19:24:21 2021
From: report at bugs.python.org (Ned Batchelder)
Date: Fri, 10 Dec 2021 00:24:21 +0000
Subject: [New-bugs-announce] [issue46028] 3.11.0a3: under tox,
 sys._base_executable is wrong
Message-ID: <1639095861.79.0.661493259569.issue46028@roundup.psfhosted.org>


New submission from Ned Batchelder <ned at nedbatchelder.com>:

Under tox, sys._base_executable is not an actual file for 3.11.0a3.  It was fine in 3.11.0a2.

To reproduce:

--- 8< --------------------
# tox.ini
[tox]
envlist = py{310,311a2,311}
skipsdist = True

[testenv]
commands =
    python -c "import sys,os.path; print(e := sys._base_executable); print(os.path.exists(e))"

[testenv:py311a2]
# This is the path to 3.11.0a2 if you have it.
basepython = /usr/local/pyenv/pyenv/versions/3.11.0a2/bin/python3
----------------------------

Create a new Python 3.8 virtualenv, and install latest tox (3.24.4 for me).

Then run "tox".  I see:

--------------------------------------------------------------------------------
py310 create: /Users/nedbatchelder/coverage/lab/fix-3.11a3/.tox/py310
py310 run-test-pre: PYTHONHASHSEED='534434199'
py310 run-test: commands[0] | python -c 'import sys,os.path; print(e := sys._base_executable); print(os.path.exists(e))'
/Users/nedbatchelder/coverage/lab/fix-3.11a3/.tox/py310/bin/python
True
py311a2 create: /Users/nedbatchelder/coverage/lab/fix-3.11a3/.tox/py311a2
py311a2 run-test-pre: PYTHONHASHSEED='534434199'
py311a2 run-test: commands[0] | python -c 'import sys,os.path; print(e := sys._base_executable); print(os.path.exists(e))'
/Users/nedbatchelder/coverage/lab/fix-3.11a3/.tox/py311a2/bin/python
True
py311 create: /Users/nedbatchelder/coverage/lab/fix-3.11a3/.tox/py311
py311 run-test-pre: PYTHONHASHSEED='534434199'
py311 run-test: commands[0] | python -c 'import sys,os.path; print(e := sys._base_executable); print(os.path.exists(e))'
/usr/local/pyenv/pyenv/versions/3.11.0a3/python
False
_________________________________________________________ summary _________________________________________________________
  py310: commands succeeded
  py311a2: commands succeeded
  py311: commands succeeded
  congratulations :)
--------------------------------------------------------------------------------

This came to my attention because the coverage.py test suite uses "python -m venv" to create environments. They worked under 3.11.0a2, but failed under a3.  I tracked it down to a difference in sys._base_executable.

I couldn't see a difference in those values without tox, but I'm not sure why it changes the results.

----------
keywords: 3.11regression
messages: 408166
nosy: nedbat, pablogsal
priority: normal
severity: normal
status: open
title: 3.11.0a3: under tox, sys._base_executable is wrong
versions: Python 3.11

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

From report at bugs.python.org  Thu Dec  9 22:01:19 2021
From: report at bugs.python.org (oittaa)
Date: Fri, 10 Dec 2021 03:01:19 +0000
Subject: [New-bugs-announce] [issue46029] "ValueError: Invalid isoformat
 string" from a valid string
Message-ID: <1639105279.05.0.259148747281.issue46029@roundup.psfhosted.org>


New submission from oittaa <oittaa at oittaa.com>:

Test case:

>>> import datetime
>>> datetime.datetime.fromisoformat('2021-12-10T01:00:00Z')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Invalid isoformat string: '2021-12-10T01:00:00Z'


Basically every other programming language I tested correctly accepted this ISO/RFC3339 string as a date.

----------
messages: 408173
nosy: oittaa
priority: normal
severity: normal
status: open
title: "ValueError: Invalid isoformat string" from a valid string
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Fri Dec 10 02:06:11 2021
From: report at bugs.python.org (David Carlier)
Date: Fri, 10 Dec 2021 07:06:11 +0000
Subject: [New-bugs-announce] [issue46030] socket module add couple of
 FreeBSD constants
Message-ID: <1639119971.08.0.15845075802.issue46030@roundup.psfhosted.org>


New submission from David Carlier <dcarlier at deviceatlas.com>:

- adding LOCAL_CREDS then LOCAL_CREDS_PERSISTENT and SCM_CREDS2 which would be used as msg type for the latter.

----------
components: FreeBSD
messages: 408175
nosy: dcarlier, koobs
priority: normal
pull_requests: 28242
severity: normal
status: open
title: socket module add couple of FreeBSD constants
versions: Python 3.11

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

From report at bugs.python.org  Fri Dec 10 04:02:08 2021
From: report at bugs.python.org (penguin_wwy)
Date: Fri, 10 Dec 2021 09:02:08 +0000
Subject: [New-bugs-announce] [issue46031] add POP_JUMP_IF_NOT_NONE and
 POP_JUMP_IF_NONE
Message-ID: <1639126928.63.0.63808958692.issue46031@roundup.psfhosted.org>


New submission from penguin_wwy <940375606 at qq.com>:

https://github.com/faster-cpython/ideas/discussions/154

----------
components: Interpreter Core
messages: 408178
nosy: penguin_wwy
priority: normal
severity: normal
status: open
title: add POP_JUMP_IF_NOT_NONE and POP_JUMP_IF_NONE
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Fri Dec 10 04:04:56 2021
From: report at bugs.python.org (Kumar Aditya)
Date: Fri, 10 Dec 2021 09:04:56 +0000
Subject: [New-bugs-announce] [issue46032] functools' singledispatch does not
 support GenericAlias
Message-ID: <1639127096.15.0.258621113418.issue46032@roundup.psfhosted.org>


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

functools' singledispatch does not support GenericAlias

```py
from functools import singledispatch

@singledispatch
def func(x):
    print("any")

@func.register
def _(x: list[str]):
    print("list[str]")


func(["a", "b"])

```

----------
components: Library (Lib)
messages: 408179
nosy: kumaraditya303, rhettinger
priority: normal
severity: normal
status: open
title: functools' singledispatch does not support GenericAlias
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Fri Dec 10 05:42:42 2021
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBE?=)
Date: Fri, 10 Dec 2021 10:42:42 +0000
Subject: [New-bugs-announce] [issue46033] Duplicated sentence in for
 statement documentation
Message-ID: <1639132962.13.0.2847255275.issue46033@roundup.psfhosted.org>


New submission from Micha? D <michcio1234 at gmail.com>:

In for statement description, there seem to be two sentences meant to mean the same:

> The suite is then executed once for each item provided by the iterator, in the order returned by the iterator. Each item in turn is assigned to the target list using the standard rules for assignments (see Assignment statements), and then the suite is executed.

(from https://docs.python.org/3/reference/compound_stmts.html#the-for-statement)

I believe only one of these sentences should be kept (probably the second one).

If I am wrong, and the current version is actually correct, then it is unclear - to me it sounds like the iterator is iterated through twice, and suite is executed twice for each item.

----------
assignee: docs at python
components: Documentation
messages: 408189
nosy: docs at python, michcio1234
priority: normal
severity: normal
status: open
title: Duplicated sentence in for statement documentation
versions: Python 3.10

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

From report at bugs.python.org  Fri Dec 10 07:01:00 2021
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Fri, 10 Dec 2021 12:01:00 +0000
Subject: [New-bugs-announce] [issue46034] Patch-adding __init__ in a class
 takes no effect when called from a subinterpreter
Message-ID: <1639137660.32.0.636703165427.issue46034@roundup.psfhosted.org>


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

Hello,

based on some bug reports reported in:

- https://github.com/GrahamDumpleton/mod_wsgi/issues/729
- https://github.com/poljar/weechat-matrix/issues/293
- https://bugzilla.redhat.com/show_bug.cgi?id=2030621

I have isolated the following reproducer that shows a regression in Python 3.10+. It happens at least with 3.10.0, 3.10.1 and 3.11.0a2. It works as expected in Python 3.9.

The following code is valid and works on 3.9, 3.10, 3.11:

=========================================
class Greeting():
    pass

def new_init(inst, name):
    inst.text = f"Hello, {name}\n"

Greeting.__init__ = new_init

Greeting("Miro")
=========================================


But if we run it via a subinterpreter, it breaks on 3.10+:

=========================================
import _testcapi

code = r"""class Greeting():
    pass

def new_init(inst, name):
    inst.text = f"Hello, {name}\n"

Greeting.__init__ = new_init

Greeting("Miro")"""

_testcapi.run_in_subinterp(code)
=========================================


$ python3.9 reproducer.py
(exits cleanly)

$ python3.10 reproducer.py 
Traceback (most recent call last):
  File "<string>", line 9, in <module>
TypeError: Greeting() takes no arguments

$ python3.11 reproducer.py 
Traceback (most recent call last):
  File "<string>", line 9, in <module>
TypeError: Greeting() takes no arguments


My observation also shows that if the Greeting class already had (any) __init__:

=========================================
class Greeting():
    __init__ = ...
=========================================

It works as expected on 3.9, 3.10, 3.11.



In reality, this is most likely to affect classes with decorators, like:

=========================================
import attr

@attr.s
class TestClass:
    foo = attr.ib()

TestClass("Miro")
=========================================

This works standalone, but fails in a subinterpreter:

$ python3.10 reproducer.py 
Traceback (most recent call last):
  File "<string>", line 7, in <module>
TypeError: TestClass() takes no arguments

----------
components: Subinterpreters
messages: 408196
nosy: eric.snow, hroncok, vstinner
priority: normal
severity: normal
status: open
title: Patch-adding __init__ in a class takes no effect when called from a subinterpreter
type: behavior
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Fri Dec 10 07:10:59 2021
From: report at bugs.python.org (milahu)
Date: Fri, 10 Dec 2021 12:10:59 +0000
Subject: [New-bugs-announce] [issue46035] mimetypes.guess_type returns
 deprecated mimetype application/x-javascript
Message-ID: <1639138259.47.0.962118215101.issue46035@roundup.psfhosted.org>


New submission from milahu <milahu at gmail.com>:

deprecated mimetype?
per rfc4329, the technical term is "unregistered media type"

https://datatracker.ietf.org/doc/html/rfc4329#section-3

related

https://stackoverflow.com/a/9664327/10440128

https://github.com/danny0838/PyWebScrapBook/issues/53

quick fix

```py
# python/Lib/mimetypes.py

class MimeTypes:
# ...
    def guess_type(self, url, strict=True):
# ...

        if ext in _types_map_default:
            # prefer the python-internal values over /etc/mime.types
            return _types_map_default[ext], encoding

        if ext in types_map:
            return types_map[ext], encoding
```

why is `application/x-javascript` returned?

on linux, mimetypes.init() loads /etc/mime.types
source:
https://mirrors.kernel.org/gentoo/distfiles/mime-types-9.tar.bz2

/etc/mime.types is sorted by alphabet, so

```
cat /etc/mime.types | grep javascript
application/javascript										js
application/x-javascript									js
```

apparently, the last entry application/x-javascript
will overwrite the previous entry application/javascript

----------
components: Library (Lib)
messages: 408197
nosy: milahu
priority: normal
severity: normal
status: open
title: mimetypes.guess_type returns deprecated mimetype application/x-javascript
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Fri Dec 10 08:32:42 2021
From: report at bugs.python.org (Daniel)
Date: Fri, 10 Dec 2021 13:32:42 +0000
Subject: [New-bugs-announce] [issue46036] Single-phase initialized modules
 gets initialized multiple times in 3.10.0
Message-ID: <1639143162.4.0.670333199133.issue46036@roundup.psfhosted.org>


New submission from Daniel <danielfa at fixedit.ai>:

The documentation (https://docs.python.org/3/c-api/init.html#c.Py_NewInterpreter) states:


For modules using single-phase initialization, e.g. PyModule_Create(), the first time a particular extension is imported, it is initialized normally, and a (shallow) copy of its module?s dictionary is squirreled away. When the same extension is imported by another (sub-)interpreter, a new module is initialized and filled with the contents of this copy; the extension?s init function is not called. Objects in the module?s dictionary thus end up shared across (sub-)interpreters, which might cause unwanted behavior (see Bugs and caveats below).


This does however seem to have changed (sometime between 3.6.9 and 3.10.0). Consider the following code:


#include <Python.h>

/*
 * Create a module "my_spam" that uses single-phase initialization
 */
static PyModuleDef EmbModule = {
      PyModuleDef_HEAD_INIT, "my_spam", NULL, -1,
      NULL,
      NULL, NULL, NULL, NULL
};

/*
 * According to the docs this function is only called once when dealing with
 * subinterpreters, the next time a shallow copy of the initial state is
 * returned. This does however not seem to be the case in Python 3.10.0..
 */
static PyObject* PyInit_emb(void) {
  PyObject *module = PyModule_Create(&EmbModule);
  PyModule_AddObject(module, "test", PyDict_New());

  printf("Init my_spam module %p\n", module);
  return module;
}

/*
 * Main program
 */

int main(int argc, char *argv[]) {
  PyImport_AppendInittab("my_spam", &PyInit_emb);
  Py_Initialize();

  // Save the main state
  PyThreadState *mainstate = PyThreadState_Get();

  // Create two new interpreters
  PyThreadState *inter1 = Py_NewInterpreter();
  PyThreadState *inter2 = Py_NewInterpreter();

  // Import the my_spam module into the first subinterpreter
  // and change the global variable of it
  PyThreadState_Swap(inter1);
  PyRun_SimpleString("import sys; print(sys.version_info)");
  PyRun_SimpleString("import my_spam; print('my_spam.test: ', my_spam.test)");
  PyRun_SimpleString("my_spam.test[1]=1; print('my_spam.test: ', my_spam.test)");

  // Import the my_spam module into the second subinterpreter
  // and change the global variable of it
  PyThreadState_Swap(inter2);
  PyRun_SimpleString("import sys; print(sys.version_info)");
  PyRun_SimpleString("import my_spam; print('my_spam.test: ', my_spam.test)");
  PyRun_SimpleString("my_spam.test[2]=2; print('my_spam.test: ', my_spam.test)");

  // Close the subinterpreters
  Py_EndInterpreter(inter2);
  PyThreadState_Swap(inter1);
  Py_EndInterpreter(inter1);

  // Swap back to the main state and finalize python
  PyThreadState_Swap(mainstate);
  if (Py_FinalizeEx() < 0) {
      exit(120);
  }

  return 0;
}



Compiled with python 3.6.9 this does act according to the documentation:


$ gcc test_subinterpreters.c -I/home/daniel/.pyenv/versions/3.6.9/include/python3.6m -L/home/daniel/.pyenv/versions/3.6.9/lib -lpython3.6m && LD_LIBRARY_PATH=/home/daniel/.pyenv/versions/3.6.9/lib ./a.out
sys.version_info(major=3, minor=6, micro=9, releaselevel='final', serial=0)
Init my_spam module 0x7ff7a63d1ef8
my_spam.test:  {}
my_spam.test:  {1: 1}
sys.version_info(major=3, minor=6, micro=9, releaselevel='final', serial=0)
my_spam.test:  {1: 1}
my_spam.test:  {1: 1, 2: 2}


But compiled with 3.10.0 the module is reinitialized and thus objects in the module are not shared between the subinterpreters:


$ gcc test_subinterpreters.c -I/home/daniel/.pyenv/versions/3.10.0/include/python3.10 -L/home/daniel/.pyenv/versions/3.10.0/lib -lpython3.10 && LD_LIBRARY_PATH=/home/daniel/.pyenv/versions/3.10.0/lib ./a.out
sys.version_info(major=3, minor=10, micro=0, releaselevel='final', serial=0)
Init my_spam module 0x7f338a9a9530
my_spam.test:  {}
my_spam.test:  {1: 1}
sys.version_info(major=3, minor=10, micro=0, releaselevel='final', serial=0)
Init my_spam module 0x7f338a9a96c0
my_spam.test:  {}
my_spam.test:  {2: 2}


To me the new behavior seems nicer, but at the very least the documentation should be updated. It also seems like if this could break integrations, albeit it is an unlikely "feature" to rely on.

----------
components: C API
messages: 408209
nosy: daniel-falk
priority: normal
severity: normal
status: open
title: Single-phase initialized modules gets initialized multiple times in 3.10.0
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Fri Dec 10 10:58:08 2021
From: report at bugs.python.org (vladmihaisima)
Date: Fri, 10 Dec 2021 15:58:08 +0000
Subject: [New-bugs-announce] [issue46037] logging.config.dictConfig with
 disable_existing_loggers set, also disables loggers in configuration
Message-ID: <1639151888.32.0.171616624845.issue46037@roundup.psfhosted.org>


New submission from vladmihaisima <vladmihaisima at gmail.com>:

When invoking logging.config.dictConfig - if a logger was previously disabled (for example by a call to "logging.config.dictConfig({'version': 1})") - the loggers specified in the dictionary will not be enabled.

Documentation at https://docs.python.org/3/library/logging.config.html specifies for disable_existing_loggers that "... behaviour is to disable any existing non-root loggers unless they or their ancestors are explicitly named in the logging configuration.". There is no explicit mention for what happens when a logger exists and is already disabled. I would have assumed that if present it will be enabled, but that does not seem to be the case.

So I think that if a logger is disabled invoking dictConfig cannot re-enable it.

See attached code for a reproducible case.

----------
files: bug.py
messages: 408216
nosy: vladmihaisima
priority: normal
severity: normal
status: open
title: logging.config.dictConfig with disable_existing_loggers set, also disables loggers in configuration
versions: Python 3.10, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file50486/bug.py

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

From report at bugs.python.org  Fri Dec 10 11:19:15 2021
From: report at bugs.python.org (Oleg Iarygin)
Date: Fri, 10 Dec 2021 16:19:15 +0000
Subject: [New-bugs-announce] [issue46038] Mark /configure file as generated
 in .gitattributes
Message-ID: <1639153155.2.0.704018156223.issue46038@roundup.psfhosted.org>


New submission from Oleg Iarygin <oleg at arhadthedev.net>:

configure is regenerated from configure.ac using a custom container with appropriate version of tools (quay.io/tiran/cpython_autoconf by Christian Heimes). As a result, configure falls into the same category as files generated by Argument Clinic, Freeze and Parser/asdl_c.py. Due to size and churn of these artifacts, they are marked in .gitattributes as generated so GitHub Pull Request Diff Viewer collapses them into a short notification. The pull request associated with this issue does the same for configure.

Actually, configure diff is so large that sometimes it crosses a threshold and GitHub collapses it by force with "Large diffs are not rendered by default" or even "xxx additions, yyy deletions not shown because the diff is too large. Please use a local Git client to view these changes". See GH-29756 as an extreme example (15,430 insertions and deletions) and <https://github.com/python/cpython/commits/main/configure> for an average.

----------
components: Build
messages: 408218
nosy: arhadthedev
priority: normal
severity: normal
status: open
title: Mark /configure file as generated in .gitattributes
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Fri Dec 10 12:48:52 2021
From: report at bugs.python.org (Mark Shannon)
Date: Fri, 10 Dec 2021 17:48:52 +0000
Subject: [New-bugs-announce] [issue46039] Break up the YIELD_FROM
 instruction.
Message-ID: <1639158532.51.0.938199888812.issue46039@roundup.psfhosted.org>


New submission from Mark Shannon <mark at hotpy.org>:

The YIELD_FROM instruction does three things:

* It sends a value to the sub-iterator
* It yields the value from the sub-iterator back up to its caller
* Loops back on itself

So we should implement this as:

SEND        <--+
YIELD_VALUE    |
JUMP_ABSOLUTE -+

Doing so would allow us to simplify gen.send and gen.throw as they wouldn't need all the special cases for 'yield from'.

Zero cost exception handling allows us to handle throw in the bytecode with no runtime overhead:

while True:
    SEND -> exit
    try:
        YIELD_VALUE
    except BaseException as ex:
        sub_iterator.throw(ex)
exit:

----------
assignee: Mark.Shannon
components: Interpreter Core
messages: 408232
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: Break up the YIELD_FROM instruction.
versions: Python 3.11

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

From report at bugs.python.org  Fri Dec 10 13:28:22 2021
From: report at bugs.python.org (Stanislav Syekirin)
Date: Fri, 10 Dec 2021 18:28:22 +0000
Subject: [New-bugs-announce] [issue46040] asyncio.coroutine documented as
 removed in 3.10
Message-ID: <1639160902.02.0.980259307717.issue46040@roundup.psfhosted.org>


New submission from Stanislav Syekirin <syekirin at gmail.com>:

https://docs.python.org/3.10/library/asyncio-task.html#generator-based-coroutines

This page says about asyncio.coroutine:

    Deprecated since version 3.8, removed in version 3.10

However, asyncio.coroutine is still working in 3.10 and has been removed, as far as I can see, here: https://bugs.python.org/issue43216.

----------
assignee: docs at python
components: Documentation
messages: 408240
nosy: Zabolekar, docs at python
priority: normal
severity: normal
status: open
title: asyncio.coroutine documented as removed in 3.10
versions: Python 3.10

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

From report at bugs.python.org  Fri Dec 10 13:34:10 2021
From: report at bugs.python.org (Maxwell Bernstein)
Date: Fri, 10 Dec 2021 18:34:10 +0000
Subject: [New-bugs-announce] [issue46041] Add reference counting
 micro-optimizations to listobject.c
Message-ID: <1639161250.42.0.698258533036.issue46041@roundup.psfhosted.org>


New submission from Maxwell Bernstein <tekk.nolagi at gmail.com>:

Avoid reference counting in the fast path of list.contains and list.index

----------
messages: 408242
nosy: tekknolagi
priority: normal
severity: normal
status: open
title: Add reference counting micro-optimizations to listobject.c

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

From report at bugs.python.org  Fri Dec 10 16:24:21 2021
From: report at bugs.python.org (Carl Friedrich Bolz-Tereick)
Date: Fri, 10 Dec 2021 21:24:21 +0000
Subject: [New-bugs-announce] [issue46042] Error range of "duplicate
 argument" SyntaxErrors is too big
Message-ID: <1639171461.19.0.894286110082.issue46042@roundup.psfhosted.org>


New submission from Carl Friedrich Bolz-Tereick <cfbolz at gmx.de>:

The error range for the "duplicate argument in function definition" SyntaxError is too large:

$ cat x.py 
def f(a, b, c, d, e, f, g, a): pass
$ python x.py
  File "/home/cfbolz/projects/cpython/x.py", line 1
    def f(a, b, c, d, e, f, g, a): pass
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
SyntaxError: duplicate argument 'a' in function definition

I would expect only the second 'a' to be underlined.

I can try to fix this.

----------
messages: 408248
nosy: Carl.Friedrich.Bolz, pablogsal
priority: normal
severity: normal
status: open
title: Error range of "duplicate argument" SyntaxErrors is too big

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

From report at bugs.python.org  Fri Dec 10 18:22:33 2021
From: report at bugs.python.org (Nicholas Bond)
Date: Fri, 10 Dec 2021 23:22:33 +0000
Subject: [New-bugs-announce] [issue46043] Python Launcher Not Opening Files.
Message-ID: <1639178553.87.0.850014051129.issue46043@roundup.psfhosted.org>


New submission from Nicholas Bond <nicholasjbond2020 at gmail.com>:

Python launcher opens its preferences and no terminal or Tkinter application opens. It appears as something was launched because for a fraction of a second, I see a window and then the icon glides back to its position on the desktop.

However, python files and Tkinter GUIs work when run through the IDLE and through other text editors, e.g. when I build the program in sublime text, the python launcher application opens and launches the Tkinter window.

Even the simplest of programs don't work. I tried opening this:
number = input("Type in a number:")

I ran this outside of the text editor(dragging the .py file onto the python launcher) and it still did not work.

----------
components: macOS
messages: 408260
nosy: ned.deily, nicholasjbond2020, ronaldoussoren
priority: normal
severity: normal
status: open
title: Python Launcher Not Opening Files.
type: crash
versions: Python 3.10

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

From report at bugs.python.org  Fri Dec 10 19:42:01 2021
From: report at bugs.python.org (Matthias Bussonnier)
Date: Sat, 11 Dec 2021 00:42:01 +0000
Subject: [New-bugs-announce] [issue46044] Update distutils documentation to
 say PyPI only accepts tar.gz and zip.
Message-ID: <1639183321.87.0.60010365673.issue46044@roundup.psfhosted.org>


New submission from Matthias Bussonnier <bussonniermatthias at gmail.com>:

This page: https://docs.python.org/3/distutils/sourcedist.html

Is the first result on google for "python sdist", but does not mention that all but tar.gz and zip are supported by PyPI.

----------
assignee: docs at python
components: Documentation
messages: 408288
nosy: docs at python, mbussonn
priority: normal
severity: normal
status: open
title: Update distutils documentation to  say PyPI only accepts tar.gz and zip.

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

From report at bugs.python.org  Sat Dec 11 05:31:04 2021
From: report at bugs.python.org (Thomas Klausner)
Date: Sat, 11 Dec 2021 10:31:04 +0000
Subject: [New-bugs-announce] [issue46045] NetBSD: do not use POSIX semaphores
Message-ID: <1639218664.63.0.969239482314.issue46045@roundup.psfhosted.org>


New submission from Thomas Klausner <tk at giga.or.at>:

On NetBSD by default, the following tests do not finish in > 1h:

1:07:13 load avg: 0.00 running: test_compileall (1 hour 7 min), test_multiprocessing_fork (1 hour 7 min), test_concurrent_futures (1 hour 6 min)

Defining HAVE_BROKEN_POSIX_SEMAPHORES fixes this, and they finish:

0:00:32 load avg: 10.63 [408/427/17] test_compileall passed ...
...
0:02:37 load avg: 3.04 [427/427/22] test_concurrent_futures passed (2 min 33 sec)

The last one fails:
test_multiprocessing_fork

with most of the subtests failing like this:

ERROR: test_shared_memory_SharedMemoryServer_ignores_sigint (test.test_multiprocessing_fork.WithProcessesTestSharedMemory)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/scratch/lang/python310/work/Python-3.10.1/Lib/test/_test_multiprocessing.py", line 4006, in test_shared_memory_SharedMemoryServer_ignores_sigint
    sl = smm.ShareableList(range(10))
  File "/scratch/lang/python310/work/Python-3.10.1/Lib/multiprocessing/managers.py", line 1372, in ShareableList
    sl = shared_memory.ShareableList(sequence)
  File "/scratch/lang/python310/work/Python-3.10.1/Lib/multiprocessing/shared_memory.py", line 327, in __init__
    self.shm = SharedMemory(name, create=True, size=requested_size)
  File "/scratch/lang/python310/work/Python-3.10.1/Lib/multiprocessing/shared_memory.py", line 92, in __init__
    self._fd = _posixshmem.shm_open(
OSError: [Errno 86] Not supported: '/psm_b1ec903a'

I think this is a separate issue, so I'd like to define HAVE_BROKEN_POSIX_SEMAPHORES for now.

This has been done in pkgsrc since at least python 2.7 (in 2011), I haven't dug deeper.

----------
components: Interpreter Core
messages: 408291
nosy: wiz
priority: normal
severity: normal
status: open
title: NetBSD: do not use POSIX semaphores
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Sat Dec 11 05:56:19 2021
From: report at bugs.python.org (Souvik Ghosh)
Date: Sat, 11 Dec 2021 10:56:19 +0000
Subject: [New-bugs-announce] [issue46046] I/O bound threads got to no chance
 to run with small CPU bound threads with new GIL
Message-ID: <1639220179.27.0.659005921662.issue46046@roundup.psfhosted.org>


New submission from Souvik Ghosh <souvikghosh872 at gmail.com>:

According to David Beazley' talk in PyCon'2010 in Atlanta Georgia, he demonstrated about a new GIL with running CPU bound and I/O bound threads together.

He said the talk that the threads which are forced to timeout of 5ms, will have the lower priority(which is CPU bound) and the thread which suspends the GIL within 5ms will have higher priority (which is I/O bound). 

What happens in the following code is if I set args=(10000000,) (seven zero after 1) then only I/O bound runs and returns when CPU bound takes much time to execute. But if I decrease that args to args=(1000,) then I/O bound got no chance to reaquire the GIL in the meantime even though the sys.getswitchinterval() is equal to 5ms(By default). If I/O bound doesn't reacquire GIL with args=(10000,) then the time to execute to run 
only the CPU bound takes 0.42777760000035414 seconds. Thats means almost ticks 0.42777760000035414/0.005=85 (approx) times to set the priority in between the two threads. In that case if the I/O got more priority within that time, it should have returned the value within that ticks. But I didn't happen. 

import threading
from queue import Queue
from timeit import default_timer as timer
import urllib.request


q = Queue()  # Queue technique to pass returns among threads while running


def decrement(numbers):  # CPU bound
    while numbers > 0:
        numbers -= 1
        if not q.empty():
            """I added this method because this thread will run most of the time
            because it's mostly cpu bound"""
            print(numbers)
            print(q.get(block=False))
            print(timer() - start)  # It tell after when exactly I/O bound returns value after both the threads started to run


def get_data():  # I/O bound

    with urllib.request.urlopen("https://www.google.com") as dt:
        q.put(dt.read(), block=False)


if __name__ == "__main__":
    start = timer()
    t1 = threading.Thread(target=get_data)
    #t2 = threading.Thread(target=decrement, args=(10000000,)) #For this I/O responds and returns
    t2 = threading.Thread(target=decrement, args=(100000,)) # I/O doesn't responds at all
    t1.start()
    t2.start()

    t1.join()
    t2.join()
    print(timer() - start)

Look at the second code...


import threading
from queue import Queue
from timeit import default_timer as timer
import urllib.request
import sys


q = Queue()  # Queue technique to pass returns among threads while running


def decrement(numbers):  # CPU bound
    while numbers > 0:
        numbers -= 1
        if not q.empty():
            """I added this method because this thread will run most of the time
            because it's mostly cpu bound"""
            print(numbers)
            print(q.get(block=False))
            print(timer() - start)  # It tell after when exactly I/O bound returns value after both the threads started to run


def get_data():  # I/O bound

    with urllib.request.urlopen("https://www.google.com") as dt:
        q.put(dt.read(), block=False)


if __name__ == "__main__":
    sys.setswitchinterval(0.0000000000000000000000000001)
    start = timer()
    t1 = threading.Thread(target=get_data)
    #t2 = threading.Thread(target=decrement, args=(1000000,)) #I/O responds with this 
    t2 = threading.Thread(target=decrement, args=(10000,))    # I/O doesn't responds at all even with this 0.0000000000000000000000000001 seconds of threads switching interval
    t1.start()
    t2.start()

    t1.join()
    t2.join()
    print(timer() - start)

Can't we have a more better version of GIL to set I/O threads(overall) priorities even more better and not to degrade the CPU bound and better callbacks in response? Or, try to remove the GIL?

Thank you so much, great future of Python!

----------
components: Interpreter Core
files: GIL9.py
messages: 408292
nosy: souvikghosh
priority: normal
severity: normal
status: open
title: I/O bound threads got to no chance to run with small CPU bound threads with new GIL
type: performance
versions: Python 3.10
Added file: https://bugs.python.org/file50487/GIL9.py

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

From report at bugs.python.org  Sat Dec 11 07:12:05 2021
From: report at bugs.python.org (Jonas Witschel)
Date: Sat, 11 Dec 2021 12:12:05 +0000
Subject: [New-bugs-announce] [issue46047] When using Py_NewInterpreter,
 some modules fail to import in Python 3.10
Message-ID: <1639224725.06.0.440012701527.issue46047@roundup.psfhosted.org>


New submission from Jonas Witschel <git at diabonas.de>:

Consider the following minimal example C code which is trying to import jsonschema (https://python-jsonschema.readthedocs.io/en/stable/), compiled using "gcc test_newinterpreter.c -I /usr/include/python3.10 -lpython3.10 -o test_newinterpreter" or similar:

#include <Python.h>

int main(void) {
	Py_Initialize();
	PyThreadState *interpreter = Py_NewInterpreter();
	PyRun_SimpleString("import jsonschema");
	Py_Finalize();	
}

In Python 3.9.9, this works as expected. However in Python 3.10.0, the following error is produced:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python3.10/site-packages/jsonschema/__init__.py", line 21, in <module>
    from jsonschema._types import TypeChecker
  File "/usr/lib/python3.10/site-packages/jsonschema/_types.py", line 168, in <module>
    draft3_type_checker = TypeChecker(
TypeError: TypeChecker() takes no arguments

Removing the Py_NewInterpreter() call makes the example work as expected in Python 3.10.0.

This might be related to the enhancements to the type cache from bpo-42745.

Another recent bug report I found that might possibly be related is bpo-46036.

This bug breaks some WeeChat plugins that try to import one of the affected modules, e.g. weechat-matrix (https://github.com/poljar/weechat-matrix).

----------
components: C API, Subinterpreters
messages: 408295
nosy: diabonas
priority: normal
severity: normal
status: open
title: When using Py_NewInterpreter, some modules fail to import in Python 3.10
type: compile error
versions: Python 3.10

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

From report at bugs.python.org  Sat Dec 11 08:13:55 2021
From: report at bugs.python.org (Steve Dower)
Date: Sat, 11 Dec 2021 13:13:55 +0000
Subject: [New-bugs-announce] [issue46048] embeddable distro cannot import
 modules
Message-ID: <1639228435.55.0.0507692076358.issue46048@roundup.psfhosted.org>


New submission from Steve Dower <steve.dower at python.org>:

The embeddable distro cannot import native modules.

This is because the '.' entry in the ._pth file is incorrect parsed by the new getpath module (issue45582).

----------
assignee: steve.dower
components: Interpreter Core
messages: 408300
nosy: lukasz.langa, steve.dower
priority: normal
severity: normal
stage: needs patch
status: open
title: embeddable distro cannot import modules
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Sat Dec 11 08:48:48 2021
From: report at bugs.python.org (Steve Dower)
Date: Sat, 11 Dec 2021 13:48:48 +0000
Subject: [New-bugs-announce] [issue46049] ._pth files untested on Linux
Message-ID: <1639230528.94.0.623170663642.issue46049@roundup.psfhosted.org>


New submission from Steve Dower <steve.dower at python.org>:

Currently ._pth files are "enabled" for all platforms, but are only tested on Windows.

Extend the tests in test_site to work on all platforms.

----------
assignee: steve.dower
components: Interpreter Core
messages: 408304
nosy: steve.dower
priority: normal
severity: normal
stage: patch review
status: open
title: ._pth files untested on Linux
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Sat Dec 11 11:25:35 2021
From: report at bugs.python.org (matt)
Date: Sat, 11 Dec 2021 16:25:35 +0000
Subject: [New-bugs-announce] [issue46050] [pathlib] Option so that OSError
 does not block glob in pathlib library
Message-ID: <1639239935.56.0.723240753411.issue46050@roundup.psfhosted.org>


New submission from matt <github.gitmatt at xoxy.net>:

Hi there,
ISSUE DESCRIPTION
when I browse starting from the linux root ('/')
    path = pathlib.Path('/')
    _glob = '**/*'
    for p in path.glob(_glob):

The program stops on my machine because of OSError.
  File "/usr/lib/python3.8/pathlib.py", line 535, in _select_from
    entries = list(scandir_it)

OSError: [Errno 22] Invalid argument: '/proc/5916/task/5916/net'

****************************************
Entering post mortem debugging...
****************************************
> /usr/lib/python3.8/pathlib.py(535)_select_from()
    533         try:
    534             with scandir(parent_path) as scandir_it:
--> 535                 entries = list(scandir_it)
    536             for entry in entries:
    537                 if self.dironly:

I also another case is if a cloud drive is disconnected.

QUICK SOLUTION
I solved both issues for me by adding an adding an except OSError: return at the end of the two function below:

class _WildcardSelector(_Selector):
    def _select_from(self, parent_path, is_dir, exists, scandir):
        (...)
        except OSError:
            return

class _RecursiveWildcardSelector(_Selector):
    def _iterate_directories(self, parent_path, is_dir, scandir):
        (...)
        except OSError:
            return

FEATURE REQUEST
I don't know the consequences of those 2 modifications so perhaps they could follow an option when calling glob with an optional parameter ignoreOSerror = false by default?!

----------
components: Library (Lib)
messages: 408314
nosy: matt32106
priority: normal
severity: normal
status: open
title: [pathlib] Option so that OSError does not block glob in pathlib library
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Sat Dec 11 12:27:01 2021
From: report at bugs.python.org (quapka)
Date: Sat, 11 Dec 2021 17:27:01 +0000
Subject: [New-bugs-announce] [issue46051] Make @atexit.register work for
 functions with arguments
Message-ID: <1639243621.71.0.144294694671.issue46051@roundup.psfhosted.org>


New submission from quapka <quapka at gmail.com>:

Hi folks!

Let me first present an example that motivated this issue. Imagine a script that builds Docker images and later starts them as Docker containers. To avoid having to stop the containers "manually" (in code and potentially forgot) I had an idea to register each container when started and stop each using atexit module. I chose to encapsulate this behavior inside a class. A much simplified example looks like this:

    import atexit

    class Program:
        # keep a class level list of started containers
        running_containers = []

        @atexit.register
        @classmethod
        def clean_up(cls, *args, **kwargs):
            for container in cls.running_containers:
                print(f'stopping {container}')

        def start_container(self, container):
            print(f'starting {container}')
            self.__class__.running_containers.append(container)

    prog = Program()
    a.start_container('container_A')
    a.start_container('container_B')

And I'd expect this to produce:

    starting container_A
    starting container_B
    stopping container_A
    stopping container_B

To me, this reads rather nicely: the Program.clean_up method can be called by the user, but if he forgets it will be handled for him using atexit. However, this code does not work. :) I've spent some time debugging and what follows are my observations:

1) If the order of decorators is @atexit.register and then @classmethod then the code throws 'TypeError: the first argument must be callable'. I believe it is because classmethod and staticmethod are descriptors without the __call__ method implemented. atexit.register does not check this and instead of func.__func__ (which resolves to Program.clean_up) gets func (a classmethod) which is not callable (https://github.com/python/cpython/blob/main/Modules/atexitmodule.c#L147).

2) If the order of decorators is swapped (@classmethod and @atexit.register) then the code throws "Error in atexit._run_exitfuncs:\nTypeError: clean_up() missing 1 required positional argument: 'cls'". From my limited understanding of CPython and atexitmodule.c I think what happens is that the @atexit.register returns (https://github.com/python/cpython/blob/main/Modules/atexitmodule.c#L180) the func without the args and kwargs (since this issue https://bugs.python.org/issue1597824).

3) However, if I step away from decorating using @atexit.register and instead use

    [...]
    atexit.register(Program.clean_up) # <-- register post definition
    prog = Program()
    a.start_container('container_A')
    a.start_container('container_B')

then the code works as expected and outputs:

    starting container_A
    starting container_B
    stopping container_A
    stopping container_B


To summarize, I don't like 3) as it puts the responsibility in a bit awkward place (good enough if I'm the only user, but I wonder about the more general library-like cases). My decorating skills are a bit dull now and it's my first time seriously looking into CPython internals - I've tried to encapsulate atexit.register in my custom decorator, to check whether that could be a workaround but overall was unsuccessful. In short, I'd say that in both 1) and 2) the cls arg is lost when atexit calls the function. I've tried to dig it up from the func passed to atexit.register

    def my_atexit_decorator(func, *args, **kwargs):
        cls = # some magic with under attrs and methods
        register.atexit(func, cls=cls, *args, **kwargs)
        [...]

, but failed (it also felt like a fragile approach).

I was not able to understand why @atexit.register does not work when the function's signature is not empty. Also, if fixable I'm happy to actually put the effort into fixing it myself (looks like a nice first CPython PR), but I'd like to have someone else's opinion before I start marching in the wrong direction. Also, let me know if you'd like more details or code/tests I've produced while debugging this.

Cheers!

----------
messages: 408321
nosy: quapka
priority: normal
severity: normal
status: open
title: Make @atexit.register work for functions with arguments
type: enhancement

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

From report at bugs.python.org  Sat Dec 11 17:12:16 2021
From: report at bugs.python.org (Anton Bryl)
Date: Sat, 11 Dec 2021 22:12:16 +0000
Subject: [New-bugs-announce] [issue46052] Ctrl+C,
 Ctrl+V in IDLE on Windows do not work with Cyrillic keyboard layout
Message-ID: <1639260736.08.0.703954085889.issue46052@roundup.psfhosted.org>


New submission from Anton Bryl <anton.bryl at gmail.com>:

Ctrl+C and Ctrl+V key combinations in IDLE on Windows do not work with Cyrillic keyboard layout. It is unexpected, as well as inconvenient when editing string constants.

----------
assignee: terry.reedy
components: IDLE
messages: 408345
nosy: anton.bryl, terry.reedy
priority: normal
severity: normal
status: open
title: Ctrl+C, Ctrl+V in IDLE on Windows do not work with Cyrillic keyboard layout
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Sat Dec 11 18:15:12 2021
From: report at bugs.python.org (Thomas Klausner)
Date: Sat, 11 Dec 2021 23:15:12 +0000
Subject: [New-bugs-announce] [issue46053] NetBSD: ossaudio support incomplete
Message-ID: <1639264512.66.0.774714620496.issue46053@roundup.psfhosted.org>


New submission from Thomas Klausner <tk at giga.or.at>:

When compiling Python on NetBSD, the ossaudio module is not enabled.
1. the code tries to export some #define that are not in the public OSS API (but that some other implementations provide)
2. on NetBSD, you need to link against libossaudio when using OSS

----------
components: Extension Modules
messages: 408349
nosy: wiz
priority: normal
severity: normal
status: open
title: NetBSD: ossaudio support incomplete
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Sun Dec 12 00:29:47 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 12 Dec 2021 05:29:47 +0000
Subject: [New-bugs-announce] [issue46054] Incorrect error when parsing
 non-utf8 files
Message-ID: <1639286987.92.0.127175285023.issue46054@roundup.psfhosted.org>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

Python3.9 shows:

 ../3.9/python /bin/ls
SyntaxError: Non-UTF-8 code starting with '\xfc' in file /bin/ls on line 2, but no encoding declared; see https://python.org/dev/peps/pep-0263/ for detail

while 3.10 shows:

 python /bin/ls
  File "/bin/ls", line 0

SyntaxError: unknown parsing error

----------
components: Parser
messages: 408361
nosy: lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Incorrect error when parsing non-utf8 files
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Sun Dec 12 00:33:38 2021
From: report at bugs.python.org (Xinhang Xu)
Date: Sun, 12 Dec 2021 05:33:38 +0000
Subject: [New-bugs-announce] [issue46055] Speed up binary shifting operators
Message-ID: <1639287218.01.0.821172330488.issue46055@roundup.psfhosted.org>


New submission from Xinhang Xu <xuxinhang4567 at 126.com>:

See its PR.

---------

Inspired by [bpo-44946](https://bugs.python.org/issue44946), I found there were no special shortcuts for shifting operation applied to "medium value" long object. So I modified CPython's VM to accelerate my python project where there is plenty of binary shifting operation. I guess somebody else might also need it.

----------
components: Interpreter Core
messages: 408362
nosy: xuxinhang
priority: normal
pull_requests: 28289
severity: normal
status: open
title: Speed up binary shifting operators
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Sun Dec 12 07:45:16 2021
From: report at bugs.python.org (wolfgang kuehn)
Date: Sun, 12 Dec 2021 12:45:16 +0000
Subject: [New-bugs-announce] [issue46056] Cannot use virtual environment on
 Windows 10 in cooperate security settingss
Message-ID: <1639313116.18.0.364057363878.issue46056@roundup.psfhosted.org>


New submission from wolfgang kuehn <wolfgang-kuehn at decatur.de>:

I just installed Python3.10.1 from the Windows 10 App Store. 
Most workflows depend on creating virtual environments, but (1)

    python -m venv venv

    # -> Error 1260: Windows cannot open this program because it has been prevented by a software restriction policy

However, a (2)

    python -m venv --without-pip venv

completes, only to not allow execution of (3)

    .\venv\Scripts\python.exe
    # -> Error 1260: Windows cannot open this program because it has been prevented by a software restriction policy


Reason for this probably are the (not so unreasonable) cooperate Software Restriction Policy (in our case enforced by Applocker):
You are not allowed to execute from where you are allowed to write.

So basically Python is broken in many MS Windows cooperate settings. Cooperate meaning (Software Restriction Policies) + (Usage of Virtual Environments). 

And my feeling is that it does not need to be, the virtual environment implementation with those *.exe copies being a kludge, IMHO.


Note: (2) is reminiscent of bpo-45337, which was fixed with 3.9.

----------
components: Installation
messages: 408380
nosy: wolfgang-kuehn
priority: normal
severity: normal
status: open
title: Cannot use virtual environment on Windows 10 in cooperate security settingss
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/issue46056>
_______________________________________

From report at bugs.python.org  Sun Dec 12 09:53:18 2021
From: report at bugs.python.org (=?utf-8?b?TMOhc3psw7MgQXR0aWxhIFTDs3Ro?=)
Date: Sun, 12 Dec 2021 14:53:18 +0000
Subject: [New-bugs-announce] [issue46057] argparse: embedded groups may
 prevent options from being in help output
Message-ID: <1639320798.63.0.0421812802369.issue46057@roundup.psfhosted.org>


New submission from L?szl? Attila T?th <laszlo.attila.toth at gmail.com>:

I tried to use the following code where the --db-password is not shown in the --help output (Originally I wanted to use mutually exclusive groups but that feature also works strangely, so I changed them to regular groups).

def register_db_args(parser: argparse.ArgumentParser):
    grp = parser.add_argument_group('Database settings')
    grp.add_argument('--db-config', dest='db_config_file',
                     help='Config file containg all details including password')

    grp.add_argument('--db-host')
    grp.add_argument('--db-port')
    grp.add_argument('--db-user')

    xgrp = grp.add_argument_group()
    xgrp.add_argument('--db-password')
    xgrp.add_argument('--db-password-env')
    xgrp.add_argument('--db-password-file')

----------
components: Library (Lib)
messages: 408388
nosy: Laszlo.Attila.Toth
priority: normal
severity: normal
status: open
title: argparse: embedded groups may prevent options from being in help output
type: behavior
versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Dec 12 14:01:14 2021
From: report at bugs.python.org (=?utf-8?b?TMOhc3psw7MgQXR0aWxhIFTDs3Ro?=)
Date: Sun, 12 Dec 2021 19:01:14 +0000
Subject: [New-bugs-announce] [issue46058] argparse: arg groups and mutually
 exclusive groups behave inconsitently
Message-ID: <1639335674.28.0.221723621867.issue46058@roundup.psfhosted.org>


New submission from L?szl? Attila T?th <laszlo.attila.toth at gmail.com>:

I tried to add arguments to process DB-related settings, either from typing import Optional
from a file
or explicitly specifying them. In theory with nested groups (by add_argument_group
and add_mutually_exlusive_group) this can be implemented in almost straightforward way:


# test.py
import argparse

parser = argparse.ArgumentParser()
dbsettings = parser.add_argument_group('Database settings')
xdbgrp = dbsettings.add_mutually_exclusive_group(required=True)
xdbgrp.add_argument('--db-config')

grp = xdbgrp.add_argument_group(required=True)
grp.add_argument('--db-host')
grp.add_argument('--db-user')

xgrp = grp.add_mutually_exclusive_group()
xgrp.add_argument('--db-password')
xgrp.add_argument('--db-password-file')
parser.parse_args()


But there are issues:
1) the add_mutually_exclusive_group has only one optional parameter, required=False by default,
   so I cannot provide a title, I have to create yet another group (xdbgrp in the example)

2) I would expect the parser do the complete argument parsing and validation, so I don't
   need to implement certain steps. In this example I expect to have a --db-host arg
   if the --db-config is not specified. But if I add  ``required=True``, the argparse
   module expects that with --db-config the --db-host is also specified.
   In other words the xdbgrp mutually exclusive group fails to be mutually exclusive.

3) While xgrp behaves correctly, I cannot specify both --db-password and --db-password-file,
   I still can specify them with --db-config (see #2)

4) If I run it as: python3 test.py  --db-host x
   the command fails:
   usage: test.py [-h] --db-config DB_CONFIG --db-host DB_HOST [--db-user DB_USER]
               [--db-password DB_PASSWORD | --db-password-file DB_PASSWORD_FILE]
   test.py: error: one of the arguments --db-config is required

   So both --db-config and --db-host are required, the embedded group, grp fails to work,
   or prehaps again the xdbgrp fails (depends on the view)


5) Removing all required=True options the following is accepted:
   python3 test.py  --db-host x --db-config y
   so the xdbgrp mutually exclusive group again doesn't work.

6) Only xdbgrp is required, --db-host is not:
    python3 test.py  --db-host x
    usage: test.py [-h] --db-config DB_CONFIG [--db-host DB_HOST] [--db-user DB_USER]
                [--db-password DB_PASSWORD | --db-password-file DB_PASSWORD_FILE]
    test.py: error: one of the arguments --db-config is required
    Again, the group embedded into a mutually exclusive group is not handled correctly

What is expected:
1) add_mutually_exclusive_group can have title/description, but unfortunately it is not
backward compatible

2) If I add a mutally exclusive group, it has XOR relation between its arguments and
   argument groups.

3) An argument group is handled as a single entity similar to an argument.
   Basically this is the same as #2.

4) A required argument affects only its argument group and the parent group
   and so on till the parser, but this chain stops at a mutually exclusive group,
   based on #2 and #3 .

----------
components: Library (Lib)
messages: 408405
nosy: Laszlo.Attila.Toth
priority: normal
severity: normal
status: open
title: argparse: arg groups and mutually exclusive groups behave inconsitently
type: behavior
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Dec 12 19:46:36 2021
From: report at bugs.python.org (Vivek Vashist)
Date: Mon, 13 Dec 2021 00:46:36 +0000
Subject: [New-bugs-announce] [issue46059] Typo in match Statement example
Message-ID: <1639356396.07.0.913283855262.issue46059@roundup.psfhosted.org>


New submission from Vivek Vashist <vivekvashist at gmail.com>:

Possible Typo in match statement example. https://docs.python.org/3/tutorial/controlflow.html#match-statements


BROKEN:
> python
Python 3.10.0b4 (default, Nov 15 2021, 18:26:05) [Clang 12.0.0 (clang-1200.0.32.29)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from enum import Enum
>>> class Color(Enum):
...     RED = 0
...     GREEN = 1
...     BLUE = 2
...
>>> match color:
...     case Color.RED:
...         print("I see red!")
...     case Color.GREEN:
...         print("Grass is green")
...     case Color.BLUE:
...         print("I'm feeling the blues :(")
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'color' is not defined. Did you mean: 'Color'?


WORKING:

> python
Python 3.10.0b4 (default, Nov 15 2021, 18:26:05) [Clang 12.0.0 (clang-1200.0.32.29)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
>>>
>>>
>>> from enum import Enum
>>> class Color(Enum):
...     RED = 0
...     GREEN = 1
...     BLUE = 2
...
>>> match Color:
...     case Color.RED:
...         print("I see red!")
...     case Color.GREEN:
...         print("Grass is green")
...     case Color.BLUE:
...         print("I'm feeling the blues :(")

----------
assignee: docs at python
components: Documentation
messages: 408415
nosy: docs at python, vivekvashist
priority: normal
severity: normal
status: open
title: Typo in match Statement example
versions: Python 3.10

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

From report at bugs.python.org  Mon Dec 13 00:10:39 2021
From: report at bugs.python.org (Paul Bryan)
Date: Mon, 13 Dec 2021 05:10:39 +0000
Subject: [New-bugs-announce] [issue46060] Clarify asyncio.new_event_loop
 return value
Message-ID: <1639372239.16.0.586208830445.issue46060@roundup.psfhosted.org>


New submission from Paul Bryan <pbryan at mperativ.io>:

Currently, the documentation states it creates a new event loop; it should also indicate that it returns the newly created event loop.

----------
assignee: docs at python
components: Documentation
messages: 408425
nosy: docs at python, pbryan2
priority: normal
severity: normal
status: open
title: Clarify asyncio.new_event_loop return value
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Mon Dec 13 04:22:21 2021
From: report at bugs.python.org (Ajaya Sutar)
Date: Mon, 13 Dec 2021 09:22:21 +0000
Subject: [New-bugs-announce] [issue46061] Journal execution gives fatal
 error in Python 3.10.1
Message-ID: <1639387341.54.0.200759283155.issue46061@roundup.psfhosted.org>


New submission from Ajaya Sutar <ajaya.sutar at siemens.com>:

+++ General Fault Exception
+++ Invalid read from 0000000000000000
    rsp:       74b27f8a10, rip:     7ffe704e2f93, rbp:       74b27f8ce9
    rsi:                0, rdi:                0
    rax:                0, rbx:               7f, rcx:      194b6e90000, rdx:      194b6e90000
    r8:       194b6db96c0, r9:                 1, r10:             8000, r11:       74b27f8a00
    r12:                0, r13:                0, r14:      19484550e40, r15:                0
[ 1] 7FFE704E2F93 pylifecycle\fatal_output_debug Line 2492 +0x43               (python310) 
[ 2] 7FFE704E3CCA pylifecycle\fatal_error Line 2734 +0x2ba                     (python310) 
[ 3] 7FFE704E3E4C pylifecycle\_Py_FatalErrorFormat Line 2784 +0xec             (python310) 
[ 4] 7FFE704E6F52 pystate\PyThreadState_Delete Line 930 +0x52                  (python310) 
[ 5] 7FFE704E1BF9 pylifecycle\new_interpreter Line 1967 +0x269                 (python310) 
[ 6] 7FFE704E1CDF pylifecycle\Py_NewInterpreter Line 1988 +0x1f                (python310)

----------
components: C API
messages: 408431
nosy: eaqrzn
priority: normal
severity: normal
status: open
title: Journal execution gives fatal error in Python 3.10.1
type: crash
versions: Python 3.10

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

From report at bugs.python.org  Mon Dec 13 05:41:37 2021
From: report at bugs.python.org (Martin Whitehead)
Date: Mon, 13 Dec 2021 10:41:37 +0000
Subject: [New-bugs-announce] [issue46062] In IDLE,
 'File > Save As' seems not to allow creation of a new folder
Message-ID: <1639392097.98.0.679705685324.issue46062@roundup.psfhosted.org>


New submission from Martin Whitehead <mw.python_bug_tracker at nym.hush.com>:

The problem: In both the IDLE shell and the editor,  'File > Save As' seems not to allow creation of a new folder.  

My system: 
IDLE v3.8.10 (64 bit)
Python 3.8.10 Tk version 8.6.10
Linus Mint  20.2 Uma (64 bit), which is based on Ubuntu 20.04 LTS (Focal Fossa)

----------
assignee: terry.reedy
components: IDLE
messages: 408437
nosy: suffolkpunch, terry.reedy
priority: normal
severity: normal
status: open
title: In IDLE,  'File > Save As' seems not to allow creation of a new folder
versions: Python 3.8

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

From report at bugs.python.org  Mon Dec 13 07:12:03 2021
From: report at bugs.python.org (Sami Salonen)
Date: Mon, 13 Dec 2021 12:12:03 +0000
Subject: [New-bugs-announce] [issue46063] TimedRotatingFileHandler deletes
 wrong files
Message-ID: <1639397523.26.0.357602434319.issue46063@roundup.psfhosted.org>


New submission from Sami Salonen <sersei at gmail.com>:

https://bugs.python.org/issue45628 breaks file rotation.

I name my log files after module name, run the modules in separate processes, use the same log config in them, and store the log files in one common directory. For example, for modules `a.b` and `a.b.c` I have the following log files:

a.b.log
a.b.c.log

Now after bpo-45628 fix, `getFilesToDelete` treats the rotated log files from those modules the same, and deletes wrong files. If `backupCount` is set to e.g. 7, only total of 7 files are stored instead of 7 of each.

----------
components: Library (Lib)
messages: 408445
nosy: Sami Salonen
priority: normal
severity: normal
status: open
title: TimedRotatingFileHandler deletes wrong files
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Mon Dec 13 08:14:42 2021
From: report at bugs.python.org (Fabian Dill)
Date: Mon, 13 Dec 2021 13:14:42 +0000
Subject: [New-bugs-announce] [issue46064] Permalinks to underscored
 documentation entries don't work.
Message-ID: <1639401282.19.0.555190776199.issue46064@roundup.psfhosted.org>


New submission from Fabian Dill <fabian.dill at web.de>:

As an example, go to https://docs.python.org/3/library/constants.html and request a permalink to __debug__. The link you get will not jump to it.
The link I get is https://docs.python.org/3/library/constants.html#debug__

----------
assignee: docs at python
components: Documentation
messages: 408451
nosy: Fabian Dill, docs at python
priority: normal
severity: normal
status: open
title: Permalinks to underscored documentation entries don't work.
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Mon Dec 13 08:26:28 2021
From: report at bugs.python.org (Ramzi Trabelsi)
Date: Mon, 13 Dec 2021 13:26:28 +0000
Subject: [New-bugs-announce] [issue46065] re.findall takes forever and never
 ends
Message-ID: <1639401988.73.0.733937004071.issue46065@roundup.psfhosted.org>


New submission from Ramzi Trabelsi <ramzi.tra at gmail.com>:

parsing emails from this text took forever and never ends. Here the code 
 and the file res.html is attached.
The Behavior is same on Windows 10, 11 and Ubuntu 18.04

CODE:

import re
pattern_email      = r"[a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\.[a-zA-Z0-9-.]{2,3}"
with open("res.html","r",encoding="utf-8") as FF:
	TEXT = FF.read()
matched_email          = re.findall(pattern_email,TEXT)

----------
components: macOS
files: res.zip
messages: 408453
nosy: ned.deily, ramzitra, ronaldoussoren
priority: normal
severity: normal
status: open
title: re.findall takes forever and never ends
type: crash
versions: Python 3.9
Added file: https://bugs.python.org/file50488/res.zip

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

From report at bugs.python.org  Mon Dec 13 10:36:57 2021
From: report at bugs.python.org (97littleleaf11)
Date: Mon, 13 Dec 2021 15:36:57 +0000
Subject: [New-bugs-announce] [issue46066] Docs: TypedDict alternative
 definition syntax with keyword args is confusing
Message-ID: <1639409817.42.0.21314101687.issue46066@roundup.psfhosted.org>


New submission from 97littleleaf11 <97littleleaf11 at gmail.com>:

According to the docs: https://docs.python.org/3/library/typing.html?#typing.TypedDict, there are two additional equivalent syntax for TypedDict definition.

Point2D = TypedDict('Point2D', x=int, y=int, label=str)
Point2D = TypedDict('Point2D', {'x': int, 'y': int, 'label': str})

However, the former one is quite confusing since we have the `total` keyword arg for TypedDict. In addition, PEP589(https://www.python.org/dev/peps/pep-0589/#id19) doesn't have this.

I think we could discard the definition syntax using keyword args in the doc.

----------
assignee: docs at python
components: Documentation
messages: 408458
nosy: 97littleleaf11, docs at python
priority: normal
severity: normal
status: open
title: Docs: TypedDict alternative definition syntax with keyword args is confusing
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Dec 13 12:18:24 2021
From: report at bugs.python.org (Jonas Witschel)
Date: Mon, 13 Dec 2021 17:18:24 +0000
Subject: [New-bugs-announce] [issue46067] SSLContext.set_npn_protocols
 broken in Python 3.10, tries to call non-existing _set_npn_protocols
Message-ID: <1639415904.86.0.18905683137.issue46067@roundup.psfhosted.org>


New submission from Jonas Witschel <git at diabonas.de>:

Consider the following minimal example:

import ssl
context = ssl.create_default_context()
context.set_npn_protocols(['http/1.1', 'spdy/2'])

In Python 3.10, it fails with the following error:

AttributeError: 'SSLContext' object has no attribute '_set_npn_protocols'. Did you mean: 'set_npn_protocols'?

This is because bpo-43669 (https://github.com/python/cpython/commit/39258d3595300bc7b952854c915f63ae2d4b9c3e) removed _set_npn_protocols, while it is still used by SSLContext.set_npn_protocols: https://github.com/python/cpython/blob/191c431de7d9b23484dd16f67e62c6e85a1fac7f/Lib/ssl.py#L551

Note that the function is already deprecated in Python 3.10 and throws a

DeprecationWarning: ssl NPN is deprecated, use ALPN instead

but should still probably continue working for now.

----------
assignee: christian.heimes
components: SSL
messages: 408466
nosy: christian.heimes, diabonas
priority: normal
severity: normal
status: open
title: SSLContext.set_npn_protocols broken in Python 3.10, tries to call non-existing _set_npn_protocols
type: compile error
versions: Python 3.10

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

From report at bugs.python.org  Mon Dec 13 17:45:12 2021
From: report at bugs.python.org (Andrei Kulakov)
Date: Mon, 13 Dec 2021 22:45:12 +0000
Subject: [New-bugs-announce] [issue46068] Change use of warnings.warn to
 logging.warning in a few places
Message-ID: <1639435512.0.0.159079727605.issue46068@roundup.psfhosted.org>


New submission from Andrei Kulakov <andrei.avk at gmail.com>:

In discussion on https://github.com/python/cpython/pull/29910 related to whether to use warnings.warn or logging.warning, I found two places in the library where it might make sense to change to logging.warning. There's probably other instances where the same change can be made but it's not easy to tell just by going through the list because the difference of when use one or the other is not always clearcut. If more instances are found, they can be added to this issue.

https://docs.python.org/3/howto/logging.html#when-to-use-logging

https://github.com/python/cpython/blob/eb483c46d62707bdf705491f76cf1fa9642fb47e/Lib/zoneinfo/_tzpath.py#L44

https://github.com/python/cpython/blob/f42a06ba279c916fb67289e47f9bc60dc5dee4ee/Lib/zipfile.py#L1480

The downside of making this change is that it may break 3rd party unit tests.

----------
components: Library (Lib)
messages: 408488
nosy: andrei.avk
priority: low
severity: normal
status: open
title: Change use of warnings.warn to logging.warning in a few places
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Tue Dec 14 04:38:01 2021
From: report at bugs.python.org (haven david)
Date: Tue, 14 Dec 2021 09:38:01 +0000
Subject: [New-bugs-announce] [issue46069] Super Smash Flash 2
Message-ID: <1639474681.48.0.76279555559.issue46069@roundup.psfhosted.org>


New submission from haven david <havenhaven0268 at gmail.com>:

Opportunity for you to transform into interesting characters like Mario, Sonic...
Online game with exciting battles
https://super-smashflash2.com

----------
components: Build
messages: 408519
nosy: havenhaven
priority: normal
severity: normal
status: open
title: Super Smash Flash 2
versions: Python 3.11

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

From report at bugs.python.org  Tue Dec 14 05:57:50 2021
From: report at bugs.python.org (graysky)
Date: Tue, 14 Dec 2021 10:57:50 +0000
Subject: [New-bugs-announce] [issue46070] broken subinterpreters
Message-ID: <1639479470.16.0.0957612092108.issue46070@roundup.psfhosted.org>


New submission from graysky <graysky at archlinux.us>:

Seems as though cpython is broken when working with subinterpreters. The problematic change could be (d0d29655ff) affecting import.c.[1] Reverting this commit and rebuilding python fixes the issues on my system with some scripts that import sqlite, for example, the Kodi plugin YouTube[2] and the IMDB Trailers plugin. Others have reported similar breakage with other python code[3].

Example output when the bug manifests:

ERROR <general>: Traceback (most recent call last):
ERROR <general>:   File "/usr/lib/python3.10/sqlite3/dbapi2.py", line 83, in register_adapters_and_converters
ERROR <general>:     
ERROR <general>: register_converter("timestamp", convert_timestamp)
ERROR <general>: 
ERROR <general>: KeyError
ERROR <general>: : 
ERROR <general>: 'timepart_full'
ERROR <general>:                                              
ERROR <general>: Exception ignored deletion of interned string failed
ERROR <general>: :


References:
1. https://github.com/python/cpython/commit/d0d29655ffc43d426ad68542d8de8304f7f1346a
2. https://github.com/anxdpanic/plugin.video.youtube/issues/255
3. https://bbs.archlinux.org/viewtopic.php?id=272121

----------
components: Interpreter Core
messages: 408520
nosy: graysky
priority: normal
severity: normal
status: open
title: broken subinterpreters
versions: Python 3.10

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

From report at bugs.python.org  Tue Dec 14 10:20:03 2021
From: report at bugs.python.org (David Mc Dougall)
Date: Tue, 14 Dec 2021 15:20:03 +0000
Subject: [New-bugs-announce] [issue46071] Graphlib documentation
Message-ID: <1639495203.77.0.753963192728.issue46071@roundup.psfhosted.org>


New submission from David Mc Dougall <dam1784 at g.rit.edu>:

The documentation for graphlib encourages users to represent their graphs in a awkward format.

Graphs are currently represented using dictionaries of nodes, for example:
graph["end_node"] = ["start_node"]

And this is unintuitive because you can't use the graph traverse edges in their forward direction.
If you look up a node in the graph, you get all of the nodes that point to the key,
as opposed to all of the nodes that the key points to.

The solution is to rewrite the documentation such that all of the edge directions are reversed.
The final topologically sorted list will be in the "opposite" direction as a consequence.

This will cause no functional changes.

----------
assignee: docs at python
components: Documentation
messages: 408535
nosy: dam1784, docs at python
priority: normal
severity: normal
status: open
title: Graphlib documentation
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Tue Dec 14 11:17:53 2021
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 14 Dec 2021 16:17:53 +0000
Subject: [New-bugs-announce] [issue46072] Unify handling of stats in the
 CPython VM
Message-ID: <1639498673.65.0.709719181358.issue46072@roundup.psfhosted.org>


New submission from Mark Shannon <mark at hotpy.org>:

By "stats" I mean the internal numbers gathered by the VM for performance and debugging. This has nothing to do with any statistics module.

Currently various parts of the VM gather stats: the GC, dicts, the bytecode interpreter, type lookup cache, etc.

These stats have various compile time flags to turn them on and off. They have differing ways to display the stats, and no unified way to gather stats across different runs.

For the specialization stats we dump stats, which we can parse to collate stats across runs.

We should:
1. Add a --with-pystats config flag (like with-pydebug) to turn on stat gathering at build time.
2. Convert the other stats to the format used by the specialization stats, so all stats can be parsed and collated.

----------
messages: 408543
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: Unify handling of stats in the CPython VM

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

From report at bugs.python.org  Tue Dec 14 11:38:50 2021
From: report at bugs.python.org (Brian Carlson)
Date: Tue, 14 Dec 2021 16:38:50 +0000
Subject: [New-bugs-announce] [issue46073] ast.unparse produces:
 'FunctionDef' object has no attribute 'lineno' for valid module
Message-ID: <1639499930.14.0.345587742085.issue46073@roundup.psfhosted.org>


New submission from Brian Carlson <briancarlson6174 at gmail.com>:

Test file linked. When unparsing the output from ast.parse on a simple class, unparse throws an error: 'FunctionDef' object has no attribute 'lineno' for a valid class and valid AST. It fails when programmatically building the module AST as well.

It seems to be from this function: https://github.com/python/cpython/blob/1cbb88736c32ac30fd530371adf53fe7554be0a5/Lib/ast.py#L790

----------
components: Library (Lib)
files: test.py
messages: 408546
nosy: TheRobotCarlson
priority: normal
severity: normal
status: open
title: ast.unparse produces: 'FunctionDef' object has no attribute 'lineno' for valid module
type: crash
versions: Python 3.10, Python 3.11, Python 3.9
Added file: https://bugs.python.org/file50490/test.py

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

From report at bugs.python.org  Tue Dec 14 11:58:45 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 14 Dec 2021 16:58:45 +0000
Subject: [New-bugs-announce] [issue46074] deepfreeze should rehash all
 strings upon reset
Message-ID: <1639501125.0.0.728137663959.issue46074@roundup.psfhosted.org>


New submission from Guido van Rossum <guido at python.org>:

In https://github.com/python/cpython/pull/30096#discussion_r768802144 it is pointed out that the hash seed can be changed if the interpreter is reset.

To guard against this we need to force (re)calculation of all hash seeds in the generated code when the corresponding code object is retrieved. This can be done by adding extra code to the `_Py_get_<name>_toplevel()` functions. (Strings that are shared between code objects will have to be rehashed repeatedly -- no big deal.)

----------
components: Build
messages: 408550
nosy: gvanrossum
priority: normal
severity: normal
stage: test needed
status: open
title: deepfreeze should rehash all strings upon reset
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Tue Dec 14 16:08:16 2021
From: report at bugs.python.org (Nick)
Date: Tue, 14 Dec 2021 21:08:16 +0000
Subject: [New-bugs-announce] [issue46075] CookieJar.extract_cookies doesn't
 process cookies form local domains when domain is explicitly set in header
Message-ID: <1639516096.67.0.483308979986.issue46075@roundup.psfhosted.org>


New submission from Nick <keddad at yandex.ru>:

Apparently, CookieJar.extract_cookies doesn't process cookies form local domains which explicitly set domain in Set-Cookie header. That means that headers with domain specified, like "Set-Cookie: foo=baz; Domain=localhost;", are ignored. As far as I can tell, this might be actually part of the standard: https://stackoverflow.com/questions/1134290/cookies-on-localhost-with-explicit-domain/32210291#32210291 . However, it looks like other HTTP clients, including modern versions of both Chrome and Firefox do accept cookies from localhost with explicit domain=localhost, and this change doesn't appear to break existing software in any way. (simple POC to test behavior in browsers: https://gist.github.com/keddad/e2ce034f68b77e59077cdb1e887fa4a1). Maybe it would be best to also allow this behavior in Python?

----------
components: Library (Lib)
messages: 408564
nosy: keddad
priority: normal
severity: normal
status: open
title: CookieJar.extract_cookies doesn't process cookies form local domains when domain is explicitly set in header
type: behavior
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Tue Dec 14 17:25:11 2021
From: report at bugs.python.org (Alex Waygood)
Date: Tue, 14 Dec 2021 22:25:11 +0000
Subject: [New-bugs-announce] [issue46076] Document using __slots__ to
 provide per-attribute docstrings
Message-ID: <1639520711.47.0.591169978723.issue46076@roundup.psfhosted.org>


New submission from Alex Waygood <Alex.Waygood at Gmail.com>:

The ability to add docstrings for individual attributes, by using a dictionary for __slots__ was added in Issue36326. This is a fantastic feature, and deserves better documentation. It appears to currently only be documented in the "What's New" entry for Python 3.8: https://docs.python.org/3/whatsnew/3.8.html#inspect.

Moreover, the data model documentation currently states the following regarding using a mapping to specify __slots__:

"""
Any non-string iterable may be assigned to __slots__. Mappings may also be used; however, in the future, special meaning may be assigned to the values corresponding to each key.
"""

This is arguably now incorrect. A special meaning has been assigned to the values corresponding to each key: the values can be used for per-attribute docstrings.

----------
assignee: docs at python
components: Documentation
messages: 408573
nosy: AlexWaygood, docs at python, rhettinger
priority: normal
severity: normal
status: open
title: Document using __slots__ to provide per-attribute docstrings
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Tue Dec 14 20:40:48 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 15 Dec 2021 01:40:48 +0000
Subject: [New-bugs-announce] [issue46077] Include sha256 hashes of release
 downloads in announcement communications
Message-ID: <1639532448.32.0.197660327997.issue46077@roundup.psfhosted.org>


New submission from Gregory P. Smith <greg at krypto.org>:

The announcement email list (https://mail.python.org/archives/list/python-announce-list at python.org/) and other places we make announcements beyond just the release pages like https://www.python.org/downloads/release/python-3101/ should include a list of sha256 hashes of the release binaries in the announcement text.

This serves as an alternative confirmation that nothing has changed as such announcements are widely distributed and archived by independent parties and individuals and can thus convey a level of trust that a hash listed on the downloads page cannot (where an attacker would simply modify both).

Yes there is a gpg signature on the downloads. I encourage people to use that.  But this provides an alternate distributed mechanism to verify that nothing has changed at all since the release announcement.  Something a gpg signature cannot fully do (consider this protection against the possibility of new signed binary being put into its place by a compromised key/signer/builder/RM before anyone happens to notice and poke around).

A simple table of:

filename.tar.gz | sha256 hash
filename.msi | sha256 hash
filename.dmg | sha256 hash
...

At the end of the announcement email/post would suffice.

Less of an issue on source packages as those can be verified against the git repo. But it's nice for people to know if binaries change without an announcement and explanation and is easy for us to provide.

Bonus points if the release announcement email body itself is signed (if that is even feasible per our release signing GPG key management).

[context: see recent python-dev subject: Python release announcement format]

----------
messages: 408579
nosy: gregory.p.smith
priority: deferred blocker
severity: normal
status: open
title: Include sha256 hashes of release downloads in announcement communications
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Tue Dec 14 21:37:47 2021
From: report at bugs.python.org (Samuel Marks)
Date: Wed, 15 Dec 2021 02:37:47 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue46078=5D_=60ast=2Eunparse?=
 =?utf-8?q?=60_fails_on_=60class_C=3A_i=3A_int=60=E2=80=A6_convert_broken_?=
 =?utf-8?q?from_=60ast=2EAnnAssign=60_to_=60ast=2EAssign=60?=
Message-ID: <1639535867.25.0.73298480081.issue46078@roundup.psfhosted.org>


New submission from Samuel Marks <samuelmarks at gmail.com>:

astor fails with:
```
  File "python3.8/site-packages/astor/code_gen.py", line 63, in to_source
    generator.visit(node)
  File "python3.8/site-packages/astor/node_util.py", line 143, in visit
    return visitor(node)
  File "python3.8/site-packages/astor/code_gen.py", line 878, in visit_Module
    self.write(*node.body)
  File "python3.8/site-packages/astor/code_gen.py", line 178, in write
    visit(item)
  File "python3.8/site-packages/astor/node_util.py", line 143, in visit
    return visitor(node)
  File "python3.8/site-packages/astor/code_gen.py", line 364, in visit_ClassDef
    self.body(node.body)
  File "python3.8/site-packages/astor/code_gen.py", line 226, in body
    self.write(*statements)
  File "python3.8/site-packages/astor/code_gen.py", line 178, in write
    visit(item)
  File "python3.8/site-packages/astor/node_util.py", line 143, in visit
    return visitor(node)
  File "python3.8/site-packages/astor/code_gen.py", line 293, in visit_Assign
    self.visit(node.value)
  File "python3.8/site-packages/astor/node_util.py", line 143, in visit
    return visitor(node)
  File "python3.8/site-packages/astor/node_util.py", line 137, in abort_visit
    raise AttributeError(msg % node.__class__.__name__)
AttributeError: No defined handler for node of type NoneType
```

Whereas the now builtin to Python (3.9+) `ast.unparse` gives:
```
File "3.10/lib/python3.10/ast.py", line 1673, in unparse
    return unparser.visit(ast_obj)
  File "3.10/lib/python3.10/ast.py", line 807, in visit
    self.traverse(node)
  File "3.10/lib/python3.10/ast.py", line 798, in traverse
    super().visit(node)
  File "3.10/lib/python3.10/ast.py", line 410, in visit
    return visitor(node)
  File "3.10/lib/python3.10/ast.py", line 822, in visit_Module
    self._write_docstring_and_traverse_body(node)
  File "3.10/lib/python3.10/ast.py", line 815, in _write_docstring_and_traverse_body
    self.traverse(node.body)
  File "3.10/lib/python3.10/ast.py", line 796, in traverse
    self.traverse(item)
  File "3.10/lib/python3.10/ast.py", line 798, in traverse
    super().visit(node)
  File "3.10/lib/python3.10/ast.py", line 410, in visit
    return visitor(node)
  File "3.10/lib/python3.10/ast.py", line 1001, in visit_ClassDef
    self._write_docstring_and_traverse_body(node)
  File "3.10/lib/python3.10/ast.py", line 815, in _write_docstring_and_traverse_body
    self.traverse(node.body)
  File "3.10/lib/python3.10/ast.py", line 796, in traverse
    self.traverse(item)
  File "3.10/lib/python3.10/ast.py", line 798, in traverse
    super().visit(node)
  File "3.10/lib/python3.10/ast.py", line 410, in visit
    return visitor(node)
  File "3.10/lib/python3.10/ast.py", line 863, in visit_Assign
    self.traverse(node.value)
  File "3.10/lib/python3.10/ast.py", line 798, in traverse
    super().visit(node)
  File "3.10/lib/python3.10/ast.py", line 410, in visit
    return visitor(node)
  File "3.10/lib/python3.10/ast.py", line 414, in generic_visit
    for field, value in iter_fields(node):
  File "3.10/lib/python3.10/ast.py", line 252, in iter_fields
    for field in node._fields:
AttributeError: 'NoneType' object has no attribute '_fields'
```

Found it when I tried to unparse previously parsed:
```py
class C:
    i: int
```

Found in reality when trying to parse then emit:
- https://github.com/tensorflow/tensorflow/blob/ba146843/tensorflow/compiler/xla/python/xla_client.py#L402-L413


Which is creating this:
```
ast.Assign(targets=[ast.Name(id="interior_padding")],
           type_comment="int",
           value=None)
```

(one thing my library does is convert betwixt `ast.Assign` and `ast.AnnAssign`? later I'll be doing more interesting variable type tracing to generate big `typing.Union` of all possible types each variable may have? but if it finds `None` then it will infer `typing.Optional`.)

Here is my `ast.NodeTransformer` override for `visit_AnnAssign`: https://github.com/offscale/cdd-python/blob/968507e/cdd/doctrans_utils.py#L111-L131

Is there some way of rewriting an `ast.AnnAssign` to `ast.Assign` without losing type information?

----------
messages: 408580
nosy: samuelmarks
priority: normal
severity: normal
status: open
title: `ast.unparse` fails on `class C: i: int`? convert broken from `ast.AnnAssign` to `ast.Assign`
versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Dec 15 01:10:31 2021
From: report at bugs.python.org (Vivek Vashist)
Date: Wed, 15 Dec 2021 06:10:31 +0000
Subject: [New-bugs-announce] [issue46079] Broken URL in tutorial
Message-ID: <1639548631.13.0.586608874559.issue46079@roundup.psfhosted.org>


New submission from Vivek Vashist <vivekvashist at gmail.com>:

URL: http://tycho.usno.navy.mil/cgi-bin/timer.pl is broken in the example 
https://docs.python.org/3/tutorial/stdlib.html#internet-access

> curl -v http://tycho.usno.navy.mil/cgi-bin/timer.pl
* Could not resolve host: tycho.usno.navy.mil
* Closing connection 0
curl: (6) Could not resolve host: tycho.usno.navy.mil

----------
assignee: docs at python
components: Documentation
messages: 408585
nosy: docs at python, vivekvashist
priority: normal
severity: normal
status: open
title: Broken URL in tutorial
versions: Python 3.10

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

From report at bugs.python.org  Wed Dec 15 01:29:31 2021
From: report at bugs.python.org (Felix Fontein)
Date: Wed, 15 Dec 2021 06:29:31 +0000
Subject: [New-bugs-announce] [issue46080] argparse.BooleanOptionalAction
 with default=argparse.SUPPRESS and help specified crashes
Message-ID: <1639549771.77.0.946249381009.issue46080@roundup.psfhosted.org>


New submission from Felix Fontein <felix at fontein.de>:

When argparse.BooleanOptionalAction is used with default=argparse.SUPPRESS and help is specified, trying to display --help results in a crash.

Reproducer:

import argparse
parser = argparse.ArgumentParser()
parser.add_argument('--test', action=argparse.BooleanOptionalAction, default=argparse.SUPPRESS, help='Foo')
parser.parse_args()

Result when running 'python t.py --help':

Traceback (most recent call last):
  File "/path/to/t.py", line 4, in <module>
    parser.parse_args()
  File "/usr/lib/python3.10/argparse.py", line 1821, in parse_args
    args, argv = self.parse_known_args(args, namespace)
  File "/usr/lib/python3.10/argparse.py", line 1854, in parse_known_args
    namespace, args = self._parse_known_args(args, namespace)
  File "/usr/lib/python3.10/argparse.py", line 2063, in _parse_known_args
    start_index = consume_optional(start_index)
  File "/usr/lib/python3.10/argparse.py", line 2003, in consume_optional
    take_action(action, args, option_string)
  File "/usr/lib/python3.10/argparse.py", line 1931, in take_action
    action(self, namespace, argument_values, option_string)
  File "/usr/lib/python3.10/argparse.py", line 1095, in __call__
    parser.print_help()
  File "/usr/lib/python3.10/argparse.py", line 2551, in print_help
    self._print_message(self.format_help(), file)
  File "/usr/lib/python3.10/argparse.py", line 2535, in format_help
    return formatter.format_help()
  File "/usr/lib/python3.10/argparse.py", line 283, in format_help
    help = self._root_section.format_help()
  File "/usr/lib/python3.10/argparse.py", line 214, in format_help
    item_help = join([func(*args) for func, args in self.items])
  File "/usr/lib/python3.10/argparse.py", line 214, in <listcomp>
    item_help = join([func(*args) for func, args in self.items])
  File "/usr/lib/python3.10/argparse.py", line 214, in format_help
    item_help = join([func(*args) for func, args in self.items])
  File "/usr/lib/python3.10/argparse.py", line 214, in <listcomp>
    item_help = join([func(*args) for func, args in self.items])
  File "/usr/lib/python3.10/argparse.py", line 530, in _format_action
    help_text = self._expand_help(action)
  File "/usr/lib/python3.10/argparse.py", line 627, in _expand_help
    return self._get_help_string(action) % params
KeyError: 'default'

The problem is that in https://github.com/python/cpython/blob/f54fee7f37563fbd569596cf94aad023ac6c3179/Lib/argparse.py#L879, default isn't tested for SUPPRESS as well. I've prepared a patch to fix that and will push it to GitHub soon.

(I've experienced the crash with Python 3.9 and 3.10; the test I've created also crashes for the current main branch, so I guess that means that Python 3.11 is also affected. I haven't tested older Python versions before 3.9.)

----------
components: Library (Lib)
messages: 408586
nosy: felixfontein
priority: normal
severity: normal
status: open
title: argparse.BooleanOptionalAction with default=argparse.SUPPRESS and help specified crashes
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Wed Dec 15 03:38:11 2021
From: report at bugs.python.org (Ram Rachum)
Date: Wed, 15 Dec 2021 08:38:11 +0000
Subject: [New-bugs-announce] [issue46081] Document the msg argument for
 assertRaises
Message-ID: <1639557491.44.0.830591969979.issue46081@roundup.psfhosted.org>


New submission from Ram Rachum <ram at rachum.com>:

The `msg` argument to the `assertRaises` function isn't documented. The documentation should say what this argument does.

----------
assignee: docs at python
components: Documentation
messages: 408587
nosy: cool-RR, docs at python
priority: normal
severity: normal
status: open
title: Document the msg argument for assertRaises
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Dec 15 06:21:17 2021
From: report at bugs.python.org (aziz)
Date: Wed, 15 Dec 2021 11:21:17 +0000
Subject: [New-bugs-announce] [issue46082] type casting of bool
Message-ID: <1639567277.19.0.409904988292.issue46082@roundup.psfhosted.org>


New submission from aziz <p146111 at nu.edu.pk>:

>>> st = "True"
>>> bool(st)
True
>>> st = "False"
>>> bool(st)
True
>>> 
>>> stk = "False"
>>> bool(stk)
True
>>> eval(stk)
False

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 408595
nosy: aziz
priority: normal
severity: normal
status: open
title: type casting of bool
type: enhancement

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

From report at bugs.python.org  Wed Dec 15 09:28:25 2021
From: report at bugs.python.org (Thomas Wouters)
Date: Wed, 15 Dec 2021 14:28:25 +0000
Subject: [New-bugs-announce] [issue46083] PyUnicode_FSConverter() has
 confusing reference semantics
Message-ID: <1639578505.04.0.502075999768.issue46083@roundup.psfhosted.org>


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

The PyUnicode_FSConverter function has confusing reference semantics, and confusing documentation.

https://docs.python.org/3/c-api/unicode.html#c.PyUnicode_FSConverter says the output argument "must be a PyBytesObject* which must be released when it is no longer used." That seems to suggest one must pass a PyBytesObject to it, and indeed one of the error paths assumes an object was passed (https://github.com/python/cpython/blob/main/Objects/unicodeobject.c#L4116-- 'addr' is called 'result' in the docs). Not passing a valid object would result in trying to DECREF NULL, or garbage. However, the function doesn't actually use the object, and later in the function overwrites the value *without* DECREFing it, so passing a valid object would in fact cause a leak.

I understand the function signature is the way it is so it can be used with PyArg_ParseTuple's O& format, but there are reasons to call it directly (e.g. with METH_O functions), and it would be nice if the semantics were more clear.

----------
components: C API
messages: 408604
nosy: twouters
priority: normal
severity: normal
status: open
title: PyUnicode_FSConverter() has confusing reference semantics
versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Dec 15 09:54:30 2021
From: report at bugs.python.org (Jim Schwartz)
Date: Wed, 15 Dec 2021 14:54:30 +0000
Subject: [New-bugs-announce] [issue46084] Python 3.9.6 scan_dir returns
 filenotfound on long paths, but os_walk does not
Message-ID: <1639580070.17.0.621007734089.issue46084@roundup.psfhosted.org>


New submission from Jim Schwartz <jschwar at sbcglobal.net>:

Python 3.9.6 scan_dir returns filenotfound on long paths, but os_walk does not.  I've enclosed sample scripts that compare the two and have returned the results.  the windows 10 registry entry to extend the path names fixes this issue (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled set to 1).  I've enclosed a scripts that proved this occurs and can be used for testing. I have a script that does the same thing using os_walk, but I can't attach two scripts to this Issue.

----------
components: IO, Tests, Windows
files: test_dir_scan_dir.py
messages: 408607
nosy: jschwar313, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python 3.9.6 scan_dir returns filenotfound on long paths, but os_walk does not
type: crash
versions: Python 3.9
Added file: https://bugs.python.org/file50492/test_dir_scan_dir.py

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

From report at bugs.python.org  Wed Dec 15 11:48:00 2021
From: report at bugs.python.org (Kevin Shweh)
Date: Wed, 15 Dec 2021 16:48:00 +0000
Subject: [New-bugs-announce] [issue46085] OrderedDict iterator allocates
 di_result unnecessarily
Message-ID: <1639586880.61.0.695571105446.issue46085@roundup.psfhosted.org>


New submission from Kevin Shweh <kevin.shweh at gmail.com>:

The OrderedDict iterator caches a di_result tuple for use with iter(od.items()). It's *supposed* to only do that for the items() case, but the code does

    if (kind & (_odict_ITER_KEYS | _odict_ITER_VALUES))

to test for this case. This is the wrong test. It should be

    if ((kind & _odict_ITER_KEYS) && (kind &_odict_ITER_VALUES))

The current test allocates di_result for key and value iterators as well as items iterators.

----------
components: Library (Lib)
messages: 408616
nosy: Kevin Shweh
priority: normal
severity: normal
status: open
title: OrderedDict iterator allocates di_result unnecessarily
type: resource usage
versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Dec 15 12:37:14 2021
From: report at bugs.python.org (Giacomo)
Date: Wed, 15 Dec 2021 17:37:14 +0000
Subject: [New-bugs-announce] [issue46086] Add ratio_min() function to the
 difflib library
Message-ID: <1639589834.45.0.869314940446.issue46086@roundup.psfhosted.org>


New submission from Giacomo <baldogiacomophd at gmail.com>:

Here I propose a new function, namely .ratio_min(self,m). 

.ratio_min(self,m) is an extension of the difflib's function .ratio(self). Equivalently to .ratio(self), .ratio_min(self,m) returns a measure of two sequences' similarity (float in [0,1]). In addition to .ratio(), it can ignore matched substrings if these substrings have length less than a given threshold m. m is the second variable of the function. 

It is very useful to avoid spurious high similarity scores. 

    # NEW FUNCTION: 

    def ratio_min(self,m):
        """Return a measure of the sequences' similarity (float in [0,1]).
        Where T is the total number of elements in both sequences, and
        M_min is the number of matches with every single match has length at least m, this is 2.0*M_min / T.
        Note that this is 1 if the sequences are identical, and 0 if
        they have no substring of length m or more in common.
        .ratio_min() is similar to .ratio(). 
        .ratio_min(1) is equivalent to .ratio().
        
        >>> s = SequenceMatcher(None, "abcd", "bcde")
        >>> s.ratio_min(1)
        0.75
        >>> s.ratio_min(2)
        0.75
        >>> s.ratio_min(3)
        0.75
        >>> s.ratio_min(4)
        0.0
        """

        matches = sum(triple[-1] for triple in self.get_matching_blocks() if triple[-1] >=m)
        return _calculate_ratio(matches, len(self.a) + len(self.b))

----------
components: Library (Lib)
messages: 408622
nosy: gibu
priority: normal
severity: normal
status: open
title: Add ratio_min() function to the difflib library
type: enhancement
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Wed Dec 15 12:48:58 2021
From: report at bugs.python.org (Arthur Milchior)
Date: Wed, 15 Dec 2021 17:48:58 +0000
Subject: [New-bugs-announce] [issue46087] Zip library documentation error
Message-ID: <1639590538.75.0.882210215696.issue46087@roundup.psfhosted.org>


New submission from Arthur Milchior <arthur at milchior.fr>:

I don't have permission to assign the issue, but I intend to post the change in a few minutes as a PR

Copied from Richard Hyde's email to doc mailing list.

One of the examples of string formatting doesn't work. This applies to prior versions of Python as well.

The last set of the examples headed: 'Nesting arguments and more complex examples:' starts with the following code:

>>> for align, text in zip('<^>', ['left', 'center', 'right']):
...     '{0:{fill}{align}16}'.format(text, fill=align, align=align)
...

This omits print()
The correct code would be:

>>> for align, text in zip('<^>', ['left', 'center', 'right']):
...     print('{0:{fill}{align}16}'.format(text, fill=align, align=align))
...



-----------------------------------------------

I agree with Richard here that there is a problem. Most example don't use print, but since there is no returned expression, that's the most relevant way to express the meaning of the example. Adding an expression would just make things more complex.

Bug introducde in 28fbea412819f90698527c1997ece5aeddf8e9a7 in 2010.

----------
assignee: docs at python
components: Documentation
messages: 408624
nosy: Arthur-Milchior, docs at python
priority: normal
severity: normal
status: open
title: Zip library documentation error
type: behavior
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Dec 15 14:07:01 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 15 Dec 2021 19:07:01 +0000
Subject: [New-bugs-announce] [issue46088] Build hangs under Visual Studio in
 deepfreeze stage
Message-ID: <1639595221.47.0.522675592351.issue46088@roundup.psfhosted.org>


New submission from Guido van Rossum <guido at python.org>:

I am trying to build under Visual Studio (the 2019 release) and I'm encountering the following weird issue. In the project file PCbuild\_freeze_module.vcxproj there's a command that runs the Tools\scripts\deepfreeze.py script to generate some code.

The invocation is as follows:

    <Exec Command='$(PythonForBuild) "$(PySourcePath)Tools\scripts\deepfreeze.py" "%(None.OutFile)" "-m" "%(None.ModName)" -o "%(None.IntFile)"' />

Apparently the PythonForBuild variable is unset, because this steps is trying to *open* the deepfreeze.py script using the default app for opening .py files, which in my case is VS Code.

It seems that when using PCbuild\build.bat, PythonForBuild is set (on line 121) to %PYTHON%, which presumably points to some Python interpreter. But apparently when the build is driven by VS, this is not executed and now we're stuck.

Is there someone with enough MSBUILD skills to help me fix this?

----------
components: Build, Windows
messages: 408635
nosy: gvanrossum, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Build hangs under Visual Studio in deepfreeze stage
type: compile error
versions: Python 3.11

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

From report at bugs.python.org  Wed Dec 15 14:29:43 2021
From: report at bugs.python.org (G. Allard)
Date: Wed, 15 Dec 2021 19:29:43 +0000
Subject: [New-bugs-announce] [issue46089] Problems with AF_PACKET sockets
Message-ID: <1639596583.53.0.533566052583.issue46089@roundup.psfhosted.org>


New submission from G. Allard <gallard at mmic.net>:

For educational purposes, I'm developing my own IP stack in Python. It's going well but I'm stuck at a low level.
I need to implement the following (simple) task:
- open an AF_PACKET socket (socket.socket)
- bind it to a specific interface (socket.bind)
Python code would look like this:
- sock = socket.socket( socket.AF_PACKET, socket.SOCK_RAW, socket.htons( ETH_P_ALL))
- sock.setblocking( False)
- sock.bind(( 'eth0', socket.htons( ETH_P_ALL)))
It does not work. bind always return "TypeError: AF_PACKET address must be a tuple of two to five elements"
I spent many days on that problem. No success.

Desperate, I tried to verify it wasn't a kernel problem. I wrote the C version of the above snippet. 
- sock = socket( AF_PACKET, SOCK_RAW | SOCK_NONBLOCK, htons( 3));
- struct sockaddr_ll addr = {0};
  addr.sll_family = AF_PACKET;
  addr.sll_ifindex = 2;  /* index of 'eth0' */
  addr.sll_protocol = htons( ETH_P_ALL);
- bind( sock, (struct sockaddr*) &addr, sizeof( addr));
I'm not an expert in C programming but it worked on first try.

First problem is that AF_PACKET sockets are broken in Python.

Second problem is inadequate documentation.
Following issue ID 25041, some documentation has been added but there is still lot of room for improvements.
For example:
- recvfrom return 2 values. The first is the binary packet and the second one is a 5 member structure. The first member of the structure is the interface name. The 5th member if the MAC address (assuming the interface is an Ethernet NIC). The 3rd one is a protocol number (the data-link protocol) whose data is in front of the returnet packet (for WiFi packets, we will see Radiotap protocol at that level).
That's a whole new world for documentors.

- socket.bind() parameter is documented to be an address. For AF_PACKET, the address is documented in "Socket Families" section. Definition is vague. The 'proto' description would be easier to understand with "An integer (in network-byte-order) representing the low level protocol (enumerated in linux/if_ether.h) or ETH_P_ALL for all protocols. This parameter is only used for filtering inbound packets."
IMO 'pkttype', 'hatype', 'addr' are there to document the information returned by recvfrom(). It's written they are "optional" but I think it's not correct.

- Working examples of AF_PACKET must be provided, possibly in a HOWTO.

When it's easier to program in C, it should tell you there is a problem on Python side.

----------
assignee: docs at python
components: Documentation
messages: 408638
nosy: docs at python, gallard
priority: normal
severity: normal
status: open
title: Problems with AF_PACKET sockets
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Wed Dec 15 15:55:31 2021
From: report at bugs.python.org (Brandt Bucher)
Date: Wed, 15 Dec 2021 20:55:31 +0000
Subject: [New-bugs-announce] [issue46090] C extensions can't swap out live
 frames anymore
Message-ID: <1639601731.02.0.904150269203.issue46090@roundup.psfhosted.org>


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

I'm specifically concerned about Greenlet here (since it's a dependency of pyperformance), but this discussion is equally relevant to any library like it that dynamically swaps out the currently executing frame.

CPython 3.11 makes several major changes to how frame objects are used and represented internally:

- bpo-44032: Move data stack to thread from FrameObject. (https://github.com/python/cpython/pull/26076)
- bpo-44590: Lazily allocate frame objects (https://github.com/python/cpython/pull/27077)
- bpo-45637: Store the frame pointer in the cframe (https://github.com/python/cpython/pull/29267)

These changes break Greenlet's hot-swapping of frame objects (https://github.com/python-greenlet/greenlet/blob/be41e1a24925326b72a02ef5cb6d1ed9643eb062/src/greenlet/greenlet_greenlet.hpp#L768-L811) in a pretty serious way, and it's not immediately clear what the best fix is. A fairly high-level overview of the new design:

When a frame is executing, the current thread state points to the current CFrame, which itself points to a C-level InterpreterFrame. This interpreter frame is located within a "data stack" that is managed by the thread state. If a PyFrameObject for the currently executing frame is requested (using PyThreadState_GetFrame), the new PyFrameObject points into the InterpreterFrame, where all of the important data is still stored. So far so good.

The issue is what happens next. If the InterpreterFrame is replaced, or exits in any way, its memory may be reused, or even freed entirely. The PyFrameObject is smart enough to copy the data elsewhere (into itself) when this happens, but the new design means that there is no obvious way for a third-party library to "reactivate" a frame in a way analogous to assigning to the old tstate->frame member.

While I'm pretty sure that we don't officially support this "feature", it's probably used often enough that we should at least brainstorm a workaround (if not an unstable C-API function) for affected projects. I suspect that a potential solution likely involves creating an entirely new InterpreterFrame the normal way, and copying the PyFrameObject's InterpreterFrame data into it? Not sure what would happen if the old InterpreterFrame was still alive on the data stack, though...

In any case, it probably makes sense to discuss here with affected library maintainers.

----------
assignee: brandtbucher
components: Interpreter Core
messages: 408646
nosy: Mark.Shannon, brandtbucher, gvanrossum, pablogsal
priority: normal
severity: normal
status: open
title: C extensions can't swap out live frames anymore
versions: Python 3.11

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

From report at bugs.python.org  Wed Dec 15 18:06:30 2021
From: report at bugs.python.org (Jeremy)
Date: Wed, 15 Dec 2021 23:06:30 +0000
Subject: [New-bugs-announce] [issue46091] IndendationError from multi-line
 indented statements
Message-ID: <1639609590.75.0.562177749036.issue46091@roundup.psfhosted.org>


New submission from Jeremy <ucodery at gmail.com>:

At some point in 3.9 Python appears to have stopped accepting source that starts with an indent, then a '\', then the indented statement. From the lexical analysis [1] "Indentation cannot be split over multiple physical lines using backslashes; the whitespace up to the first backslash determines the indentation."

Running the attached program under 3.8.12 I get:
```
0 1 1 2 3 5 8 13 21 34 55 89 144 233 377
```

But running under 3.10.0 I get:
```
  File "/Users/jeremyp/tmp/nodent.py", line 3
    """Print a Fibonacci series up to n."""
    ^
IndentationError: expected an indented block after function definition on line 1
```

Running under 3.9.9 also gives an IndentationError, both with and without -X oldparser. So this doesn't seem directly related to the new parser, but seems likely it is fall out from the general grammar restructuring.

IMHO it isn't a particularly nice feature for the language to have. Especially since not all lines like '    \' behave the same. But it was there and documented for many years, so should probably be put back. Does a core developer agree? That the implementation is not following the spec?

[1]: https://docs.python.org/3/reference/lexical_analysis.html#indentation

----------
components: Parser
files: nodent.py
messages: 408651
nosy: lys.nikolaou, pablogsal, ucodery
priority: normal
severity: normal
status: open
title: IndendationError from multi-line indented statements
versions: Python 3.10, Python 3.11, Python 3.9
Added file: https://bugs.python.org/file50496/nodent.py

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

From report at bugs.python.org  Wed Dec 15 18:27:12 2021
From: report at bugs.python.org (Vivek Vashist)
Date: Wed, 15 Dec 2021 23:27:12 +0000
Subject: [New-bugs-announce] [issue46092] Fix/update missing parameters in
 function signatures for Built-in Functions documentation.
Message-ID: <1639610832.29.0.673265280888.issue46092@roundup.psfhosted.org>


New submission from Vivek Vashist <vivekvashist at gmail.com>:

Previous issue:

https://github.com/python/cpython/pull/30113#issuecomment-994642493

As noted/pointed by Alex - I went through all the Built-in Functions and updated/fixed the missing parameters.

I'll raise a PR shortly.

----------
assignee: docs at python
components: Documentation
messages: 408653
nosy: docs at python, vivekvashist
priority: normal
severity: normal
status: open
title: Fix/update missing parameters in function signatures for Built-in Functions documentation.
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Thu Dec 16 00:16:24 2021
From: report at bugs.python.org (Ritvik S)
Date: Thu, 16 Dec 2021 05:16:24 +0000
Subject: [New-bugs-announce] [issue46093] 2D array issue
Message-ID: <1639631784.52.0.780624744558.issue46093@roundup.psfhosted.org>


New submission from Ritvik S <ritviksetty at gmail.com>:

I had a problem running the following code. When I ran through what I thought python was supposed to do, I got a different answer than what python did. I think this is an error. Here is the code:



problem_ary = [['a','b','c'],['d','e','f'],['g','h','i']]
normal_ary = ['a','b','c']

print(normal_ary[:]) #should print ['a','b','c']
print(problem_ary[:][1])



The second output should be ['b','e','h'] since the print statement tells python to take [0][1],[1][1], and [2][1] from the problem_ary which is 'b','e','h'. It confused me when python instead returned ['d','e','f']. I came across this problem when I was trying to create tic-tac-toe in python. I tried coding this is Python 3.8, 3.9, and using an online interpreter, and I got the same result every time.

----------
files: 2D-Array-Problem.py
messages: 408671
nosy: ritviksetty
priority: normal
severity: normal
status: open
title: 2D array issue
type: behavior
versions: Python 3.8, Python 3.9
Added file: https://bugs.python.org/file50498/2D-Array-Problem.py

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

From report at bugs.python.org  Thu Dec 16 01:46:05 2021
From: report at bugs.python.org (dhruv)
Date: Thu, 16 Dec 2021 06:46:05 +0000
Subject: [New-bugs-announce] [issue46094] Missing unit test on
 unittest.TestResult to check for required arguments
Message-ID: <1639637165.39.0.102854010232.issue46094@roundup.psfhosted.org>


New submission from dhruv <kapoor_1992 at hotmail.com>:

stream, descriptions, and verbosity seem like they aren't needed at first glance but are required to work with multiple inheritance. A simple test can clarify this.

----------
components: Tests
messages: 408674
nosy: DreamSh0t
priority: normal
severity: normal
status: open
title: Missing unit test on unittest.TestResult to check for required arguments
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Thu Dec 16 04:48:01 2021
From: report at bugs.python.org (=?utf-8?q?Ture_P=C3=A5lsson?=)
Date: Thu, 16 Dec 2021 09:48:01 +0000
Subject: [New-bugs-announce] [issue46095] Warning about iterate/modify has
 unwarranted detail
Message-ID: <1639648081.19.0.0569018631816.issue46095@roundup.psfhosted.org>


New submission from Ture P?lsson <ture at turepalsson.se>:

The language reference about the 'for' statement (https://docs.python.org/3/reference/compound_stmts.html#the-for-statement) has a "Note" box that states that the for statement uses an "internal counter" which is "incremented", and goes into detail about what happens when modifications happen before or after the current loop position. Surely this depends on the underlying iterator? For example, with a balanced tree an insert or a delete could completely re-jigger the tree with hard-to-predict results on an iterator.

----------
assignee: docs at python
components: Documentation
messages: 408680
nosy: docs at python, turepalsson
priority: normal
severity: normal
status: open
title: Warning about iterate/modify has unwarranted detail
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Thu Dec 16 05:33:14 2021
From: report at bugs.python.org (Dmitry)
Date: Thu, 16 Dec 2021 10:33:14 +0000
Subject: [New-bugs-announce] [issue46096] Support PyObject interface for
 global variables in local scope and debugger
Message-ID: <1639650794.38.0.196898311549.issue46096@roundup.psfhosted.org>


New submission from Dmitry <Dmitry_Zhamoytsin at mentor.com>:

We use the embedded Python in a multiscript environment. For example, VBS can execute Python code and vice versa. 

For that purpose we use a global context which is common for all running scripts (Python, VBS etc.) and control access to variables in that context by PyObject interface. 

But we faced with an issue:

1) Setting/deleting global variables in local scope are done outside of our control (without using PyObject interface).

2) A debugger (LOAD_NAME tag) does not see global variables in local scope.

We would like to fix that issue by adding a check for exact PyDict (PyDict_CheckExact) in STORE_GLOBAL, DELETE_GLOBAL and LOAD_NAME tags in ceval.c. 
If a global dictionary is redefined then use PyObject interface instead of direct PyDict one.

----------
components: Interpreter Core
hgrepos: 412
messages: 408684
nosy: dzhamoytsin
priority: normal
severity: normal
status: open
title: Support PyObject interface for global variables in local scope and debugger
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Thu Dec 16 06:06:10 2021
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 16 Dec 2021 11:06:10 +0000
Subject: [New-bugs-announce] [issue46097] Split function versions into
 1-0xffff and 0x1000+ regions
Message-ID: <1639652770.25.0.708221453944.issue46097@roundup.psfhosted.org>


New submission from Mark Shannon <mark at hotpy.org>:

Because functions are mutable, specifically because the __code__ attribute is mutable, we need to version functions when specializing.

However, some specializations (for special methods mainly) only have space for 16 bit versions.

It is likely that programs will have more than 2**16 functions versions, but it is much less likely that they will have more than 2**16 versions of special methods.

We should partition the version space into 1-0xffff for use by special methods and 0x1000+ for use by other methods.

See https://github.com/python/cpython/pull/30129 for an example of why this is needed.

----------
components: Interpreter Core
messages: 408686
nosy: Mark.Shannon, brandtbucher
priority: normal
severity: normal
status: open
title: Split function versions into 1-0xffff and 0x1000+ regions
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Thu Dec 16 06:28:49 2021
From: report at bugs.python.org (Irit Katriel)
Date: Thu, 16 Dec 2021 11:28:49 +0000
Subject: [New-bugs-announce] [issue46098] Missing test for multi-line errors
 in traceback
Message-ID: <1639654129.22.0.790505803608.issue46098@roundup.psfhosted.org>


New submission from Irit Katriel <iritkatriel at gmail.com>:

While reviewing a change nearby, Erlend noticed that there is no test coverage for the multi-line error case in the traceback printing code added in bpo-43914.

See https://github.com/python/cpython/pull/30073#discussion_r770114429

----------
messages: 408688
nosy: erlendaasland, iritkatriel, pablogsal
priority: normal
severity: normal
status: open
title: Missing test for multi-line errors in traceback
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Thu Dec 16 06:54:02 2021
From: report at bugs.python.org (Jakub Kulik)
Date: Thu, 16 Dec 2021 11:54:02 +0000
Subject: [New-bugs-announce] [issue46099] Solaris: Fix pthread_getcpuclockid
 test
Message-ID: <1639655642.85.0.652795317343.issue46099@roundup.psfhosted.org>


New submission from Jakub Kulik <jakub.kulik at oracle.com>:

On Solaris, when `pthread_getcpuclockid()` is called with current thread id as an argument, it returns `CLOCK_THREAD_CPUTIME_ID`.

======================================================================
FAIL: test_pthread_getcpuclockid (test.test_time.TimeTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/share/buildbot-worker/default/3.9.kulikjak-solaris-sparcv9/build/Lib/test/test_time.py", line 116, in test_pthread_getcpuclockid
    self.assertNotEqual(clk_id, time.CLOCK_THREAD_CPUTIME_ID)
AssertionError: 2 == 2

Based on the test code, 32bit AIX seems to do the same thing so I added another similar code for Solaris.

----------
components: Tests
messages: 408694
nosy: kulikjak
priority: normal
severity: normal
status: open
title: Solaris: Fix pthread_getcpuclockid test
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Thu Dec 16 07:37:48 2021
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 16 Dec 2021 12:37:48 +0000
Subject: [New-bugs-announce] [issue46100] Simplify readline / editline
 detection
Message-ID: <1639658268.15.0.0477908867569.issue46100@roundup.psfhosted.org>


New submission from Christian Heimes <lists at cheimes.de>:

The configure.ac code for editline/readline detection is complicated. Especially the code for linking with extra termcap libraries makes it complicated to port the check to pkg-config. The termcap checks were added by Greg in bpo-3645 and commit 188209465a966cf046ed7946589aa21767f95e68 .

I propose to simplify the checks and require a readline 4.2 compatible API. GNU readline was released in 2001 (20 years ago). NetBSD libedit editline/readline.h has RL_READLINE_VERSION 0x0402 for at least 10 years.

* drop the check for additional termcap libs
* remove the fallback to completion_matches
* replace AC_CHECK_LIB($LIBREADLINE, ...) checks with a check for RL_READLINE_VERSION >= 0x0402

What do you think?

----------
components: Build
messages: 408700
nosy: christian.heimes, erlendaasland, gregory.p.smith
priority: normal
severity: normal
status: open
title: Simplify readline / editline detection
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Thu Dec 16 10:29:06 2021
From: report at bugs.python.org (Lucas Cimon)
Date: Thu, 16 Dec 2021 15:29:06 +0000
Subject: [New-bugs-announce] [issue46101] argparse: using parents &
 subcommands, options can be ignored
Message-ID: <1639668546.2.0.488904720024.issue46101@roundup.psfhosted.org>


New submission from Lucas Cimon <lucas.cimon at gmail.com>:

Hi!

Here is some minimal code reproducing the issue:

    import argparse

    common_opts_parser = argparse.ArgumentParser(add_help=False)
    common_opts_parser.add_argument("--endpoint", choices=("prod", "dev"), default="dev")

    parser = argparse.ArgumentParser(parents=[common_opts_parser])
    subparsers = parser.add_subparsers(required=True)

    subcmd_cmd = subparsers.add_parser("subcmd", parents=[common_opts_parser])
    subcmd_cmd.add_argument("--debug", action="store_true")

    print(parser.parse_args())

Everything works fine / as expected when specifying the common optional arg last:

    $ ./bug_repro.py subcmd --endpoint=dev
    Namespace(endpoint='dev', debug=False)

However when specifying the --endpoint between the program and the subcommand, the value provided is ignored:

    $ ./bug_repro.py --endpoint=dev subcmd
    Namespace(endpoint=None, debug=False)

I have a PR ready to fix that.

----------
components: Library (Lib)
messages: 408711
nosy: Lucas Cimon
priority: normal
severity: normal
status: open
title: argparse: using parents & subcommands, options can be ignored
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Thu Dec 16 10:36:42 2021
From: report at bugs.python.org (Aidas Petryla)
Date: Thu, 16 Dec 2021 15:36:42 +0000
Subject: [New-bugs-announce] [issue46102] pdb can't convert dict_values to
 list
Message-ID: <1639669002.59.0.612026213531.issue46102@roundup.psfhosted.org>


New submission from Aidas Petryla <apetryla at redhat.com>:

Reproducing:

Running pdb shell (for example "python -m pdb <some_file.py>"

Input:
x = {'a': 1}
list(x.values())

Output:
*** Error in argument: '(x.values())'

----------
messages: 408714
nosy: apetryla
priority: normal
severity: normal
status: open
title: pdb can't convert dict_values to list
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Thu Dec 16 10:40:43 2021
From: report at bugs.python.org (hongweipeng)
Date: Thu, 16 Dec 2021 15:40:43 +0000
Subject: [New-bugs-announce] [issue46103] inspect.getmembers will call the
 instance __bases__ attribute, which may cause an exception
Message-ID: <1639669243.89.0.636826061264.issue46103@roundup.psfhosted.org>


New submission from hongweipeng <hongweichen8888 at sina.com>:

root at debian:/workspace/cpython# ./python
Python 3.11.0a3+ (heads/main-dirty:b123ad8030, Dec 16 2021, 06:16:15) [GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import inspect
>>> class Foo:
...   def __getattr__(self, attr):
...     return None
... 
>>> inspect.getmembers(Foo())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/workspace/cpython/Lib/inspect.py", line 488, in getmembers
    return _getmembers(object, predicate, getattr)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/workspace/cpython/Lib/inspect.py", line 455, in _getmembers
    for base in object.__bases__:
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: 'NoneType' object is not iterable

----------
components: Library (Lib)
messages: 408717
nosy: hongweipeng
priority: normal
severity: normal
status: open
title: inspect.getmembers will call the instance __bases__ attribute, which may cause an exception
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Thu Dec 16 11:23:54 2021
From: report at bugs.python.org (Alex Waygood)
Date: Thu, 16 Dec 2021 16:23:54 +0000
Subject: [New-bugs-announce] [issue46104] Reduce use of old-style syntax in
 typing docs
Message-ID: <1639671834.7.0.734699107107.issue46104@roundup.psfhosted.org>


New submission from Alex Waygood <Alex.Waygood at Gmail.com>:

There are a few places in the typing docs where old-style (pre-PEP 526) syntax is used in examples. It doesn't look like these examples have been updated since 2016; it would be good to change them so that they use the newer syntax introduced in PEP 526.

----------
assignee: docs at python
components: Documentation
messages: 408721
nosy: AlexWaygood, docs at python, gvanrossum, kj
priority: normal
severity: normal
status: open
title: Reduce use of old-style syntax in typing docs
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Thu Dec 16 14:14:18 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 16 Dec 2021 19:14:18 +0000
Subject: [New-bugs-announce] [issue46105] Requirement syntax broken when
 extras indicated on url_req
Message-ID: <1639682058.29.0.323171575702.issue46105@roundup.psfhosted.org>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

In https://github.com/python/importlib_metadata/issues/357, a user reported an issue where a requirement generated by importlib.metadata from egg info metadata would result in a parse error attempting to parse the error. A fix was released in importlib_metadata 4.8.3.

----------
assignee: jaraco
messages: 408727
nosy: jaraco
priority: normal
severity: normal
status: open
title: Requirement syntax broken when extras indicated on url_req
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Thu Dec 16 15:22:02 2021
From: report at bugs.python.org (Ned Deily)
Date: Thu, 16 Dec 2021 20:22:02 +0000
Subject: [New-bugs-announce] [issue46106] OpenSSL 1.1.1m is now available
Message-ID: <1639686122.34.0.476872418462.issue46106@roundup.psfhosted.org>


New submission from Ned Deily <nad at python.org>:

Update Windows build, macOS installer, and Tools/multissltests.py

----------
components: Build, Windows, macOS
messages: 408736
nosy: christian.heimes, ned.deily, paul.moore, ronaldoussoren, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: OpenSSL 1.1.1m is now available
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Thu Dec 16 17:36:49 2021
From: report at bugs.python.org (Irit Katriel)
Date: Thu, 16 Dec 2021 22:36:49 +0000
Subject: [New-bugs-announce] [issue46107] ExceptionGroup.split()/subgroup()
 don't copy __note__ to parts
Message-ID: <1639694209.93.0.209402666532.issue46107@roundup.psfhosted.org>


New submission from Irit Katriel <iritkatriel at gmail.com>:

>>> e = ExceptionGroup("eg", [ValueError(1), TypeError(2)])
>>> e.__note__ = "a note"
>>> e.split(ValueError)
(ExceptionGroup('eg', [ValueError(1)]), ExceptionGroup('eg', [TypeError(2)]))
>>> e.split(ValueError)[0].__note__
>>> e.subgroup(ValueError).__note__

----------
components: Interpreter Core
messages: 408740
nosy: iritkatriel
priority: normal
severity: normal
status: open
title: ExceptionGroup.split()/subgroup() don't copy __note__ to parts
versions: Python 3.11

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

From report at bugs.python.org  Thu Dec 16 20:13:16 2021
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 17 Dec 2021 01:13:16 +0000
Subject: [New-bugs-announce] [issue46108] Enum repr() incorrect when mixed
 with dataclasses
Message-ID: <1639703596.51.0.989960862505.issue46108@roundup.psfhosted.org>


New submission from Ethan Furman <ethan at stoneleaf.us>:

from dataclasses import dataclass
from enum import Enum

@dataclass
class Foo:
    a: int = 0

class Entries(Foo, Enum):
    ENTRY1 = Foo(1)

repr(Entries.ENTRY1) != '<Entries.ENTRY1: Foo(a=1)>'

----------
assignee: ethan.furman
messages: 408748
nosy: ethan.furman
priority: normal
severity: normal
status: open
title: Enum repr() incorrect when mixed with dataclasses
versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Dec 16 21:10:06 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 17 Dec 2021 02:10:06 +0000
Subject: [New-bugs-announce] [issue46109] Separate resources and abc docs
 from other importlib docs
Message-ID: <1639707006.6.0.710997331931.issue46109@roundup.psfhosted.org>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

The `importlib` documentation is fairly long and covers a number of topics. Furthermore, the `importlib.metadata` is separately documented and presents a good example of breaking out major aspects. Let's do the same with `.abc` and `.resources`.

----------
assignee: jaraco
components: Documentation
messages: 408749
nosy: jaraco
priority: normal
severity: normal
status: open
title: Separate resources and abc docs from other importlib docs
versions: Python 3.11

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

From report at bugs.python.org  Fri Dec 17 00:22:07 2021
From: report at bugs.python.org (Charles McMarrow)
Date: Fri, 17 Dec 2021 05:22:07 +0000
Subject: [New-bugs-announce] [issue46110] `eval("-"*3000000 + "4")` in cmd
 causes hard crash
Message-ID: <1639718527.05.0.162787916832.issue46110@roundup.psfhosted.org>


New submission from Charles McMarrow <charles.mcmarrow.4 at gmail.com>:

`eval("-"*3000000 + "4")` in cmd causes hard crash

----------
components: Parser
messages: 408753
nosy: charles.mcmarrow.4, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: `eval("-"*3000000 + "4")` in cmd causes hard crash
type: crash
versions: Python 3.10

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

From report at bugs.python.org  Fri Dec 17 02:43:08 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 17 Dec 2021 07:43:08 +0000
Subject: [New-bugs-announce] [issue46111] test_unittest fails in optimized
 mode
Message-ID: <1639726988.61.0.440638905224.issue46111@roundup.psfhosted.org>


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

$ ./python -OO -m test -vuall test_unittest
...
======================================================================
FAIL: testShortDescriptionWhitespaceTrimming (unittest.test.test_case.Test_TestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/unittest/test/test_case.py", line 639, in testShortDescriptionWhitespaceTrimming
    self.assertEqual(
    ^^^^^^^^^^^^^^^^^
AssertionError: None != 'Tests shortDescription() whitespace is trimmed, so that the first'

======================================================================
FAIL: test_Exit (unittest.test.test_program.Test_TestProgram)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/unittest/test/test_program.py", line 127, in test_Exit
    self.assertIn('\nFAIL: testFail ', stream.getvalue())
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: '\nFAIL: testFail ' not found in '..\n----------------------------------------------------------------------\nRan 2 tests in 0.000s\n\nOK\n'

======================================================================
FAIL: test_ExitAsDefault (unittest.test.test_program.Test_TestProgram)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/unittest/test/test_program.py", line 139, in test_ExitAsDefault
    self.assertIn('\nFAIL: testFail ', stream.getvalue())
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: '\nFAIL: testFail ' not found in '..\n----------------------------------------------------------------------\nRan 2 tests in 0.000s\n\nOK\n'

======================================================================
FAIL: test_NonExit (unittest.test.test_program.Test_TestProgram)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/unittest/test/test_program.py", line 114, in test_NonExit
    self.assertIn('\nFAIL: testFail ', stream.getvalue())
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: '\nFAIL: testFail ' not found in '..\n----------------------------------------------------------------------\nRan 2 tests in 0.000s\n\nOK\n'

======================================================================
FAIL: test_special_attrs (unittest.test.testmock.testpatch.PatchTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/unittest/test/testmock/testpatch.py", line 1880, in test_special_attrs
    self.assertEqual(foo.__doc__, "TEST")
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: None != 'TEST'

----------------------------------------------------------------------

----------
assignee: serhiy.storchaka
components: Tests
messages: 408755
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: test_unittest fails in optimized mode
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Fri Dec 17 04:18:00 2021
From: report at bugs.python.org (Zhiyuan Chen)
Date: Fri, 17 Dec 2021 09:18:00 +0000
Subject: [New-bugs-announce] [issue46112] PEP 8 code format
Message-ID: <1639732680.85.0.32086966085.issue46112@roundup.psfhosted.org>


New submission from Zhiyuan Chen <this at zyc.ai>:

Current cpython code base still contains a massive amount of code that is not complied with the PEP-8 formatting. 
For example, there are 553 one line if statement (`if xxx: yyy`) in the current codebase.

----------
files: onelineif.txt
messages: 408761
nosy: ZhiyuanChen
priority: normal
severity: normal
status: open
title: PEP 8 code format
type: enhancement
Added file: https://bugs.python.org/file50499/onelineif.txt

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

From report at bugs.python.org  Fri Dec 17 05:09:39 2021
From: report at bugs.python.org (Vivek Vashist)
Date: Fri, 17 Dec 2021 10:09:39 +0000
Subject: [New-bugs-announce] [issue46113] Typos and minor fixes in built in
 types documentation
Message-ID: <1639735779.26.0.586060935342.issue46113@roundup.psfhosted.org>


New submission from Vivek Vashist <vivekvashist at gmail.com>:

Will raise a PR shortly.

----------
assignee: docs at python
components: Documentation
messages: 408766
nosy: docs at python, vivekvashist
priority: normal
severity: normal
status: open
title: Typos and minor fixes in built in types documentation
versions: Python 3.10

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

From report at bugs.python.org  Fri Dec 17 05:51:19 2021
From: report at bugs.python.org (Alexey Stepanov)
Date: Fri, 17 Dec 2021 10:51:19 +0000
Subject: [New-bugs-announce] [issue46114] OpenSSL deprecated
 OpenSSL_version_num() since version 3.0.0
Message-ID: <1639738279.91.0.163233406525.issue46114@roundup.psfhosted.org>


New submission from Alexey Stepanov <penguinolog at gmail.com>:

Documentation: https://www.openssl.org/docs/manmaster/man3/OpenSSL_version_num.html

Python build fail with OpenSSL 3.0.1
(looks like OpenSSL broken deprecated API)

----------
assignee: christian.heimes
components: SSL
messages: 408770
nosy: christian.heimes, penguinolog
priority: normal
severity: normal
status: open
title: OpenSSL deprecated OpenSSL_version_num() since version 3.0.0
versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Dec 17 06:14:30 2021
From: report at bugs.python.org (Xinmeng Xia)
Date: Fri, 17 Dec 2021 11:14:30 +0000
Subject: [New-bugs-announce] [issue46115] Interrupting subprocess.popen in
 recursive calls by KeyboardInterrupt causes Fatal Python error.
Message-ID: <1639739670.52.0.854058490899.issue46115@roundup.psfhosted.org>


New submission from Xinmeng Xia <xiaxm at smail.nju.edu.cn>:

Popen works when stdio fds are available. However, when interrupting popen in a recursive function call. The Python interpreter reports a Fatal Python error.

test.py
========================================
import subprocess
import os
import sys


def test_small_errpipe_write_fd():
    new_stdout = os.dup(1)
    try:
        os.close(1)
        subprocess.Popen([sys.executable, '-c', "print('AssertionError:0:CLOEXEC failure.')"]).wait()
    finally:
        os.dup2(new_stdout, 0)
        os.dup2(new_stdout, 1)
        test_small_errpipe_write_fd()

test_small_errpipe_write_fd()
=======================================

Reported message:
---------------------------------------------
xxm at xxm:~$ 'cpython-main/python' '/home/xxm/Desktop/test/test.py' 
^CFatal Python error: init_import_site: Failed to import the site module
Python runtime state: initialized
Traceback (most recent call last):
  File "/home/xxm/Desktop/compilers/cpython-main/Lib/site.py", line 73, in <module>
    import os
    ^^^^^^^^^
  File "/home/xxm/Desktop/compilers/cpython-main/Lib/os.py", line 29, in <module>
    from _collections_abc import _check_methods
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/xxm/Desktop/compilers/cpython-main/Lib/_collections_abc.py", line 1015, in <module>
    class Sequence(Reversible, Collection):
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/xxm/Desktop/compilers/cpython-main/Lib/abc.py", line 106, in __new__
    cls = super().__new__(mcls, name, bases, namespace, **kwargs)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
KeyboardInterrupt
-----------------------------------------------

Reproduce step:
1. run test.py in the console
2. use "Ctrl C" to interrupt the program

If typing a "Ctrl C", the program does not stop and no error is reported. Just type "Ctrl C" constantly. Sometimes, it need 5 or 6 "Ctrl C" to reproduce this bug. 



verson of Python: Python 3.11.0a2+ (main, Nov 26 2021, 18:38:48) [GCC 7.5.0] on linux (it also crashes Python 3.6.15, 3.7.12,3.8.12)

----------
components: Interpreter Core
messages: 408772
nosy: xxm
priority: normal
severity: normal
status: open
title: Interrupting subprocess.popen in recursive calls by KeyboardInterrupt causes Fatal Python error.
type: crash
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Dec 17 09:02:14 2021
From: report at bugs.python.org (James Lawrie)
Date: Fri, 17 Dec 2021 14:02:14 +0000
Subject: [New-bugs-announce] [issue46116] _asyncio_backend.py
 datagram_received doesn't handle Future cancelled, throws Exception
Message-ID: <1639749734.89.0.485816466406.issue46116@roundup.psfhosted.org>


New submission from James Lawrie <james at silvermouse.net>:

The datagram_received:

def datagram_received(self, data, addr):
    if self.recvfrom:
        self.recvfrom.set_result((data, addr))
        self.recvfrom = None

Throws an exception if self.recvfrom is a Future Cancelled:

Exception in callback _SelectorDatagramTransport._read_ready()
handle: <Handle _SelectorDatagramTransport._read_ready()>
Traceback (most recent call last):
  File "/usr/lib/python3.8/asyncio/events.py", line 81, in _run
    self._context.run(self._callback, *self._args)
  File "/usr/lib/python3.8/asyncio/selector_events.py", line 1021, in _read_ready
    self._protocol.datagram_received(data, addr)
  File "/usr/local/lib/python3.8/dist-packages/dns/_asyncio_backend.py", line 30, in datagram_received
    self.recvfrom.set_result((data, addr))
asyncio.exceptions.InvalidStateError: invalid state

In my test code (attached), this wasn't caught in a try: catch:

----------
components: asyncio
files: asynctest.py
messages: 408778
nosy: asvetlov, james2, yselivanov
priority: normal
severity: normal
status: open
title: _asyncio_backend.py datagram_received doesn't handle Future cancelled, throws Exception
versions: Python 3.8
Added file: https://bugs.python.org/file50500/asynctest.py

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

From report at bugs.python.org  Fri Dec 17 09:27:10 2021
From: report at bugs.python.org (asper)
Date: Fri, 17 Dec 2021 14:27:10 +0000
Subject: [New-bugs-announce] [issue46117] tk could not refresh auto in mac os
Message-ID: <1639751230.51.0.11843295078.issue46117@roundup.psfhosted.org>


New submission from asper <asper at 21cn.com>:

from tkinter import *
from tkinter import ttk


def change():
    global flag
    if flag == 1:
        namelbl.grid_remove()
        namelbl2.grid(column=0, row=0)
        entry2.grid(column=1, row=0, sticky=(W, E))
        flag = 2
    elif flag == 2:
        namelbl2.grid_remove()
        namelbl.grid()
        flag = 1


root = Tk()
root.columnconfigure(1, weight=1)

namelbl = ttk.Label(root, text="Name")
namelbl2 = ttk.Label(root, text="Name2")
entry1 = ttk.Entry(root)
entry2 = ttk.Entry(root)

ok = ttk.Button(root, text="change", command=change)
ok.grid(column=1, row=1)
namelbl.grid(column=0, row=0)
entry1.grid(column=1, row=0, sticky=(W, E))
flag = 1

root.mainloop()

I run the script in mac os 12.1, use python3.10 download from python.org. when the main window show, I change it's size, and press the   "change" button, the script change the label'text from "Name" to "Name2".When press the button again, the label'text from "Name2" to "Name". but the label cannot refresh the text, it show nothing. when I move the mouse, the text showed immediately. 
The script run normally on windows system.
I use the grid_remove() and grid() to switch frame.

----------
assignee: terry.reedy
components: IDLE
messages: 408780
nosy: asper, terry.reedy
priority: normal
severity: normal
status: open
title: tk could not refresh auto in mac os
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Fri Dec 17 15:54:28 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 17 Dec 2021 20:54:28 +0000
Subject: [New-bugs-announce] [issue46118] Migrate importlib.resources into a
 package
Message-ID: <1639774468.14.0.755654670872.issue46118@roundup.psfhosted.org>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

The importlib.resources module has several modules on which it relies (_adapters, _legacy, simple) and some classes in other modules shared by other parts of importlib (namely abc).

Because these implementations overlap, it adds difficulty in maintaining the `importlib_resources` backport, which must maintain these modules but keep them separate from the unrelated functionality in other parts of importlib.

In an earlier refactoring, `importlib.metadata` was refactored into its own package (https://github.com/python/cpython/pull/25565). This refactoring had benefits of making it clearer which functionality of importlib was related to metadata and which was not.

I'd like to do the same for importlib.resources.

The main complicate

----------
messages: 408815
nosy: jaraco
priority: normal
severity: normal
status: open
title: Migrate importlib.resources into a package
versions: Python 3.11

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

From report at bugs.python.org  Sat Dec 18 02:02:43 2021
From: report at bugs.python.org (Kumar Aditya)
Date: Sat, 18 Dec 2021 07:02:43 +0000
Subject: [New-bugs-announce] [issue46119] Update bundled pip to 21.3.1 and
 setuptools to 59.7.0
Message-ID: <1639810963.48.0.453440530558.issue46119@roundup.psfhosted.org>


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


----------
components: Distutils
nosy: dstufft, eric.araujo, kumaraditya303, pablogsal
priority: normal
severity: normal
status: open
title: Update bundled pip to 21.3.1 and setuptools to 59.7.0
versions: Python 3.11

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

From report at bugs.python.org  Sat Dec 18 03:20:39 2021
From: report at bugs.python.org (Nikita Sobolev)
Date: Sat, 18 Dec 2021 08:20:39 +0000
Subject: [New-bugs-announce] [issue46120] Add note to `typing.Union` that it
 is recommended to use `|` instead
Message-ID: <1639815639.46.0.989122263928.issue46120@roundup.psfhosted.org>


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

As discussed in https://mail.python.org/archives/list/typing-sig at python.org/thread/TW5M6XDN7DO346RXMADKBAAGNSZPC4ZQ/

> we could probably stick a huge notice in the typing.Union docs saying `|` is preferred for readability in most cases, and not deprecate it for now.

I will send a PR to `Union` and `Optional` docs with this note today.

----------
assignee: docs at python
components: Documentation
messages: 408836
nosy: docs at python, sobolevn
priority: normal
severity: normal
status: open
title: Add note to `typing.Union` that it is recommended to use `|` instead
type: behavior
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Sat Dec 18 04:07:00 2021
From: report at bugs.python.org (dmitry-bychkov)
Date: Sat, 18 Dec 2021 09:07:00 +0000
Subject: [New-bugs-announce] [issue46121] Add a note to QueueListener
 documentation saying that SimpleQueue instances can't be used in
 multiprocessing scenarios
Message-ID: <1639818420.43.0.822761446674.issue46121@roundup.psfhosted.org>


New submission from dmitry-bychkov <iamdbychkov at gmail.com>:

Currently, documentation for QueueListener (https://docs.python.org/3/library/logging.handlers.html#queuelistener) says:
"""
supports receiving logging messages from a queue, such as those implemented in the queue or multiprocessing modules.
"""

While also saying that we can use queue.SimpleQueue as an underlying queue:

"""
The queue is not required to have the task tracking API, which means that you can use queue.SimpleQueue instances for queue.
"""

I think it should also say that neither queue.SimpleQueue nor multiprocessing.SimpleQueue instances will work if your intended use of QueueListener is to receive logging messages from processes spawned by multiprocessing module. One should use multiprocessing.Queue instance.

usage of queue.SimpleQueue will result in pickle exception.
multiprocessing.SimpleQueue lacks the API QueueListener expects from queue.

English is not my first language so I'll step aside from PR's in documentation :)

----------
assignee: docs at python
components: Documentation
messages: 408838
nosy: docs at python, iamdbychkov
priority: normal
severity: normal
status: open
title: Add a note to QueueListener documentation saying that SimpleQueue instances can't be used in multiprocessing scenarios
type: enhancement
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Sat Dec 18 05:15:32 2021
From: report at bugs.python.org (Vivek Vashist)
Date: Sat, 18 Dec 2021 10:15:32 +0000
Subject: [New-bugs-announce] [issue46122] Update/fix types.UnionType to
 types.Union in Built-in Types documentation
Message-ID: <1639822532.89.0.201363038797.issue46122@roundup.psfhosted.org>


New submission from Vivek Vashist <vivekvashist at gmail.com>:

There is an error in https://docs.python.org/3/library/stdtypes.html#types-union example.

Looks like there is no types.UnionType

BROKEN:

>>> import types
>>> isinstance(int | str, types.UnionType)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: module 'types' has no attribute 'UnionType'. Did you mean: 'FunctionType'?
>>> [att for att in dir(types) if 'Union' in att]
['Union']
>>>

WORKING:

>>> import types
>>>
>>> isinstance(int | str, types.Union)
True
>>>

I'll raise a PR shortly.

----------
assignee: docs at python
components: Documentation
messages: 408839
nosy: docs at python, vivekvashist
priority: normal
severity: normal
status: open
title: Update/fix types.UnionType to types.Union in Built-in Types documentation
versions: Python 3.10

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

From report at bugs.python.org  Sat Dec 18 06:50:48 2021
From: report at bugs.python.org (neonene)
Date: Sat, 18 Dec 2021 11:50:48 +0000
Subject: [New-bugs-announce] [issue46123] _freeze_module on Windows can be
 built faster with no optimization
Message-ID: <1639828248.15.0.819206839809.issue46123@roundup.psfhosted.org>


New submission from neonene <nicesalmon at gmail.com>:

In Makefile.pre.in, LTO is disabled when building _freeze_module. MSVC can also cut the build time of _freeze_module.exe in half without the optimization.

----------
components: Build, Windows
messages: 408841
nosy: neonene, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: _freeze_module on Windows can be built faster with no optimization
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Sat Dec 18 09:04:21 2021
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 18 Dec 2021 14:04:21 +0000
Subject: [New-bugs-announce] [issue46124] Deprecation warning in zoneinfo
 module
Message-ID: <1639836261.99.0.934737788895.issue46124@roundup.psfhosted.org>


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

zoneinfo module currently emits deprecation warnings due to API changes in importlib.resources

./python -Wonce -m test test_zoneinfo
0:00:00 load avg: 0.73 Run tests sequentially
0:00:00 load avg: 0.73 [1/1] test_zoneinfo
/home/karthikeyan/stuff/python/cpython/Lib/zoneinfo/_tzpath.py:121: DeprecationWarning: open_text is deprecated. Use files() instead. Refer to https://importlib-resources.readthedocs.io/en/latest/using.html#migrating-from-legacy for migration advice.
  with resources.open_text("tzdata", "zones") as f:
/home/karthikeyan/stuff/python/cpython/Lib/zoneinfo/_common.py:12: DeprecationWarning: open_binary is deprecated. Use files() instead. Refer to https://importlib-resources.readthedocs.io/en/latest/using.html#migrating-from-legacy for migration advice.
  return importlib.resources.open_binary(package_name, resource_name)
/home/karthikeyan/stuff/python/cpython/Lib/zoneinfo/_tzpath.py:121: DeprecationWarning: open_text is deprecated. Use files() instead. Refer to https://importlib-resources.readthedocs.io/en/latest/using.html#migrating-from-legacy for migration advice.
  with resources.open_text("tzdata", "zones") as f:
/home/karthikeyan/stuff/python/cpython/Lib/zoneinfo/_common.py:12: DeprecationWarning: open_binary is deprecated. Use files() instead. Refer to https://importlib-resources.readthedocs.io/en/latest/using.html#migrating-from-legacy for migration advice.
  return importlib.resources.open_binary(package_name, resource_name)

== Tests result: SUCCESS ==

1 test OK.

Total duration: 376 ms
Tests result: SUCCESS

A fix would be to adapt the _legacy module changes inline like below patch though normalize_path is not public API and need to be inlined too.

diff --git a/Lib/zoneinfo/_common.py b/Lib/zoneinfo/_common.py
index 4c24f01bd7..bfe3fe4c3c 100644
--- a/Lib/zoneinfo/_common.py
+++ b/Lib/zoneinfo/_common.py
@@ -2,14 +2,15 @@
 
 
 def load_tzdata(key):
-    import importlib.resources
+    from importlib.resources import files
+    from importlib._common import normalize_path
 
     components = key.split("/")
     package_name = ".".join(["tzdata.zoneinfo"] + components[:-1])
     resource_name = components[-1]
 
     try:
-        return importlib.resources.open_binary(package_name, resource_name)
+        return (files(package_name) / normalize_path(resource_name)).open('rb')
     except (ImportError, FileNotFoundError, UnicodeEncodeError):
         # There are three types of exception that can be raised that all amount
         # to "we cannot find this key":
diff --git a/Lib/zoneinfo/_tzpath.py b/Lib/zoneinfo/_tzpath.py
index 672560b951..b1efe5d99e 100644
--- a/Lib/zoneinfo/_tzpath.py
+++ b/Lib/zoneinfo/_tzpath.py
@@ -111,14 +111,15 @@ def available_timezones():
         determine if a given file on the time zone search path is to open it
         and check for the "magic string" at the beginning.
     """
-    from importlib import resources
+    from importlib.resources import files
+    from importlib._common import normalize_path
 
     valid_zones = set()
 
     # Start with loading from the tzdata package if it exists: this has a
     # pre-assembled list of zones that only requires opening one file.
     try:
-        with resources.open_text("tzdata", "zones") as f:
+        with (files("tzdata") / normalize_path("zones")).open('r') as f:
             for zone in f:
                 zone = zone.strip()
                 if zone:

----------
components: Library (Lib)
messages: 408851
nosy: jaraco, p-ganssle, xtreak
priority: normal
severity: normal
status: open
title: Deprecation warning in zoneinfo module
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Sat Dec 18 17:30:51 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 18 Dec 2021 22:30:51 +0000
Subject: [New-bugs-announce] [issue46125] Test the preferred API instead of
 relying on legacy for coverage
Message-ID: <1639866651.22.0.383271924508.issue46125@roundup.psfhosted.org>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

importlib_resources 5.4 did some refactoring to ensure that the preferred traversable API was tested (https://github.com/python/importlib_resources/pull/239). Let's incorporate those changes for importlib.resources.

----------
messages: 408872
nosy: jaraco
priority: normal
severity: normal
status: open
title: Test the preferred API instead of relying on legacy for coverage

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

From report at bugs.python.org  Sat Dec 18 18:08:24 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 18 Dec 2021 23:08:24 +0000
Subject: [New-bugs-announce] [issue46126] Unittest output drives developers
 to avoid docstrings
Message-ID: <1639868904.15.0.52665025329.issue46126@roundup.psfhosted.org>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

In https://github.com/python/importlib_metadata/issues/302, I learned that the way unittest reports failures in tests is incentivizing the replacement of docstrings with comments in order not to make resolution of the relevant failing test more difficult to locate.

I presume I don't need to explain why docstrings are nice and preferable over comments.

Better would be for unittest to provide an option to ignore the docstrings or to emit the test path regardless of whether a docstring was present and to employ that option in CPython, allowing for docstrings in tests.

----------
components: Tests
messages: 408876
nosy: jaraco
priority: normal
severity: normal
status: open
title: Unittest output drives developers to avoid docstrings
versions: Python 3.11

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

From report at bugs.python.org  Sun Dec 19 02:07:18 2021
From: report at bugs.python.org (Vivek Vashist)
Date: Sun, 19 Dec 2021 07:07:18 +0000
Subject: [New-bugs-announce] [issue46127] Missing HTML span element in
 exceptions.html
Message-ID: <1639897638.32.0.841511577932.issue46127@roundup.psfhosted.org>


New submission from Vivek Vashist <vivekvashist at gmail.com>:

Link:
https://docs.python.org/3/library/exceptions.html#exception-hierarchy

Looking at EncodingWarning under exception-hierarchy is displaying BLACK color instead of RED. 

Digging into HTML looks like it is missing the appropriate span class element.

Working:

<span class="o">+--</span> <span class="ne">BytesWarning</span>

Broken:

<span class="o">+--</span> <span class="n">EncodingWarning</span>

See attached screenshot. 

I"m not too familiar with Sphinx but I'm happy to create a PR for this issue if someone could point me in right direction on how to fix this.

----------
assignee: docs at python
components: Documentation
files: Screen Shot 2021-12-19 at 5.29.54 pm.png
messages: 408886
nosy: docs at python, vivekvashist
priority: normal
severity: normal
status: open
title: Missing HTML span element in exceptions.html
versions: Python 3.10
Added file: https://bugs.python.org/file50501/Screen Shot 2021-12-19 at 5.29.54 pm.png

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

From report at bugs.python.org  Sun Dec 19 03:45:55 2021
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 19 Dec 2021 08:45:55 +0000
Subject: [New-bugs-announce] [issue46128] Strip IsolatedAsyncioTestCase
 frames from reported stacktraces
Message-ID: <1639903555.79.0.958192231992.issue46128@roundup.psfhosted.org>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

#7815 supports `__unittest = True` module globals to stripping unittest framework calls from a stacktrace reported by a test failure.

IsolatedAsyncioTestCase missed this setup.

----------
components: Library (Lib)
messages: 408887
nosy: asvetlov
priority: normal
severity: normal
status: open
title: Strip IsolatedAsyncioTestCase frames from reported stacktraces
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Sun Dec 19 05:16:11 2021
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 19 Dec 2021 10:16:11 +0000
Subject: [New-bugs-announce] [issue46129] Rewrite asyncio.locks tests with
 IsolatedAsyncioTestCase
Message-ID: <1639908971.72.0.170814605108.issue46129@roundup.psfhosted.org>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

The change makes tests much better readable.

----------
components: Tests, asyncio
messages: 408888
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Rewrite asyncio.locks tests with IsolatedAsyncioTestCase
versions: Python 3.11

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

From report at bugs.python.org  Sun Dec 19 05:22:01 2021
From: report at bugs.python.org (Rafael Fontenelle)
Date: Sun, 19 Dec 2021 10:22:01 +0000
Subject: [New-bugs-announce] [issue46130] Untranslatable link text in
 whatsnew/3.10
Message-ID: <1639909321.54.0.519282001136.issue46130@roundup.psfhosted.org>


New submission from Rafael Fontenelle <rffontenelle at gmail.com>:

The following string can be found in What's New in Python 3.10 source file (Doc/whatsnew/3.10.rst):

> For major changes, see `New Features Related to Type Hints`_.

where "`New Features Related to Type Hints`_" is a link to a section in the very same page with this name.

The issue with this link text is that translators should translate it (in python-doc organization in Transifex) but warning as errors will pop up if translated. For example, in Portuguese:

> Para mais altera??es, veja `Novos recrusos relacionados a dicas de tipo`_

or to

> Para mais altera??es, veja `Novos recrusos relacionados a dicas de tipo <New Features Related to Type Hints>`_

Sphinx would complain with:

Doc/whatsnew/3.10.rst:1432: WARNING: inconsistent references in translated message. original: ['`New Features Related to Type Hints`_'], translated: []

To solve this issue, I see two solutions:

1- Create an anchor for "New Features Related to Type Hints" section in this page (let's say, "new-feat-related-type-hints") and then call it like :ref:`new-feat-related-type-hints` so that it gets the section title name automatically. Translators won't need to edit it in order to get translated title name. (recommended)

2- Rewrite the source string adding the internal link to the paragraph using `New Features Related to Type Hints <#new-features-related-to-type-hints>`_, so that it can be translated without popping up the warning message.

----------
assignee: docs at python
components: Documentation
messages: 408889
nosy: docs at python, rffontenelle
priority: normal
severity: normal
status: open
title: Untranslatable link text in whatsnew/3.10
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Sun Dec 19 05:38:20 2021
From: report at bugs.python.org (mattip)
Date: Sun, 19 Dec 2021 10:38:20 +0000
Subject: [New-bugs-announce] [issue46131] Add PyType_FastSubclass for float
Message-ID: <1639910300.33.0.186780284433.issue46131@roundup.psfhosted.org>


New submission from mattip <matti.picus at gmail.com>:

The basic classes int, dict, list, tuple ... all have a fast path for Py_*Check(obj):

#define PyLong_Check(op) \
        PyType_FastSubclass(Py_TYPE(op), Py_TPFLAGS_LONG_SUBCLASS)


except for float. I propose to add a Py_TPFLAGS_FLOAT_SUBCLASS enum and use it to implement PyType_FastSubclass for float.

----------
components: C API
messages: 408890
nosy: mattip
priority: normal
severity: normal
status: open
title: Add PyType_FastSubclass for float

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

From report at bugs.python.org  Sun Dec 19 08:47:18 2021
From: report at bugs.python.org (Alex Waygood)
Date: Sun, 19 Dec 2021 13:47:18 +0000
Subject: [New-bugs-announce] [issue46132] Attempting to create an enum with
 slots silently fails
Message-ID: <1639921638.91.0.283272496595.issue46132@roundup.psfhosted.org>


New submission from Alex Waygood <Alex.Waygood at Gmail.com>:

Attempting to create an enum with __slots__ silently fails. No error is raised if __slots__ are specified, but the usual behaviour of __slots__ does not work as expected. Attributes that are not specified in __slots__ can be freely set:


>>> from enum import Enum
>>> class Color(Enum):
...     __slots__ = ()
...     RED = 0
...     BLUE = 1
...
>>> Color.RED.foo = 'bar'
>>>


Given that enums are rather special, I didn't exactly *expect* this to work -- but it might be good to raise some kind of error if a user attempts to specify __slots__, instead of having it fail silently.

----------
messages: 408898
nosy: AlexWaygood, ethan.furman
priority: normal
severity: normal
status: open
title: Attempting to create an enum with slots silently fails
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Sun Dec 19 11:17:53 2021
From: report at bugs.python.org (Matt B)
Date: Sun, 19 Dec 2021 16:17:53 +0000
Subject: [New-bugs-announce] [issue46133] Unclear whether one can (or how
 to) provide source to exec-generated code
Message-ID: <1639930673.95.0.69918856393.issue46133@roundup.psfhosted.org>


New submission from Matt B <eb3f73+python+org at yaymail.com>:

Unless I missed it, looking at https://github.com/python/cpython/blob/main/Lib/pdb.py, https://github.com/python/cpython/blob/main/Lib/inspect.py, and https://docs.python.org/3/library/pdb.html doesn't give much of a clue how to provide sources to exec-generated code.

I may have misread, but pdb *seems* to lean on inspect.findsource which eventually excludes sources that match `^<.*>$` (like `<string>`).

Running attached test_case.py:

% python test_case.py
> <string>(4)foo()
(Pdb) l
[EOF]
(Pdb) c
inspect.getfile(<function foo at 0x10b735160>): <string>
calling inspect.findsource(<function foo at 0x10b735160>) ...
Traceback (most recent call last):
  File "/Users/matt/Documents/dev/numerary/test_case.py", line 12, in <module>
    foo()
  File "/Library/Frameworks/MacPorts-20200907/Python.framework/Versions/3.9/lib/python3.9/inspect.py", line 835, in findsource
    raise OSError('could not get source code')
OSError: could not get source code

----------
files: test_case.py
messages: 408910
nosy: posita
priority: normal
severity: normal
status: open
title: Unclear whether one can (or how to) provide source to exec-generated code
Added file: https://bugs.python.org/file50502/test_case.py

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

From report at bugs.python.org  Sun Dec 19 13:15:09 2021
From: report at bugs.python.org (Landon Ginn)
Date: Sun, 19 Dec 2021 18:15:09 +0000
Subject: [New-bugs-announce] [issue46134] Dataclass Suggestion reversed:
 sortindex / sort_index
Message-ID: <1639937709.73.0.49042724739.issue46134@roundup.psfhosted.org>


New submission from Landon Ginn <landonjpginn at gmail.com>:

from dataclasses import dataclass, field

@dataclass(order=True, frozen=True)
class Character:
    sort_index: int = field(init=False, repr=False)
    name: str
    job: str
    age: int
    intelligence: int = 50

    def __post_init__(self):
        object.__setattr__(self, 'sortindex', self.intelligence)

Description:
using sortindex instead of sort_index gave the following suggestion: 

Current:
AttributeError: 'Character' object has no attribute 'sort_index'. Did you mean: 'sortindex'?


Expected: 
AttributeError: 'Character' object has no attribute 'sortindex'. Did you mean: 'sort_index'?

----------
components: Library (Lib)
messages: 408919
nosy: landonjpginn
priority: normal
severity: normal
status: open
title: Dataclass Suggestion reversed: sortindex / sort_index
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Sun Dec 19 16:23:41 2021
From: report at bugs.python.org (MB SANTALU)
Date: Sun, 19 Dec 2021 21:23:41 +0000
Subject: [New-bugs-announce] [issue46135] Changing a label's text is not
 working properly on transparent widgets
Message-ID: <1639949021.69.0.959451743673.issue46135@roundup.psfhosted.org>


New submission from MB SANTALU <mbsantalu at gmail.com>:

Updating a label's text on a transparent widget in MacOS behaves strangely, previous text remains partially visible (see screenshot)

System Specs: MacOS Monterey 12.0.1 and Python 3.10

Code:

import sys
from PyQt6 import QtWidgets, QtCore
from PyQt6.QtCore import QTimer
from PyQt6.QtGui import QFont
from PyQt6.QtWidgets import QLabel, QFrame
def update_label():
    l1.setText("Bye!")
    l1.update()
    window.repaint()
app = QtWidgets.QApplication(sys.argv)
window = QtWidgets.QWidget()
window.setAttribute(QtCore.Qt.WidgetAttribute.WA_TranslucentBackground)
window.setWindowFlag(QtCore.Qt.WindowType.FramelessWindowHint)
window.setFixedSize(800, 600)
font = QFont()
font.setPointSize(72)
l1 = QLabel(window)
l1.setText("Hello World")
l1.setFont(font)
l1.setStyleSheet("color:red")
window.show()
timer = QTimer()
timer.setInterval(1000)
timer.timeout.connect(update_label)
timer.start()
app.exec()

----------
components: macOS
files: sof.png
messages: 408931
nosy: mbsantalu, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Changing a label's text is not working properly on transparent widgets
type: behavior
versions: Python 3.10
Added file: https://bugs.python.org/file50503/sof.png

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

From report at bugs.python.org  Mon Dec 20 02:22:12 2021
From: report at bugs.python.org (Ajith MsM)
Date: Mon, 20 Dec 2021 07:22:12 +0000
Subject: [New-bugs-announce] [issue46136] "dh low key " issue when try to
 connect mysql
Message-ID: <1639984932.4.0.143068456396.issue46136@roundup.psfhosted.org>


New submission from Ajith MsM <ajithmsm555 at gmail.com>:

i have tried to connect my db using python 3.10. 
import module is mysql.connector.
db has installed in AWS. while excuting pycharm able to connect the db to get the output. 
using CMD prompt in windows not able to execute facing error like "dh low key" error code 2055. 


But able to connect and execute on python 3.9.9 verision could you please fix the 3.10 and above versions.

----------
assignee: christian.heimes
components: SSL
files: issue.txt
messages: 408947
nosy: ajithmsm555, christian.heimes
priority: normal
severity: normal
status: open
title: "dh low key " issue when try to connect mysql
type: resource usage
versions: Python 3.10
Added file: https://bugs.python.org/file50504/issue.txt

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

From report at bugs.python.org  Mon Dec 20 05:40:08 2021
From: report at bugs.python.org (Vivek Vashist)
Date: Mon, 20 Dec 2021 10:40:08 +0000
Subject: [New-bugs-announce] [issue46137] Update/change built-in keyword
 type used in RE example
Message-ID: <1639996808.31.0.346495346407.issue46137@roundup.psfhosted.org>


New submission from Vivek Vashist <vivekvashist at gmail.com>:

Link: https://docs.python.org/3/library/re.html#writing-a-tokenizer

Noticed that built-in type() class is being used inside the Tokenizer example:

class Token(NamedTuple):
    type: str
    value: str
    line: int
    column: int

Should this attribute be updated/renamed to kind or name perhaps ? 

Happy to submit a PR once the change/replacement is confirmed.

----------
assignee: docs at python
components: Documentation
messages: 408951
nosy: docs at python, vivekvashist
priority: normal
severity: normal
status: open
title: Update/change built-in keyword type used in RE example
versions: Python 3.10

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

From report at bugs.python.org  Mon Dec 20 08:28:02 2021
From: report at bugs.python.org (Daniel Frey)
Date: Mon, 20 Dec 2021 13:28:02 +0000
Subject: [New-bugs-announce] [issue46138] Strange behavior with lists
Message-ID: <1640006882.67.0.618077108937.issue46138@roundup.psfhosted.org>


New submission from Daniel Frey <daniel.frey at unibe.ch>:

Hi

I found a strange behavior with lists. When I want to save the list {3,1,8}, it saves the 8 at the first entry. Only when I add the integers 7 and 9, the 8 is placed correctly. (See the attached picture)

Can anyone help me understand what is going on here?

Thanks in advance!

----------
files: python_strange_behavior.png
messages: 408960
nosy: daniel.frey
priority: normal
severity: normal
status: open
title: Strange behavior with lists
type: behavior
versions: Python 3.10
Added file: https://bugs.python.org/file50505/python_strange_behavior.png

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

From report at bugs.python.org  Mon Dec 20 16:20:25 2021
From: report at bugs.python.org (Abri Vincent)
Date: Mon, 20 Dec 2021 21:20:25 +0000
Subject: [New-bugs-announce] [issue46139] Boolean Logic Check - Built-in
 Types Documentation page
Message-ID: <1640035225.46.0.0193110772528.issue46139@roundup.psfhosted.org>


New submission from Abri Vincent <abriabrisham at gmail.com>:

On the documentation page https://docs.python.org/3/library/stdtypes.html the header 'Boolean Operations ? and, or, not' provides a table (attached as an image). 

It states: 

a.1) x OR y - if x is false, then y, else x **
a.2) x AND y - if x is false, then x, else y **

When I read this i intuit the following

b.1) x OR y - if x is false, then x, else y
b.2) x AND y - if x is false, then y, else x

Providing an example with a.1 which is currently listed in the documentation

If x is false -> else x = False (we don't check if Y=True which is the definition of an OR operator). 

** This is a short-circuit operator, so it only evaluates the second argument if the first one is false.

I would appreciate clarification on this and if others see an issue with the documentation after reading my description able then movement on consensus to correct the documentation

----------
assignee: docs at python
components: Documentation
messages: 408972
nosy: abriabrisham, docs at python
priority: normal
severity: normal
status: open
title: Boolean Logic Check - Built-in Types Documentation page

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

From report at bugs.python.org  Mon Dec 20 17:26:56 2021
From: report at bugs.python.org (David Hewitt)
Date: Mon, 20 Dec 2021 22:26:56 +0000
Subject: [New-bugs-announce] [issue46140] Some API methods could take const
 Py_buffer* instead of Py_buffer *
Message-ID: <1640039216.66.0.26119941091.issue46140@roundup.psfhosted.org>


New submission from David Hewitt <david at hewitt.tech>:

The limited api methods `PyBuffer_GetPointer`, `PyBuffer_FromContiguous`, `PyBuffer_ToContiguous` and `PyMemoryView_FromBuffer` take buffer arguments as `Py_buffer *`.

They do not mutate the buffer info, so could simply take `const Py_buffer *`.

There is already precedent to take `const Py_buffer *` argument in `PyBuffer_IsContiguous`.

I'm going to submit a PR to fix.

----------
messages: 408976
nosy: davidhewitt
priority: normal
severity: normal
status: open
title: Some API methods could take const Py_buffer* instead of Py_buffer *
versions: Python 3.11

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

From report at bugs.python.org  Mon Dec 20 17:49:04 2021
From: report at bugs.python.org (Bar Harel)
Date: Mon, 20 Dec 2021 22:49:04 +0000
Subject: [New-bugs-announce] [issue46141] Fix ipaddress.ip_network TypeErrors
Message-ID: <1640040544.01.0.288057218729.issue46141@roundup.psfhosted.org>


New submission from Bar Harel <bzvi7919 at gmail.com>:

IPv4Network accepts a tuple.

If you send a tuple to ip_network instead, it throws a TypeError while attempting to format the ValueError message.

----------
components: Library (Lib)
messages: 408980
nosy: bar.harel
priority: normal
pull_requests: 28439
severity: normal
status: open
title: Fix ipaddress.ip_network TypeErrors
type: behavior
versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Dec 20 18:43:15 2021
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Dec 2021 23:43:15 +0000
Subject: [New-bugs-announce] [issue46142] python --help output is too long
Message-ID: <1640043795.98.0.690443918792.issue46142@roundup.psfhosted.org>


New submission from ?ric Araujo <merwok at netwok.org>:

>From Serhiy in https://mail.python.org/archives/list/python-dev at python.org/thread/QUUBM7DGSXYWBOLZNWOSCQUDALWJIYZF/ :

    The output of "python -h" is 104 lines long now. It was only 51 lines in
    3.6. 35% of it is about the -X option, and 30% about environment
    variables. Also some lines in the -X option description are too long
    (102 columns). Both topics are "advanced" and mostly interested for
    debugging. I suggest to move them out of the main help output.  [?]

Guido:

    -X opt : implementation-specific option; use -X help to list options.

    We could also see if we can put the help text for each of the supported -X
    flags in the table defining these flags [?]

GvR again:

    --help-env [?] prints info about env vars (new flag)


I would enjoy trying to make a patch around next week!

----------
messages: 408981
nosy: eric.araujo, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: python --help output is too long
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Mon Dec 20 23:42:17 2021
From: report at bugs.python.org (David Gilbertson)
Date: Tue, 21 Dec 2021 04:42:17 +0000
Subject: [New-bugs-announce] [issue46143] [docs] IO > Text Encoding info
 outdated
Message-ID: <1640061737.92.0.106243605034.issue46143@roundup.psfhosted.org>


New submission from David Gilbertson <gilbertson.david at gmail.com>:

On this page: https://docs.python.org/3/library/io.html#text-encoding it says "there is no concrete plan as of yet, Python may change the default text file encoding to UTF-8 in the future".

On this page https://docs.python.org/3/library/os.html#utf8-mode is says that from 3.7 onwards UTF-8 will be selected by default.

Does that mean that the text in the first section is now outdated, as it was addressed by PEP 540?

I'm a newbie, so apologies if I'm missing something obvious or filing this in the wrong spot.

----------
assignee: docs at python
components: Documentation
messages: 408983
nosy: docs at python, gilbertson.david
priority: normal
severity: normal
status: open
title: [docs] IO > Text Encoding info outdated
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Tue Dec 21 01:59:34 2021
From: report at bugs.python.org (Joshua Insel)
Date: Tue, 21 Dec 2021 06:59:34 +0000
Subject: [New-bugs-announce] [issue46144] math.log() returns improper output
Message-ID: <1640069974.07.0.0953618961908.issue46144@roundup.psfhosted.org>


New submission from Joshua Insel <joshinsel63 at gmail.com>:

math.log(536870912, 2) should return 29.0, because 2^29 = 536870912. However, it instead returns 29.000000000000004.

----------
messages: 408986
nosy: joshinsel
priority: normal
severity: normal
status: open
title: math.log() returns improper output
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Tue Dec 21 12:24:45 2021
From: report at bugs.python.org (Antara)
Date: Tue, 21 Dec 2021 17:24:45 +0000
Subject: [New-bugs-announce] [issue46145] List reference not working properly
Message-ID: <1640107485.01.0.343364222268.issue46145@roundup.psfhosted.org>


New submission from Antara <antara.data at gmail.com>:

o= [1,2,3,3]
print('o:',id(o))
d= o
print('d:',id(d))
d= [1,2,3,4]
dd= o
print('dd:',id(dd))
dd[3]= 5

print('o:',o)
print('d:',d)
print('dd:',dd)

=======================
Output:
o: 1976210449032
d: 1976210449032
dd: 1976210449032
o: [1, 2, 3, 5]
d: [1, 2, 3, 4]
dd: [1, 2, 3, 5]

Though o,d and dd points to the same memory pointer but d has different value. How can same memory location points to 2 different values?

----------
messages: 408998
nosy: antarab
priority: normal
severity: normal
status: open
title: List reference not working properly
type: behavior

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

From report at bugs.python.org  Tue Dec 21 18:39:11 2021
From: report at bugs.python.org (Matej Cepl)
Date: Tue, 21 Dec 2021 23:39:11 +0000
Subject: [New-bugs-announce] [issue46146] Python IDLE fails to start (tk
 font issue?)
Message-ID: <1640129951.0.0.532007272156.issue46146@roundup.psfhosted.org>


New submission from Matej Cepl <mcepl at cepl.eu>:

(originally filed as https://bugzilla.suse.com/1193409)

When trying to start "idle3.8", I get a ZeroDivisionError in
editor.py. Trying to patch it, I noticed that the complete UI of
IDLE shows no text. Since the same also happens with "idle3.9",
I guess it is a bug in tk.

The error happens also with a fresh user account.

The complete error message is as follows:

> idle3.8
Traceback (most recent call last):
  File "/usr/bin/idle3.8", line 5, in <module>
    main()
  File "/usr/lib64/python3.8/idlelib/pyshell.py", line 1522, in main
    shell = flist.open_shell()
  File "/usr/lib64/python3.8/idlelib/pyshell.py", line 329, in open_shell
    self.pyshell = PyShell(self)
  File "/usr/lib64/python3.8/idlelib/pyshell.py", line 874, in __init__
    OutputWindow.__init__(self, flist, None, None)
  File "/usr/lib64/python3.8/idlelib/outwin.py", line 79, in __init__
    EditorWindow.__init__(self, *args)
  File "/usr/lib64/python3.8/idlelib/editor.py", line 218, in __init__
    self.set_width()
  File "/usr/lib64/python3.8/idlelib/editor.py", line 366, in set_width
    self.width = pixel_width // zero_char_width
ZeroDivisionError: integer division or modulo by zero
>

----------
assignee: terry.reedy
components: IDLE
messages: 409003
nosy: mcepl, terry.reedy
priority: normal
severity: normal
status: open
title: Python IDLE fails to start (tk font issue?)
type: crash
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Dec 21 19:39:46 2021
From: report at bugs.python.org (anthony shaw)
Date: Wed, 22 Dec 2021 00:39:46 +0000
Subject: [New-bugs-announce] [issue46147] Support AddressSanitizer in
 Windows build
Message-ID: <1640133586.41.0.76812451287.issue46147@roundup.psfhosted.org>


New submission from anthony shaw <anthonyshaw at apache.org>:

I'd like to compile my C-extensions with ASAN for testing in Windows, but they cannot be loaded as the host python.exe process needs to be compiled with ASAN. 

https://docs.microsoft.com/en-us/cpp/sanitizers/asan?view=msvc-170#ide-msbuild

The EnableASAN flag would be a setting in vcxproj files within the PCBuild solution, and a flag in the build.bat to enable it.

----------
components: Build, Windows
messages: 409006
nosy: anthonypjshaw, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Support AddressSanitizer in Windows build
type: enhancement

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

From report at bugs.python.org  Wed Dec 22 04:00:00 2021
From: report at bugs.python.org (Kumar Aditya)
Date: Wed, 22 Dec 2021 09:00:00 +0000
Subject: [New-bugs-announce] [issue46148] Optimize pathlib
Message-ID: <1640163600.5.0.408738563991.issue46148@roundup.psfhosted.org>


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

Issue for tracking improving performance of pathlib module.

----------
components: Library (Lib)
messages: 409015
nosy: gvanrossum, kumaraditya303
priority: normal
severity: normal
status: open
title: Optimize pathlib
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Wed Dec 22 05:32:08 2021
From: report at bugs.python.org (=?utf-8?q?Florin_Sp=C4=83tar?=)
Date: Wed, 22 Dec 2021 10:32:08 +0000
Subject: [New-bugs-announce] [issue46149] FIPS usedforsecurity flag is no
 longer functional with OpenSSL 3.0.0
Message-ID: <1640169128.02.0.712227783585.issue46149@roundup.psfhosted.org>


New submission from Florin Sp?tar <florin.spatar at gmail.com>:

I added christian.heimes to the nosy list; I hope that's OK

usedforsecurity flag is based on setting the EVP_MD_CTX_FLAG_NON_FIPS_ALLOW flag. However this flag has no effect in OpenSSL 3.0.0.

    [root at lambada ~]# /opt/opsware/bin/python3
    Python 3.10.0 (default, Dec  8 2021, 17:05:23) [GCC 4.8.5 20150623 (Red Hat 4.8.5-39)] on linux-x86_64
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import _hashlib                                        
    >>> _hashlib.get_fips_mode()                               
    1
    >>> import hashlib
    >>> hashlib.md5(b'ceva', usedforsecurity=False).hexdigest()
    '970c7956028654ac329b12c10b112058'
    >>> hashlib.md5(b'ceva', usedforsecurity=True).hexdigest()
    '970c7956028654ac329b12c10b112058'

The last call, when usedforsecurity is True, should fail because MD5 is not allowed in FIPS mode.

I will add a GitHub pull request for this issue.

----------
assignee: christian.heimes
components: SSL
messages: 409017
nosy: christian.heimes, florinspatar
priority: normal
severity: normal
status: open
title: FIPS usedforsecurity flag is no longer functional with OpenSSL 3.0.0
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Wed Dec 22 07:58:48 2021
From: report at bugs.python.org (Thomas Wouters)
Date: Wed, 22 Dec 2021 12:58:48 +0000
Subject: [New-bugs-announce] [issue46150] test_pathlib assumes "fakeuser"
 does not exist as user
Message-ID: <1640177928.13.0.0270124264104.issue46150@roundup.psfhosted.org>


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

test_pathlib contains, in PosixPathTest.test_expanduser, a check that expanduser on a nonexistent user will raise RuntimeError. Leaving aside the question why that's a RuntimeError (which is probably too late to fix anyway), the test performs this check by assuming 'fakeuser' is a nonexistent user. This test will fail when such a user does exist. (The test already uses the pwd module for other reasons, so it certainly could check that first.)

----------
components: Tests
messages: 409030
nosy: twouters
priority: normal
severity: normal
status: open
title: test_pathlib assumes "fakeuser" does not exist as user
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Wed Dec 22 08:26:50 2021
From: report at bugs.python.org (Trung Pham)
Date: Wed, 22 Dec 2021 13:26:50 +0000
Subject: [New-bugs-announce] [issue46151] SimpleCookie.js_output is
 vulnerable to HTML injection
Message-ID: <1640179610.51.0.982763035039.issue46151@roundup.psfhosted.org>


New submission from Trung Pham <trungpaaa at gmail.com>:

In /Lib/http/cookies.py, the output from SimpleCookie.js_output might be parsed as HTML if it contained < and >.

```
from http import cookies
c = cookies.SimpleCookie()
c["fig"] = "newton</script><script>alert(document.domain)</script>";

// c.js_output()

<script type="text/javascript">
<!-- begin hiding
document.cookie = "fig=\"newton</script><script>alert(document.domain)</script>\"";
// end hiding -->
</script>
```

We can't simply escape all the special characters because the encoding method is treated differently depending on the document types. For example, the following snippet (from The Tangled Web) is safe in HTML but not in XHTML:

```
<script type="text/javascript">
    var tmp = 'I am harmless! &#x27;+alert(1);// Or am I?';
</script>
```

To avoid messing with the encoding methods, we could encode the cookie string in base64 and let the browser decode it.

```
// c.js_output()
<script type="text/javascript">
document.cookie = base64decode(<ENCODED>);
</script>

```

After searching around on Github, I think this function is rarely used so making it deprecated is also an option.

----------
components: Library (Lib)
messages: 409035
nosy: trungpaaa
priority: normal
severity: normal
status: open
title: SimpleCookie.js_output is vulnerable to HTML injection
type: security
versions: Python 3.11

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

From report at bugs.python.org  Wed Dec 22 08:35:24 2021
From: report at bugs.python.org (=?utf-8?b?5riF6ICF6Ieq5riF?=)
Date: Wed, 22 Dec 2021 13:35:24 +0000
Subject: [New-bugs-announce] [issue46152] rename wave.py class nane
Message-ID: <1640180124.46.0.483716784216.issue46152@roundup.psfhosted.org>


New submission from ???? <a1025952421 at gmail.com>:

Wave_read/Wave_write is ugly, change to WaveReader/WaveWriter?

----------
messages: 409036
nosy: a1025952421
priority: normal
severity: normal
status: open
title: rename wave.py class nane
type: performance
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Wed Dec 22 10:38:00 2021
From: report at bugs.python.org (Quentin Peter)
Date: Wed, 22 Dec 2021 15:38:00 +0000
Subject: [New-bugs-announce] [issue46153] closure fails in exec when locals
 is given
Message-ID: <1640187480.74.0.946037624707.issue46153@roundup.psfhosted.org>


New submission from Quentin Peter <qpeter at bluewin.ch>:

When both namespace arguments are given to exec, function definitions fail to capture closure. See below:
```
Python 3.8.6 (default, Oct  8 2020, 14:06:32) 
[Clang 12.0.0 (clang-1200.0.32.2)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> exec("a = 1\ndef f(): return a\nprint(f())")
1
>>> exec("a = 1\ndef f(): return a\nprint(f())", {})
1
>>> exec("a = 1\ndef f(): return a\nprint(f())", {}, {})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 3, in <module>
  File "<string>", line 2, in f
NameError: name 'a' is not defined
>>> 
```

----------
messages: 409038
nosy: qpeter
priority: normal
severity: normal
status: open
title: closure fails in exec when locals is given
type: crash
versions: Python 3.8

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

From report at bugs.python.org  Wed Dec 22 11:36:56 2021
From: report at bugs.python.org (Sophonet)
Date: Wed, 22 Dec 2021 16:36:56 +0000
Subject: [New-bugs-announce] [issue46154] MIMEMultipart enforces line
 endings also for binary subparts
Message-ID: <1640191016.18.0.569343304951.issue46154@roundup.psfhosted.org>


New submission from Sophonet <pythonbugtracker at kant.sophonet.de>:

For an activity with fastapi, I am preparing a Response object with the content of a email.mime.multipart MIMEMultipart object. Adhering to the standards (RFC), a MIMEMultipart response uses CRLF line endings (policy=HTTP). However, the binary attachment I am adding with MIMEApplication() and multipart.attach() in that case gets corrupted since all bytes corresponding to newlines (LF) are replaces with CRLF.

Am I doing something wrong or is this a bug that needs to be fixed?

What I would like to achieve is building a RFC-compliant MIMEMultipart payload in which the subparts do not get altered (in case of application/octet-stream).

Thanks, Sophonet

----------
components: email
messages: 409041
nosy: barry, r.david.murray, sophonet
priority: normal
severity: normal
status: open
title: MIMEMultipart enforces line endings also for binary subparts
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Wed Dec 22 13:42:01 2021
From: report at bugs.python.org (Irit Katriel)
Date: Wed, 22 Dec 2021 18:42:01 +0000
Subject: [New-bugs-announce] [issue46155] Implement ExceptionGroup __new__
Message-ID: <1640198521.38.0.169703954813.issue46155@roundup.psfhosted.org>


New submission from Irit Katriel <iritkatriel at gmail.com>:

Currently ExceptionGroup inherits __new__ from BaseExceptionGroup, it should have its own __new__ implementation which raises a TypeError if any contained exception is not an Exception subclass.

----------
messages: 409047
nosy: gvanrossum, iritkatriel, yselivanov
priority: normal
severity: normal
status: open
title: Implement ExceptionGroup __new__
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Wed Dec 22 14:02:14 2021
From: report at bugs.python.org (lkraav)
Date: Wed, 22 Dec 2021 19:02:14 +0000
Subject: [New-bugs-announce] [issue46156] 3.9.9: python built-in SSL module
 unable to connect to an IIS server (104 Connection reset by peer),
 but pyopenssl works fine
Message-ID: <1640199734.31.0.675782620401.issue46156@roundup.psfhosted.org>


New submission from lkraav <leho at kraav.com>:

Problems emerged when Requests phased out PyOpenSSL as their default backend https://github.com/psf/requests/blob/main/HISTORY.md#2240-2020-06-17

Suddenly my script wasn't able to connect to a remote server that it had been working with for years.

All connection attempts with Python built-in SSL module, with various certificate or TLS configurations tested, result in a blunt ConnectionResetError during `do_handshake()`

This leads me to believe Python SSL module is maybe incompatible [with some IIS thing] in some perhaps fixable way, because going with PyOpenSSL backend via `urllib3.contrib.pyopenssl.inject_into_urllib3()`

I can provide the real server name in a private email if any maintainers is interested in doing a debug run in some more thorough way that I'm unable to, let me know.

Example test:

```
$ ipython
Python 3.9.9 (main, Dec 21 2021, 17:21:49) 
Type 'copyright', 'credits' or 'license' for more information
IPython 7.29.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import ssl

In [2]: context = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)

In [3]: import socket

In [4]: context = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT, verify_mode=ssl.CERT_NONE)

In [5]: conn = context.wrap_socket(socket.socket(socket.AF_INET), server_hostname="webapi.remote")

In [6]: conn.connect(("webapi.remote", 52100))
---------------------------------------------------------------------------
ConnectionResetError                      Traceback (most recent call last)
<ipython-input-6-f778062c5e51> in <module>
----> 1 conn.connect(("webapi.remote", 52100))

/usr/lib/python3.9/ssl.py in connect(self, addr)
   1340         """Connects to remote ADDR, and then wraps the connection in
   1341         an SSL channel."""
-> 1342         self._real_connect(addr, False)
   1343 
   1344     def connect_ex(self, addr):

/usr/lib/python3.9/ssl.py in _real_connect(self, addr, connect_ex)
   1331                 self._connected = True
   1332                 if self.do_handshake_on_connect:
-> 1333                     self.do_handshake()
   1334             return rc
   1335         except (OSError, ValueError):

/usr/lib/python3.9/ssl.py in do_handshake(self, block)
   1307             if timeout == 0.0 and block:
   1308                 self.settimeout(None)
-> 1309             self._sslobj.do_handshake()
   1310         finally:
   1311             self.settimeout(timeout)

ConnectionResetError: [Errno 104] Connection reset by peer
```

----------
assignee: christian.heimes
components: SSL
messages: 409050
nosy: christian.heimes, lkraav
priority: normal
severity: normal
status: open
title: 3.9.9: python built-in SSL module unable to connect to an IIS server (104 Connection reset by peer), but pyopenssl works fine
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Wed Dec 22 14:12:06 2021
From: report at bugs.python.org (Jordan Bonecutter)
Date: Wed, 22 Dec 2021 19:12:06 +0000
Subject: [New-bugs-announce] [issue46157] Typo in JSON documentation
Message-ID: <1640200326.77.0.347412536319.issue46157@roundup.psfhosted.org>


New submission from Jordan Bonecutter <jordanbonecutter at gmail.com>:

In this doc: https://docs.python.org/3/library/json.html#json.dump

The section on check_circular has a typo:

...a circular reference will result in an RecursionError => a RecursionError

----------
assignee: docs at python
components: Documentation
messages: 409051
nosy: docs at python, jordan-bonecutter
priority: normal
severity: normal
status: open
title: Typo in JSON documentation
type: enhancement

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

From report at bugs.python.org  Wed Dec 22 19:58:43 2021
From: report at bugs.python.org (Aditya Kumar)
Date: Thu, 23 Dec 2021 00:58:43 +0000
Subject: [New-bugs-announce] [issue46158] Hardcoded sysroot path,
 to MacOSX11.sdk, in python sysconfig
Message-ID: <1640221123.65.0.639100397925.issue46158@roundup.psfhosted.org>


New submission from Aditya Kumar <akumar9 at snapchat.com>:

$ python3.9
Python 3.9.7 (default, Sep  3 2021, 12:37:55) 
[Clang 12.0.5 (clang-1205.0.22.9)] on darwin

>>> import sysconfig
>>> cflags = sysconfig.get_config_var('CFLAGS')
>>> cflags
'-Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk'


Because of hardcoded 'MacOSX11.sdk', installation of python dependencies that are built from source fails when MacOSX11.sdk is not present on the system.

----------
components: macOS
messages: 409057
nosy: akumar9, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Hardcoded sysroot path, to MacOSX11.sdk, in python sysconfig
versions: Python 3.9

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

From report at bugs.python.org  Wed Dec 22 22:07:26 2021
From: report at bugs.python.org (Paul Kehrer)
Date: Thu, 23 Dec 2021 03:07:26 +0000
Subject: [New-bugs-announce] [issue46159] Segfault
Message-ID: <1640228846.77.0.888301890747.issue46159@roundup.psfhosted.org>


New submission from Paul Kehrer <paul.l.kehrer at gmail.com>:

In Python 3.11a3 on Linux/x86_64 (failed to replicate on macOS, not attempted on Windows) the interpreter non-deterministically segfaults when running some code under coverage. This did not occur under 3.11a2. Looking at the backtrace from a core dump I see:

#0  _PyFrame_FastToLocalsWithError (frame=0x7fedf9e1f608) at Objects/frameobject.c:903
#1  0x00007fedfa15f593 in call_trampoline (tstate=0x55b767a44080, callback=0x7fedf8bbd9c0, 

This is the trace received if I use pure Python coverage (sys.settrace) while I get one inside coverage's ctracer if I use the native library. However, at the moment I don't believe the bug resides within coverage.

Since stack frame optimization has been a focus in 3.11 could something have changed that is causing issues with sys.settrace/PyEval_SetTrace?

I haven't managed to reduce this test case much but here's a somewhat messy dockerfile that can demonstrate it:

FROM ubuntu:focal
RUN apt-get update && apt-get install -y build-essential git cargo libffi-dev libssl-dev libsqlite3-dev zlib1g-dev curl
RUN curl -OL https://www.python.org/ftp/python/3.11.0/Python-3.11.0a3.tgz && \
    tar zxf Python-3.11* && \
    cd Python-3.11* && \
    ./configure --prefix=/opt && \
    make -j4 && make install
RUN /opt/bin/pip3 install tox && git clone https://github.com/pyca/cryptography
RUN cd cryptography && /opt/bin/tox -e py311

----------
messages: 409061
nosy: reaperhulk
priority: normal
severity: normal
status: open
title: Segfault
type: crash
versions: Python 3.11

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

From report at bugs.python.org  Thu Dec 23 02:01:38 2021
From: report at bugs.python.org (dafu-wu)
Date: Thu, 23 Dec 2021 07:01:38 +0000
Subject: [New-bugs-announce] [issue46160] IPy->IPSet AttributeError: module
 'collections' has no attribute 'MutableSet'
Message-ID: <1640242898.84.0.73991251786.issue46160@roundup.psfhosted.org>


New submission from dafu-wu <wucy4328 at gmail.com>:

Traceback (most recent call last):
  File "/Users/jackwu/zhiyun/mygit/webgw/manage.py", line 5, in <module>
    from webgw.settings import DEBUG
  File "/Users/jackwu/zhiyun/mygit/webgw/webgw/__init__.py", line 1, in <module>
    from .app import app
  File "/Users/jackwu/zhiyun/mygit/webgw/webgw/app.py", line 14, in <module>
    from .route_config import Route
  File "/Users/jackwu/zhiyun/mygit/webgw/webgw/route_config.py", line 4, in <module>
    from IPy import IP
  File "/Users/jackwu/zhiyun/mygit/webgw/venv/zhiyun/mygit/my_venv/lib/python3.10/site-packages/IPy.py", line 1025, in <module>
    class IPSet(collections.MutableSet):
AttributeError: module 'collections' has no attribute 'MutableSet'

I'm not sure it's a bug, could someone look at it for me?

----------
components: Library (Lib)
messages: 409068
nosy: dafu-wu
priority: normal
severity: normal
status: open
title: IPy->IPSet AttributeError: module 'collections' has no attribute 'MutableSet'
type: crash
versions: Python 3.10

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

From report at bugs.python.org  Thu Dec 23 02:03:06 2021
From: report at bugs.python.org (zq)
Date: Thu, 23 Dec 2021 07:03:06 +0000
Subject: [New-bugs-announce] [issue46161] Incorrect bytecpde compilation for
 class
Message-ID: <1640242986.51.0.0809941364169.issue46161@roundup.psfhosted.org>


New submission from zq <email2zq at gmail.com>:

Please refer to https://github.com/python/cpython/pull/30235

----------
messages: 409069
nosy: zq1997
priority: normal
pull_requests: 28456
severity: normal
status: open
title: Incorrect bytecpde compilation for class
type: compile error

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

From report at bugs.python.org  Thu Dec 23 04:50:25 2021
From: report at bugs.python.org (Nikita Sobolev)
Date: Thu, 23 Dec 2021 09:50:25 +0000
Subject: [New-bugs-announce] [issue46162] Make `builtins.property` generic
Message-ID: <1640253025.77.0.520385746674.issue46162@roundup.psfhosted.org>


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

Original discussion in `typing` bug tracker: https://github.com/python/typing/issues/985

Short description:
- `property[GetType, SetType]` is required for us to remove a lot of special casing from type-checkers and just use the primitive type
- In runtime it copies the same behavior `list` / `dict` / other primitive types have under PEP585

Open questions:
- I think that it is too late to backport this in 3.10. Am I right?
- I hope that `from __future__ import annotations` will just work for this new change. Is there anything I should do in scope of this PR? Is my assumption about `__future__` import is even correct in this context? Do I need to test that it works with `__future__ annotations`?

----------
components: Library (Lib)
messages: 409080
nosy: gvanrossum, kj, sobolevn
priority: normal
severity: normal
status: open
title: Make `builtins.property` generic
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Thu Dec 23 08:12:46 2021
From: report at bugs.python.org (dmitry-bychkov)
Date: Thu, 23 Dec 2021 13:12:46 +0000
Subject: [New-bugs-announce] [issue46163] multiprocessing logger deadlocks
 if used with logging.handlers.QueueHandler
Message-ID: <1640265166.09.0.322257892524.issue46163@roundup.psfhosted.org>


New submission from dmitry-bychkov <iamdbychkov at gmail.com>:

Hello!
If you use multiprocessing logger with logging.handlers.QueueHandler it will deadlock on first attempt at logging.

First attempt will initialize queue's background thread, which uses multiprocessing logger itself which will result in something what looks like deadlock :) 

There are workarounds and I'm not sure if it can be classified as a bug, prehaps a little note in documentation about this behaviour will do? 

I've attached example script.

----------
files: logger_deadlock.py
messages: 409088
nosy: iamdbychkov
priority: normal
severity: normal
status: open
title: multiprocessing logger deadlocks if used with logging.handlers.QueueHandler
versions: Python 3.9
Added file: https://bugs.python.org/file50513/logger_deadlock.py

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

From report at bugs.python.org  Thu Dec 23 09:22:03 2021
From: report at bugs.python.org (Billy)
Date: Thu, 23 Dec 2021 14:22:03 +0000
Subject: [New-bugs-announce] [issue46164] New `both()` operator for matching
 multiple variables to one
Message-ID: <1640269323.26.0.968410653987.issue46164@roundup.psfhosted.org>


New submission from Billy <billydevbusiness at gmail.com>:

A new `both()` operator for matching multiple variables to one at the same time.

Currently,
```py
if a == 1 and b == 1:
    ...
```

With a `both()` operator, it can be done as follows (concept):
```py
if both(a, b) == 1:
    ...
```

Why? 
-> With the increasing number of variables, it may be hard to compare each of them at once, hence this operator can help a lot in such situations. 
Of course, using lists appropriately can solve this issue easily, but a general-direct method for achieving this would be a lot helpful. This also makes the code more simplistic and easily readable and understandable.



*Sorry for the bad formatting if markdown is not supported for this comment section, I couldn't find it mentioned anywhere in the python developer's guide. Hence I'm assuming it is supported since it's a common and highly needed feature nowadays.

----------
messages: 409091
nosy: billyeatcookies
priority: normal
severity: normal
status: open
title: New `both()` operator for matching multiple variables to one
type: enhancement

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

From report at bugs.python.org  Thu Dec 23 13:53:27 2021
From: report at bugs.python.org (Tomasz Kloczko)
Date: Thu, 23 Dec 2021 18:53:27 +0000
Subject: [New-bugs-announce] [issue46165] pythin is core dumping with SIGILL
 in pytest of the jupyter-server
Message-ID: <1640285607.3.0.100411347335.issue46165@roundup.psfhosted.org>


New submission from Tomasz Kloczko <kloczko.tomasz at gmail.com>:

I;m packaging python modules as rpm packages and just found that package jupyter-server (1.13.1) when pytest was executed python crashed with call trace

+ /usr/bin/pytest -ra jupyter_server
=========================================================================== test session starts ============================================================================
platform linux -- Python 3.8.12, pytest-6.2.5, py-1.11.0, pluggy-1.0.0
rootdir: /home/tkloczko/rpmbuild/BUILD/jupyter_server-1.13.1, configfile: pyproject.toml
plugins: cov-3.0.0, console-scripts-1.2.0, mock-3.6.1, tornasync-0.6.0.post2, anyio-3.3.4
collected 581 items

jupyter_server/auth/security.py Fatal Python error: Illegal instruction

Current thread 0x00007f480bd08740 (most recent call first):
  File "/usr/lib64/python3.8/site-packages/argon2/low_level.py", line 112 in hash_secret
  File "/usr/lib64/python3.8/site-packages/argon2/_password_hasher.py", line 133 in hash
  File "/home/tkloczko/rpmbuild/BUILD/jupyter_server-1.13.1/jupyter_server/auth/security.py", line 73 in passwd
  File "<doctest jupyter_server.auth.security.passwd[0]>", line 1 in <module>
  File "/usr/lib64/python3.8/doctest.py", line 1336 in __run
  File "/usr/lib64/python3.8/doctest.py", line 1483 in run
  File "/usr/lib64/python3.8/doctest.py", line 1844 in run
  File "/usr/lib/python3.8/site-packages/_pytest/doctest.py", line 287 in runtest
  File "/usr/lib/python3.8/site-packages/_pytest/runner.py", line 162 in pytest_runtest_call
  File "/usr/lib/python3.8/site-packages/pluggy/_callers.py", line 39 in _multicall
  File "/usr/lib/python3.8/site-packages/pluggy/_manager.py", line 80 in _hookexec
  File "/usr/lib/python3.8/site-packages/pluggy/_hooks.py", line 265 in __call__
  File "/usr/lib/python3.8/site-packages/_pytest/runner.py", line 255 in <lambda>
  File "/usr/lib/python3.8/site-packages/_pytest/runner.py", line 311 in from_call
  File "/usr/lib/python3.8/site-packages/_pytest/runner.py", line 254 in call_runtest_hook
  File "/usr/lib/python3.8/site-packages/_pytest/runner.py", line 215 in call_and_report
  File "/usr/lib/python3.8/site-packages/_pytest/runner.py", line 126 in runtestprotocol
  File "/usr/lib/python3.8/site-packages/_pytest/runner.py", line 109 in pytest_runtest_protocol
  File "/usr/lib/python3.8/site-packages/pluggy/_callers.py", line 39 in _multicall
  File "/usr/lib/python3.8/site-packages/pluggy/_manager.py", line 80 in _hookexec
  File "/usr/lib/python3.8/site-packages/pluggy/_hooks.py", line 265 in __call__
  File "/usr/lib/python3.8/site-packages/_pytest/main.py", line 348 in pytest_runtestloop
  File "/usr/lib/python3.8/site-packages/pluggy/_callers.py", line 39 in _multicall
  File "/usr/lib/python3.8/site-packages/pluggy/_manager.py", line 80 in _hookexec
  File "/usr/lib/python3.8/site-packages/pluggy/_hooks.py", line 265 in __call__
  File "/usr/lib/python3.8/site-packages/_pytest/main.py", line 323 in _main
  File "/usr/lib/python3.8/site-packages/_pytest/main.py", line 269 in wrap_session
  File "/usr/lib/python3.8/site-packages/_pytest/main.py", line 316 in pytest_cmdline_main
  File "/usr/lib/python3.8/site-packages/pluggy/_callers.py", line 39 in _multicall
  File "/usr/lib/python3.8/site-packages/pluggy/_manager.py", line 80 in _hookexec
  File "/usr/lib/python3.8/site-packages/pluggy/_hooks.py", line 265 in __call__
  File "/usr/lib/python3.8/site-packages/_pytest/config/__init__.py", line 162 in main
  File "/usr/lib/python3.8/site-packages/_pytest/config/__init__.py", line 185 in console_main
  File "/usr/bin/pytest", line 33 in <module>
/var/tmp/rpm-tmp.WmHwan: line 49: 2150294 Illegal instruction     (core dumped) PATH="/home/tkloczko/rpmbuild/BUILDROOT/python-jupyter-server-1.13.1-2.fc35.x86_64/usr/bin:$PATH" PYTHONDONTWRITEBYTECODE=1 SETUPTOOLS_SCM_PRETEND_VERSION=1.13.1 PYTHONPATH="${PYTHONPATH:-/home/tkloczko/rpmbuild/BUILDROOT/python-jupyter-server-1.13.1-2.fc35.x86_64/usr/lib64/python3.8/site-packages:/home/tkloczko/rpmbuild/BUILDROOT/python-jupyter-server-1.13.1-2.fc35.x86_64/usr/lib/python3.8/site-packages}" /usr/bin/pytest -ra jupyter_server

I'm using my own Linux distribution (which I';m supporting for may clients) and I'm still using python 3.8.12.

Here is list of modules installed in build env
[tkloczko at ss-desktop SPECS]$ pip list
Package                       Version
----------------------------- -------------------
alabaster                     0.7.12
anyio                         3.3.4
appdirs                       1.4.4
argon2-cffi                   21.1.0
attrs                         21.2.0
Babel                         2.9.1
backcall                      0.2.0
bleach                        4.0.0
build                         0.7.0
cffi                          1.15.0
chardet                       4.0.0
charset-normalizer            2.0.9
coverage                      6.2
cycler                        0.11.0
dbus-python                   1.2.18
decorator                     5.1.0
defusedxml                    0.7.1
distro                        1.6.0
docutils                      0.17.1
entrypoints                   0.3
extras                        1.0.0
fixtures                      3.0.0
fonttools                     4.28.5
gpg                           1.16.0-unknown
html5lib                      1.1
idna                          3.3
imagesize                     1.2.0
importlib-metadata            4.10.0
importlib-resources           5.4.0
iniconfig                     1.1.1
ipykernel                     6.6.0
ipython                       7.30.1
ipython_genutils              0.2.0
ipywidgets                    7.6.4
jedi                          0.18.1
Jinja2                        3.0.3
jsonschema                    4.3.2
jupyter-client                7.1.0
jupyter-core                  4.9.1
jupyterlab-pygments           0.1.2
kiwisolver                    1.3.2
libcomps                      0.1.18
lxml                          4.7.1
m2r                           0.2.1
Mako                          1.1.6.dev0
Markdown                      3.3.6
markdown-it-py                1.1.0
MarkupSafe                    2.0.1
matplotlib                    3.5.1
matplotlib-inline             0.1.2
mdit-py-plugins               0.3.0
meson                         0.60.2
mistune                       0.8.4
mock                          4.0.3
myst-parser                   0.16.1
nbclient                      0.5.9
nbconvert                     6.1.0
nbformat                      5.1.3
nest-asyncio                  1.5.1
notebook                      6.4.2
numpy                         1.21.4
olefile                       0.46
packaging                     21.3
pandocfilters                 1.5.0
parso                         0.8.3
pbr                           5.6.0
pep517                        0.12.0
pexpect                       4.8.0
pickleshare                   0.7.5
Pillow                        8.4.0
pip                           21.3.1
pluggy                        1.0.0
ply                           3.11
prometheus-client             0.12.0
prompt-toolkit                3.0.24
ptyprocess                    0.7.0
py                            1.11.0
pycparser                     2.21
Pygments                      2.10.0
PyGObject                     3.42.0
pyparsing                     3.0.6
pyrsistent                    0.18.0
pytest                        6.2.5
pytest-console-scripts        1.2.0
pytest-cov                    3.0.0
pytest-mock                   3.6.1
pytest-tornasync              0.6.0.post2
python-dateutil               2.8.2
pytz                          2021.1
PyYAML                        6.0
pyzmq                         22.2.1
requests                      2.26.0
requests-unixsocket           0.2.0
rpm                           4.17.0
scour                         0.38.2
Send2Trash                    1.8.0
setuptools                    60.0.0.post20211220
six                           1.16.0
smartypants                   2.0.1
sniffio                       1.2.0
snowballstemmer               2.1.0
Sphinx                        4.3.2.dev20211220
sphinxcontrib-applehelp       1.0.2.dev20210802
sphinxcontrib-devhelp         1.0.2.dev20210801
sphinxcontrib_github_alt      1.2
sphinxcontrib-htmlhelp        2.0.0
sphinxcontrib-httpdomain      1.7.0
sphinxcontrib-jsmath          1.0.1.dev20210801
sphinxcontrib-openapi         0.7.0
sphinxcontrib-qthelp          1.0.3.dev20210824
sphinxcontrib-serializinghtml 1.1.5
sphinxemoji                   0.1.9
terminado                     0.12.1
testpath                      0.5.0
testtools                     2.5.0
toml                          0.10.2
tomli                         2.0.0
tornado                       6.1
traitlets                     5.1.1
typogrify                     2.0.7
urllib3                       1.26.7
wcwidth                       0.2.5
webencodings                  0.5.1
websocket-client              1.2.3
wheel                         0.37.0
widgetsnbextension            3.5.1
youtube-dl                    2021.6.6
zipp                          3.6.0

I made terminal dump of the gdb session using script command so by "cat python_testing_jupyter-server_pytest.log" on current termilnal you may see full gdb back trace with original colouring.

Please let me know what I can do more to diagnose that issue or if you need more details.

I can add that exactly that python binary was up to now rock solid on building, minstalling and testing +800 python modules as rpm packages.

----------
files: python_testing_jupyter-server_pytest.log
messages: 409098
nosy: kloczek
priority: normal
severity: normal
status: open
title: pythin is core dumping with SIGILL in pytest of the jupyter-server
versions: Python 3.8
Added file: https://bugs.python.org/file50514/python_testing_jupyter-server_pytest.log

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

From report at bugs.python.org  Thu Dec 23 14:33:30 2021
From: report at bugs.python.org (Aaron Gokaslan)
Date: Thu, 23 Dec 2021 19:33:30 +0000
Subject: [New-bugs-announce] [issue46166] Get "self" args or non-null
 co_varnames from frame object with C-API
Message-ID: <1640288010.25.0.698839040509.issue46166@roundup.psfhosted.org>


New submission from Aaron Gokaslan <aaronGokaslan at gmail.com>:

Hello, I am a maintainer with the PyBind11 project. We have been following the 3.11 development branch and have noticed an issue we are encountering with changes to the C-API. 

Particularly, we have an edge case in our overloading dispatch mechanism that we used to solve by inspecting the "self" argument in the co_varnames member of the python frame object: (https://github.com/pybind/pybind11/blob/a224d0cca5f1752acfcdad8e37369e4cda42259e/include/pybind11/pybind11.h#L2380). However, in the new struct, the co_varnames object can now be null. There also doesn't appear to be any public API to populate it on the C-API side. Accessing it via the "inspect" module still works, but that requires us to run a Python code snippit in a potentially very hot code path: (https://github.com/pybind/pybind11/blob/a224d0cca5f1752acfcdad8e37369e4cda42259e/include/pybind11/pybind11.h#L2408).

As such, we were hoping that either there is some new API change we have missed, or if there is some way other modern (and hopefully somewhat  stable way to access the API) so we can emulate the old behavior with the C-API.

----------
components: C API
messages: 409100
nosy: Skylion007
priority: normal
severity: normal
status: open
title: Get "self" args or non-null co_varnames from frame object with C-API
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Thu Dec 23 14:58:53 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 23 Dec 2021 19:58:53 +0000
Subject: [New-bugs-announce] [issue46167] Parse assert (x == y,
 "Descriptive text") as statement params instead of a tuple
Message-ID: <1640289533.73.0.869146772295.issue46167@roundup.psfhosted.org>


New submission from Gregory P. Smith <greg at krypto.org>:

Now that we have a shiny new parser, can we finally get rid of this language wart:

assert thing, description  # works as intended

assert (thing, description)  # always True as non-empty tuples are Truthy

This most often happens when extending thing or description beyond a single line on assert statements as () are the natural way to do that and as it is with assert being a statement, knowing specifically where to place the ()s to not fall into the pit of snakes of unintentionally nerfing your assertion to be an always true tuple is hard for human authors.

This would obsolete the pylint error about tuple assertion and enable more natural assert use.

py.test framework users would presumably rejoice as well.


This parsing change would need a PEP.  I fail to see any obvious downsides though.

----------
components: Parser
messages: 409101
nosy: gregory.p.smith, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Parse assert (x == y, "Descriptive text") as statement params instead of a tuple
versions: Python 3.11

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

From report at bugs.python.org  Thu Dec 23 15:58:06 2021
From: report at bugs.python.org (David Bereza)
Date: Thu, 23 Dec 2021 20:58:06 +0000
Subject: [New-bugs-announce] [issue46168] Incorrect format specified for the
 "style" key in the configuration file format formatter example
Message-ID: <1640293086.43.0.363469814409.issue46168@roundup.psfhosted.org>


New submission from David Bereza <bokunogf at gmail.com>:

Documentation link: https://docs.python.org/3/library/logging.config.html#configuration-file-format

It seems that the example for the "formatter_form01" formatter section specifies following for the style(please note the single-quotes around the value). 
style='%'

This seems to raise a ValueError with the message "Style must be one of..." when parsing the configuration file. Removing the single quotes seems to fix the issue:
style=%

----------
assignee: docs at python
components: Documentation
messages: 409108
nosy: bokunogf, docs at python
priority: normal
severity: normal
status: open
title: Incorrect format specified for the "style" key in the configuration file format formatter example
versions: Python 3.8

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

From report at bugs.python.org  Thu Dec 23 18:27:29 2021
From: report at bugs.python.org (Huon Wilson)
Date: Thu, 23 Dec 2021 23:27:29 +0000
Subject: [New-bugs-announce] [issue46169] Same-moment datetimes with
 different ZoneInfo timezones are not considered ==
Message-ID: <1640302049.86.0.995317132949.issue46169@roundup.psfhosted.org>


New submission from Huon Wilson <wilson.huon at gmail.com>:

The documentation suggests that two datetimes that represent the same moment should compare equal, even if they have different timezones: "If both comparands are aware and have different tzinfo attributes, the comparands are first adjusted by subtracting their UTC offsets (obtained from self.utcoffset())." (below https://docs.python.org/3/library/datetime.html#datetime.datetime.fold)

This doesn't seem to be true for == with ZoneInfo timezones, even though it is true for <= and >=, and -, meaning these seem to violate mathematical laws/expectations:

    from zoneinfo import ZoneInfo
    from datetime import datetime, timezone

    dt_utc = datetime(2020, 11, 1, 8, tzinfo=timezone.utc)
    dt_local = dt_utc.astimezone(ZoneInfo("America/Los_Angeles"))
    print(f"{dt_local == dt_utc = }")
    print(f"{dt_local <= dt_utc = }")
    print(f"{dt_local >= dt_utc = }")
    print(f"{dt_local - dt_utc = }")

Output:

    dt_local == dt_utc = False
    dt_local <= dt_utc = True
    dt_local >= dt_utc = True
    dt_local - dt_utc = datetime.timedelta(0)

Tested with:

- macOS 11.4; Python 3.9.7, 3.10.1, 3.11.0a3
- Linux; via docker image python:3.9.7

Full test including comparisons to python-dateutil (same behaviour as ZoneInfo) and pytz (== gives True as expected) is attached.

Comparing timestamps for exact equality is potentially unusual, but we use it extensively in tests for some time-handling functions.

----------
components: Library (Lib)
files: tz.py
messages: 409113
nosy: huonw
priority: normal
severity: normal
status: open
title: Same-moment datetimes with different ZoneInfo timezones are not considered ==
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9
Added file: https://bugs.python.org/file50516/tz.py

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

From report at bugs.python.org  Thu Dec 23 19:01:32 2021
From: report at bugs.python.org (Gobot1234)
Date: Fri, 24 Dec 2021 00:01:32 +0000
Subject: [New-bugs-announce] [issue46170] Improving the error message when
 subclassing NewType
Message-ID: <1640304092.48.0.180382760459.issue46170@roundup.psfhosted.org>


New submission from Gobot1234 <gobot1234yt at gmail.com>:

I'd like to propose making the error message when subclassing typing.NewType much more understandable. Currently it looks like:
```
TypeError: NewType.__init__() takes 3 positional arguments but 4 were given
```
But I think we could do much better by adding __mro_entries__ to the class and then just having that raise a TypeError telling users they cannot subclass NewType and they are probably looking for `NewType('Subclass', OlderType)`. I'd be happy to patch this myself if this sounds like a good idea.

----------
components: Library (Lib)
messages: 409114
nosy: Gobot1234, gvanrossum, kj
priority: normal
severity: normal
status: open
title: Improving the error message when subclassing NewType
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Fri Dec 24 04:29:51 2021
From: report at bugs.python.org (layday)
Date: Fri, 24 Dec 2021 09:29:51 +0000
Subject: [New-bugs-announce] [issue46171] venv module produces spurious
 warning that location has moved
Message-ID: <1640338191.84.0.15434906765.issue46171@roundup.psfhosted.org>


New submission from layday <layday at protonmail.com>:

After https://github.com/python/cpython/commit/6811fdaec825bd6ab64e358a4b480108f5634d2d
the venv module produces spurious warnings for venv paths which contain
DOS-encoded parts e.g. "USER\~1" in "C:\Users\USER~1".
`tempfile.gettempdir()` returns legacy paths like these for
user temp dirs.

MRE:

    python -c "import tempfile
    import venv

    venv.create(tempfile.mkdtemp())"
    Actual environment location may have moved due to redirects, links or junctions.
    Requested location: "C:\Users\RUNNER~1\AppData\Local\Temp\tmpfoobar\Scripts\python.exe"
    Actual location:    "C:\Users\runneradmin\AppData\Local\Temp\tmpfoobar\Scripts\python.exe"

----------
components: Library (Lib), Windows
messages: 409135
nosy: layday, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: venv module produces spurious warning that location has moved
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Fri Dec 24 04:53:47 2021
From: report at bugs.python.org (CCXXXI)
Date: Fri, 24 Dec 2021 09:53:47 +0000
Subject: [New-bugs-announce] [issue46172] [doc] Outdated description of
 `license` object
Message-ID: <1640339627.46.0.314703994034.issue46172@roundup.psfhosted.org>


New submission from CCXXXI <ccxxxi at qq.com>:

https://docs.python.org/3/library/constants.html#license

> Object that when printed, prints the message ?Type license() to see the full license text?, and when called, displays the full license text in a pager-like fashion (one screen at a time).

It displays "See https://www.python.org/psf/license/" when either printed or called in Python 3.10.1.

----------
assignee: docs at python
components: Documentation
messages: 409138
nosy: CCXXXI, docs at python
priority: normal
severity: normal
status: open
title: [doc] Outdated description of `license` object
versions: Python 3.10

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

From report at bugs.python.org  Fri Dec 24 08:17:25 2021
From: report at bugs.python.org (Cyker Way)
Date: Fri, 24 Dec 2021 13:17:25 +0000
Subject: [New-bugs-announce] [issue46173] float(x) with large x not raise
 OverflowError
Message-ID: <1640351845.8.0.430184776211.issue46173@roundup.psfhosted.org>


New submission from Cyker Way <cykerway at gmail.com>:

Acccording to: https://docs.python.org/3/library/functions.html#float

>    If the argument is outside the range of a Python float, an OverflowError will be raised.

It is well known that the maximum value in IEEE 754 binary64 format is:

    >>> M = ((1<<53)-1)<<(1023-52)
    ...

So `(M+1)` will be out of range. But `float(M+1)` gives me:

    >>> float(M+1)
    1.7976931348623157e+308

No OverflowError is thrown. Contrast this with:

    >>> float(M+M)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    OverflowError: int too large to convert to float

In another text: https://docs.python.org/3/tutorial/floatingpoint.html#representation-error

>   ...Almost all machines today (November 2000) use IEEE-754 floating point arithmetic, and almost all platforms map Python floats to IEEE-754 ?double precision?...

Is Python not following IEEE 754 binary64 format or something missing here?

----------
components: Interpreter Core
messages: 409143
nosy: cykerway
priority: normal
severity: normal
status: open
title: float(x) with large x not raise OverflowError
type: behavior
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Fri Dec 24 11:17:33 2021
From: report at bugs.python.org (Or)
Date: Fri, 24 Dec 2021 16:17:33 +0000
Subject: [New-bugs-announce] [issue46174] Feature Request for Python
 Interfaces
Message-ID: <1640362653.44.0.824482732412.issue46174@roundup.psfhosted.org>


New submission from Or <orieeeams at gmail.com>:

Most object oriented languages provide interfaces as part of the core language, this helps bring better design principles to a team's workflows.

Today Python provides the ABC module for abstract base classes and the Protocol class from typing module as something that might resemble an interface.

Creating abstract classes to simulate interface behavior is pretty tedious and the Protocol class is not supported by IDEs for type hints, completions, bug findings, etc.

I think the Python community would really benefit if we have an interface keyword built into the core language and enforced by the interpreter, similar to how it's implemented in Java and C#.

----------
messages: 409149
nosy: Orie
priority: normal
severity: normal
status: open
title: Feature Request for Python Interfaces
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Fri Dec 24 22:25:41 2021
From: report at bugs.python.org (Alex Walters)
Date: Sat, 25 Dec 2021 03:25:41 +0000
Subject: [New-bugs-announce] [issue46175] Zero argument super() does not
 function properly inside generator expressions
Message-ID: <1640402741.49.0.663575697797.issue46175@roundup.psfhosted.org>


New submission from Alex Walters <tritium-list at sdamon.com>:

When zero argument super is used inside a generator expression, it raises 'TypeError: super(type, obj): obj must be an instance or subtype of type'.

I can find no information on if this is working as intended, a bug, or a known issue, and the error isn't helping.  Attached is a minimal example of the error.

----------
files: superbug.py
messages: 409166
nosy: tritium
priority: normal
severity: normal
status: open
title: Zero argument super() does not function properly inside generator expressions
versions: Python 3.9
Added file: https://bugs.python.org/file50518/superbug.py

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

From report at bugs.python.org  Sat Dec 25 06:10:06 2021
From: report at bugs.python.org (David CARLIER)
Date: Sat, 25 Dec 2021 11:10:06 +0000
Subject: [New-bugs-announce] [issue46176] mmap module add MAP_STACK constant
 mostly for OpenBSD
Message-ID: <1640430606.11.0.300408283052.issue46176@roundup.psfhosted.org>


Change by David CARLIER <devnexen at gmail.com>:


----------
components: Library (Lib)
nosy: devnexen
priority: normal
pull_requests: 28473
severity: normal
status: open
title: mmap module add MAP_STACK constant mostly for OpenBSD
versions: Python 3.11

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

From report at bugs.python.org  Sat Dec 25 14:00:42 2021
From: report at bugs.python.org (Amine Harrabi)
Date: Sat, 25 Dec 2021 19:00:42 +0000
Subject: [New-bugs-announce] [issue46177] can't install launcher for all
 users
Message-ID: <1640458842.49.0.0625081718975.issue46177@roundup.psfhosted.org>


New submission from Amine Harrabi <amineiiiiharrabi at gmail.com>:

the install launcher for all users is grayed out although im logged in as admin

----------
components: Windows
messages: 409173
nosy: Amine, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: can't install launcher for all users
versions: Python 3.10

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

From report at bugs.python.org  Sun Dec 26 04:34:33 2021
From: report at bugs.python.org (Nikita Sobolev)
Date: Sun, 26 Dec 2021 09:34:33 +0000
Subject: [New-bugs-announce] [issue46178] Remove `.travis.yml`?
Message-ID: <1640511273.57.0.0109670921395.issue46178@roundup.psfhosted.org>


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

Travis does not seem to be used anymore. 
There are not builds in Travis for cpython on `.org`: https://travis-ci.org/github/python/cpython/builds
The last build on `.com` is 6 month old: https://app.travis-ci.com/github/python/cpython/builds

If some information from this file will be needed in the future, we can always find its legacy version in git.

I will send a PR!

----------
components: Build
messages: 409182
nosy: sobolevn
priority: normal
severity: normal
status: open
title: Remove `.travis.yml`?
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Sun Dec 26 05:02:13 2021
From: report at bugs.python.org (Jason Yang)
Date: Sun, 26 Dec 2021 10:02:13 +0000
Subject: [New-bugs-announce] [issue46179] Delete selected item generate
 "<<TreeviewSelect>>" event or not in different version of tkinter or Python
Message-ID: <1640512933.66.0.468585865252.issue46179@roundup.psfhosted.org>


New submission from Jason Yang <jason990420 at outlook.com>:

In python(3.8.10)/tkinter(8.6.9), it won't generate "<<TreeviewSelect>>" event if we delete selected item of ttk.Treeview, but it will for python(3.9.9/3.10.1)/tkinter(8.6.12).

Check it just by clicking 'Delete Item 1' button in following demo code

```python
import sys
from random import randint
from datetime import datetime
import tkinter as tk
from tkinter import ttk

def button_callback():
    button.configure(state='disabled')
    treeview.delete(1)

def treeview_callback(event):
    print(datetime.now().strftime("%H:%M:%S"), "Treeview selection changed !")

print(f"Python version : {sys.version.split(' ')[0]}")
print(f"tkinter version: {tk.Tcl().eval('info patchlevel')}")

columns = ('President', 'Birthday')
data = [
    ('Ronald Reagan', 'February 6'),
    ('Abraham Lincoln', 'February 12'),
    ('George Washington', 'February 22'),
    ('Andrew Jackson', 'March 15'),
    ('Thomas Jefferson', 'April 13'),
]

root = tk.Tk()

treeview = ttk.Treeview(root, columns=columns, height=5, show='headings')
treeview.pack()
for column in columns:
    treeview.heading(column, text=column)
    treeview.column(column, width=150)
for i, row in enumerate(data):
    treeview.insert('', i, iid=i, text=str(i), values=row)
treeview.selection_set(1)

button = tk.Button(root, text='Delete Item 1', command=button_callback)
button.pack()

treeview.bind("<<TreeviewSelect>>", treeview_callback)

root.mainloop()
```

```python
d:\>python test3.py
Python version : 3.8.10
tkinter version: 8.6.9
17:57:43 Treeview selection changed !

d:\>python test3.py
Python version : 3.9.9
tkinter version: 8.6.12
17:58:10 Treeview selection changed !
17:58:11 Treeview selection changed !

d:\>python test3.py
Python version : 3.10.1
tkinter version: 8.6.12
18:01:10 Treeview selection changed !
18:01:12 Treeview selection changed !
```

----------
components: Tkinter
messages: 409185
nosy: Jason990420
priority: normal
severity: normal
status: open
title: Delete selected item generate "<<TreeviewSelect>>" event or not in different version of tkinter or Python
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Dec 26 05:39:08 2021
From: report at bugs.python.org (Jason Yang)
Date: Sun, 26 Dec 2021 10:39:08 +0000
Subject: [New-bugs-announce] [issue46180] Button clicked failed when mouse
 hover tooltip and tooltip destroyed
Message-ID: <1640515148.68.0.766649384181.issue46180@roundup.psfhosted.org>


New submission from Jason Yang <jason990420 at outlook.com>:

Button no response when clicked if mouse move into tooltip and tooltip destroyed for Python 3.9.9/3.10.1 and tkinter 8.6.12

You can check it by moving mouse into button, then move to tooltip after it shown, then click button and you won't get response for button clicked, but "Leave". It is OK for lower version of Python/tkinter.

```python
import sys
from datetime import datetime
import tkinter as tk

class Tooltip(object):
    """
    create a tooltip for a given widget
    """
    def __init__(self, widget, text='widget info'):
        self.waittime = 500     # miliseconds
        self.widget = widget
        self.text = text
        self.widget.bind("<Enter>", self.enter)
        self.widget.bind("<Leave>", self.leave)
        self.widget.bind("<ButtonPress>", self.leave)
        self.id = None
        self.top = None

    def enter(self, event=None):
        print(now(), "Enter")
        self.schedule()

    def leave(self, event=None):
        print(now(), "Leave")
        self.unschedule()
        self.hidetip()

    def schedule(self):
        self.unschedule()
        self.id = self.widget.after(self.waittime, self.showtip)

    def unschedule(self):
        id = self.id
        self.id = None
        if id:
            self.widget.after_cancel(id)

    def showtip(self, event=None):
        x = y = 0
        x, y, cx, cy = self.widget.bbox("insert")
        x += self.widget.winfo_rootx() + self.widget.winfo_width()//2
        y += self.widget.winfo_rooty() + self.widget.winfo_height()//2
        self.top = tk.Toplevel(self.widget)
        self.top.wm_overrideredirect(True)
        self.top.wm_geometry("+%d+%d" % (x, y))
        label = tk.Label(self.top, text=self.text, bd=1, font=font, relief='solid')
        label.pack(ipadx=1)

    def hidetip(self):
        top = self.top
        self.top = None
        if top:
            top.destroy()

def now():
    return datetime.now().strftime("%H:%M:%S")

print(f"Python version : {sys.version.split(' ')[0]}")
print(f"tkinter version: {tk.Tcl().eval('info patchlevel')}")

font = ("Courier New", 40)

root = tk.Tk()
button = tk.Button(root, text="button", font=font,
    command=lambda:print(now(), 'Button clicked'))
button.pack(padx=10, pady=5)
tooltip = Tooltip(button, 'This is button 1')

root.mainloop()
```

```python
d:\>python test.py
Python version : 3.10.1
tkinter version: 8.6.12
18:21:52 Enter (Mouse to button)
18:21:54 Leave (mouse to tooltip)
18:21:55 Leave (button clicked get no response)
18:21:57 Leave (button clicked get no response)
18:21:58 Leave (button clicked get no response)

d:\>python test.py
Python version : 3.9.9
tkinter version: 8.6.12
18:22:51 Enter (Mouse to button)
18:22:54 Leave (mouse to tooltip)
18:22:55 Leave (button clicked get no response)
18:22:56 Leave (button clicked get no response)
18:22:57 Leave (button clicked get no response)

d:\>python test.py
Python version : 3.8.10
tkinter version: 8.6.9
18:23:22 Enter (Mouse to button)
18:23:23 Leave (mouse to tooltip)
18:23:23 Enter (mouse stay, and it will repeat `Enter and Leave` again and again)
18:23:24 Leave
...
18:23:28 Enter
18:23:28 Leave
18:23:28 Button clicked (button clicked get response)
18:23:31 Leave
18:23:31 Button clicked (button clicked get response)
18:23:32 Leave
```

Platform - WIN10

----------
components: Tkinter
messages: 409188
nosy: Jason990420
priority: normal
severity: normal
status: open
title: Button clicked failed when mouse hover tooltip and tooltip destroyed
type: crash
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Dec 26 07:21:18 2021
From: report at bugs.python.org (Jonathan Lahav)
Date: Sun, 26 Dec 2021 12:21:18 +0000
Subject: [New-bugs-announce] [issue46181] Destroying an expaned Combobox
 prevents Entry focus until Alt+Tab
Message-ID: <1640521278.35.0.92599921807.issue46181@roundup.psfhosted.org>


New submission from Jonathan Lahav <j.lahav at gmail.com>:

Happens on Windows.

Observation:
When an expanded Combobox is destroyerd, widgets in the window can't get focus until Alt+Tab forth and back.
Buttons can still be clicked, but focus can't be obtained by widgets, entries fro example, not by clicking nor by the Tab or arrow keys.

The attached file contains a minimal reproduction example.

Motivation:
I develop the GUI for a complex application at work which needs to recreate its GUI layout upon a combobox selection, thus destroying the combobox as well.

----------
components: Tkinter
files: combobug.py
messages: 409196
nosy: j.lahav
priority: normal
severity: normal
status: open
title: Destroying an expaned Combobox prevents Entry focus until Alt+Tab
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file50522/combobug.py

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

From report at bugs.python.org  Sun Dec 26 10:38:34 2021
From: report at bugs.python.org (Arthur Milchior)
Date: Sun, 26 Dec 2021 15:38:34 +0000
Subject: [New-bugs-announce] [issue46182] `super` and descriptor
 clarification
Message-ID: <1640533114.63.0.779589080472.issue46182@roundup.psfhosted.org>


New submission from Arthur Milchior <arthur at milchior.fr>:

I find super documentation confusing because it uses multiple variables that are never introduced. Once you understand super, the meaning of those variables gets easier to understand, but still, I believe that it would help the documentation to rephrase some sentences.

In https://docs.python.org/3/reference/datamodel.html#invoking-descriptors you can read
> If a is an instance of super, then the binding super(B, obj).m() searches obj.__class__.__mro__ for the base class A immediately following B and then invokes the descriptor with the call: A.__dict__['m'].__get__(obj, obj.__class__).

It took me many reading to understand that `obj` is supposed to be a new variable; and also why `a` only appear once in the line. I believe it'd be better to explicitly state "We consider the case where a = super(B, obj), with `obj` an instance of B."

Also, `super(B, obj).m()` seems to indicate that the method `m` is called. While ` A.__dict__['m'].__get__(obj, obj.__class__)` does not seems to call this method. Hence, I believe that the parentheses should be removed after `m` (and either `m` should be renamed to `x`, or we should state explicitly that we are not considered `a.x` anymore, contrary to the previous cases)



In https://docs.python.org/3/library/functions.html#super , you can read 
> If the second argument is omitted, the super object returned is unbound. If the second argument is an object, isinstance(obj, type) must be true. If the second argument is a type, issubclass(type2, type) must be true (this is useful for classmethods).

On first reading, I have no idea what it means that a returned object is unbound. I know what "variable binding" mean, but it really does not seems to apply here. My current understanding, and I would love if someone can confirm it, is that the first sentence means that "contrary to the other cases, the returned value do not have to satisfy any bound". In this case, I believe that it would be far better to put the case with no second argument at the end of the paragraph, ensuring that "is unbound" makes sens to the reader since they already will have seen bounds.
Also, it may help clarify to write "is an object `obj`" and "is a type `type2`" so that it get clear what `obj` and `type2` means.



Any feedback welcome.

----------
assignee: docs at python
components: Documentation
messages: 409201
nosy: Arthur-Milchior, docs at python
priority: normal
severity: normal
status: open
title: `super` and descriptor clarification
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Dec 26 11:10:13 2021
From: report at bugs.python.org (syed shah)
Date: Sun, 26 Dec 2021 16:10:13 +0000
Subject: [New-bugs-announce] [issue46183] float function errors on negative
 number string with comma seperator ex: '-1, 234.0'
Message-ID: <1640535013.14.0.929646727158.issue46183@roundup.psfhosted.org>


New submission from syed shah <jj.github.jj at gmail.com>:

>>> float ('-1,234')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: could not convert string to float: '-1,234'

----------
components: Library (Lib)
messages: 409202
nosy: jj.github.jj
priority: normal
severity: normal
status: open
title: float function errors on negative number string with comma seperator ex: '-1,234.0'
versions: Python 3.9

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

From report at bugs.python.org  Sun Dec 26 17:00:26 2021
From: report at bugs.python.org (Nikita Sobolev)
Date: Sun, 26 Dec 2021 22:00:26 +0000
Subject: [New-bugs-announce] [issue46184] Remove `netlify.toml`?
Message-ID: <1640556026.15.0.409778819422.issue46184@roundup.psfhosted.org>


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

It was added one year ago in https://bugs.python.org/issue37860

But, it is not used. Right now it does not do anything. Others report that it has a lot of limitations (including financial and technical ones): https://github.com/python/cpython/pull/15288#issuecomment-579476340

Original author even proposed another solution: https://bugs.python.org/issue37860 (PR is stale)

I propose to remove it. It can always be found in git.
Permalink to the last version in `main`: https://github.com/python/cpython/blob/2e3e0d23adca8d83722d939d6abd1e467d7578f7/netlify.toml

Related issue about `.travis.yml`: https://bugs.python.org/issue46178

----------
components: Build
messages: 409220
nosy: sobolevn
priority: normal
severity: normal
status: open
title: Remove `netlify.toml`?
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Mon Dec 27 07:05:26 2021
From: report at bugs.python.org (Jaap Roes)
Date: Mon, 27 Dec 2021 12:05:26 +0000
Subject: [New-bugs-announce] [issue46185] Python 3.10.1 installer refers to
 /Applications/Python 3.9 Install Certificates
Message-ID: <1640606726.92.0.295758053578.issue46185@roundup.psfhosted.org>


New submission from Jaap Roes <jaap.roes at gmail.com>:

The Python 3.10.1 installer on macOS has the text "A sample command script is included in /Applications/Python 3.9" when mentioning the "Install Certificates" command. This location doesn't exist (unless one has installed Python 3.9).

The source of this text can be found here:

https://github.com/python/cpython/blob/f4c03484da59049eb62a9bf7777b963e2267d187/Mac/BuildScript/resources/ReadMe.rtf#L29

----------
components: Installation
messages: 409230
nosy: jaap3, ned.deily
priority: normal
severity: normal
status: open
title: Python 3.10.1 installer refers to /Applications/Python 3.9 Install Certificates
versions: Python 3.10

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

From report at bugs.python.org  Mon Dec 27 13:01:06 2021
From: report at bugs.python.org (Guo Ci Teo)
Date: Mon, 27 Dec 2021 18:01:06 +0000
Subject: [New-bugs-announce] [issue46186] replace
 `io.IncrementalNewlineDecoder` with non incremental newline decoders
Message-ID: <1640628066.96.0.973649532824.issue46186@roundup.psfhosted.org>


New submission from Guo Ci Teo <zguoci at gmail.com>:

replace unnecessary use of `io.IncrementalNewlineDecoder` in code.
Some uses of the `decode` method were also incorrect without the `final=True` argument.

----------
messages: 409235
nosy: guoci
priority: normal
severity: normal
status: open
title: replace `io.IncrementalNewlineDecoder` with non incremental newline decoders

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

From report at bugs.python.org  Mon Dec 27 14:29:59 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 27 Dec 2021 19:29:59 +0000
Subject: [New-bugs-announce] [issue46187] Optionally support rounding for
 math.isqrt()
Message-ID: <1640633399.46.0.8152811809.issue46187@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

By default, isqrt(n) gives the floor of the exact square of n.  It would be nice to have a flag to give a rounded result:

    y = isqrt(n, round=True)

Alternatively, set a mode argument to one of {'floor', 'round', 'ceil'}:

    y = isqrt(n, mode='round')

I would like something better than this:

    def risqrt(x):
        'Big integer version of: round(sqrt(x)).'
        y = isqrt(x)
        s = y ** 2
        return y if x <= s + y else y + 1

    def cisqrt(x):
        'Big integer version of: ceil(sqrt(x)).'
        return isqrt(x - 1) + 1

My use case arose when building a table of square roots incorporated in arbitrary precision functions implemented with scaled integer arithmetic:

    def get_root_table(base, steps, scale):
        s = []
        x = round(base * scale)
        for i in range(steps):
            x = risqrt(x * scale)
            s.append(x)
        return s

----------
assignee: mark.dickinson
components: Library (Lib)
messages: 409243
nosy: mark.dickinson, rhettinger, tim.peters
priority: normal
severity: normal
status: open
title: Optionally support rounding for math.isqrt()
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Tue Dec 28 05:00:02 2021
From: report at bugs.python.org (TobiasHT)
Date: Tue, 28 Dec 2021 10:00:02 +0000
Subject: [New-bugs-announce] [issue46188] dictionary creation error
Message-ID: <1640685602.96.0.10576142491.issue46188@roundup.psfhosted.org>


New submission from TobiasHT <higenyi.tobias at gmail.com>:

I was creating a dictionary when I noticed something weird.
I had a function responsible for creating dictionary keys and then values were assigned to the keys in a for loop.
The code goes a little like this:

>>> def key_maker(n):
...     if (n % 2) == 0:
...         return n
...     return None

>>> dictionary = {}
>>> for i in range(10):
...     dictionary[key_maker(i)] = i if key_maker(i) else "error"

>>> dictionary
{0: 'error', None: 'error', 2: 2, 4: 4, 6: 6, 8: 8}


when I tried to print out the rest of the values in the "else" clause,
I realized that 0 appeared there as well, so 0 appeared twice.

>>> for i in range(10):
...     dictionary[key_maker(i)] = i if key_maker(i) else print(i)
...
0
1
3
5
7
9
>>> dictionary
{0: 'error', None: 'error', 2: 2, 4: 4, 6: 6, 8: 8}

I still can not figure out why the first two elements are inconsistent
from the rest of the dictionary, and why they appear in the first place.

----------
messages: 409251
nosy: TobiasHT
priority: normal
severity: normal
status: open
title: dictionary creation error
type: behavior

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

From report at bugs.python.org  Tue Dec 28 10:01:14 2021
From: report at bugs.python.org (hejin517)
Date: Tue, 28 Dec 2021 15:01:14 +0000
Subject: [New-bugs-announce] [issue46189] Text containing "wide" character
 not correctly refreshed
Message-ID: <1640703674.26.0.944384925323.issue46189@roundup.psfhosted.org>


New submission from hejin517 <hejin517 at 126.com>:

When the app runs it first shows a black character "f" in Times New Roman.
By clicking the button, I expect that the color of the whole character will be changed to red, but actually only part is changed.

In FontForge (a font editor), I find the character "f" in Times New Roman is wider than its "width".
Please look into this problem. Thanks.

Code to reproduce:
----------------------
import tkinter

def change_color():
    canvas.itemconfig(text, fill="red")

root = tkinter.Tk()
canvas = tkinter.Canvas(root, width=500, height=500)
canvas.pack()

text = canvas.create_text((200, 200), text="f", font=("Times New Roman", 200), fill="black")

button = tkinter.Button(text="Change Color", command=change_color)
button.pack()

root.mainloop()

----------
components: Tkinter
messages: 409258
nosy: hejin517
priority: normal
severity: normal
status: open
title: Text containing "wide" character not correctly refreshed
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Wed Dec 29 00:36:37 2021
From: report at bugs.python.org (Tilman Krummeck)
Date: Wed, 29 Dec 2021 05:36:37 +0000
Subject: [New-bugs-announce] [issue46190] Omit k in random.sample()
Message-ID: <1640756197.3.0.702729016627.issue46190@roundup.psfhosted.org>


New submission from Tilman Krummeck <tilman.krummeck at googlemail.com>:

random.sample can be used to choose k items from a given sequence. Currently, k is a mandatory parameter. 

I suggest to make k optional and instead, if omitted, pick a random value from the range of 0 and the length of the sequence.

Of course, doing this must also consider any possible value of 'count'

----------
components: Extension Modules
messages: 409283
nosy: TilmanKrummeck
priority: normal
severity: normal
status: open
title: Omit k in random.sample()
type: enhancement

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

From report at bugs.python.org  Wed Dec 29 03:28:12 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 29 Dec 2021 08:28:12 +0000
Subject: [New-bugs-announce] [issue46191] Conflict between using annotations
 in singledispatch() and MyPy
Message-ID: <1640766492.06.0.603316818634.issue46191@roundup.psfhosted.org>


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

You can dispatch on collections.abc.Sequence.

@functools.singledispatch
def f(a: collections.abc.Sequence) -> None:
    pass

But MyPy complains about this:

error: Missing type parameters for generic type "Sequence"

MyPy requires parametrized generic (like collections.abc.Sequence[int]), but singledispatch() does not work with it.

----------
components: Library (Lib)
messages: 409295
nosy: gvanrossum, kj, rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Conflict between using annotations in singledispatch() and MyPy
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Wed Dec 29 05:04:55 2021
From: report at bugs.python.org (colorfulappl)
Date: Wed, 29 Dec 2021 10:04:55 +0000
Subject: [New-bugs-announce] [issue46192] Optimize builtin functions min()
 and max()
Message-ID: <1640772295.19.0.507214715597.issue46192@roundup.psfhosted.org>


New submission from colorfulappl <colorfulappl at qq.com>:

https://github.com/faster-cpython/ideas/discussions/199

----------
components: Interpreter Core
messages: 409299
nosy: colorfulappl
priority: normal
severity: normal
status: open
title: Optimize builtin functions min() and max()
versions: Python 3.11

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

From report at bugs.python.org  Wed Dec 29 07:34:59 2021
From: report at bugs.python.org (Keepun)
Date: Wed, 29 Dec 2021 12:34:59 +0000
Subject: [New-bugs-announce] [issue46193] Using a dictionary for open files.
Message-ID: <1640781299.57.0.336049681987.issue46193@roundup.psfhosted.org>


New submission from Keepun <keepun at gmail.com>:

"""
Using a dictionary for open files.

The file is filled with NULL. Only the last entry is normal.

Result:
00 00 00 00 ... 00 0A 48 65 6C 6C 6F 0A

Ubuntu - 3.8.10
Windows - 3.9.8
"""
fhandles = {}
for f in range(100):
    fh = fhandles.setdefault("suffix", open(r"test.txt", "w"))
    fh.write("\nHello\n")
    fh.flush()
for f in fhandles.values():
    f.close()

import sys
print(sys.version_info)

----------
components: IO
messages: 409303
nosy: Keepun
priority: normal
severity: normal
status: open
title: Using a dictionary for open files.
type: behavior
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Dec 29 09:56:23 2021
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 29 Dec 2021 14:56:23 +0000
Subject: [New-bugs-announce] [issue46194] Wrong base class for transport
 returned by loop.create_datagram_endpoint()
Message-ID: <1640789783.73.0.00777071599466.issue46194@roundup.psfhosted.org>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

Selector-based event loops returns `_SelectorDatagramTransport` which inherits `asyncio.Transport` instead of `asyncio.DatagramTransport`.

isinstance(transp, asyncio.DatagramTransport) fails.
It doesn't affect the actual execution since `transp.sendto()` and `transp.error_received()` are correctly implemented.

The bug doesn't affect Windows proactor-based implementation.

The fix is relatively easy, a champion is welcome!

----------
components: asyncio
messages: 409309
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Wrong base class for transport returned by loop.create_datagram_endpoint()
versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Dec 29 13:38:47 2021
From: report at bugs.python.org (Mehdi2277)
Date: Wed, 29 Dec 2021 18:38:47 +0000
Subject: [New-bugs-announce] [issue46195] Annotated and Optional
 get_type_hints buggy interaction
Message-ID: <1640803127.78.0.466747350347.issue46195@roundup.psfhosted.org>


New submission from Mehdi2277 <med2277 at gmail.com>:

This is two closely related issues with get_type_hints on an optional annotated member. I'm testing with Annotated/get_type_hints from typing extensions on 3.8 and assuming they're backport equivalent to current behavior.

The first issue is get_type_hints has inconsistent behavior depending on whether annotation comes from a function with a None default or an attribute with a None default.

class Foo:
    def __init__(
        self,
        x: 
            Annotated[Optional[str], "doc string"] = None,
    ):
        ...

class Foo2:
    x: Annotated[Optional[str], "doc string"] = None

get_type_hints(Foo.__init__) 
# {'x': typing.Union[typing_extensions.Annotated[typing.Union[str, NoneType], 'doc string'], NoneType]}

get_type_hints(Foo2)
# {'x': typing_extensions.Annotated[typing.Union[str, NoneType], 'doc string']}

Attributes with a None default are not wrapped by get_type_hints, but function parameters. Which of the two behaviors is correct I don't know, but I'd expect the two to be equivalent annotations.

The second issue is for function arguments with a None default the optional wrapper happens even if the type inside annotated already has optional. Example,

from typing_extensions import Annotated, get_type_hints

class Foo:
    def __init__(
        self,
        x: 
            Annotated[Optional[str], "doc string"] = None,
    ):
        ...

get_type_hints(Foo.__init__, include_extras=True)
# {'x': typing.Union[typing_extensions.Annotated[typing.Union[str, NoneType], 'doc string'], NoneType]}


For Annotated types I would expect any type rules like wrapping to apply only to the first argument and not the entire annotation. I mainly ran into this for a runtime type introspection library (similar in spirit to pydantic).

As a note include_extras being True or False while it changes type is an issue in either case. With include_extras as False the Annotated goes away, but the type still gets double wrapped as an Optional.

----------
messages: 409319
nosy: gvanrossum, kj, med2277
priority: normal
severity: normal
status: open
title: Annotated and Optional get_type_hints buggy interaction
versions: Python 3.8

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

From report at bugs.python.org  Wed Dec 29 17:35:57 2021
From: report at bugs.python.org (sharewell)
Date: Wed, 29 Dec 2021 22:35:57 +0000
Subject: [New-bugs-announce] [issue46196] documentation for cmd library
 should include columnize() function
Message-ID: <1640817357.67.0.539360584483.issue46196@roundup.psfhosted.org>


New submission from sharewell <jawed at sharewellnow.com>:

Cmd.columnize is an extremely useful function in Python, that can be used in many situations. It is part of the Cmd library. Unfortunately, the Cmd documentation does not mention it. It should. I only found out about it via https://stackoverflow.com/a/59627245

Please add to the documentation: https://docs.python.org/3/library/cmd.html

----------
assignee: docs at python
components: Documentation
messages: 409332
nosy: docs at python, sharewell
priority: normal
severity: normal
status: open
title: documentation for cmd library should include columnize() function
versions: Python 3.11

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

From report at bugs.python.org  Wed Dec 29 18:24:11 2021
From: report at bugs.python.org (kcdodd)
Date: Wed, 29 Dec 2021 23:24:11 +0000
Subject: [New-bugs-announce] [issue46197] ensurepip bootstrap breaks out of
 isolated environment
Message-ID: <1640820251.78.0.719610352005.issue46197@roundup.psfhosted.org>


New submission from kcdodd <carter.dodd at gmail.com>:

A change in behavior was made to the `ensurepip` module in Python 3.8.7 that causes bootstrapping to break out of an isolated environment. This is relevant to the assumption made in the `venv` module, which ran ensurepip as a sub-process with the `-I` flag environment isolation to force installation in the virtual environment directory.

In Python <= 3.8.6, ensurepip ran the bootstrap within the current interpreter, so the environment remained isolated. But in Python >= 3.8.7 it creates a second subprocess without the `-I` flag, and the un-isolated environment appears to be restored for pip. This would then allow a search of any additional paths, and prevent installation of pip and setuptools from being installed in the venv environment directory if they are found somewhere else.

----------
messages: 409334
nosy: kcdodd
priority: normal
severity: normal
status: open
title: ensurepip bootstrap breaks out of isolated environment
type: behavior
versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Dec 29 19:23:42 2021
From: report at bugs.python.org (Nikita Sobolev)
Date: Thu, 30 Dec 2021 00:23:42 +0000
Subject: [New-bugs-announce] [issue46198] Duplicated test name
 `test_get_unstructured_invalid_ew` in `test__header_value_parser.py`
Message-ID: <1640823822.61.0.842322675872.issue46198@roundup.psfhosted.org>


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

There are two tests with the same name in a same test class in `Lib/test/test_email/test__header_value_parser.py`: `test_get_unstructured_invalid_ew`

1. https://github.com/python/cpython/blob/8e11237c5d24e649b26cc928b52bc37f2fde9c7a/Lib/test/test_email/test__header_value_parser.py#L304
2. https://github.com/python/cpython/blob/8e11237c5d24e649b26cc928b52bc37f2fde9c7a/Lib/test/test_email/test__header_value_parser.py#L398

So, because of this bad naming - the first test is always shadowed by the second one and is silently skipped. With my patch: 1660 tests, without: 1659 tests.

PR to rename the second test is on its way.

----------
components: Tests
messages: 409338
nosy: sobolevn
priority: normal
severity: normal
status: open
title: Duplicated test name `test_get_unstructured_invalid_ew` in `test__header_value_parser.py`
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Wed Dec 29 21:23:22 2021
From: report at bugs.python.org (wby78826)
Date: Thu, 30 Dec 2021 02:23:22 +0000
Subject: [New-bugs-announce] [issue46199] Calculation influenced by print
Message-ID: <1640831002.13.0.0752515074236.issue46199@roundup.psfhosted.org>


New submission from wby78826 <wby78826 at boofx.com>:

(Could be a numpy bug)
##Just run the script, then uncomment Line 14 and run again
The result of "supertrend" is different, depending on whether I print "LB" first or not.
If I don't print it first, the result is wrong.

It also does'nt matter if I print it to stdout or stderr, it only works this way.

(sry if I did something wrong)

----------
components: Windows
files: supertrend.py
messages: 409343
nosy: paul.moore, steve.dower, tim.golden, wby78826, zach.ware
priority: normal
severity: normal
status: open
title: Calculation influenced by print
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file50527/supertrend.py

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

From report at bugs.python.org  Thu Dec 30 02:44:15 2021
From: report at bugs.python.org (Arie Bovenberg)
Date: Thu, 30 Dec 2021 07:44:15 +0000
Subject: [New-bugs-announce] [issue46200] Discourage logging f-strings due
 to security considerations
Message-ID: <1640850255.25.0.496981368409.issue46200@roundup.psfhosted.org>


New submission from Arie Bovenberg <a.c.bovenberg at gmail.com>:

(I've already submitted this issue to security at python.org, who directed me to propose a documentation change here)

Logging f-strings is quite popular, because the `%` style of logging is often considered ugly.
However, logging preformatted strings comes with security risks which should explicitly be mentioned in the logging documentation.

The following example illustrates the problem:

    logger.info('look: %s', untrusted_string)                # OK
    logger.info('look: %(foo)s', {'foo', untrusted_string})  # OK
    logger.info(f'look: {untrusted_string}')                 # OK (security-wise)
    logger.info(f'look: {untrusted_string}', some_dict)      # DANGER!

The problem is that `untrusted_string` will be interpreted as a string template by the logger. 
If `untrusted_string` has the value `%(foo)999999999s` (where foo is present in `some_dict`), 
logging gets stuck trying to add over a gigabyte of whitespace to a string. 
In other words: a Denial-of-Service attack.

Of course, this combination of f-string and logger arguments is unlikely. But it is plausible that:
- After a refactoring to f-string, removing the dict argument is forgotten;
- A developer adding a variable to a message prefers using f-strings and thus creates a template mixing the two styles (e.g. `{foo} and %(bar)s`);
- The string is passed through a logging Filter or other function which adds a dict argument.

Open questions:
1. Do we want to simply highlight the risks, or actively discourage logging f-strings?

   My thoughts:
   I feel it's important enough to actively discourage logging preformatted strings (i.e. also .format and manual %-formatting).
   A strong recommendation will allow security linters to flag this.
   Additionally, there are other advantages to the formatting built into `logging` (e.g. performance).

2. Should we type annotate logger `msg` as `Literal[str]` following PEP675?

   My thoughts:
   Annotating `msg` as a literal string will greatly help enforce this best practice.
   The adoption of typecheckers exceeds that of security linters.

3. Where should this risk be documented?
  a. In the `logger.debug` function docs
  b. In the `logging` docs introduction (like xml.etree.elementtree)
  c. In a new "security" section of the `logging` docs
  d. An informational PEP on logging security considerations (similar to PEP672)

  My thoughts:
  I fear option (a) would not get the attention of most readers.
  Option (c) or (d) may be useful to also highlight general risks 
  of logging (i.e. log injection)

As soon as there is agreement on these questions, I would be happy to submit a PR.

----------
assignee: docs at python
components: Documentation
messages: 409352
nosy: ariebovenberg, docs at python
priority: normal
severity: normal
status: open
title: Discourage logging f-strings due to security considerations
type: security
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Dec 30 04:30:15 2021
From: report at bugs.python.org (Carl Drougge)
Date: Thu, 30 Dec 2021 09:30:15 +0000
Subject: [New-bugs-announce] [issue46201] PEP 495 misnames
 PyDateTime_DATE_GET_FOLD
Message-ID: <1640856615.86.0.436530713038.issue46201@roundup.psfhosted.org>


New submission from Carl Drougge <bugs.python.org at s.z42.net>:

PEP 495 names one of the accessor macros PyDateTime_GET_FOLD but the code names it PyDateTime_DATE_GET_FOLD.

The FOLD macros are also missing from https://docs.python.org/3/c-api/datetime.html (and versions).

----------
assignee: docs at python
components: Documentation
messages: 409354
nosy: docs at python, drougge
priority: normal
severity: normal
status: open
title: PEP 495 misnames PyDateTime_DATE_GET_FOLD
type: behavior
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Dec 30 05:16:16 2021
From: report at bugs.python.org (Irit Katriel)
Date: Thu, 30 Dec 2021 10:16:16 +0000
Subject: [New-bugs-announce] [issue46202] remove opcode
 POP_EXCEPT_AND_RERAISE
Message-ID: <1640859376.18.0.58534498395.issue46202@roundup.psfhosted.org>


New submission from Irit Katriel <iritkatriel at gmail.com>:

Following issue45711 this opcode can be replaced by 

ADDOP(c, ROT_THREE);
ADDOP(c, ROT_THREE);
ADDOP(c, POP_EXCEPT);
ADDOP_I(c, RERAISE, 1);

----------
assignee: iritkatriel
components: Interpreter Core
messages: 409356
nosy: iritkatriel
priority: normal
severity: normal
status: open
title: remove opcode POP_EXCEPT_AND_RERAISE
versions: Python 3.11

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

From report at bugs.python.org  Thu Dec 30 06:06:59 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 30 Dec 2021 11:06:59 +0000
Subject: [New-bugs-announce] [issue46203] Add timeout for Windows build steps
Message-ID: <1640862419.94.0.348307028163.issue46203@roundup.psfhosted.org>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Recently there was an upstream issue with GitHub Actions that caused the Windows build steps in build.yml to hang. No output for the step was displayed in the build logs until the entire job was eventually cancelled, after the default step timeout of 6 hours.

I don't know how to fix the "no output" problem, but we can mitigate the 6 hour wait by adding a timeout for the build step. Some external discussion suggested that a conservative timeout of 30 minutes would be appropriate; looking at recent PRs, the build usually completes in around 5 minutes.

The (soon-to-be-)attached PR adds that timeout.

Here's the log from one of the failed jobs: https://github.com/python/cpython/runs/4641823914?check_suite_focus=true  (note that this link will probably eventually become invalid).

Here's the relevant GitHub incident: https://www.githubstatus.com/incidents/gh0vvxtlj5v7

----------
messages: 409359
nosy: christian.heimes, mark.dickinson, steve.dower
priority: normal
severity: normal
status: open
title: Add timeout for Windows build steps
versions: Python 3.11

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

From report at bugs.python.org  Thu Dec 30 08:42:32 2021
From: report at bugs.python.org (David Mc Dougall)
Date: Thu, 30 Dec 2021 13:42:32 +0000
Subject: [New-bugs-announce] [issue46204] Graphlib documentation (general
 cleanup)
Message-ID: <1640871752.23.0.818403233457.issue46204@roundup.psfhosted.org>


New submission from David Mc Dougall <dam1784 at g.rit.edu>:

The graphlib documentation has some grammar & phrasing issues.

----------
components: Library (Lib)
messages: 409370
nosy: dam1784
priority: normal
severity: normal
status: open
title: Graphlib documentation (general cleanup)
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Thu Dec 30 12:12:53 2021
From: report at bugs.python.org (Sam Gross)
Date: Thu, 30 Dec 2021 17:12:53 +0000
Subject: [New-bugs-announce] [issue46205] Race condition in runtest_mp leads
 to hangs (never exits)
Message-ID: <1640884373.19.0.652074258131.issue46205@roundup.psfhosted.org>


New submission from Sam Gross <colesbury at gmail.com>:

The runtest_mp.py has a race condition between checking for worker.is_alive() and processing the queue that can lead to indefinite hangs.

The hang happens when the all the results from the self.output queue are processed but at least one of the workers hasn't finished exiting.

https://github.com/python/cpython/blob/8d7644fa64213207b8dc6f555cb8a02bfabeced2/Lib/test/libregrtest/runtest_mp.py#L394-L418

The main thread tries to get a result from the output queue, but the queue is empty and remains empty. Although the queue.get() operation eventually times out (after 30 seconds), the main thread does not re-check if all the workers have exited (!), but instead retries the queue.get() in the "while True" loop.

https://github.com/python/cpython/blob/8d7644fa64213207b8dc6f555cb8a02bfabeced2/Lib/test/libregrtest/runtest_mp.py#L415-L418

To reproduce, apply the below patch which introduces a small delay to more reliably trigger the hang.

curl "https://gist.githubusercontent.com/colesbury/fe3769f43dfb724c86ecbb182b1f6749/raw/e29a4eaeebb8d5252cdd66f3f8a70f7bc5fa14e7/runtest_mp.diff" | patch -p1
./python -m test test_regrtest -m test_module_from_test_autotest -v

----------
messages: 409374
nosy: colesbury
priority: normal
severity: normal
status: open
title: Race condition in runtest_mp leads to hangs (never exits)
versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Dec 30 14:00:20 2021
From: report at bugs.python.org (M Z)
Date: Thu, 30 Dec 2021 19:00:20 +0000
Subject: [New-bugs-announce] [issue46206] Crash when editing emoji
 containing strings
Message-ID: <1640890820.86.0.186821451382.issue46206@roundup.psfhosted.org>


New submission from M Z <10maurycy10 at gmail.com>:

Reproduction steps:
0. start rpel. command: ``python``
1. enter into  '___?'
2. use arrow keys and backspace to delete an underscore
3. press enter.
4. observe segfault

- insertion of chars before emoji can also cause crash

back trace (gdb):

```
(gdb) bt
#0  0x00007ffff7495d22 in raise () from /lib/libc.so.6
#1  0x00007ffff747f862 in abort () from /lib/libc.so.6
#2  0x00007ffff747f747 in __assert_fail_base.cold () from /lib/libc.so.6
#3  0x00007ffff748e616 in __assert_fail () from /lib/libc.so.6
#4  0x00007ffff77e7b6e in get_error_line (p=p at entry=0x7ffff6e53b80, lineno=lineno at entry=0) at Parser/pegen.c:438
#5  0x00007ffff7b3660d in _PyPegen_raise_error_known_location (p=p at entry=0x7ffff6e53b80, errtype=errtype at entry=0x7ffff7e7ac00 <_PyExc_SyntaxError>, lineno=0, col_offset=0, end_lineno=0, end_col_offset=-1, errmsg=0x7ffff7c84bcd "(%s) %U",
    va=0x7fffffffdcb0) at Parser/pegen.c:491
#6  0x00007ffff7b36d33 in _PyPegen_raise_error (p=p at entry=0x7ffff6e53b80, errtype=0x7ffff7e7ac00 <_PyExc_SyntaxError>, errmsg=errmsg at entry=0x7ffff7c84bcd "(%s) %U") at Parser/pegen.c:422
#7  0x00007ffff7b37213 in raise_decode_error (p=p at entry=0x7ffff6e53b80) at Parser/pegen.c:271
#8  0x00007ffff7bbed14 in initialize_token (token_type=60, end=0x0, start=<optimized out>, token=0x7ffff6ffb330, p=0x7ffff6e53b80) at Parser/pegen.c:712
#9  _PyPegen_fill_token (p=p at entry=0x7ffff6e53b80) at Parser/pegen.c:785
#10 0x00007ffff7c5eca1 in statement_newline_rule (p=0x7ffff6e53b80) at Parser/parser.c:1521
#11 interactive_rule (p=0x7ffff6e53b80) at Parser/parser.c:994
#12 _PyPegen_parse (p=p at entry=0x7ffff6e53b80) at Parser/parser.c:33180
#13 0x00007ffff7bd5784 in _PyPegen_run_parser (p=p at entry=0x7ffff6e53b80) at Parser/pegen.c:1343
#14 0x00007ffff7bd8e72 in _PyPegen_run_parser_from_file_pointer (fp=fp at entry=0x7ffff7619800 <_IO_2_1_stdin_>, start_rule=start_rule at entry=256, filename_ob=filename_ob at entry=0x7ffff7155490, enc=enc at entry=0x7ffff714bdb0 "utf-8",
    ps1=ps1 at entry=0x7ffff7155c40 ">>> ", ps2=ps2 at entry=0x7ffff6ffafa0 "... ", flags=0x7fffffffe0f8, errcode=0x7fffffffdfe4, arena=0x7ffff6feb820) at Parser/pegen.c:1440
#15 0x00007ffff7bd903e in _PyParser_ASTFromFile (fp=fp at entry=0x7ffff7619800 <_IO_2_1_stdin_>, filename_ob=filename_ob at entry=0x7ffff7155490, enc=enc at entry=0x7ffff714bdb0 "utf-8", mode=mode at entry=256, ps1=ps1 at entry=0x7ffff7155c40 ">>> ",
    ps2=ps2 at entry=0x7ffff6ffafa0 "... ", flags=0x7fffffffe0f8, errcode=0x7fffffffdfe4, arena=0x7ffff6feb820) at Parser/peg_api.c:26
#16 0x00007ffff7bd9205 in PyRun_InteractiveOneObjectEx (fp=fp at entry=0x7ffff7619800 <_IO_2_1_stdin_>, filename=filename at entry=0x7ffff7155490, flags=flags at entry=0x7fffffffe0f8) at Python/pythonrun.c:257
#17 0x00007ffff7bda02d in _PyRun_InteractiveLoopObject (fp=0x7ffff7619800 <_IO_2_1_stdin_>, filename=0x7ffff7155490, flags=0x7fffffffe0f8) at Python/pythonrun.c:148
#18 0x00007ffff7bdbbc7 in _PyRun_AnyFileObject (fp=0x7ffff7619800 <_IO_2_1_stdin_>, filename=0x7ffff7155490, closeit=0, flags=0x7fffffffe0f8) at Python/pythonrun.c:84
#19 0x00007ffff7bdbdf3 in PyRun_AnyFileExFlags (fp=0x7ffff7619800 <_IO_2_1_stdin_>, filename=<optimized out>, closeit=0, flags=0x7fffffffe0f8) at Python/pythonrun.c:116
#20 0x00007ffff7bddf60 in pymain_run_stdin (config=0x55555555f910) at Modules/main.c:502
#21 pymain_run_python (exitcode=0x7fffffffe0f0) at Modules/main.c:590
#22 Py_RunMain () at Modules/main.c:666
#23 0x00007ffff7bde683 in pymain_main (args=args at entry=0x7fffffffe250) at Modules/main.c:696
#24 0x00007ffff7bde7f9 in Py_BytesMain (argc=argc at entry=1, argv=argv at entry=0x7fffffffe3a8) at Modules/main.c:720
#25 0x00005555555560af in main (argc=1, argv=0x7fffffffe3a8) at ./Programs/python.c:15
(gdb)
```

----------
components: Unicode
messages: 409379
nosy: 10maurycy10, ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: Crash when editing emoji containing strings
versions: Python 3.10

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

From report at bugs.python.org  Thu Dec 30 14:31:56 2021
From: report at bugs.python.org (David Fritz)
Date: Thu, 30 Dec 2021 19:31:56 +0000
Subject: [New-bugs-announce] [issue46207] Log emit performance degradation
 in RotatingFileHandlers due to filesystem checks
Message-ID: <1640892716.93.0.621207003678.issue46207@roundup.psfhosted.org>


New submission from David Fritz <dfritz at purestorage.com>:

I believe this also impacts 3.10 and 3.11 based on the original bpo-45401 which led to this change. Prior to commit ac421c348b in the 3.9 branch there were no additional os.path checks in the shouldRollover() methods of RotatingFileHandler and TimedRotatingFileHandler, which led to maximum performance regardless of where log files existed. With the new "os.path.exists(self.baseFilename) and not os.path.isfile(self.baseFilename)" checks added to these functions, a varying performance degradation is seen if the log lives on a filesystem that is not a local disk. It is hard for me to strictly call this a "regression", since I understand the reason of the original change (only rollover regular files), but I feel this is something developers should be aware of, or possibly have a way to disable (without making their own subclass) since this cost was not incurred before.

For example, let's say we have user home folders as mounts via S3FS, and each user has a log stored in their home folders. Since there are now os.path checks on every single emit call, performance of logging is now directly impacted by networking latency if using one of these native logging handlers. This came as quite a surprise when upgrading to 3.9.8+, when operations that were previously taking ~2 seconds were now taking ~2 1/2 minutes. This is reproducible (once you have a similar external filesystem mounted) using the following script (also attached):


# vi logtest.py
import logging
import logging.handlers

logging.basicConfig(filename="test.log", level=logging.INFO)
logger = logging.getLogger("test_logger")
log_handler = logging.handlers.TimedRotatingFileHandler("test.log", when='D', backupCount=2)
logger.addHandler(log_handler)

for i in range(0, 10000):
    logger.info("iteration: %d", i)


As seen between the commits, cost spikes due to the new calls (double the amount of log emit calls):

$ time /build_397/bin/python3 -m cProfile logtest.py |awk '$5>0.00'
...[truncated output to highest percall items]...
ncalls  tottime  percall  cumtime  percall filename:lineno(function)
  12/1    0.000    0.000    0.549    0.549 {built-in method builtins.exec} # 3.9.7_d57d33c234 (no posix.stat calls)
  12/1    0.000    0.000   70.125   70.125 {built-in method builtins.exec} # 3.9.7_ac421c348b
 20100   68.972    0.003   68.972    0.003 {built-in method posix.stat}    # 3.9.7_ac421c348b

This performance degradation is further compounded if for example you have logging being performed inside threads, where locks have to be obtained. This is actually how I noticed it originally, because I was attempting to use the cProfile module to find what was taking so long. I ended up testing several python versions to make sure I was not crazy, before identifying the exact commit where the change in performance occurred.

ncalls  tottime  percall  cumtime  percall filename:lineno(function)
    67    0.661    0.010    0.661    0.010 {method 'acquire' of '_thread.lock' objects} # 3.7.8
    67    1.237    0.018    1.237    0.018 {method 'acquire' of '_thread.lock' objects} # 3.9.0
    67    1.293    0.019    1.293    0.019 {method 'acquire' of '_thread.lock' objects} # 3.9.4
    67    0.756    0.011    0.756    0.011 {method 'acquire' of '_thread.lock' objects} # 3.9.6
    67    1.218    0.018    1.218    0.018 {method 'acquire' of '_thread.lock' objects} # 3.9.7
    67  152.411    2.275  152.411    2.275 {method 'acquire' of '_thread.lock' objects} # 3.9.8
    67  152.382    2.274  152.382    2.274 {method 'acquire' of '_thread.lock' objects} # 3.9.9

Ultimately I do not have a recommendation for a native fix that keeps both the improvement from the commit, and the performance from before the commit. Perhaps caching the results of the checks until there is a rollover? Only perform the check on initial handler creation? Otherwise it appears the only solution is to subclass and override the shouldRollover() to not include the os.path checks and match <=3.9.7 behavior. This is the solution I am implementing in the codebase/environment where this was discovered while this report is discussed further. This feels less than ideal, but if that is the consensus then hopefully this report can help the next person to come across it. Thank you for your time and all the hard work put into Python!

----------
files: logtest.py
messages: 409381
nosy: dfritz
priority: normal
severity: normal
status: open
title: Log emit performance degradation in RotatingFileHandlers due to filesystem checks
type: performance
versions: Python 3.10, Python 3.11, Python 3.9
Added file: https://bugs.python.org/file50529/logtest.py

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

From report at bugs.python.org  Thu Dec 30 14:38:30 2021
From: report at bugs.python.org (Hugo van Kemenade)
Date: Thu, 30 Dec 2021 19:38:30 +0000
Subject: [New-bugs-announce] [issue46208] os.path.normpath change between
 3.11.0a2 and 3.11.0a3+
Message-ID: <1640893110.04.0.882099438605.issue46208@roundup.psfhosted.org>


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

The behaviour of os.path.normpath appears to have changed between Python 3.10/Python 3.11.0a2 and 3.11.0a3+.

I don't see anything mentioned in https://docs.python.org/3.11/whatsnew/3.11.html

Is this intentional?


Old behaviour:

Python 3.10.1 (v3.10.1:2cd268a3a9, Dec  6 2021, 14:28:59) [Clang 13.0.0 (clang-1300.0.29.3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from os.path import normpath
>>> normpath('handbook/../../Tests/image.png')
'../Tests/image.png'
>>>


Python 3.11.0a2 (main, Dec 30 2021, 21:22:15) [Clang 13.0.0 (clang-1300.0.29.30)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from os.path import normpath
>>> normpath('handbook/../../Tests/image.png')
'../Tests/image.png'
>>>


New behaviour:

Python 3.11.0a3+ (heads/main:af6b406, Dec  9 2021, 15:34:48) [Clang 13.0.0 (clang-1300.0.29.3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from os.path import normpath
>>> normpath('handbook/../../Tests/image.png')
'Tests/image.png'
>>>


Python 3.11.0a3+ (heads/main:8d7644f, Dec 30 2021, 21:32:51) [Clang 13.0.0 (clang-1300.0.29.30)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from os.path import normpath
>>> normpath('handbook/../../Tests/image.png')
'Tests/image.png'
>>>

(Found in https://github.com/sphinx-doc/sphinx/issues/10030.)

----------
components: Library (Lib)
messages: 409384
nosy: hugovk
priority: normal
severity: normal
status: open
title: os.path.normpath change between 3.11.0a2 and 3.11.0a3+
versions: Python 3.11

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

From report at bugs.python.org  Thu Dec 30 16:23:58 2021
From: report at bugs.python.org (Guo Ci Teo)
Date: Thu, 30 Dec 2021 21:23:58 +0000
Subject: [New-bugs-announce] [issue46209] add documentation for decoding
 newlines in the `io` module
Message-ID: <1640899438.69.0.632491877806.issue46209@roundup.psfhosted.org>


New submission from Guo Ci Teo <zguoci at gmail.com>:

add documentation for
`io.IncrementalNewlineDecoder`
`io.TextIOWrapper`
`io.StringIO`,
listing various ways to decode newlines

----------
messages: 409388
nosy: guoci
priority: normal
severity: normal
status: open
title: add documentation for decoding newlines in the `io` module

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

From report at bugs.python.org  Thu Dec 30 18:26:14 2021
From: report at bugs.python.org (Jason Wilkes)
Date: Thu, 30 Dec 2021 23:26:14 +0000
Subject: [New-bugs-announce] [issue46210] print deadlocks
Message-ID: <1640906774.22.0.0895418196174.issue46210@roundup.psfhosted.org>


New submission from Jason Wilkes <notarealdeveloper at gmail.com>:

Hi there. :)

(First time posting here, so apologies in advance if I'm a goof.)

I recently found a deadlock in the stdout and stderr buffer objects.

Following the dev guide, I

(1) wrote up a patch

(2) checked that it fixes the deadlock (on Linux and OS X)

(3) made sure it doesn't break any of the cpython tests (on Linux and OS X)

But I could use some feedback to make sure the patch isn't doing anything dumb, and to make sure I'm not missing something obvious.

Here's the situation.

The deadlock only occurs in the sinful state of threading while forking. (I'm aware of the reasons why one should never do that.)

But asking newcomers to never mix the two is sort of asking them to know the implementation details of every library they use (these abstractions are leaky). And I like teaching people about python and concurrency, so it would be nice if they didn't have to know all that.

So I've recently developed the ill-advised hobby of trying to run as much code as possible in the sinful state of threading while forking, to try to understand which bits of the interpreter and standard library are responsible for most of the deadlocks, in practice.

All the non-obvious deadlocks I've encountered seemed to be due to one thing, namely stdout and stderr's buffer->lock not having an _at_fork_reinit. So if a thread is printing during a fork, the child process can never print, else deadlock. Standard hazard of threading and forking.

What surprised me was that there didn't seem to be 100s of places in the interpreter where threading and forking don't mix. After fixing this one, all the different thread + fork code I'd been testing worked.

Which makes me wonder if there's a reason this hasn't been fixed yet.

Hence, maybe the patch is doing something dumb.

Anyways, this is sort of a bug report, and sort of a request for comments on how I can make this patch better. Equally cool would be an explanation of why re-initializing that lock is a bad idea to begin with.

Thanks for your patience if you read all that.

----------
components: IO
files: example.py
messages: 409394
nosy: notarealdeveloper
priority: normal
severity: normal
status: open
title: print deadlocks
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9
Added file: https://bugs.python.org/file50532/example.py

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

From report at bugs.python.org  Fri Dec 31 00:45:05 2021
From: report at bugs.python.org (Xinmeng Xia)
Date: Fri, 31 Dec 2021 05:45:05 +0000
Subject: [New-bugs-announce] [issue46211] Recursively calling makepasv()
 finally leads to core dumped.
Message-ID: <1640929505.72.0.774878078134.issue46211@roundup.psfhosted.org>


New submission from Xinmeng Xia <xiaxm at smail.nju.edu.cn>:

See the following 'test.py', we call client.makepasv() in socket, and then create_connection. Recursively calling makepasv() finally leads to core dumped.

System: Python 3.10.1, 3.11.0a3 ,master on Ubuntu 18.04
  
Reproduce step: 
1. executing "python test.py"
2. If only TimeoutError is observed, just executing this code again. Maybe after 4 or 5 times, this program crashes Python interpreter.


test.py
===============================================
import socket
from test.test_ftplib import TestFTPClass,TIMEOUT

def test_makepasv():
    host, port = TestFTPClass.client.makepasv()
    conn = socket.create_connection((test_makepasv(), host), timeout=TIMEOUT)
    conn.close()
===============================================

Error Message:
---------------------------------------------------
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/home/xxm/Desktop/compilers/cpython-main12-31/Lib/asyncore.py", line 90, in read
    obj.handle_read_event()
    ^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/xxm/Desktop/compilers/cpython-main12-31/Lib/asyncore.py", line 427, in handle_read_event
Traceback (most recent call last):
.....
  File "/home/xxm/Desktop/compilers/cpython-main12-31/Lib/test/test_ftplib.py", line 298, in run
    return self._sock.recv_into(b)
           ^^^^^^^^^^^^^^^^^^^^^^^
TimeoutError: timed out
Fatal Python error: _enter_buffered_busy: could not acquire lock for <_io.BufferedWriter name='<stderr>'> at interpreter shutdown, possibly due to daemon threads
Python runtime state: finalizing (tstate=0x0000556df3cfbe30)

Current thread 0x00007fb82ce69080 (most recent call first):
  <no Python frame>

Extension modules: _testcapi (total: 1)
Aborted (core dumped)
-----------------------------------------------------

----------
components: Library (Lib)
messages: 409408
nosy: xxm
priority: normal
severity: normal
status: open
title: Recursively calling makepasv() finally leads to core dumped.
type: crash
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Fri Dec 31 05:05:47 2021
From: report at bugs.python.org (colorfulappl)
Date: Fri, 31 Dec 2021 10:05:47 +0000
Subject: [New-bugs-announce] [issue46212] Avoid temporary `varargs` tuple
 creation in argument passing
Message-ID: <1640945147.14.0.155789461509.issue46212@roundup.psfhosted.org>


New submission from colorfulappl <colorfulappl at qq.com>:

When "Augument Clinic generated code" are parsing arguments, the args are packed to a tuple before passing to callee. This may be unnecessary.

Pass a raw pointer which points to on-stack varargs, and a varargssize integer to indicate how many varargs are passed, can save the time of tuple creation/destruction and value copy.

----------
components: Argument Clinic
messages: 409412
nosy: colorfulappl, erlendaasland, larry
priority: normal
severity: normal
status: open
title: Avoid temporary `varargs` tuple creation in argument passing
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Fri Dec 31 11:11:15 2021
From: report at bugs.python.org (DonaldDuck313)
Date: Fri, 31 Dec 2021 16:11:15 +0000
Subject: [New-bugs-announce] [issue46213] webbrowser.open doesn't work in
 Termux
Message-ID: <1640967075.78.0.947803082888.issue46213@roundup.psfhosted.org>


New submission from DonaldDuck313 <kalle.anka.ank at gmail.com>:

In Termux, if I type the following code, I would expect it to open the URL in a browser, but it does nothing:

import webbrowser
webbrowser.open("http://example.com")

----------
components: Library (Lib)
messages: 409422
nosy: DonaldDuck1313
priority: normal
pull_requests: 28530
severity: normal
status: open
title: webbrowser.open doesn't work in Termux
versions: Python 3.10

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

From report at bugs.python.org  Fri Dec 31 12:07:49 2021
From: report at bugs.python.org (Irit Katriel)
Date: Fri, 31 Dec 2021 17:07:49 +0000
Subject: [New-bugs-announce] [issue46214] Remove unused opcode ROT_FOUR
Message-ID: <1640970469.6.0.457340037474.issue46214@roundup.psfhosted.org>


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


----------
assignee: iritkatriel
components: Interpreter Core
nosy: iritkatriel
priority: normal
severity: normal
status: open
title: Remove unused opcode ROT_FOUR
versions: Python 3.11

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

From report at bugs.python.org  Fri Dec 31 15:46:44 2021
From: report at bugs.python.org (=?utf-8?q?beda_pi=C5=A1l?=)
Date: Fri, 31 Dec 2021 20:46:44 +0000
Subject: [New-bugs-announce] [issue46215] Wrong error line after using pdb
Message-ID: <1640983604.86.0.570920927154.issue46215@roundup.psfhosted.org>


New submission from beda pi?l <bedapisl at gmail.com>:

Consider simple script:
```
for i in range(1):
    import pdb
    pdb.set_trace()

x = y + z
```
After running it and pressing 'c' to continue:

```
test$ python test.py
> /Users/bedrich.pisl/test/test.py(1)<module>()
-> for i in range(1):
(Pdb) c
```
I get error, but with wrong error line
```
Traceback (most recent call last):
  File "/Users/bedrich.pisl/test/test.py", line 1, in <module>
    for i in range(1):
NameError: name 'y' is not defined
```
The error is actually on line 5 not 1.

----------
components: Library (Lib)
messages: 409434
nosy: bedapisl
priority: normal
severity: normal
status: open
title: Wrong error line after using pdb
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Fri Dec 31 19:00:50 2021
From: report at bugs.python.org (Emery Berger)
Date: Sat, 01 Jan 2022 00:00:50 +0000
Subject: [New-bugs-announce] [issue46216] spurious link to os.system() from
 os.times() documentation entry
Message-ID: <1640995250.13.0.0626118666649.issue46216@roundup.psfhosted.org>


New submission from Emery Berger <emery.berger at gmail.com>:

This is a minor documentation nit.

Under the entry for `os.times()`, there is a description of the various fields it returns (e.g., `user`, `system`).

```os.times()
Returns the current global process times. The return value is an object with five attributes:

user - user time

system - system time
```

For the latter, the word `system` is hyperlinked to the `os.system()` entry. This probably goes without saying, but there's no logical relationship of system time (time spent in the kernel on behalf of the process) to the system command (which invokes a command via a shell), so the link should be removed.

----------
assignee: docs at python
components: Documentation
messages: 409442
nosy: docs at python, emery.berger
priority: normal
severity: normal
status: open
title: spurious link to os.system() from os.times() documentation entry
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Dec 31 20:28:36 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 01 Jan 2022 01:28:36 +0000
Subject: [New-bugs-announce] [issue46217] 3.11 build failure on Win10: new
 _freeze_module changes?
Message-ID: <1641000516.27.0.500789613902.issue46217@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Installed 3.11.0a3 was built Dec  8 2021, 22:56:33.  My corresponding repository build is a bit older than that.  Rebuilding now I get
  fileutils.c
..\Python\fileutils.c(2132): error C2065: 'PATHCCH_FORCE_ENABLE_LONG_NAME_PROCE
SS': undeclared identifier [f:\dev\3x\PCbuild\_freeze_module.vcxproj]

I have likely seen this before today but mistook the error message for a warning and did not check the respository build date.  3.9 and 3.10 just update normally, so unique to 3.11 and apparently new freeze changes.

----------
components: Build
messages: 409445
nosy: terry.reedy
priority: normal
severity: normal
status: open
title: 3.11 build failure on Win10: new _freeze_module changes?
versions: Python 3.11

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

From report at bugs.python.org  Fri Dec 31 20:46:39 2021
From: report at bugs.python.org (Tim Peters)
Date: Sat, 01 Jan 2022 01:46:39 +0000
Subject: [New-bugs-announce] [issue46218] Change long_pow() to sliding
 window algorithm
Message-ID: <1641001599.99.0.180996324134.issue46218@roundup.psfhosted.org>


New submission from Tim Peters <tim at python.org>:

As discussed on python-dev, it would be nice to break long_pow()'s reliance on that the number of bits in a CPython long "digit" is a multiple of 5.

Moving to the sliding-window algorithm would do that (it has to be able to cross digit boundaries to fill the current window), and would be better on some other counts too: the precomputed table can be half the size (or we can add an extra bit to the window for the same table size), and it can - depending on exponent bit patterns - sometimes reduce the number of multiplies needed too.

So I intend to do that, and bump the window size from 5 to 6 (which would yield a significant, although modest, speed improvement for giant-exponent cases).

----------
assignee: tim.peters
components: Interpreter Core
messages: 409446
nosy: tim.peters
priority: normal
severity: normal
stage: needs patch
status: open
title: Change long_pow() to sliding window algorithm
type: performance
versions: Python 3.11

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