From report at bugs.python.org  Tue Jun  1 01:08:47 2021
From: report at bugs.python.org (Kshitiz Arya)
Date: Tue, 01 Jun 2021 05:08:47 +0000
Subject: [New-bugs-announce] [issue44276] Replace if-elif-else structure
 with match-case (PEP634)
Message-ID: <1622524127.91.0.692072896945.issue44276@roundup.psfhosted.org>


New submission from Kshitiz Arya <aryakshitiz17 at gmail.com>:

Replace if-elif-else with match-case for pattern matching, which is generally faster and more intuitive.

----------
components: Library (Lib)
messages: 394839
nosy: Kshitiz17
priority: normal
severity: normal
status: open
title: Replace if-elif-else structure with match-case (PEP634)
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Tue Jun  1 01:56:02 2021
From: report at bugs.python.org (Anthony Sottile)
Date: Tue, 01 Jun 2021 05:56:02 +0000
Subject: [New-bugs-announce] [issue44277] cpython forks are spammed with
 dependabot PRs
Message-ID: <1622526962.42.0.431881645294.issue44277@roundup.psfhosted.org>


New submission from Anthony Sottile <asottile at umich.edu>:

for example: https://github.com/asottile/cpython/pull/1

----------
messages: 394842
nosy: Anthony Sottile
priority: normal
severity: normal
status: open
title: cpython forks are spammed with dependabot PRs

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

From report at bugs.python.org  Tue Jun  1 06:36:54 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 01 Jun 2021 10:36:54 +0000
Subject: [New-bugs-announce] [issue44278] Improve syntax error message for
 assigning to "..."
Message-ID: <1622543814.93.0.384857928409.issue44278@roundup.psfhosted.org>


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

Some users can be confused by syntax error message for assigning to ellipsis [1]:

>>> ... = 1
  File "<stdin>", line 1
    ... = 1
    ^^^
SyntaxError: cannot assign to Ellipsis here. Maybe you meant '==' instead of '='?

because Ellipsis is a name of a builtin variable Ellipsis, and it is possible to assign to variable named Ellipsis.

>>> Ellipsis = 1
>>> Ellipsis
1

I think that using lowercase spelling of "ellipsis" will eliminate confusion.

[1] https://mail.python.org/archives/list/python-ideas at python.org/thread/KDQ3OHALLXVZJIGPC4BMPVS2XH3VFPJV/

----------
components: Interpreter Core
messages: 394849
nosy: pablogsal, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Improve syntax error message for assigning to "..."
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Tue Jun  1 14:02:31 2021
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 01 Jun 2021 18:02:31 +0000
Subject: [New-bugs-announce] [issue44279] doc: contextlib.suppress
 documentation is imprecise
Message-ID: <1622570551.2.0.610733137318.issue44279@roundup.psfhosted.org>


New submission from Irit Katriel <iritkatriel at yahoo.com>:

"suppresses any of the specified exceptions if they occur in the body of a with statement"

Should be:

"suppresses any of the specified exceptions if they are raised in the body of a with statement"

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 394863
nosy: docs at python, iritkatriel
priority: normal
severity: normal
status: open
title: doc: contextlib.suppress documentation is imprecise
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Tue Jun  1 15:42:48 2021
From: report at bugs.python.org (Peter Hawkins)
Date: Tue, 01 Jun 2021 19:42:48 +0000
Subject: [New-bugs-announce] [issue44280] unittest filters out too many
 assertion stack frames from context/cause chains
Message-ID: <1622576568.02.0.771904699767.issue44280@roundup.psfhosted.org>


New submission from Peter Hawkins <peter.hawkins at gmail.com>:

Example repro:
```
import unittest


def d():
  assert 2 == 3

def c():
  d()

def b():
  c()

def a():
  try:
    b()
  except Exception as e:
    assert 1 == 2


class MyTest(unittest.TestCase):

  def testException(self):
    a()


if __name__ == '__main__':
  unittest.main()
```

Example output from Python 3.9.0:
```
$ python atest.py
F
======================================================================
FAIL: testException (__main__.MyTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/private/tmp/atest.py", line 15, in a
    b()
  File "/private/tmp/atest.py", line 11, in b
    c()
AssertionError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/private/tmp/atest.py", line 23, in testException
    a()
  File "/private/tmp/atest.py", line 17, in a
    assert 1 == 2
AssertionError

----------------------------------------------------------------------
Ran 1 test in 0.000s

FAILED (failures=1)
```

Too many frames have been filtered out of the `__context__` exception, including a number of relevant frames for `c` and `d`. I believe this happens because unittest sets a `limit` here based on the contents of the main traceback:
https://github.com/python/cpython/blob/39dd141a4ba68bbb38fd00a65cdcff711acdafb5/Lib/unittest/result.py#L182

but that limit applies recursively to the `__context__` and `__cause__` chains, when the intent of the limit was presumably only to filter the main exception.

----------
messages: 394865
nosy: peter.hawkins
priority: normal
severity: normal
status: open
title: unittest filters out too many assertion stack frames from context/cause chains
versions: Python 3.9

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

From report at bugs.python.org  Tue Jun  1 16:16:59 2021
From: report at bugs.python.org (Andrei Kulakov)
Date: Tue, 01 Jun 2021 20:16:59 +0000
Subject: [New-bugs-announce] [issue44281] Links on top of collections doc
 not in the order of sections
Message-ID: <1622578619.23.0.835840856741.issue44281@roundup.psfhosted.org>


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

https://docs.python.org/3.11/library/collections.html

Links are not in the same order as the sections below. It creates some dissonance for the reader to first read the section names above and then continue reading expecting them to be in the same order through the page.

Seems like would be an easy fix to reorder them.

----------
assignee: docs at python
components: Documentation
messages: 394867
nosy: andrei.avk, docs at python
priority: normal
severity: normal
status: open
title: Links on top of collections doc not in the order of sections
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Tue Jun  1 16:38:25 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 01 Jun 2021 20:38:25 +0000
Subject: [New-bugs-announce] [issue44282] IDLE: ColorDelegatorTest
 test_incremental_editing failures
Message-ID: <1622579905.14.0.972004304373.issue44282@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

idlelib.idle_test.test_colordelagator.ColorDelegatorTest.test_incremental_editing has failed on at least on the following machines.  

Pip32  CI Pipelines Win32
Gen3x  https://buildbot.python.org/all/#/builders/464  x86 Gentoo Installed with X 3.x
GenPR  https://buildbot.python.org/all/#/builders/465  x86 Gentoo Installed with X PR

Failures seen.  Since tests are sequential without subtesting, failure means successors are not tested.

line  keyword start       want            got  
569   ('BUILTIN', '1.0'), ('1.0', '1.3')  ()              Gen3x, x3; GenPR
573   ('BUILTIN', '1.0'), ('1.0', '1.3')  ()              Gen3x, x5
586   ('BUILTIN', '1.0'), ('1.0', '1.3')  ()              GenPR
597   ('KEYWORD', '1.0'), ()              ('1.0', '1.1')  Pip32, x2

As far as I can tell, looking at Windows buildbots, the 1 failure on Win32 has not been repeated.  If there have been any on CI machines, I have not been informed.

A few years ago, I believe Gentoo was the only *nix buildbot running tkinter and IDLE tests. It has a problem with a builtin at the beginning of the line about 10-20% of test runs.  This are the majority of its failures in the last week.  Perhaps there is a timing issue we can fix.

----------
assignee: terry.reedy
components: IDLE, Tests
messages: 394870
nosy: taleinat, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE: ColorDelegatorTest test_incremental_editing failures
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Tue Jun  1 17:58:12 2021
From: report at bugs.python.org (Dennis Sweeney)
Date: Tue, 01 Jun 2021 21:58:12 +0000
Subject: [New-bugs-announce] [issue44283] Add jump table for certain safe
 match-case statements
Message-ID: <1622584692.02.0.792244992516.issue44283@roundup.psfhosted.org>


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

Anecdotally, a few people I've talked to have expected that match-case statements would improve performance in the same way that switch-cases sometimes do in C-like languages. While this is impossible in general without changing semantics (since, for example, __eq__ can have side effects), it would be nice if a jump table was implemented in certain safe cases.

My idea was to implement this whenever the list of cases begins with 2 or more of the following in a row:

    (1) ints
    (2) strings
    (3) None
    (4) OR (`|`) patterns of any of the above
    (5?) potentially later add support for tuples

Example:

    match x:
        case 10:             # safe
            print("A")
        case 20:             # safe
            print("B")
        case 30 | 31:        # safe
            print("C")
        case 40:             # safe
            print("D")
        case MyClass(10, 20): # unsafe
            print("E")
        case []:              # unsafe
            print("F")
        case whatever:        # unsafe
            print("G")


This would compile to something like

    LOAD_FAST (x)
    LOAD_CONST 16            ({10: 16, 20: 38, 30: 80, 31: 80, 40: 102})
    ATTEMPT_SAFE_MATCH 110

    ... all the rest of the code is the same ...

Where the new opcode would be would be something like

case TARGET(ATTEMPT_SAFE_MATCH): {
    PyObject *jump_dict = POP();
    PyObject *x = TOP();
    
    if (PyLong_CheckExact(x) ||
        PyUnicode_CheckExact(x) ||
        Py_Is(x, Py_None))
    {
        PyObject *boxed = PyDict_GetItemWithError(jump_dict, x);
        Py_DECREF(jump_dict);
        if (res == NULL) {
            if (PyErr_Occurred()) {
                goto error;
            }
            else {
                JUMPBY(oparg);
            }
        }
        assert(PyLong_CheckExact(boxed));
        int target = (int)PyLong_AsLong(boxed);
        JUMPBY(target);
    }
    else {
        // fall back to general matching code
        Py_DECREF(jump_dict);
        DISPATCH();
    }
}

I can work on an implementation in the next couple of weeks.

----------
components: Interpreter Core
messages: 394874
nosy: Dennis Sweeney
priority: normal
severity: normal
status: open
title: Add jump table for certain safe match-case statements
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Wed Jun  2 00:44:38 2021
From: report at bugs.python.org (helpimnotdrowning)
Date: Wed, 02 Jun 2021 04:44:38 +0000
Subject: [New-bugs-announce] [issue44284] Python references wrong line but
 correct line number in traceback
Message-ID: <1622609078.37.0.104205223264.issue44284@roundup.psfhosted.org>


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

To reproduce (at least on Windows 10 w/ Python 3.9.4):

1) Make a python file:

while True:
    print('hello')

2) Run the file via cmd
3) Edit the file (while it is still running):

while True:
    print('goodbye')
    print('hello')

then save it
4) ctrl+c in the cmd window to exit the script
5) The traceback will look something like this:

Traceback (most recent call last):
  File "dfbssss.py", line 2, in <module>
    print('goodbye')
KeyboardInterrupt

The traceback mentions the print('goodbye') even though it wasnt in the file when it was run. It still calls it line 2, which is the line the print('hello') was before adding the print('goodbye')

----------
messages: 394888
nosy: helpimnotdrowning
priority: normal
severity: normal
status: open
title: Python references wrong line but correct line number in traceback
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Wed Jun  2 09:39:39 2021
From: report at bugs.python.org (Charalampos Stratakis)
Date: Wed, 02 Jun 2021 13:39:39 +0000
Subject: [New-bugs-announce] [issue44285] Coverity scan: Modules/getpath.c.
 "calculate_open_pyenv" allocates memory that is stored into "env_file".
Message-ID: <1622641179.93.0.747162591311.issue44285@roundup.psfhosted.org>


New submission from Charalampos Stratakis <cstratak at redhat.com>:

This is an issue as it seems with coverity as it's an error case where the file was not actually opened. This warning can be silenced and the code be made more explicit by adding an assertion.

Python-3.9.1/Modules/getpath.c:1264: alloc_arg: "calculate_open_pyenv" allocates memory that is stored into "env_file".
Python-3.9.1/Modules/getpath.c:1266: leaked_storage: Variable "env_file" going out of scope leaks the storage it points to.
# 1264|       status = calculate_open_pyenv(calculate, &env_file);
# 1265|       if (_PyStatus_EXCEPTION(status)) {
# 1266|->         return status;
# 1267|       }
# 1268|       if (env_file == NULL) {

----------
messages: 394906
nosy: cstratak
priority: normal
severity: normal
status: open
title: Coverity scan: Modules/getpath.c. "calculate_open_pyenv" allocates memory that is stored into "env_file".
versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Jun  2 10:03:06 2021
From: report at bugs.python.org (john kim)
Date: Wed, 02 Jun 2021 14:03:06 +0000
Subject: [New-bugs-announce] [issue44286] venv activate script would be good
 to show failure.
Message-ID: <1622642586.2.0.174845262957.issue44286@roundup.psfhosted.org>


New submission from john kim <idle947 at gmail.com>:

I changed the path of the project using venv, so it didn't work properly.

I thought it worked successfully because there was a (venv) on the terminal line.

However, the __VENV_DIR__ in the 

set "VIRTUAL_ENV=__VENV_DIR__" 

in the activate script did not work properly because it was the PATH before the replacement.

How about adding a procedure to verify the __VENV_DIR__ is a valid PATH to the Activate Script?

----------
components: Library (Lib)
messages: 394909
nosy: idle947
priority: normal
severity: normal
status: open
title: venv activate script would be good to show failure.
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Wed Jun  2 10:34:03 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 02 Jun 2021 14:34:03 +0000
Subject: [New-bugs-announce] [issue44287] test_asyncio: test_popen() failed
 on AMD64 Windows8.1 Refleaks 3.9
Message-ID: <1622644443.7.0.37477111657.issue44287@roundup.psfhosted.org>


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

AMD64 Windows8.1 Refleaks 3.9:
https://buildbot.python.org/all/#/builders/6/builds/31

2:16:22 load avg: 7.33 [364/425/2] test_asyncio crashed (Exit code 1) -- running: test_decimal (2 min 33 sec), test_dbm (2 min 53 sec), test_bufio (18 min 18 sec)
["test_asyncio", 0, 268.7466852, null]
beginning 6 repetitions
123456
D:\buildarea\3.9.ware-win81-release.refleak\build\lib\subprocess.py:1052: ResourceWarning: subprocess 2724 is still running
  _warn("subprocess %s is still running" % self.pid,
ResourceWarning: Enable tracemalloc to get the object allocation traceback
D:\buildarea\3.9.ware-win81-release.refleak\build\lib\asyncio\windows_utils.py:112: ResourceWarning: unclosed <PipeHandle handle=2008>
  _warn(f"unclosed {self!r}", ResourceWarning, source=self)
ResourceWarning: Enable tracemalloc to get the object allocation traceback
D:\buildarea\3.9.ware-win81-release.refleak\build\lib\asyncio\windows_utils.py:112: ResourceWarning: unclosed <PipeHandle handle=1364>
  _warn(f"unclosed {self!r}", ResourceWarning, source=self)
ResourceWarning: Enable tracemalloc to get the object allocation traceback
D:\buildarea\3.9.ware-win81-release.refleak\build\lib\asyncio\windows_utils.py:112: ResourceWarning: unclosed <PipeHandle handle=1968>
  _warn(f"unclosed {self!r}", ResourceWarning, source=self)
ResourceWarning: Enable tracemalloc to get the object allocation traceback
test test_asyncio failed -- Traceback (most recent call last):
  File "D:\buildarea\3.9.ware-win81-release.refleak\build\lib\test\test_asyncio\test_windows_utils.py", line 111, in test_popen
    self.assertEqual(res, _winapi.WAIT_OBJECT_0)
AssertionError: 258 != 0

Traceback (most recent call last):
  File "D:\buildarea\3.9.ware-win81-release.refleak\build\lib\test\support\__init__.py", line 906, in temp_dir
    yield path
  File "D:\buildarea\3.9.ware-win81-release.refleak\build\lib\test\support\__init__.py", line 958, in temp_cwd
    yield cwd_dir
  File "D:\buildarea\3.9.ware-win81-release.refleak\build\lib\test\libregrtest\main.py", line 638, in main
    self._main(tests, kwargs)
  File "D:\buildarea\3.9.ware-win81-release.refleak\build\lib\test\libregrtest\main.py", line 658, in _main
    run_tests_worker(self.ns, self.worker_test_name)
  File "D:\buildarea\3.9.ware-win81-release.refleak\build\lib\test\libregrtest\runtest_mp.py", line 86, in run_tests_worker
    sys.exit(0)
SystemExit: 0

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "D:\buildarea\3.9.ware-win81-release.refleak\build\lib\test\support\__init__.py", line 329, in _force_run
    return func(*args)
PermissionError: [WinError 32] The process cannot access the file because it is being used by another process: 'D:\\buildarea\\3.9.ware-win81-release.refleak\\build\\build\\test_python_6648?\\test_python_worker_1760?'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "D:\buildarea\3.9.ware-win81-release.refleak\build\lib\runpy.py", line 197, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "D:\buildarea\3.9.ware-win81-release.refleak\build\lib\runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "D:\buildarea\3.9.ware-win81-release.refleak\build\lib\test\regrtest.py", line 47, in <module>
    _main()
  File "D:\buildarea\3.9.ware-win81-release.refleak\build\lib\test\regrtest.py", line 43, in _main
    main()
  File "D:\buildarea\3.9.ware-win81-release.refleak\build\lib\test\libregrtest\main.py", line 716, in main
    Regrtest().main(tests=tests, **kwargs)
  File "D:\buildarea\3.9.ware-win81-release.refleak\build\lib\test\libregrtest\main.py", line 638, in main
    self._main(tests, kwargs)
  File "D:\buildarea\3.9.ware-win81-release.refleak\build\lib\contextlib.py", line 135, in __exit__
    self.gen.throw(type, value, traceback)
  File "D:\buildarea\3.9.ware-win81-release.refleak\build\lib\test\support\__init__.py", line 958, in temp_cwd
    yield cwd_dir
  File "D:\buildarea\3.9.ware-win81-release.refleak\build\lib\contextlib.py", line 135, in __exit__
    self.gen.throw(type, value, traceback)
  File "D:\buildarea\3.9.ware-win81-release.refleak\build\lib\test\support\__init__.py", line 911, in temp_dir
    rmtree(path)
  File "D:\buildarea\3.9.ware-win81-release.refleak\build\lib\test\support\__init__.py", line 452, in rmtree
    _rmtree(path)
  File "D:\buildarea\3.9.ware-win81-release.refleak\build\lib\test\support\__init__.py", line 393, in _rmtree
    _waitfor(lambda p: _force_run(p, os.rmdir, p), path)
  File "D:\buildarea\3.9.ware-win81-release.refleak\build\lib\test\support\__init__.py", line 340, in _waitfor
    func(pathname)
  File "D:\buildarea\3.9.ware-win81-release.refleak\build\lib\test\support\__init__.py", line 393, in <lambda>
    _waitfor(lambda p: _force_run(p, os.rmdir, p), path)
  File "D:\buildarea\3.9.ware-win81-release.refleak\build\lib\test\support\__init__.py", line 335, in _force_run
    return func(*args)
PermissionError: [WinError 32] The process cannot access the file because it is being used by another process: 'D:\\buildarea\\3.9.ware-win81-release.refleak\\build\\build\\test_python_6648?\\test_python_worker_1760?'

----------
components: asyncio
messages: 394915
nosy: asvetlov, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: test_asyncio: test_popen() failed on AMD64 Windows8.1 Refleaks 3.9
versions: Python 3.9

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

From report at bugs.python.org  Wed Jun  2 11:05:01 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 02 Jun 2021 15:05:01 +0000
Subject: [New-bugs-announce] [issue44288] unittest: _is_relevant_tb_level()
 fails because tb.tb_frame.f_globals=None
Message-ID: <1622646301.21.0.530084460919.issue44288@roundup.psfhosted.org>


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

Sometimes, when a test fails in the main branch, unittest fails with the following error:

...
  File "C:\vstinner\python\main\lib\unittest\result.py", line 205, in _is_relevant_tb_level
    return '__unittest' in tb.tb_frame.f_globals
TypeError: argument of type 'NoneType' is not iterable

I only see this error in the main branch, so I suspect that it's a recent change.

Mark, Guido: can it be related to the recent optimization work?


Full log:

vstinner at DESKTOP-DK7VBIL C:\vstinner\python\main>python -u -m test test_ssl -u all -v -m test_pha_required_nocert -F -j5
(...)
0:00:27 load avg: 15.68 [ 47/1] test_ssl failed
test_ssl: testing with 'OpenSSL 1.1.1k  25 Mar 2021' (1, 1, 1, 11, 15)
          under Windows ('10', '10.0.19043', 'SP0', 'Multiprocessor Free')
          HAS_SNI = True
          OP_ALL = 0x-7fffffac
          OP_NO_TLSv1_1 = 0x10000000
test_pha_required_nocert (test.test_ssl.TestPostHandshakeAuth) ...  server:  new connection from ('127.0.0.1', 57613)
 client cert is None
 client did not provide a cert
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
TLS: (<ssl.SSLSocket fd=644, family=AF_INET, type=SOCK_STREAM, proto=0, laddr=('127.0.0.1', 57612), raddr=('127.0.0.1', 57613)>, 'write', TLSVersion.TLSv1_3, _TLSContentType.ALERT, _TLSAlertType.CERTIFICA
TE_REQUIRED, b'\x02t')
Test server failure:
Traceback (most recent call last):
   File "C:\vstinner\python\main\lib\test\test_ssl.py", line 2444, in run
    msg = self.read()
   File "C:\vstinner\python\main\lib\test\test_ssl.py", line 2421, in read
    return self.sslconn.read()
   File "C:\vstinner\python\main\lib\ssl.py", line 1131, in read
    return self._sslobj.read(len)
 ssl.SSLError: [SSL: PEER_DID_NOT_RETURN_A_CERTIFICATE] peer did not return a certificate (_ssl.c:2522)
Warning -- threading_cleanup() failed to cleanup 0 threads (count: 0, dangling: 2)
Warning -- Dangling thread: <ThreadedEchoServer(Thread-1, stopped daemon 540)>
Warning -- Dangling thread: <_MainThread(MainThread, started 1592)>
Warning -- threading._dangling was modified by test_ssl
  Before: {<weakref at 0x00000235F1D3A210; to '_MainThread' at 0x00000235F0E9C730>}
  After:  {<weakref at 0x00000235F1D3B050; to 'ThreadedEchoServer' at 0x00000235F1687890>, <weakref at 0x00000235F1D3B2F0; to '_MainThread' at 0x00000235F0E9C730>}
test test_ssl crashed -- Traceback (most recent call last):
  File "C:\vstinner\python\main\lib\test\libregrtest\runtest.py", line 282, in _runtest_inner
    refleak = _runtest_inner2(ns, test_name)
  File "C:\vstinner\python\main\lib\test\libregrtest\runtest.py", line 246, in _runtest_inner2
    test_runner()
  File "C:\vstinner\python\main\lib\test\test_ssl.py", line 5010, in test_main
    support.run_unittest(*tests)
  File "C:\vstinner\python\main\lib\test\support\__init__.py", line 1083, in run_unittest
    _run_suite(suite)
  File "C:\vstinner\python\main\lib\test\support\__init__.py", line 960, in _run_suite
    result = runner.run(suite)
  File "C:\vstinner\python\main\lib\unittest\runner.py", line 176, in run
    test(result)
  File "C:\vstinner\python\main\lib\unittest\suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "C:\vstinner\python\main\lib\unittest\suite.py", line 122, in run
    test(result)
  File "C:\vstinner\python\main\lib\unittest\suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "C:\vstinner\python\main\lib\unittest\suite.py", line 122, in run
    test(result)
  File "C:\vstinner\python\main\lib\unittest\case.py", line 652, in __call__
    return self.run(*args, **kwds)
  File "C:\vstinner\python\main\lib\unittest\case.py", line 600, in run
    self._feedErrorsToResult(result, outcome.errors)
  File "C:\vstinner\python\main\lib\unittest\case.py", line 516, in _feedErrorsToResult
    result.addFailure(test, exc_info)
  File "C:\vstinner\python\main\lib\test\support\testresult.py", line 123, in addFailure
    super().addFailure(test, err)
  File "C:\vstinner\python\main\lib\unittest\runner.py", line 75, in addFailure
    super(TextTestResult, self).addFailure(test, err)
  File "C:\vstinner\python\main\lib\unittest\result.py", line 17, in inner
    return method(self, *args, **kw)
  File "C:\vstinner\python\main\lib\unittest\result.py", line 122, in addFailure
    self.failures.append((test, self._exc_info_to_string(err, test)))
  File "C:\vstinner\python\main\lib\unittest\result.py", line 182, in _exc_info_to_string
    length = self._count_relevant_tb_levels(tb)
  File "C:\vstinner\python\main\lib\unittest\result.py", line 209, in _count_relevant_tb_levels
    while tb and not self._is_relevant_tb_level(tb):
  File "C:\vstinner\python\main\lib\unittest\result.py", line 205, in _is_relevant_tb_level
    return '__unittest' in tb.tb_frame.f_globals
TypeError: argument of type 'NoneType' is not iterable

----------
components: Interpreter Core
messages: 394920
nosy: gvanrossum, mark.dickinson, vstinner
priority: normal
severity: normal
status: open
title: unittest: _is_relevant_tb_level() fails because tb.tb_frame.f_globals=None
versions: Python 3.11

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

From report at bugs.python.org  Wed Jun  2 11:09:05 2021
From: report at bugs.python.org (Andrzej Mateja)
Date: Wed, 02 Jun 2021 15:09:05 +0000
Subject: [New-bugs-announce] [issue44289] tarfile.is_tarfile() modifies file
 object's current position
Message-ID: <1622646545.23.0.614350359918.issue44289@roundup.psfhosted.org>


New submission from Andrzej Mateja <mateja.and at gmail.com>:

Since Python 3.9 tarfile.is_tarfile accepts not only paths but also files and file-like objects (bpo-29435).

Verification if a file or file-like object is a tar file modifies file object's current position.

Imagine a function listing names of all tar archive members but checking first if this is a valid tar archive. When its argument is a str or pathlib.Path this is quite straightforward. If the argument is a file of file-like object then current position must be reset or TarFile.getmembers() returns empty list.

import tarfile


def list_tar(archive):
    if tarfile.is_tarfile(archive):
        kwargs = {'fileobj' if hasattr(archive, 'read') else 'name': archive}
        t = tarfile.open(**kwargs)
        return [member.name for member in t.getmembers()]
    return []


if __name__ == '__main__':
    path = 'archive.tar.gz'
    print(list_tar(path))
    print(list_tar(open(path, 'rb')))


['spam.py', 'ham.py', 'bacon.py', 'eggs.py']
[]

----------
components: Library (Lib)
messages: 394922
nosy: mateja.and
priority: normal
severity: normal
status: open
title: tarfile.is_tarfile() modifies file object's current position
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Wed Jun  2 12:17:00 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 02 Jun 2021 16:17:00 +0000
Subject: [New-bugs-announce] [issue44290] x86-64 macOS 3.x buildbot build
 failed with: No such file or directory:
 '/Users/buildbot/buildarea/3.x.billenstein-macos/build/target/include/python3.11d/pyconfig.h'
Message-ID: <1622650620.73.0.633378867962.issue44290@roundup.psfhosted.org>


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

x86-64 macOS 3.x:
https://buildbot.python.org/all/#/builders/366/builds/322

The build 322 is the first error. Build 320 was fine, 321 failed with "retry lost connection test (retry)".

(...)
gcc -c  -Wno-unused-result -Wsign-compare -g -O0 -Wall -Qunused-arguments  -Qunused-arguments   -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Wstrict-prototypes -Werror=implicit-function-declaration -fvisibility=hidden  -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o Modules/_math.o Modules/_math.c
 CC='gcc' LDSHARED='gcc -bundle -undefined dynamic_lookup    ' OPT='-g -O0 -Wall' 	_TCLTK_INCLUDES='' _TCLTK_LIBS='' 	./python.exe -E ./setup.py  build
running build
running build_ext
error: [Errno 2] No such file or directory: '/Users/buildbot/buildarea/3.x.billenstein-macos/build/target/include/python3.11d/pyconfig.h'
make: *** [sharedmods] Error 1
program finished with exit code 2
elapsedTime=29.576823

----------
components: Build
messages: 394926
nosy: ned.deily, ronaldoussoren, vstinner
priority: normal
severity: normal
status: open
title: x86-64 macOS 3.x buildbot build failed with: No such file or directory: '/Users/buildbot/buildarea/3.x.billenstein-macos/build/target/include/python3.11d/pyconfig.h'
versions: Python 3.11

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

From report at bugs.python.org  Wed Jun  2 14:31:52 2021
From: report at bugs.python.org (Kirill Pinchuk)
Date: Wed, 02 Jun 2021 18:31:52 +0000
Subject: [New-bugs-announce] [issue44291] Unify
 logging.handlers.SysLogHandler behavior with SocketHandlers
Message-ID: <1622658712.23.0.244922352408.issue44291@roundup.psfhosted.org>


New submission from Kirill Pinchuk <cybergrind at gmail.com>:

Probably we should make the behavior of SysLogHandler consistent with other Socket handlers.

Right now SocketHandler and DatagramHandler implement such behavior:

1) on `close` set `self.socket = None`
2) when trying to send - make socket when it is None


SysLogHandler doesn't implement this behavior and when you close the socket for some reason (eg. restart of uWSGI server on code change) it leaves it in the closed state, then raises an error when you try to send any message because it is closed

```
--- Logging error ---
Traceback (most recent call last):
  File "/usr/lib/python3.9/logging/handlers.py", line 959, in emit
    self.socket.sendto(msg, self.address)
OSError: [Errno 9] Bad file descriptor

```

----------
components: Library (Lib)
messages: 394932
nosy: Kirill Pinchuk
priority: normal
severity: normal
status: open
title: Unify logging.handlers.SysLogHandler behavior with SocketHandlers
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/issue44291>
_______________________________________

From report at bugs.python.org  Wed Jun  2 17:59:52 2021
From: report at bugs.python.org (Luca Mattiello)
Date: Wed, 02 Jun 2021 21:59:52 +0000
Subject: [New-bugs-announce] [issue44292] contextmanager +
 ExitStack.pop_all()
Message-ID: <1622671192.83.0.598517840912.issue44292@roundup.psfhosted.org>


New submission from Luca Mattiello <lucae.mattiello at gmail.com>:

Reading the contextlib documentation, one might assume the following to be functionally equivalent, when used in a with statement:

@contextlib.contextmanager
def managed_resource():
  resource = acquire()
  try:
    yield resource
  finally:
    resource.release()

class ManagedResource:
  def __init__(self):
    self.resource = acquire()
  def __enter__(self):
    return self.resource
  def __exit__(self, *args):
    self.resource.release()

However, the first version has a seemingly unexpected behavior when used in conjunction with an ExitStack, and pop_all().

with contextlib.ExitStack() as es:
  r = es.enter_context(managed_resource())
  es.pop_all()
  # Uh-oh, r gets released anyway

with contextlib.ExitStack() as es:
  r = es.enter_context(ManagedResource())
  es.pop_all()
  # Works as expected

I think the reason is https://docs.python.org/3/reference/expressions.html#yield-expressions, in particular

> Yield expressions are allowed anywhere in a try construct.
> If the generator is not resumed before it is finalized (by
> reaching a zero reference count or by being garbage collected),
> the generator-iterator?s close() method will be called,
> allowing any pending finally clauses to execute.

I guess this is working according to the specs, but I found it very counter-intuitive. Could we improve the documentation to point out this subtle difference?

Full repro:

import contextlib

@contextlib.contextmanager
def cm():
  print("acquire cm")
  try:
    yield 1
  finally:
    print("release cm")

class CM:
  def __init__(self):
    print("acquire CM")
  def __enter__(self):
    return 1
  def __exit__(self, *args):
    print("release CM")

def f1():
  with contextlib.ExitStack() as es:
    es.enter_context(cm())
    es.pop_all()

def f2():
  with contextlib.ExitStack() as es:
    es.enter_context(CM())
    es.pop_all()

f1()
f2()

Output:

acquire cm
release cm
acquire CM

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 394948
nosy: docs at python, lucae.mattiello
priority: normal
severity: normal
status: open
title: contextmanager + ExitStack.pop_all()
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Jun  2 18:26:01 2021
From: report at bugs.python.org (Joseph Perez)
Date: Wed, 02 Jun 2021 22:26:01 +0000
Subject: [New-bugs-announce] [issue44293] PEP 585 breaks inspect.isclass
Message-ID: <1622672761.68.0.195869463104.issue44293@roundup.psfhosted.org>


New submission from Joseph Perez <joperez at hotmail.fr>:

PEP 585 has the side-effect of making `list[int]` an instance of `type`. This is not the case for other generic aliases.

It also implies that `inspect.isclass(list[int]) is True`, while `list[int]` is not a class; as a proof of this statement `issubclass(list[int], collections.abc.Collection)` raises `TypeError: issubclass() arg 1 must be a class`.

By the way, there is the awkward thing of having `isinstance(list[int], type) is True` while `issubclass(type(list[int]), type) is False`.

----------
messages: 394950
nosy: joperez
priority: normal
severity: normal
status: open
title: PEP 585 breaks inspect.isclass
versions: Python 3.9

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

From report at bugs.python.org  Wed Jun  2 18:34:06 2021
From: report at bugs.python.org (Sunny Jamshedji)
Date: Wed, 02 Jun 2021 22:34:06 +0000
Subject: [New-bugs-announce] [issue44294] 3.9.5 Windows 64-bit installer
 says v3.8.10 in startup window.
Message-ID: <1622673246.94.0.636468251984.issue44294@roundup.psfhosted.org>


New submission from Sunny Jamshedji <sunnyjamshedji at gmail.com>:

Downloaded Windows 64 bit installer from:

https://www.python.org/downloads/windows/

Link said:

https://www.python.org/ftp/python/3.9.5/python-3.9.5-amd64.exe

It downloaded what appears to be 3.8.10 installer. I launched it and I got the attached screenshot with 3.8.10 installer.

Tested it out 4 times. First 2 times it did the same thing. While testing the third time, acquiring screenshots so it took longer, it gave me the correct file! IDK what happened, unless you guys fixed it in between!

----------
components: Installation
files: 1. Python for Windows Download Page.png
messages: 394951
nosy: sunnyjamshedji
priority: normal
severity: normal
status: open
title: 3.9.5 Windows 64-bit installer says v3.8.10 in startup window.
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file50085/1. Python for Windows Download Page.png

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

From report at bugs.python.org  Wed Jun  2 19:32:40 2021
From: report at bugs.python.org (Anthony Sottile)
Date: Wed, 02 Jun 2021 23:32:40 +0000
Subject: [New-bugs-announce] [issue44295] self.assertDictContainsSubset
 warning is unhelpful
Message-ID: <1622676760.31.0.209382096259.issue44295@roundup.psfhosted.org>


New submission from Anthony Sottile <asottile at umich.edu>:

it's missing stacklevel= -- mostly creating a bpo issue to link to

----------
messages: 394953
nosy: Anthony Sottile
priority: normal
severity: normal
status: open
title: self.assertDictContainsSubset warning is unhelpful
versions: Python 3.11

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

From report at bugs.python.org  Wed Jun  2 19:55:20 2021
From: report at bugs.python.org (Anthony Sottile)
Date: Wed, 02 Jun 2021 23:55:20 +0000
Subject: [New-bugs-announce] [issue44296] Should warnings.warn default to
 stacklevel=2?
Message-ID: <1622678120.26.0.13288465488.issue44296@roundup.psfhosted.org>


New submission from Anthony Sottile <asottile at umich.edu>:

I have yet to come across a usecase where `stacklevel=1` makes sense -- usually it is more helpful to point at the calling code than the function which is itself warning

my proposal is to update the default for `stacklevel=` from `1` to `2`

an example bpo where this is relevant is bpo-44295

----------
components: Library (Lib)
messages: 394960
nosy: Anthony Sottile
priority: normal
severity: normal
status: open
title: Should warnings.warn default to stacklevel=2?
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Wed Jun  2 21:51:01 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 03 Jun 2021 01:51:01 +0000
Subject: [New-bugs-announce] [issue44297] Frame with -1 line number
Message-ID: <1622685061.25.0.0760408902282.issue44297@roundup.psfhosted.org>


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

While debugging https://bugs.python.org/issue43921 on Windows, I got a traceback with a single frame and the frame line number is -1.

It looks like a Python 3.11 regression.

Mark, Guido: can it be related to recent optimization work done in the main branch?

See also bpo-44288 "unittest: _is_relevant_tb_level() fails because tb.tb_frame.f_globals=None".

======================================================================
FAIL: test_pha_required_nocert (test.test_ssl.TestPostHandshakeAuth)
----------------------------------------------------------------------
ssl.SSLEOFError: EOF occurred in violation of protocol (_ssl.c:2522)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\vstinner\python\main\lib\test\test_ssl.py", line -1, in test_pha_required_nocert
AssertionError: "certificate required" does not match "EOF occurred in violation of protocol (_ssl.c:2522)"

----------
components: Interpreter Core
messages: 394969
nosy: Mark.Shannon, gvanrossum, vstinner
priority: normal
severity: normal
status: open
title: Frame with -1 line number
versions: Python 3.11

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

From report at bugs.python.org  Thu Jun  3 06:05:02 2021
From: report at bugs.python.org (Ned Batchelder)
Date: Thu, 03 Jun 2021 10:05:02 +0000
Subject: [New-bugs-announce] [issue44298] 3.10.0b2 traces with-exit before
 the break that caused the exit
Message-ID: <1622714702.42.0.954785031393.issue44298@roundup.psfhosted.org>


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

Python 3.10 now traces back to with statements when exiting the with block. When the exit is a break statement, the with exit is visited before the break statement is.  This seems confusing.

--- 8< -----------------------------------------

import linecache, sys

def trace(frame, event, arg):
    # The weird globals here is to avoid a NameError on shutdown...
    if frame.f_code.co_filename == globals().get("__file__"):
        lineno = frame.f_lineno
        print("{} {}: {}".format(event[:4], lineno, linecache.getline(__file__, lineno).rstrip()))
    return trace

def doit():
    for i in range(2):
        with open("test", "w") as f:
            a = 13
            b = 14
            break
    c = 16

print(sys.version)
sys.settrace(trace)
doit()

--- 8< -----------------------------------------

3.10.0b2 (default, Jun  3 2021, 05:27:13) [Clang 12.0.0 (clang-1200.0.32.29)]
call 10: def doit():
line 11:     for i in range(2):
line 12:         with open("test", "w") as f:
line 13:             a = 13
line 14:             b = 14
line 12:         with open("test", "w") as f:
line 15:             break
line 16:     c = 16
retu 16:     c = 16



Shouldn't we get a trace for line 15 (break), then line 12 (with-exit), then line 15 again, then line 16?

----------
assignee: Mark.Shannon
components: Interpreter Core
messages: 394990
nosy: Mark.Shannon, nedbat
priority: normal
severity: normal
status: open
title: 3.10.0b2 traces with-exit before the break that caused the exit
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Thu Jun  3 07:01:05 2021
From: report at bugs.python.org (Dmitry Kropachev)
Date: Thu, 03 Jun 2021 11:01:05 +0000
Subject: [New-bugs-announce] [issue44299] Enable control over daemon flag in
 ThreadPoolExecutor and ProcessPoolExecutor
Message-ID: <1622718065.29.0.723713253214.issue44299@roundup.psfhosted.org>


New submission from Dmitry Kropachev <dmitry.kropachev at gmail.com>:

ThreadPoolExecutor and ProcessPoolExecutor spawn threads and processes with default value of daemon flag, i.e. None.

In some cases it would handful to have control over daemon flag of spawned threads and processes.
Simple 6-line fix to enable it.

----------
components: Library (Lib)
messages: 394993
nosy: dkropachev
priority: normal
severity: normal
status: open
title: Enable control over daemon flag in ThreadPoolExecutor and ProcessPoolExecutor
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Thu Jun  3 10:41:35 2021
From: report at bugs.python.org (Mihai Ion)
Date: Thu, 03 Jun 2021 14:41:35 +0000
Subject: [New-bugs-announce] [issue44300] using Linked list vs dynamic array
 for LifoQueue class
Message-ID: <1622731295.64.0.26729974152.issue44300@roundup.psfhosted.org>


New submission from Mihai Ion <euromike21 at yahoo.com>:

Switching to Linked list data structure for improving performance append() and pop() run time complexity when eliminating dynamic array resizing

----------
components: Library (Lib)
files: main.py
messages: 395004
nosy: euromike21
priority: normal
severity: normal
status: open
title: using Linked list vs dynamic array for LifoQueue class
type: performance
versions: Python 3.11
Added file: https://bugs.python.org/file50086/main.py

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

From report at bugs.python.org  Thu Jun  3 12:13:29 2021
From: report at bugs.python.org (Azat Ibrakov)
Date: Thu, 03 Jun 2021 16:13:29 +0000
Subject: [New-bugs-announce] [issue44301] Is there a way to provide
 destructor for module written using C API?
Message-ID: <1622736809.26.0.65904835791.issue44301@roundup.psfhosted.org>


New submission from Azat Ibrakov <azatibrakov at gmail.com>:

I'm reimplementing `fractions.Fraction` class using C API (https://github.com/lycantropos/cfractions).

And the problem is that I want to use `numbers.Rational` interface in my type checks to add support for user-defined rational numbers.

I see how it's done for `decimal.Decimal` class:
https://github.com/python/cpython/blob/142e5c5445c019542246d93fe2f9e195d3131686/Modules/_decimal/_decimal.c#L2916
but the problem is: I don't see when/where we call `Py_DECREF(Rational)`, so it looks like this class will not be "freed" until the  end of the program.

So my question is: is there any way to define some function which will be called once module is not used?

----------
components: C API
messages: 395012
nosy: lycantropos
priority: normal
severity: normal
status: open
title: Is there a way to provide destructor for module written using C API?
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Jun  3 12:39:15 2021
From: report at bugs.python.org (Battant)
Date: Thu, 03 Jun 2021 16:39:15 +0000
Subject: [New-bugs-announce] [issue44302] compile fail when make install run
 pip install as sudo
Message-ID: <1622738355.45.0.608961303254.issue44302@roundup.psfhosted.org>


New submission from Battant <mparchet at sunrise.ch>:

Hello,
5.4.0-73-generic
Here is my configuration
ubuntu 20.04
linux kernel 5.4.0-73-generic

step to reproduce

clone cpytjpm 3.11 repository

https://github.com/python/cpython

compile with this tcl
./configure -with-tcltk-includes=/usr/include/ --with-tcltk-libs=/usr/local/lib/libtcl.so --enable-optimizations

make
sudo make install

Actual result :

compil fail because pip is run as sudo to install python

rm -f /usr/local/bin/idle3
(cd /usr/local/bin; ln -s idle3.11 idle3)
rm -f /usr/local/bin/pydoc3
(cd /usr/local/bin; ln -s pydoc3.11 pydoc3)
rm -f /usr/local/bin/2to3
(cd /usr/local/bin; ln -s 2to3-3.11 2to3)
if test "x" != "x" ; then \
	rm -f /usr/local/bin/python3-32; \
	(cd /usr/local/bin; ln -s python3.11-32 python3-32) \
fi
if test "x" != "x" ; then \
	rm -f /usr/local/bin/python3-intel64; \
	(cd /usr/local/bin; ln -s python3.11-intel64 python3-intel64) \
fi
rm -f /usr/local/share/man/man1/python3.1
(cd /usr/local/share/man/man1; ln -s python3.11.1 python3.1)
if test "xupgrade" != "xno"  ; then \
	case upgrade in \
		upgrade) ensurepip="--upgrade" ;; \
		install|*) ensurepip="" ;; \
	esac; \
	 ./python -E -m ensurepip \
		$ensurepip --root=/ ; \
fi
Looking in links: /tmp/tmpr3j5u6l0
Requirement already satisfied: setuptools in /usr/local/lib/python3.11/site-packages (56.0.0)
Requirement already satisfied: pip in /usr/local/lib/python3.11/site-packages (21.1.1)
WARNING: Running pip as root will break packages and permissions. You should install packages reliably by using venv: https://pip.pypa.io/warnings/venv

See attachement log detais

Could you help me please to fix this issus

Best regards

Battant

----------
components: Build
files: output.log
messages: 395017
nosy: Battant
priority: normal
severity: normal
status: open
title: compile fail when make install run pip install as sudo
versions: Python 3.11
Added file: https://bugs.python.org/file50087/output.log

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

From report at bugs.python.org  Thu Jun  3 13:10:54 2021
From: report at bugs.python.org (Shreyan Avigyan)
Date: Thu, 03 Jun 2021 17:10:54 +0000
Subject: [New-bugs-announce] [issue44303] Buildbot website failing with 503
Message-ID: <1622740254.43.0.647808533518.issue44303@roundup.psfhosted.org>


New submission from Shreyan Avigyan <shreyan.avigyan at gmail.com>:

I was trying to debug a issue (the test_asyncio random failing problem) when suddenly Buildbot is showing up with "503 Service Unavailable
No server is available to handle this request.". It's constantly failing with the request. I'm not sure if it's only for me though.

----------
components: Demos and Tools
messages: 395023
nosy: shreyanavigyan
priority: normal
severity: normal
status: open
title: Buildbot website failing with 503

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

From report at bugs.python.org  Thu Jun  3 14:23:07 2021
From: report at bugs.python.org (mike bayer)
Date: Thu, 03 Jun 2021 18:23:07 +0000
Subject: [New-bugs-announce] [issue44304] segmentation fault appeared in
 python 3.10.0b2
Message-ID: <1622744587.51.0.457614596671.issue44304@roundup.psfhosted.org>


New submission from mike bayer <mike_mp at zzzcomputing.com>:

segmentation fault related to object deallocation and traceback objects, is extremely difficult to reproduce and definitely appeared as of 3.10.0b2, does not occur in 3.10.0b1.   linux and osx platforms are affected.

The issue requires "greenlet==1.1.0" to be installed, as well as that for me to reproduce it I have to use sqlite3 with some special APIs also, so while this issue might be in greenlet, or sqlite3, I have a feeling these are all factors that are combining together in a very random way to reveal something that's actually happening in the interpreter, but in any case would be great if core devs can see why it happens.  The below script has been tested on various linux platforms, and the overall bug was revealed by an interaction in the SQLAlchemy test suite that's occurring in many places including OSX, linux.   As noted, a whole bunch of very random things are needed for me to reproduce it.


import greenlet
import sqlite3


class _ErrorContainer(object):
    error = None


def _expect_raises_fn(fn):
    ec = _ErrorContainer()
    try:
        fn()
    except Exception as err:
        assert str(err) == "this is a test"

        # assign the exception context outside of the except
        # is necessary
        ec.error = err

    # don't del the exception context is necessary
#    del ec


def greenlet_spawn(fn, *args, **kwargs):

    # spawning a greenlet is necessary
    context = greenlet.greenlet(fn, greenlet.getcurrent())

    # assignment to "result" is necessary
    result = context.switch(*args, **kwargs)

    # raising exception is necessary
    raise Exception("this is a test")


class OuterConnectionWrapper:
    def __init__(self, connection):
        self.connection = connection

    def go(self, stmt):
        sqlite_connection = self.connection
        cursor = sqlite_connection.cursor()
        cursor.execute("select 1")
        return cursor

    def execute(self, stmt):
        return greenlet_spawn(self.go, stmt)

    def _do_close(self):
        self.connection.close()
        self.connection = None

    def close(self):
        self._do_close()


class InnerConnectionWrapper:
    def __init__(self, connection):
        self.connection = connection

    def create_function(self, *arg, **kw):
        self.connection.create_function(*arg, **kw)

    def cursor(self):
        return self.connection.cursor()

    def close(self):
        self.connection = None


class ConnectionPool:
    def __init__(self):
        self.conn = sqlite3.connect(":memory:")

        def regexp(a, b):
            return None

        self.conn.create_function("regexp", 2, regexp)

    def connect(self):
        return InnerConnectionWrapper(self.conn)


def do_test():
    pool = ConnectionPool()

    def go():
        c1 = pool.connect()
        conn = OuterConnectionWrapper(c1)
        try:
            conn.execute("test")
        finally:
            conn.close()

    _expect_raises_fn(go)


do_test()

----------
components: Interpreter Core
messages: 395028
nosy: zzzeek
priority: normal
severity: normal
status: open
title: segmentation fault appeared in python 3.10.0b2
versions: Python 3.10

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

From report at bugs.python.org  Thu Jun  3 17:48:37 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 03 Jun 2021 21:48:37 +0000
Subject: [New-bugs-announce] [issue44305] Improve syntax error for try block
 without finally or except block
Message-ID: <1622756917.47.0.333858090631.issue44305@roundup.psfhosted.org>


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

Given this script:
try:
    x = 34

a = 1

instead of printing:
  File "/home/pablogsal/github/python/master/lel.py", line 4
    a = 1
    ^
SyntaxError: invalid syntax

we should print:

  File "/home/pablogsal/github/python/master/lel.py", line 4
    a = 1
    ^
SyntaxError: expected 'except' or 'finally' block

----------
messages: 395053
nosy: pablogsal
priority: normal
severity: normal
status: open
title: Improve syntax error for try block without finally or except block

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

From report at bugs.python.org  Thu Jun  3 18:08:45 2021
From: report at bugs.python.org (Thomas Grainger)
Date: Thu, 03 Jun 2021 22:08:45 +0000
Subject: [New-bugs-announce] [issue44306] asyncio.from_thread
Message-ID: <1622758125.93.0.576935961865.issue44306@roundup.psfhosted.org>


New submission from Thomas Grainger <tagrain at gmail.com>:

create a asyncio.from_thread shortcut to run async functions from a thread started with asyncio.to_thread


```
def from_thread(async_func, /, *args, **kwargs):
    """Synchronously run function *async_func* in the event loop thread.

    Any *args and **kwargs supplied for this function are directly passed
    to *func*. Also, the current :class:`contextvars.Context` is propogated,
    allowing context variables from the main thread to be accessed in the
    separate thread.

    Return a concurrent.futures.Future to wait for the result from the event
    loop thread.
```

----------
components: asyncio
messages: 395054
nosy: asvetlov, graingert, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.from_thread

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

From report at bugs.python.org  Thu Jun  3 21:50:34 2021
From: report at bugs.python.org (Anthony Sottile)
Date: Fri, 04 Jun 2021 01:50:34 +0000
Subject: [New-bugs-announce] [issue44307] date.today() is 2x slower than
 datetime.now().date()
Message-ID: <1622771434.0.0.798564808537.issue44307@roundup.psfhosted.org>


New submission from Anthony Sottile <asottile at umich.edu>:

```console
$ python3.10 -m timeit -s 'from datetime import datetime' 'datetime.now().date()'
500000 loops, best of 5: 708 nsec per loop
$ python3.10 -m timeit -s 'from datetime import date' 'date.today()'
200000 loops, best of 5: 1.4 usec per loop
```

this surprised me so I dug into it -- it appears a fast path can be added to `date.today()` to make it faster than `datetime.date.now()` -- though I'm rather unfamiliar with the functions involved here

here is my ~sloppy patch attempting to add a fast path, I would need some guidance to improve it and get it accepted:

```diff
$ git diff -w
diff --git a/Modules/_datetimemodule.c b/Modules/_datetimemodule.c
index 8ef2dad37a..7eaa5d1740 100644
--- a/Modules/_datetimemodule.c
+++ b/Modules/_datetimemodule.c
@@ -2875,6 +2875,17 @@ date_fromtimestamp(PyObject *cls, PyObject *obj)
 static PyObject *
 date_today(PyObject *cls, PyObject *dummy)
 {
+    /* fast path, don't call fromtimestamp */
+    if ((PyTypeObject *)cls == &PyDateTime_DateType) {
+        struct tm tm;
+        time_t t;
+        time(&t);
+        localtime_r(&t, &tm);
+        return new_date_ex(tm.tm_year + 1900,
+                           tm.tm_mon + 1,
+                           tm.tm_mday,
+                           (PyTypeObject*)cls);
+    } else {
         PyObject *time;
         PyObject *result;
         _Py_IDENTIFIER(fromtimestamp);
@@ -2893,6 +2904,7 @@ date_today(PyObject *cls, PyObject *dummy)
         Py_DECREF(time);
         return result;
     }
+}
 
 /*[clinic input]
 @classmethod
```

after this, `date.today()` is faster!

```console
$ ./python -m timeit -s 'from datetime import datetime' 'datetime.now().date()'
500000 loops, best of 5: 764 nsec per loop
$ ./python -m timeit -s 'from datetime import date' 'date.today()'
500000 loops, best of 5: 407 nsec per loop
```

\o/

----------
components: Extension Modules
messages: 395061
nosy: Anthony Sottile
priority: normal
severity: normal
status: open
title: date.today() is 2x slower than datetime.now().date()
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Fri Jun  4 00:21:26 2021
From: report at bugs.python.org (Nicholas Willhite)
Date: Fri, 04 Jun 2021 04:21:26 +0000
Subject: [New-bugs-announce] [issue44308] Raw Strings lack parody
Message-ID: <1622780486.03.0.720343987459.issue44308@roundup.psfhosted.org>


New submission from Nicholas Willhite <willhite.nicholas at gmail.com>:

I'm really sure this isn't filed correctly. I'm a total noob to this process, so feel free to redirect me. :) 

Bytes can be defined as a function, or a prefixed series. You can prefix a series with "b" and get the expected data type. You can also use the builtin functions "bytes" to get the same structure:

  bytes('foo\bar', 'utf-8') == b'foo\bar'
  True

But there's no builtin function for r'foo\bar' that gives you 'foo\\bar'.

This would be really handy for applications that accept a regular expression. If that regex was part of the source code, I'd just r'foo\bar' to get the expected string. Being able to accept something like bytes and do:

  data = b'foo\bar'
  raw_string(data)
  'foo\\bar'

would be really useful for applications that accept a regex as input. 

Is there an obvious way to do this that I'm not seeing? Has my google-foo failed me? Feels like a function that should exist in the stdlib.

Again, really sure I'm not "doing this correctly." So please direct me! :) 

Appreciative,
-Nick Willhite

----------
components: Unicode
messages: 395064
nosy: Nicholas Willhite, ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: Raw Strings lack parody
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Fri Jun  4 07:10:28 2021
From: report at bugs.python.org (=?utf-8?q?Bj=C3=B6rn_Esser?=)
Date: Fri, 04 Jun 2021 11:10:28 +0000
Subject: [New-bugs-announce] [issue44309] Add support for yescrypt in crypt.
Message-ID: <1622805028.07.0.450307029503.issue44309@roundup.psfhosted.org>


New submission from Bj?rn Esser <besser82 at fedoraproject.org>:

Proposed PR adds support for a new method in the crypt module:

yescrypt. It is considered stronger as SHA512 or blowfish and as strong as argon2 for crypt() purpose. The hashing method was developed by the author of the blowfish crypt method, and was based on scrypt. It is supported on most Linux distributions, that ship with libxcrypt as a replacement for the glibc crypt library: Fedora, Debian, Ubuntu, OpenSUSE and many others.

----------
components: Library (Lib)
messages: 395073
nosy: besser82
priority: normal
pull_requests: 25120
severity: normal
status: open
title: Add support for yescrypt in crypt.
versions: Python 3.10

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

From report at bugs.python.org  Fri Jun  4 07:45:58 2021
From: report at bugs.python.org (Wouter De Borger)
Date: Fri, 04 Jun 2021 11:45:58 +0000
Subject: [New-bugs-announce] [issue44310] lru_cache memory leak
Message-ID: <1622807158.12.0.225505300643.issue44310@roundup.psfhosted.org>


New submission from Wouter De Borger <wouter at inmanta.com>:

# Problem

the functools.lru_cache decorator locks all arguments to the function in memory (inclusing self), causing hard to find memory leaks. 

# Expected  

I had assumed that the lru_cache would keep weak-references and that when an object is garbage colected, all its cache entries expire as unreachable. This is not the case.

# Solutions 

1. I think it is worth at least mentioning this behavior in de documentation. 
2. I also think it would be good if the LRU cache actually uses weak references. 

I will try to make a PR for this.

----------
components: Library (Lib)
messages: 395075
nosy: Wouter De Borger2
priority: normal
severity: normal
status: open
title: lru_cache memory leak
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/issue44310>
_______________________________________

From report at bugs.python.org  Fri Jun  4 09:20:02 2021
From: report at bugs.python.org (Jinwoo PARK NANTIER)
Date: Fri, 04 Jun 2021 13:20:02 +0000
Subject: [New-bugs-announce] [issue44311] How to print results of asyncio
 websockets at the same time?
Message-ID: <1622812802.67.0.29847846911.issue44311@roundup.psfhosted.org>


New submission from Jinwoo PARK NANTIER <github.jinwoo at gmail.com>:

## Question
 - How can I merge the results of two or three asynchronous websocket results, defined with the library `asyncio`?
 - I am downloading order book data (how many people want to buy or sell something at which price) of cryptocurrencies using websockets asynchronously, but having hard time showing the results of several coins.
 - The desired output example is as follows, being printed at the same time :
```python
XRP-BTC : The most favorable ask price is 0.00023
ETH-BTC : The most favorable ask price is 0.04
LTC-BTC : The most favorable ask price is 0.001
```
- Each line is a result of each websocket, so what I want to do is to merge the results of several webscokets

## Code Example

```python
import asyncio
import websockets
import ast
import time
import json

# websocket address for the cryptocurrency exchange OKEx
url = "wss://ws.okex.com:8443/ws/v5/public"

# function to download orderbook data, using websocket asynchronously
async def ws_orderbook5(crypto_pair):
    while True:
            try:
                async with websockets.connect(url) as ws:
                    channels = [{'channel': 'books5', 'instId': f'{crypto_pair}'}]
                    sub_param = {"op": "subscribe", "args": channels}
                    sub_str = json.dumps(sub_param)
                    await ws.send(sub_str)
                    print(f"send: {sub_str}")
                    res = await asyncio.wait_for(ws.recv(), timeout=25)

                    while True:
                        try:
                            res = await asyncio.wait_for(ws.recv(), timeout=25)
                            res = ast.literal_eval(res) 
                            print(f"{crypto-pair} : Most favorable ask price is {res['data'][0]['asks'][0][0]}")
                            
                            time.sleep(1)

                        except (asyncio.TimeoutError, websockets.exceptions.ConnectionClosed) as e:
                            try:
                                await ws.send('ping')
                                print("")
                                print("ping")
                                res = await ws.recv()
                                continue
                            except Exception as e:
                                print("Failure due to an unknown error. Stopped working")
                                break
            except Exception as e:
                print("Failure due to an unknown error. Try working again")
                continue
```

- The variable `res`, which is the data downloaded from OKEx websocket looks like the following dictionary, when the argument `crypto_pair` = 'XRP-BTC' .

```python
{'arg': {'channel': 'books5', 'instId': 'XRP-BTC'}, 
 'data': [{'asks': [['0.00002585', '4514.84', '0', '2'], 
                    ['0.00002586', '5845.946', '0', '5'],
                    ['0.00002587', '30306.155', '0', '5'], 
                    ['0.00002588', '9974.105', '0', '7'], 
                    ['0.00002589', '3104.84', '0', '5']], 
           'bids': [['0.00002582', '3988', '0', '2'], 
                    ['0.00002581', '23349.817', '0', '4'], 
                    ['0.0000258', '18735.565', '0', '8'], 
                    ['0.00002579', '6429.196', '0', '6'], 
                    ['0.00002578', '3492.795', '0', '5']], 
 'instId': 'XRP-BTC', 
 'ts': '1622805157064'}]}
```

- As such what is printed on console is as follows. The argument here, for example, is "XRP-BTC" again.

``` python
XRP-BTC : The most favorable ask price is 0.00023
```

- Can anyone tell me how I can merge the result of websockets so that they can be printed at the same time?

----------
components: asyncio
messages: 395082
nosy: asvetlov, hellojinwoo, yselivanov
priority: normal
severity: normal
status: open
title: How to print results of asyncio websockets at the same time?
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Fri Jun  4 12:07:44 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 04 Jun 2021 16:07:44 +0000
Subject: [New-bugs-announce] [issue44312] test_asyncio leaked [1533, 1531,
 1533] references, sum=4597
Message-ID: <1622822864.09.0.0318219471221.issue44312@roundup.psfhosted.org>


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

All refleak buildbots are currently broken in master:

......
test_asyncio leaked [1533, 1531, 1533] references, sum=4597
test_asyncio leaked [367, 366, 367] memory blocks, sum=1100
11 tests failed again:
    test_asyncgen test_asyncio test_code test_collections
    test_coroutines test_exceptions test_idle test_import test_inspect
    test_modulefinder test_types
== Tests result: FAILURE then FAILURE ==
403 tests OK.
10 slowest tests:
- test_signal: 31 min 10 sec
- test_pydoc: 29 min 41 sec
- test_asyncio: 20 min 3 sec
- test_concurrent_futures: 17 min 35 sec
- test_peg_generator: 13 min 38 sec
- test_gdb: 12 min 20 sec
- test_multiprocessing_spawn: 9 min 33 sec
- test_multiprocessing_forkserver: 6 min 49 sec
- test_nntplib: 6 min 20 sec
- test_multiprocessing_fork: 5 min 41 sec
11 tests failed:
    test_asyncgen test_asyncio test_code test_collections
    test_coroutines test_exceptions test_idle test_import test_inspect
    test_modulefinder test_types
13 tests skipped:
    test_devpoll test_ioctl test_kqueue test_msilib test_ossaudiodev
    test_startfile test_tix test_tk test_ttk_guionly test_winconsoleio
    test_winreg test_winsound test_zipfile64
11 re-run tests:
    test_asyncgen test_asyncio test_code test_collections
    test_coroutines test_exceptions test_idle test_import test_inspect
    test_modulefinder test_types

Example failure:

https://buildbot.python.org/all/#/builders/384/builds/50/steps/5/logs/stdio

----------
messages: 395096
nosy: pablogsal, vstinner
priority: normal
severity: normal
status: open
title: test_asyncio leaked [1533, 1531, 1533] references, sum=4597

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

From report at bugs.python.org  Fri Jun  4 12:33:18 2021
From: report at bugs.python.org (Batuhan Taskaya)
Date: Fri, 04 Jun 2021 16:33:18 +0000
Subject: [New-bugs-announce] [issue44313] Generate LOAD_ATTR+CALL_FUNCTION
 instead of LOAD_METHOD+CALL_METHOD for imports
Message-ID: <1622824398.73.0.627770754352.issue44313@roundup.psfhosted.org>


New submission from Batuhan Taskaya <isidentical at gmail.com>:

import foo
def func():
    return foo.bar()

The snippet above will generate the following code;

  2           0 LOAD_GLOBAL              0 (foo)
              2 LOAD_METHOD              1 (bar)
              4 CALL_METHOD              0
              6 RETURN_VALUE

Though this will make things harder for specializing the LOAD_ATTR for modules since now the handling of LOAD_METHOD for that case is necessary so for the imports that we can infer during the symbol analysis pass, we'll generate LOAD_ATTR+CALL_ATTR instead of LOAD_METHOD+CALL_METHOD and hopefully the generated code will get specialized via the PEP 659.

Ref: https://github.com/faster-cpython/ideas/issues/55#issuecomment-853101039

----------
assignee: BTaskaya
components: Interpreter Core
messages: 395099
nosy: BTaskaya, Mark.Shannon
priority: normal
severity: normal
status: open
title: Generate LOAD_ATTR+CALL_FUNCTION instead of LOAD_METHOD+CALL_METHOD for imports
versions: Python 3.11

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

From report at bugs.python.org  Fri Jun  4 14:21:57 2021
From: report at bugs.python.org (Chris Mayo)
Date: Fri, 04 Jun 2021 18:21:57 +0000
Subject: [New-bugs-announce] [issue44314] [doc] SSLContext.set_ciphers()
 link to OpenSSL cipher list format is outdated
Message-ID: <1622830917.65.0.837599008306.issue44314@roundup.psfhosted.org>


New submission from Chris Mayo <aklhfex at gmail.com>:

Current link is:
https://www.openssl.org/docs/manmaster/man1/ciphers.html

Manual page entries without the 'openssl-' prefix have been deprecated, and this link is now directed to a generic page for openssl cmd.

Suggest an update to:
https://www.openssl.org/docs/manmaster/man1/openssl-ciphers.html#CIPHER-LIST-FORMAT

Currently at:
https://github.com/python/cpython/blame/main/Doc/library/ssl.rst#L1680

----------
assignee: docs at python
components: Documentation
messages: 395108
nosy: cjmayo, docs at python
priority: normal
severity: normal
status: open
title: [doc] SSLContext.set_ciphers() link to OpenSSL cipher list format is outdated
versions: Python 3.9

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

From report at bugs.python.org  Fri Jun  4 16:14:46 2021
From: report at bugs.python.org (Erlend E. Aasland)
Date: Fri, 04 Jun 2021 20:14:46 +0000
Subject: [New-bugs-announce] [issue44315] [sqlite3] remove unused connection
 argument from pysqlite_step()
Message-ID: <1622837686.69.0.940426818255.issue44315@roundup.psfhosted.org>


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

The code that used the connection argument was removed one year before pysqlite was included in CPython, as far as I can see. It can safely be removed.

See also:
https://github.com/ghaering/pysqlite/commit/5a009ed6fb2e90b952438f5786f93cd1e8ac8722

----------
assignee: erlendaasland
components: Extension Modules
messages: 395117
nosy: erlendaasland
priority: low
severity: normal
status: open
title: [sqlite3] remove unused connection argument from pysqlite_step()
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Fri Jun  4 17:21:19 2021
From: report at bugs.python.org (Barney Gale)
Date: Fri, 04 Jun 2021 21:21:19 +0000
Subject: [New-bugs-announce] [issue44316] Support preserving path meaning in
 os.path.normpath() and abspath()
Message-ID: <1622841679.24.0.579072106292.issue44316@roundup.psfhosted.org>


New submission from Barney Gale <barney.gale at gmail.com>:

>>> os.path.normpath('a/./b/../c//.')
'a/c'
>>> pathlib.Path('a/./b/../c//.')
PosixPath('a/b/../c')

pathlib takes care not to change the meaning of the path when normalising. That means preserving '..' entries, as these can't be simplified without resolving symlinks etc.

normpath(), on the other handle, /always/ eliminates '..' entries, which can change the meaning of the path.

We could add a new argument to `normpath()` and `abspath()` that leaves '..' entries intact. This was closed as "won't fix" back in bpo-2289, but I think it's worth re-considering.

This enhancement would be helpful for my longer-term work to make pathlib an OOP wrapper of os + os.path, rather than a parallel implementation.

----------
components: Library (Lib)
messages: 395122
nosy: barneygale
priority: normal
severity: normal
status: open
title: Support preserving path meaning in os.path.normpath() and abspath()
type: enhancement

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

From report at bugs.python.org  Sat Jun  5 07:01:10 2021
From: report at bugs.python.org (wyz23x2)
Date: Sat, 05 Jun 2021 11:01:10 +0000
Subject: [New-bugs-announce] [issue44317] Misleading mark of octal
 SyntaxErrors
Message-ID: <1622890870.25.0.904012906945.issue44317@roundup.psfhosted.org>


New submission from wyz23x2 <wyz23x2 at 163.com>:

Python 3.10.0b2 (tags/v3.10.0b2:3173141, Jun  1 2021, 09:05:29) [MSC v.1928 64 bit (AMD64)] on win32 
Type "help", "copyright", "credits" or "license" for more information.
>>> 0777
  File "<stdin>", line 1
    0777
       ^
SyntaxError: leading zeros in decimal integer literals are not permitted; use an 0o prefix for octal integers
>>> 000123
  File "<stdin>", line 1
    000123
         ^
SyntaxError: leading zeros in decimal integer literals are not permitted; use an 0o prefix for octal integers

The ^ is placed below the last digit.
However, this is misleading. The error is "leading zeros" and "prefix". So I would expect this:

>>> 0777
  File "<stdin>", line 1
    0777
    ^
SyntaxError: leading zeros in decimal integer literals are not permitted; use an 0o prefix for octal integers
>>> 000123
  File "<stdin>", line 1
    000123
    ^^^
SyntaxError: leading zeros in decimal integer literals are not permitted; use an 0o prefix for octal integers

Opinions?

----------
components: Parser
messages: 395161
nosy: lys.nikolaou, pablogsal, wyz23x2
priority: normal
severity: normal
status: open
title: Misleading mark of octal SyntaxErrors
type: behavior
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Sat Jun  5 10:58:52 2021
From: report at bugs.python.org (Bluenix)
Date: Sat, 05 Jun 2021 14:58:52 +0000
Subject: [New-bugs-announce] [issue44318] Asyncio classes missing __slots__
Message-ID: <1622905132.97.0.599095697066.issue44318@roundup.psfhosted.org>


New submission from Bluenix <bluenixdev at gmail.com>:

Most of asyncio's classes are missing a __slots__ attribute - for example Lock, Event, Condition, Semaphore, BoundedSemaphore all from locks.py; or Future, FlowControlMixin, Queue, BaseSubprocessTransport from various other parts of asyncio.

----------
components: asyncio
messages: 395165
nosy: Bluenix2, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Asyncio classes missing __slots__
versions: Python 3.10

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

From report at bugs.python.org  Sat Jun  5 15:40:30 2021
From: report at bugs.python.org (Battant)
Date: Sat, 05 Jun 2021 19:40:30 +0000
Subject: [New-bugs-announce] [issue44319] setup openssl faild on linux
 (ubuntu 20.04)
Message-ID: <1622922030.41.0.294175639013.issue44319@roundup.psfhosted.org>


New submission from Battant <mparchet at sunrise.ch>:

Hello,
Here is my configuration


command for ubuntu distributions

lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 20.04.2 LTS
Release:	20.04
Codename:	focal

linux kernel version
uname -r
5.4.0-74-generic


Step to reproduce

1. compile openssl 1.1.1

https://stackoverflow.com/questions/53543477/building-python-3-7-1-ssl-module-failed


clone cpython on main branch
https://github.com/python/cpython



comple python
go to module directory

run python3.11 setup.py install

Actuel result : 

I get this error : 

Could not build the ssl module!
Python requires a OpenSSL 1.1.1 or newer

running build_scripts
error: file '/usr/local/lib/python3.11/config-3.11-x86_64-linux-gnu/Tools/scripts/pydoc3' does not exist

Expend result :

python3.11 modules could be installed

Could you help me to fix this issus

Best regards

Battant

----------
assignee: christian.heimes
components: SSL
messages: 395180
nosy: Battant, christian.heimes
priority: normal
severity: normal
status: open
title: setup openssl faild on linux (ubuntu 20.04)
versions: Python 3.11

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

From report at bugs.python.org  Sat Jun  5 21:48:47 2021
From: report at bugs.python.org (OSAMU NAKAMURA)
Date: Sun, 06 Jun 2021 01:48:47 +0000
Subject: [New-bugs-announce] [issue44320] License for W3C C14N test suite is
 rendered as blockquote
Message-ID: <1622944127.79.0.396883426351.issue44320@roundup.psfhosted.org>


New submission from OSAMU NAKAMURA <osamu0329nakamura at gmail.com>:

The License text for W3C C14N test suite is rendered as quoted text, but it should be rendered same as others.

- change`:` to `::`

----------
assignee: docs at python
components: Documentation
messages: 395197
nosy: OSAMU.NAKAMURA, docs at python
priority: normal
severity: normal
status: open
title: License for W3C C14N test suite is rendered as blockquote
versions: Python 3.8

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

From report at bugs.python.org  Sun Jun  6 06:40:29 2021
From: report at bugs.python.org (Samuel Marks)
Date: Sun, 06 Jun 2021 10:40:29 +0000
Subject: [New-bugs-announce] [issue44321] os.EX_OK for Windows
Message-ID: <1622976029.7.0.66701832067.issue44321@roundup.psfhosted.org>


New submission from Samuel Marks <samuelmarks at gmail.com>:

Since Python 2.3 alpha 2 [19-Feb-2003] `EX_OK` has existed? but only for Unix. This adds support for Windows.

----------
components: Windows
messages: 395203
nosy: paul.moore, samuelmarks, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: os.EX_OK for Windows
type: enhancement

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

From report at bugs.python.org  Sun Jun  6 14:08:02 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 06 Jun 2021 18:08:02 +0000
Subject: [New-bugs-announce] [issue44322] Document SyntaxError args and
 interpretation for f-string fields
Message-ID: <1623002882.29.0.18089696259.issue44322@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Document that SyntaxError args[1] is a tuple of the other attributes and how the meaning of the attributes is adjusted when the syntax error is in an f-string field replacement expression.  Also add compile() to the list of builtins that can raise SyntaxError.

PR to follow immediately.  I wrote most of the text so that it works for 3.9 and 3.10+, with the new end info.  In the example, the main part of the message changed from "invalid syntax" to "invalid syntax. Perhaps you forgot a comma?".  I hid that with '...' but each could be given in the respective versions.  args[1] changes from "('', 1, 4, '(a b)\n')" to "('', 1, 2, '(a b)\n', 1, 5)" and that will have to be changed in a 3.9 backport.

Spinoff from #43705.  I will create a separate issue for using this information in IDLE.

----------
assignee: docs at python
components: Documentation
messages: 395208
nosy: ammar2, docs at python, pablogsal, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: Document SyntaxError args and interpretation for f-string fields
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Sun Jun  6 15:40:31 2021
From: report at bugs.python.org (Battant)
Date: Sun, 06 Jun 2021 19:40:31 +0000
Subject: [New-bugs-announce] [issue44323] insttall module faid on wondows 10
Message-ID: <1623008431.46.0.342907692424.issue44323@roundup.psfhosted.org>


New submission from Battant <mparchet at sunrise.ch>:

Hello

Configuration :
windows 10
python install p: python3.9 from microsoft store

step to reproduce :
on windows, install visual studio and buid tools
clone cpython repository main branch

https://github.com/python/cpython

compile python with command

pCbuil/bauld.bat

run command : 
.\PCbuild\amd64\py.exe .\setup.py install
Actuel result :
cpython\setup.py", line 131, in set_compiler_flags
    sysconfig.get_config_vars()[compiler_flags] = flags + ' ' + py_flags_nodist
TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'
Detail :
cpython\setup.py", line : 128
compile flag  : CFLAGS py_flags_nodist = None
compiler_flags  : CFLAGS
sysconfig  : PY_CFLAGS_NODIST
Question :
why compile flag  : CFLAGS py_flags_nodist = None )

Coud you help me to fix this issuus ?


Best regards

Battant

----------
components: Extension Modules
messages: 395210
nosy: Battant
priority: normal
severity: normal
status: open
title: insttall module faid on wondows 10
versions: Python 3.11

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

From report at bugs.python.org  Sun Jun  6 16:38:43 2021
From: report at bugs.python.org (Arjun)
Date: Sun, 06 Jun 2021 20:38:43 +0000
Subject: [New-bugs-announce] [issue44324] add a "expected expression" syntax
 error
Message-ID: <1623011923.67.0.14438904408.issue44324@roundup.psfhosted.org>


New submission from Arjun <ccldarjun at icloud.com>:

Recently, CPython got a new syntax error, "SyntaxError: expression expected after dictionary key and ':'". I propose to add a "expected expression" in general for consistency. I would like to have it changed for all the "equals" (e.g. PLUSEQUAL, MINEQUAL, etc). 


>>> x =
  File "<stdin>", line 1
    x =
        ^
SyntaxError: invalid syntax

Would be enhanced by:

>>> x +=
  File "<stdin>", line 1
    x =
         ^
SyntaxError: expected expression

----------
components: Parser
messages: 395213
nosy: CCLDArjun, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: add a "expected expression" syntax error
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Sun Jun  6 16:44:50 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 06 Jun 2021 20:44:50 +0000
Subject: [New-bugs-announce] [issue44325] IDLE: Fix shell comment anomalies
Message-ID: <1623012290.47.0.522226397666.issue44325@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Spinoff from #38673, about standard REPL, msg356271 (me) and msg356348 (Guido).  In the following interactions, no blank lines were entered.

3.9 behavior
>>> #a
>>> # a
>>>  #a
>>>  # a
 
>>> 
Mystery 1: why the blank continuation line?

I previously wrote
"ast.dump(ast.parse(' # a\n', '', 'single')) gives the same result, 'Module(body=[], type_ignores=[])', as without [space after #]".
Today, 3.8.10, 3.9.5, 3.10, and 3.11 say "unexpected EOF while parsing".

3.10 behavior
>>> #a
...  
>>> # a
>>>  #a
>>>  # a
...  
>>>
Mystery 2: why the new continuation line after '#a'?

3.11 behavior
>>> #a
>>> # a
>>> #a
>>>  #a
>>>  # a
...  
>>>
Mystery 3: why does the 3.10 regression for '#a' disappear?

Perhaps IDLE should handle initial blank lines itself, but I will investigate what codeop._maybe_compile is getting and doing in the different cases first.

----------
messages: 395214
nosy: taleinat, terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: IDLE: Fix shell comment anomalies
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Sun Jun  6 17:27:15 2021
From: report at bugs.python.org (Erlend E. Aasland)
Date: Sun, 06 Jun 2021 21:27:15 +0000
Subject: [New-bugs-announce] [issue44326] [sqlite3] remove unused db member
 from pysqlite_Statement
Message-ID: <1623014835.09.0.0517265568225.issue44326@roundup.psfhosted.org>


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

The db member of pysqlite_Statement is only "used" in the __init__ method. Suggesting to remove this. A couple of lines less of code, a couple of bytes less per statement object.

----------
assignee: erlendaasland
components: Extension Modules
messages: 395216
nosy: erlendaasland
priority: low
severity: normal
status: open
title: [sqlite3] remove unused db member from pysqlite_Statement
type: enhancement

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

From report at bugs.python.org  Sun Jun  6 17:46:11 2021
From: report at bugs.python.org (Erlend E. Aasland)
Date: Sun, 06 Jun 2021 21:46:11 +0000
Subject: [New-bugs-announce] [issue44327] [sqlite3] remove unused members
 from pysqlite_Connection
Message-ID: <1623015971.21.0.951801606377.issue44327@roundup.psfhosted.org>


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

The timeout and timeout_started members of pysqlite_Connection are never used. Suggesting to remove them.

----------
assignee: erlendaasland
components: Extension Modules
messages: 395219
nosy: erlendaasland
priority: low
severity: normal
status: open
title: [sqlite3] remove unused members from pysqlite_Connection
type: enhancement

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

From report at bugs.python.org  Sun Jun  6 18:05:07 2021
From: report at bugs.python.org (Ryan Hileman)
Date: Sun, 06 Jun 2021 22:05:07 +0000
Subject: [New-bugs-announce] [issue44328] time.monotonic() should use
 QueryPerformanceCounter() on Windows
Message-ID: <1623017107.78.0.286257337073.issue44328@roundup.psfhosted.org>


New submission from Ryan Hileman <lunixbochs at gmail.com>:

Related to https://bugs.python.org/issue41299#msg395220

Presumably `time.monotonic()` on Windows historically used GetTickCount64() because QueryPerformanceCounter() could fail. However, that hasn't been the case since Windows XP: https://docs.microsoft.com/en-us/windows/win32/api/profileapi/nf-profileapi-queryperformancecounter

> On systems that run Windows XP or later, the function will always succeed and will thus never return zero

I've run into issues with this when porting python-based applications to Windows. On other platforms, time.monotonic() was a decent precision so I used it. When I ported to Windows, I had to replace all of my time.monotonic() calls with time.perf_counter(). I would pretty much never knowingly call time.monotonic() if I knew ahead of time it could be quantized to 16ms.

My opinion is that the GetTickCount64() monotonic time code in CPython should be removed entirely and only the QueryPerformanceCounter() path should be used.

I also think some of the failure checks could be removed from QueryPerformanceCounter() / QueryPerformanceFrequency(), as they're documented to never fail in modern Windows and CPython has been dropping support for older versions of Windows, but that's less of a firm opinion.

----------
components: Library (Lib), Windows
messages: 395221
nosy: lunixbochs2, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: time.monotonic() should use QueryPerformanceCounter() on Windows
type: performance
versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Jun  6 18:21:32 2021
From: report at bugs.python.org (Erlend E. Aasland)
Date: Sun, 06 Jun 2021 22:21:32 +0000
Subject: [New-bugs-announce] [issue44329] [sqlite3] refactor
 pysqlite_statement_create
Message-ID: <1623018092.83.0.126983081124.issue44329@roundup.psfhosted.org>


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

Currently, pysqlite_statement_create() approx. looks like this:

1. some sanity checks (type, sql lenght, etc.)
2. allocate (PyObject_GC_New)
3. initialise members
4. determine if statement is a DML statement
5. create the statement (sqlite3_prepare_v2)
6. PyObject_GC_Track
7. check statement return value
8. more sanity checking
9. done!


Suggesting to refactor as this:
1. all sanity checks => early exit on failure
2. create the statement and validate return value
3. determine if statement is a DML statement => no need to do this if statement creation failed
4. allocate
5. initialise members
5. return


This will avoid unneeded allocations/GC tracking, it will avoid unneeded statement creation, and it will be more readable/maintainable.

----------
assignee: erlendaasland
components: Extension Modules
messages: 395224
nosy: erlendaasland
priority: low
severity: normal
status: open
title: [sqlite3] refactor pysqlite_statement_create
type: enhancement

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

From report at bugs.python.org  Sun Jun  6 21:41:11 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 07 Jun 2021 01:41:11 +0000
Subject: [New-bugs-announce] [issue44330] IDLE: Colorizer test hangs on macOS
Message-ID: <1623030071.98.0.487829717412.issue44330@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Ned, have you seen or heard anything about tkinter/tk8.6.11 freezing on macOS?  It is happening in many places.

On my MacBook, python3.9 -m test -ugui -v test_idle runs OK in about 10 seconds.  With installed python3.10.0b2, it runs test_colorizer ColorCongigTest, ColorDelagatorInstantionTest, and ColorDelagatorTest.test_LoadTagDefs.  It hangs on test_case_soft_keyword, which is new in 3.10 for the new match statement soft keywords.  With added skips, it hangs on
test_def_statement
test_incremental_editing
test_match_soft_keyword
test_recolorize_main
test_removecolors
and then test_colorizer passes.

At this point, I thought the problem was the fancy new test methods and helpers.  But running test_idle again, test_outwin.OutputWindowTest.test_goto_file_line (line 105) hangs displaying a blank window.  The test writes something at 115 which did not appear.  However, debug prints indicate that it is the 2nd write, about 121, that does not return.  The write method just inserts into the text widget.  Nothing apparently fancy.  The failure is deterministic (over 10 times).  In 3.9.5, the same test and all of test_idle ran OK 3 times.

Adding .update() and .update_idletasks() before the write did nothing.  Making this test method fail before the write, let the test continue until it hung in test_write.

The problem seems to be in the test environment.  Tests of match, case, and _ in Shell looked corrected.  Grepping idlelib for 'tkinter' returned 222 hits and multiple gotos for different files and lines within a file worked normally.

----------
messages: 395239
nosy: ned.deily, taleinat, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: Colorizer test hangs on macOS
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Sun Jun  6 22:41:46 2021
From: report at bugs.python.org (Neil Schemenauer)
Date: Mon, 07 Jun 2021 02:41:46 +0000
Subject: [New-bugs-announce] [issue44331] Generate static PyCodeObjects for
 faster startup
Message-ID: <1623033706.49.0.452269314092.issue44331@roundup.psfhosted.org>


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

Note: This is a proof of concept and not ready for merging as is.


This is based on 'frozen_modules' from Jeethu Rao <jeethu at jeethurao.com>, via Larry Hastings.  Larry's git branch was:

        git at github.com:larryhastings/cpython.git
        not_another_use_of_the_word_frozen

Usage:

- Compile Python as normal
- Run "make regen-freeze-startup" to re-generate Python/frozenmodules_code.c
- Compile Python a second time

Changes from Larry's branch:

- Move static C code generation tool to Tools/freeze2
- Move _serializer to Modules
- Rebase on Python 3.10.0b1
- determine startup modules by running sys.executable
- use importlib.util.find_spec() to get code objects
- fix ref-counting when setting __path__
- put static frozen modules in frozen_code_objects dict
- reduce set of "bad" modules as it seems only _collections_abc needs
  exclusion
- fix the is_frozen_package() and is_frozen() functions to find
  static frozen code

It's not passing all unit tests yet but I'm somewhat hopeful there are no deep problems.  Porting the changes from 3.6 to 3.8 and then to 3.10 was not too horrible.  There was a few changes to PyGC_Head, to the PyCodeObject structure and to the runtime initialization process.  That gives me some hope that it wouldn't be too burdensome to maintain this in the long-term.  Mostly it would be updating _serialize.c to keep up with PyCodeObject changes.

Based on benchmarking with 3.8, this gives a decent speedup for startup of a trival program, e.g. python -c "True".  I measure it as taking 76% of the time.  The savings are mostly in marshal.c but there is also some importlib/filesystem overhead that's removed.

----------
messages: 395243
nosy: nascheme
priority: low
severity: normal
stage: patch review
status: open
title: Generate static PyCodeObjects for faster startup
type: performance

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

From report at bugs.python.org  Mon Jun  7 00:56:39 2021
From: report at bugs.python.org (Debasis Satapathy)
Date: Mon, 07 Jun 2021 04:56:39 +0000
Subject: [New-bugs-announce] [issue44332] For Loop temporary variable scope
 should be local to For loop
Message-ID: <1623041799.48.0.127398218724.issue44332@roundup.psfhosted.org>


New submission from Debasis Satapathy <deb_ctc at yahoo.co.in>:

numbers = [1, 2, 3, 4, 5, 6, 7, 8]
for x in numbers:
    print(x)
print(x)

In the above code, print(x) statement should give error. Because x scope should be local to for loop only.
99% cases, developers will not use the temporary variable x outside of the for loop.
So x will keep on consuming memory always. So it is a bad usage of memory.
Ideally x memory should be free once for loop execution is completed.

----------
components: Library (Lib)
messages: 395246
nosy: deb_ctc
priority: normal
severity: normal
status: open
title: For Loop temporary variable scope should be local to For loop
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Mon Jun  7 04:12:07 2021
From: report at bugs.python.org (Kuldeep Daksh)
Date: Mon, 07 Jun 2021 08:12:07 +0000
Subject: [New-bugs-announce] [issue44333] Segmentation fault
Message-ID: <1623053527.52.0.368644825796.issue44333@roundup.psfhosted.org>


New submission from Kuldeep Daksh <mechatronickuldeep at gmail.com>:

I am getting Segmentation fault when i run server.starttls() method.

----------
components: Library (Lib)
files: segment_fault.png
messages: 395251
nosy: mechatronickuldeep
priority: normal
severity: normal
status: open
title: Segmentation fault
versions: Python 3.6
Added file: https://bugs.python.org/file50094/segment_fault.png

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

From report at bugs.python.org  Mon Jun  7 11:07:39 2021
From: report at bugs.python.org (Mustafa El Agamey)
Date: Mon, 07 Jun 2021 15:07:39 +0000
Subject: [New-bugs-announce] [issue44334] urllib cannot parse large data
Message-ID: <1623078459.0.0.104370862751.issue44334@roundup.psfhosted.org>


Change by Mustafa El Agamey <eng.mustafaelagamey at gmail.com>:


----------
components: Extension Modules
nosy: eng.mustafaelagamey
priority: normal
severity: normal
status: open
title: urllib cannot parse large data
type: performance
versions: Python 3.8

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

From report at bugs.python.org  Mon Jun  7 13:07:47 2021
From: report at bugs.python.org (Andre Roberge)
Date: Mon, 07 Jun 2021 17:07:47 +0000
Subject: [New-bugs-announce] [issue44335] "Wrong" invalid character
 identified
Message-ID: <1623085667.6.0.884749551164.issue44335@roundup.psfhosted.org>


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

When using Python 3.10.0b2 on a line with more than one invalid characters, the second one is identified as being incorrect, whereas in previous versions the first such character was identified.


> py -3.8 unicode_quote.py
  File "unicode_quote.py", line 2
    a = ? hello ? ? world ?
        ^
SyntaxError: invalid character in identifier


> py -3.9 unicode_quote.py
  File "C:\...\unicode_quote.py", line 2
    a = ? hello ? ? world ?
        ^
SyntaxError: invalid character '?' (U+00AB)


> py -3.10 unicode_quote.py
  File "C:\...\unicode_quote.py", line 2
    a = ? hello ? ? world ?
                ^
SyntaxError: invalid character '?' (U+00BB)

----------
messages: 395267
nosy: aroberge, pablogsal
priority: normal
severity: normal
status: open
title: "Wrong" invalid character identified
versions: Python 3.10

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

From report at bugs.python.org  Mon Jun  7 13:07:52 2021
From: report at bugs.python.org (Jeremy Kloth)
Date: Mon, 07 Jun 2021 17:07:52 +0000
Subject: [New-bugs-announce] [issue44336] Windows buildbots hang after fatal
 exit
Message-ID: <1623085672.48.0.908810860846.issue44336@roundup.psfhosted.org>


New submission from Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com>:

Currently, a stack overflow is causing the debug build Windows buildbots to abort (bpo-11105).  Once the regrtest process is terminated, the buildbot test process hangs indefinitely waiting for handles to be closed (see msg350191 from bpo-37531 for some details).

----------
components: Tests, Windows
messages: 395268
nosy: jkloth, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows buildbots hang after fatal exit
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Mon Jun  7 14:03:40 2021
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 07 Jun 2021 18:03:40 +0000
Subject: [New-bugs-announce] [issue44337] Port LOAD_ATTR to adaptive
 interpreter
Message-ID: <1623089020.4.0.120322851148.issue44337@roundup.psfhosted.org>


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

Port the implementation of LOAD_ATTR to the new adaptive interpreter

----------
messages: 395271
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: Port LOAD_ATTR to adaptive interpreter

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

From report at bugs.python.org  Mon Jun  7 14:04:54 2021
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 07 Jun 2021 18:04:54 +0000
Subject: [New-bugs-announce] [issue44338] Port LOAD_GLOBAL to adaptive
 interpreter
Message-ID: <1623089094.6.0.928459069961.issue44338@roundup.psfhosted.org>


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

Port the implementation of LOAD_GLOBAL to the new adaptive interpreter

Once this and https://bugs.python.org/issue44337 are implemented we can remove the old opcache.

----------
messages: 395272
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: Port LOAD_GLOBAL to adaptive interpreter

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

From report at bugs.python.org  Mon Jun  7 15:13:36 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 07 Jun 2021 19:13:36 +0000
Subject: [New-bugs-announce] [issue44339] Discrepancy between math.pow(0.0,
 -inf) and 0.0**-inf
Message-ID: <1623093216.78.0.772729157177.issue44339@roundup.psfhosted.org>


New submission from Mark Dickinson <dickinsm at gmail.com>:

For floats x and y, x ** y and math.pow(x, y) mostly agree. There are three points of difference:

1. if x is finite and negative and y is finite and non-integral, then x ** y returns a complex number, while math.pow(x, y) raises ValueError
2. for cases where x ** y raises ZeroDivisionError (for example, 0.0 ** -1.0), math.pow(x, y) raises ValueError instead
3. the special cases 0.0 ** -inf and (-0.0) ** -inf return inf, but the equivalent math.pow calls raise ValueError

That third discrepancy is a surprising one: in particular, it's the only case where math.pow does not follow IEEE 754 rules.

Note that the math.pow behaviour is not accidental. The special cases were based on C99 Annex F (and are documented to do so), but the standards themselves have evolved here. In chronological order:

- IEEE 754-1985 did not cover transcendental functions, so has nothing to say on the topic of special values for pow.
- C99 ?F.9.4.4 implies that pow(0, -inf) should raise the "divide-by-zero" exception; the relevant clause covers pow(0, y) for any y satisfying y < 0 and y not an odd integer
- IEEE 754-2008 ?9.2.1 has an explicit clause specifying that pow(0, -inf) should be inf and that the operation does not raise any exception.
- C11 ?F.10.4.4 mentions the case pow(0, -inf) explicitly and now says "may raise the divide-by-zero floating-point exception". The "may" is significant: other clauses simply say "raises the "divide-by-zero" floating-point exception".
- IEEE 754-2019 ?9.2.1 is unchanged from IEEE 754-2008 for this particular special case.
- Similarly, C17 is unchanged from C11 in this respect.

For Python 3.11, I propose changing the behaviour of math.pow in this corner case so that it returns inf instead of raising. This would make math.pow conformant with IEEE 754, consistent with C11 and later, and consistent with the built-in pow function.

----------
messages: 395277
nosy: mark.dickinson
priority: normal
severity: normal
status: open
title: Discrepancy between math.pow(0.0, -inf) and 0.0**-inf
versions: Python 3.11

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

From report at bugs.python.org  Mon Jun  7 18:38:11 2021
From: report at bugs.python.org (Brett Holman)
Date: Mon, 07 Jun 2021 22:38:11 +0000
Subject: [New-bugs-announce] [issue44340] Add support for building cpython
 with clang thin lto
Message-ID: <1623105491.02.0.949113840673.issue44340@roundup.psfhosted.org>


New submission from Brett Holman <bpholman5 at gmail.com>:

The existing --with-lto argument could be extended to pass through a value to select non-default lto compiler options:

CC=clang ./configure --with-lto=thin

This would allow default behavior to remain unchanged, while allowing those that want to use thin lto to opt in.

For what it's worth, the tests (make test) pass using clang 11.1.0 and thinlto.

----------
components: Interpreter Core
messages: 395293
nosy: holmanb
priority: normal
severity: normal
status: open
title: Add support for building cpython with clang thin lto
type: enhancement

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

From report at bugs.python.org  Mon Jun  7 19:22:07 2021
From: report at bugs.python.org (Finn Mason)
Date: Mon, 07 Jun 2021 23:22:07 +0000
Subject: [New-bugs-announce] [issue44341] Conflict between re.match and
 match keyword
Message-ID: <1623108127.98.0.605122773588.issue44341@roundup.psfhosted.org>


New submission from Finn Mason <finnjavier08 at gmail.com>:

>>> import re
>>> re.match('str', 'str').group()
'str'
>>> match 'str':
...     case 'str':
...         print('match!')
...
match!
>>> from re import match
>>> match
<function re.match ...>

As the above example demonstrates, while re.match doesn't raise an error despite having a keyword name, importing re.match directly into __main__ replaces the keyword with the function. The obvious solution is to rename re.match, but this would break many, many pieces of code.

----------
components: Library (Lib), Regular Expressions
messages: 395295
nosy: ezio.melotti, finnjavier08, mrabarnett
priority: normal
severity: normal
status: open
title: Conflict between re.match and match keyword
type: behavior
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Mon Jun  7 20:56:53 2021
From: report at bugs.python.org (Tom Brown)
Date: Tue, 08 Jun 2021 00:56:53 +0000
Subject: [New-bugs-announce] [issue44342] enum with inherited type won't
 pickle
Message-ID: <1623113813.43.0.510993848809.issue44342@roundup.psfhosted.org>


New submission from Tom Brown <thecapcom at gmail.com>:

The following script runs without error in 3.8.5 and raises an error in 3.8.6, 3.9.5 and 3.10.0b1. 

Source:
```
import enum, pickle

class MyInt(int):
    pass
    # work-around: __reduce_ex__ = int.__reduce_ex__

class MyEnum(MyInt, enum.Enum):
    A = 1

pickle.dumps(MyEnum.A)
```

Error (same in 3.8.6, 3.9.5 and 3.10.0b1):
```
Traceback (most recent call last):
  File "/home/thecap/projects/covid-data-model/./enum-pickle.py", line 12, in <module>
    pickle.dumps(MyEnum.A)
  File "/home/thecap/.pyenv/versions/3.10.0b1/lib/python3.10/enum.py", line 83, in _break_on_call_reduce
    raise TypeError('%r cannot be pickled' % self)
TypeError: MyEnum.A cannot be pickled
```

Like https://bugs.python.org/issue41889 this seems to be related to the fix for https://bugs.python.org/issue39587 which changes member_type from int to MyInt. A work-around is in the comment above.

----------
components: Library (Lib)
messages: 395300
nosy: Tom.Brown
priority: normal
severity: normal
status: open
title: enum with inherited type won't pickle
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Jun  7 22:38:29 2021
From: report at bugs.python.org (Joongi Kim)
Date: Tue, 08 Jun 2021 02:38:29 +0000
Subject: [New-bugs-announce] [issue44343] Adding the "with" statement
 support to ContextVar
Message-ID: <1623119909.23.0.724701230762.issue44343@roundup.psfhosted.org>


New submission from Joongi Kim <me at daybreaker.info>:

This is just an idea: ContextVar.set() and ContextVar.reset() looks naturally mappable with the "with" statement.

For example:

a = ContextVar('a')
token = a.set(1234)
...
a.reset(token)

could be naturally rewritten as:

a = ContextVar('a')
with a.set(1234):
    ...

Is there any particular reason *not* to do this?
If not, I'd like make a PR to add this API.
Naming suggestions of this API are welcome, but it also seems possible to keep it "set()" if we retain the reference to the ContextVar instance in the Token instance.

----------
components: Library (Lib)
messages: 395302
nosy: achimnol
priority: normal
severity: normal
status: open
title: Adding the "with" statement support to ContextVar
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Tue Jun  8 00:13:36 2021
From: report at bugs.python.org (Erik Y. Adams)
Date: Tue, 08 Jun 2021 04:13:36 +0000
Subject: [New-bugs-announce] [issue44344] Documentation for pow() should
 include the possibility of complex numbers as a return type
Message-ID: <1623125616.73.0.892905550694.issue44344@roundup.psfhosted.org>


New submission from Erik Y. Adams <erikyadams at outlook.com>:

https://docs.python.org/3/library/functions.html#pow

The built-in pow() function will return a complex number if the base is negative and the exponent is a float between 0 and 1. For example, the value returned by `pow(-1, 1.0/3)` is `(1.0000000000000002+1.7320508075688772j)`

The answer is mathematically correct, but `-2.0` is also mathematically correct. There is nothing in the documentation currently to suggest that a complex number might be returned; in fact, given the statement "[with] mixed operand types, the coercion rules for binary arithmetic operators apply", one might reasonably expect `-2.0` as the answer. 

I suggest the following sentences be added to the end of the second paragraph:

"If `base` is negative and the `exp` is a `float` between 0 and 1, a complex number will be returned. For example, `pow(-8, 1.0/3)` will return `(1.0000000000000002+1.7320508075688772j)`, and not `-2.0.`"

----------
assignee: docs at python
components: Documentation
messages: 395305
nosy: docs at python, eyadams
priority: normal
severity: normal
status: open
title: Documentation for pow() should include the possibility of complex numbers as a return type
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Tue Jun  8 00:53:30 2021
From: report at bugs.python.org (Akira Nonaka)
Date: Tue, 08 Jun 2021 04:53:30 +0000
Subject: [New-bugs-announce] [issue44345] The First-line (comment) of the
 parser.c is incorrect.
Message-ID: <1623128010.09.0.450986539958.issue44345@roundup.psfhosted.org>


New submission from Akira Nonaka <nonaka at mac.com>:

The First-line (comment) of the parser.c is incorrect.

"// @generated by pegen.py from ./Grammar/python.gram"

pegen.py no longer exists. It is now "pegen" package.

----------
components: Demos and Tools
messages: 395306
nosy: anonaka
priority: normal
severity: normal
status: open
title: The First-line (comment) of the parser.c is incorrect.
versions: Python 3.10

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

From report at bugs.python.org  Tue Jun  8 04:29:36 2021
From: report at bugs.python.org (Sergey B Kirpichev)
Date: Tue, 08 Jun 2021 08:29:36 +0000
Subject: [New-bugs-announce] [issue44346] Fraction constructor may accept
 spaces around '/'
Message-ID: <1623140976.11.0.768118294716.issue44346@roundup.psfhosted.org>


New submission from Sergey B Kirpichev <skirpichev at gmail.com>:

Per https://bugs.python.org/msg394731 suggestion.

For instance, mpq_set_str() does support this.  Also, gmpy2.mpq().

Tentative patch attached.

----------
components: Library (Lib)
files: fraction-spaces.diff
keywords: patch
messages: 395314
nosy: Sergey.Kirpichev
priority: normal
severity: normal
status: open
title: Fraction constructor may accept spaces around '/'
versions: Python 3.11
Added file: https://bugs.python.org/file50097/fraction-spaces.diff

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

From report at bugs.python.org  Tue Jun  8 05:17:12 2021
From: report at bugs.python.org (Tilman Vogel)
Date: Tue, 08 Jun 2021 09:17:12 +0000
Subject: [New-bugs-announce] [issue44347] Unclear documentation for
 shutil.copytree()
Message-ID: <1623143832.18.0.435867988934.issue44347@roundup.psfhosted.org>


New submission from Tilman Vogel <tilman.vogel at gmail.com>:

I donot understand this sentence:

"dirs_exist_ok dictates whether to raise an exception in case dst or any 
missing parent directory already exists."

How can a "missing parent directory already exist"?

My understanding would be that an existing `dst` would be OK (and copied into) but missing parent directories are just the ones above `dst` that also don't exist. 

Until 3.7, missing parent directories were documented to be auto-created (`mkdir -p`-style) according to the documentation ("The destination directory, named by dst, must not already exist; it will be created as well as missing parent directories."). Was this feature really removed? If not, then this part was accidentally (?) dropped from documentation?

What am I missing? I think, the documentation should be amended to make that clear.

----------
assignee: docs at python
components: Documentation
messages: 395315
nosy: docs at python, tilman.vogel
priority: normal
severity: normal
status: open
title: Unclear documentation for shutil.copytree()
type: enhancement
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Jun  8 05:47:57 2021
From: report at bugs.python.org (Ken Jin)
Date: Tue, 08 Jun 2021 09:47:57 +0000
Subject: [New-bugs-announce] [issue44348]
 test_exceptions.ExceptionTests.test_recursion_in_except_handler stack
 overflow on Windows debug builds
Message-ID: <1623145677.55.0.159722944157.issue44348@roundup.psfhosted.org>


New submission from Ken Jin <kenjin4096 at gmail.com>:

Hi all, I created this issue after discussion in https://bugs.python.org/issue39573#msg395206:

In issue39573 "[C API] Make PyObject an opaque structure in the limited C API" the commit f3fa63ec75fdbb4a08a10957a5c631bf0c4a5970 ("Py_TYPE becomes a static inline function") may have caused test_recursion_in_except_handler to fail only on windows debug builds (according to git bisect anyways) due to higher stack consumption causing a stack overflow.

That test was added in 4e7a69bdb63a104587759d7784124492dcdd496e (Dec 2020), and was passing until last week. Currently another test (bpo-11105, test_ast test_recursion_direct) is masking the broken test, but it's also a stack overflow in windows debug. When I reverted commit f3fa63ec75fdbb4a08a10957a5c631bf0c4a5970, test_recursion_in_except_handler passes but test_recursion_direct still fails.

For test_recursion_direct, the overflow occurs after the Py_Enter/LeaveRecursiveCall guard, when calling some other function like _PyObject_LookupAttr.

I can think of a few possible ways to fix this (in no particular order):

1. Increase stack size for windows builds from 2MB (some valid points against this though, see msg395177).
2. Decrease the global recursion limit only for windows debug.
3. Custom recursion limits for each module depending on OS, which Batuhan has been working on for AST module at GH-26550.
4. Skip the tests on windows debug, since most people on windows use release builds anyways which are unaffected.

Thanks for your time! Which approach would you prefer?

----------
components: Windows
messages: 395316
nosy: BTaskaya, kj, pablogsal, paul.moore, steve.dower, tim.golden, vstinner, zach.ware
priority: normal
severity: normal
status: open
title: test_exceptions.ExceptionTests.test_recursion_in_except_handler stack overflow on Windows debug builds
type: crash
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Tue Jun  8 13:50:20 2021
From: report at bugs.python.org (Ammar Askar)
Date: Tue, 08 Jun 2021 17:50:20 +0000
Subject: [New-bugs-announce] [issue44349] Edge case in pegen's error
 displaying with non-utf8 lines
Message-ID: <1623174620.92.0.143887592684.issue44349@roundup.psfhosted.org>


New submission from Ammar Askar <ammar at ammaraskar.com>:

The AST currently stores column offsets for characters as byte-offsets. However, when displaying errors, these byte-offsets must be turned into character-offsets so that the characters line up properly with the characters on the line when printed. This is done with the function `byte_offset_to_character_offset` (https://github.com/python/cpython/blob/fdc7e52f5f1853e350407c472ae031339ac7f60c/Parser/pegen.c#L142-L161) which assumes that the line is UTF8 encoded.

However, consider a file like this:

  '????????????' + f(4, 'Hi' for x in range(1)) # This line has a SyntaxError

This prints

  File "test-normal.py", line 1
    '????????????' + f(4, 'Hi' for x in range(1)) # This line has a SyntaxError
                          ^^^^^^^^^^^^^^^^^^^^^^
  SyntaxError: Generator expression must be parenthesized

as expected.


However if we use a custom source encoding line:

  # -*- coding: cp437 -*-
  '????????????' + f(4, 'Hi' for x in range(1)) # This line has a SyntaxError

it ends up printing out

  File "C:\Users\ammar\junk\test-utf16.py", line 2
    '??????' + f(4, 'Hi' for x in range(1)) # This line has a SyntaxError
                                      ^^^^^^^^^^^^^^^^^^^^^^
  SyntaxError: Generator expression must be parenthesized

where the carets/offsets are misaligned with the actual characters. This is because the string "??" has the display width of 2 characters and encodes to 2 bytes in cp437 but when interpreted as utf-8 is the single character "?" with a display width of 1.

Note that this edge case is relatively hard to trigger because ordinarily what will happen here is that the call to PyErr_ProgramTextObject will fail because it tries to decode the line as utf-8: https://github.com/python/cpython/blob/ae3c66acb89a6104fcd0eea760f80a0287327cc4/Python/errors.c#L1693-L1696 after which the error handling logic uses the tokenizer's internal buffer which has a proper utf-8 string.
So this bug requires the input to be valid as both utf-8 and the source encoding.

(Discovered while implementing PEP 657 https://github.com/colnotab/cpython/issues/10)

----------
components: Parser
messages: 395347
nosy: ammar2, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Edge case in pegen's error displaying with non-utf8 lines
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Tue Jun  8 14:13:50 2021
From: report at bugs.python.org (Aivar Annamaa)
Date: Tue, 08 Jun 2021 18:13:50 +0000
Subject: [New-bugs-announce] [issue44350] Support
Message-ID: <1623176030.37.0.450096721589.issue44350@roundup.psfhosted.org>


Change by Aivar Annamaa <aivar.annamaa at gmail.com>:


----------
nosy: Aivar.Annamaa
priority: normal
severity: normal
status: open
title: Support

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

From report at bugs.python.org  Tue Jun  8 15:00:01 2021
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Tue, 08 Jun 2021 19:00:01 +0000
Subject: [New-bugs-announce] [issue44351]
 distutils.sysconfig.parse_makefile() regression in Python 3.10
Message-ID: <1623178801.93.0.611041567501.issue44351@roundup.psfhosted.org>


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

Hello. I think https://github.com/python/cpython/pull/23142 changed the behavior of distutils.sysconfig.parse_makefile().

A downstream Fedora report with an affected petsc package: https://bugzilla.redhat.com/show_bug.cgi?id=1959088


Reproducers (DeprecationWarnings removed for readability):


$ cat makefile
ALL: lib

DIRS = ssls asls # isls rscs
LOCDIR = src/tao/complementarity/impls/

include ${PETSC_DIR}/lib/petsc/conf/variables
include ${PETSC_DIR}/lib/petsc/conf/rules
include ${PETSC_DIR}/lib/petsc/conf/test


$ python3.9
>>> from distutils.sysconfig import parse_makefile
>>> makevars = parse_makefile('makefile')
>>> makevars.get('DIRS','').split()
['ssls', 'asls']

$ python3.10
>>> from distutils.sysconfig import parse_makefile
>>> makevars = parse_makefile('makefile')
>>> makevars.get('DIRS','').split()
['ssls', 'asls', '#', 'isls', 'rscs']



And:

$ cat makefile
-include ../../../../petscdir.mk
ALL: lib

LIBBASE  = libpetscksp
DIRS     = cr bcgs bcgsl cg cgs gmres cheby rich lsqr preonly tcqmr tfqmr \
           qcg bicg minres symmlq lcd ibcgs python gcr fcg tsirm fetidp hpddm
LOCDIR   = src/ksp/ksp/impls/

include ${PETSC_DIR}/lib/petsc/conf/variables
include ${PETSC_DIR}/lib/petsc/conf/rules
include ${PETSC_DIR}/lib/petsc/conf/test

$ python3.9
>>> from distutils.sysconfig import parse_makefile
>>> makevars = parse_makefile('makefile')
>>> makevars.get('DIRS','').split()
['cr', 'bcgs', 'bcgsl', 'cg', 'cgs', 'gmres', 'cheby', 'rich', 'lsqr', 'preonly', 'tcqmr', 'tfqmr', 'qcg', 'bicg', 'minres', 'symmlq', 'lcd', 'ibcgs', 'python', 'gcr', 'fcg', 'tsirm', 'fetidp', 'hpddm']

$ python3.10
>>> from distutils.sysconfig import parse_makefile
>>> makevars = parse_makefile('makefile')
>>> makevars.get('DIRS','').split()
['cr', 'bcgs', 'bcgsl', 'cg', 'cgs', 'gmres', 'cheby', 'rich', 'lsqr', 'preonly', 'tcqmr', 'tfqmr', '\\']


And:

$ cat makefile
-include ../../../../petscdir.mk
ALL: lib

LIBBASE  = libpetscksp
DIRS     = jacobi none sor shell bjacobi mg eisens asm ksp composite redundant spai is pbjacobi vpbjacobi ml\
           mat hypre tfs fieldsplit factor galerkin cp wb python \
           chowiluviennacl chowiluviennaclcuda rowscalingviennacl rowscalingviennaclcuda saviennacl saviennaclcuda\
           lsc redistribute gasm svd gamg parms bddc kaczmarz telescope patch lmvm hmg deflation hpddm hara
LOCDIR   = src/ksp/pc/impls/

include ${PETSC_DIR}/lib/petsc/conf/variables
include ${PETSC_DIR}/lib/petsc/conf/rules
include ${PETSC_DIR}/lib/petsc/conf/test

$ python3.9
>>> from distutils.sysconfig import parse_makefile
>>> makevars = parse_makefile('makefile')
>>> makevars.get('DIRS','').split()
['jacobi', 'none', 'sor', 'shell', 'bjacobi', 'mg', 'eisens', 'asm', 'ksp', 'composite', 'redundant', 'spai', 'is', 'pbjacobi', 'vpbjacobi', 'ml', 'mat', 'hypre', 'tfs', 'fieldsplit', 'factor', 'galerkin', 'cp', 'wb', 'python', 'chowiluviennacl', 'chowiluviennaclcuda', 'rowscalingviennacl', 'rowscalingviennaclcuda', 'saviennacl', 'saviennaclcuda', 'lsc', 'redistribute', 'gasm', 'svd', 'gamg', 'parms', 'bddc', 'kaczmarz', 'telescope', 'patch', 'lmvm', 'hmg', 'deflation', 'hpddm', 'hara']

$ python3.10
>>> from distutils.sysconfig import parse_makefile
>>> makevars = parse_makefile('makefile')
>>> makevars.get('DIRS','').split()
['jacobi', 'none', 'sor', 'shell', 'bjacobi', 'mg', 'eisens', 'asm', 'ksp', 'composite', 'redundant', 'spai', 'is', 'pbjacobi', 'vpbjacobi', 'ml\\']

----------
components: Library (Lib)
messages: 395352
nosy: frenzy, hroncok, petr.viktorin
priority: normal
severity: normal
status: open
title: distutils.sysconfig.parse_makefile() regression in Python 3.10
type: behavior
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Tue Jun  8 15:05:21 2021
From: report at bugs.python.org (Mike Kaganski)
Date: Tue, 08 Jun 2021 19:05:21 +0000
Subject: [New-bugs-announce] [issue44352] Native Windows Python builds
 running on Europe/Moscow TZ report wrong time from datetime.datetime.now
 when there is TZ environment variable also set to Europe/Moscow
Message-ID: <1623179121.82.0.0104763138056.issue44352@roundup.psfhosted.org>


New submission from Mike Kaganski <mikekaganski at hotmail.com>:

On a Windows 10 system, which TZ is set to Moscow (UTC+3), I use a native Windows Python build (as opposed to e.g. one from Cygwin). Specifically, I tested both custom Python build created by LibreOffice project, as well as the Python by Python Software Foundation available from MS Store [1].

1. Open command prompt on Windows (cmd.exe).
2. Execute 'set TZ=Europe/Moscow'
3. Execute 'python'
4. In the Python prompt, execute 'import datetime'
5. Execute 'datetime.datetime.now()'

The result of this is a time that is two hours off, e.g.

> datetime.datetime(2021, 6, 8, 19, 59, 21, 925240)

instead of proper

> datetime.datetime(2021, 6, 8, 21, 59, 21, 925240)

which appears when step #2 is skipped.
Possibly Python takes both system time zone information *and* the environment variable into account when calculating the time. I suppose it should only consider one or the other, not both.

Note that the problem does not happen with Cygwin's Python, which works fine with the same TZ environment variable value.

For a real-life problem that results from this, see case at [2], where unit test is failing only from 00:00 till 02:00 on my local system, obviously telling me that I should sleep at that time, not try to run unit tests :-)

[1] https://www.microsoft.com/en-us/p/python-38/9mssztt1n39l
[2] https://gerrit.libreoffice.org/c/core/+/92217/2#message-f55091795e7cde9d75adc00ddb69451121b644f6

----------
components: Windows
messages: 395355
nosy: mikekaganski, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Native Windows Python builds running on Europe/Moscow TZ report wrong time from datetime.datetime.now when there is TZ environment variable also set to Europe/Moscow
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Tue Jun  8 16:21:48 2021
From: report at bugs.python.org (Joseph Perez)
Date: Tue, 08 Jun 2021 20:21:48 +0000
Subject: [New-bugs-announce] [issue44353] PEP 604 NewType
Message-ID: <1623183708.45.0.801079090844.issue44353@roundup.psfhosted.org>


New submission from Joseph Perez <joperez at hotmail.fr>:

`typing.NewType` doesn't support PEP 604.

```
>>> import typing
>>> A = typing.NewType("A", int)
>>> B = typing.NewType("B", str)
>>> A | B
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for |: 'function' and 'function'
```

----------
messages: 395359
nosy: joperez
priority: normal
severity: normal
status: open
title: PEP 604 NewType
versions: Python 3.10

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

From report at bugs.python.org  Tue Jun  8 16:36:09 2021
From: report at bugs.python.org (Thomas Grainger)
Date: Tue, 08 Jun 2021 20:36:09 +0000
Subject: [New-bugs-announce] [issue44354] ssl deprecation warnings erganomics
Message-ID: <1623184569.91.0.0837869945939.issue44354@roundup.psfhosted.org>


New submission from Thomas Grainger <tagrain at gmail.com>:

The ssl module OP_NO_* deprecation warning message is slightly wrong: The error message prints out "is deprecated is deprecated" because of an earlier format template

There's a colon in the warning message `ssl module:` and that makes it difficult to use in simplefilter

The NPN deprecation warnning raises a UserWarning instead of DeprecationWarning

see also UserWarning: ssl module: NPN is deprecated, use ALPN instead

----------
messages: 395362
nosy: alex, christian.heimes, dstufft, graingert, janssen
priority: normal
pull_requests: 25197
severity: normal
status: open
title: ssl deprecation warnings erganomics
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Tue Jun  8 21:10:05 2021
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 09 Jun 2021 01:10:05 +0000
Subject: [New-bugs-announce] [issue44355] Allow spaces in format strings
Message-ID: <1623201005.41.0.703153649475.issue44355@roundup.psfhosted.org>


New submission from Steven D'Aprano <steve+python at pearwood.info>:

Format strings should allow spaces around keys and indices. This might be as simple as running str.strip() on the contents of curly braces?

Aside from indentation and newlines, in most other contexts whitespace is insignificant. E.g. in subscripting `seq[ index ]`. But format strings treat spaces as part of the index or key, which is surprising.

f-strings, on the other hand, already allow spaces around expressions and keys:

    >>> name = 'Brian'
    >>> f'{ name.upper() }'
    'BRIAN'


Examples:

    '{ }'.format(30)
    Expect to get '30'
    but get KeyError: ' '


    '{ 0 }'.format(30)
    Expect to get '30'
    but get KeyError: ' 0 '

    '{ x }'.format(x=30)
    Expect to get '30'
    but get KeyError: ' x '


See discussion here:

https://discuss.python.org/t/please-help-key-error/9168/1

----------
messages: 395371
nosy: steven.daprano
priority: normal
severity: normal
status: open
title: Allow spaces in format strings
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Wed Jun  9 00:20:29 2021
From: report at bugs.python.org (Jordan Ephron)
Date: Wed, 09 Jun 2021 04:20:29 +0000
Subject: [New-bugs-announce] [issue44356] Abstract enum mixins not allowed
Message-ID: <1623212429.94.0.967649002759.issue44356@roundup.psfhosted.org>


New submission from Jordan Ephron <j at jephron.com>:

Prior to 3.8 it was possible to create "abstract" enums (without members) and mix them together. To motivate with an example, perhaps we're modeling an API and want to be robust in the face of inconsistent casing


class CaseInsensitiveStrEnum(str, Enum):
    @classmethod
    def _missing_(cls, value):
        for member in cls._member_map_.values():
            if member._value_.lower() == value.lower():
                return member
        return super()._missing_(value)


and perhaps we also want to be robust in response to extensibility


class LenientStrEnum(str, Enum):
    @classmethod
    def _missing_(cls, value):
        logger.warning(
            f"[{cls.__name__}] encountered an unknown value!\n"
            f"Luckily I'm a LenientStrEnum, so I won't crash just yet.\n"
            f"You might want to add a new case though.\n"
            f"Value was: '{value}'"
        )
        return UnexpectedStr(value)


but we also want to model some known good set of values, so mixing together the abstract enums we'd get something like


class JobStatus(CaseInsensitiveStrEnum, LenientStrEnum):
    ACTIVE = "active"
    PENDING = "pending"
    TERMINATED = "terminated"

However, due to the resolution of https://bugs.python.org/issue39587 this no longer works, instead producing:

TypeError: 'JobStatus': too many data types: [<class 'str'>, <class 'str'>]


The relevant change is

https://github.com/ethanfurman/cpython/commit/bff01f3a3aac0c15fe8fbe8b2f561f7927d117a1

I believe that if we made `data_types` a set rather than a list then the example would become valid once again.

----------
messages: 395378
nosy: JEphron
priority: normal
severity: normal
status: open
title: Abstract enum mixins not allowed
type: behavior
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Jun  9 03:45:49 2021
From: report at bugs.python.org (Ajith Ramachandran)
Date: Wed, 09 Jun 2021 07:45:49 +0000
Subject: [New-bugs-announce] [issue44357] Add math.cbrt() function: Cube Root
Message-ID: <1623224749.57.0.0756711881662.issue44357@roundup.psfhosted.org>


Change by Ajith Ramachandran <ajithar204 at gmail.com>:


----------
components: Library (Lib)
nosy: AjithRamachandran
priority: normal
severity: normal
status: open
title: Add math.cbrt() function: Cube Root
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Wed Jun  9 03:50:20 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Jun 2021 07:50:20 +0000
Subject: [New-bugs-announce] [issue44358] AMD64 RHEL8 LTO + PGO 3.x build
 failed with: /usr/bin/ld: Dwarf Error: Offset (2487097600) greater than or
 equal to .debug_str size (571933).
Message-ID: <1623225020.58.0.673640131019.issue44358@roundup.psfhosted.org>


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

On RHEL8, gcc (GCC) 8.4.1 20200928 (Red Hat 8.4.1-1) fails to build Python with LTO+PGO: the linker fails with "Dwarf Error".

On ~200 builds, the linker error only occurred once (build 279) :-( It sounds really hard to reproduce.

I suggest to close the issue as "out of date" if it doesn't come back next weeks.

https://buildbot.python.org/all/#/builders/568/builds/279

gcc -pthread   -fno-semantic-interposition -flto -fuse-linker-plugin -ffat-lto-objects -flto-partition=none -g -fprofile-generate -Xlinker -export-dynamic -o Programs/_testembed Programs/_testembed.o libpython3.11.a -lcrypt -lpthread -ldl  -lutil -lm   -lm 
/usr/bin/ld: Dwarf Error: Offset (2487097600) greater than or equal to .debug_str size (571933).
/usr/bin/ld: Dwarf Error: Could not find abbrev number 12095.

Then the linker failed to find many symbols:

/tmp/cccV00H7.lto.o: In function `signal_pthread_sigmask':
<artificial>:(.text+0x292cbc): undefined reference to `_Py_Sigset_Converter'
/tmp/cccV00H7.lto.o: In function `fill_siginfo':
<artificial>:(.text+0x2930cb): undefined reference to `_PyLong_FromUid'
/tmp/cccV00H7.lto.o: In function `signal_sigwaitinfo':
<artificial>:(.text+0x29325e): undefined reference to `_Py_Sigset_Converter'
/tmp/cccV00H7.lto.o: In function `signal_sigtimedwait':
<artificial>:(.text+0x293566): undefined reference to `_Py_Sigset_Converter'
/tmp/cccV00H7.lto.o: In function `signal_sigwait':
<artificial>:(.text+0x293af0): undefined reference to `_Py_Sigset_Converter'
/tmp/cccV00H7.lto.o: In function `PyUnicode_FSDecoder':
<artificial>:(.text+0x315fed): undefined reference to `PyOS_FSPath'
/tmp/cccV00H7.lto.o: In function `mkpwent':
<artificial>:(.text+0x31a78c): undefined reference to `_PyLong_FromUid'
<artificial>:(.text+0x31a7a1): undefined reference to `_PyLong_FromGid'
/tmp/cccV00H7.lto.o: In function `pwd_getpwuid':
<artificial>:(.text+0x31afb6): undefined reference to `_Py_Uid_Converter'
<artificial>:(.text+0x31b1df): undefined reference to `_PyLong_FromUid'
/tmp/cccV00H7.lto.o: In function `PyUnicode_FSConverter':
<artificial>:(.text+0x349247): undefined reference to `PyOS_FSPath'
/tmp/cccV00H7.lto.o: In function `_io_open':
<artificial>:(.text+0x38781d): undefined reference to `PyOS_FSPath'
/tmp/cccV00H7.lto.o:(.data+0x74528): undefined reference to `PyInit_posix'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:603: python] Error 1
make[3]: *** Waiting for unfinished jobs....
/usr/bin/ld: Dwarf Error: Could not find abbrev number 6864.
/tmp/ccMUbctW.lto.o: In function `fill_siginfo':
<artificial>:(.text+0x1f010b): undefined reference to `_PyLong_FromUid'
/tmp/ccMUbctW.lto.o: In function `signal_sigwait':
<artificial>:(.text+0x2a6d80): undefined reference to `_Py_Sigset_Converter'
/tmp/ccMUbctW.lto.o: In function `signal_sigwaitinfo':
<artificial>:(.text+0x2a821e): undefined reference to `_Py_Sigset_Converter'
/tmp/ccMUbctW.lto.o: In function `signal_pthread_sigmask':
<artificial>:(.text+0x2b05bc): undefined reference to `_Py_Sigset_Converter'
/tmp/ccMUbctW.lto.o: In function `signal_sigtimedwait':
<artificial>:(.text+0x2b2536): undefined reference to `_Py_Sigset_Converter'
/tmp/ccMUbctW.lto.o: In function `PyUnicode_FSDecoder':
<artificial>:(.text+0x30d08d): undefined reference to `PyOS_FSPath'
/tmp/ccMUbctW.lto.o: In function `mkpwent':
<artificial>:(.text+0x30edac): undefined reference to `_PyLong_FromUid'
<artificial>:(.text+0x30edc1): undefined reference to `_PyLong_FromGid'
/tmp/ccMUbctW.lto.o: In function `pwd_getpwuid':
<artificial>:(.text+0x30f5d6): undefined reference to `_Py_Uid_Converter'
<artificial>:(.text+0x30f7ff): undefined reference to `_PyLong_FromUid'
/tmp/ccMUbctW.lto.o: In function `PyUnicode_FSConverter':
<artificial>:(.text+0x33b157): undefined reference to `PyOS_FSPath'
/tmp/ccMUbctW.lto.o: In function `_io_open':
<artificial>:(.text+0x377d0d): undefined reference to `PyOS_FSPath'
/tmp/ccMUbctW.lto.o:(.data+0x84748): undefined reference to `PyInit_posix'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:744: Programs/_testembed] Error 1
make[3]: Leaving directory '/home/buildbot/buildarea/3.x.cstratak-RHEL8-x86_64.lto-pgo/build'
make[2]: *** [Makefile:533: build_all_generate_profile] Error 2
make[2]: Leaving directory '/home/buildbot/buildarea/3.x.cstratak-RHEL8-x86_64.lto-pgo/build'
make[1]: *** [Makefile:509: profile-gen-stamp] Error 2
make[1]: Leaving directory '/home/buildbot/buildarea/3.x.cstratak-RHEL8-x86_64.lto-pgo/build'
make: *** [Makefile:521: profile-run-stamp] Error 2
program finished with exit code 2
elapsedTime=157.205212

----------
components: Build
messages: 395386
nosy: pablogsal, vstinner
priority: normal
severity: normal
status: open
title: AMD64 RHEL8 LTO + PGO 3.x build failed with: /usr/bin/ld: Dwarf Error: Offset (2487097600) greater than or equal to .debug_str size (571933).
versions: Python 3.11

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

From report at bugs.python.org  Wed Jun  9 03:58:31 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Jun 2021 07:58:31 +0000
Subject: [New-bugs-announce] [issue44359] test_ftplib fails as "env changes"
 if a socket operation times out in a thread: TimeoutError is not catched
Message-ID: <1623225511.63.0.739788412824.issue44359@roundup.psfhosted.org>


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

test_ftplib fails with "env changed" if a socket operation times out in a thread (in the "dummy FTP server").

Example on AMD64 Fedora Rawhide LTO 3.10:
https://buildbot.python.org/all/#/builders/653/builds/95

0:02:41 load avg: 8.20 [394/427/1] test_ftplib failed (env changed) -- running: test_lib2to3 (33.9 sec), test_peg_generator (2 min 37 sec), test_concurrent_futures (1 min 53 sec), test_gdb (1 min 37 sec)
Warning -- Uncaught thread exception: Exception
Exception in thread Thread-34:
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.10.cstratak-fedora-rawhide-x86_64.lto/build/Lib/asyncore.py", line 83, in read
    obj.handle_read_event()
  File "/home/buildbot/buildarea/3.10.cstratak-fedora-rawhide-x86_64.lto/build/Lib/asyncore.py", line 420, in handle_read_event
    self.handle_read()
  File "/home/buildbot/buildarea/3.10.cstratak-fedora-rawhide-x86_64.lto/build/Lib/asynchat.py", line 171, in handle_read
    self.found_terminator()
  File "/home/buildbot/buildarea/3.10.cstratak-fedora-rawhide-x86_64.lto/build/Lib/test/test_ftplib.py", line 129, in found_terminator
    method(arg)
  File "/home/buildbot/buildarea/3.10.cstratak-fedora-rawhide-x86_64.lto/build/Lib/test/test_ftplib.py", line 154, in cmd_pasv
    conn, addr = sock.accept()
  File "/home/buildbot/buildarea/3.10.cstratak-fedora-rawhide-x86_64.lto/build/Lib/socket.py", line 293, in accept
    fd, addr = self._accept()
TimeoutError: timed out

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.10.cstratak-fedora-rawhide-x86_64.lto/build/Lib/threading.py", line 1006, in _bootstrap_inner
    self.run()
  File "/home/buildbot/buildarea/3.10.cstratak-fedora-rawhide-x86_64.lto/build/Lib/test/test_ftplib.py", line 292, in run
    asyncore.loop(timeout=0.1, count=1)
  File "/home/buildbot/buildarea/3.10.cstratak-fedora-rawhide-x86_64.lto/build/Lib/asyncore.py", line 207, in loop
    poll_fun(timeout, map)
  File "/home/buildbot/buildarea/3.10.cstratak-fedora-rawhide-x86_64.lto/build/Lib/asyncore.py", line 150, in poll
    read(obj)
  File "/home/buildbot/buildarea/3.10.cstratak-fedora-rawhide-x86_64.lto/build/Lib/asyncore.py", line 87, in read
    obj.handle_error()
  File "/home/buildbot/buildarea/3.10.cstratak-fedora-rawhide-x86_64.lto/build/Lib/test/test_ftplib.py", line 134, in handle_error
    raise Exception
Exception

test_abort (test.test_ftplib.TestFTPClass) ... ok
(...)
test__all__ (test.test_ftplib.MiscTestCase) ... ok

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

Ran 94 tests in 8.491s

OK (skipped=2)



A similar issue (is it the same one?) can be reproduced with attached test_ftplib_timeout.patch which sets the timeout to 1 nanosecond and the command:

$ ./python -m test test_ftplib -v --fail-env-changed -m test.test_ftplib.TestFTPClass.test_retrlines
== CPython 3.11.0a0 (heads/main:257e400a19, Jun 8 2021, 18:04:17) [GCC 11.1.1 20210531 (Red Hat 11.1.1-3)]
== Linux-5.12.8-300.fc34.x86_64-x86_64-with-glibc2.33 little-endian
== cwd: /home/vstinner/python/main/build/test_python_129053?
== CPU count: 8
== encodings: locale=UTF-8, FS=utf-8
0:00:00 load avg: 1.03 Run tests sequentially
0:00:00 load avg: 1.03 [1/1] test_ftplib
test_retrlines (test.test_ftplib.TestFTPClass) ... Warning -- Uncaught thread exception: Exception
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/home/vstinner/python/main/Lib/asyncore.py", line 83, in read
    obj.handle_read_event()
  File "/home/vstinner/python/main/Lib/asyncore.py", line 420, in handle_read_event
    self.handle_read()
  File "/home/vstinner/python/main/Lib/asynchat.py", line 171, in handle_read
    self.found_terminator()
  File "/home/vstinner/python/main/Lib/test/test_ftplib.py", line 129, in found_terminator
    method(arg)
  File "/home/vstinner/python/main/Lib/test/test_ftplib.py", line 154, in cmd_pasv
    conn, addr = sock.accept()
  File "/home/vstinner/python/main/Lib/socket.py", line 293, in accept
    fd, addr = self._accept()
TimeoutError: timed out

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/vstinner/python/main/Lib/threading.py", line 1006, in _bootstrap_inner
    self.run()
  File "/home/vstinner/python/main/Lib/test/test_ftplib.py", line 292, in run
    asyncore.loop(timeout=0.1, count=1)
  File "/home/vstinner/python/main/Lib/asyncore.py", line 207, in loop
    poll_fun(timeout, map)
  File "/home/vstinner/python/main/Lib/asyncore.py", line 150, in poll
    read(obj)
  File "/home/vstinner/python/main/Lib/asyncore.py", line 87, in read
    obj.handle_error()
  File "/home/vstinner/python/main/Lib/test/test_ftplib.py", line 134, in handle_error
    raise Exception
Exception
ERROR

======================================================================
ERROR: test_retrlines (test.test_ftplib.TestFTPClass)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/vstinner/python/main/Lib/test/test_ftplib.py", line 598, in test_retrlines
    self.client.retrlines('retr', received.append)
  File "/home/vstinner/python/main/Lib/ftplib.py", line 462, in retrlines
    with self.transfercmd(cmd) as conn, \
  File "/home/vstinner/python/main/Lib/ftplib.py", line 393, in transfercmd
    return self.ntransfercmd(cmd, rest)[0]
  File "/home/vstinner/python/main/Lib/ftplib.py", line 354, in ntransfercmd
    conn = socket.create_connection((host, port), self.timeout,
  File "/home/vstinner/python/main/Lib/socket.py", line 844, in create_connection
    raise err
  File "/home/vstinner/python/main/Lib/socket.py", line 832, in create_connection
    sock.connect(sa)
ConnectionRefusedError: [Errno 111] Connection refused

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

Ran 1 test in 0.021s

FAILED (errors=1)
test test_ftplib failed
test_ftplib failed

== Tests result: FAILURE ==

1 test failed:
    test_ftplib

Total duration: 169 ms
Tests result: FAILURE

----------
components: Tests
files: test_ftplib_timeout.patch
keywords: patch
messages: 395389
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_ftplib fails as "env changes" if a socket operation times out in a thread: TimeoutError is not catched
versions: Python 3.10, Python 3.11
Added file: https://bugs.python.org/file50100/test_ftplib_timeout.patch

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

From report at bugs.python.org  Wed Jun  9 04:06:22 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Jun 2021 08:06:22 +0000
Subject: [New-bugs-announce] [issue44360] test_compile segfault on AMD64
 Ubuntu 3.x
Message-ID: <1623225982.87.0.660015113857.issue44360@roundup.psfhosted.org>


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

test_compile and test_multiprocessing_forkserver crashed with segfault (SIGSEGV) on AMD64 Ubuntu 3.x:
https://buildbot.python.org/all/#/builders/708/builds/31

It *seems* like test_compile.test_stack_overflow() crashed, but the log is not reliable so I cannot confirm.

According to buildbot, the responsible change is:
"bpo-43693: Un-revert commit f3fa63e. (#26609)(10 hours ago)"
https://github.com/python/cpython/commit/3e1c7167d86a2a928cdcb659094aa10bb5550c4c

So Eric, can you please investigate the change? If nobody is available to fix the buildbot, I suggest to revert the change.


Python was built in debug mode with:

./configure --prefix '$(PWD)/target' --with-pydebug
make all


test.pythoninfo:

CC.version: gcc (Ubuntu 10.3.0-1ubuntu1) 10.3.0
os.uname: posix.uname_result(sysname='Linux', nodename='doxy.learntosolveit.com', release='5.11.0-18-generic', version='#19-Ubuntu SMP Fri May 7 14:22:03 UTC 2021', machine='x86_64')
platform.platform: Linux-5.11.0-18-generic-x86_64-with-glibc2.33
sys.thread_info: sys.thread_info(name='pthread', lock='semaphore', version='NPTL 2.33')


Logs:

./python  ./Tools/scripts/run_tests.py -j 1 -u all -W --slowest --fail-env-changed --timeout=900 -j2 --junit-xml test-results.xml 
== CPython 3.11.0a0 (heads/main:3e1c7167d8, Jun 8 2021, 22:09:42) [GCC 10.3.0]
== Linux-5.11.0-18-generic-x86_64-with-glibc2.33 little-endian
== cwd: /home/buildbot/buildarea/3.x.skumaran-ubuntu-x86_64/build/build/test_python_1439770?
== CPU count: 1
== encodings: locale=UTF-8, FS=utf-8
Using random seed 5059550
0:00:00 load avg: 0.97 Run tests in parallel using 2 child processes (timeout: 15 min, worker timeout: 20 min)
(...)
0:00:43 load avg: 2.22 running: test_compile (34.7 sec), test_signal (30.8 sec)
0:01:12 load avg: 3.84 [ 13/427/1] test_compile crashed (Exit code -9) -- running: test_signal (59.6 sec)
(...)
0:06:26 load avg: 1.84 running: test_concurrent_futures (42.0 sec), test_multiprocessing_forkserver (30.0 sec)
0:06:56 load avg: 3.91 running: test_concurrent_futures (1 min 12 sec), test_multiprocessing_forkserver (1 min)
0:07:26 load avg: 5.47 running: test_concurrent_futures (1 min 42 sec), test_multiprocessing_forkserver (1 min 30 sec)
0:07:58 load avg: 5.93 running: test_concurrent_futures (2 min 13 sec), test_multiprocessing_forkserver (2 min 2 sec)
0:08:30 load avg: 5.73 running: test_concurrent_futures (2 min 44 sec), test_multiprocessing_forkserver (2 min 33 sec)
0:08:48 load avg: 4.62 [ 85/427/2] test_multiprocessing_forkserver crashed (Exit code -9) -- running: test_concurrent_futures (3 min 3 sec)
(...)
2 tests failed:
    test_compile test_multiprocessing_forkserver
(...)
0:27:56 load avg: 1.28 Re-running test_compile in verbose mode
test_and (test.test_compile.TestExpressionStackSize) ... ok
(...)
test_sequence_unpacking_error (test.test_compile.TestSpecifics) ... ok
test_single_statement (test.test_compile.TestSpecifics) ... ok
test_stack_overflow (test.test_compile.TestSpecifics) ... 
make: *** [Makefile:1256: buildbottest] Killed
program finished with exit code 2
elapsedTime=1684.973552

----------
components: Tests
messages: 395390
nosy: eric.snow, pablogsal, vstinner
priority: normal
severity: normal
status: open
title: test_compile segfault on AMD64 Ubuntu 3.x
versions: Python 3.11

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

From report at bugs.python.org  Wed Jun  9 04:12:30 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Jun 2021 08:12:30 +0000
Subject: [New-bugs-announce] [issue44361] test_smtpnet failed with
 SMTPServerDisconnected on x86 Gentoo Non-Debug with X 3.10
Message-ID: <1623226350.91.0.267462887988.issue44361@roundup.psfhosted.org>


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

x86 Gentoo Non-Debug with X 3.10:
https://buildbot.python.org/all/#/builders/698/builds/112

This buildbot worker has Internet connection issues, so my concern is only how test_smtpnet handles Internet issues.

The two tests which fail use "with socket_helper.transient_internet(self.testServer):", but it seems like this context manager doesn't catch SMTPServerDisconnected.

Maybe transient_internet() should be modified to catch smtplib.SMTPServerDisconnected (or even the generic smtplib.SMTPException)?

======================================================================
ERROR: test_connect_default_port (test.test_smtpnet.SmtpSSLTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/buildbot/buildarea/cpython/3.10.ware-gentoo-x86.nondebug/build/Lib/test/test_smtpnet.py", line 60, in test_connect_default_port
    server = smtplib.SMTP_SSL(self.testServer)
  File "/buildbot/buildarea/cpython/3.10.ware-gentoo-x86.nondebug/build/Lib/smtplib.py", line 1045, in __init__
    SMTP.__init__(self, host, port, local_hostname, timeout,
  File "/buildbot/buildarea/cpython/3.10.ware-gentoo-x86.nondebug/build/Lib/smtplib.py", line 255, in __init__
    (code, msg) = self.connect(host, port)
  File "/buildbot/buildarea/cpython/3.10.ware-gentoo-x86.nondebug/build/Lib/smtplib.py", line 343, in connect
    (code, msg) = self.getreply()
  File "/buildbot/buildarea/cpython/3.10.ware-gentoo-x86.nondebug/build/Lib/smtplib.py", line 400, in getreply
    raise SMTPServerDisconnected("Connection unexpectedly closed")
smtplib.SMTPServerDisconnected: Connection unexpectedly closed

======================================================================
ERROR: test_connect_using_sslcontext (test.test_smtpnet.SmtpSSLTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/buildbot/buildarea/cpython/3.10.ware-gentoo-x86.nondebug/build/Lib/test/test_smtpnet.py", line 70, in test_connect_using_sslcontext
    server = smtplib.SMTP_SSL(self.testServer, self.remotePort, context=context)
  File "/buildbot/buildarea/cpython/3.10.ware-gentoo-x86.nondebug/build/Lib/smtplib.py", line 1045, in __init__
    SMTP.__init__(self, host, port, local_hostname, timeout,
  File "/buildbot/buildarea/cpython/3.10.ware-gentoo-x86.nondebug/build/Lib/smtplib.py", line 255, in __init__
    (code, msg) = self.connect(host, port)
  File "/buildbot/buildarea/cpython/3.10.ware-gentoo-x86.nondebug/build/Lib/smtplib.py", line 343, in connect
    (code, msg) = self.getreply()
  File "/buildbot/buildarea/cpython/3.10.ware-gentoo-x86.nondebug/build/Lib/smtplib.py", line 400, in getreply
    raise SMTPServerDisconnected("Connection unexpectedly closed")
smtplib.SMTPServerDisconnected: Connection unexpectedly closed

----------
components: Tests
messages: 395393
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_smtpnet failed with SMTPServerDisconnected on x86 Gentoo Non-Debug with X 3.10
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Wed Jun  9 05:02:28 2021
From: report at bugs.python.org (Thomas Grainger)
Date: Wed, 09 Jun 2021 09:02:28 +0000
Subject: [New-bugs-announce] [issue44362] improve documentation of SSL
 deprecations
Message-ID: <1623229348.31.0.791251182567.issue44362@roundup.psfhosted.org>


New submission from Thomas Grainger <tagrain at gmail.com>:

> I can see in the 3.10 release notes, that ssl.PROTOCOL_TLS becomes deprecated. Is there any further context explaining why, and what the preferred usage is instead, so that I (and anyone else) can understand this a bit more thoroughly?

https://github.com/encode/httpx/issues/1670#issuecomment-857509311

----------
messages: 395398
nosy: alex, christian.heimes, dstufft, graingert, janssen
priority: normal
severity: normal
status: open
title: improve documentation of SSL deprecations
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Wed Jun  9 05:30:48 2021
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 09 Jun 2021 09:30:48 +0000
Subject: [New-bugs-announce] [issue44363] Likely false positive for address
 sanitizer after fork
Message-ID: <1623231048.1.0.253699094355.issue44363@roundup.psfhosted.org>


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

Running the buildbot for https://github.com/python/cpython/pull/26595
results in failures:
https://buildbot.python.org/all/#/builders/581/builds/63
Which claim that the address calculation in `LOAD_ATTR_MODULE` is out of bounds.

The tests pass with an added assert to verify that the address in question is in bounds. 

All failures seem to happen after a fork, which seems to be a longstanding weakness of the address sanitizer.

I'd like to merge https://github.com/python/cpython/pull/26595. I'd also like to keep the buildbots working. Dichotomy.

----------
messages: 395403
nosy: Mark.Shannon, pablogsal
priority: normal
severity: normal
status: open
title: Likely false positive for address sanitizer after fork

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

From report at bugs.python.org  Wed Jun  9 11:14:51 2021
From: report at bugs.python.org (Ajith Ramachandran)
Date: Wed, 09 Jun 2021 15:14:51 +0000
Subject: [New-bugs-announce] [issue44364] Add non integral tests for `sqrt()`
Message-ID: <1623251691.77.0.68992058324.issue44364@roundup.psfhosted.org>


Change by Ajith Ramachandran <ajithar204 at gmail.com>:


----------
components: Tests
nosy: AjithRamachandran
priority: normal
severity: normal
status: open
title: Add non integral tests for `sqrt()`
type: enhancement
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Wed Jun  9 11:33:08 2021
From: report at bugs.python.org (Micael Jarniac)
Date: Wed, 09 Jun 2021 15:33:08 +0000
Subject: [New-bugs-announce] [issue44365] Bad dataclass post-init example
Message-ID: <1623252788.44.0.375918246935.issue44365@roundup.psfhosted.org>


New submission from Micael Jarniac <micael at jarniac.com>:

https://docs.python.org/3/library/dataclasses.html#post-init-processing

https://github.com/python/cpython/blob/3.9/Doc/library/dataclasses.rst#post-init-processing

In the example, a base class "Rectangle" is defined, and then a "Square" class inherits from it.

On reading the example, it seems like the Square class is meant to be used like:

>>> square = Square(5)

Since the Square class seems to be supposed to be a "shortcut" to creating a Rectangle with equal sides.

However, the Rectangle class has two required init arguments, and when Square inherits from it, those arguments are still required, so using Square like in the above example, with a single argument, results in an error:

>>> square = Square(5)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __init__() missing 2 required positional arguments: 'width' and 'side'

To "properly" use the Square class, it'd need to be instantiated like so:

>>> square = Square(0, 0, 5)
>>> square
Square(height=5, width=5, side=5)

Which, in my opinion, is completely counter-intuitive, and basically invalidates this example.

----------
assignee: docs at python
components: Documentation
messages: 395427
nosy: MicaelJarniac, docs at python
priority: normal
severity: normal
status: open
title: Bad dataclass post-init example
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Wed Jun  9 12:54:16 2021
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Wed, 09 Jun 2021 16:54:16 +0000
Subject: [New-bugs-announce] [issue44366] Define functions without
 parentheses (if no parameters given)
Message-ID: <1623257656.83.0.503591632705.issue44366@roundup.psfhosted.org>


New submission from Bo?tjan Mejak <bostjan.xperia at gmail.com>:

The syntax to define a class looks like this:

class MyClass:
    pass

Nice and neat.

***
And the syntax to define a function looks like this:

def my_function():
    pass

Hmmm...

***
What if we could define functions (that don't have any parameters) like this:

def my_function:
    pass

***
Is that a possible scenario at this point, or even desirable?

----------
components: Interpreter Core
messages: 395436
nosy: PedanticHacker
priority: normal
severity: normal
status: open
title: Define functions without parentheses (if no parameters given)
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Wed Jun  9 12:54:52 2021
From: report at bugs.python.org (Bhavna Sewani)
Date: Wed, 09 Jun 2021 16:54:52 +0000
Subject: [New-bugs-announce] [issue44367] Python Code for WebView2 Exe
 Testing
Message-ID: <1623257692.76.0.177889854171.issue44367@roundup.psfhosted.org>


New submission from Bhavna Sewani <bhavna.sewani at gmail.com>:

I have an application developed using webview2.
It is a web application that would be driven by Microsoft Edge(Chromium). It would give a feel of Native/Desktop app
instead of web app to the end user.

I want to automate testing for this app using Python/Robot framework. 
I found an documentation which uses Dotnet, Selenium and Edge drivers for testing it.

https://docs.microsoft.com/en-us/microsoft-edge/webview2/how-to/webdriver

Can someone help how can we write below code in Python and Robot to test the same using Selenium Library:

static void Main(string[] args)
{
    
	EdgeOptions edgeOptions = new EdgeOptions(false, "webview2");
	edgeOptions.BinaryLocation = @"C:\path\to\your\webview2\project.exe";
	string msedgedriverDir = @"C:\path\to\your\msededriver.exe's\directory";
	string msedgedriverExe = @"msedgedriver.exe";
	EdgeDriverService service = EdgeDriverService.CreateDefaultService(msedgedriverDir, msedgedriverExe, false);

	EdgeDriver e = new EdgeDriver(service, edgeOptions);
	e.Url = @"https://www.microsoft.com"; //myexe or webpage path
	e.Quit();
}

----------
components: Library (Lib)
messages: 395437
nosy: bhavna.sewani, gvanrossum, ncoghlan
priority: normal
severity: normal
status: open
title: Python Code for WebView2 Exe Testing
versions: Python 3.7

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

From report at bugs.python.org  Wed Jun  9 15:47:35 2021
From: report at bugs.python.org (Brandt Bucher)
Date: Wed, 09 Jun 2021 19:47:35 +0000
Subject: [New-bugs-announce] [issue44368] Invalid mapping patterns give
 confusing SyntaxErrors
Message-ID: <1623268055.49.0.141846106713.issue44368@roundup.psfhosted.org>


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

Here are a few that I found. Not sure when they were introduced:

match ...:
    case {**rest, "key": value}:
        pass

match ...:
    case {"first": first, **rest, "last": last}:
        pass

match ...:
    case {**_}:
        pass

These all give the following error while parsing the second line:

  File "<stdin>", line 1
    match ...:
    ^^^^^^^^^
SyntaxError: invalid syntax. Perhaps you forgot a comma?

----------
components: Parser
messages: 395453
nosy: brandtbucher, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Invalid mapping patterns give confusing SyntaxErrors
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Wed Jun  9 17:15:52 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 09 Jun 2021 21:15:52 +0000
Subject: [New-bugs-announce] [issue44369] Improve syntax error for wrongly
 closed strings
Message-ID: <1623273352.85.0.523852871256.issue44369@roundup.psfhosted.org>


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

Let's asume this string:
"
x = "Cannot recover from "MemoryErrors" while something happnes while "

The line is incorrect because the quotes arround MemoryErrors are the same as the string is used, resulting in STRING + expression + STRING.

Currenly we say:

>>> 'Cannot recover from 'MemoryErrors' while '
  File "<stdin>", line 1
    'Cannot recover from 'MemoryErrors' while '
                          ^
SyntaxError: invalid syntax

but I think it will be a great improvement if we say:

>>> 'Cannot recover from 'MemoryErrors' while '
  File "<stdin>", line 1
    'Cannot recover from 'MemoryErrors' while '
                          ^^^^^^^^^^^^
SyntaxError: invalid syntax. Did you use the same quotes here as the string?

Probably the message should be better, but I think this is a good improvement.

----------
components: Parser
messages: 395476
nosy: lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Improve syntax error for wrongly closed strings
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Wed Jun  9 21:54:15 2021
From: report at bugs.python.org (=?utf-8?q?Jo=C3=ABl_Larose?=)
Date: Thu, 10 Jun 2021 01:54:15 +0000
Subject: [New-bugs-announce] [issue44370] Inconsistent results for min() and
 max() with math.nan as argument
Message-ID: <1623290055.89.0.0955889494044.issue44370@roundup.psfhosted.org>


New submission from Jo?l Larose <joel.larose at gmail.com>:

If `math.nan` is the first argument for either max() or min(), the result is always `nan`, regardless of the other values in the results.  However, if `nan` is in any other position in the arguments list, the result is always what you would expect if `nan` was not in the arguments list.

E.g.
from math import nan, inf

>>> max(nan, 5, 3, 0)
nan

>>> min(nan, 5, 3, 0)
nan

>>> min(nan, 5, 3, 0, inf, -inf)
nan

>>> max(nan, 5, 3, 0, inf, -inf)
nan

>>> max(inf, 5, 3, 0, nan, -inf)
inf

>>> max(8, inf, 5, 3, 0, nan, -inf)
inf

>>> min(8, inf, 5, 3, 0, nan, -inf)
-inf

>>> min(8, nan, inf, 5, 3, 0, nan, -inf)
-inf

>>> max(8, nan, inf, 5, 3, 0, nan, -inf)
inf

>>> max(8, 5, 3, 0, nan)
8

As you can see, the results for min() and max() are inconsistent for `nan` depending on whether it's the first argument or not.

I would prefer for min() and max() to ignore `nan` unless all arguments are `nan`.  However, the other path for consistent behaviour is to return `nan` if any of the arguments are `nan`.

----------
components: Interpreter Core
messages: 395497
nosy: joel.larose
priority: normal
severity: normal
status: open
title: Inconsistent results for min() and max() with math.nan as argument
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Thu Jun 10 01:55:58 2021
From: report at bugs.python.org (Ofek Kirzner)
Date: Thu, 10 Jun 2021 05:55:58 +0000
Subject: [New-bugs-announce] [issue44371] asyncio.wait_for does not cancel
 running tasks in the correct fashion
Message-ID: <1623304558.86.0.995602779591.issue44371@roundup.psfhosted.org>


New submission from Ofek Kirzner <ofekkir at gmail.com>:

Following https://bugs.python.org/issue32751 I think wait_for should also wait for running coroutine in case it has been cancelled.

Example code:

import asyncio


async def inner():
    try:
        print(1)
        await asyncio.sleep(3600)
        print(2)
    except asyncio.CancelledError:
        print('inner - canc')
        raise


async def outer(f):
    try:
        print('a')
        # Version 1 - This creates the expected behaviour
        # await f
        # Version 2 - This creates the reversed behaviour
        await asyncio.wait_for(f, timeout=500)
        print('b')
    except asyncio.CancelledError:
        print('outer - canc')


@pytest.mark.asyncio
async def test_t1():
    t = asyncio.create_task(outer(inner()))
    done, pending = await asyncio.wait([t], timeout=1)
    t.cancel()

    await t

------
I expect inner to be cancelled and awaited before outer is finished.
i.e., exepcted output:
1
inner - canc
outer - canc


While I get:
1
outer - canc
inner - canc

----------
components: asyncio
messages: 395505
nosy: asvetlov, ofekkir, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.wait_for does not cancel running tasks in the correct fashion
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Thu Jun 10 03:28:50 2021
From: report at bugs.python.org (Thomas Schweikle)
Date: Thu, 10 Jun 2021 07:28:50 +0000
Subject: [New-bugs-announce] [issue44372] Can't install Python3.8, 3.9,
 3.10 various errors including 0x80070643
Message-ID: <1623310130.37.0.4237956149.issue44372@roundup.psfhosted.org>


New submission from Thomas Schweikle <tschweikle at gmail.com>:

Python Setup for python-3.8.10-amd64.exe, python-3.9.5-amd64.exe, python10.0b2-amd64.exe fails after exausting "No Python 3.8 installation was detected.", then again "No Python 3.8 installation was detected." next it tells about "Error 0x80070643 while installing".

Non of the workarounds you'll able to find will work.

Looking into the registry you'll find various entries like:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\0255A3B1CB3E0445EBD928E5D9ABECFD]
"8400E080C358BF9469DE03ED7FBAE643"="C:\\Program Files\\Python\\38\\Lib\\lib2to3\\fixes\\fix_funcattrs.py"

I could find ~300 entries for Python 3.8, ~400 entries for Python 3.9 and ~1000 entries for Python 3.10.

I've installed into a new windows 10, then removed Python 3.8 looked into the registry and found -- nothing. Tried the same, but this time installed Python 3.8 and Python 3.9 in parallel before removing Python 3.8 and then Python 3.9. Again nothing. Next try: installed Python 3.8.9, then Python 3.9.0. Next upgraded Python 3.8.9 to 3.8.10. Then upgraded Python 3.9.0 to 3.9.5. Then removed Python 3.8.10 and Python 3.9.5. Voila! Lots of entries!

Conclusion: the installer does what it is expected to do, as long as you install and then remove the same version. As soon, as you upgraded in between, then remove it will leave various entries in the registry behind and reinstalling will fail with error 0x80070643.

Your installer has to do its work different: do not upgrade an existing installation "in line", but backup necessary parts, then remove the existing installation, clean up registry, then install the new version, restore what you backed up before.
Seems the installer looses track of these registry entries if upgrades are done inline and later on these existing entries make reinstalling/upgrading impossible.

----------
components: Installation
messages: 395510
nosy: tps800
priority: normal
severity: normal
status: open
title: Can't install Python3.8, 3.9, 3.10 various errors including 0x80070643
type: crash
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Jun 10 03:34:22 2021
From: report at bugs.python.org (Kaleb Barrett)
Date: Thu, 10 Jun 2021 07:34:22 +0000
Subject: [New-bugs-announce] [issue44373] make Event and Awaitable
Message-ID: <1623310462.97.0.487595968193.issue44373@roundup.psfhosted.org>


New submission from Kaleb Barrett <dev.ktbarrett at gmail.com>:

Following on from https://bugs.python.org/issue33544. I don't agree with the original suggestion to deprecate the wait() method on Events, but I do agree that Event should be made Awaitable. Doing so would make code more expressive, but more importantly improve the ability to use Events with generic code that can already handles the other Awaitable types in asyncio.

There were generally neutral takes on providing both __await__ and wait, besides Yury Selivanov who implied it was complex (???). I just tried the below, but maybe I'm missing something?


class AwaitableEvent(Awaitable[None], Event):

    def __await__(self) -> None:
        yield from self.wait().__await__()

    __iter__ = __await__

----------
components: asyncio
messages: 395511
nosy: asvetlov, ktbarrett, yselivanov
priority: normal
severity: normal
status: open
title: make Event and Awaitable
versions: Python 3.10

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

From report at bugs.python.org  Thu Jun 10 06:14:52 2021
From: report at bugs.python.org (junyixie)
Date: Thu, 10 Jun 2021 10:14:52 +0000
Subject: [New-bugs-announce] [issue44374] PyThreadState_IsCurrent bug under
 building Python with --with-experimental-isolated-subinterpreters
Message-ID: <1623320092.73.0.0769901058138.issue44374@roundup.psfhosted.org>


New submission from junyixie <xie.junyi at outlook.com>:

under building Python with --with-experimental-isolated-subinterpreters
PyThreadState_IsCurrent use _PyRuntime.gilstate. is shared by multi sub interpreters.
Use interpreter `gil->last_holder == state` can fix it? 



```
static int
PyThreadState_IsCurrent(PyThreadState *tstate)
{
    /* Must be the tstate for this thread */
    struct _gilstate_runtime_state *gilstate = &_PyRuntime.gilstate;
    assert(_PyGILState_GetThisThreadState(gilstate) == tstate);
    return tstate == _PyRuntimeGILState_GetThreadState(gilstate);
}
```


```
static int
PyThreadState_IsCurrent(PyThreadState *tstate)
{
#ifdef EXPERIMENTAL_ISOLATED_SUBINTERPRETERS
    PyInterpreterState *interp = tstate->interp;
    struct _ceval_state *ceval2 = &interp->ceval;
    struct _gil_runtime_state *gil = &ceval2->gil;
    return tstate == (PyThreadState*)_Py_atomic_load_relaxed(&gil->last_holder);
#else
    /* Must be the tstate for this thread */
    struct _gilstate_runtime_state *gilstate = &_PyRuntime.gilstate;
    assert(_PyGILState_GetThisThreadState(gilstate) == tstate);
    return tstate == _PyRuntimeGILState_GetThreadState(gilstate);
#endif
}
```

----------
components: Subinterpreters
messages: 395517
nosy: JunyiXie, vstinner
priority: normal
severity: normal
status: open
title: PyThreadState_IsCurrent bug under building Python with --with-experimental-isolated-subinterpreters
versions: Python 3.11

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

From report at bugs.python.org  Thu Jun 10 07:29:34 2021
From: report at bugs.python.org (Neethu)
Date: Thu, 10 Jun 2021 11:29:34 +0000
Subject: [New-bugs-announce] [issue44375] urllib.parse.urlparse is not
 parsing the url properly
Message-ID: <1623324574.38.0.821681616785.issue44375@roundup.psfhosted.org>


New submission from Neethu <narayanan.neethu at gmail.com>:

urllib.parse.urlparse is not parsing urls without scheme and with port number properly.

from urllib.parse import urlparse
print(urlparse("www.cwi.nl:80"))

ParseResult(scheme='www.cwi.nl', netloc='', path='80', params='', query='', fragment='')

Python version : 3.9.5

----------
messages: 395518
nosy: neethun
priority: normal
severity: normal
status: open
title: urllib.parse.urlparse is not parsing the url properly
versions: Python 3.9

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

From report at bugs.python.org  Thu Jun 10 08:12:15 2021
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 10 Jun 2021 12:12:15 +0000
Subject: [New-bugs-announce] [issue44376] Improve performance of integer
 exponentiation
Message-ID: <1623327135.25.0.232758885401.issue44376@roundup.psfhosted.org>


New submission from Steven D'Aprano <steve+python at pearwood.info>:

Naively, I assumed that `x**2` would be faster than `x*x` as there is only one name lookup in the first, and two in the second. But it is slower.

The performance of `x**2` relative to `x*x` has gradually deteriorated compared to `x*x` over many versions.

I have found the ratio of `x**2` to `x*x` using timeit:

    pythonX.Y -m timeit -s "x=115" "x**2"
    pythonX.Y -m timeit -s "x=115" "x*x"

for various X.Y:

2.4: 1.1  # ratio of time for x**2 / time for x*x
2.5: 1.5
2.6: 1.0
2.7: 1.6
3.2: 4.2
3.3: 4.2
3.5: 3.8
3.7: 5.9
3.9: 7.3


In the 2.x series, performance was quite close. In 3.x, the ratio has increased significantly. Either integer multiplication has gotten much faster, or exponentiation much slower, or both.

Shockingly (to me at least), an exponent of 1 is an order of magnitude slower than an multiplicand of 1:

2.7: 1.3  # ratio of time for x**1 / time for x*1
3.9: 10.2


Even an exponent of 10 is a little slower than repeated multiplication in 3.9:

`x*x*x*x*x*x*x*x*x*x` is slightly faster than `x**10`.


It would be nice if we could improve the performance of exponentiation.


(OS: Linux)

----------
components: Interpreter Core
messages: 395527
nosy: steven.daprano
priority: normal
severity: normal
status: open
title: Improve performance of integer exponentiation
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Thu Jun 10 08:27:15 2021
From: report at bugs.python.org (Prasanth Rajendran)
Date: Thu, 10 Jun 2021 12:27:15 +0000
Subject: [New-bugs-announce] [issue44377] Truncated error message of
 original function while multiprocessing or multithreading
Message-ID: <1623328035.9.0.197827548789.issue44377@roundup.psfhosted.org>


New submission from Prasanth Rajendran <mrshanth at gmail.com>:

Under multiprocessing package, in pool.py, when an error occurs on line 122:
result = (True, func(*args, **kwds))

The exception "e" has the error message due to execution of the function that is executed in parallel. 

However, the error message is lost when another error is occurred due to the execution of following line 128:
put((job, i, result))

The MaybeEncodingError masks or truncates the original error message, due to the following line at 130:
MaybeEncodingError(e, result[1])

where the repr function in the class truncates the message. 

The final error message has pickling error and the masked error of the actual execution.

----------
components: Library (Lib)
messages: 395529
nosy: mrshanth
priority: normal
severity: normal
status: open
title: Truncated error message of original function while multiprocessing or multithreading
versions: Python 3.7

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

From report at bugs.python.org  Thu Jun 10 09:19:54 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jun 2021 13:19:54 +0000
Subject: [New-bugs-announce] =?utf-8?b?W2lzc3VlNDQzNzhdIFB5X0lTX1RZUEUo?=
 =?utf-8?q?=29=3A_cast_discards_=E2=80=98const=E2=80=99_qualifier_from_poi?=
 =?utf-8?q?nter_target_type?=
Message-ID: <1623331194.1.0.529436211827.issue44378@roundup.psfhosted.org>


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

The following change introduced a compiler warning:

commit c5cb077ab3c88394b7ac8ed4e746bd31b53e39f1
Author: Victor Stinner <vstinner at python.org>
Date:   Tue Sep 22 12:42:28 2020 +0200

    Py_IS_TYPE() macro uses Py_TYPE() (GH-22341)

Steps to Reproduce:

1. dnf install -y python3-devel pkgconf-pkg-config gcc
2. printf '#include <Python.h>' > test.c
3. gcc -Wcast-qual -Werror -c test.c `pkg-config --cflags --libs python-3.10`

Actual results:
sh-5.1# gcc -Wcast-qual -Werror -c test.c `pkg-config --cflags --libs python-3.10`
In file included from /usr/include/python3.10/Python.h:78,
                 from test.c:1:
/usr/include/python3.10/object.h: In function ?_Py_IS_TYPE?:
/usr/include/python3.10/object.h:112:29: error: cast discards ?const? qualifier from pointer target type [-Werror=cast-qual]
  112 | #define _PyObject_CAST(op) ((PyObject*)(op))
      |                             ^
/usr/include/python3.10/object.h:137:34: note: in expansion of macro ?_PyObject_CAST?
  137 | #define Py_TYPE(ob)             (_PyObject_CAST(ob)->ob_type)
      |                                  ^~~~~~~~~~~~~~
/usr/include/python3.10/object.h:144:12: note: in expansion of macro ?Py_TYPE?
  144 |     return Py_TYPE(ob) == type;
      |            ^~~~~~~
cc1: all warnings being treated as errors


Attached PR fix the compiler warning.


Issue reported on Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1969663

----------
components: C API
messages: 395534
nosy: vstinner
priority: normal
severity: normal
status: open
title: Py_IS_TYPE(): cast discards ?const? qualifier from pointer target type
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Thu Jun 10 11:31:07 2021
From: report at bugs.python.org (Violet Godfrey)
Date: Thu, 10 Jun 2021 15:31:07 +0000
Subject: [New-bugs-announce] [issue44379] Pickling recursion error,
 did not import pickle
Message-ID: <1623339067.02.0.0636537811776.issue44379@roundup.psfhosted.org>


New submission from Violet Godfrey <violet.a.godfrey at gmail.com>:

I accidentally created an infinite recursion. The error referenced pickling but I did not import pickle. 

To reproduce: 
def permute(inputList):
    '''permute(inputList) -> list
    returns list of all permutations of inputList
    CURRENTLY DOESN'T ACTUALLLY WORK PROPERLY'''
    for i in range(len(inputList)-1):
        tempList = inputList[:-i-2]
        tempList.append(inputList[-1])
        for num in inputList[-i-2:-1]:
            tempList.append(num)
        print(tempList)
        permute(tempList)  # runs infinitely (whoops)
    print()

permute([1,2,3,4])

Error thrown: 
Traceback (most recent call last):
  File "C:\Users\Violet\Documents\Python Files\test.py", line 14, in <module>
    permute([1,2,3,4])
  File "C:\Users\Violet\Documents\Python Files\test.py", line 11, in permute
    permute(tempList)  # runs infinitely (whoops)
  File "C:\Users\Violet\Documents\Python Files\test.py", line 11, in permute
    permute(tempList)  # runs infinitely (whoops)
  File "C:\Users\Violet\Documents\Python Files\test.py", line 11, in permute
    permute(tempList)  # runs infinitely (whoops)
  [Previous line repeated 1009 more times]
  File "C:\Users\Violet\Documents\Python Files\test.py", line 10, in permute
    print(tempList)
RecursionError: maximum recursion depth exceeded while pickling an object

----------
assignee: terry.reedy
components: IDLE
messages: 395542
nosy: Octopi, terry.reedy
priority: normal
severity: normal
status: open
title: Pickling recursion error, did not import pickle
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Thu Jun 10 11:53:43 2021
From: report at bugs.python.org (Maxim Egorushkin)
Date: Thu, 10 Jun 2021 15:53:43 +0000
Subject: [New-bugs-announce] [issue44380] glob.glob handling of * (asterisk)
 wildcard is broken
Message-ID: <1623340423.37.0.118155398047.issue44380@roundup.psfhosted.org>


New submission from Maxim Egorushkin <maxim.yegorushkin at gmail.com>:

Problem:

`glob.glob` documentation states that "pathname ... can contain shell-style wildcards." 

However, it stops short of saying that shell-style wildcards are handled the same way as in a POSIX-compliant/friendly shell.

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13_02 POSIX requires that "`*` (asterisk) is a pattern that shall match any string, including the null string."

However, `glob.glob` pattern `*` (asterisk) doesn't match an empty/null string. 

Reproduction:

$ ls *.bash_profile
.bash_profile
$ python3 -c 'import glob; print(glob.glob("*.bash_profile"))'
[]
$ python3 -c 'import glob; print(glob.glob(".bash_profile"))'
['.bash_profile']

----------
components: Library (Lib)
messages: 395545
nosy: max0x7ba
priority: normal
severity: normal
status: open
title: glob.glob handling of * (asterisk) wildcard is broken
versions: Python 3.8

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

From report at bugs.python.org  Thu Jun 10 13:07:15 2021
From: report at bugs.python.org (Steve Dower)
Date: Thu, 10 Jun 2021 17:07:15 +0000
Subject: [New-bugs-announce] [issue44381] Allow enabling control flow guard
 in Windows build
Message-ID: <1623344835.21.0.813448023937.issue44381@roundup.psfhosted.org>


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

Currently we don't enable CFG (which is runtime protection against code injection into tables), because it likely has a performance impact and the kind of attack is outside our scope.

However, we should make it easier to build CPython with CFG enabled, so that third-parties who do want to include it in their scope can do so.

----------
assignee: steve.dower
components: Build, Windows
messages: 395556
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Allow enabling control flow guard in Windows build
type: security
versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Jun 10 13:53:53 2021
From: report at bugs.python.org (Hypo Turtle)
Date: Thu, 10 Jun 2021 17:53:53 +0000
Subject: [New-bugs-announce] [issue44382] Python 3.9+ on Windows 8.0
Message-ID: <1623347633.5.0.426865894131.issue44382@roundup.psfhosted.org>


New submission from Hypo Turtle <hypoturtle at gmail.com>:

As per https://docs.python.org/3/using/windows.html:
"This means that Python 3.9 supports Windows 8.1 and newer."

Isn't reflected on python.org main page which has:
"Note that Python 3.9+ cannot be used on Windows 7 or earlier."

Leaving 8.0 unaddressed.

----------
assignee: docs at python
components: Documentation
messages: 395558
nosy: docs at python, hypoturtle
priority: normal
severity: normal
status: open
title: Python 3.9+ on Windows 8.0
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Thu Jun 10 14:07:47 2021
From: report at bugs.python.org (Julian Gilbey)
Date: Thu, 10 Jun 2021 18:07:47 +0000
Subject: [New-bugs-announce] [issue44383] argparse.BooleanOptionalAction
 interacts poorly with ArgumentDefaultsHelpFormatter
Message-ID: <1623348467.33.0.718434111549.issue44383@roundup.psfhosted.org>


New submission from Julian Gilbey <julian-python at d-and-j.net>:

With code like the following:

~~~~

import argparse

parser = argparse.ArgumentParser(
    description="Test program",
    formatter_class=argparse.ArgumentDefaultsHelpFormatter,
)
parser.add_argument(
    "--foo",
    help="Use the foo component.",
    action=argparse.BooleanOptionalAction,
    default=True,
)

args = parser.parse_args()

~~~~

a call "python prog.py --help" then gives:

~~~~
usage: prog.py [-h] [--foo | --no-foo]

Test program

optional arguments:
  -h, --help       show this help message and exit
  --foo, --no-foo  Use the foo component. (default: True) (default: True)
~~~~

Note the repeated "(default: True)", one produced by the BooleanOptionalAction class and the other by the ArgumentDefaultsHelpFormatter.  It would be good if they didn't both add this helpful information.

My suggestion would be that BooleanOptionalAction should not include this information; it is unique in doing so.

----------
components: Library (Lib)
messages: 395559
nosy: juliangilbey
priority: normal
severity: normal
status: open
title: argparse.BooleanOptionalAction interacts poorly with ArgumentDefaultsHelpFormatter
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Thu Jun 10 16:15:13 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 10 Jun 2021 20:15:13 +0000
Subject: [New-bugs-announce] [issue44384] test_ttk_guionly: 2 tests fail
 once each on Pipelines Ubuntu
Message-ID: <1623356113.96.0.920783829552.issue44384@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

3.10 Pipelines Ubuntu CI (like #42370) Each passed on 3.11 and 3.9 and all other CI tests and my machine.

FIRST RUN - FAIL: test_heading_callback 
(tkinter.test.test_ttk.test_widgets.TreeviewTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/vsts/work/1/s/Lib/tkinter/test/test_ttk/test_widgets.py", line 1548, in test_heading_callback
    simulate_heading_click(5, 5)
  File "/home/vsts/work/1/s/Lib/tkinter/test/test_ttk/test_widgets.py", line 1536, in simulate_heading_click
    self.assertEqual(self.tv.identify_region(x, y), 'heading')
AssertionError: 'nothing' != 'heading'
- nothing
+ heading


RETEST RUN - FAIL: test_variable_change (tkinter.test.test_ttk.test_extensions.LabeledScaleTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/vsts/work/1/s/Lib/tkinter/test/test_ttk/test_extensions.py", line 144, in test_variable_change
    self.assertGreater(x.scale.coords()[0], curr_xcoord)
AssertionError: 1 not greater than 1

----------
components: Tests, Tkinter
messages: 395567
nosy: serhiy.storchaka, terry.reedy, vstinner
priority: normal
severity: normal
stage: needs patch
status: open
title: test_ttk_guionly: 2 tests fail once each on Pipelines Ubuntu
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Thu Jun 10 17:42:26 2021
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Thu, 10 Jun 2021 21:42:26 +0000
Subject: [New-bugs-announce] [issue44385] Some target-related rules are
 unreachable in the grammar
Message-ID: <1623361346.78.0.306429671294.issue44385@roundup.psfhosted.org>


New submission from Lysandros Nikolaou <lisandrosnik at gmail.com>:

Three rules (targets, target and t_atom) in the grammar are unreachable. We were using them at some point in the past, but we never removed them when we replaced them with other rules.

----------
assignee: lys.nikolaou
components: Parser
messages: 395577
nosy: gvanrossum, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Some target-related rules are unreachable in the grammar
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Thu Jun 10 18:45:59 2021
From: report at bugs.python.org (Paul Prescod)
Date: Thu, 10 Jun 2021 22:45:59 +0000
Subject: [New-bugs-announce] [issue44386] importlib and math.pi interact
 strangely
Message-ID: <1623365159.13.0.132987664597.issue44386@roundup.psfhosted.org>


New submission from Paul Prescod <prescod at gmail.com>:

from importlib import util

mathmodule = util.find_spec("math")
math1 = util.module_from_spec(mathmodule)
print(math1.pi)

=====

$ python3.8 /tmp/foo.py 
3.141592653589793

$ python3.9 /tmp/foo.py 
Traceback (most recent call last):
  File "/tmp/foo.py", line 5, in <module>
    print(math1.pi)
AttributeError: module 'math' has no attribute 'pi'

----------
components: Extension Modules
files: foo.py
messages: 395583
nosy: prescod2
priority: normal
severity: normal
status: open
title: importlib and math.pi interact strangely
versions: Python 3.10, Python 3.11
Added file: https://bugs.python.org/file50101/foo.py

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

From report at bugs.python.org  Thu Jun 10 19:27:24 2021
From: report at bugs.python.org (Richard Mines)
Date: Thu, 10 Jun 2021 23:27:24 +0000
Subject: [New-bugs-announce] [issue44387] Not obvious that
 locale.LC_MESSAGES may not exist sometimes (e.g. on Windows)
Message-ID: <1623367644.12.0.511636948809.issue44387@roundup.psfhosted.org>


New submission from Richard Mines <richardmines91 at gmail.com>:

Documentation page:
https://docs.python.org/3/library/locale.html#locale.LC_MESSAGES

Code comment saying that locale.LC_MESSAGES doesn't exist sometimes:
https://github.com/python/cpython/blob/62f1d2b3d7dda99598d053e10b785c463fdcf591/Lib/locale.py#L25-L26

Code fragment showing that locale.LC_MESSAGES can be non-existent:
https://github.com/python/cpython/blob/62f1d2b3d7dda99598d053e10b785c463fdcf591/Lib/locale.py#L1747-L1752

Reading documentation it's not obvious that locale.LC_MESSAGES may not exist (e.g. Windows - Microsoft Store - Python 3.8)

----------
assignee: docs at python
components: Documentation
messages: 395588
nosy: docs at python, richardmines91
priority: normal
severity: normal
status: open
title: Not obvious that locale.LC_MESSAGES may not exist sometimes (e.g. on Windows)
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/issue44387>
_______________________________________

From report at bugs.python.org  Fri Jun 11 01:00:48 2021
From: report at bugs.python.org (Matthew Clapp)
Date: Fri, 11 Jun 2021 05:00:48 +0000
Subject: [New-bugs-announce] [issue44388] venv API Docs for
 EnvBuilder.ensure_directories incorrectly describe behavior
Message-ID: <1623387648.1.0.29600166507.issue44388@roundup.psfhosted.org>


New submission from Matthew Clapp <itsayellow+dev at gmail.com>:

The docs for the venv module, EnvBuilder class, ensure_directories method, describe behavior that doesn't match what its actual behavior is, (and what the code is).  I propose to update the documentation of the API to match the actual behavior.

https://docs.python.org/3.9/library/venv.html#venv.EnvBuilder.ensure_directories

The last sentence for ensure_directories(env_dir) reads:
The directories are allowed to exist already, as long as either clear or upgrade were specified to allow operating on an existing environment directory.

After testing and looking at the code (including past commits back over 6 years), this is not true.  ensure_directories completely disregards the `upgrade` attribute.  Also it allows directories to exist already unconditionally (always operating without error), whether the `clear` attribute is set or not.  In addition, if `clear` is not set, it doesn't make any changes to the directories, but helpfully still returns the context of venv paths.

Ref: https://github.com/python/cpython/blob/3ce35bfbbe29664942f9a8c50c177a4575a31934/Lib/venv/__init__.py#L95

----------
assignee: docs at python
components: Documentation
messages: 395603
nosy: docs at python, itsayellow
priority: normal
severity: normal
status: open
title: venv API Docs for EnvBuilder.ensure_directories incorrectly describe 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/issue44388>
_______________________________________

From report at bugs.python.org  Fri Jun 11 04:23:58 2021
From: report at bugs.python.org (Brother Beer)
Date: Fri, 11 Jun 2021 08:23:58 +0000
Subject: [New-bugs-announce] [issue44389] Modules/_ssl.c,
 repeated 'SSL_OP_NO_TLSv1_2'
Message-ID: <1623399838.97.0.436743234737.issue44389@roundup.psfhosted.org>


New submission from Brother Beer <brotherbeer at 163.com>:

cpython-3.10.0b2/Modules/_ssl.c  line 3576

3570 static int
3571 set_options(PySSLContext *self, PyObject *arg, void *c)
3572 {
3573     long new_opts, opts, set, clear;
3574     long opt_no = (
3575         SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 | SSL_OP_NO_TLSv1 |
3576         SSL_OP_NO_TLSv1_1 | SSL_OP_NO_TLSv1_2 | SSL_OP_NO_TLSv1_2
3577     );

'SSL_OP_NO_TLSv1_2' is repeated, are any other items missing?

----------
files: _ssl_c_line_3576.png
messages: 395612
nosy: brotherbeer
priority: normal
severity: normal
status: open
title: Modules/_ssl.c, repeated 'SSL_OP_NO_TLSv1_2'
type: behavior
versions: Python 3.10
Added file: https://bugs.python.org/file50103/_ssl_c_line_3576.png

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

From report at bugs.python.org  Fri Jun 11 04:43:42 2021
From: report at bugs.python.org (Brother Beer)
Date: Fri, 11 Jun 2021 08:43:42 +0000
Subject: [New-bugs-announce] [issue44390] PC/frozen_dllmain.c,
 some expressions have no side effects
Message-ID: <1623401022.53.0.60129097271.issue44390@roundup.psfhosted.org>


New submission from Brother Beer <brotherbeer at 163.com>:

cpython-3.10.0b2/PC/frozen_dllmain.c, line 66

 63 void PyWinFreeze_ExeInit(void)
 64 {
 65     char **modName;
 66     for (modName = possibleModules;*modName;*modName++) {
 67 /*              printf("Initialising '%s'\n", *modName); */
 68         CallModuleDllMain(*modName, DLL_PROCESS_ATTACH);
 69     }
 70 }

'*' in '*modName++' is redundant? Line 82 has the same problem

 76 void PyWinFreeze_ExeTerm(void)
 77 {
 78     // Must go backwards
 79     char **modName;
 80     for (modName = possibleModules+Py_ARRAY_LENGTH(possibleModules)-2;
 81          modName >= possibleModules;
 82          *modName--) {
 83 /*              printf("Terminating '%s'\n", *modName);*/
 84         CallModuleDllMain(*modName, DLL_PROCESS_DETACH);
 85     }
 86 }

----------
messages: 395619
nosy: brotherbeer
priority: normal
severity: normal
status: open
title: PC/frozen_dllmain.c, some expressions have no side effects
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Fri Jun 11 04:49:15 2021
From: report at bugs.python.org (Brother Beer)
Date: Fri, 11 Jun 2021 08:49:15 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue44391=5D_PC/launcher=2Ec?=
 =?utf-8?q?=EF=BC=8Cone_more_argument_than_required?=
Message-ID: <1623401355.22.0.20418176372.issue44391@roundup.psfhosted.org>


New submission from Brother Beer <brotherbeer at 163.com>:

cpython-3.10.0b2/PC/launcher.c, line 347

One more argument than required?

 345         else if (attrs & FILE_ATTRIBUTE_DIRECTORY) {
 346             debug(L"locate_pythons_for_key: '%ls' is a directory\n",
 347                   ip->executable, attrs);
 348         }

----------
messages: 395620
nosy: brotherbeer
priority: normal
severity: normal
status: open
title: PC/launcher.c?one more argument than required
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Fri Jun 11 05:18:35 2021
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 11 Jun 2021 09:18:35 +0000
Subject: [New-bugs-announce] [issue44392] Py_GenericAlias is not documented
Message-ID: <1623403115.39.0.360289172902.issue44392@roundup.psfhosted.org>


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

Py_GenericAlias seems to be a public API given its name and is mention in the stable ABI list for 3.10 (https://docs.python.org/3.10/c-api/stable.html?highlight=py_genericalias), but the API is not documented. 

Likewise for Py_GenericAliasType.

----------
assignee: docs at python
components: Documentation
messages: 395625
nosy: docs at python, ronaldoussoren
priority: normal
severity: normal
status: open
title: Py_GenericAlias is not documented
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Fri Jun 11 05:27:01 2021
From: report at bugs.python.org (Alex Hall)
Date: Fri, 11 Jun 2021 09:27:01 +0000
Subject: [New-bugs-announce] [issue44393] segfault with sys.setrecursionlimit
Message-ID: <1623403621.34.0.625867974474.issue44393@roundup.psfhosted.org>


New submission from Alex Hall <bearodark at gmail.com>:

Found on:
Python 3.9.5
GCC 11.1 on Linux (x86_64)
Reproduced on:
Python 3.9.5
Clang 9.0.8 Linux (arm)

When setting the recursion limit to a high enough amount, trying to reach that recursion limit ends in a segmentation fault (stack overflow?)

code:
```py
import sys

def recurse(n: int) -> int:
    recurse(n)

sys.setrecursionlimit(2**16-1)

recurse(1000000)
```

----------
components: Library (Lib)
files: segpy.png
messages: 395626
nosy: ultrabear
priority: normal
severity: normal
status: open
title: segfault with sys.setrecursionlimit
type: crash
versions: Python 3.9
Added file: https://bugs.python.org/file50104/segpy.png

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

From report at bugs.python.org  Fri Jun 11 10:14:07 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jun 2021 14:14:07 +0000
Subject: [New-bugs-announce] [issue44394] [security] CVE-2013-0340 "Billion
 Laughs" fixed in Expat >=2.4.0: Updated to vendoed copy to expat 2.4.1
Message-ID: <1623420847.27.0.469352206791.issue44394@roundup.psfhosted.org>


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

Our vendored copy of Modules/expat/ should be updated to Expat 2.4.1 to retrieve the fix for the security vulnerabily CVE-2013-0340 "Billion Laughs":
https://blog.hartwork.org/posts/cve-2013-0340-billion-laughs-fixed-in-expat-2-4-0/

The table of vulnerabilities in Python XML parsers should be updated as well:
https://docs.python.org/dev/library/xml.html#xml-vulnerabilities

My outdated notes on Modules/expat/: copy of libexpat

* ./configure --with-system-expat
* Rationale: https://mail.python.org/pipermail/python-dev/2017-June/148287.html
* Used on Windows and macOS, Linux distributions use system libexpat
* Version: search for XML_MAJOR_VERSION in Modules/expat/expat.h
* Script to update it: see attached script to https://bugs.python.org/issue30947
* Recent update: https://bugs.python.org/issue30947
* Python 2.7, 3.3-3.6 use libexpat 2.2.1

https://pythondev.readthedocs.io/files.html

----------
components: Extension Modules
messages: 395634
nosy: vstinner
priority: normal
severity: normal
status: open
title: [security] CVE-2013-0340 "Billion Laughs" fixed in Expat >=2.4.0: Updated to vendoed copy to expat 2.4.1
type: security
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/issue44394>
_______________________________________

From report at bugs.python.org  Fri Jun 11 10:15:26 2021
From: report at bugs.python.org (Konstantin Ryabitsev)
Date: Fri, 11 Jun 2021 14:15:26 +0000
Subject: [New-bugs-announce] [issue44395] email.message as_string() not
 writing unixfrom
Message-ID: <1623420926.37.0.619875341642.issue44395@roundup.psfhosted.org>


New submission from Konstantin Ryabitsev <konstantin at linuxfoundation.org>:

When using as_string(unixfrom=True), the "From " line is not always printed. The behaviour is correct for as_bytes().

Test case:

----
import email.message

msg = email.message.EmailMessage()
msg.set_payload('Hello World\n')
msg.set_unixfrom('From foo at bar Thu Jan  1 00:00:00 1970')
msg['Subject'] = 'Hello'
msg['From'] = 'Me <me at foo.bar>'
print('as_string:')
print(msg.as_string(unixfrom=True))
print('as_bytes:')
print(msg.as_bytes(unixfrom=True).decode())
----

Results (3.5 and 3.9):

as_string:
Subject: Hello
From: Me <me at foo.bar>

Hello World

as_bytes:
>From foo at bar Thu Jan  1 00:00:00 1970
Subject: Hello
From: Me <me at foo.bar>

Hello World

----------
components: email
messages: 395635
nosy: barry, konstantin2, r.david.murray
priority: normal
severity: normal
status: open
title: email.message as_string() not writing unixfrom
versions: Python 3.9

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

From report at bugs.python.org  Fri Jun 11 10:39:45 2021
From: report at bugs.python.org (alessandro mantovani)
Date: Fri, 11 Jun 2021 14:39:45 +0000
Subject: [New-bugs-announce] [issue44396] Use-After-Free
Message-ID: <1623422385.05.0.487332987283.issue44396@roundup.psfhosted.org>


New submission from alessandro mantovani <mantovanialessandro1994 at gmail.com>:

Use After Free in python3.11 (commit  2ab27c4af4ddf752)
Steps to reproduce:

1) ./configure --with-address-sanitizer
2) make
3) ./python <input>

I attach some of the input  that lead to the undefined behavior

For the complete description you can find the asan report here:

==1082579==ERROR: AddressSanitizer: heap-use-after-free on address 0x626000045a40 at pc 0x000000735155 bp 0x7fffffffbed0 sp 0x7fffffffbec8
READ of size 8 at 0x626000045a40 thread T0
    #0 0x735154 in ascii_decode /home/elmanto/ddg/other_targets/cpython/Objects/unicodeobject.c:5091:28
    #1 0x735154 in unicode_decode_utf8 /home/elmanto/ddg/other_targets/cpython/Objects/unicodeobject.c:5158:10
    #2 0xc98381 in syntaxerror /home/elmanto/ddg/other_targets/cpython/Parser/tokenizer.c:1087:15
    #3 0xc8d616 in tok_get /home/elmanto/ddg/other_targets/cpython/Parser/tokenizer.c
    #4 0xc8696b in PyTokenizer_Get /home/elmanto/ddg/other_targets/cpython/Parser/tokenizer.c:1884:18
    #5 0xead74c in _PyPegen_check_tokenizer_errors /home/elmanto/ddg/other_targets/cpython/Parser/pegen.c:1260:17
    #6 0xead74c in _PyPegen_run_parser /home/elmanto/ddg/other_targets/cpython/Parser/pegen.c:1292:17
    #7 0xeaebca in _PyPegen_run_parser_from_file_pointer /home/elmanto/ddg/other_targets/cpython/Parser/pegen.c:1377:14
    #8 0xc83a91 in _PyParser_ASTFromFile /home/elmanto/ddg/other_targets/cpython/Parser/peg_api.c:26:12
    #9 0xa0abf1 in pyrun_file /home/elmanto/ddg/other_targets/cpython/Python/pythonrun.c:1197:11
    #10 0xa0abf1 in _PyRun_SimpleFileObject /home/elmanto/ddg/other_targets/cpython/Python/pythonrun.c:455:13
    #11 0xa09b19 in _PyRun_AnyFileObject /home/elmanto/ddg/other_targets/cpython/Python/pythonrun.c:89:15
    #12 0x4dfe94 in pymain_run_file_obj /home/elmanto/ddg/other_targets/cpython/Modules/main.c:353:15
    #13 0x4dfe94 in pymain_run_file /home/elmanto/ddg/other_targets/cpython/Modules/main.c:372:15
    #14 0x4dfe94 in pymain_run_python /home/elmanto/ddg/other_targets/cpython/Modules/main.c:587:21
    #15 0x4dfe94 in Py_RunMain /home/elmanto/ddg/other_targets/cpython/Modules/main.c:666:5
    #16 0x4e154c in pymain_main /home/elmanto/ddg/other_targets/cpython/Modules/main.c:696:12
    #17 0x4e1874 in Py_BytesMain /home/elmanto/ddg/other_targets/cpython/Modules/main.c:720:12
    #18 0x7ffff7a2e0b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
    #19 0x43501d in _start (/home/elmanto/ddg/other_targets/cpython/python+0x43501d)

0x626000045a40 is located 2368 bytes inside of 10560-byte region [0x626000045100,0x626000047a40)
freed by thread T0 here:
    #0 0x4ada79 in realloc (/home/elmanto/ddg/other_targets/cpython/python+0x4ada79)
    #1 0x638e61 in PyMem_RawRealloc /home/elmanto/ddg/other_targets/cpython/Objects/obmalloc.c:602:12
    #2 0x638e61 in _PyObject_Realloc /home/elmanto/ddg/other_targets/cpython/Objects/obmalloc.c:2339:12

previously allocated by thread T0 here:
    #0 0x4ada79 in realloc (/home/elmanto/ddg/other_targets/cpython/python+0x4ada79)
    #1 0x638e61 in PyMem_RawRealloc /home/elmanto/ddg/other_targets/cpython/Objects/obmalloc.c:602:12
    #2 0x638e61 in _PyObject_Realloc /home/elmanto/ddg/other_targets/cpython/Objects/obmalloc.c:2339:12

SUMMARY: AddressSanitizer: heap-use-after-free /home/elmanto/ddg/other_targets/cpython/Objects/unicodeobject.c:5091:28 in ascii_decode
Shadow bytes around the buggy address:
  0x0c4c80000af0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c4c80000b00: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c4c80000b10: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c4c80000b20: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c4c80000b30: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
=>0x0c4c80000b40: fd fd fd fd fd fd fd fd[fd]fd fd fd fd fd fd fd
  0x0c4c80000b50: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c4c80000b60: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c4c80000b70: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c4c80000b80: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c4c80000b90: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==1082579==ABORTING

----------
components: C API
files: crashes.tgz
messages: 395637
nosy: elmanto
priority: normal
severity: normal
status: open
title: Use-After-Free
type: security
versions: Python 3.11
Added file: https://bugs.python.org/file50105/crashes.tgz

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

From report at bugs.python.org  Fri Jun 11 11:18:53 2021
From: report at bugs.python.org (Ajith Ramachandran)
Date: Fri, 11 Jun 2021 15:18:53 +0000
Subject: [New-bugs-announce] [issue44397] Add Linked Linked module
Message-ID: <1623424733.17.0.137913731614.issue44397@roundup.psfhosted.org>


New submission from Ajith Ramachandran <ajithar204 at gmail.com>:

There is a module present for queue which can also be used for a stack like LIFO structure. But there is none for linked list.

----------
components: Library (Lib)
messages: 395640
nosy: AjithRamachandran
priority: normal
severity: normal
status: open
title: Add Linked Linked module
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Fri Jun 11 15:36:14 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 11 Jun 2021 19:36:14 +0000
Subject: [New-bugs-announce] [issue44398] IDLE: On macOS,
 cntl-space/backslash display as ^S/^B
Message-ID: <1623440174.98.0.65068433782.issue44398@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

(Related to the more general macOS hotkey issue 18444.)
'Edit => Show completions' invokes pseudoevent <<force-open-completions>>.  In all built-in keysets, the latter is bound to Control-space.  This includes on macOS, as can be seen on the Settings Keys tab.

On Windows, and I presume *nix, this is displayed on the menu as 'Cntl+space'.  On macOS, the menu hotkeys are displayed differently than on other systems (how?).  'Cntl+' is condensed to '^', which is fine and which would be okay elsewhere.  However, 'space' is condensed to 'S', which is a bug.  Can this be fixed?  If not, we could add ^S as an alternate hotkey on macOS.

'^S' causes 'Edit' to flash, indicating, I believe, that it is recognized as an Edit menu hotkey.  But nothing happens as IDLE/tk does not recognize it on macOS.  (On Windows, it means 'save'.)

^space, currently works to show completions with 3.10.0b2.  The same will be true after the PR for #40128 is merged and backported.

The situation is the same for Edit => Show calltip, <<force-open-calltip>>, and control-backslash, except that 'backslash' is visible as '\'.  If the hotkey were displayed on Windows as 'Cntl+\', perhaps the result on macOS would be the correct '^\'.

----------
assignee: terry.reedy
components: IDLE, macOS
messages: 395656
nosy: ned.deily, ronaldoussoren, taleinat, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE: On macOS, cntl-space/backslash display as ^S/^B
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Fri Jun 11 15:50:16 2021
From: report at bugs.python.org (mori-b)
Date: Fri, 11 Jun 2021 19:50:16 +0000
Subject: [New-bugs-announce] [issue44399] log rotator cookbook example might
 waste disk space
Message-ID: <1623441016.81.0.46745114.issue44399@roundup.psfhosted.org>


New submission from mori-b <moribirom at gmail.com>:

In https://docs.python.org/3/howto/logging-cookbook.html#using-a-rotator-and-namer-to-customize-log-rotation-processing, the log rotator example deletes the original log file after compressing it. However, running on Linux the command "lsof +S1" shows that the deleted original log file might still hold the same disk space, and keep growing.
Replacing the command "os.remove(source)" with "os.truncate(source,0)" seems to solve the issue by freeing the original log file disk space at each rotation.

----------
assignee: docs at python
components: Documentation
messages: 395658
nosy: docs at python, mori-b
priority: normal
severity: normal
status: open
title: log rotator cookbook example might waste disk space
type: resource usage

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

From report at bugs.python.org  Fri Jun 11 20:33:48 2021
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 12 Jun 2021 00:33:48 +0000
Subject: [New-bugs-announce] [issue44400] Propose random.randbool()
Message-ID: <1623458028.32.0.0235692226246.issue44400@roundup.psfhosted.org>


New submission from Dong-hee Na <donghee.na at python.org>:

I noticed that the random library does not provide `random.randbool()`.
Generating bool value is quite common in the use-case when we generated faked data
(unittest, machine learning training, etc)

Somebody can say write your own library but it's too common use-case and in physically some isolated environments is hard to use 3rd party library.

Since the bool value is the built-in type of python, I think that is very useful when we provide this function.

I would like to get opinions from Raymond and then proceed with this issue.

Here is the candidate implementation:

def randbool():
    return bool(getrandbits(1))

----------
components: Library (Lib)
messages: 395671
nosy: corona10, rhettinger
priority: normal
severity: normal
status: open
title: Propose random.randbool()
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Fri Jun 11 21:21:56 2021
From: report at bugs.python.org (Richard Barnes)
Date: Sat, 12 Jun 2021 01:21:56 +0000
Subject: [New-bugs-announce] [issue44401] const kwlist for
 PyArg_ParseTupleAndKeywords and PyArg_VaParseTupleAndKeywords
Message-ID: <1623460916.5.0.468559041794.issue44401@roundup.psfhosted.org>


New submission from Richard Barnes <rbarnes at umn.edu>:

PyArg_ParseTupleAndKeywords and PyArg_VaParseTupleAndKeywords currently accept `kwlist` as `char **`; however, is not modified by either function. Therefore, a `const char **` might be better since this allows calling code to take advantage of `const` safety.

----------
components: C API
messages: 395674
nosy: r-barnes
priority: normal
severity: normal
status: open
title: const kwlist for PyArg_ParseTupleAndKeywords and PyArg_VaParseTupleAndKeywords
type: security

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

From report at bugs.python.org  Sat Jun 12 01:40:12 2021
From: report at bugs.python.org (Samuel Marks)
Date: Sat, 12 Jun 2021 05:40:12 +0000
Subject: [New-bugs-announce] [issue44402] Python 3.9 and 3.10 fails to
 install in WINE
Message-ID: <1623476412.99.0.399943466578.issue44402@roundup.psfhosted.org>


New submission from Samuel Marks <samuelmarks at gmail.com>:

What works:
- python-3.7.9.exe  python-3.8.9.exe

What fails:
- python-3.10.0b2.exe  python-3.9.5.exe

(I'm debugging some regressions on my test suite? macOS and Linux [incl. in Docker] work, Windows fails)

How to reproduce (macOS):
0. Install WINE (crossover) https://github.com/Gcenx/homebrew-wine#how-to-install-using-brew
1. wine python-<version>.exe /quiet /passive /log c:/p.log TargetDir=C:/python-<version> InstallAllUsers=1 Include_doc=0 Include_debug=0 Include_dev=0 Include_exe=1 Include_launcher=0 Include_lib=1 Include_pip=1 Include_symbols=0 Include_tcltk=0 Include_test=0 Include_tools=0
2. curl https://bootstrap.pypa.io/get-pip.py -o http://get-pip.py
3. wine "C:\\python-<version>\\python.exe" http://get-pip.py

(replacing `<version>`; obviously)

Error:
```
000b:fixme:thread:create_user_shared_data_thread Creating user shared data update thread.
000d:fixme:thread:create_user_shared_data_thread Creating user shared data update thread.
0010:fixme:thread:create_user_shared_data_thread Creating user shared data update thread.
0017:fixme:thread:create_user_shared_data_thread Creating user shared data update thread.
001d:err:plugplay:process_IOService_Device object 0x9203
001d:err:plugplay:process_IOService_Device Unable to create plug in interface for USB deviceobject 0x9207
001f:fixme:thread:create_user_shared_data_thread Creating user shared data update thread.
0009:fixme:heap:RtlSetHeapInformation 0x0 1 0x0 0 stub
0025:fixme:thread:create_user_shared_data_thread Creating user shared data update thread.
0009:fixme:ntdll:NtQueryInformationToken QueryInformationToken( ..., TokenElevation, ...) semi-stub
0009:fixme:ntdll:NtQueryInformationToken QueryInformationToken( ..., TokenElevation, ...) semi-stub
0009:fixme:advapi:DecryptFileW (L"C:\\windows\\Temp\\{FDB2F91C-29EE-4A75-AAA5-39F402CF12ED}\\", 00000000): stub
002b:fixme:heap:RtlSetHeapInformation 0x0 1 0x0 0 stub
002b:fixme:ntdll:NtQueryInformationToken QueryInformationToken( ..., TokenElevation, ...) semi-stub
002b:fixme:ntdll:NtQueryInformationToken QueryInformationToken( ..., TokenElevation, ...) semi-stub
002b:fixme:advapi:DecryptFileW (L"C:\\windows\\Temp\\{3F224591-5EEC-4431-8291-2450B9ECC110}\\", 00000000): stub
002e:fixme:shell:SHAutoComplete stub
002b:fixme:ver:GetCurrentPackageId (0x31fd04 0x0): stub
0009:fixme:ver:GetCurrentPackageId (0x31fd04 0x0): stub
```

Expected (`uniq` output of a successful install of 3.8):
```
000b:fixme:thread:create_user_shared_data_thread Creating user shared data update thread.
000d:fixme:thread:create_user_shared_data_thread Creating user shared data update thread.
0010:fixme:thread:create_user_shared_data_thread Creating user shared data update thread.
0017:fixme:thread:create_user_shared_data_thread Creating user shared data update thread.
001d:err:plugplay:process_IOService_Device object 0x6a03
001d:err:plugplay:process_IOService_Device Unable to create plug in interface for USB deviceobject 0x6a07
001f:fixme:thread:create_user_shared_data_thread Creating user shared data update thread.
0009:fixme:heap:RtlSetHeapInformation 0x0 1 0x0 0 stub
0025:fixme:thread:create_user_shared_data_thread Creating user shared data update thread.
0009:fixme:ntdll:NtQueryInformationToken QueryInformationToken( ..., TokenElevation, ...) semi-stub
0009:fixme:advapi:DecryptFileW (L"C:\\windows\\Temp\\{86717C64-3933-4B4D-9283-CEA5CD0F5EBB}\\", 00000000): stub
002b:fixme:heap:RtlSetHeapInformation 0x0 1 0x0 0 stub
002b:fixme:ntdll:NtQueryInformationToken QueryInformationToken( ..., TokenElevation, ...) semi-stub
002b:fixme:advapi:DecryptFileW (L"C:\\windows\\Temp\\{9A024DD0-BF6A-4DF1-A034-C61E89E6F711}\\", 00000000): stub
002e:fixme:shell:SHAutoComplete stub
002b:fixme:advapi:DecryptFileW (L"C:\\windows\\Temp\\{9A024DD0-BF6A-4DF1-A034-C61E89E6F711}\\", 00000000): stub
002b:fixme:exec:SHELL_execute flags ignored: 0x00000100
0030:fixme:heap:RtlSetHeapInformation 0x0 1 0x0 0 stub
0030:fixme:ntdll:NtQueryInformationToken QueryInformationToken( ..., TokenElevation, ...) semi-stub
0030:fixme:ole:CoInitializeSecurity (0031F458,-1,00000000,00000000,6,2,00000000,12288,00000000) - stub!
0030:fixme:wuapi:automatic_updates_Pause 
0030:fixme:sfc:SRSetRestorePointW 0031F320 0031F530
0033:fixme:advapi:DecryptFileW (L"C:\\ProgramData\\Package Cache\\{3854F8D0-6FA6-4227-8047-8DE95B0A7DE7}v3.8.9150.0\\core.msi", 00000000): stub
0030:fixme:ntdll:NtLockFile I/O completion on lock not implemented yet
0033:fixme:advapi:DecryptFileW (L"C:\\ProgramData\\Package Cache\\{A3ED59F7-FC59-4793-AEBC-9D3813922BE1}v3.8.9150.0\\exe.msi", 00000000): stub
0030:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_PERFORMANCE_INFORMATION
0030:err:mscoree:LoadLibraryShim error reading registry key for installroot
0033:fixme:advapi:DecryptFileW (L"C:\\ProgramData\\Package Cache\\{D12B4386-129A-4C17-AB8D-45FD90C6EB0D}v3.8.9150.0\\lib.msi", 00000000): stub
0033:fixme:advapi:DecryptFileW (L"C:\\ProgramData\\Package Cache\\{D9AC2AA4-3635-4476-BDC0-CC9B7992815D}v3.8.9150.0\\pip.msi", 00000000): stub
0030:err:mscoree:LoadLibraryShim error reading registry key for installroot
0037:fixme:thread:create_user_shared_data_thread Creating user shared data update thread.
0030:err:mscoree:LoadLibraryShim error reading registry key for installroot
0041:fixme:msvcrt:_configure_wide_argv (1) stub
0041:fixme:msvcrt:_initialize_wide_environment stub
0041:fixme:msvcrt:__stdio_common_vsprintf options 25 not handled
0041:fixme:ntdll:server_get_file_info Unsupported info class e
0041:fixme:msvcrt:__stdio_common_vsprintf options 25 not handled
0030:fixme:wuapi:automatic_updates_Resume 
0030:fixme:ver:GetCurrentPackageId (0x31fd04 0x0): stub
002b:fixme:ver:GetCurrentPackageId (0x31fd04 0x0): stub
0009:fixme:ver:GetCurrentPackageId (0x31fd04 0x0): stub
```

----------
components: Windows
messages: 395677
nosy: paul.moore, samuelmarks, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python 3.9 and 3.10 fails to install in WINE
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Sat Jun 12 15:52:47 2021
From: report at bugs.python.org (Barney Gale)
Date: Sat, 12 Jun 2021 19:52:47 +0000
Subject: [New-bugs-announce] [issue44403] Add os.path.isreserved() function
Message-ID: <1623527567.53.0.441598034335.issue44403@roundup.psfhosted.org>


New submission from Barney Gale <barney.gale at gmail.com>:

Windows reserves certain filenames like 'NUL'. Checking for these names is part of a small handful of functionality that is available in pathlib but not in os.path.

I propose that we add an os.path.isreserved() function, encorporating Eryk Sun's work on bpo-27827. We then adjust pathlib to call the new function.

By doing so, we move one of the few remaining OS-specific implementations in pathlib to low-level libraries (posixpath, ntpath) where it arguably belongs.

We also make this functionality available to the segment of people using traditional string-based path operations who don't want to dip their toes into pathlib just for reserved names.

----------
components: Library (Lib)
messages: 395702
nosy: barneygale
priority: normal
severity: normal
status: open
title: Add os.path.isreserved() function
type: enhancement

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

From report at bugs.python.org  Sat Jun 12 16:53:12 2021
From: report at bugs.python.org (Philip Sundt)
Date: Sat, 12 Jun 2021 20:53:12 +0000
Subject: [New-bugs-announce] [issue44404] tkinter's after() AttributeError
 with functools.partial (no attribute __name__)
Message-ID: <1623531192.89.0.502203464734.issue44404@roundup.psfhosted.org>


New submission from Philip Sundt <phil.tgd at gmail.com>:

```
>>> import tkinter
>>> from functools import partial
>>> r=tkinter.Tk()
>>> r.after(500, partial(print, "lol"))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.7/tkinter/__init__.py", line 755, in after
    callit.__name__ = func.__name__
AttributeError: 'functools.partial' object has no attribute '__name__'
```

----------
components: Tkinter
messages: 395712
nosy: phil.tgd
priority: normal
severity: normal
status: open
title: tkinter's after() AttributeError with functools.partial (no attribute __name__)
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Sat Jun 12 20:44:24 2021
From: report at bugs.python.org (Arjun)
Date: Sun, 13 Jun 2021 00:44:24 +0000
Subject: [New-bugs-announce] [issue44405] add program passed as string to
 dis module.
Message-ID: <1623545064.0.0.0970757041396.issue44405@roundup.psfhosted.org>


New submission from Arjun <ccldarjun at icloud.com>:

python dis module should have a program passed in as string.

Currently, you can do this:
$ echo "x = 6" | python -m dis /dev/stdin
  1           0 LOAD_CONST               0 (6)
              2 STORE_NAME               0 (x)
              4 LOAD_CONST               1 (None)
              6 RETURN_VALUE

would be convenient like this:
$ ./python.exe -m dis -c "x=6"
  1           0 LOAD_CONST               0 (6)
              2 STORE_NAME               0 (x)
              4 LOAD_CONST               1 (None)
              6 RETURN_VALUE

these changes seem to be working.

----------
components: Library (Lib)
files: dis.patch
keywords: patch
messages: 395720
nosy: CCLDArjun
priority: normal
severity: normal
status: open
title: add program passed as string to dis module.
type: enhancement
Added file: https://bugs.python.org/file50107/dis.patch

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

From report at bugs.python.org  Sat Jun 12 22:06:49 2021
From: report at bugs.python.org (Dylan)
Date: Sun, 13 Jun 2021 02:06:49 +0000
Subject: [New-bugs-announce] [issue44406] Divergent sys.prefix behavior
 causes `python -m build` command to fail when in virtual environment
Message-ID: <1623550009.05.0.642341298843.issue44406@roundup.psfhosted.org>


New submission from Dylan <dsmaccy at rocketmail.com>:

Confirmed on 3.6 and 3.9.  The issue can be found in venv\__init__.py where the sys.prefix is used to determine the parent path of the python executable (near the bottom of the symlink_or_copy method at about line 190).  On the venv documentation page (https://docs.python.org/3/library/venv.html), it is noted that:

====
When a virtual environment is active (i.e., the virtual environment?s Python interpreter is running), the attributes sys.prefix and sys.exec_prefix point to the base directory of the virtual environment, whereas sys.base_prefix and sys.base_exec_prefix point to the non-virtual environment Python installation which was used to create the virtual environment. If a virtual environment is not active, then sys.prefix is the same as sys.base_prefix and sys.exec_prefix is the same as sys.base_exec_prefix (they all point to a non-virtual environment Python installation).
====

This code is called by lib\site-packages\build\env.py (venv.EnvBuilder...) which fails erroneously due to the divergent behavior of the sys.prefix as described in the documentation snippet above.

Recommended fix:  I'm not sure why that behavior diverges in the first place.  Ideally, either the build lib\venv\__init__.py should be updated to not rely on sys.prefix, or the sys.prefix behavior should be changed.

Additional Notes:
- I am seeing this issue on Windows 10
- The venv instance is within an Anaconda directory.
- The python -m build command I am running is from within a virtual environment
- I've listed file paths in relation to the library path within the same directory as the python executable for convenience.  Let me clarify, however, that there are multiple instances of the python lib folder: 1 global and 1 local copy.  The venv path is located in the global instance within the Anaconda path whereas the build script is using the virtual environment instance of python.

----------
assignee: docs at python
components: Build, Documentation, Windows
messages: 395721
nosy: docs at python, dsmaccy, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Divergent sys.prefix behavior causes `python -m build` command to fail when in virtual environment
versions: Python 3.6, Python 3.9

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

From report at bugs.python.org  Sun Jun 13 01:17:43 2021
From: report at bugs.python.org (Atsushi Sakai)
Date: Sun, 13 Jun 2021 05:17:43 +0000
Subject: [New-bugs-announce] [issue44407] A "Coroutines and Tasks" code
 example needs "asyncio.run(main())"
Message-ID: <1623561463.56.0.048465518238.issue44407@roundup.psfhosted.org>


New submission from Atsushi Sakai <asakaig at gmail.com>:

This is very small documentation improvement proposal.

In the "Coroutines and Tasks" doc, the code example after "Let?s modify the above example and run two say_after coroutines concurrently:" is missing "asyncio.run(main())" at the end of the code example:

async def main():
    task1 = asyncio.create_task(
        say_after(1, 'hello'))

    task2 = asyncio.create_task(
        say_after(2, 'world'))

    print(f"started at {time.strftime('%X')}")

    # Wait until both tasks are completed (should take
    # around 2 seconds.)
    await task1
    await task2

    print(f"finished at {time.strftime('%X')}")

----------
assignee: docs at python
components: Documentation
messages: 395728
nosy: AtsushiSakai, docs at python
priority: normal
severity: normal
status: open
title: A "Coroutines and Tasks" code example needs "asyncio.run(main())"
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Sun Jun 13 01:34:08 2021
From: report at bugs.python.org (John L)
Date: Sun, 13 Jun 2021 05:34:08 +0000
Subject: [New-bugs-announce] [issue44408] imaplib fails when server sends
 extra blank line after literal value
Message-ID: <1623562448.65.0.279795750286.issue44408@roundup.psfhosted.org>


New submission from John L <johnl at taugh.com>:

Some IMAP servers return an extra blank line after a counted literal value, which makes imaplib crash.
MacOS mail and T'bird handle the blank line OK so it seems to be a somewhat common bug.

----------
components: Library (Lib)
messages: 395729
nosy: jrlevine
priority: normal
severity: normal
status: open
title: imaplib fails when server sends extra blank line after literal value
type: crash
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Jun 13 07:25:16 2021
From: report at bugs.python.org (Florian Weimer)
Date: Sun, 13 Jun 2021 11:25:16 +0000
Subject: [New-bugs-announce] [issue44409] compile raises SyntaxError with
 undocumented lineno attribute None
Message-ID: <1623583516.06.0.84402770903.issue44409@roundup.psfhosted.org>


New submission from Florian Weimer <fweimer at redhat.com>:

This example results in an undocumented value None for the lineno attribute:

```
source = b"\xef\xbb\xbf#coding: utf8\nprint('\xe6\x88\x91')\n"

try:
    compile(source, filename="example.py", mode="exec")
except SyntaxError as e:
    print(str(e))
    print(type(e.lineno))
```

Output:

```
encoding problem: utf8 with BOM
<class 'NoneType'>
```

Seen with python3-3.9.5-2.fc33.x86_64.

python3-3.8.10-1.fc32.x86_64 used a lineno value of 0 (type int).

----------
components: Parser
messages: 395740
nosy: fweimer, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: compile raises SyntaxError with undocumented lineno attribute None
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Sun Jun 13 10:52:01 2021
From: report at bugs.python.org (Daniel Andersson)
Date: Sun, 13 Jun 2021 14:52:01 +0000
Subject: [New-bugs-announce] [issue44410] Exception in AsyncMock side_effect
 cases incorrect refcount
Message-ID: <1623595921.99.0.250644393873.issue44410@roundup.psfhosted.org>


New submission from Daniel Andersson <daniel.4ndersson at gmail.com>:

Dear maintainers,

I discovered an unexpected behavior when the `side_effect` of an `AsyncMock` includes an exception. The test case below fails but I expected it to pass:

```
import sys
import unittest
from unittest.mock import AsyncMock


class A:
    async def foobar(self):
        while True:
            try:
                return await self.mock()
            except Exception:
                continue


class TestA(unittest.IsolatedAsyncioTestCase):
    async def test_refcount(self):
        a = A()
        a.mock = AsyncMock(side_effect=[Exception(), None])
        refc = sys.getrefcount(a)
        await a.foobar()
        self.assertEqual(refc, sys.getrefcount(a))


if __name__ == "__main__":
    unittest.main()
```

If `side_effect=[Exception(), None]` is changed to `side_effect=[None, None]` the test case pass.

I discovered this in a bigger codebase while debugging why a weakref.finalize did not trigger as expected.

----------
components: asyncio
messages: 395752
nosy: asvetlov, penlect, yselivanov
priority: normal
severity: normal
status: open
title: Exception in AsyncMock side_effect cases incorrect refcount
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Sun Jun 13 11:21:10 2021
From: report at bugs.python.org (Jack DeVries)
Date: Sun, 13 Jun 2021 15:21:10 +0000
Subject: [New-bugs-announce] [issue44411] regrtests fail with segfault after
 failing calls to malloc
Message-ID: <1623597670.2.0.418457748374.issue44411@roundup.psfhosted.org>


New submission from Jack DeVries <jdevries3133 at gmail.com>:

When running regrtests via `./python.exe -m test` on my system, several warnings about failing calls to malloc are generated during `test_decorators`. Then, a segmentation fault happens shortly thereafter in `test_descrtut`.

The most recent commit on the main branch as of this test run was 17b16e13bb444001534ed6fccb459084596c8bcf.

Here are some details about my system:

Model Name:	MacBook Pro
  Model Identifier:	MacBookPro12,1
  Processor Name:	Dual-Core Intel Core i5
  Processor Speed:	2.7 GHz
  Number of Processors:	1
  Total Number of Cores:	2
  L2 Cache (per Core):	256 KB
  L3 Cache:	3 MB
  Hyper-Threading Technology:	Enabled
  Memory:	8 GB
  System Firmware Version:	427.0.0.0.0
  SMC Version (system):	2.28f7
  Serial Number (system):	C02P9EMTFVH5
  Hardware UUID:	ABA9DB61-5A93-54BC-8057-6F0E0DA6544B
  Provisioning UDID:	ABA9DB61-5A93-54BC-8057-6F0E0DA6544B



Here is the full output from cloning all the way down to segfault
=================================================================


?  tmp.kw3WJpEs git clone git at github.com:python/cpython.git . --depth=1
Cloning into '.'...
remote: Enumerating objects: 4779, done.
remote: Counting objects: 100% (4779/4779), done.
remote: Compressing objects: 100% (4362/4362), done.
remote: Total 4779 (delta 488), reused 1570 (delta 314), pack-reused 0
Receiving objects: 100% (4779/4779), 24.71 MiB | 11.00 MiB/s, done.
Resolving deltas: 100% (488/488), done.
Updating files: 100% (4537/4537), done.
?  tmp.kw3WJpEs git:(main) ./configure --with-pydebug
checking for git... found
checking build system type... x86_64-apple-darwin20.5.0
checking host system type... x86_64-apple-darwin20.5.0
checking for python3.11... no
checking for python3... python3
checking for --enable-universalsdk... no
checking for --with-universal-archs... no
checking MACHDEP... "darwin"
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for a sed that does not truncate output... /usr/bin/sed
checking for --with-cxx-main=<compiler>... no
checking for g++... no
configure:

  By default, distutils will build C++ extension modules with "g++".
  If this is not intended, then set CXX on the configure command line.
  
checking for the platform triplet based on compiler characteristics... darwin
checking for -Wl,--no-as-needed... no
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking for the Android API level... not Android
checking for --with-suffix... 
checking for case-insensitive build directory... yes
checking LIBRARY... libpython$(VERSION)$(ABIFLAGS).a
checking LINKCC... $(PURIFY) $(MAINCC)
checking EXPORTSYMS... 
checking for GNU ld... no
checking for --enable-shared... no
checking for --enable-profiling... no
checking LDLIBRARY... libpython$(VERSION)$(ABIFLAGS).a
checking for ar... ar
checking for readelf... no
checking for a BSD-compatible install... /usr/bin/install -c
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for --with-pydebug... yes
checking for --with-trace-refs... no
checking for --with-assertions... implied by --with-pydebug
checking for --enable-optimizations... no
checking PROFILE_TASK... -m test --pgo --timeout=$(TESTTIMEOUT)
checking for --with-lto... no
checking for llvm-profdata... no
configure: llvm-profdata found via xcrun: /usr/bin/xcrun llvm-profdata
checking for -Wextra... yes
checking whether gcc accepts and needs -fno-strict-aliasing... no
checking if we can turn off gcc unused result warning... yes
checking if we can turn off gcc unused parameter warning... yes
checking if we can turn off gcc missing field initializers warning... yes
checking if we can turn on gcc mixed sign comparison warning... yes
checking if we can turn on gcc unreachable code warning... no
checking if we can turn on gcc strict-prototypes warning... yes
checking if we can make implicit function declaration an error in gcc... yes
checking if we can use visibility in gcc... yes
checking which compiler should be used... gcc
checking which MACOSX_DEPLOYMENT_TARGET to use... 11.4
checking if specified universal architectures work... yes
checking whether pthreads are available without options... yes
checking whether g++ also accepts flags for thread support... no
checking for ANSI C header files... (cached) yes
checking asm/types.h usability... no
checking asm/types.h presence... no
checking for asm/types.h... no
checking crypt.h usability... no
checking crypt.h presence... no
checking for crypt.h... no
checking conio.h usability... no
checking conio.h presence... no
checking for conio.h... no
checking direct.h usability... no
checking direct.h presence... no
checking for direct.h... no
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking errno.h usability... yes
checking errno.h presence... yes
checking for errno.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking grp.h usability... yes
checking grp.h presence... yes
checking for grp.h... yes
checking ieeefp.h usability... no
checking ieeefp.h presence... no
checking for ieeefp.h... no
checking io.h usability... no
checking io.h presence... no
checking for io.h... no
checking langinfo.h usability... yes
checking langinfo.h presence... yes
checking for langinfo.h... yes
checking libintl.h usability... yes
checking libintl.h presence... yes
checking for libintl.h... yes
checking process.h usability... no
checking process.h presence... no
checking for process.h... no
checking pthread.h usability... yes
checking pthread.h presence... yes
checking for pthread.h... yes
checking sched.h usability... yes
checking sched.h presence... yes
checking for sched.h... yes
checking shadow.h usability... no
checking shadow.h presence... no
checking for shadow.h... no
checking signal.h usability... yes
checking signal.h presence... yes
checking for signal.h... yes
checking stropts.h usability... no
checking stropts.h presence... no
checking for stropts.h... no
checking termios.h usability... yes
checking termios.h presence... yes
checking for termios.h... yes
checking utime.h usability... yes
checking utime.h presence... yes
checking for utime.h... yes
checking poll.h usability... yes
checking poll.h presence... yes
checking for poll.h... yes
checking sys/devpoll.h usability... no
checking sys/devpoll.h presence... no
checking for sys/devpoll.h... no
checking sys/epoll.h usability... no
checking sys/epoll.h presence... no
checking for sys/epoll.h... no
checking sys/poll.h usability... yes
checking sys/poll.h presence... yes
checking for sys/poll.h... yes
checking sys/audioio.h usability... no
checking sys/audioio.h presence... no
checking for sys/audioio.h... no
checking sys/xattr.h usability... yes
checking sys/xattr.h presence... yes
checking for sys/xattr.h... yes
checking sys/bsdtty.h usability... no
checking sys/bsdtty.h presence... no
checking for sys/bsdtty.h... no
checking sys/event.h usability... yes
checking sys/event.h presence... yes
checking for sys/event.h... yes
checking sys/file.h usability... yes
checking sys/file.h presence... yes
checking for sys/file.h... yes
checking sys/ioctl.h usability... yes
checking sys/ioctl.h presence... yes
checking for sys/ioctl.h... yes
checking sys/kern_control.h usability... yes
checking sys/kern_control.h presence... yes
checking for sys/kern_control.h... yes
checking sys/loadavg.h usability... no
checking sys/loadavg.h presence... no
checking for sys/loadavg.h... no
checking sys/lock.h usability... yes
checking sys/lock.h presence... yes
checking for sys/lock.h... yes
checking sys/mkdev.h usability... no
checking sys/mkdev.h presence... no
checking for sys/mkdev.h... no
checking sys/modem.h usability... no
checking sys/modem.h presence... no
checking for sys/modem.h... no
checking sys/param.h usability... yes
checking sys/param.h presence... yes
checking for sys/param.h... yes
checking sys/random.h usability... yes
checking sys/random.h presence... yes
checking for sys/random.h... yes
checking sys/select.h usability... yes
checking sys/select.h presence... yes
checking for sys/select.h... yes
checking sys/sendfile.h usability... no
checking sys/sendfile.h presence... no
checking for sys/sendfile.h... no
checking sys/socket.h usability... yes
checking sys/socket.h presence... yes
checking for sys/socket.h... yes
checking sys/statvfs.h usability... yes
checking sys/statvfs.h presence... yes
checking for sys/statvfs.h... yes
checking for sys/stat.h... (cached) yes
checking sys/syscall.h usability... yes
checking sys/syscall.h presence... yes
checking for sys/syscall.h... yes
checking sys/sys_domain.h usability... yes
checking sys/sys_domain.h presence... yes
checking for sys/sys_domain.h... yes
checking sys/termio.h usability... no
checking sys/termio.h presence... no
checking for sys/termio.h... no
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking sys/times.h usability... yes
checking sys/times.h presence... yes
checking for sys/times.h... yes
checking for sys/types.h... (cached) yes
checking sys/uio.h usability... yes
checking sys/uio.h presence... yes
checking for sys/uio.h... yes
checking sys/un.h usability... yes
checking sys/un.h presence... yes
checking for sys/un.h... yes
checking sys/utsname.h usability... yes
checking sys/utsname.h presence... yes
checking for sys/utsname.h... yes
checking sys/wait.h usability... yes
checking sys/wait.h presence... yes
checking for sys/wait.h... yes
checking pty.h usability... no
checking pty.h presence... no
checking for pty.h... no
checking libutil.h usability... no
checking libutil.h presence... no
checking for libutil.h... no
checking sys/resource.h usability... yes
checking sys/resource.h presence... yes
checking for sys/resource.h... yes
checking netpacket/packet.h usability... no
checking netpacket/packet.h presence... no
checking for netpacket/packet.h... no
checking sysexits.h usability... yes
checking sysexits.h presence... yes
checking for sysexits.h... yes
checking bluetooth.h usability... no
checking bluetooth.h presence... no
checking for bluetooth.h... no
checking linux/tipc.h usability... no
checking linux/tipc.h presence... no
checking for linux/tipc.h... no
checking linux/random.h usability... no
checking linux/random.h presence... no
checking for linux/random.h... no
checking spawn.h usability... yes
checking spawn.h presence... yes
checking for spawn.h... yes
checking util.h usability... yes
checking util.h presence... yes
checking for util.h... yes
checking alloca.h usability... yes
checking alloca.h presence... yes
checking for alloca.h... yes
checking endian.h usability... no
checking endian.h presence... no
checking for endian.h... no
checking sys/endian.h usability... no
checking sys/endian.h presence... no
checking for sys/endian.h... no
checking sys/sysmacros.h usability... no
checking sys/sysmacros.h presence... no
checking for sys/sysmacros.h... no
checking linux/memfd.h usability... no
checking linux/memfd.h presence... no
checking for linux/memfd.h... no
checking linux/wait.h usability... no
checking linux/wait.h presence... no
checking for linux/wait.h... no
checking sys/memfd.h usability... no
checking sys/memfd.h presence... no
checking for sys/memfd.h... no
checking sys/mman.h usability... yes
checking sys/mman.h presence... yes
checking for sys/mman.h... yes
checking sys/eventfd.h usability... no
checking sys/eventfd.h presence... no
checking for sys/eventfd.h... no
checking for dirent.h that defines DIR... yes
checking for library containing opendir... none required
checking whether sys/types.h defines makedev... yes
checking bluetooth/bluetooth.h usability... no
checking bluetooth/bluetooth.h presence... no
checking for bluetooth/bluetooth.h... no
checking for net/if.h... yes
checking for linux/netlink.h... no
checking for linux/qrtr.h... no
checking for linux/vm_sockets.h... no
checking for linux/can.h... no
checking for linux/can/bcm.h... no
checking for linux/can/j1939.h... no
checking for linux/can/raw.h... no
checking for clock_t in time.h... yes
checking for makedev... yes
checking for le64toh... no
checking for mode_t... yes
checking for off_t... yes
checking for pid_t... yes
checking for size_t... yes
checking for uid_t in sys/types.h... yes
checking for ssize_t... yes
checking for __uint128_t... yes
checking size of int... 4
checking size of long... 8
checking alignment of long... 8
checking size of long long... 8
checking size of void *... 8
checking size of short... 2
checking size of float... 4
checking size of double... 8
checking size of fpos_t... 8
checking size of size_t... 8
checking alignment of size_t... 8
checking size of pid_t... 4
checking size of uintptr_t... 8
checking for long double... yes
checking size of long double... 16
checking size of _Bool... 1
checking size of off_t... 8
checking whether to enable large file support... no
checking size of time_t... 8
checking for pthread_t... yes
checking size of pthread_t... 8
checking size of pthread_key_t... 8
checking whether pthread_key_t is compatible with int... no
checking for --enable-framework... no
checking for dyld... always on for Darwin
checking the extension of shared libraries... .so
checking LDSHARED... $(CC) -bundle -undefined dynamic_lookup
checking CCSHARED... 
checking LINKFORSHARED... -Wl,-stack_size,1000000  -framework CoreFoundation
checking CFLAGSFORSHARED... 
checking SHLIBS... $(LIBS)
checking for sendfile in -lsendfile... no
checking for dlopen in -ldl... yes
checking for shl_load in -ldld... no
checking uuid/uuid.h usability... yes
checking uuid/uuid.h presence... yes
checking for uuid/uuid.h... yes
checking uuid.h usability... no
checking uuid.h presence... no
checking for uuid.h... no
checking for uuid_generate_time_safe... no
checking for uuid_create... no
checking for uuid_enc_be... no
checking for library containing sem_init... none required
checking for textdomain in -lintl... yes
checking aligned memory access is required... no
checking for --with-hash-algorithm... default
checking for --with-tzpath... "/usr/share/zoneinfo:/usr/lib/zoneinfo:/usr/share/lib/zoneinfo:/etc/zoneinfo"
checking for --with-address-sanitizer... no
checking for --with-memory-sanitizer... no
checking for --with-undefined-behavior-sanitizer... no
checking for t_open in -lnsl... no
checking for socket in -lsocket... no
checking for --with-libs... no
./configure: line 10530: PKG_PROG_PKG_CONFIG: command not found
checking for --with-system-expat... no
checking for --with-system-ffi... no
checking for --with-system-libmpdec... no
checking for --with-decimal-contextvar... yes
checking for --enable-loadable-sqlite-extensions... no
checking for --with-tcltk-includes... default
checking for --with-tcltk-libs... default
checking for --with-dbmliborder... 
checking if PTHREAD_SCOPE_SYSTEM is supported... yes
checking for pthread_sigmask... yes
checking for pthread_getcpuclockid... no
checking if --enable-ipv6 is specified... yes
checking if RFC2553 API is available... yes
checking ipv6 stack type... kame
using libc
checking for CAN_RAW_FD_FRAMES... no
checking for CAN_RAW_JOIN_FILTERS... no
checking for --with-doc-strings... yes
checking for --with-pymalloc... yes
checking for --with-c-locale-coercion... yes
checking for --with-valgrind... no
checking for --with-dtrace... no
checking for dlopen... yes
checking DYNLOADFILE... dynload_shlib.o
checking MACHDEP_OBJS... none
checking for alarm... yes
checking for accept4... no
checking for setitimer... yes
checking for getitimer... yes
checking for bind_textdomain_codeset... yes
checking for chown... yes
checking for clock... yes
checking for confstr... yes
checking for close_range... no
checking for copy_file_range... no
checking for ctermid... yes
checking for dup3... no
checking for execv... yes
checking for explicit_bzero... no
checking for explicit_memset... no
checking for faccessat... yes
checking for fchmod... yes
checking for fchmodat... yes
checking for fchown... yes
checking for fchownat... yes
checking for fdwalk... no
checking for fexecve... no
checking for fdopendir... yes
checking for fork... yes
checking for fpathconf... yes
checking for fstatat... yes
checking for ftime... yes
checking for ftruncate... yes
checking for futimesat... no
checking for futimens... yes
checking for futimes... yes
checking for gai_strerror... yes
checking for getentropy... yes
checking for getgrgid_r... yes
checking for getgrnam_r... yes
checking for getgrouplist... yes
checking for getgroups... yes
checking for getlogin... yes
checking for getloadavg... yes
checking for getpeername... yes
checking for getpgid... yes
checking for getpid... yes
checking for getpriority... yes
checking for getresuid... no
checking for getresgid... no
checking for getpwent... yes
checking for getpwnam_r... yes
checking for getpwuid_r... yes
checking for getspnam... no
checking for getspent... no
checking for getsid... yes
checking for getwd... yes
checking for if_nameindex... yes
checking for initgroups... yes
checking for kill... yes
checking for killpg... yes
checking for lchown... yes
checking for lockf... yes
checking for linkat... yes
checking for lstat... yes
checking for lutimes... yes
checking for mmap... yes
checking for memrchr... no
checking for mbrtowc... yes
checking for mkdirat... yes
checking for mkfifo... yes
checking for madvise... yes
checking for mkfifoat... no
checking for mknod... yes
checking for mknodat... no
checking for mktime... yes
checking for mremap... no
checking for nice... yes
checking for openat... yes
checking for pathconf... yes
checking for pause... yes
checking for pipe2... no
checking for plock... no
checking for poll... yes
checking for posix_fallocate... no
checking for posix_fadvise... no
checking for posix_spawn... yes
checking for posix_spawnp... yes
checking for pread... yes
checking for preadv... yes
checking for preadv2... no
checking for pthread_condattr_setclock... no
checking for pthread_init... no
checking for pthread_kill... yes
checking for pwrite... yes
checking for pwritev... yes
checking for pwritev2... no
checking for readlink... yes
checking for readlinkat... yes
checking for readv... yes
checking for realpath... yes
checking for renameat... yes
checking for sem_open... yes
checking for sem_timedwait... no
checking for sem_getvalue... yes
checking for sem_unlink... yes
checking for sendfile... yes
checking for setegid... yes
checking for seteuid... yes
checking for setgid... yes
checking for sethostname... yes
checking for setlocale... yes
checking for setregid... yes
checking for setreuid... yes
checking for setresuid... no
checking for setresgid... no
checking for setsid... yes
checking for setpgid... yes
checking for setpgrp... yes
checking for setpriority... yes
checking for setuid... yes
checking for setvbuf... yes
checking for sched_get_priority_max... yes
checking for sched_setaffinity... no
checking for sched_setscheduler... no
checking for sched_setparam... no
checking for sched_rr_get_interval... no
checking for sigaction... yes
checking for sigaltstack... yes
checking for sigfillset... yes
checking for siginterrupt... yes
checking for sigpending... yes
checking for sigrelse... yes
checking for sigtimedwait... no
checking for sigwait... yes
checking for sigwaitinfo... no
checking for snprintf... yes
checking for splice... no
checking for strftime... yes
checking for strlcpy... yes
checking for strsignal... yes
checking for symlinkat... yes
checking for sync... yes
checking for sysconf... yes
checking for tcgetpgrp... yes
checking for tcsetpgrp... yes
checking for tempnam... yes
checking for timegm... yes
checking for times... yes
checking for tmpfile... yes
checking for tmpnam... yes
checking for tmpnam_r... no
checking for truncate... yes
checking for uname... yes
checking for unlinkat... yes
checking for utimensat... yes
checking for utimes... yes
checking for vfork... yes
checking for waitid... yes
checking for waitpid... yes
checking for wait3... yes
checking for wait4... yes
checking for wcscoll... yes
checking for wcsftime... yes
checking for wcsxfrm... yes
checking for wmemcmp... yes
checking for writev... yes
checking for _getpty... no
checking for rtpSpawn... no
checking for lchmod... yes
checking whether dirfd is declared... yes
checking for chroot... yes
checking for link... yes
checking for symlink... yes
checking for fchdir... yes
checking for fsync... yes
checking for fdatasync... no
checking for epoll... no
checking for epoll_create1... no
checking for kqueue... yes
checking for prlimit... no
checking for _dyld_shared_cache_contains_path... yes
checking for memfd_create... no
checking for eventfd... no
checking for ctermid_r... yes
checking for flock declaration... yes
checking for flock... yes
checking for getpagesize... yes
checking for broken unsetenv... no
checking for true... true
checking for inet_aton in -lc... yes
checking for chflags... yes
checking for lchflags... yes
checking for inflateCopy in -lz... yes
checking for hstrerror... yes
checking for inet_aton... yes
checking for inet_pton... yes
checking for setgroups... yes
checking for openpty... yes
checking for forkpty... yes
checking for fseek64... no
checking for fseeko... yes
checking for fstatvfs... yes
checking for ftell64... no
checking for ftello... yes
checking for statvfs... yes
checking for dup2... yes
checking for getpgrp... yes
checking for setpgrp... (cached) yes
checking for library containing crypt... none required
checking for library containing crypt_r... no
checking for crypt_r... no
checking for clock_gettime... yes
checking for clock_getres... yes
checking for clock_settime... yes
checking for major... yes
checking for getaddrinfo... yes
checking getaddrinfo bug... no
checking for getnameinfo... yes
checking whether time.h and sys/time.h may both be included... yes
checking whether struct tm is in sys/time.h or time.h... time.h
checking for struct tm.tm_zone... yes
checking for struct stat.st_rdev... yes
checking for struct stat.st_blksize... yes
checking for struct stat.st_flags... yes
checking for struct stat.st_gen... yes
checking for struct stat.st_birthtime... yes
checking for struct stat.st_blocks... yes
checking for struct passwd.pw_gecos... yes
checking for struct passwd.pw_passwd... yes
checking for siginfo_t.si_band... yes
checking for time.h that defines altzone... no
checking whether sys/select.h and sys/time.h may both be included... yes
checking for addrinfo... yes
checking for sockaddr_storage... yes
checking for sockaddr_alg... no
checking whether char is unsigned... no
checking for an ANSI C-conforming const... yes
checking for working signed char... yes
checking for prototypes... yes
checking for variable length prototypes and stdarg.h... yes
checking for socketpair... yes
checking if sockaddr has sa_len member... yes
checking for gethostbyname_r... no
checking for gethostbyname... yes
checking for __fpu_control... no
checking for __fpu_control in -lieee... no
checking for --with-libm=STRING... default LIBM=""
checking for --with-libc=STRING... default LIBC=""
checking for x64 gcc inline assembler... yes
checking whether float word ordering is bigendian... no
checking whether we can use gcc inline assembler to get and set x87 control word... yes
checking whether we can use gcc inline assembler to get and set mc68881 fpcr... no
checking for x87-style double rounding... no
checking for acosh... yes
checking for asinh... yes
checking for atanh... yes
checking for copysign... yes
checking for erf... yes
checking for erfc... yes
checking for expm1... yes
checking for finite... yes
checking for gamma... yes
checking for hypot... yes
checking for lgamma... yes
checking for log1p... yes
checking for log2... yes
checking for round... yes
checking for tgamma... yes
checking whether isinf is declared... yes
checking whether isnan is declared... yes
checking whether isfinite is declared... yes
checking whether POSIX semaphores are enabled... yes
checking for broken sem_getvalue... yes
checking whether RTLD_LAZY is declared... yes
checking whether RTLD_NOW is declared... yes
checking whether RTLD_GLOBAL is declared... yes
checking whether RTLD_LOCAL is declared... yes
checking whether RTLD_NODELETE is declared... yes
checking whether RTLD_NOLOAD is declared... yes
checking whether RTLD_DEEPBIND is declared... no
checking whether RTLD_MEMBER is declared... no
checking digit size for Python's longs... no value specified
checking wchar.h usability... yes
checking wchar.h presence... yes
checking for wchar.h... yes
checking size of wchar_t... 4
checking for UCS-4 tcl... no
checking whether wchar_t is signed... yes
checking whether wchar_t is usable... no
checking whether byte ordering is bigendian... no
checking ABIFLAGS... d
checking SOABI... cpython-311d-darwin
checking LDVERSION... $(VERSION)$(ABIFLAGS)
checking for --with-platlibdir... no
checking for --with-wheel-pkg-dir... no
checking whether right shift extends the sign bit... yes
checking for getc_unlocked() and friends... yes
checking how to link readline libs... -lreadline
checking whether rl_completion_append_character is declared... yes
checking whether rl_completion_suppress_append is declared... no
checking for rl_pre_input_hook in -lreadline... yes
checking for rl_completion_display_matches_hook in -lreadline... yes
checking for rl_resize_terminal in -lreadline... no
checking for rl_completion_matches in -lreadline... yes
checking whether rl_catch_signals is declared... no
checking for append_history in -lreadline... no
checking for broken nice()... no
checking for broken poll()... no
checking for working tzset()... yes
checking for tv_nsec in struct stat... no
checking for tv_nsec2 in struct stat... yes
checking curses.h usability... yes
checking curses.h presence... yes
checking for curses.h... yes
checking ncurses.h usability... yes
checking ncurses.h presence... yes
checking for ncurses.h... yes
checking for term.h... yes
checking whether mvwdelch is an expression... yes
checking whether WINDOW has _flags... yes
checking for is_pad... no
checking for is_term_resized... yes
checking for resize_term... yes
checking for resizeterm... yes
checking for immedok... yes
checking for syncok... yes
checking for wchgat... yes
checking for filter... yes
checking for has_key... yes
checking for typeahead... yes
checking for use_env... yes
configure: checking for device files
checking for /dev/ptmx... yes
checking for /dev/ptc... no
checking for %zd printf() format support... yes
checking for socklen_t... yes
checking for broken mbstowcs... no
checking for --with-computed-gotos... no value specified
checking whether gcc supports computed gotos... yes
checking for build directories... done
checking for -O2... yes
checking for glibc _FORTIFY_SOURCE/memmove bug... no
checking for gcc ipa-pure-const bug... no
checking for stdatomic.h... yes
checking for builtin __atomic_load_n and __atomic_store_n functions... yes
checking for ensurepip... upgrade
checking if the dirent structure of a d_type field... yes
checking for the Linux getrandom() syscall... no
checking for the getrandom() function... no
checking for library containing shm_open... none required
checking for sys/mman.h... (cached) yes
checking for shm_open... yes
checking for shm_unlink... yes
checking for pkg-config... pkg-config
checking whether compiling and linking against OpenSSL works... yes
checking for --with-openssl-rpath... 
checking for --with-ssl-default-suites... python
checking for --with-builtin-hashlib-hashes... md5,sha1,sha256,sha512,sha3,blake2
checking for --with-experimental-isolated-subinterpreters... no
checking for --with-static-libpython... yes
checking for --disable-test-modules... no
configure: creating ./config.status
config.status: creating Makefile.pre
config.status: creating Misc/python.pc
config.status: creating Misc/python-embed.pc
config.status: creating Misc/python-config.sh
config.status: creating Modules/ld_so_aix
config.status: creating pyconfig.h
creating Modules/Setup.local
creating Makefile
?  tmp.kw3WJpEs git:(main) make -s -j
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: libpython3.11d.a(dynamic_annotations.o) has no symbols
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: libpython3.11d.a(pymath.o) has no symbols
 CC='gcc' LDSHARED='gcc -bundle -undefined dynamic_lookup    ' OPT='-g -O0 -Wall' 	_TCLTK_INCLUDES='' _TCLTK_LIBS='' 	./python.exe -E ./setup.py -q build
ld: warning: directory not found for option '-L/usr/lib/termcap'
/private/var/folders/wt/twzkdpd53g182wvx2s1n_6540000gn/T/tmp.kw3WJpEs/Modules/_sqlite/module.c:145:10: warning: 
      'sqlite3_enable_shared_cache' is deprecated: first deprecated in macOS 10.7 - Not supported [-Wdeprecated-declarations]
    rc = sqlite3_enable_shared_cache(do_enable);
         ^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sqlite3.h:6341:16: note: 'sqlite3_enable_shared_cache' has been explicitly
      marked deprecated here
SQLITE_API int sqlite3_enable_shared_cache(int);
               ^
1 warning generated.
/private/var/folders/wt/twzkdpd53g182wvx2s1n_6540000gn/T/tmp.kw3WJpEs/Modules/_tkinter.c:2927:12: warning: 'Tk_GetNumMainWindows' is
      deprecated: first deprecated in macOS 10.15 - Tk API deprecated. [-Wdeprecated-declarations]
    while (Tk_GetNumMainWindows() > threshold &&
           ^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Tk.framework/Headers/tkDecls.h:673:13: note: 
      'Tk_GetNumMainWindows' has been explicitly marked deprecated here
EXTERN int              Tk_GetNumMainWindows(void);
                        ^
/private/var/folders/wt/twzkdpd53g182wvx2s1n_6540000gn/T/tmp.kw3WJpEs/Modules/_tkinter.c:3054:13: warning: 'Tk_Init' is deprecated: first
      deprecated in macOS 10.15 - Tk API deprecated. [-Wdeprecated-declarations]
        if (Tk_Init(interp)             == TCL_ERROR) {
            ^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Tk.framework/Headers/tkDecls.h:769:13: note: 'Tk_Init' has been
      explicitly marked deprecated here
EXTERN int              Tk_Init(Tcl_Interp *interp);
                        ^
/private/var/folders/wt/twzkdpd53g182wvx2s1n_6540000gn/T/tmp.kw3WJpEs/Modules/_tkinter.c:3450:9: warning: 'Tk_GetNumMainWindows' is
      deprecated: first deprecated in macOS 10.15 - Tk API deprecated. [-Wdeprecated-declarations]
    if (Tk_GetNumMainWindows() == 0 && PyOS_InputHook == EventHook) {
        ^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Tk.framework/Headers/tkDecls.h:673:13: note: 
      'Tk_GetNumMainWindows' has been explicitly marked deprecated here
EXTERN int              Tk_GetNumMainWindows(void);
                        ^
3 warnings generated.
/private/var/folders/wt/twzkdpd53g182wvx2s1n_6540000gn/T/tmp.kw3WJpEs/Modules/tkappinit.c:105:9: warning: 'Tk_Init' is deprecated: first
      deprecated in macOS 10.15 - Tk API deprecated. [-Wdeprecated-declarations]
    if (Tk_Init(interp) == TCL_ERROR) {
        ^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Tk.framework/Headers/tkDecls.h:769:13: note: 'Tk_Init' has been
      explicitly marked deprecated here
EXTERN int              Tk_Init(Tcl_Interp *interp);
                        ^
/private/var/folders/wt/twzkdpd53g182wvx2s1n_6540000gn/T/tmp.kw3WJpEs/Modules/tkappinit.c:113:5: warning: 'Tk_MainWindow' is deprecated:
      first deprecated in macOS 10.15 - Tk API deprecated. [-Wdeprecated-declarations]
    Tk_MainWindow(interp);
    ^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Tk.framework/Headers/tkDecls.h:792:18: note: 'Tk_MainWindow'
      has been explicitly marked deprecated here
EXTERN Tk_Window        Tk_MainWindow(Tcl_Interp *interp);
                        ^
2 warnings generated.

Python build finished successfully!
The necessary bits to build these optional modules were not found:
ossaudiodev           spwd                                     
To find the necessary bits, look in setup.py in detect_modules() for the module's name.


The following modules found by detect_modules() in setup.py, have been
built by the Makefile instead, as configured by the Setup files:
_abc                  pwd                   time               

?  tmp.kw3WJpEs git:(main) ./python.exe -m test
== CPython 3.11.0a0 (heads/main:17b16e1, Jun 13 2021, 00:58:47) [Clang 12.0.0 (clang-1200.0.32.27)]
== macOS-11.4-x86_64-i386-64bit little-endian
== cwd: /private/var/folders/wt/twzkdpd53g182wvx2s1n_6540000gn/T/tmp.kw3WJpEs/build/test_python_37107?
== CPU count: 4
== encodings: locale=UTF-8, FS=utf-8
0:00:00 load avg: 27.15 Run tests sequentially
0:00:00 load avg: 27.15 [  1/427] test_grammar
0:00:00 load avg: 27.15 [  2/427] test_opcodes
0:00:00 load avg: 27.15 [  3/427] test_dict
0:00:02 load avg: 27.15 [  4/427] test_builtin
0:00:04 load avg: 27.15 [  5/427] test_exceptions
0:00:07 load avg: 25.22 [  6/427] test_types
0:00:08 load avg: 25.22 [  7/427] test_unittest
0:00:22 load avg: 20.29 [  8/427] test_doctest
0:00:27 load avg: 19.06 [  9/427] test_doctest2
0:00:27 load avg: 19.06 [ 10/427] test_support
0:00:40 load avg: 15.65 [ 11/427] test___all__
0:00:51 load avg: 13.62 [ 12/427] test___future__
0:00:52 load avg: 13.62 [ 13/427] test__locale
0:00:53 load avg: 13.62 [ 14/427] test__opcode
0:00:55 load avg: 12.85 [ 15/427] test__osx_support
0:00:56 load avg: 12.85 [ 16/427] test__xxsubinterpreters
0:01:02 load avg: 11.98 [ 17/427] test_abc
0:01:03 load avg: 11.98 [ 18/427] test_abstract_numbers
0:01:04 load avg: 11.98 [ 19/427] test_aifc
0:01:06 load avg: 11.26 [ 20/427] test_argparse
0:01:19 load avg: 10.06 [ 21/427] test_array
0:01:29 load avg: 9.36 [ 22/427] test_asdl_parser
0:01:30 load avg: 8.85 [ 23/427] test_ast
0:01:42 load avg: 8.10 [ 24/427] test_asyncgen
0:01:44 load avg: 8.10 [ 25/427] test_asynchat
0:01:47 load avg: 7.70 [ 26/427] test_asyncio
0:06:25 load avg: 2.97 [ 27/427] test_asyncore -- test_asyncio passed in 4 min 38 sec
0:06:28 load avg: 3.77 [ 28/427] test_atexit
0:06:30 load avg: 3.77 [ 29/427] test_audioop
0:06:32 load avg: 3.77 [ 30/427] test_audit
0:06:38 load avg: 4.30 [ 31/427] test_augassign
0:06:40 load avg: 4.30 [ 32/427] test_base64
0:06:42 load avg: 4.30 [ 33/427] test_baseexception
0:06:44 load avg: 4.35 [ 34/427] test_bdb
0:06:46 load avg: 4.35 [ 35/427] test_bigaddrspace
0:06:47 load avg: 4.35 [ 36/427] test_bigmem
0:06:48 load avg: 4.16 [ 37/427] test_binascii
0:06:50 load avg: 4.16 [ 38/427] test_binhex
0:06:51 load avg: 4.16 [ 39/427] test_binop
0:06:52 load avg: 4.16 [ 40/427] test_bisect
0:06:54 load avg: 4.71 [ 41/427] test_bool
0:06:56 load avg: 4.71 [ 42/427] test_buffer
0:07:37 load avg: 6.24 [ 43/427] test_bufio -- test_buffer passed in 40.9 sec
0:07:46 load avg: 11.70 [ 44/427] test_bytes
0:08:07 load avg: 11.21 [ 45/427] test_bz2
0:08:18 load avg: 12.44 [ 46/427] test_c_locale_coercion
0:08:25 load avg: 11.45 [ 47/427] test_calendar
0:08:35 load avg: 10.14 [ 48/427] test_call
0:08:37 load avg: 10.14 [ 49/427] test_capi
0:08:49 load avg: 8.47 [ 50/427] test_cgi
0:08:50 load avg: 8.47 [ 51/427] test_cgitb
0:08:53 load avg: 8.47 [ 52/427] test_charmapcodec
0:08:54 load avg: 8.47 [ 53/427] test_check_c_globals
/private/var/folders/wt/twzkdpd53g182wvx2s1n_6540000gn/T/tmp.kw3WJpEs/Tools/c-analyzer/c_common/tables.py:236: FutureWarning: Possible nested set at position 12
  _COLSPEC_RE = re.compile(textwrap.dedent(r'''
0:08:55 load avg: 7.87 [ 54/427] test_class
0:08:57 load avg: 7.87 [ 55/427] test_clinic
0:08:59 load avg: 7.87 [ 56/427] test_cmath
0:09:00 load avg: 7.40 [ 57/427] test_cmd
0:09:02 load avg: 7.40 [ 58/427] test_cmd_line
0:09:11 load avg: 6.65 [ 59/427] test_cmd_line_script
0:09:22 load avg: 6.00 [ 60/427] test_code
0:09:24 load avg: 6.00 [ 61/427] test_code_module
0:09:25 load avg: 5.84 [ 62/427] test_codeccallbacks
0:09:27 load avg: 5.84 [ 63/427] test_codecencodings_cn
0:09:29 load avg: 5.84 [ 64/427] test_codecencodings_hk
0:09:31 load avg: 5.70 [ 65/427] test_codecencodings_iso2022
0:09:33 load avg: 5.70 [ 66/427] test_codecencodings_jp
0:09:37 load avg: 5.48 [ 67/427] test_codecencodings_kr
0:09:39 load avg: 5.48 [ 68/427] test_codecencodings_tw
0:09:40 load avg: 5.28 [ 69/427] test_codecmaps_cn
0:09:42 load avg: 5.28 [ 70/427] test_codecmaps_hk
0:09:43 load avg: 5.28 [ 71/427] test_codecmaps_jp
0:09:45 load avg: 5.18 [ 72/427] test_codecmaps_kr
0:09:46 load avg: 5.18 [ 73/427] test_codecmaps_tw
0:09:48 load avg: 5.18 [ 74/427] test_codecs
0:09:54 load avg: 5.00 [ 75/427] test_codeop
0:09:56 load avg: 5.08 [ 76/427] test_collections
0:10:03 load avg: 5.00 [ 77/427] test_colorsys
0:10:05 load avg: 4.76 [ 78/427] test_compare
0:10:06 load avg: 4.76 [ 79/427] test_compile
0:10:19 load avg: 4.56 [ 80/427] test_compileall
0:10:58 load avg: 3.53 [ 81/427] test_complex -- test_compileall passed in 38.7 sec
0:11:00 load avg: 3.41 [ 82/427] test_concurrent_futures
0:14:26 load avg: 2.90 [ 83/427] test_configparser -- test_concurrent_futures passed in 3 min 26 sec
0:14:30 load avg: 2.82 [ 84/427] test_contains
0:14:31 load avg: 2.82 [ 85/427] test_context
0:14:38 load avg: 2.78 [ 86/427] test_contextlib
0:14:40 load avg: 2.78 [ 87/427] test_contextlib_async
Task was destroyed but it is pending!
task: <Task pending name='Task-4443' coro=<<async_generator_athrow without __name__>()>>
Task was destroyed but it is pending!
task: <Task pending name='Task-4445' coro=<<async_generator_athrow without __name__>()>>
Task was destroyed but it is pending!
task: <Task pending name='Task-4451' coro=<<async_generator_athrow without __name__>()>>
0:14:42 load avg: 2.78 [ 88/427] test_copy
0:14:43 load avg: 2.63 [ 89/427] test_copyreg
0:14:45 load avg: 2.63 [ 90/427] test_coroutines
0:14:49 load avg: 2.58 [ 91/427] test_cprofile
0:14:54 load avg: 2.54 [ 92/427] test_crashers
0:14:56 load avg: 2.54 [ 93/427] test_crypt
0:14:57 load avg: 2.54 [ 94/427] test_csv
0:15:09 load avg: 2.71 [ 95/427] test_ctypes
0:15:15 load avg: 2.65 [ 96/427] test_curses
test_curses skipped -- Use of the 'curses' resource not enabled
0:15:16 load avg: 2.65 [ 97/427] test_dataclasses -- test_curses skipped (resource denied)
0:15:19 load avg: 2.84 [ 98/427] test_datetime
0:15:33 load avg: 2.71 [ 99/427] test_dbm
0:15:35 load avg: 2.49 [100/427] test_dbm_dumb
0:15:38 load avg: 2.49 [101/427] test_dbm_gnu
0:15:40 load avg: 2.37 [102/427] test_dbm_ndbm
0:15:42 load avg: 2.37 [103/427] test_decimal
python.exe(37107,0x10189fe00) malloc: can't allocate region
:*** mach_vm_map(size=842105263157895168, flags: 100) failed (error code=3)
python.exe(37107,0x10189fe00) malloc: *** set a breakpoint in malloc_error_break to debug
python.exe(37107,0x10189fe00) malloc: can't allocate region
:*** mach_vm_map(size=842105263157895168, flags: 100) failed (error code=3)
python.exe(37107,0x10189fe00) malloc: *** set a breakpoint in malloc_error_break to debug
python.exe(37107,0x10189fe00) malloc: can't allocate region
:*** mach_vm_map(size=421052631578947584, flags: 100) failed (error code=3)
python.exe(37107,0x10189fe00) malloc: *** set a breakpoint in malloc_error_break to debug
python.exe(37107,0x10189fe00) malloc: can't allocate region
:*** mach_vm_map(size=421052631578947584, flags: 100) failed (error code=3)
python.exe(37107,0x10189fe00) malloc: *** set a breakpoint in malloc_error_break to debug
0:16:03 load avg: 2.19 [104/427] test_decorators
0:16:05 load avg: 2.25 [105/427] test_defaultdict
0:16:06 load avg: 2.25 [106/427] test_deque
0:16:25 load avg: 2.28 [107/427] test_descr
Fatal Python error: Segmentation fault

Current thread 0x000000010189fe00 (most recent call first):
  File "<frozen importlib._bootstrap>", line 306 in _module_repr
  File "/private/var/folders/wt/twzkdpd53g182wvx2s1n_6540000gn/T/tmp.kw3WJpEs/Lib/test/test_descr.py", line 3696 in test_uninitialized_modules
  File "/private/var/folders/wt/twzkdpd53g182wvx2s1n_6540000gn/T/tmp.kw3WJpEs/Lib/unittest/case.py", line 549 in _callTestMethod
  File "/private/var/folders/wt/twzkdpd53g182wvx2s1n_6540000gn/T/tmp.kw3WJpEs/Lib/unittest/case.py", line 592 in run
  File "/private/var/folders/wt/twzkdpd53g182wvx2s1n_6540000gn/T/tmp.kw3WJpEs/Lib/unittest/case.py", line 652 in __call__
  File "/private/var/folders/wt/twzkdpd53g182wvx2s1n_6540000gn/T/tmp.kw3WJpEs/Lib/unittest/suite.py", line 122 in run
  File "/private/var/folders/wt/twzkdpd53g182wvx2s1n_6540000gn/T/tmp.kw3WJpEs/Lib/unittest/suite.py", line 84 in __call__
  File "/private/var/folders/wt/twzkdpd53g182wvx2s1n_6540000gn/T/tmp.kw3WJpEs/Lib/unittest/suite.py", line 122 in run
  File "/private/var/folders/wt/twzkdpd53g182wvx2s1n_6540000gn/T/tmp.kw3WJpEs/Lib/unittest/suite.py", line 84 in __call__
  File "/private/var/folders/wt/twzkdpd53g182wvx2s1n_6540000gn/T/tmp.kw3WJpEs/Lib/test/support/testresult.py", line 169 in run
  File "/private/var/folders/wt/twzkdpd53g182wvx2s1n_6540000gn/T/tmp.kw3WJpEs/Lib/test/support/__init__.py", line 960 in _run_suite
  File "/private/var/folders/wt/twzkdpd53g182wvx2s1n_6540000gn/T/tmp.kw3WJpEs/Lib/test/support/__init__.py", line 1083 in run_unittest
  File "/private/var/folders/wt/twzkdpd53g182wvx2s1n_6540000gn/T/tmp.kw3WJpEs/Lib/test/test_descr.py", line 5734 in test_main
  File "/private/var/folders/wt/twzkdpd53g182wvx2s1n_6540000gn/T/tmp.kw3WJpEs/Lib/test/libregrtest/runtest.py", line 246 in _runtest_inner2
  File "/private/var/folders/wt/twzkdpd53g182wvx2s1n_6540000gn/T/tmp.kw3WJpEs/Lib/test/libregrtest/runtest.py", line 282 in _runtest_inner
  File "/private/var/folders/wt/twzkdpd53g182wvx2s1n_6540000gn/T/tmp.kw3WJpEs/Lib/test/libregrtest/runtest.py", line 154 in _runtest
  File "/private/var/folders/wt/twzkdpd53g182wvx2s1n_6540000gn/T/tmp.kw3WJpEs/Lib/test/libregrtest/runtest.py", line 194 in runtest
  File "/private/var/folders/wt/twzkdpd53g182wvx2s1n_6540000gn/T/tmp.kw3WJpEs/Lib/test/libregrtest/main.py", line 423 in run_tests_sequential
  File "/private/var/folders/wt/twzkdpd53g182wvx2s1n_6540000gn/T/tmp.kw3WJpEs/Lib/test/libregrtest/main.py", line 521 in run_tests
  File "/private/var/folders/wt/twzkdpd53g182wvx2s1n_6540000gn/T/tmp.kw3WJpEs/Lib/test/libregrtest/main.py", line 694 in _main
  File "/private/var/folders/wt/twzkdpd53g182wvx2s1n_6540000gn/T/tmp.kw3WJpEs/Lib/test/libregrtest/main.py", line 641 in main
  File "/private/var/folders/wt/twzkdpd53g182wvx2s1n_6540000gn/T/tmp.kw3WJpEs/Lib/test/libregrtest/main.py", line 719 in main
  File "/private/var/folders/wt/twzkdpd53g182wvx2s1n_6540000gn/T/tmp.kw3WJpEs/Lib/test/__main__.py", line 2 in <module>
  File "/private/var/folders/wt/twzkdpd53g182wvx2s1n_6540000gn/T/tmp.kw3WJpEs/Lib/runpy.py", line 86 in _run_code
  File "/private/var/folders/wt/twzkdpd53g182wvx2s1n_6540000gn/T/tmp.kw3WJpEs/Lib/runpy.py", line 196 in _run_module_as_main

Extension modules: _testcapi, _scproxy, _xxsubinterpreters, _testbuffer, _testinternalcapi, _ctypes_test, xxsubtype (total: 7)
[1]    37107 segmentation fault  ./python.exe -m test

----------
messages: 395754
nosy: jack__d
priority: normal
severity: normal
status: open
title: regrtests fail with segfault after failing calls to malloc

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

From report at bugs.python.org  Sun Jun 13 12:10:22 2021
From: report at bugs.python.org (Barney Gale)
Date: Sun, 13 Jun 2021 16:10:22 +0000
Subject: [New-bugs-announce] [issue44412] Add os.path.fileuri() function
Message-ID: <1623600622.48.0.298537036447.issue44412@roundup.psfhosted.org>


New submission from Barney Gale <barney.gale at gmail.com>:

Proposal:

- Introduce `os.path.fileuri()` function that produces a 'file://' URI
- Adjust `PurePosixPath.to_uri()` to call `posixpath.fileuri()`
- Adjust `PureWindowsPath.to_uri()` to call `ntpath.fileuri()`
- Adjust `nturl2path.pathname2url()` to call `ntpath.fileuri()`

Rationale:

- pathlib is 95% a wrapper around `os` and `os.path`. It implements
  little itself except the OOP interface. `as_uri()` is one of only a
  tiny handful of pathlib features that have no decent antecedents.
- the existence of these OS-specific features complicates pathlib's
  internals, necessitating the existence of OS-specific '_Flavour'
  classes that greatly complicate work on bpo-24132
- this is a useful feature with lots of stackoverflow posts. It seems
  silly to /require/ users to use pathlib for this, as the rest of their
  codebase may work just fine using traditional path manip.

Further discussion on python-ideas: https://discuss.python.org/t/pathlib-and-os-path-feature-parity-and-code-de-duplication/9239

Related: bpo-44403, bpo-44136, bpo-24132

----------
components: Library (Lib)
messages: 395756
nosy: barneygale
priority: normal
severity: normal
status: open
title: Add os.path.fileuri() function
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Sun Jun 13 14:02:13 2021
From: report at bugs.python.org (Vyacheslav)
Date: Sun, 13 Jun 2021 18:02:13 +0000
Subject: [New-bugs-announce] [issue44413] OverflowError: mktime argument out
 of range after 2019
Message-ID: <1623607333.16.0.709856027198.issue44413@roundup.psfhosted.org>


New submission from Vyacheslav <psijic at gmail.com>:

date_str = "2019-06-06 10:02:00"
    datetime_obj = datetime.strptime(date_str, "%Y-%m-%d %H:%M:%S")
    datetime_obj_utc1 = datetime_obj.replace(tzinfo=pytz.timezone("America/New_York"))
    datetime_obj_utc2 = pytz.timezone("America/New_York").localize(datetime_obj)
    print(datetime_obj_utc1, datetime_obj_utc2)
    ts1 = time.mktime(datetime_obj_utc1.timetuple())
    ts2 = time.mktime(datetime_obj_utc2.timetuple())

>>> Output:
    ts2 = int(time.mktime(datetime_obj_utc2.timetuple()))
OverflowError: mktime argument out of range


OS: Linux OpenSuse TW

----------
messages: 395758
nosy: psijic
priority: normal
severity: normal
status: open
title: OverflowError: mktime argument out of range after 2019
type: crash
versions: Python 3.8

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

From report at bugs.python.org  Sun Jun 13 17:20:30 2021
From: report at bugs.python.org (James Wilcox)
Date: Sun, 13 Jun 2021 21:20:30 +0000
Subject: [New-bugs-announce] [issue44414] from __future__ import annotations
 breaks profiler's handling of dataclasses
Message-ID: <1623619230.3.0.519841029097.issue44414@roundup.psfhosted.org>


New submission from James Wilcox <wilcoxjay at gmail.com>:

This program behaves differently when run under the profiler (either profile or cProfile) versus when run normally.

```
from __future__ import annotations  # ***
import dataclasses

@dataclasses.dataclass
class C:
    x: dataclasses.InitVar[int]

    def __post_init__(self, x):
        print(f'hello {x}')

C(0)
```

Save this as foo.py. Then

    python foo.py

prints

    hello 0

but

    python -m profile foo.py

results in the traceback

```
Traceback (most recent call last):
  File "/Users/jrw12/.pyenv/versions/3.9.5/lib/python3.9/runpy.py", line 197, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/Users/jrw12/.pyenv/versions/3.9.5/lib/python3.9/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/Users/jrw12/.pyenv/versions/3.9.5/lib/python3.9/profile.py", line 610, in <module>
    main()
  File "/Users/jrw12/.pyenv/versions/3.9.5/lib/python3.9/profile.py", line 599, in main
    runctx(code, globs, None, options.outfile, options.sort)
  File "/Users/jrw12/.pyenv/versions/3.9.5/lib/python3.9/profile.py", line 99, in runctx
    return _Utils(Profile).runctx(statement, globals, locals, filename, sort)
  File "/Users/jrw12/.pyenv/versions/3.9.5/lib/python3.9/profile.py", line 62, in runctx
    prof.runctx(statement, globals, locals)
  File "/Users/jrw12/.pyenv/versions/3.9.5/lib/python3.9/profile.py", line 422, in runctx
    exec(cmd, globals, locals)
  File "foo.py", line 11, in <module>
    C(0)
  File "<string>", line 4, in __init__
TypeError: __post_init__() missing 1 required positional argument: 'x'
```

A similar traceback occurs if using `-m cProfile` instead of `-m profile`.

No such traceback occurs if the `from future import __annotations__` is removed from the file.

Possibly related to #39442.

----------
components: Library (Lib)
messages: 395762
nosy: wilcoxjay
priority: normal
severity: normal
status: open
title: from __future__ import annotations breaks profiler's handling of dataclasses
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Mon Jun 14 00:36:52 2021
From: report at bugs.python.org (Rajeev Chaurasia)
Date: Mon, 14 Jun 2021 04:36:52 +0000
Subject: [New-bugs-announce] [issue44415] sys.stdout.flush and print()
 hanging
Message-ID: <1623645412.68.0.708640835339.issue44415@roundup.psfhosted.org>


New submission from Rajeev Chaurasia <rajeevsgsits at gmail.com>:

I am running an application using cronjob. This application runs on Linux(X86_64) platform where inside a loop we have print() and sys.stdout.flush() statements. This loop iterates around 500 times and after the loop we have few more sys.stdout.flush() and print() statements. 

When I am running same application on terminal (without cronjob) then it is working fine.

Inside the loop everything is working fine but application is hanging after the loop. I put some debug statements and I found it is hanging on print() and sys.stdout.flush().


Code logic:-

for x in range(500):
  print(x)
  print ("something")
  sys.stdout.flush()
self.logger.info("A")
sys.stdout.flush()     #1 
self.logger.info("B")
print ("Hello")        #2
self.logger.info("C")
print ("Bye")          #3
self.logger.info("D")
-----------------------------------------
"A" is getting printed in log file and nothing after that but-
If I comment #1 then I get "B" as well in the log file.
If I comment #2 then I get "C" as well in the log file
If I comment #3 then I get "D" as well in the log file.

-----------------------------------------
ps results-
[root at scao05adm07 ~]# ps -ef|grep exachk
root     239265  98963  0 Jun11 ?        00:00:00 sh /opt/oracle.ahf/bin/exachk -silentforce -showpass -dball -nocvu -autorun_id DEFAULT
root     239706 239265  0 Jun11 ?        00:00:35 /opt/oracle.ahf/python/bin/python /opt/oracle.ahf/exachk/exachk.py -silentforce -showpass -dball -nocvu -autorun_id DEFAULT
root     277938 239706  0 Jun11 ?        00:00:00 sh /opt/oracle.ahf/exachk/exachk -silentforce -showpass -dball -nocvu -autorun_id DEFAULT -localonly -sudo_remoterun 0
root     278989 277938  0 Jun11 ?        00:12:26 /opt/oracle.ahf/python/bin/python /opt/oracle.ahf/exachk/exachk.py -silentforce -showpass -dball -nocvu -autorun_id DEFAULT -localonly -sudo_remoterun 0
root     281983 278989  0 Jun11 ?        00:00:27 /opt/oracle.ahf/python/bin/python /opt/oracle.ahf/exachk/exachk.py -silentforce -showpass -dball -nocvu -autorun_id DEFAULT -localonly -sudo_remoterun 0

-----------------------------------------
# uname -a
Linux ************ 4.14.35-1902.306.2.2.el7uek.x86_64 #2 SMP Thu Nov 19 18:09:09 PST 2020 x86_64 x86_64 x86_64 GNU/Linux
-----------------------------------------
I believe this issue is related to standard output buffer but I am not able to find a fix for it.

Please help.
-Rajeev

----------
components: Library (Lib)
messages: 395772
nosy: rajeevkchaurasia
priority: normal
severity: normal
status: open
title: sys.stdout.flush and print() hanging
versions: Python 3.8

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

From report at bugs.python.org  Mon Jun 14 03:36:56 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jun 2021 07:36:56 +0000
Subject: [New-bugs-announce] [issue44416] test_threading:
 test_print_exception() hangs and killed after 3h15
Message-ID: <1623656216.7.0.491497742026.issue44416@roundup.psfhosted.org>


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

AMD64 Windows8.1 Refleaks 3.9:
https://buildbot.python.org/all/#/builders/6/builds/48

4:03:35 load avg: 3.98 [425/425/1] test_threading crashed (Exit code 1)
beginning 6 repetitions
123456
Timeout (3:15:00)!
Thread 0x00000748 (most recent call first):
  File "D:\buildarea\3.9.ware-win81-release.refleak\build\lib\subprocess.py", line 1479 in _readerthread
  File "D:\buildarea\3.9.ware-win81-release.refleak\build\lib\threading.py", line 907 in run
  File "D:\buildarea\3.9.ware-win81-release.refleak\build\lib\threading.py", line 970 in _bootstrap_inner
  File "D:\buildarea\3.9.ware-win81-release.refleak\build\lib\threading.py", line 927 in _bootstrap

Thread 0x00001138 (most recent call first):
  File "D:\buildarea\3.9.ware-win81-release.refleak\build\lib\subprocess.py", line 1479 in _readerthread
  File "D:\buildarea\3.9.ware-win81-release.refleak\build\lib\threading.py", line 907 in run
  File "D:\buildarea\3.9.ware-win81-release.refleak\build\lib\threading.py", line 970 in _bootstrap_inner
  File "D:\buildarea\3.9.ware-win81-release.refleak\build\lib\threading.py", line 927 in _bootstrap

Thread 0x00000b80 (most recent call first):
  File "D:\buildarea\3.9.ware-win81-release.refleak\build\lib\threading.py", line 1066 in _wait_for_tstate_lock
  File "D:\buildarea\3.9.ware-win81-release.refleak\build\lib\threading.py", line 1050 in join
  File "D:\buildarea\3.9.ware-win81-release.refleak\build\lib\subprocess.py", line 1508 in _communicate
  File "D:\buildarea\3.9.ware-win81-release.refleak\build\lib\subprocess.py", line 1134 in communicate
  File "D:\buildarea\3.9.ware-win81-release.refleak\build\lib\test\support\script_helper.py", line 132 in run_python_until_end
  File "D:\buildarea\3.9.ware-win81-release.refleak\build\lib\test\support\script_helper.py", line 140 in _assert_python
  File "D:\buildarea\3.9.ware-win81-release.refleak\build\lib\test\support\script_helper.py", line 156 in assert_python_ok
  File "D:\buildarea\3.9.ware-win81-release.refleak\build\lib\test\test_threading.py", line 1164 in test_print_exception
  ...

The test runs a subprocess, the logs don't say where the child process was stuck:

    def test_print_exception(self):
        script = r"""if True:
            import threading
            import time

            running = False
            def run():
                global running
                running = True
                while running:
                    time.sleep(0.01)
                1/0
            t = threading.Thread(target=run)
            t.start()
            while not running:
                time.sleep(0.01)
            running = False
            t.join()
            """
        rc, out, err = assert_python_ok("-c", script)
        self.assertEqual(out, b'')
        err = err.decode()
        self.assertIn("Exception in thread", err)
        self.assertIn("Traceback (most recent call last):", err)
        self.assertIn("ZeroDivisionError", err)
        self.assertNotIn("Unhandled exception", err)

Note: using a "busy loop" to (1) waits until the thread starts (2) waits until the thread is requested to stop, is not an effecient way to synchonize. One two threading.Event would be better.

----------
components: Tests
messages: 395779
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_threading: test_print_exception() hangs and killed after 3h15
versions: Python 3.9

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

From report at bugs.python.org  Mon Jun 14 06:09:16 2021
From: report at bugs.python.org (Gabriele N Tornetta)
Date: Mon, 14 Jun 2021 10:09:16 +0000
Subject: [New-bugs-announce] [issue44417] bytecode<>line number mapping
 seems wrong in 3.10.0b2
Message-ID: <1623665356.44.0.686515764926.issue44417@roundup.psfhosted.org>


New submission from Gabriele N Tornetta <phoenix1987 at gmail.com>:

I was looking at how the new co_linetable works in order to add initial support for Python 3.10 to Austin (https://github.com/P403n1x87/austin) when I stumbled upon the following interesting output from the dis module. I am using the following test target:

https://github.com/P403n1x87/austin/blob/master/test/target34.py

When I call python3.10 -m dis target34.py using Python 3.10.0b2 I get

----

 25           0 LOAD_CONST               0 (0)
              2 LOAD_CONST               1 (None)
              4 IMPORT_NAME              0 (threading)
              6 STORE_NAME               0 (threading)

 28           8 LOAD_CONST               2 (<code object keep_cpu_busy at 0x7fb7cd750870, file "target34.py", line 28>)
             10 LOAD_CONST               3 ('keep_cpu_busy')
             12 MAKE_FUNCTION            0
             14 STORE_NAME               1 (keep_cpu_busy)

 36          16 LOAD_NAME                2 (__name__)
             18 LOAD_CONST               4 ('__main__')
             20 COMPARE_OP               2 (==)
             22 POP_JUMP_IF_FALSE       25 (to 50)

 37          24 LOAD_NAME                0 (threading)
             26 LOAD_ATTR                3 (Thread)
             28 LOAD_NAME                1 (keep_cpu_busy)
             30 LOAD_CONST               5 (('target',))
             32 CALL_FUNCTION_KW         1
             34 LOAD_METHOD              4 (start)
             36 CALL_METHOD              0
             38 POP_TOP

 38          40 LOAD_NAME                1 (keep_cpu_busy)
             42 CALL_FUNCTION            0
             44 POP_TOP
             46 LOAD_CONST               1 (None)
             48 RETURN_VALUE

 36     >>   50 LOAD_CONST               1 (None)
             52 RETURN_VALUE

Disassembly of <code object keep_cpu_busy at 0x7fb7cd750870, file "target34.py", line 28>:
 29           0 BUILD_LIST               0
              2 STORE_FAST               0 (a)

 30           4 LOAD_GLOBAL              0 (range)
              6 LOAD_CONST               1 (2000000)
              8 CALL_FUNCTION            1
             10 GET_ITER
        >>   12 FOR_ITER                21 (to 56)
             14 STORE_FAST               1 (i)

 31          16 LOAD_FAST                0 (a)
             18 LOAD_METHOD              1 (append)
             20 LOAD_FAST                1 (i)
             22 CALL_METHOD              1
             24 POP_TOP

 32          26 LOAD_FAST                1 (i)
             28 LOAD_CONST               2 (1000000)
             30 BINARY_MODULO
             32 LOAD_CONST               3 (0)
             34 COMPARE_OP               2 (==)
             36 POP_JUMP_IF_FALSE       27 (to 54)

 33          38 LOAD_GLOBAL              2 (print)
             40 LOAD_CONST               4 ('Unwanted output ')
             42 LOAD_GLOBAL              3 (str)
             44 LOAD_FAST                1 (i)
             46 CALL_FUNCTION            1
             48 BINARY_ADD
             50 CALL_FUNCTION            1
             52 POP_TOP
        >>   54 JUMP_ABSOLUTE            6 (to 12)

 30     >>   56 LOAD_CONST               0 (None)
             58 RETURN_VALUE

----

Note how the line number is not monotonic. Compare this to the output generated by Python 3.9.5

----
 25           0 LOAD_CONST               0 (0)
              2 LOAD_CONST               1 (None)
              4 IMPORT_NAME              0 (threading)
              6 STORE_NAME               0 (threading)

 28           8 LOAD_CONST               2 (<code object keep_cpu_busy at 0x7fa9c539cb30, file "target34.py", line 28>)
             10 LOAD_CONST               3 ('keep_cpu_busy')
             12 MAKE_FUNCTION            0
             14 STORE_NAME               1 (keep_cpu_busy)

 36          16 LOAD_NAME                2 (__name__)
             18 LOAD_CONST               4 ('__main__')
             20 COMPARE_OP               2 (==)
             22 POP_JUMP_IF_FALSE       46

 37          24 LOAD_NAME                0 (threading)
             26 LOAD_ATTR                3 (Thread)
             28 LOAD_NAME                1 (keep_cpu_busy)
             30 LOAD_CONST               5 (('target',))
             32 CALL_FUNCTION_KW         1
             34 LOAD_METHOD              4 (start)
             36 CALL_METHOD              0
             38 POP_TOP

 38          40 LOAD_NAME                1 (keep_cpu_busy)
             42 CALL_FUNCTION            0
             44 POP_TOP
        >>   46 LOAD_CONST               1 (None)
             48 RETURN_VALUE

Disassembly of <code object keep_cpu_busy at 0x7fa9c539cb30, file "target34.py", line 28>:
 29           0 BUILD_LIST               0
              2 STORE_FAST               0 (a)

 30           4 LOAD_GLOBAL              0 (range)
              6 LOAD_CONST               1 (2000000)
              8 CALL_FUNCTION            1
             10 GET_ITER
        >>   12 FOR_ITER                42 (to 56)
             14 STORE_FAST               1 (i)

 31          16 LOAD_FAST                0 (a)
             18 LOAD_METHOD              1 (append)
             20 LOAD_FAST                1 (i)
             22 CALL_METHOD              1
             24 POP_TOP

 32          26 LOAD_FAST                1 (i)
             28 LOAD_CONST               2 (1000000)
             30 BINARY_MODULO
             32 LOAD_CONST               3 (0)
             34 COMPARE_OP               2 (==)
             36 POP_JUMP_IF_FALSE       12

 33          38 LOAD_GLOBAL              2 (print)
             40 LOAD_CONST               4 ('Unwanted output ')
             42 LOAD_GLOBAL              3 (str)
             44 LOAD_FAST                1 (i)
             46 CALL_FUNCTION            1
             48 BINARY_ADD
             50 CALL_FUNCTION            1
             52 POP_TOP
             54 JUMP_ABSOLUTE           12
        >>   56 LOAD_CONST               0 (None)
             58 RETURN_VALUE
----

This problem seems to get reflected in the output generated by Austin. With Python 3.9 I do get the expected traceback:

P1539;T1539;/mnt/c/Users/Gabriele/Projects/austin/test/target34.py:<module>:38;/mnt/c/Users/Gabriele/Projects/austin/test/target34.py:keep_cpu_busy:32 101003

(note the correct path <module>:38 => keep_cpu_busy:32)

but with Python 3.10.0b2 I do get

P2064;T2064;/mnt/c/Users/Gabriele/Projects/austin/test/target34.py:<module>:36;/mnt/c/Users/Gabriele/Projects/austin/test/target34.py:keep_cpu_busy:32 100511

which is incorrect. What seems to be off is the value of the f_lasti field. The computation that I'm performing to map bytecode to line number produces the following "[start, end) => line number" triplets (the computation stops as soon as end > lasti):

<module> (lasti = 21)
  [0, 8) => 25
  [8, 16) => 28
  [16, 24) => 36

The computations within the code object for the keep_cpu_busy function look fine:

keep_cpu_busy (lasti = 27)
  [0, 4) => 29
  [4, 16) => 30
  [16, 26) => 31
  [26, 38) => 32

----------
components: C API
messages: 395787
nosy: Gabriele Tornetta
priority: normal
severity: normal
status: open
title: bytecode<>line number mapping seems wrong in 3.10.0b2
versions: Python 3.10

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

From report at bugs.python.org  Mon Jun 14 08:21:13 2021
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Mon, 14 Jun 2021 12:21:13 +0000
Subject: [New-bugs-announce] [issue44418] unicodedata.ucnhash_CAPI removed
 from Python 3.10 without deprecation
Message-ID: <1623673273.47.0.342389136094.issue44418@roundup.psfhosted.org>


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

In bpo-42157, the unicodedata.ucnhash_CAPI attribute was removed without deprecation. This breaks at least https://github.com/dgrunwald/rust-cpython with:

    AttributeError: module 'unicodedata' has no attribute 'ucnhash_CAPI'

Please revert the removal and deprecate the attribute for 2 Python releases if you want to remove it.

Thanks

----------
components: Library (Lib)
messages: 395792
nosy: hroncok, vstinner
priority: normal
severity: normal
status: open
title: unicodedata.ucnhash_CAPI removed from Python 3.10 without deprecation
type: behavior
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Mon Jun 14 10:04:18 2021
From: report at bugs.python.org (Abbas Baharforoosh)
Date: Mon, 14 Jun 2021 14:04:18 +0000
Subject: [New-bugs-announce] [issue44419] Wrong division calculation for
 numbers more than 16 digits
Message-ID: <1623679458.04.0.92278906874.issue44419@roundup.psfhosted.org>


New submission from Abbas Baharforoosh <abahar1996 at gmail.com>:

Hi
For big numbers (more than about 16 digits), python wrong calculate division, but calculating mod (%) is correct.

I write a sample code of manual division in file.

Thanks

----------
files: big_number.py
messages: 395798
nosy: abahar1996
priority: normal
severity: normal
status: open
title: Wrong division calculation for numbers more than 16 digits
versions: Python 3.9
Added file: https://bugs.python.org/file50108/big_number.py

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

From report at bugs.python.org  Mon Jun 14 14:00:51 2021
From: report at bugs.python.org (Douglas Thor)
Date: Mon, 14 Jun 2021 18:00:51 +0000
Subject: [New-bugs-announce] [issue44420] Add CapWords classes to datetime
 module?
Message-ID: <1623693651.24.0.820963890692.issue44420@roundup.psfhosted.org>


New submission from Douglas Thor <doug.thor at gmail.com>:

Has there been any discussion on adding CapWords class names to the datetime.py module?

I searched through the bug tracker ("CapWords" and "CamelCase") and didn't find anything, but perhaps I'm not searching for the correct keywords.

Eg:

```
# datetime.py
class datetime:
    ...

class tzinfo:
    ...

...

DateTime = datetime
TzInfo = tzinfo
TimeZone = timezone
TimeDelta = timedelta
...
```


I'd imaging implementing this would be pretty trivial and wouldn't break any existing functionality. I'd be happy to implement it.


Benefits:
+ Starts down the road to naming conventions found in pep8.
+ Maybe makes discovery easier for new users? It can be confusing for new users when the same word "datetime" can refer to either a class or a module.
+ Can start a deprecation process for the all-lowercase class names if so desired (actually doing so is outside the scope of this discussion)
+ Makes it easy, at a glance, to tell if code is referring to `datetime` the module or `DateTime` the class.


Downsides:
- fragments future usage: there will be a split between people using `DateTime` and `datetime`. This makes it hard to do things like mass grep over codebase.
- "If it ain't broke, don't fix it"
- ???

----------
components: Library (Lib)
messages: 395830
nosy: dougthor42
priority: normal
severity: normal
status: open
title: Add CapWords classes to datetime module?
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/issue44420>
_______________________________________

From report at bugs.python.org  Mon Jun 14 14:47:03 2021
From: report at bugs.python.org (Christian Kleineidam)
Date: Mon, 14 Jun 2021 18:47:03 +0000
Subject: [New-bugs-announce] [issue44421] random.uniform() hangs will eating
 up all available RAM
Message-ID: <1623696423.1.0.630569105584.issue44421@roundup.psfhosted.org>


New submission from Christian Kleineidam <christian.kleineidam at gmail.com>:

I'm writing a model that needs a lot of random numbers. The model counts up to "Year:640: Count:1339" (taking around two minutes) and then hangs on random.uniform(0, 1). While it hangs, the amount of RAM python takes grows till it eats up all available RAM with RAM usage growing by around 100 MB per second.

I'm running Windows 10 and the error appears in both Python 3.8.8 as well as in 3.9.5. I'm attaching a file that reproduces the error. 

File "C:\Users\Christian\folder\obfuscated.py", line 427, in <module>
    population = population.next()

  File "C:\Users\Christian\folder\obfuscated.py", line 385, in next
    return Class4(self.nextClass4)

  File "C:\Users\Christian\folder\obfuscated.py", line 280, in __init__
    var42.var30()

  File "C:\Users\Christian\folder\obfuscated.py", line 177, in var30
    var22.var30(self.var17,self.var18,self.var21)

  File "C:\Users\Christian\folder\obfuscated.py", line 100, in var30
    self.barClass1s.append(var23.child())

  File "C:\Users\Christian\folder\obfuscated.py", line 29, in child
    if var6>random.uniform(0, 1):

  File "C:\Progs\anaconda3\lib\random.py", line 417, in uniform
    return a + (b-a) * self.random()

----------
components: Library (Lib)
files: obfuscated.py
messages: 395836
nosy: Christian.Kleineidam
priority: normal
severity: normal
status: open
title: random.uniform() hangs will eating up all available RAM
versions: Python 3.9
Added file: https://bugs.python.org/file50109/obfuscated.py

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

From report at bugs.python.org  Mon Jun 14 17:26:28 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jun 2021 21:26:28 +0000
Subject: [New-bugs-announce] [issue44422] threading.enumerate(): reentrant
 call during a GC collection hangs
Message-ID: <1623705988.63.0.204635618533.issue44422@roundup.psfhosted.org>


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

The threading.enumerate() code is simple:
---
# Active thread administration
_active_limbo_lock = _allocate_lock()
_active = {}    # maps thread id to Thread object
_limbo = {}

def enumerate():
    with _active_limbo_lock:
        return list(_active.values()) + list(_limbo.values())
---

values(), list() and list+list operations can call trigger a GC collection depending on the GC thresholds, created Python objects, etc.

During a GC collection, a Python object destructor (__del__) can again call threading.enumerate().

Problem: _active_limbo_lock is not re-entrant lock and so the second call hangs.

In practice, this issue was seen in OpenStack which uses eventlet, when a destructor uses the logging module. The logging module uses threading.current_thread(), but this function is monkey-patched by the eventlet module.

Extract of the eventlet function:
---
def current_thread():
    ...
    found = [th for th in __patched_enumerate() if th.ident == g_id]
    ...
---
https://github.com/eventlet/eventlet/blob/master/eventlet/green/threading.py

Attached PR makes _active_limbo_lock re-entrant to avoid this issue. I'm not sure if it's ok or not, I would appreciate to get a review and your feedback ;-)

Attached file triggers the threading.enumerate() hang on re-entrant call.

----------
components: Library (Lib)
files: rec_threading.py
messages: 395851
nosy: vstinner
priority: normal
severity: normal
status: open
title: threading.enumerate(): reentrant call during a GC collection hangs
versions: Python 3.10, Python 3.11, Python 3.9
Added file: https://bugs.python.org/file50110/rec_threading.py

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

From report at bugs.python.org  Tue Jun 15 01:52:25 2021
From: report at bugs.python.org (karl)
Date: Tue, 15 Jun 2021 05:52:25 +0000
Subject: [New-bugs-announce] [issue44423] copy2 / sendfile fails on linux
 with large file
Message-ID: <1623736345.91.0.29501439742.issue44423@roundup.psfhosted.org>


New submission from karl <k.r.goger+github at gmail.com>:

by copy a large file e.g.

-rwxrwxr-x 1 1002 1001 5359338160 Feb  9  2019 xxx_file_xxx.mdx

copy2 / sendfile / fastcopy fails with:


Traceback (most recent call last):
  File "/usr/lib/python3.8/multiprocessing/pool.py", line 125, in worker
    result = (True, func(*args, **kwds))
  File "/usr/lib/python3.8/multiprocessing/pool.py", line 48, in mapstar
    return list(map(*args))
  File "/usr/local/lib/python3.8/dist-packages/pybcpy/diff_bak_copy.py", line 212, in _init_copy_single
    shutil.copy2(f, dest_path)
  File "/usr/lib/python3.8/shutil.py", line 432, in copy2
    copyfile(src, dst, follow_symlinks=follow_symlinks)
  File "/usr/lib/python3.8/shutil.py", line 272, in copyfile
    _fastcopy_sendfile(fsrc, fdst)
  File "/usr/lib/python3.8/shutil.py", line 169, in _fastcopy_sendfile
    raise err
  File "/usr/lib/python3.8/shutil.py", line 149, in _fastcopy_sendfile
    sent = os.sendfile(outfd, infd, offset, blocksize)
OSError: [Errno 75] Value too large for defined data type: 'xxx_file_xxx.mdx' -> 'dest/xxx_file_xxx.mdx'
"""

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/lib/python3.8/runpy.py", line 194, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/lib/python3.8/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/usr/local/lib/python3.8/dist-packages/pybcpy/__main__.py", line 433, in <module>
    main_func()
  File "/usr/local/lib/python3.8/dist-packages/pybcpy/__main__.py", line 425, in main_func
    args.func(args)
  File "/usr/local/lib/python3.8/dist-packages/pybcpy/__main__.py", line 75, in cmd_init
    ) = dbak.init_backup_repo(tarmode=args.tar)
  File "/usr/local/lib/python3.8/dist-packages/pybcpy/diff_bak_copy.py", line 231, in init_backup_repo
    files = p.map(self._init_copy_single, ifiles)
  File "/usr/lib/python3.8/multiprocessing/pool.py", line 364, in map
    return self._map_async(func, iterable, mapstar, chunksize).get()
  File "/usr/lib/python3.8/multiprocessing/pool.py", line 771, in get
    raise self._value
OSError: [Errno 75] Value too large for defined data type: 'xxx_file_xxx.mdx' -> 'dest/xxx_file_xxx.mdx'


reference to code:
https://github.com/kr-g/pybcpy/blob/master/pybcpy/diff_bak_copy.py

----------
messages: 395862
nosy: kr-g
priority: normal
severity: normal
status: open
title: copy2 / sendfile fails on linux with large file
type: crash
versions: Python 3.8

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

From report at bugs.python.org  Tue Jun 15 06:25:57 2021
From: report at bugs.python.org (Carlos Franzreb)
Date: Tue, 15 Jun 2021 10:25:57 +0000
Subject: [New-bugs-announce] [issue44424] Decompress streaming bz2 file
Message-ID: <1623752757.23.0.263493527636.issue44424@roundup.psfhosted.org>


Change by Carlos Franzreb <carlosfranzreb at gmail.com>:


----------
components: Library (Lib)
nosy: carlosfranzreb
priority: normal
severity: normal
status: open
title: Decompress streaming bz2 file
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Tue Jun 15 06:27:55 2021
From: report at bugs.python.org (Mark Final)
Date: Tue, 15 Jun 2021 10:27:55 +0000
Subject: [New-bugs-announce] [issue44425] 'dirty' added to sys.version on
 Linux and Mac source builds depending on git version
Message-ID: <1623752875.9.0.718456041412.issue44425@roundup.psfhosted.org>


New submission from Mark Final <mark.final at foundry.com>:

Hi,

We build Python 3.7 from source in-house for Windows, Linux and macOSX.

It's been noticed that 'dirty' has been appended to sys.version in our builds, even though the source tree has not been modified from a git clone. This only happens for Linux and macOSX.

I traced this to the following commands (which are unchanged in main):

https://github.com/python/cpython/blob/main/configure#L2833
https://github.com/python/cpython/blob/main/configure.ac#L50

> GITTAG="git --git-dir \$(srcdir)/.git describe --all --always --dirty"

I further traced it to behaviours of different versions of git. In particular, when git is invoked outside of the working tree, and --git-dir is used alone, 'dirty' is always appended.

It's been noticed in a number of places online, including https://www.reddit.com/r/git/comments/4edtlx/git_describe_in_makefile_always_dirty/

Additionally using --work-tree does avoid the 'dirty' flag for a clean source tree, for git v2.21.0+.

I believe that this was this fix https://github.com/git/git/commit/a1e19004e11dcbc0ceebd92c425ceb1770e52d0b

However, since we do have usage of older versions of git, we've had to go with a different solution, which was to use git -C, i.e.

GITTAG="git -C \$(srcdir) describe --all --always --dirty"

so that git's working directory is changed to $(srcdir).

The other git commands in the code linked to do not seem to have the same issue, but we haven't changed them.

I'm writing this up in case anyone else has seen the issue, and offer the solution we found if it is useful.

Many thanks,
Mark

----------
components: Build
messages: 395866
nosy: mark.final
priority: normal
severity: normal
status: open
title: 'dirty' added to sys.version on Linux and Mac source builds depending on git version
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Tue Jun 15 08:42:29 2021
From: report at bugs.python.org (Karolina Surma)
Date: Tue, 15 Jun 2021 12:42:29 +0000
Subject: [New-bugs-announce] [issue44426] Docs fail to build with Sphinx 4
 due to Invalid C declaration
Message-ID: <1623760949.4.0.2341930076.issue44426@roundup.psfhosted.org>


New submission from Karolina Surma <warumnicht at tutanota.com>:

Hello all,
I want to build Python 3.10~b2 documentation using Sphinx 4.0.2 (released in May 2021) as RPM in Fedora with aim to ship it in Fedora 35.

The build fails with the following error:

Warning, treated as error:
/builddir/build/BUILD/Python-3.10.0b2/Doc/c-api/complex.rst:49:Error in declarator or parameters
Error in declarator or parameters
Invalid C declaration: Expected identifier, got keyword: complex [error at 39]
  Py_complex _Py_c_neg(Py_complex complex)
  ---------------------------------------^
make: *** [Makefile:51: build] Error 2


The Sphinx changelog mentions in Bug fixes in https://www.sphinx-doc.org/en/master/changes.html#id21 the likely cause:
C, properly reject function declarations when a keyword is used as parameter name.

----------
assignee: docs at python
components: Documentation
messages: 395874
nosy: docs at python, ksurma
priority: normal
severity: normal
status: open
title: Docs fail to build with Sphinx 4 due to Invalid C declaration
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Tue Jun 15 08:46:03 2021
From: report at bugs.python.org (Malte Kliemann)
Date: Tue, 15 Jun 2021 12:46:03 +0000
Subject: [New-bugs-announce] [issue44427] File extension for scripts on
 windows is unclear
Message-ID: <1623761163.14.0.147390138108.issue44427@roundup.psfhosted.org>


New submission from Malte Kliemann <mail at maltekliemann.com>:

It is common practice to use no extension for python scripts on UNIX. In 3.8.1.4., it is hinted that a script with a shebang line can be executed on windows only if the file extension of the script is associated with the python launcher.

I'm not sure where the right place is, but I suggest clearly stating that this is a critical requirement. As scripts on UNIX usually don't use file extensions, using these scripts without further modification is not possible cross-platform.

----------
assignee: docs at python
components: Documentation
messages: 395875
nosy: docs at python, maltekliemann
priority: normal
severity: normal
status: open
title: File extension for scripts on windows is unclear
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Tue Jun 15 17:00:19 2021
From: report at bugs.python.org (Thomas Grainger)
Date: Tue, 15 Jun 2021 21:00:19 +0000
Subject: [New-bugs-announce] [issue44428] _ProactorBasePipeTransport.abort()
 after _ProactorBasePipeTransport.close() does not cancel writes
Message-ID: <1623790819.66.0.954991188371.issue44428@roundup.psfhosted.org>


New submission from Thomas Grainger <tagrain at gmail.com>:

demo program:

import asyncio
import socket
import threading

async def amain():
    family = socket.AddressFamily.AF_INET
    sock = socket.socket(family, socket.SOCK_STREAM)
    sock.settimeout(1)
    sock.bind(('localhost', 0))
    sock.listen()
    host, port = sock.getsockname()[:2]

    event = threading.Event()

    def serve():
        client, _ = sock.accept()
        with client:
            client.recv(1)
            event.wait()

    t = threading.Thread(target=serve, daemon=True)
    t.start()

    reader, writer = await asyncio.open_connection(host=host, port=port)
    try:
        while True:
            writer.write(b"\x00" * 4096 * 682 * 2)
            await asyncio.wait_for(writer.drain(), 2)
            print("wrote")
    except asyncio.TimeoutError:
        print("timed out")

    writer.close()
    await asyncio.sleep(0)
    writer.transport.abort()
    print("waiting close")
    await writer.wait_closed()  # never finishes on ProactorEventLoop
    print("closed")
    event.set()
    t.join()

asyncio.run(amain())

it looks like it was fixed for the selector eventloop in https://github.com/python/cpython/commit/2546a177650264205e8a52b6836bc5b8c48bf085

but not for the proactor https://github.com/python/cpython/blame/8fe57aacc7bf9d9af84803b69dbb1d66597934c6/Lib/asyncio/proactor_events.py#L140

----------
components: asyncio
messages: 395896
nosy: asvetlov, graingert, yselivanov
priority: normal
severity: normal
status: open
title: _ProactorBasePipeTransport.abort() after _ProactorBasePipeTransport.close() does not cancel writes
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Jun 15 19:09:33 2021
From: report at bugs.python.org (Gary Davenport)
Date: Tue, 15 Jun 2021 23:09:33 +0000
Subject: [New-bugs-announce] [issue44429] Tkinter Flow Geometry Manager
Message-ID: <1623798573.21.0.50454331855.issue44429@roundup.psfhosted.org>


New submission from Gary Davenport <garydavenport73 at gmail.com>:

Hi there.  I love Python and Tkinter.  I know that there are geometry managers pack, place, and grid.  I think there should be a flow type management available, like what is done in Java or html/css.  This is more important as responsive GUI design is needed with different screen sizes.

I initially addressed this by inheriting from the Frame in tkinter to a 'FlowFrame' object and anything in that Frame would have flow geometry.

But this is a little awkward because the syntax is widget.pack() or widget.grid(), etc, so the method is linked to the widget.

So I altered the tkinter __init__.py  wrapper to add the .flow method so you can use widget.flow() syntax.

The flow geometry manager uses the grid managers methods.

The changes are straight-forward and I have 3 related projects on github:

1) https://github.com/garydavenport73/tkinterFlow - 
there are only 2 versions so history will demonstrate the relatively simple changes.

2) https://github.com/garydavenport73/FlowFrame -
a related project, FlowFrame object

3) https://github.com/garydavenport73/cpython
the formal changes to the most recent

https://github.com/python/cpython/blob/3.9/Lib/tkinter/__init__.py file.

----------
components: Tkinter
hgrepos: 405
messages: 395900
nosy: Gary73
priority: normal
severity: normal
status: open
title: Tkinter Flow Geometry Manager
versions: Python 3.9

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

From report at bugs.python.org  Tue Jun 15 19:22:29 2021
From: report at bugs.python.org (Erlend E. Aasland)
Date: Tue, 15 Jun 2021 23:22:29 +0000
Subject: [New-bugs-announce] [issue44430] [sqlite3] refactor threading tests
Message-ID: <1623799349.31.0.598300171565.issue44430@roundup.psfhosted.org>


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

The threading tests (ThreadTests) in Lib/sqlite3/test/dbapi.py has a lot of code duplication, and none of the test methods use the test.support.threading_helper.reap_threads helper. Also, some branches are not covered by this test class. Suggesting the following:

1. Rewrite ThreadTests with a _run_test() helper method that does the heavy lifting
2. Add test.support.threading_helper.reap_threads to _run_test()
3. Use _run_test() in all threading tests
4. Add test case for sqlite3.Connection.set_trace_callback
5. Add test case for sqlite3.Connection.create_collation

----------
assignee: erlendaasland
components: Tests
messages: 395901
nosy: erlendaasland, pablogsal
priority: low
severity: normal
status: open
title: [sqlite3] refactor threading tests
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Wed Jun 16 00:14:46 2021
From: report at bugs.python.org (Eric Phenix)
Date: Wed, 16 Jun 2021 04:14:46 +0000
Subject: [New-bugs-announce] [issue44431] Add command-line functionality to
 uuid module
Message-ID: <1623816886.43.0.954667545648.issue44431@roundup.psfhosted.org>


New submission from Eric Phenix <python at ericphenix.com>:

Suggested functionality:

> python -m uuid
> b9aa5a06-e2cd-4c26-b26b-1590f01ea996

----------
messages: 395906
nosy: ephenix
priority: normal
severity: normal
status: open
title: Add command-line functionality to uuid module
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Wed Jun 16 02:44:26 2021
From: report at bugs.python.org (Andrew Johnson)
Date: Wed, 16 Jun 2021 06:44:26 +0000
Subject: [New-bugs-announce] [issue44432] SourceFileLoader.load_module() is
 mixing content of previosly loaded files
Message-ID: <1623825866.63.0.177432261124.issue44432@roundup.psfhosted.org>


New submission from Andrew Johnson <wesoly.krzysztofa at gmail.com>:

Hi,

I'm loading multiple files in same convention - same filename, as a part of creating a build system. I can compare the case to the loading multple configuration files for various plugins in the application, the file contents of multiple files from different directories are mixed together which looks dangerous.

Here is a reproducible case for Python 3.9.4 (running on Arch Linux)
https://github.com/blackandred/python-bug-sourcefileloader

----------
hgrepos: 406
messages: 395908
nosy: blackandred
priority: normal
severity: normal
status: open
title: SourceFileLoader.load_module() is mixing content of previosly loaded files
versions: Python 3.9

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

From report at bugs.python.org  Wed Jun 16 03:16:43 2021
From: report at bugs.python.org (Rajeev Chaurasia)
Date: Wed, 16 Jun 2021 07:16:43 +0000
Subject: [New-bugs-announce] [issue44433] processes created by
 subprocess.Popen is not terminating
Message-ID: <1623827803.93.0.311738638951.issue44433@roundup.psfhosted.org>


New submission from Rajeev Chaurasia <rajeevsgsits at gmail.com>:

I am using Linux OS and using multiprocessing in my application.

The child process execution get completed but the processes are not terminating.


childprocess = "/opt/oracle.ahf/exachk/exachk -silentforce -showpass -dball -nocvu -autorun_id DEFAULT -localonly -sudo_remoterun 0"

session = subprocess.Popen(childprocess, shell = True)
session.communicate()  

>From the log I can see execution of childprocess scripts(exachk and exachk.py) is completed successfully but the process remains alive forever. Also the parent process from where I am using subprocess.Popen that also remains alive.
----------------------------------------------------
# ps -ef|grep exachk
(P1)     278988 247699  0 18:46 ?        00:00:00 sh /opt/oracle.ahf/exachk/exachk -silentforce -showpass -dball -nocvu -autorun_id DEFAULT -localonly -sudo_remoterun 0
(P2)     279873 278988 39 18:46 ?        00:12:51 /opt/oracle.ahf/python/bin/python /opt/oracle.ahf/exachk/exachk.py -silentforce -showpass -dball -nocvu -autorun_id DEFAULT -localonly
----------------------------------------------------

Please help!
-Rajeev

----------
components: Library (Lib)
messages: 395909
nosy: rajeevkchaurasia
priority: normal
severity: normal
status: open
title: processes created by subprocess.Popen is not terminating
versions: Python 3.8

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

From report at bugs.python.org  Wed Jun 16 10:19:11 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Jun 2021 14:19:11 +0000
Subject: [New-bugs-announce] [issue44434] _thread module: Remove redundant
 PyThread_exit_thread() call to avoid glibc fatal error: libgcc_s.so.1 must
 be installed for pthread_cancel to work
Message-ID: <1623853151.2.0.762537523912.issue44434@roundup.psfhosted.org>


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

The glibc pthread_exit() functions loads an unwind function from libgcc_s.so.1 using dlopen(). dlopen() can fail to open libgcc_s.so.1 file to various reasons, but the most likely seems to be that the process is out of available file descriptor (EMFILE error).

If the glibc pthread_exit() fails to open libgcc_s.so.1, it aborts the process. Extract of pthread_cancel():

  /* Trigger an error if libgcc_s cannot be loaded.  */
  {
    struct unwind_link *unwind_link = __libc_unwind_link_get ();
    if (unwind_link == NULL)
      __libc_fatal (LIBGCC_S_SO
		    " must be installed for pthread_cancel to work\n");
  }

Sometimes, libgcc_s.so.1 library is loaded early in Python startup. Sometimes, it only loaded when the first Python thread exits.

Hitting in a multithreaded real world application, dlopen() failing with EMFILE is not deterministic. It depends on precise timing and in which order threads are running. It is unlikely in a small application, but it is more likely on a network server which has thousands of open sockets (file descriptors).

--

Attached scripts reproduces the issue. You may need to run the scripts (especially pthread_cancel_emfile.py) multiple times to trigger the issue. Sometimes libgcc_s library is loaded early for an unknown reason, it works around the issue.

(1) pthread_cancel_bug.py 

$ python3.10 pthread_cancel_bug.py 
libgcc_s.so.1 must be installed for pthread_cancel to work
Abandon (core dumped)


(2) pthread_cancel_emfile.py:

$ python3.10 ~/pthread_cancel_emfile.py 
spawn thread
os.open failed: OSError(24, 'Too many open files')
FDs open by the thread: 2 (max FD: 4)
fd 0 valid? True
fd 1 valid? True
fd 2 valid? True
fd 3 valid? True
fd 4 valid? True
libgcc_s.so.1 must be installed for pthread_cancel to work
Abandon (core dumped)

--

Example of real world issue on RHEL8:
https://bugzilla.redhat.com/show_bug.cgi?id=1972293

The RHEL reproducer uses a very low RLIMIT_NOFILE (5 file descriptors) to trigger the bug faster. It simulates a busy server application.

--

There are different options:

(*) Modify thread_run() of Modules/_threadmodule.c to remove the *redundant* PyThread_exit_thread() call.

This is the most simple option and it sounds perfectly safe to me. I'm not sure why PyThread_exit_thread() is called explicitly. We don't pass any parameter to the function.


(*) Link the Python _thread extension on libgcc_s.so if Python it built with the glibc.

Checking if Python is linked to the glibc is non trivial and we have hardcode the "libgcc_s" library name. I expect painful maintenance burden with this option.

(*) Load explicitly the libgcc_s.so library in _thread.start_new_thread(): when the first thread is created.

We need to detect that we are running the glibc at runtime, by calling confstr('CS_GNU_LIBC_VERSION') for example. The problem is that "libgcc_s.so.1" filename may change depending on the Linux distribution. It will likely have a different filename on macOS (".dynlib"). In short, it's tricky to get it right.

(*) Fix the glibc!

I discussed with glibc developers who explained me that there are good reasons to keep the unwind code in the compiler (GCC), and so load it dynamically in the glibc. In short, this is not going to change.

--

Attached PR implements the most straightforward option: remove the redundant PyThread_exit_thread() call in thread_run().

----------
components: Library (Lib)
files: pthread_cancel_bug.py
messages: 395924
nosy: vstinner
priority: normal
severity: normal
status: open
title: _thread module: Remove redundant PyThread_exit_thread() call to avoid glibc fatal error: libgcc_s.so.1 must be installed for pthread_cancel to work
versions: Python 3.11
Added file: https://bugs.python.org/file50112/pthread_cancel_bug.py

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

From report at bugs.python.org  Wed Jun 16 11:29:31 2021
From: report at bugs.python.org (Jack DeVries)
Date: Wed, 16 Jun 2021 15:29:31 +0000
Subject: [New-bugs-announce] [issue44435] There is no description of
 PY_SSIZE_T_CLEAN in docs
Message-ID: <1623857371.31.0.735487801609.issue44435@roundup.psfhosted.org>


New submission from Jack DeVries <jdevries3133 at gmail.com>:

In the intro to the C API (https://docs.python.org/3/c-api/intro.html#include-files), it says, "see Parsing arguments and building values for a description of this macro." There is a link which leads to ``arg.rst``, but there is no description of the macro there, just a note to include the macro like elsewhere.

I propose to remove this sentence from the docs, since it is my understanding that there is no need to document the details of why this macro must be defined, only to ensure that users define it.

Alternatively, add a description of the macro in the appropriate place in the C API docs, and fix the link in this blurb.

I'm happy to submit a documentation patch, but I'd need someone to advise on which of these options are more desired.

----------
messages: 395935
nosy: jack__d
priority: normal
severity: normal
status: open
title: There is no description of PY_SSIZE_T_CLEAN in docs

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

From report at bugs.python.org  Wed Jun 16 11:43:23 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Jun 2021 15:43:23 +0000
Subject: [New-bugs-announce] [issue44436] [Windows]
 _thread.start_new_thread() should close the thread handle
Message-ID: <1623858203.56.0.613282344713.issue44436@roundup.psfhosted.org>


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

_thread.start_new_thread() is implemented by calling _beginthreadex(). 

Currently, when the thread completes: PyThread_exit_thread() is called which calls "_endthreadex(0)" on Windows. I proposed to no longer call it explicitly in bpo-44434.

_endthreadex() documentation says that the thread handle must be closed explicitly (with CloseHandle()), same applies for ExitThread().

"Unlike _endthread, the _endthreadex function does not close the thread handle, thereby allowing other threads to block on this one without fear that the handle will be freed out from under the system."

_endthread() closes the thread handle, but Python uses _endthreadex().

Should Python be modified to close explicitly the thread handle once the thread terminated?

_endthread() and _endthreadex() documentation:
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/endthread-endthreadex?view=msvc-160

Example closing the thread handle in the thread which created the thread:
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/beginthread-beginthreadex?view=msvc-160

Simplified code:
---
    hThread = (HANDLE)_beginthreadex( NULL, 0, &SecondThreadFunc, NULL, 0, &threadID );
    WaitForSingleObject( hThread, INFINITE );
    CloseHandle( hThread );
---


Would it be safe to close the handle just after PyThread_start_new_thread() success?

Or should it be done in the C function thread_run(), just before existing, CloseHandle(GetCurrentThread())?


To debug this issue, GetHandleInformation() can be used to check if the handle is still open or not. For example, call os.get_handle_inheritable(handle) in Python.

----------
components: Windows
messages: 395939
nosy: eryksun, paul.moore, steve.dower, tim.golden, vstinner, zach.ware
priority: normal
severity: normal
status: open
title: [Windows] _thread.start_new_thread() should close the thread handle
versions: Python 3.11

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

From report at bugs.python.org  Wed Jun 16 15:23:02 2021
From: report at bugs.python.org (Ryan Rudes)
Date: Wed, 16 Jun 2021 19:23:02 +0000
Subject: [New-bugs-announce] [issue44437] Add multimap() function similar to
 map(), but with multiprocessing functionality to the multiprocessing module
Message-ID: <1623871382.47.0.596035925697.issue44437@roundup.psfhosted.org>


Change by Ryan Rudes <ryanrudes at gmail.com>:


----------
components: Tkinter
nosy: Ryan-Rudes
priority: normal
severity: normal
status: open
title: Add multimap() function similar to map(), but with multiprocessing functionality to the multiprocessing module
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Jun 16 17:26:12 2021
From: report at bugs.python.org (Arman Sargsyan)
Date: Wed, 16 Jun 2021 21:26:12 +0000
Subject: [New-bugs-announce] [issue44438] argparser documentation error
Message-ID: <1623878772.88.0.230451377939.issue44438@roundup.psfhosted.org>


New submission from Arman Sargsyan <sargsyan_arman at outlook.com>:

URL - https://docs.python.org/3/howto/argparse.html

The following code will return a type error:

import argparse
parser = argparse.ArgumentParser()
parser.add_argument("square", help="display a square of a given number")
args = parser.parse_args()
print(args.square**2)

This should be changed to:

import argparse
parser = argparse.ArgumentParser()
parser.add_argument("square", help="display a square of a given number")
args = parser.parse_args()
print(int(args.square)**2)

----------
components: Parser
messages: 395963
nosy: arsar7, lys.nikolaou, pablogsal
priority: normal
pull_requests: 25349
severity: normal
status: open
title: argparser documentation error
type: resource usage
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/issue44438>
_______________________________________

From report at bugs.python.org  Thu Jun 17 01:05:24 2021
From: report at bugs.python.org (Ma Lin)
Date: Thu, 17 Jun 2021 05:05:24 +0000
Subject: [New-bugs-announce] [issue44439] PickleBuffer doesn't have __len__
 method
Message-ID: <1623906324.37.0.876825919891.issue44439@roundup.psfhosted.org>


New submission from Ma Lin <malincns at 163.com>:

If run this code, it will raise an exception: 

    import pickle
    import lzma
    import pandas as pd
    with lzma.open("test.xz", "wb") as file:
        pickle.dump(pd.DataFrame(range(1_000_000)), file, protocol=5)

The exception:

    Traceback (most recent call last):
      File "E:\testlen.py", line 7, in <module>
        pickle.dump(pd.DataFrame(range(1_000_000)), file, protocol=5)
      File "D:\Python39\lib\lzma.py", line 234, in write
        self._pos += len(data)
    TypeError: object of type 'pickle.PickleBuffer' has no len()
    
The exception is raised in lzma.LZMAFile.write() method:
https://github.com/python/cpython/blob/v3.10.0b2/Lib/lzma.py#L238
        
PickleBuffer doesn't have .__len__ method, is it intended?

----------
messages: 395971
nosy: malin, pitrou
priority: normal
severity: normal
status: open
title: PickleBuffer doesn't have __len__ method

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

From report at bugs.python.org  Thu Jun 17 06:10:19 2021
From: report at bugs.python.org (Alexander Dietz)
Date: Thu, 17 Jun 2021 10:10:19 +0000
Subject: [New-bugs-announce] [issue44440] logging does not work as
 documented (setLevel)
Message-ID: <1623924619.02.0.4525598898.issue44440@roundup.psfhosted.org>


New submission from Alexander Dietz <alexander.dietz at epfl.ch>:

Using python 3.8.10 and the documentation https://docs.python.org/3.8/library/logging.html it seems that either the documentation is incorrect/unclear, or that the logging module does not work as described. 

Reading on the Logger Object and the setLevel method I created the attached python code, which does not work as expected. As I set the level to "DEBUG", and the documentation clearly says " Logging messages which are less severe than level will be ignored". But having set the level to DEBUG, even the more "severe" info message is ignored. That is clearly contradicting the documentation!

----------
assignee: docs at python
components: Documentation
files: problem.py
messages: 395984
nosy: alex4200, docs at python
priority: normal
severity: normal
status: open
title: logging does not work as documented (setLevel)
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file50114/problem.py

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

From report at bugs.python.org  Thu Jun 17 06:14:12 2021
From: report at bugs.python.org (kryheb)
Date: Thu, 17 Jun 2021 10:14:12 +0000
Subject: [New-bugs-announce] [issue44441] Malformed PyImport_Inittab after
 re-initialization
Message-ID: <1623924852.9.0.945684144321.issue44441@roundup.psfhosted.org>


New submission from kryheb <krystianheberlein at gmail.com>:

Hi all,

I observed misbehavior trying to embed the Python interpreter into a C app.
It seems that after re-initialization, PyImport_Inittab is malformed and points to the memory freed _PyImport_Fini2.


Steps to reproduce:

1. Append embedded module
2. Initialize Python from config with run_filename
3. Run main with an infinite loop
4. Interrupt script execution with async call
5. Finalize Python
6. Repeat all above

Observed behavior:
The script is executed at first iteration, but re-initialization fails with an error:
"
Traceback (most recent call last):
  File "<frozen importlib._bootstrap>", line 1187, in _install_external_importers
ModuleNotFoundError: No module named 'posix'

Error: external importer setup failed
"

Head of modules list at fist run:
------ Modules: ------
#0 'posix'
#1 'errno'
#2 'pwd'
----------------------
and after re-initialization:
------ Modules: ------
#0 'P ''
#1 'errno'
#2 'pwd'
----------------------

An issue discovered on:
Fedora 33
gcc (GCC) 10.3.1 20210422 (Red Hat 10.3.1-1)
python3-devel.x86_64 3.9.5-2.fc33

Issue still exists on the latest main and on the rc 3.10
Source code to reproduce an issue in attachment.

Best regards,
Krystian Heberlein

----------
components: C API, Library (Lib)
files: inittab-bug.c
messages: 395985
nosy: kryheb
priority: normal
severity: normal
status: open
title: Malformed PyImport_Inittab after re-initialization
versions: Python 3.10, Python 3.9
Added file: https://bugs.python.org/file50115/inittab-bug.c

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

From report at bugs.python.org  Thu Jun 17 07:14:29 2021
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 17 Jun 2021 11:14:29 +0000
Subject: [New-bugs-announce] [issue44442] Globals (and presumably builtins)
 are cleared premuturely in FrameObject
Message-ID: <1623928469.97.0.790918455178.issue44442@roundup.psfhosted.org>


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

When calling frame.clear(), the globals (and builtins) are cleared.
This is not the case in 3.10. We should restore the 3.10 behavior, as there is no reason not to.


Victor, you've mentioned this problem. Did you have a specific example I can add as a test?

----------
assignee: Mark.Shannon
messages: 395995
nosy: Mark.Shannon, vstinner
priority: normal
severity: normal
status: open
title: Globals (and presumably builtins) are cleared premuturely in FrameObject
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Thu Jun 17 08:34:23 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 17 Jun 2021 12:34:23 +0000
Subject: [New-bugs-announce] [issue44443] dataclass looks up default on the
 class, not the classes __dict__
Message-ID: <1623933263.46.0.398257064207.issue44443@roundup.psfhosted.org>


New submission from Eric V. Smith <eric at trueblade.com>:

Consider:

class FtpHelper(ftplib.FTP):
    host: str
    baz: str = 'baz default'

>>> FtpHelper.host
''
>>> FtpHelper.baz
'baz default'
>>> getattr(FtpHelper, "host")
''
>>> getattr(FtpHelper, "baz")
'baz default'

But:
>>> FtpHelper.__dict__['host']
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 'host'
>>> FtpHelper.__dict__['baz']
'baz default'


Now make this a dataclass, without a default value for baz:

@dataclass
class FtpHelper(ftplib.FTP):
    host: str
    baz: str

This gives an error:
TypeError: non-default argument 'baz' follows default argument

And this is because it's picking up a default value for host from the base class ftplib.FTP, and generating an __init__ like:

def __init__(self, host='', baz):

@dataclass uses getattr(cls, field_name, MISSING) to find the default value for the field, but in this case that's wrong. I think what should happen is that it should use getattr(cls.__dict__, field_name, MISSING). This would be consistent with other features where dataclasses does not look in base classes for various things, but only in the class itself (like __hash__).

----------
assignee: eric.smith
components: Library (Lib)
messages: 396000
nosy: eric.smith
priority: normal
severity: normal
status: open
title: dataclass looks up default on the class, not the classes __dict__
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Thu Jun 17 10:49:48 2021
From: report at bugs.python.org (fastway track)
Date: Thu, 17 Jun 2021 14:49:48 +0000
Subject: [New-bugs-announce] [issue44444] How can track and trace your
 parcel live?
Message-ID: <1623941388.28.0.28797105255.issue44444@roundup.psfhosted.org>


New submission from fastway track <fastwaytracking123 at gmail.com>:

Do you feel worried about your parcel and also get bored collecting the parcel from depo? Fastway Tracking is the best service for tracking the parcel. You are looking for a service in which you can track your parcel and also get the parcel at home? Then this is the right page for the solution to your problem. And it also provides the service of delivery. https://fastwaytracking.com/

----------
messages: 396003
nosy: fastwaytracking123
priority: normal
severity: normal
status: open
title: How can track and trace your parcel live?

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

From report at bugs.python.org  Thu Jun 17 11:03:28 2021
From: report at bugs.python.org (=?utf-8?q?Filipe_La=C3=ADns?=)
Date: Thu, 17 Jun 2021 15:03:28 +0000
Subject: [New-bugs-announce] [issue44445] Add `site-include` install scheme
 path in sysconfig
Message-ID: <1623942208.43.0.621445516609.issue44445@roundup.psfhosted.org>


New submission from Filipe La?ns <lains at riseup.net>:

During the distutils deprecation, we have identified that there is no good replacement for the distutils `headers` install path. This path defines where packages are supposed to install headers on the system.

The setuptools equivalent would be `include`/`platinclude`, but these paths depend on `installed_base`/`installed_platbase`, which makes them the same on virtual environments. For this reason, they are not very suitable as a `headers` replacement -- if a package installs to `include` on a virtual environment, those files will be available everywhere.

{
    ...
    'include': '{installed_base}/include/python{py_version_short}{abiflags}',
    'platinclude': '{installed_platbase}/include/python{py_version_short}{abiflags}',
}

I propose introducing two new paths, `site-include` and `site-platinclude`, as follows:

{
    ...
    'include': '{installed_base}/include/python{py_version_short}{abiflags}',
    'platinclude': '{installed_platbase}/include/python{py_version_short}{abiflags}',
    'site-include': '{base}/include/python{py_version_short}{abiflags}-site',
    'site-platinclude': '{platbase}/include/python{py_version_short}{abiflags}-site',
}

This would make them different paths on virtual environments and would allow us to install header files there instead of `include`/`platinclude`.

Does anyone have a better idea? Or is there perhaps something I have missed?

---

Hopefully, this could go into Python 3.10, so that users can easily replace distutils usages with sysconfig. I understand if that may be unlikely.

---

Relevant links:
https://discuss.python.org/t/clarification-on-a-wheels-header-data/9305
https://github.com/pypa/pip/issues/9617

----------
messages: 396004
nosy: FFY00, dstufft, eric.araujo, jaraco, pablogsal, steve.dower, tarek
priority: high
severity: normal
status: open
title: Add `site-include` install scheme path in sysconfig
versions: Python 3.10

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

From report at bugs.python.org  Thu Jun 17 14:49:12 2021
From: report at bugs.python.org (Thomas Grainger)
Date: Thu, 17 Jun 2021 18:49:12 +0000
Subject: [New-bugs-announce] [issue44446] linecache.getline TypeError when
 formatting tracebacks in stacks containing an async list comprehension
Message-ID: <1623955752.49.0.722717443318.issue44446@roundup.psfhosted.org>


New submission from Thomas Grainger <tagrain at gmail.com>:

demo:

import traceback
import io

async def foo():
    yield 1
    traceback.print_stack(file=io.StringIO())
    yield 2

async def bar():
    return [chunk async for chunk in foo()]


next(bar().__await__(), None)
print("working!")


Traceback (most recent call last):
  File "/home/graingert/projects/anyio/foo.py", line 13, in <module>
    next(bar().__await__(), None)
  File "/home/graingert/projects/anyio/foo.py", line 10, in bar
    return [chunk async for chunk in foo()]
  File "/home/graingert/projects/anyio/foo.py", line -1, in <listcomp>
  File "/home/graingert/projects/anyio/foo.py", line 6, in foo
    traceback.print_stack(file=io.StringIO())
  File "/usr/lib/python3.10/traceback.py", line 203, in print_stack
    print_list(extract_stack(f, limit=limit), file=file)
  File "/usr/lib/python3.10/traceback.py", line 224, in extract_stack
    stack = StackSummary.extract(walk_stack(f), limit=limit)
  File "/usr/lib/python3.10/traceback.py", line 379, in extract
    f.line
  File "/usr/lib/python3.10/traceback.py", line 301, in line
    self._line = linecache.getline(self.filename, self.lineno).strip()
  File "/usr/lib/python3.10/linecache.py", line 31, in getline
    if 1 <= lineno <= len(lines):
TypeError: '<=' not supported between instances of 'int' and 'NoneType'

----------
messages: 396014
nosy: graingert
priority: normal
severity: normal
status: open
title: linecache.getline TypeError when formatting tracebacks in stacks containing an async list comprehension
versions: Python 3.10

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

From report at bugs.python.org  Thu Jun 17 18:36:13 2021
From: report at bugs.python.org (Eesa Ibrahim Khokhar)
Date: Thu, 17 Jun 2021 22:36:13 +0000
Subject: [New-bugs-announce] [issue44447] Syntax Error not as detailed as
 shown
Message-ID: <1623969373.41.0.105437108016.issue44447@roundup.psfhosted.org>


New submission from Eesa Ibrahim Khokhar <khokhareesa.home at gmail.com>:

I was testing the new features for python 3.10 beta 3, and noticed the errors were not as detailed as shown in the docs.

I have an image below:


In the docs, it was said that the entire generator statement would be pointed out by carets. However, it only pointed out 'for', and the error was not as detailed as shown in the docs.

----------
components: Regular Expressions
files: Untitled.png
messages: 396023
nosy: ezio.melotti, khokhareesa.home, mrabarnett
priority: normal
severity: normal
status: open
title: Syntax Error not as detailed as shown
type: performance
versions: Python 3.10
Added file: https://bugs.python.org/file50116/Untitled.png

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

From report at bugs.python.org  Thu Jun 17 21:08:57 2021
From: report at bugs.python.org (Andre Roberge)
Date: Fri, 18 Jun 2021 01:08:57 +0000
Subject: [New-bugs-announce] [issue44448] Suggestion: change existing error
 message for invalid function name
Message-ID: <1623978537.81.0.198253423262.issue44448@roundup.psfhosted.org>


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

Consider the following two examples with the latest beta release:

Python 3.10.0b3 ...

>>> def 3job(x):
  File "<stdin>", line 1
    def 3job(x):
         ^
SyntaxError: invalid imaginary literal

>>> def 3ob(x):
  File "<stdin>", line 1
    def 3ob(x):
        ^
SyntaxError: invalid decimal literal

In most situations, these error messages are fantastic improvements compared with what was done previously. Here however, as they are intended to be used as function names, perhaps they could be improved.

**If** it is easy to check if those "invalid number literals" are preceded by "def" during the analysis, perhaps a better error message might be

SyntaxError: invalid function name

If such an analysis would be difficult to do, I would suggest to simply close this issue as these examples are probably almost never going to be seen in real-life situations.


(One might also consider to change the error message in the cases of "invalid octal" and "invalid hexadecimal" when they are used as function names.)

----------
components: Parser
messages: 396027
nosy: aroberge, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Suggestion: change existing error message for invalid function name
versions: Python 3.10

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

From report at bugs.python.org  Fri Jun 18 06:27:10 2021
From: report at bugs.python.org (Duncan Grisby)
Date: Fri, 18 Jun 2021 10:27:10 +0000
Subject: [New-bugs-announce] [issue44449] Segfault in _PyTrash_begin when
 faulthandler tries to dump thread stacks
Message-ID: <1624012030.73.0.910498447609.issue44449@roundup.psfhosted.org>


New submission from Duncan Grisby <duncan-python at grisby.org>:

I am using Python 3.9.4 on CentOS 7. faulthandler is registered with SIGUSR1:

faulthandler.register(signal.SIGUSR1)

Sending SIGUSR1 normally correctly dumps the thread stacks, but occasionally it segfaults from the main thread instead:

Thread 1 (Thread 0x7efe15e69740 (LWP 15201)):
#0  _PyTrash_begin (tstate=tstate at entry=0x0, op=op at entry=0x757ece0) at Objects/object.c:2125
#1  0x00007efe156f05e5 in frame_dealloc (f=0x757ece0) at Objects/frameobject.c:578
#2  0x00007efe15898f88 in _Py_DECREF (op=0x757ece0) at Include/object.h:430
#3  dump_traceback (write_header=0, tstate=0x757e1a0, fd=2) at Python/traceback.c:821
#4  _Py_DumpTracebackThreads (fd=fd at entry=2, interp=<optimized out>, interp at entry=0x0, current_tstate=0xbe6a70) at Python/traceback.c:921
#5  0x00007efe1590be7d in faulthandler_dump_traceback (interp=<optimized out>, all_threads=1, fd=2) at Modules/faulthandler.c:243
#6  faulthandler_user (signum=10) at Modules/faulthandler.c:839
#7  <signal handler called>
#8  0x00007efe15243d2f in do_futex_wait () from /lib64/libpthread.so.0
#9  0x00007efe15243e07 in __new_sem_wait_slow () from /lib64/libpthread.so.0
#10 0x00007efe15243ea5 in sem_timedwait () from /lib64/libpthread.so.0
#11 0x00007efe15896d11 in PyThread_acquire_lock_timed (lock=lock at entry=0x7ea7080, microseconds=microseconds at entry=5000000, intr_flag=intr_flag at entry=1) at Python/thread_pthread.h
:457
#12 0x00007efe158f35a4 in acquire_timed (timeout=5000000000, lock=0x7ea7080) at Modules/_threadmodule.c:63
#13 lock_PyThread_acquire_lock (self=0x7efdf4518750, args=<optimized out>, kwds=<optimized out>) at Modules/_threadmodule.c:146
#14 0x00007efe15749916 in method_vectorcall_VARARGS_KEYWORDS (func=0x7efe15e1b310, args=0x186d208, nargsf=<optimized out>, kwnames=<optimized out>) at Objects/descrobject.c:346
...


It has failed because tstate is null. tstate came from Py_TRASHCAN_BEGIN_CONDITION that calls PyThreadState_GET(), assuming it returns a valid pointer, but the comment on the _PyThreadState_GET macro says:

   Efficient macro reading directly the 'gilstate.tstate_current' atomic
   variable. The macro is unsafe: it does not check for error and it can
   return NULL.

The only place I can see that tstate_current would be set to NULL is in _PyThreadState_DeleteCurrent(). I suspect that there has been a race with a thread exit.

I'm not sure quite what to do about this. Perhaps faulthandler should check if tstate_current is NULL and set it suitably if so?

----------
components: Library (Lib)
messages: 396042
nosy: dgrisby
priority: normal
severity: normal
status: open
title: Segfault in _PyTrash_begin when faulthandler tries to dump thread stacks
type: crash
versions: Python 3.9

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

From report at bugs.python.org  Fri Jun 18 07:50:04 2021
From: report at bugs.python.org (Ned Batchelder)
Date: Fri, 18 Jun 2021 11:50:04 +0000
Subject: [New-bugs-announce] [issue44450] Generator expressions trace
 differently on Windows than on Mac
Message-ID: <1624017004.2.0.445134128293.issue44450@roundup.psfhosted.org>


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

Here is a trace involving generator expressions.  Using 3.10.0b3 on Mac, there are "line" events within the expression.  Those events are missing on Windows.

--- 8< -------------------------------
import linecache, sys

def trace(frame, event, arg):
    # The weird globals here is to avoid a NameError on shutdown...
    if frame.f_code.co_filename == globals().get("__file__"):
        lineno = frame.f_lineno
        print("{} {}: {}".format(event[:4], lineno, linecache.getline(__file__, lineno).rstrip()))
    return trace

def doit():
    o = ((1,2), (3,4))
    o = (a for a in o)
    for tup in o:
        x = tup[0]
        y = tup[1]

print(sys.version)
sys.settrace(trace)
doit()
---------------------------------------

When run on Mac, it produces this output:


3.10.0b3 (default, Jun 18 2021, 06:43:38) [Clang 12.0.0 (clang-1200.0.32.29)]
call 10: def doit():
line 11:     o = ((1,2), (3,4))
line 12:     o = (a for a in o)
line 13:     for tup in o:
call 12:     o = (a for a in o)
line 12:     o = (a for a in o)
retu 12:     o = (a for a in o)
line 14:         x = tup[0]
line 15:         y = tup[1]
line 13:     for tup in o:
call 12:     o = (a for a in o)
line 12:     o = (a for a in o)
retu 12:     o = (a for a in o)
line 14:         x = tup[0]
line 15:         y = tup[1]
line 13:     for tup in o:
call 12:     o = (a for a in o)
retu 12:     o = (a for a in o)
retu 13:     for tup in o:


When run on Windows, it produces this output:

3.10.0b3 (tags/v3.10.0b3:865714a, Jun 17 2021, 20:39:25) [MSC v.1929 64 bit (AMD64)]
call 10: def doit():
line 11:     o = ((1,2), (3,4))
line 12:     o = (a for a in o)
line 13:     for tup in o:
call 12:     o = (a for a in o)
retu 12:     o = (a for a in o)
line 14:         x = tup[0]
line 15:         y = tup[1]
line 13:     for tup in o:
call 12:     o = (a for a in o)
retu 12:     o = (a for a in o)
line 14:         x = tup[0]
line 15:         y = tup[1]
line 13:     for tup in o:
call 12:     o = (a for a in o)
retu 12:     o = (a for a in o)
retu 13:     for tup in o:

On Windows, the "line 12" events are missing.

----------
components: Interpreter Core
keywords: 3.10regression
messages: 396050
nosy: Mark.Shannon, nedbat
priority: normal
severity: normal
status: open
title: Generator expressions trace differently on Windows than on Mac
versions: Python 3.10

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

From report at bugs.python.org  Fri Jun 18 08:08:37 2021
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Fri, 18 Jun 2021 12:08:37 +0000
Subject: [New-bugs-announce] [issue44451] test_entry_points_by_index
 (test.test_importlib.test_metadata_api.APITests) fails on Fedora 33 and 34
Message-ID: <1624018117.88.0.819441595689.issue44451@roundup.psfhosted.org>


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

Hello.

When we attempted to upgrade to Python 3.10.0b3 on Fedora 33 and 34, we see the following test failure:



======================================================================
ERROR: test_entry_points_by_index (test.test_importlib.test_metadata_api.APITests)
Prior versions of Distribution.entry_points would return a
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.10.0b3/Lib/test/test_importlib/test_metadata_api.py", line 145, in test_entry_points_by_index
    expected = next(iter(caught))
StopIteration
----------------------------------------------------------------------
Ran 1402 tests in 2.125s
FAILED (errors=1, skipped=18, expected failures=1)


I've reproduced it without any Fedora's patches:

$ cd cpython
$ git switch -d v3.10.0b3  # or the tip of 3.10 today, 77eaf14d27

$ ./configure --enable-shared && make

$ LD_LIBRARY_PATH=. ./python -m test test_importlib
0:00:00 load avg: 13.59 Run tests sequentially
0:00:00 load avg: 13.59 [1/1] test_importlib
test test_importlib failed -- Traceback (most recent call last):
  File "/home/churchyard/Dokumenty/RedHat/cpython/Lib/test/test_importlib/test_metadata_api.py", line 145, in test_entry_points_by_index
    expected = next(iter(caught))
StopIteration

test_importlib failed

== Tests result: FAILURE ==

1 test failed:
    test_importlib

Total duration: 11.0 sec
Tests result: FAILURE

----------
components: Library (Lib)
messages: 396051
nosy: hroncok, jaraco
priority: normal
severity: normal
status: open
title: test_entry_points_by_index (test.test_importlib.test_metadata_api.APITests) fails on Fedora 33 and 34
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Fri Jun 18 08:58:26 2021
From: report at bugs.python.org (=?utf-8?q?Zbyszek_J=C4=99drzejewski-Szmek?=)
Date: Fri, 18 Jun 2021 12:58:26 +0000
Subject: [New-bugs-announce] [issue44452] Allow paths to be joined without
 worrying about a leading slash
Message-ID: <1624021106.97.0.804015487667.issue44452@roundup.psfhosted.org>


New submission from Zbyszek J?drzejewski-Szmek <zbyszek at in.waw.pl>:

pathlib.Path.__truediv__(), i.e. pathlib.Path.joinpath() is surprising when the second argument starts with a slash.

>>> pathlib.Path('/foo') / '/bar'
>>> PosixPath('/bar')

I know that this follows the precedent set by os.path.join(), and
probably makes sense in some scenarios. But for the general operation
of "concatenating paths", it doesn't fit very well. In particular,
when concatenating multiple components this becomes even stranger:

>>> pathlib.Path('/var/tmp/instroot') / '/some/path' / '/suffix'
>>> PosixPath('/suffix')

In my particular use case, I'm concatenating some user specified paths
relative to some root. The paths may or may not be absolute.
 
To avoid this pitfall, something like this is necessary:

>>> pathlib.Path('/var/tmp/instroot') / p.lstrip('/') / q.lstrip('/')

Please provide a way to do this natively. I think it'd be nice to
use // or + for this:

>>> pathlib.Path('/var/tmp/instroot') // '/some/path' // '/suffix'
>>> PosixPath('/var/tmp/instroot/some/path/suffix')

----------
components: Library (Lib)
messages: 396058
nosy: zbysz
priority: normal
severity: normal
status: open
title: Allow paths to be joined without worrying about a leading slash
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Fri Jun 18 09:39:19 2021
From: report at bugs.python.org (Jelle Zijlstra)
Date: Fri, 18 Jun 2021 13:39:19 +0000
Subject: [New-bugs-announce] [issue44453] Documented return type of
 sysconfig.get_path() is wrong
Message-ID: <1624023559.66.0.0464260239119.issue44453@roundup.psfhosted.org>


New submission from Jelle Zijlstra <jelle.zijlstra at gmail.com>:

https://docs.python.org/3/library/sysconfig.html#sysconfig.get_path says it returns None if the name is not found, but the implementation (https://github.com/python/cpython/blame/main/Lib/sysconfig.py) uses [] and will raise KeyError instead.

Noticed by @srittau in https://github.com/python/typeshed/pull/5659. I will submit a PR.

----------
assignee: Jelle Zijlstra
components: Documentation
messages: 396065
nosy: Jelle Zijlstra
priority: normal
severity: normal
status: open
title: Documented return type of sysconfig.get_path() is wrong
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Fri Jun 18 14:58:18 2021
From: report at bugs.python.org (fix offline printers)
Date: Fri, 18 Jun 2021 18:58:18 +0000
Subject: [New-bugs-announce] [issue44454] How to find canon printer default
 wifi password
Message-ID: <1624042698.69.0.686585289751.issue44454@roundup.psfhosted.org>


New submission from fix offline printers <fixofflineprinters at gmail.com>:

You cannot use the Canon Printer for printing purpose until and unless you do not have Canon Printer Password. However, Canon Printer password troubleshooting can be done in short span of time by following technical steps. Therefore, Canon Printer Default Password setup steps mentioned below and if you cannot fix it yourself then feel free to ask for help through our chat window and get help from experts.
https://fixofflineprinters.com/how-to-find-canon-printer-default-wifi-password/

----------
messages: 396077
nosy: fixofflineprinters
priority: normal
severity: normal
status: open
title: How to find canon printer default wifi password

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

From report at bugs.python.org  Fri Jun 18 16:59:37 2021
From: report at bugs.python.org (Aaron Meurer)
Date: Fri, 18 Jun 2021 20:59:37 +0000
Subject: [New-bugs-announce] [issue44455] compileall should exit nonzero for
 nonexistent directories
Message-ID: <1624049977.61.0.207716246546.issue44455@roundup.psfhosted.org>


New submission from Aaron Meurer <asmeurer at gmail.com>:

$ ./python.exe -m compileall doesntexist
Listing 'doesntexist'...
Can't list 'doesntexist'
$ echo $?
0

It's standard for a command line tool that processes files to exit nonzero when given a directory that doesn't exist.

----------
messages: 396087
nosy: asmeurer
priority: normal
severity: normal
status: open
title: compileall should exit nonzero for nonexistent directories

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

From report at bugs.python.org  Fri Jun 18 17:07:47 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 18 Jun 2021 21:07:47 +0000
Subject: [New-bugs-announce] [issue44456] Improve syntax error for mixing
 keyword/positional in max patterns
Message-ID: <1624050467.44.0.473632182827.issue44456@roundup.psfhosted.org>


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

This got me confused for a sec when doing some live demo:

>>> match x:
...    case A(y=1, foo):
  File "<stdin>", line 2
    case A(y=1, foo):
                   ^
SyntaxError: invalid syntax

I propose to improve this to:

>>> match x:
...    case A(y=1, foo):
  File "<stdin>", line 2
    case A(y=1, foo):
                ^^^
SyntaxError: cannot mix keyword patterns and positional patterns

----------
messages: 396088
nosy: brandtbucher, pablogsal
priority: normal
severity: normal
status: open
title: Improve syntax error for mixing keyword/positional in max patterns

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

From report at bugs.python.org  Fri Jun 18 17:33:26 2021
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 18 Jun 2021 21:33:26 +0000
Subject: [New-bugs-announce] [issue44457] Finish format() change started in
 issue43945
Message-ID: <1624052006.12.0.84955724933.issue44457@roundup.psfhosted.org>


New submission from Ethan Furman <ethan at stoneleaf.us>:

Finish the work started in issue43945 -- in 3.12 `format()` now uses the enum member itself instead of its `value`; e.g.:

    >>> class Color(int, Enum):
    ...     RED = 1

    >>> f"{Color.RED}"
    'RED'
    >>> f"{Color.RED:d}"
    '1'

----------
assignee: ethan.furman
messages: 396098
nosy: ethan.furman
priority: normal
severity: normal
status: open
title: Finish format() change started in issue43945
type: behavior

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

From report at bugs.python.org  Fri Jun 18 23:24:49 2021
From: report at bugs.python.org (Russell Keith-Magee)
Date: Sat, 19 Jun 2021 03:24:49 +0000
Subject: [New-bugs-announce] [issue44458] Duplicate symbol
 _BUFFER_BLOCK_SIZE when statically linking multiple modules
Message-ID: <1624073089.72.0.865720775518.issue44458@roundup.psfhosted.org>


New submission from Russell Keith-Magee <russell at keith-magee.com>:

BPO-41486 added _BlocksOutputBuffer for the bz2, lzma and zlib module.

Part of this patch included a new header file, pycore_blocks_output_buffer.h, which defines a BUFFER_BLOCK_SIZE constant.

If two or more of the bz2, lzma or zlib modules are compiled as statically linked modules (i.e., added to Lib/Setup.local), this results in a duplicate symbol error when the Python executable is linked:

```
duplicate symbol '_BUFFER_BLOCK_SIZE' in:
    libpython3.10.a(_bz2module.o)
    libpython3.10.a(_lzmamodule.o)
duplicate symbol '_BUFFER_BLOCK_SIZE' in:
    libpython3.10.a(_bz2module.o)
    libpython3.10.a(zlibmodule.o)
```

----------
components: Extension Modules
messages: 396114
nosy: freakboy3742
priority: normal
severity: normal
status: open
title: Duplicate symbol _BUFFER_BLOCK_SIZE when statically linking multiple modules
type: compile error
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Sat Jun 19 02:22:26 2021
From: report at bugs.python.org (Anthony Sottile)
Date: Sat, 19 Jun 2021 06:22:26 +0000
Subject: [New-bugs-announce] [issue44459] 3.10b2 -> 3.10b3 regression in
 importlib.metadata for rinoh
Message-ID: <1624083746.4.0.9882241408.issue44459@roundup.psfhosted.org>


New submission from Anthony Sottile <asottile at umich.edu>:

installed from git:

```
$ git remote -v
origin	https://github.com/brechtm/rinohtype.git (fetch)
origin	https://github.com/brechtm/rinohtype.git (push)
$ git rev-parse HEAD
4054539bae53eaddd10291c8429a1a32aeeb4786
```

working in 3.10 b2:

```console
$ ./venv310/bin/python --version --version
Python 3.10.0b2 (default, Jun  2 2021, 00:22:18) [GCC 9.3.0]
$ ./venv310/bin/python -m rinoh
usage: rinoh [-h] [-f FORMAT] [-o OPTION=VALUE] [-t NAME or FILENAME] [-s NAME or FILENAME]
             [-O FILENAME or DIRECTORY] [-p PAPER] [-i] [--list-templates] [--list-stylesheets]
             [--list-fonts [FILENAME]] [--list-formats] [--list-options FRONTEND] [--version] [--docs]
             [input]

Render a structured document to PDF.

positional arguments:
  input                 the document to render

options:
  -h, --help            show this help message and exit
  -f FORMAT, --format FORMAT
                        the format of the input file (default: autodetect)
  -o OPTION=VALUE, --option OPTION=VALUE
                        options to be passed to the input file reader
  -t NAME or FILENAME, --template NAME or FILENAME
                        the document template or template configuration file to use (default: article)
  -s NAME or FILENAME, --stylesheet NAME or FILENAME
                        the style sheet used to style the document elements (default: the template's default)
  -O FILENAME or DIRECTORY, --output FILENAME or DIRECTORY
                        write the PDF output to FILENAME or to an existing DIRECTORY with a filename derived
                        from the input filename (default: the current working directory)
  -p PAPER, --paper PAPER
                        the paper size to render to (default: the template's default)
  -i, --install-resources
                        automatically install missing resources (fonts, templates, style sheets) from PyPI
  --list-templates      list the installed document templates and exit
  --list-stylesheets    list the installed style sheets and exit
  --list-fonts [FILENAME]
                        list the installed fonts or, if FILENAME is given, write a PDF file displaying all
                        the fonts
  --list-formats        list the supported input formats and exit
  --list-options FRONTEND
                        list the options supported by the given frontend and exit
  --version             show program's version number and exit
  --docs                open the online documentation in the default browser
```

broken in 3.10 b3:

```console
$ ./venv/bin/python --version --version
Python 3.10.0b3+ (heads/3.10:1b4addf3cb, Jun 18 2021, 17:21:48) [GCC 9.3.0]
$ ./venv/bin/python -m rinoh
Traceback (most recent call last):
  File "/home/asottile/workspace/cpython/prefix/lib/python3.10/runpy.py", line 187, in _run_module_as_main
    mod_name, mod_spec, code = _get_module_details(mod_name, _Error)
  File "/home/asottile/workspace/cpython/prefix/lib/python3.10/runpy.py", line 146, in _get_module_details
    return _get_module_details(pkg_main_name, error)
  File "/home/asottile/workspace/cpython/prefix/lib/python3.10/runpy.py", line 110, in _get_module_details
    __import__(pkg_name)
  File "/tmp/rinohtype/venv/lib/python3.10/site-packages/rinoh/__init__.py", line 41, in <module>
    from . import resource
  File "/tmp/rinohtype/venv/lib/python3.10/site-packages/rinoh/resource.py", line 205, in <module>
    from .template import DocumentTemplate
  File "/tmp/rinohtype/venv/lib/python3.10/site-packages/rinoh/template.py", line 42, in <module>
    from .stylesheets import sphinx
  File "/tmp/rinohtype/venv/lib/python3.10/site-packages/rinoh/stylesheets/__init__.py", line 42, in <module>
    .format(stylesheet.description, stylesheet))
  File "/tmp/rinohtype/venv/lib/python3.10/site-packages/rinoh/style.py", line 670, in __str__
    for name, entry_point in self.installed_resources:
  File "/tmp/rinohtype/venv/lib/python3.10/site-packages/rinoh/resource.py", line 54, in installed_resources
    for entry_point in ilm.entry_points()[cls.entry_point_group]:
  File "/home/asottile/workspace/cpython/prefix/lib/python3.10/importlib/metadata/__init__.py", line 979, in entry_points
    return SelectableGroups.load(eps).select(**params)
  File "/home/asottile/workspace/cpython/prefix/lib/python3.10/importlib/metadata/__init__.py", line 437, in load
    ordered = sorted(eps, key=by_group)
  File "/home/asottile/workspace/cpython/prefix/lib/python3.10/importlib/metadata/__init__.py", line -1, in <genexpr>
  File "/home/asottile/workspace/cpython/prefix/lib/python3.10/importlib/metadata/_itertools.py", line 16, in unique_everseen
    k = key(element)
  File "/home/asottile/workspace/cpython/prefix/lib/python3.10/importlib/metadata/__init__.py", line 600, in _normalized_name
    return Prepared.normalize(self.name)
  File "/home/asottile/workspace/cpython/prefix/lib/python3.10/importlib/metadata/__init__.py", line 841, in normalize
    return re.sub(r"[-_.]+", "-", name).lower().replace('-', '_')
  File "/home/asottile/workspace/cpython/prefix/lib/python3.10/re.py", line 187, in sub
    return _compile(pattern, flags).sub(repl, string, count)
TypeError: expected string or bytes-like object
```

----------
components: Library (Lib)
messages: 396117
nosy: Anthony Sottile, jaraco, pablogsal
priority: normal
severity: normal
status: open
title: 3.10b2 -> 3.10b3 regression in importlib.metadata for rinoh
type: crash
versions: Python 3.10

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

From report at bugs.python.org  Sat Jun 19 06:57:49 2021
From: report at bugs.python.org (Andrey Brykin)
Date: Sat, 19 Jun 2021 10:57:49 +0000
Subject: [New-bugs-announce] [issue44460] python crashes when pandas reading
 parquet
Message-ID: <1624100269.18.0.472069850311.issue44460@roundup.psfhosted.org>


New submission from Andrey Brykin <brand17 at yandex.ru>:

Python crashes when running this code (I attached the error message screenshot):

import pandas as pd
d = {'col1': [[0.] * 25] * 2560}
df = pd.DataFrame(data=d)
df.to_parquet('data.parquet')
for j in range(15):
  table = pd.read_parquet('data.parquet')

There is no error when running from python 3.9.5 with the same pandas version. So it doesn't relate to pandas. 

The error happening with the exact list size of 2560 - no error with 2561 or 2559. Another dimension is also important: there is no error if it is exceeding 25.

I am running on Windows 10 2004.

----------
components: IO, Windows
files: message.png
messages: 396124
nosy: brand17, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: python crashes when pandas reading parquet
type: crash
versions: Python 3.6
Added file: https://bugs.python.org/file50118/message.png

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

From report at bugs.python.org  Sat Jun 19 11:55:24 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 19 Jun 2021 15:55:24 +0000
Subject: [New-bugs-announce] [issue44461] 'Pdb' object has no attribute
 'botframe'
Message-ID: <1624118124.56.0.165481666817.issue44461@roundup.psfhosted.org>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

While doing some debugging on issue44459 using Python 3.10b3, I was using Pdb and after troubleshooting an exception and hitting 'q' to quit, I saw the following:

```
(Pdb) q
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/pdb.py", line 1709, in main
    pdb._runmodule(mainpyfile)
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/pdb.py", line 1541, in _runmodule
    mod_name, mod_spec, code = runpy._get_module_details(module_name)
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/runpy.py", line 146, in _get_module_details
    return _get_module_details(pkg_main_name, error)
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/runpy.py", line 110, in _get_module_details
    __import__(pkg_name)
  File "/var/folders/c6/v7hnmq453xb6p2dbz1gqc6rr0000gn/T/pip-run-w0xovt3h/rinoh/__init__.py", line 41, in <module>
    from . import resource
  File "/var/folders/c6/v7hnmq453xb6p2dbz1gqc6rr0000gn/T/pip-run-w0xovt3h/rinoh/resource.py", line 205, in <module>
    from .template import DocumentTemplate
  File "/var/folders/c6/v7hnmq453xb6p2dbz1gqc6rr0000gn/T/pip-run-w0xovt3h/rinoh/template.py", line 42, in <module>
    from .stylesheets import sphinx
  File "/var/folders/c6/v7hnmq453xb6p2dbz1gqc6rr0000gn/T/pip-run-w0xovt3h/rinoh/stylesheets/__init__.py", line 42, in <module>
    .format(stylesheet.description, stylesheet))
  File "/var/folders/c6/v7hnmq453xb6p2dbz1gqc6rr0000gn/T/pip-run-w0xovt3h/rinoh/style.py", line 670, in __str__
    for name, entry_point in self.installed_resources:
  File "/var/folders/c6/v7hnmq453xb6p2dbz1gqc6rr0000gn/T/pip-run-w0xovt3h/rinoh/resource.py", line 54, in installed_resources
    for entry_point in ilm.entry_points()[cls.entry_point_group]:
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/importlib/metadata/__init__.py", line 979, in entry_points
    return SelectableGroups.load(eps).select(**params)
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/importlib/metadata/__init__.py", line 437, in load
    ordered = sorted(eps, key=by_group)
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/importlib/metadata/__init__.py", line -1, in <genexpr>
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/importlib/metadata/_itertools.py", line 16, in unique_everseen
    k = key(element)
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/importlib/metadata/__init__.py", line 600, in _normalized_name
    return Prepared.normalize(self.name)
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/importlib/metadata/__init__.py", line 841, in normalize
    return re.sub(r"[-_.]+", "-", name).lower().replace('-', '_')
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/re.py", line 187, in sub
    return _compile(pattern, flags).sub(repl, string, count)
TypeError: expected string or bytes-like object

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/pdb.py", line 1738, in <module>
    pdb.main()
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/pdb.py", line 1730, in main
    pdb.interaction(None, t)
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/pdb.py", line 357, in interaction
    self._cmdloop()
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/pdb.py", line 322, in _cmdloop
    self.cmdloop()
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/cmd.py", line 138, in cmdloop
    stop = self.onecmd(line)
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/pdb.py", line 422, in onecmd
    return cmd.Cmd.onecmd(self, line)
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/cmd.py", line 217, in onecmd
    return func(arg)
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/pdb.py", line 1118, in do_quit
    self.set_quit()
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/bdb.py", line 358, in set_quit
    self.stopframe = self.botframe
AttributeError: 'Pdb' object has no attribute 'botframe'. Did you mean: 'curframe'?
```

I'd not seen this error before, so I suspect there may be a regression in 3.10. I haven't investigated further, but I wanted to register this possible issue.

----------
components: Library (Lib)
keywords: 3.10regression
messages: 396138
nosy: jaraco
priority: normal
severity: normal
status: open
title: 'Pdb' object has no attribute 'botframe'
versions: Python 3.10

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

From report at bugs.python.org  Sat Jun 19 15:49:48 2021
From: report at bugs.python.org (Chaitanya)
Date: Sat, 19 Jun 2021 19:49:48 +0000
Subject: [New-bugs-announce] [issue44462] multiprocessing.get hangs if the
 pool is closed in the signal handler
Message-ID: <1624132188.66.0.0481912539758.issue44462@roundup.psfhosted.org>


New submission from Chaitanya <chaitanya.tk17 at gmail.com>:

This is similar to https://bugs.python.org/issue22393 but the child is killed in the Pool.terminate() using SIGTERM i.e., proper way.

Run the attached script that runs an indefinite method using multiprocessing.apply_async, and in the signal handler for SIGTERM does the pool clean up (close, terminate and join), on issuing a SIGTERM (`kill <parent PID>`), the cleanup works fine, but the parent process is stuck in get() as during termination the event is not set.

Able to repro with all 3.6/3.9/3.10.


See logs below
```
[DEBUG/MainProcess] created semlock with handle 140035884298240
[DEBUG/MainProcess] created semlock with handle 140035884294144
[DEBUG/MainProcess] created semlock with handle 140035884290048
[DEBUG/MainProcess] created semlock with handle 140035884285952
[DEBUG/MainProcess] created semlock with handle 140035884281856
[DEBUG/MainProcess] created semlock with handle 140035884277760
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-1] child process calling self.run()
[INFO/MainProcess] <function close_thread_pools at 0x7f5ca3a20b80>
[INFO/MainProcess] <function close_thread_pools at 0x7f5ca3a20b80>
[INFO/MainProcess] <function close_thread_pools at 0x7f5ca3a20b80>
[INFO/ForkPoolWorker-1] Signals for 28462
[INFO/ForkPoolWorker-1] Handlers.SIG_DFL
[INFO/ForkPoolWorker-1] <built-in function default_int_handler>
[INFO/ForkPoolWorker-1] Handlers.SIG_DFL
[INFO/MainProcess] 28461: Caught signal 15
[INFO/MainProcess] 28461: Closing pools
[INFO/MainProcess] 28461: Terminating pools
[DEBUG/MainProcess] terminating pool
[DEBUG/MainProcess] finalizing pool
[DEBUG/MainProcess] helping task handler/workers to finish
[DEBUG/MainProcess] removing tasks from inqueue until task handler finished
[DEBUG/MainProcess] joining worker handler
[DEBUG/MainProcess] worker handler exiting
[DEBUG/MainProcess] result handler found thread._state=TERMINATE
[DEBUG/MainProcess] ensuring that outqueue is not full
[DEBUG/MainProcess] result handler exiting: len(cache)=1, thread._state=TERMINATE
[DEBUG/MainProcess] task handler got sentinel
[DEBUG/MainProcess] task handler sending sentinel to result handler
[DEBUG/MainProcess] task handler sending sentinel to workers
[DEBUG/MainProcess] task handler exiting
[DEBUG/MainProcess] terminating workers
[DEBUG/MainProcess] joining task handler
[DEBUG/MainProcess] joining result handler
[DEBUG/MainProcess] joining pool workers
[DEBUG/MainProcess] cleaning up worker 28462
[INFO/MainProcess] 28461: Joining pools
[DEBUG/MainProcess] joining pool
[INFO/MainProcess] 28461: Closed pools
```

```
(gdb) py-bt
Traceback (most recent call first):
  File "/usr/lib/python3.9/threading.py", line 312, in wait
    waiter.acquire()
  File "/usr/lib/python3.9/threading.py", line 574, in wait
    signaled = self._cond.wait(timeout)
  File "/usr/lib/python3.9/multiprocessing/pool.py", line 762, in wait
    self._event.wait(timeout)
  File "/usr/lib/python3.9/multiprocessing/pool.py", line 765, in get
    self.wait(timeout)
  File "/home/tatac/workspaces/gerrit/bwt-device-health-manager/mp_test.py", line 66, in <module>
    a.get()
(gdb) 
```

----------
components: Library (Lib)
files: mp_test.py
messages: 396151
nosy: tkc17
priority: normal
severity: normal
status: open
title: multiprocessing.get hangs if the pool is closed in the signal handler
type: behavior
versions: Python 3.10
Added file: https://bugs.python.org/file50121/mp_test.py

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

From report at bugs.python.org  Sat Jun 19 18:25:23 2021
From: report at bugs.python.org (Chris Wagner)
Date: Sat, 19 Jun 2021 22:25:23 +0000
Subject: [New-bugs-announce] [issue44463] HTTP Cookiejar doesn't support
 samesite
Message-ID: <1624141523.4.0.557016380209.issue44463@roundup.psfhosted.org>


New submission from Chris Wagner <jwag.wagner at gmail.com>:

In 3.8 the samesite attributes was added to http.cookies module.
However it hasn't been added to http.cookiejar module. The method: _normalized_cookie_tuples seems to have a hardcoded list of allowable attributes.

While the updated standard is still in draft stage (https://datatracker.ietf.org/doc/draft-ietf-httpbis-rfc6265bis/)
samesite is widely implemented and used (Chrome added support in 2017).

----------
components: Library (Lib)
messages: 396153
nosy: jwag956
priority: normal
severity: normal
status: open
title: HTTP Cookiejar doesn't support samesite
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Sat Jun 19 21:48:38 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 20 Jun 2021 01:48:38 +0000
Subject: [New-bugs-announce] [issue44464] Remove flake8 exception for
 deprecation warning (importlib.metadata)
Message-ID: <1624153718.07.0.351819215831.issue44464@roundup.psfhosted.org>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

importlib_metadata 4.5 (https://importlib-metadata.readthedocs.io/en/latest/history.html#v4-5-0) removed the special exclusion for flake8 in the deprecation warning for deprecated interfaces in entry_points. For the same motivations there, do the same in importlib.metadata.

----------
assignee: jaraco
components: Library (Lib)
messages: 396159
nosy: jaraco
priority: normal
severity: normal
status: open
title: Remove flake8 exception for deprecation warning (importlib.metadata)
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Sat Jun 19 23:40:30 2021
From: report at bugs.python.org (Andrei Kulakov)
Date: Sun, 20 Jun 2021 03:40:30 +0000
Subject: [New-bugs-announce] [issue44465] html.escape can be used in a few
 places in the standard lib instead of similar existing code
Message-ID: <1624160430.21.0.153812631131.issue44465@roundup.psfhosted.org>


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

There are a few places where old code does essentially the same thing as `html.escape()`, and can be replaced with html.escape():

 - more readable
 - less error prone on refactorings
 - will benefit if html.escape() performance is improved in the future
 - will be easier to grep for in case in the future html.escape() is enhanced with new escapes & it will be useful to consider applying it to all instances where it is used.

Here's what I found:

https://github.com/python/cpython/blob/main/Lib/difflib.py#L1914

https://github.com/python/cpython/blob/09eb81711597725f853e4f3b659ce185488b0d8c/Lib/plistlib.py#L158

https://github.com/python/cpython/blob/09eb81711597725f853e4f3b659ce185488b0d8c/Lib/pydoc.py#L525

https://github.com/python/cpython/blob/09eb81711597725f853e4f3b659ce185488b0d8c/Lib/xml/dom/minidom.py#L306

(^ keep existing escape of double quote)

https://github.com/python/cpython/blob/09eb81711597725f853e4f3b659ce185488b0d8c/Lib/xml/sax/saxutils.py#L27

https://github.com/python/cpython/blob/09eb81711597725f853e4f3b659ce185488b0d8c/Lib/xmlrpc/client.py#L149

I can add a PR if this sounds good.

----------
components: Library (Lib)
messages: 396161
nosy: andrei.avk
priority: normal
severity: normal
status: open
title: html.escape can be used in a few places in the standard lib instead of similar existing code
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Sun Jun 20 16:24:28 2021
From: report at bugs.python.org (Maxwell Ballenger)
Date: Sun, 20 Jun 2021 20:24:28 +0000
Subject: [New-bugs-announce] [issue44466] faulthandler should indicate if
 the fault happened in garbage collection
Message-ID: <1624220668.4.0.0473395523202.issue44466@roundup.psfhosted.org>


New submission from Maxwell Ballenger <ballengerm at gmail.com>:

I have been working on debugging a segfault. When faulthandler catches the fault, it makes a printout like this:

Current thread 0x00007f4fa62b2700 (most recent call first):
  File "/usr/lib/python3.6/site-packages/tornado/ioloop.py", line 919, in call_at
  File "/usr/lib/python3.6/site-packages/tornado/ioloop.py", line 502, in add_timeout
  ...

However, when I run the same app with gdb, catch the segfault with gdb and and run py-bt, it makes a printout like this

(gdb) py-bt
Traceback (most recent call first):
  Garbage-collecting
  File "/usr/lib/python3.6/site-packages/tornado/ioloop.py", line 919, in call_at
    functools.partial(stack_context.wrap(callback), *args, **kwargs),
  File "/usr/lib/python3.6/site-packages/tornado/ioloop.py", line 502, in add_timeout
    return self.call_at(deadline, callback, *args, **kwargs)
  ...

The important distinction here for me is the "Garbage-collecting" line. When debugging this issue with faulthandler, I thought that the segfault was happening somewhere in the execution stack of this ioloop.py function. It wasn't until I ran under gdb that I realized it was actually happening in garbage collection and more or less has nothing to do with ioloop.py. It seems like faulthandler should be able to tell that the segfault was actually generated in garbage collection and this would make faulthandler much more helpful for cases like this.

Thank you for reading!

----------
components: Library (Lib)
messages: 396196
nosy: maxballenger
priority: normal
severity: normal
status: open
title: faulthandler should indicate if the fault happened in garbage collection
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Sun Jun 20 16:40:39 2021
From: report at bugs.python.org (Anthony Sottile)
Date: Sun, 20 Jun 2021 20:40:39 +0000
Subject: [New-bugs-announce] [issue44467] profiling-compatible
 functools.wraps
Message-ID: <1624221639.17.0.239071642719.issue44467@roundup.psfhosted.org>


New submission from Anthony Sottile <asottile at umich.edu>:

this is a small proposal to add a new function to the functools module which provides better profiling-compatible `@functools.wraps(...)`

the rationale comes from https://github.com/Yelp/named_decorator (which is dead / abandoned)

the tl;dr from there is any time a decorator is involved in a profile it becomes very difficult to trace because everything becomes tangled around common decorators (because function names are used from the code object)

here is the proposal and an initial implementation:


def wraps_with_name(func, decorator, **kwargs):
    def wraps_with_name_decorator(wrapped):
        new_name = f'{func.__name__}@{decorator.__name__}'
        new_code = wrapped.__code__.replace(co_name=new_name)
        # would be nice if `types.FunctionType` had a `.replace(...)` too!
        new_wrapped = types.FunctionType(
            new_code,
            wrapped.__globals__,
            new_name,
            wrapped.__defaults__,
            wrapped.__closure__,
        )
        return functools.wraps(func, **kwargs)(new_wrapped)
    return better_wraps_decorator

the usage would be similar to `functools.wraps`, here is an example:

```python
def my_decorator(func):
    @functools.wraps_with_name(func, my_decorator)
    def my_decorator_inner(*args, **kwargs):
        return func(*args, **kwargs)
    return my_decorator
```

----------
components: Library (Lib)
messages: 396199
nosy: Anthony Sottile
priority: normal
severity: normal
status: open
title: profiling-compatible functools.wraps
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Mon Jun 21 00:11:39 2021
From: report at bugs.python.org (Will Chen)
Date: Mon, 21 Jun 2021 04:11:39 +0000
Subject: [New-bugs-announce] [issue44468] Shouldn't
 `typing.get_type_hints()` default `globalns` to `{}` instead of skipping
 base classes?
Message-ID: <1624248699.71.0.0674887100793.issue44468@roundup.psfhosted.org>


New submission from Will Chen <inbox at intralexical.studio>:

An issue was recently closed that caused synthetic classes and base classes with invalid `__module__` attributes to raise `KeyError()` in `typing.get_type_hints()`:

https://bugs.python.org/issue41515

However, the implemented solution appears to be to skip those classes completely with a `continue` statement, instead of getting the annotations that may still be present by using an empty globals dictonary:

https://github.com/python/cpython/pull/25352/files#diff-ddb987fca5f5df0c9a2f5521ed687919d70bb3d64eaeb8021f98833a2a716887

In order to work around this issue in my local install of Blender, I had to change `.get_type_hints()` to use an empty dictionary for `globalns` when encountering invalid modules, rather than skipping them:

https://developer.blender.org/T88986#1179812

>From reading the commit where the broken behaviour was first introduced? Which was described/designed as "backwards compatible"? It looks like the original behaviour was also to use an empty dictionary, and never skip:

https://github.com/python/cpython/commit/f350a268a7071ce7d7a5bb86a9b1229782d4963b#diff-ddb987fca5f5df0c9a2f5521ed687919d70bb3d64eaeb8021f98833a2a716887R1501

Using an empty dictionary also seemed to be mentioned in the bug report linked above.

IMO using an empty dictionary and still returning annotations from classes with invalid modules seems like it'd be more sensible, predictable, and backwards-compatible, while skipping base classes is likely to just replace the obvious `KeyError()` with less reproducible and nastier errors caused by returning incomplete type hints.

----------
messages: 396205
nosy: willchencontact
priority: normal
severity: normal
status: open
title: Shouldn't `typing.get_type_hints()` default `globalns` to `{}` instead of skipping base classes?
type: behavior
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Mon Jun 21 01:38:29 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 21 Jun 2021 05:38:29 +0000
Subject: [New-bugs-announce] [issue44469] Fix tests for "async with"
Message-ID: <1624253909.65.0.82466833877.issue44469@roundup.psfhosted.org>


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

In Lib/test/test_coroutines.py some tests test that the body of the "asyn with" statement with bad context manager was not executed by setting a value of a variable in the body and checking its value after executing.

        body_executed = False
        async def foo():
            async with CM():
                body_executed = True

        with self.assertRaisesRegex(AttributeError, '__aexit__'):
            run_async(foo())
        self.assertFalse(body_executed)

The problem is that it sets the value of local variable of the inner function, and does not affect the outer variable. The test would pass even if the body was executed.

----------
components: Tests
messages: 396206
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Fix tests for "async with"
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Mon Jun 21 02:52:35 2021
From: report at bugs.python.org (Samuel Marks)
Date: Mon, 21 Jun 2021 06:52:35 +0000
Subject: [New-bugs-announce] [issue44470] 3.11 docs.python.org in Polish not
 English?
Message-ID: <1624258355.63.0.825475628203.issue44470@roundup.psfhosted.org>


New submission from Samuel Marks <samuelmarks at gmail.com>:

It's been too long since my family have been Polish!

(see screenshot of https://docs.python.org/3.11/library/parser.html )

My computer is only configured for English. Running Firefox 90.0b9 (64-bit) on macOS 11.4 (20F71).

----------
assignee: docs at python
components: Documentation
files: Screen Shot 2021-06-21 at 4.49.27 pm.png
messages: 396207
nosy: docs at python, samuelmarks
priority: normal
severity: normal
status: open
title: 3.11 docs.python.org in Polish not English?
type: behavior
versions: Python 3.11
Added file: https://bugs.python.org/file50122/Screen Shot 2021-06-21 at 4.49.27 pm.png

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

From report at bugs.python.org  Mon Jun 21 03:43:53 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 21 Jun 2021 07:43:53 +0000
Subject: [New-bugs-announce] [issue44471] Raise TypeError in
 ExitStack.enter_context() for bad argument
Message-ID: <1624261433.34.0.758010123752.issue44471@roundup.psfhosted.org>


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

For consistency with the "with" statement (see issue12022) ExitStack.enter_context() should raise TypeError instead of AttributeError if the argument is not a context manager. Same for AsyncExitStack.enter_async_context().

----------
components: Library (Lib)
messages: 396209
nosy: ncoghlan, serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: Raise TypeError in ExitStack.enter_context() for bad argument
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Mon Jun 21 06:18:55 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 21 Jun 2021 10:18:55 +0000
Subject: [New-bugs-announce] [issue44472] ltrace functionality doesn't work
 if there is an exception set
Message-ID: <1624270735.06.0.710664144934.issue44472@roundup.psfhosted.org>


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

Using lltrace results in this crash because we are getting the repl with an exception set:

pop None
Assertion failed: (!_PyErr_Occurred(tstate)), function PyObject_Repr, file Objects/object.c, line 431.
pop Fatal Python error: Aborted

Current thread 0x00000001060eddc0 (most recent call first):
  File "/Users/pgalindo3/github/cpython/Lib/test/test_sys_settrace.py", line 1999 in gen
  File "/Users/pgalindo3/github/cpython/Lib/test/test_sys_settrace.py", line 2001 in test_jump_from_yield
  File "/Users/pgalindo3/github/cpython/Lib/test/test_sys_settrace.py", line 1248 in run_test
  File "/Users/pgalindo3/github/cpython/Lib/test/test_sys_settrace.py", line 1276 in test
  File "/Users/pgalindo3/github/cpython/Lib/unittest/case.py", line 549 in _callTestMethod
  File "/Users/pgalindo3/github/cpython/Lib/unittest/case.py", line 592 in run
  File "/Users/pgalindo3/github/cpython/Lib/unittest/case.py", line 652 in __call__
  File "/Users/pgalindo3/github/cpython/Lib/unittest/suite.py", line 122 in run
  File "/Users/pgalindo3/github/cpython/Lib/unittest/suite.py", line 84 in __call__
  File "/Users/pgalindo3/github/cpython/Lib/unittest/suite.py", line 122 in run
  File "/Users/pgalindo3/github/cpython/Lib/unittest/suite.py", line 84 in __call__
  File "/Users/pgalindo3/github/cpython/Lib/unittest/suite.py", line 122 in run
  File "/Users/pgalindo3/github/cpython/Lib/unittest/suite.py", line 84 in __call__
  File "/Users/pgalindo3/github/cpython/Lib/unittest/runner.py", line 176 in run
  File "/Users/pgalindo3/github/cpython/Lib/test/support/__init__.py", line 960 in _run_suite
  File "/Users/pgalindo3/github/cpython/Lib/test/support/__init__.py", line 1083 in run_unittest
  File "/Users/pgalindo3/github/cpython/Lib/test/libregrtest/runtest.py", line 210 in _test_module
  File "/Users/pgalindo3/github/cpython/Lib/test/libregrtest/runtest.py", line 246 in _runtest_inner2
  File "/Users/pgalindo3/github/cpython/Lib/test/libregrtest/runtest.py", line 282 in _runtest_inner
  File "/Users/pgalindo3/github/cpython/Lib/test/libregrtest/runtest.py", line 154 in _runtest
  File "/Users/pgalindo3/github/cpython/Lib/test/libregrtest/runtest.py", line 194 in runtest
  File "/Users/pgalindo3/github/cpython/Lib/test/libregrtest/main.py", line 423 in run_tests_sequential
  File "/Users/pgalindo3/github/cpython/Lib/test/libregrtest/main.py", line 521 in run_tests
  File "/Users/pgalindo3/github/cpython/Lib/test/libregrtest/main.py", line 694 in _main
  File "/Users/pgalindo3/github/cpython/Lib/test/libregrtest/main.py", line 641 in main
  File "/Users/pgalindo3/github/cpython/Lib/test/libregrtest/main.py", line 719 in main
  File "/Users/pgalindo3/github/cpython/Lib/test/__main__.py", line 2 in <module>
  File "/Users/pgalindo3/github/cpython/Lib/runpy.py", line 86 in _run_code
  File "/Users/pgalindo3/github/cpython/Lib/runpy.py", line 196 in _run_module_as_main

----------
messages: 396220
nosy: pablogsal
priority: normal
severity: normal
status: open
title: ltrace functionality doesn't work if there is an exception set

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

From report at bugs.python.org  Mon Jun 21 09:04:38 2021
From: report at bugs.python.org (=?utf-8?q?Kai_M=C3=BCller?=)
Date: Mon, 21 Jun 2021 13:04:38 +0000
Subject: [New-bugs-announce] [issue44473] logging.handlers.QueueHandler acts
 unexpected
Message-ID: <1624280678.3.0.314490541758.issue44473@roundup.psfhosted.org>


New submission from Kai M?ller <kai.jmueller at gmail.com>:

According to the docstring of logging.handlers.QueueHandler
"The base implementation formats the record to merge the message and arguments, and removes unpickleable items from the record in-place."
But, if a just a log message is used w/o any arguments, the arguments are still set to None, which IMHO unexpected. Especially, according to the typeshed project, the "args" is ALWAYS either a dict or a tuple. But in this case, they are set to None which surprised my a lot.

Would it be possible to improve the docstring to state, that args, exc_info, exc_text are set to None and that msg is overwritten. If you miss this tiny but very important detail, additional handlers can act very wrong.
In addition, it seems to be that the type information needs to be improved in typeshed or are there any other plans on your side?

----------
assignee: docs at python
components: Documentation
messages: 396243
nosy: docs at python, kai.jmueller
priority: normal
severity: normal
status: open
title: logging.handlers.QueueHandler acts unexpected
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/issue44473>
_______________________________________

From report at bugs.python.org  Mon Jun 21 09:33:42 2021
From: report at bugs.python.org (Wel Griv)
Date: Mon, 21 Jun 2021 13:33:42 +0000
Subject: [New-bugs-announce] [issue44474] inspect.getsourceslines() consider
 lambda of one line only
Message-ID: <1624282422.28.0.515829011404.issue44474@roundup.psfhosted.org>


New submission from Wel Griv <kataklysme at gmail.com>:

When lambda expression is more than one line or contain a line break, getsourcelines() from inspect package only return the first line. Code example:

import inspect


def foo(param, lambda_ref):
    _ = param
    print(str(inspect.getsourcelines(lambda_ref)))


foo(param=0,
    lambda_ref=lambda:
    40 + 2)

output:

(['    lambda_ref=lambda:\n'], 10)

expected output:

(['foo(lambda_ref=lambda:\n', '    40 + 2)\n'], 10)

`param` is not necessary to make the bug appears but makes more sense in a real use-case scenario.
Beside, I checked the inspect.py code (see github: https://github.com/python/cpython/blob/3.9/Lib/inspect.py couldn't include link in the form for some reason), the guilty code is in the tokeneater() method in the BlockFinder class. A commentary explicitly mention "# lambdas always end at the first NEWLINE" (line 957 of inspect.py in python 3.9, line 1078 in python 3.10). EndOfBlock is raised after the first newline in case the block is a lambda.
Moreover, a similar issue was raised, and closed for strange reason in python 2 back in 2013, see here: https://bugs.python.org/issue17631

----------
components: Extension Modules, Library (Lib), Windows
messages: 396245
nosy: Welgriv, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: inspect.getsourceslines() consider lambda of one line only
type: behavior
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Mon Jun 21 11:06:36 2021
From: report at bugs.python.org (Andrew C)
Date: Mon, 21 Jun 2021 15:06:36 +0000
Subject: [New-bugs-announce] [issue44475] Dataclass Causes Infinite
 Recursion when using type of bytes
Message-ID: <1624287996.71.0.124244983784.issue44475@roundup.psfhosted.org>


New submission from Andrew C <andrewonboe at gmail.com>:

Hello,

When given a `Field` on a Dataclass, the `__repr__` throws an infinite recursive error when the data type is bytes.

In the `Field` class, the __repr__ is as follows:

```
    def __repr__(self):
        return (
            'Field('
            f'name={self.name!r},'
            f'type={self.type!r},'
            f'default={self.default!r},'
            f'default_factory={self.default_factory!r},'
            f'init={self.init!r},'
            f'repr={self.repr!r},'
            f'hash={self.hash!r},'
            f'compare={self.compare!r},'
            f'metadata={self.metadata!r},'
            f'_field_type={self._field_type}'
            ')'
        )
```

The issue is the f'type={self.type!r}, part of the code.

----------
components: Windows
messages: 396250
nosy: andrewonboe, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Dataclass Causes Infinite Recursion when using type of bytes
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Mon Jun 21 11:52:57 2021
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 21 Jun 2021 15:52:57 +0000
Subject: [New-bugs-announce] [issue44476] "subprocess not supported for
 isolated subinterpreters" when running venv
Message-ID: <1624290777.25.0.989735208414.issue44476@roundup.psfhosted.org>


New submission from Brian Curtin <brian at python.org>:

I'm currently trying to run my `tox` testing environment?all of which runs under `coverage`?against 3.10b3 and am running into some trouble. I initially thought it was something about tox or coverage, but it looks lower level than that as the venv script in the stdlib isn't working. I'm not actually sure if the direct problem I'm experiencing is the same as what I'm listing below, but it reproduces the same result:

$ python3.10 -m venv ~/.envs/test
Error: subprocess not supported for isolated subinterpreters

Here's the version I'm running: Python 3.10.0b3 (tags/v3.10.0b3:865714a117, Jun 17 2021, 17:37:28) [Clang 10.0.1 (clang-1001.0.46.4)] on darwin


In case it's helpful, here's a full traceback from tox:

action: py310-unit, msg: getenv
cwd: /Users/briancurtin/elastic/cloud/python-services-v3
cmd: /Users/briancurtin/elastic/cloud/python-services-v3/.tox/py310-unit/bin/python -m pip install coverage -rrequirements.txt -rtest-requirements.txt
Collecting coverage
  Using cached coverage-5.5.tar.gz (691 kB)
    ERROR: Error subprocess not supported for isolated subinterpreters while executing command python setup.py egg_info
ERROR: Exception:
Traceback (most recent call last):
  File "/Users/briancurtin/elastic/cloud/python-services-v3/.tox/py310-unit/lib/python3.10/site-packages/pip/_internal/cli/base_command.py", line 188, in _main
    status = self.run(options, args)
  File "/Users/briancurtin/elastic/cloud/python-services-v3/.tox/py310-unit/lib/python3.10/site-packages/pip/_internal/cli/req_command.py", line 185, in wrapper
    return func(self, options, args)
  File "/Users/briancurtin/elastic/cloud/python-services-v3/.tox/py310-unit/lib/python3.10/site-packages/pip/_internal/commands/install.py", line 332, in run
    requirement_set = resolver.resolve(
  File "/Users/briancurtin/elastic/cloud/python-services-v3/.tox/py310-unit/lib/python3.10/site-packages/pip/_internal/resolution/legacy/resolver.py", line 179, in resolve
    discovered_reqs.extend(self._resolve_one(requirement_set, req))
  File "/Users/briancurtin/elastic/cloud/python-services-v3/.tox/py310-unit/lib/python3.10/site-packages/pip/_internal/resolution/legacy/resolver.py", line 362, in _resolve_one
    abstract_dist = self._get_abstract_dist_for(req_to_install)
  File "/Users/briancurtin/elastic/cloud/python-services-v3/.tox/py310-unit/lib/python3.10/site-packages/pip/_internal/resolution/legacy/resolver.py", line 314, in _get_abstract_dist_for
    abstract_dist = self.preparer.prepare_linked_requirement(req)
  File "/Users/briancurtin/elastic/cloud/python-services-v3/.tox/py310-unit/lib/python3.10/site-packages/pip/_internal/operations/prepare.py", line 487, in prepare_linked_requirement
    abstract_dist = _get_prepared_distribution(
  File "/Users/briancurtin/elastic/cloud/python-services-v3/.tox/py310-unit/lib/python3.10/site-packages/pip/_internal/operations/prepare.py", line 91, in _get_prepared_distribution
    abstract_dist.prepare_distribution_metadata(finder, build_isolation)
  File "/Users/briancurtin/elastic/cloud/python-services-v3/.tox/py310-unit/lib/python3.10/site-packages/pip/_internal/distributions/sdist.py", line 40, in prepare_distribution_metadata
    self.req.prepare_metadata()
  File "/Users/briancurtin/elastic/cloud/python-services-v3/.tox/py310-unit/lib/python3.10/site-packages/pip/_internal/req/req_install.py", line 550, in prepare_metadata
    self.metadata_directory = self._generate_metadata()
  File "/Users/briancurtin/elastic/cloud/python-services-v3/.tox/py310-unit/lib/python3.10/site-packages/pip/_internal/req/req_install.py", line 525, in _generate_metadata
    return generate_metadata_legacy(
  File "/Users/briancurtin/elastic/cloud/python-services-v3/.tox/py310-unit/lib/python3.10/site-packages/pip/_internal/operations/build/metadata_legacy.py", line 70, in generate_metadata
    call_subprocess(
  File "/Users/briancurtin/elastic/cloud/python-services-v3/.tox/py310-unit/lib/python3.10/site-packages/pip/_internal/utils/subprocess.py", line 185, in call_subprocess
    proc = subprocess.Popen(
  File "/usr/local/lib/python3.10/subprocess.py", line 962, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/usr/local/lib/python3.10/subprocess.py", line 1773, in _execute_child
    self.pid = _posixsubprocess.fork_exec(
RuntimeError: subprocess not supported for isolated subinterpreters
WARNING: You are using pip version 20.1.1; however, version 21.1.2 is available.
You should consider upgrading via the '/Users/briancurtin/elastic/cloud/python-services-v3/.tox/py310-unit/bin/python -m pip install --upgrade pip' command.

----------
messages: 396262
nosy: brian.curtin
priority: normal
severity: normal
status: open
title: "subprocess not supported for isolated subinterpreters" when running venv
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Mon Jun 21 12:08:34 2021
From: report at bugs.python.org (Ken Jin)
Date: Mon, 21 Jun 2021 16:08:34 +0000
Subject: [New-bugs-announce] [issue44477] Remove ma_version_tag in dict?
Message-ID: <1624291714.04.0.676545373232.issue44477@roundup.psfhosted.org>


New submission from Ken Jin <kenjin4096 at gmail.com>:

issue44206, issue44337, and issue44338 converted things dependent on ma_version_tag to ma_keys->dk_version.

I propose to remove ma_version_tag and save 8 bytes of space in dict. I've prepared a draft PR to do that. However, I'd like to wait for some time before merging it. This will make it easier to revert a PR in one of those issues should the need arise.

----------
messages: 396264
nosy: Mark.Shannon, kj, methane
priority: normal
severity: normal
status: open
title: Remove ma_version_tag in dict?
versions: Python 3.11

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

From report at bugs.python.org  Mon Jun 21 13:06:44 2021
From: report at bugs.python.org (Oz Mouchtar)
Date: Mon, 21 Jun 2021 17:06:44 +0000
Subject: [New-bugs-announce] [issue44478] I can't
Message-ID: <1624295204.74.0.655904668148.issue44478@roundup.psfhosted.org>


New submission from Oz Mouchtar <oz1804 at gmail.com>:

Hey I'm new to Python (just started to learn this magnificent language) and during my online course I tried to create a virtual environment and got the error on the attached file.
I tried even to re-install Python and Visual Studio and yet I get this error. Can someone help me?  
I'm using Visual Studio code and Python version 3.9.5

----------
components: Windows
files: problem.jpg
messages: 396272
nosy: oz1804, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: I can't
type: crash
versions: Python 3.9
Added file: https://bugs.python.org/file50123/problem.jpg

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

From report at bugs.python.org  Mon Jun 21 19:02:30 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 21 Jun 2021 23:02:30 +0000
Subject: [New-bugs-announce] [issue44479] Windows build doesn't regenerate
 some files
Message-ID: <1624316550.78.0.114514197703.issue44479@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
components: Windows
nosy: gvanrossum, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows build doesn't regenerate some files

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

From report at bugs.python.org  Mon Jun 21 19:04:43 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Jun 2021 23:04:43 +0000
Subject: [New-bugs-announce] [issue44480] test_compile killed by signal 9 on
 AMD64 FreeBSD Non-Debug 3.x
Message-ID: <1624316683.45.0.985202182274.issue44480@roundup.psfhosted.org>


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

It looks like bpo-44360 which was a Linux OOM Killer issue since the Linux machine memory was too low.

AMD64 FreeBSD Non-Debug 3.x:
https://buildbot.python.org/all/#/builders/172/builds/387

...
test_single_statement (test.test_compile.TestSpecifics) ... ok
test_stack_overflow (test.test_compile.TestSpecifics) ... *** Signal 9
Stop.
make: stopped in /usr/home/buildbot/python/3.x.koobs-freebsd-9e36.nondebug/build
program finished with exit code 1
elapsedTime=855.058198

----------
components: Tests
messages: 396298
nosy: koobs, vstinner
priority: normal
severity: normal
status: open
title: test_compile killed by signal 9 on AMD64 FreeBSD Non-Debug 3.x
versions: Python 3.11

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

From report at bugs.python.org  Mon Jun 21 19:44:11 2021
From: report at bugs.python.org (Jeff S)
Date: Mon, 21 Jun 2021 23:44:11 +0000
Subject: [New-bugs-announce] [issue44481] Tkinter config() minor
 documentation bug for shorthand options
Message-ID: <1624319051.28.0.321773416541.issue44481@roundup.psfhosted.org>


New submission from Jeff S <spirko at gmail.com>:

The documentation page https://docs.python.org/3/library/tkinter.html states "Passing the config() method the name of a shorthand option will return a 2-tuple, not 5-tuple."  While config() without argument does return a map that yields references like this, if config() is given the shorthand name as an argument, it follows the reference to the long option name and does yield the full 5-tuple.

To demonstrate the difference:

from tkinter import Tk

Tk().config()['bg']

Tk().config('bg')

----------
components: Tkinter
messages: 396301
nosy: spirko
priority: normal
severity: normal
status: open
title: Tkinter config() minor documentation bug for shorthand options
type: behavior
versions: Python 3.6, Python 3.9

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

From report at bugs.python.org  Tue Jun 22 01:40:18 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 22 Jun 2021 05:40:18 +0000
Subject: [New-bugs-announce] [issue44482] Possible resource leeak in glob in
 non-refcount implementations
Message-ID: <1624340418.29.0.31085247702.issue44482@roundup.psfhosted.org>


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

There is possible resource leak in glob on alternate Python implementation witch do not use reference counting to immediate releasing resources.

It is in the code

    names = list(_iterdir(dirname, dir_fd, dironly))

where _iterdir() is a generator function which calls os.scandir() and yields entry names after some filtering. If an exception happens inside _iterdir(), the scandir iterator will be immediately closed, because of using the with statement. But an exception can happens outside of _iterdir(), in the list constructor (MemoryError). In this case the generator will be closed immediately in CPython because of reference counting (newly created generator has only one reference), but on other implementation it can be deferred on arbitrary time. And even in CPython we rely on garbage collector if there reference loops in the generator frame. This issue has very small chance to occur but still.

The right way is to close the generator explicitly:

    it = _iterdir(dirname, dir_fd, dironly)
    try:
        names = list(it)
    finally:
        it.close()

or

    with contextlib.closing(_iterdir(dirname, dir_fd, dironly)) as it:
        names = list(it)

We should analyze all other generator functions which acquire some resources and ensure that they are always properly closed.

----------
components: Library (Lib)
messages: 396306
nosy: gvanrossum, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Possible resource leeak in glob in non-refcount implementations
type: resource usage
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Tue Jun 22 02:32:26 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 22 Jun 2021 06:32:26 +0000
Subject: [New-bugs-announce] [issue44483] Fatal error in type union
Message-ID: <1624343546.88.0.657403133793.issue44483@roundup.psfhosted.org>


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

The following example crashes:

class TypeVar:
    @property
    def __module__(self):
        1/0

str | TypeVar()


Output:
Fatal Python error: _Py_CheckSlotResult: Slot | of type type succeeded with an exception set
Python runtime state: initialized
Traceback (most recent call last):
  File "<stdin>", line 4, in __module__
ZeroDivisionError: division by zero
Aborted (core dumped)

The problem in Objects/unionobject.c is that is_typing_module() (and therefore is_typevar() and is_special_form()) can return not only 0 and 1, but -1 as a signal of error, but is_unionable() does not check results for error and interprets it as boolean true.

----------
assignee: serhiy.storchaka
components: Interpreter Core
messages: 396307
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Fatal error in type union
type: crash
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Tue Jun 22 04:31:40 2021
From: report at bugs.python.org (Erlend E. Aasland)
Date: Tue, 22 Jun 2021 08:31:40 +0000
Subject: [New-bugs-announce] [issue44484] test_concurrent_futures: failure
 on Windows (x64)
Message-ID: <1624350700.35.0.200169528157.issue44484@roundup.psfhosted.org>


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

https://github.com/python/cpython/pull/26840/checks?check_run_id=2879802998

2021-06-21T22:34:41.2973359Z Current runner version: '2.278.0'
2021-06-21T22:34:41.3112811Z ##[group]Operating System
2021-06-21T22:34:41.3113619Z Microsoft Windows Server 2019
2021-06-21T22:34:41.3114096Z 10.0.17763
2021-06-21T22:34:41.3114505Z Datacenter
2021-06-21T22:34:41.3115007Z ##[endgroup]
2021-06-21T22:34:41.3115466Z ##[group]Virtual Environment
2021-06-21T22:34:41.3116039Z Environment: windows-2019
2021-06-21T22:34:41.3116541Z Version: 20210616.0
2021-06-21T22:34:41.3117404Z Included Software: https://github.com/actions/virtual-environments/blob/win19/20210616.0/images/win/Windows2019-Readme.md
2021-06-21T22:34:41.3118637Z Image Release: https://github.com/actions/virtual-environments/releases/tag/win19%2F20210616.0


2021-06-21T22:38:24.0261439Z == CPython 3.11.0a0 (remotes/pull/26840/merge:b69c744, Jun 21 2021, 22:36:15) [MSC v.1929 64 bit (AMD64)]
2021-06-21T22:38:24.0262925Z == Windows-10-10.0.17763-SP0 little-endian
2021-06-21T22:38:24.0264290Z == cwd: D:\a\cpython\cpython\build\test_python_2792?
2021-06-21T22:38:24.0278874Z == CPU count: 2
2021-06-21T22:38:24.0284909Z == encodings: locale=cp1252, FS=utf-8


2021-06-21T22:41:30.6340389Z ======================================================================
2021-06-21T22:41:30.6341414Z FAIL: test_cancel_futures_wait_false (test.test_concurrent_futures.ThreadPoolShutdownTest)
2021-06-21T22:41:30.6342422Z ----------------------------------------------------------------------
2021-06-21T22:41:30.6343079Z Traceback (most recent call last):
2021-06-21T22:41:30.6343885Z   File "D:\a\cpython\cpython\lib\test\test_concurrent_futures.py", line 486, in test_cancel_futures_wait_false
2021-06-21T22:41:30.6344929Z     rc, out, err = assert_python_ok('-c', """if True:
2021-06-21T22:41:30.6345751Z   File "D:\a\cpython\cpython\lib\test\support\script_helper.py", line 160, in assert_python_ok
2021-06-21T22:41:30.6347111Z     return _assert_python(True, *args, **env_vars)
2021-06-21T22:41:30.6348114Z   File "D:\a\cpython\cpython\lib\test\support\script_helper.py", line 145, in _assert_python
2021-06-21T22:41:30.6348807Z     res.fail(cmd_line)
2021-06-21T22:41:30.6349473Z   File "D:\a\cpython\cpython\lib\test\support\script_helper.py", line 72, in fail
2021-06-21T22:41:30.6350312Z     raise AssertionError("Process return code is %d\n"
2021-06-21T22:41:30.6351066Z AssertionError: Process return code is 3221225477
2021-06-21T22:41:30.6353102Z command line: ['D:\\a\\cpython\\cpython\\PCbuild\\amd64\\python.exe', '-X', 'faulthandler', '-I', '-c', 'if True:\n            from concurrent.futures import ThreadPoolExecutor\n            from test.test_concurrent_futures import sleep_and_print\n            if __name__ == "__main__":\n                t = ThreadPoolExecutor()\n                t.submit(sleep_and_print, .1, "apple")\n                t.shutdown(wait=False, cancel_futures=True)\n            ']
2021-06-21T22:41:30.6354570Z 
2021-06-21T22:41:30.6354966Z stdout:
2021-06-21T22:41:30.6355350Z ---
2021-06-21T22:41:30.6355742Z apple
2021-06-21T22:41:30.6356133Z ---
2021-06-21T22:41:30.6356402Z 
2021-06-21T22:41:30.6356793Z stderr:
2021-06-21T22:41:30.6357161Z ---
2021-06-21T22:41:30.6357446Z 
2021-06-21T22:41:30.6357812Z ---
2021-06-21T22:41:30.6358099Z 
2021-06-21T22:41:30.6358545Z ======================================================================
2021-06-21T22:41:30.6359427Z FAIL: test_hang_issue39205 (test.test_concurrent_futures.ThreadPoolShutdownTest)
2021-06-21T22:41:30.6360495Z shutdown(wait=False) doesn't hang at exit with running futures.
2021-06-21T22:41:30.6361234Z ----------------------------------------------------------------------
2021-06-21T22:41:30.6361882Z Traceback (most recent call last):
2021-06-21T22:41:30.6362654Z   File "D:\a\cpython\cpython\lib\test\test_concurrent_futures.py", line 393, in test_hang_issue39205
2021-06-21T22:41:30.6363427Z     rc, out, err = assert_python_ok('-c', """if True:
2021-06-21T22:41:30.6364204Z   File "D:\a\cpython\cpython\lib\test\support\script_helper.py", line 160, in assert_python_ok
2021-06-21T22:41:30.6365084Z     return _assert_python(True, *args, **env_vars)
2021-06-21T22:41:30.6365860Z   File "D:\a\cpython\cpython\lib\test\support\script_helper.py", line 145, in _assert_python
2021-06-21T22:41:30.6366552Z     res.fail(cmd_line)
2021-06-21T22:41:30.6367198Z   File "D:\a\cpython\cpython\lib\test\support\script_helper.py", line 72, in fail
2021-06-21T22:41:30.6367976Z     raise AssertionError("Process return code is %d\n"
2021-06-21T22:41:30.6368677Z AssertionError: Process return code is 3221225477
2021-06-21T22:41:30.6371113Z command line: ['D:\\a\\cpython\\cpython\\PCbuild\\amd64\\python.exe', '-X', 'faulthandler', '-I', '-c', 'if True:\n            from concurrent.futures import ThreadPoolExecutor\n            from test.test_concurrent_futures import sleep_and_print\n            if __name__ == "__main__":\n                t = ThreadPoolExecutor(max_workers=3)\n                t.submit(sleep_and_print, 1.0, "apple")\n                t.shutdown(wait=False)\n            ']
2021-06-21T22:41:30.6372592Z 
2021-06-21T22:41:30.6373007Z stdout:
2021-06-21T22:41:30.6373379Z ---
2021-06-21T22:41:30.6373797Z apple
2021-06-21T22:41:30.6374176Z ---
2021-06-21T22:41:30.6374462Z 
2021-06-21T22:41:30.6374848Z stderr:
2021-06-21T22:41:30.6375301Z ---
2021-06-21T22:41:30.6375594Z 
2021-06-21T22:41:30.6375960Z ---
2021-06-21T22:41:30.6376249Z 
2021-06-21T22:41:30.6376805Z ----------------------------------------------------------------------
2021-06-21T22:41:30.6377249Z 
2021-06-21T22:41:30.6377686Z Ran 226 tests in 99.406s
2021-06-21T22:41:30.6378011Z 
2021-06-21T22:41:30.6378486Z FAILED (failures=2, skipped=111)
2021-06-21T22:41:30.6379080Z test test_concurrent_futures failed




test_regrtest also times out (related? side-effect?):

2021-06-21T23:00:47.1024847Z Timeout (0:20:00)!
2021-06-21T23:00:47.1025489Z Thread 0x0000140c (most recent call first):
2021-06-21T23:00:47.1026155Z   File "D:\a\cpython\cpython\lib\subprocess.py", line 1493 in _readerthread
2021-06-21T23:00:47.1026928Z   File "D:\a\cpython\cpython\lib\threading.py", line 946 in run
2021-06-21T23:00:47.1027633Z   File "D:\a\cpython\cpython\lib\threading.py", line 1009 in _bootstrap_inner
2021-06-21T23:00:47.1028402Z   File "D:\a\cpython\cpython\lib\threading.py", line 966 in _bootstrap
2021-06-21T23:00:47.1028829Z 
2021-06-21T23:00:47.1029247Z Thread 0x00001990 (most recent call first):
2021-06-21T23:00:47.1029942Z   File "D:\a\cpython\cpython\lib\threading.py", line 1099 in _wait_for_tstate_lock
2021-06-21T23:00:47.1030683Z   File "D:\a\cpython\cpython\lib\threading.py", line 1083 in join
2021-06-21T23:00:47.1031396Z   File "D:\a\cpython\cpython\lib\subprocess.py", line 1522 in _communicate
2021-06-21T23:00:47.1032178Z   File "D:\a\cpython\cpython\lib\subprocess.py", line 1148 in communicate
2021-06-21T23:00:47.1033029Z   File "D:\a\cpython\cpython\lib\subprocess.py", line 503 in run
2021-06-21T23:00:47.1033763Z   File "D:\a\cpython\cpython\lib\test\test_regrtest.py", line 522 in run_command
2021-06-21T23:00:47.1034561Z   File "D:\a\cpython\cpython\lib\test\test_regrtest.py", line 547 in run_python
2021-06-21T23:00:47.1035300Z   File "D:\a\cpython\cpython\lib\test\test_regrtest.py", line 602 in run_tests
2021-06-21T23:00:47.1036512Z   File "D:\a\cpython\cpython\lib\test\test_regrtest.py", line 649 in test_tools_script_run_tests
2021-06-21T23:00:47.1037383Z   File "D:\a\cpython\cpython\lib\unittest\case.py", line 549 in _callTestMethod
2021-06-21T23:00:47.1038111Z   File "D:\a\cpython\cpython\lib\unittest\case.py", line 592 in run
2021-06-21T23:00:47.1038827Z   File "D:\a\cpython\cpython\lib\unittest\case.py", line 652 in __call__
2021-06-21T23:00:47.1039511Z   File "D:\a\cpython\cpython\lib\unittest\suite.py", line 122 in run
2021-06-21T23:00:47.1040225Z   File "D:\a\cpython\cpython\lib\unittest\suite.py", line 84 in __call__
2021-06-21T23:00:47.1040890Z   File "D:\a\cpython\cpython\lib\unittest\suite.py", line 122 in run
2021-06-21T23:00:47.1041608Z   File "D:\a\cpython\cpython\lib\unittest\suite.py", line 84 in __call__
2021-06-21T23:00:47.1042317Z   File "D:\a\cpython\cpython\lib\unittest\suite.py", line 122 in run
2021-06-21T23:00:47.1042986Z   File "D:\a\cpython\cpython\lib\unittest\suite.py", line 84 in __call__
2021-06-21T23:00:47.1043715Z   File "D:\a\cpython\cpython\lib\unittest\runner.py", line 176 in run
2021-06-21T23:00:47.1044409Z   File "D:\a\cpython\cpython\lib\test\support\__init__.py", line 960 in _run_suite
2021-06-21T23:00:47.1045522Z   File "D:\a\cpython\cpython\lib\test\support\__init__.py", line 1083 in run_unittest
2021-06-21T23:00:47.1046305Z   File "D:\a\cpython\cpython\lib\test\libregrtest\runtest.py", line 210 in _test_module
2021-06-21T23:00:47.1047201Z   File "D:\a\cpython\cpython\lib\test\libregrtest\runtest.py", line 246 in _runtest_inner2
2021-06-21T23:00:47.1048077Z   File "D:\a\cpython\cpython\lib\test\libregrtest\runtest.py", line 282 in _runtest_inner
2021-06-21T23:00:47.1048889Z   File "D:\a\cpython\cpython\lib\test\libregrtest\runtest.py", line 141 in _runtest
2021-06-21T23:00:47.1049727Z   File "D:\a\cpython\cpython\lib\test\libregrtest\runtest.py", line 194 in runtest
2021-06-21T23:00:47.1050546Z   File "D:\a\cpython\cpython\lib\test\libregrtest\runtest_mp.py", line 81 in run_tests_worker
2021-06-21T23:00:47.1051374Z   File "D:\a\cpython\cpython\lib\test\libregrtest\main.py", line 661 in _main
2021-06-21T23:00:47.1052149Z   File "D:\a\cpython\cpython\lib\test\libregrtest\main.py", line 641 in main
2021-06-21T23:00:47.1052882Z   File "D:\a\cpython\cpython\lib\test\libregrtest\main.py", line 719 in main
2021-06-21T23:00:47.1053632Z   File "D:\a\cpython\cpython\lib\test\regrtest.py", line 43 in _main
2021-06-21T23:00:47.1054425Z   File "D:\a\cpython\cpython\lib\test\regrtest.py", line 47 in <module>
2021-06-21T23:00:47.1055141Z   File "D:\a\cpython\cpython\lib\runpy.py", line 86 in _run_code
2021-06-21T23:00:47.1055833Z   File "D:\a\cpython\cpython\lib\runpy.py", line 196 in _run_module_as_main
2021-06-21T23:00:47.1056566Z 0:22:23 load avg: 0.00 [427/427/2] test_regrtest crashed (Exit code 1)

----------
components: Tests
messages: 396312
nosy: erlendaasland
priority: normal
severity: normal
status: open
title: test_concurrent_futures: failure on Windows (x64)
versions: Python 3.11

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

From report at bugs.python.org  Tue Jun 22 04:42:57 2021
From: report at bugs.python.org (Chris Trent)
Date: Tue, 22 Jun 2021 08:42:57 +0000
Subject: [New-bugs-announce] [issue44485] TKinter docs page does not provide
 actual documentation
Message-ID: <1624351377.85.0.40142939191.issue44485@roundup.psfhosted.org>


New submission from Chris Trent <arkevorkhat at gmail.com>:

The documentation pages for the tkinter module are not actually documentation. They are tutorials, which belong on the wiki. "Documentation" is not documentation if it does not provide at bare minimum a structured list of all names exposed by the module's public interface. 

Python's official docs should be the sole authoritative source for full, complete, useful documentation of everything one could need to know about a module, but instead, We're forced to go to 3rd party sites of dubious provenance and questionable accuracy, instead of being able to just go to the source, and find a page to, I don't know, find out what kinds of panels we have to work with.

----------
assignee: docs at python
components: Documentation
messages: 396313
nosy: arkevorkhat, docs at python
priority: normal
severity: normal
status: open
title: TKinter docs page does not provide actual documentation
versions: Python 3.9

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

From report at bugs.python.org  Tue Jun 22 05:53:42 2021
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 22 Jun 2021 09:53:42 +0000
Subject: [New-bugs-announce] [issue44486] Modules should alway have a
 dictionary
Message-ID: <1624355622.79.0.135643740949.issue44486@roundup.psfhosted.org>


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

It is possible to create a module without a dictionary:
m = types.ModuleType.__new__(types.ModuleType)

But that is the only way to create to a module without a dict; all other means of creating a module, both in Python and in the C API, result in a fully formed module.

Existing code expects that modules will always have a dictionary, e.g.
https://github.com/python/cpython/blob/3.10/Include/internal/pycore_moduleobject.h#L35

We should change types.ModuleType.__new__ to properly initialize the module.

----------
assignee: Mark.Shannon
messages: 396316
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: Modules should alway have a dictionary
type: behavior

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

From report at bugs.python.org  Tue Jun 22 06:24:16 2021
From: report at bugs.python.org (Erik Faye-Lund)
Date: Tue, 22 Jun 2021 10:24:16 +0000
Subject: [New-bugs-announce] [issue44487] Regression
Message-ID: <1624357456.42.0.547216936781.issue44487@roundup.psfhosted.org>


New submission from Erik Faye-Lund <kusmabite at gmail.com>:

This commit lead to a regression when using Meson on Windows to build the Mesa project:

https://github.com/python/cpython/commit/4827483f47906fecee6b5d9097df2a69a293a85c

The reason is that pathlib.read_text now uses the locale as the encoding when reading files when there's no encoding explicitly passed in. That means that C++ source files are attempted read as CP1252 on Windows, which throws exceptions when source files contain UTF-8 code-points.

----------
components: Library (Lib)
messages: 396318
nosy: kusma
priority: normal
severity: normal
status: open
title: Regression
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Tue Jun 22 08:24:26 2021
From: report at bugs.python.org (NIKDISSV)
Date: Tue, 22 Jun 2021 12:24:26 +0000
Subject: [New-bugs-announce] [issue44488] ERROR: No matching distribution
 found for kivy
Message-ID: <1624364666.6.0.0593631097252.issue44488@roundup.psfhosted.org>


New submission from NIKDISSV <enikdissv-forever at protonmail.com>:

An error occurred when installing kiwi on python 3.10.0b3, on Python 3.9.5 there are no errors, but on 3.10 there are:

Collecting kivy
  Using cached Kivy-2.0.0.tar.gz (23.7 MB)
  Installing build dependencies ... error
  ERROR: Command errored out with exit status 1:
   command: 'c:\users\shikardosik\appdata\local\programs\python\python310\python.exe' 'C:\Users\shikardosik\AppData\Local\Temp\pip-standalone-pip-vfw34azi\__env_pip__.zip\pip' install --ignore-installed --no-user --prefix 'C:\Users\shikardosik\AppData\Local\Temp\pip-build-env-lxpt2_oy\overlay' --no-warn-script-location --no-binary :none: --only-binary :none: -i https://pypi.org/simple -- setuptools wheel 'cython>=0.24,<=0.29.21,!=0.27,!=0.27.2' 'kivy_deps.gstreamer_dev~=0.3.1; sys_platform == "win32"' 'kivy_deps.sdl2_dev~=0.3.1; sys_platform == "win32"' 'kivy_deps.glew_dev~=0.3.0; sys_platform == "win32"' 'kivy_deps.gstreamer~=0.3.1; sys_platform == "win32"' 'kivy_deps.sdl2~=0.3.1; sys_platform == "win32"' 'kivy_deps.glew~=0.3.0; sys_platform == "win32"'
       cwd: None
  Complete output (8 lines):
  Collecting setuptools
    Using cached setuptools-57.0.0-py3-none-any.whl (821 kB)
  Collecting wheel
    Using cached wheel-0.36.2-py2.py3-none-any.whl (35 kB)
  Collecting cython!=0.27,!=0.27.2,<=0.29.21,>=0.24
    Using cached Cython-0.29.21-py2.py3-none-any.whl (974 kB)
  ERROR: Could not find a version that satisfies the requirement kivy_deps.gstreamer_dev~=0.3.1 (from versions: none)
  ERROR: No matching distribution found for kivy_deps.gstreamer_dev~=0.3.1
  ----------------------------------------
WARNING: Discarding https://files.pythonhosted.org/packages/12/96/091ddacafb84dd18555a32d860dbfaf9c806147aa30c6f3c8b93cb7bab97/Kivy-2.0.0.tar.gz#sha256=d25e44eb44e43762b2fd0c5874e51954e0f1181fd9800d8a6756be6d084812d8 (from https://pypi.org/simple/kivy/). Command errored out with exit status 1: 'c:\users\shikardosik\appdata\local\programs\python\python310\python.exe' 'C:\Users\shikardosik\AppData\Local\Temp\pip-standalone-pip-vfw34azi\__env_pip__.zip\pip' install --ignore-installed --no-user --prefix 'C:\Users\shikardosik\AppData\Local\Temp\pip-build-env-lxpt2_oy\overlay' --no-warn-script-location --no-binary :none: --only-binary :none: -i https://pypi.org/simple -- setuptools wheel 'cython>=0.24,<=0.29.21,!=0.27,!=0.27.2' 'kivy_deps.gstreamer_dev~=0.3.1; sys_platform == "win32"' 'kivy_deps.sdl2_dev~=0.3.1; sys_platform == "win32"' 'kivy_deps.glew_dev~=0.3.0; sys_platform == "win32"' 'kivy_deps.gstreamer~=0.3.1; sys_platform == "win32"' 'kivy_deps.sdl2~=0.3.1; sys_platform == "win32"' 'kivy_deps.glew~=0.3.0; sys_platform == "win32"' Check the logs for full command output.
  Using cached Kivy-1.11.1.tar.gz (23.6 MB)

----------
components: Installation
messages: 396325
nosy: nikdissv_forever
priority: normal
severity: normal
status: open
title: ERROR: No matching distribution found for kivy
type: crash
versions: Python 3.10

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

From report at bugs.python.org  Tue Jun 22 08:57:06 2021
From: report at bugs.python.org (Ron Serruya)
Date: Tue, 22 Jun 2021 12:57:06 +0000
Subject: [New-bugs-announce] [issue44489] _handle_existing_loggers should
 respect loggers that were manually disabled
Message-ID: <1624366626.62.0.782556758458.issue44489@roundup.psfhosted.org>


New submission from Ron Serruya <ronserruya at gmail.com>:

The method `_handle_existing_loggers` in the logging lib (called when configuring loggers using dictConfig) iterates over all existing loggers and sets their .disabled attribute according to the `disable_existing_loggers` parameter (usually set to false)

However this only lets the user completely disable/enable all existing loggers, and there is no way to tell the function to keep the value to what it was

This example was how I found about it

1. Imported the pkg ddtrace, which writes some logs that I'm not interested in

2. Disabled the ddtrace logger 
`logging.getLogger('ddtrace.internal.writer').disabled = True`

3. Imported the pkg Sanic, which configures its logging using `logging.configure.dictConfig()`, with `disable_existing_loggers` set to False, as it doesn't want to disable all of the loggers that were created before it

4. `_handle_existing_loggers` re-enabled the logger that I manually disabled before



Ps. apologies if this is not the correct place, I don't really see this as a bug, more like a feature request, however the only place I found for feature requests were PEPs, which this obviously isnt

----------
components: Library (Lib)
messages: 396327
nosy: ronserruya2
priority: normal
severity: normal
status: open
title: _handle_existing_loggers should respect loggers that were manually disabled
versions: Python 3.8

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

From report at bugs.python.org  Tue Jun 22 09:29:59 2021
From: report at bugs.python.org (Ken Jin)
Date: Tue, 22 Jun 2021 13:29:59 +0000
Subject: [New-bugs-announce] [issue44490] PEP 604 Union (int | str) doesn't
 have __parameters__
Message-ID: <1624368599.83.0.338910210763.issue44490@roundup.psfhosted.org>


New submission from Ken Jin <kenjin4096 at gmail.com>:

Recently I noticed that the new PEP 604 Union type doesn't collect type variables:

from typing import TypeVar
T = TypeVar('T')

(int | list[T]).__parameters__

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'types.Union' object has no attribute '__parameters__'

Whereas the typing.Union version has __parameters__. Is this behavior intentional?

The downside to this is that things like this don't work:

alias: TypeAlias = int | list[T]
alias[str] # Error!

----------
messages: 396329
nosy: Jelle Zijlstra, gvanrossum, kj, levkivskyi
priority: normal
severity: normal
status: open
title: PEP 604 Union (int | str) doesn't have __parameters__
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Tue Jun 22 19:30:45 2021
From: report at bugs.python.org (Erlend E. Aasland)
Date: Tue, 22 Jun 2021 23:30:45 +0000
Subject: [New-bugs-announce] [issue44491] [sqlite3] allow clearing the
 authoriser callback
Message-ID: <1624404645.88.0.222168479229.issue44491@roundup.psfhosted.org>


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

Currently, it is possible to clear both the sqlite3 trace callback and progress handler by passing 'None' as the callback/handler, however it is not possible to clear the authoriser callback.

Suggesting to allow clearing the authoriser callback with set_authorizer(None).


See also https://sqlite.org/c3ref/set_authorizer.html

----------
assignee: erlendaasland
components: Extension Modules
messages: 396374
nosy: erlendaasland
priority: low
severity: normal
status: open
title: [sqlite3] allow clearing the authoriser callback
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Tue Jun 22 20:52:48 2021
From: report at bugs.python.org (Phil Thompson)
Date: Wed, 23 Jun 2021 00:52:48 +0000
Subject: [New-bugs-announce] [issue44492] Building a C extension on Big Sur
 and SDK v10.15 fails
Message-ID: <1624409568.36.0.590312520398.issue44492@roundup.psfhosted.org>


New submission from Phil Thompson <phil at riverbankcomputing.com>:

I am running macOS v11 (Big Sur) and using Xcode v12.1 (because this is the latest that includes SDK v10.15 rather than v11) to build a C extension. I'm using the older SDK because of 3rd party libraries that are not tested against the newer SDK.

This version of Xcode/SDK does not support universal2 binaries. However because _supports_arm64_builds() in _osx_support only tests the macOS version and not the SDK version it returns True which means that distutils does not call compiler_fixup() to remove the '-arch arm64'. The compilation then fails.

Should this work, or does Python v3.10 require SDK v11?

----------
components: Distutils
messages: 396377
nosy: dstufft, eric.araujo, philthompson10
priority: normal
severity: normal
status: open
title: Building a C extension on Big Sur and SDK v10.15 fails
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Tue Jun 22 23:08:23 2021
From: report at bugs.python.org (ty)
Date: Wed, 23 Jun 2021 03:08:23 +0000
Subject: [New-bugs-announce] [issue44493] Missing terminated NUL in the
 length of sockaddr_un
Message-ID: <1624417703.28.0.996748207886.issue44493@roundup.psfhosted.org>


New submission from ty <zonyitoo at gmail.com>:

https://github.com/python/cpython/blob/main/Modules/socketmodule.c#L1700

----------
components: Library (Lib)
messages: 396379
nosy: zonyitoo
priority: normal
severity: normal
status: open
title: Missing terminated NUL in the length of sockaddr_un
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue Jun 22 23:29:41 2021
From: report at bugs.python.org (Jack DeVries)
Date: Wed, 23 Jun 2021 03:29:41 +0000
Subject: [New-bugs-announce] [issue44494] Overhaul of
 Doc/library/__main__.rst
Message-ID: <1624418981.72.0.882162459841.issue44494@roundup.psfhosted.org>


New submission from Jack DeVries <jdevries3133 at gmail.com>:

I made a proposal on discourse to redraft Doc/library/__main__.rst as it is currently quite terse and there have been a series of bpo's asking for more. See my discourse post:

https://discuss.python.org/t/proposed-overhaul-of-main-py-documentation-doc-library-main-rst/9344
================
There have been many complaints about the shortcoming of the documentation
towards informing users about __main__. Both the popular __name__ == '__main__' construct, and the role of __main__.py in a python module.

bpo-17359
bpo-24632
bpo-38452

I propose a broad overhaul of Doc/library/__main__.rst to address these
shortcomings and to provide a single source of truth on __main__ (in
general!). This is an appropriate place to put this information.
Both the __name__ == '__main__' and fooModule/__main__.py
constructs reasonably fall under the category of ?Python Runtime Services,?
because they both control the way that programs run depending on how they are
used (command-line versus import versus running directly).

The new Doc/library/__main__.rst should have a new synopsis of, ?CLIs,
import-time behavior, and if __name__ == ?__main__??, reflecting its new and
broader focus.

Additionally, the new docs should have the following distinct sections:

    Differentiating between __name__ == ?__main__? and __main.__.py
    __main__.py and the -m flag (this is roughly what is there already, although
    it?s not as descriptive as it should be).
    __name__ and the if __name__ == '__main__' construct.

If there is interest, I would be happy to open uptake this work on as soon as there is
consensus around this plan. I?m looking forward to hearing what you think!
================

Anyway, I have a first draft ready. I'm sure there will be plenty of feedback, so let it rip! I will open a GitHub PR and attach it to this bpo in just a moment.

----------
assignee: docs at python
components: Documentation
messages: 396380
nosy: docs at python, jack__d
priority: normal
severity: normal
status: open
title: Overhaul of Doc/library/__main__.rst
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/issue44494>
_______________________________________

From report at bugs.python.org  Wed Jun 23 02:55:14 2021
From: report at bugs.python.org (Maciej Misiak)
Date: Wed, 23 Jun 2021 06:55:14 +0000
Subject: [New-bugs-announce] [issue44495] wrong FNAME in tarfile if tgz
 extension is used
Message-ID: <1624431314.4.0.407283752721.issue44495@roundup.psfhosted.org>


New submission from Maciej Misiak <maciej.mm.misiak at gmail.com>:

This code is incomplete:

def _init_write_gz(self):
...
    if self.name.endswith(".gz"):
        self.name = self.name[:-3]
    # RFC1952 says we must use ISO-8859-1 for the FNAME field.
    self.__write(self.name.encode("iso-8859-1", "replace") + NUL)

If it is used in following way '.gz' is stripped properly and FNAME='somefile.tar':
    tarfile.open('somefile.tar.gz', 'w:gz')
but with 
    tarfile.open('somefile.tgz', 'w:gz')

FNAME is incorrectly prepared as somefile.tgz

----------
components: Library (Lib)
messages: 396382
nosy: maciej.mm.misiak
priority: normal
severity: normal
status: open
title: wrong FNAME in tarfile if tgz extension is used
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/issue44495>
_______________________________________

From report at bugs.python.org  Wed Jun 23 03:26:04 2021
From: report at bugs.python.org (Aschwin)
Date: Wed, 23 Jun 2021 07:26:04 +0000
Subject: [New-bugs-announce] [issue44496] string.Formatter class not
 allowing {.field}
Message-ID: <1624433164.24.0.876705812645.issue44496@roundup.psfhosted.org>


New submission from Aschwin <aschwin at vanderwoude.info>:

I expected the custom Formatter to behave the same as the normal "".format() function, but unnamed args or not supported.
Below is an example, which fails at a KeyError.


from string import Formatter

class test():
    def __init__(self):
        self.msg = "OK"
t = test()

print("Normal format() is {.msg}".format(t))

f = Formatter()
print(f.format("Formatter.format() is {.msg}", t))

----------
components: Library (Lib)
messages: 396383
nosy: avdwoude
priority: normal
severity: normal
status: open
title: string.Formatter class not allowing {.field}
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Wed Jun 23 05:20:31 2021
From: report at bugs.python.org (Sorin Sbarnea)
Date: Wed, 23 Jun 2021 09:20:31 +0000
Subject: [New-bugs-announce] [issue44497] distutil findall can choke with
 recursive symlinks (performance)
Message-ID: <1624440031.78.0.268205320364.issue44497@roundup.psfhosted.org>


New submission from Sorin Sbarnea <sorin.sbarnea at gmail.com>:

As the results of investigating a very poor performance of pip while trying to install some code I was able to identify that the root cause was the current implementation of distutils.filelist.findall or to be more precise the _find_all_simple function, which does followsymlinks but without any measures for preventing recursivity and duplicates.

To give an idea in my case it was taking 5-10minutes to run while the CPU was at 100%, for a repository with 95k files (most of them temp inside .tox folders). Removal of the symlinks did make it run in ~5s.

IMHO, _find_all_simple should normalize paths and avoid returning any duplicates.


Realted: https://bugs.launchpad.net/pbr/+bug/1933311

----------
components: Distutils
messages: 396394
nosy: dstufft, eric.araujo, ssbarnea
priority: normal
severity: normal
status: open
title: distutil findall can choke with recursive symlinks (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/issue44497>
_______________________________________

From report at bugs.python.org  Wed Jun 23 05:59:41 2021
From: report at bugs.python.org (Irit Katriel)
Date: Wed, 23 Jun 2021 09:59:41 +0000
Subject: [New-bugs-announce] [issue44498] remove deprecated smtpd from the
 stdlib
Message-ID: <1624442381.98.0.346061734567.issue44498@roundup.psfhosted.org>


New submission from Irit Katriel <iritkatriel at gmail.com>:

smtpd uses asynchat which has been deprecated since 3.6.

See discussion at
https://mail.python.org/archives/list/python-committers at python.org/thread/KNF6YQE2O4OLJDNKSGAT4NLZUNCQ5QSH/#KNF6YQE2O4OLJDNKSGAT4NLZUNCQ5QSH

----------
messages: 396399
nosy: iritkatriel, vstinner
priority: normal
severity: normal
status: open
title: remove deprecated smtpd from the stdlib
versions: Python 3.11

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

From report at bugs.python.org  Wed Jun 23 09:18:18 2021
From: report at bugs.python.org (Erlend E. Aasland)
Date: Wed, 23 Jun 2021 13:18:18 +0000
Subject: [New-bugs-announce] [issue44499] [sqlite3] make sqlite3.Connection
 exception refs strong
Message-ID: <1624454298.48.0.88024552275.issue44499@roundup.psfhosted.org>


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

Currently, pysqlite_Connection keeps borrowed references to all the sqlite3 exception types. Suggesting to convert these to strong refs.

See comments on GH-26745: https://github.com/python/cpython/pull/26745#issuecomment-866810269

----------
assignee: erlendaasland
components: Extension Modules
messages: 396417
nosy: erlendaasland, petr.viktorin
priority: normal
severity: normal
status: open
title: [sqlite3] make sqlite3.Connection exception refs strong
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Wed Jun 23 12:37:14 2021
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 23 Jun 2021 16:37:14 +0000
Subject: [New-bugs-announce] [issue44500] Document changes to code object.
Message-ID: <1624466234.05.0.483369758939.issue44500@roundup.psfhosted.org>


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

We are making lots of changes to the code object.

We should clearly document all the changes in one place and explain the new design well before 3.11 beta.

----------
assignee: docs at python
components: Documentation
messages: 396432
nosy: Mark.Shannon, docs at python, eric.snow, gvanrossum
priority: normal
severity: normal
status: open
title: Document changes to code object.
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Wed Jun 23 14:13:42 2021
From: report at bugs.python.org (Batuhan Taskaya)
Date: Wed, 23 Jun 2021 18:13:42 +0000
Subject: [New-bugs-announce] [issue44501] Packing constant call arguments
Message-ID: <1624472022.52.0.0584361591595.issue44501@roundup.psfhosted.org>


New submission from Batuhan Taskaya <isidentical at gmail.com>:

It is a common scenario to make calls with only constant arguments (e.g to datetime.datetime/os.path.join/re.match.group/nox.session.run etc) and the bytecode that we currently generate looks like this;
f(1,2,3,4,5,6)
  1           0 LOAD_NAME                0 (f)
              2 LOAD_CONST               0 (1)
              4 LOAD_CONST               1 (2)
              6 LOAD_CONST               2 (3)
              8 LOAD_CONST               3 (4)
             10 LOAD_CONST               4 (5)
             12 LOAD_CONST               5 (6)
             14 CALL_FUNCTION            6
             16 POP_TOP
             18 LOAD_CONST               6 (None)
             20 RETURN_VALUE

But if we are sure that all arguments to a function is positional* (it is also possible to support keyword arguments to some extent, needs more research, but out of the scope for this particular optimization) and constant, then we could simply pack everything together and use CALL_FUNCTION_EX (we also need to set some limits, since when it is too little might prevent constant cache, and when it is too high might create giant tuples in the code object, perhaps 75 > N > 4)

  1           0 LOAD_NAME                0 (f)
              2 LOAD_CONST               0 ((1, 2, 3, 4, 5, 6))
              4 CALL_FUNCTION_EX         0
              6 POP_TOP
              8 LOAD_CONST               1 (None)
             10 RETURN_VALUE

The implementation is also very simple, and doesn't even touch anywhere beside the ast optimizer itself. It is possible to do this in the compiler, but that might complicate the logic so I'd say it is best to keep it as isolated as it can be.

(debug builds)

-s 'foo = lambda *args: None' 'foo("yyyyy", 123, 123321321312, (1,2,3), "yyyyy", 1.0, (1,2,3), "yyyyy", "yyyyy", (1,2,3), 5, 6, 7)'
Mean +- std dev: [master_artificial] 251 ns +- 2 ns -> [optimized_artificial] 185 ns +- 1 ns: 1.36x faster

-s 'from datetime import datetime' 'datetime(1997, 7, 27, 12, 10, 0, 0)'
Mean +- std dev: [master_datetime] 461 ns +- 1 ns -> [optimized_datetime] 386 ns +- 2 ns: 1.19x faster

One other potential candidate to this optimization is doing something similar in the CFG optimizer, and folding all contiguous LOAD_CONSTs (within some sort of limit ofc) into a single tuple load and then adding an UNPACK_SEQUENCE (which would replicate the effect). This is a poorer form, and I was only able to observe a speedup of 1.13x / 1.03x respectively on the benchmarks. The good thing about that optimization was that, first it was able to work with mixed parameters (so if you have some other types of expressions besides constants, but all constants follow each other, then it was able to optimize that case as well) and also it wasn't only for calls but rather all compiler cases where LOAD_CONST blocks were generated.

----------
assignee: BTaskaya
components: Interpreter Core
messages: 396437
nosy: BTaskaya, Mark.Shannon, pablogsal, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Packing constant call arguments
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Thu Jun 24 05:40:58 2021
From: report at bugs.python.org (zcpara)
Date: Thu, 24 Jun 2021 09:40:58 +0000
Subject: [New-bugs-announce] [issue44502] bla in
 cpython/Lib/test/test_sys_settrace.py
Message-ID: <1624527658.23.0.171750310771.issue44502@roundup.psfhosted.org>


New submission from zcpara <zhangchaospecial at gmail.com>:

In cpython/Lib/test/test_sys_settrace.py, there is a function:
1 def no_pop_blocks():
2    y = 1
3    while not y:
4        bla
5    x = 1

what does bla mean? bla is not defined anywhere. But the function can pass the compilation. bla is treated as a global name in symtable during compilation. Why does python allow this statement (line 4)? Will line 4 be deleted in the future? Or be replaced with pass?

----------
components: Tests
messages: 396465
nosy: zhangchaospecial
priority: normal
severity: normal
status: open
title: bla in cpython/Lib/test/test_sys_settrace.py
versions: Python 3.11

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

From report at bugs.python.org  Thu Jun 24 07:08:55 2021
From: report at bugs.python.org (Pierre Ossman)
Date: Thu, 24 Jun 2021 11:08:55 +0000
Subject: [New-bugs-announce] [issue44503] Hide __enter__ calls in mock_open
Message-ID: <1624532935.8.0.760752273219.issue44503@roundup.psfhosted.org>


New submission from Pierre Ossman <ossman at cendio.se>:

I'd like to write this test case:

  with patch('builtins.open') as pyopen:
    mock_open(pyopen, read_data="foo")
    run()
    pyopen.assert_has_calls([call("filename", "wt"),
                             call().write("gazonk"),
                             call().close()])

and I shouldn't have to care if the code is written like this:

  def run():
    f = open("filename", "wt")
    try:
      write("gazonk")
    finally:
      f.close()

or like this:

  def run():
    with open("filename", "wt") as f:
      write("gazonk")

----------
components: Library (Lib)
messages: 396469
nosy: CendioOssman
priority: normal
severity: normal
status: open
title: Hide __enter__ calls in mock_open
type: enhancement

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

From report at bugs.python.org  Thu Jun 24 08:22:21 2021
From: report at bugs.python.org (Yevhen Kuzmovych)
Date: Thu, 24 Jun 2021 12:22:21 +0000
Subject: [New-bugs-announce] [issue44504] Typo in the docstring of
 Mapping.get method
Message-ID: <1624537341.91.0.397818097073.issue44504@roundup.psfhosted.org>


New submission from Yevhen Kuzmovych <kuzmovich.goog at gmail.com>:

The comment of `Mapping.get` method should state

'D.get(k[,d]) -> D[k] if k in D else d.  d defaults to None.'

instead of 

'D.get(k[,d]) -> D[k] if k in D, else d.  d defaults to None.' (note the comma before `else`.

----------
components: Library (Lib)
messages: 396478
nosy: kuzmovich.goog
priority: normal
severity: normal
status: open
title: Typo in the docstring of Mapping.get method
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/issue44504>
_______________________________________

From report at bugs.python.org  Thu Jun 24 11:36:41 2021
From: report at bugs.python.org (zcpara)
Date: Thu, 24 Jun 2021 15:36:41 +0000
Subject: [New-bugs-announce] [issue44505] loop invariant code motion
Message-ID: <1624549001.38.0.871680374624.issue44505@roundup.psfhosted.org>


New submission from zcpara <zhangchaospecial at gmail.com>:

It is a common scenario to call functions in loop, such as
def foo():
  for i in range(10):
    len("abc")
Currently, we generate bytecode like this;
2           0 SETUP_LOOP              24 (to 26)
              2 LOAD_GLOBAL              0 (range)
              4 LOAD_CONST               1 (10)
              6 CALL_FUNCTION            1
              8 GET_ITER
        >>   10 FOR_ITER                12 (to 24)
             12 STORE_FAST               0 (i)

  3          14 LOAD_GLOBAL              1 (len)
             16 LOAD_CONST               2 ('abc')
             18 CALL_FUNCTION            1
             20 POP_TOP
             22 JUMP_ABSOLUTE           10
        >>   24 POP_BLOCK
        >>   26 LOAD_CONST               0 (None)
             28 RETURN_VALUE
If we can make sure len is a loop invariant, we can generate code as follows. Only one LOAD_GLOBAL len is executed before the loop. LOAD_GLOBAL len is replaced with LOAD_FAST __local__len in the loop.
2           0 LOAD_GLOBAL              0 (range)
              2 LOAD_CONST               1 (10)
              4 CALL_FUNCTION            1
              6 GET_ITER
              8 LOAD_GLOBAL              1 (len)
             10 STORE_FAST               1 (__local__len)
        >>   12 FOR_ITER                 6 (to 26)
             14 STORE_FAST               0 (i)

  3          16 LOAD_FAST                1 (__local__len)
             18 LOAD_CONST               2 ('abc')
             20 CALL_FUNCTION            1
             22 POP_TOP
             24 JUMP_ABSOLUTE            6 (to 12)

  2     >>   26 LOAD_CONST               0 (None)
             28 RETURN_VALU

I prototyped this optimization and gain 4.6% performance improvement on regex_v8 of PyPerformance. Currently, only the global invariants are moved out of the loop. There are some other loop invariants can be moved. Other optimizations such as function inline can provide more opportunities for LICM.
I meet a problem with the following case;
1 def no_pop_blocks():
2    y = 1
3    while not y:
4        bla
5    x = 1

bla is not defined anywhere. With LICM, LOAD_GLOBAL bla will be move out of the loop. Then it executes with an error: bla is not defined.

----------
components: Interpreter Core
messages: 396496
nosy: zhangchaospecial
priority: normal
severity: normal
status: open
title: loop invariant code motion
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Thu Jun 24 12:53:10 2021
From: report at bugs.python.org (Erlend E. Aasland)
Date: Thu, 24 Jun 2021 16:53:10 +0000
Subject: [New-bugs-announce] [issue44506] test_asyncio:
 test_sendfile_close_peer_in_the_middle_of_receiving fails on Windows x64
 and x86
Message-ID: <1624553590.23.0.0289077713667.issue44506@roundup.psfhosted.org>


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

https://github.com/python/cpython/runs/2905621215:
2021-06-24T14:18:23.3772681Z ======================================================================
2021-06-24T14:18:23.3773622Z FAIL: test_sendfile_close_peer_in_the_middle_of_receiving (test.test_asyncio.test_sendfile.ProactorEventLoopTests)
2021-06-24T14:18:23.3774665Z ----------------------------------------------------------------------
2021-06-24T14:18:23.3775258Z Traceback (most recent call last):
2021-06-24T14:18:23.3776123Z   File "D:\a\cpython\cpython\lib\test\test_asyncio\test_sendfile.py", line 457, in test_sendfile_close_peer_in_the_middle_of_receiving
2021-06-24T14:18:23.3777065Z     with self.assertRaises(ConnectionError):
2021-06-24T14:18:23.3777775Z AssertionError: ConnectionError not raised
2021-06-24T14:18:23.3778226Z 
2021-06-24T14:18:23.3778744Z ----------------------------------------------------------------------
2021-06-24T14:18:23.3779161Z 
2021-06-24T14:18:23.3779555Z Ran 2022 tests in 54.341s
2021-06-24T14:18:23.3779870Z 
2021-06-24T14:18:23.3780352Z FAILED (failures=1, skipped=63)
2021-06-24T14:18:23.3780890Z test test_asyncio failed


https://github.com/python/cpython/runs/2906141524:
2021-06-24T15:23:11.7177493Z ======================================================================
2021-06-24T15:23:11.7178338Z FAIL: test_sendfile_close_peer_in_the_middle_of_receiving (test.test_asyncio.test_sendfile.ProactorEventLoopTests)
2021-06-24T15:23:11.7179234Z ----------------------------------------------------------------------
2021-06-24T15:23:11.7179754Z Traceback (most recent call last):
2021-06-24T15:23:11.7180469Z   File "D:\a\cpython\cpython\lib\test\test_asyncio\test_sendfile.py", line 457, in test_sendfile_close_peer_in_the_middle_of_receiving
2021-06-24T15:23:11.7181284Z     with self.assertRaises(ConnectionError):
2021-06-24T15:23:11.7182125Z AssertionError: ConnectionError not raised
2021-06-24T15:23:11.7182560Z 
2021-06-24T15:23:11.7183334Z ----------------------------------------------------------------------
2021-06-24T15:23:11.7183839Z

----------
components: Tests, asyncio
messages: 396502
nosy: asvetlov, erlendaasland, yselivanov
priority: normal
severity: normal
status: open
title: test_asyncio: test_sendfile_close_peer_in_the_middle_of_receiving fails on Windows x64 and x86
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Thu Jun 24 17:41:29 2021
From: report at bugs.python.org (Glenn Travis)
Date: Thu, 24 Jun 2021 21:41:29 +0000
Subject: [New-bugs-announce] [issue44507] Favor needed ASAP
Message-ID: <1624570889.78.0.11284349672.issueNone@roundup.psfhosted.org>


New submission from Glenn Travis <pbfuddle at comcast.net>:

- This mail is in HTML. Some elements may be ommited in plain text. -

Hi to you!
Need a favor from you, do you have an account with Amazon?
Glenn Travis

----------
messages: 396511
nosy: Old Sub Sailor
priority: normal
severity: normal
status: open
title: Favor needed ASAP

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

From report at bugs.python.org  Fri Jun 25 08:00:15 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 25 Jun 2021 12:00:15 +0000
Subject: [New-bugs-announce] [issue44508] asyncio: document failure mode for
 loop.call_soon_threadsafe
Message-ID: <1624622415.86.0.725571040455.issue44508@roundup.psfhosted.org>


New submission from Mark Dickinson <dickinsm at gmail.com>:

`loop.call_soon_threadsafe` raises `RuntimeError` when the event loop has been closed, but that fact doesn't seem to be documented. It would be useful to document it so that that it's clear that that behaviour is part of the API, and can be depended on.

Doc link: I'm looking at https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.loop.call_soon_threadsafe

My use-case is that I have a background thread that's making use of `loop.call_soon_threadsafe` to place callbacks onto the main thread's event loop. The main thread at some point closes that event loop (e.g., as part of controlled application shutdown, or in the tearDown of a unit test). The background thread isn't in a position to know whether the event loop has been closed or not, and obviously checking that using the `is_closed` attribute runs into race condition issues. So I'd like to catch the potential exception from the `loop.call_soon_threadsafe`, but to do that I need to know what exception type to catch.

It would probably also make sense to document the failure mode for `loop.call_soon`.

----------
assignee: docs at python
components: Documentation, asyncio
messages: 396523
nosy: asvetlov, docs at python, mark.dickinson, yselivanov
priority: normal
severity: normal
status: open
title: asyncio: document failure mode for loop.call_soon_threadsafe
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Fri Jun 25 16:11:24 2021
From: report at bugs.python.org (alex rakowski)
Date: Fri, 25 Jun 2021 20:11:24 +0000
Subject: [New-bugs-announce] [issue44509] Build in type alias for paths
Message-ID: <1624651884.63.0.0362769234249.issue44509@roundup.psfhosted.org>


New submission from alex rakowski <alexrakowski90 at gmail.com>:

Hello,

I've noticed that when type hinting paths, it often becomes a bit verbose:

from typing import Union
import pathlib 

custom_path = Union[str, pathlib.Path]

def foobar(x:custom_path):
   ...
Writing functions which handle paths are pretty routine, I'm wondering if it is worth including something that is importable e.g.

from typing import PathLike #or similar path_obj, PathType etc. 
def foobar(x:PathLike):
 ...

Apologies if similar functionality already exists,

Alex

----------
components: Library (Lib)
messages: 396526
nosy: arakowski
priority: normal
severity: normal
status: open
title: Build in type alias for paths
type: enhancement
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Fri Jun 25 19:06:12 2021
From: report at bugs.python.org (Rohan Amin)
Date: Fri, 25 Jun 2021 23:06:12 +0000
Subject: [New-bugs-announce] [issue44510] file.read() UnicodeDecodeError
 with large files on Windows
Message-ID: <1624662372.97.0.0432881469482.issue44510@roundup.psfhosted.org>


New submission from Rohan Amin <aminrohan64 at gmail.com>:

When using file.read() with a large text file,  
there is a UnicodeDecodeError. I expected file.read(1) to read one character from the file. It works with a smaller text file. I experienced this bug on  Windows 10 version 20H2. My teacher couldn't reproduce this bug on Linux.

----------
components: IO, Unicode, Windows
files: Bug Reproduction Code.zip
messages: 396532
nosy: RohanA, ezio.melotti, paul.moore, steve.dower, tim.golden, vstinner, zach.ware
priority: normal
severity: normal
status: open
title: file.read() UnicodeDecodeError with large files on Windows
type: behavior
versions: Python 3.6, Python 3.9
Added file: https://bugs.python.org/file50126/Bug Reproduction Code.zip

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

From report at bugs.python.org  Fri Jun 25 20:12:00 2021
From: report at bugs.python.org (Brandt Bucher)
Date: Sat, 26 Jun 2021 00:12:00 +0000
Subject: [New-bugs-announce] [issue44511] Improve the bytecode for mapping
 patterns
Message-ID: <1624666320.05.0.738166042939.issue44511@roundup.psfhosted.org>


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

The generated bytecode for mapping patterns is more complicated than it needs to be:

- Matching sub-patterns involves indexing into a tuple of values in order to extract them. We already know the size of this tuple at compile-time, so we can just unpack it onto the stack instead.

- COPY_DICT_WITHOUT_KEYS isn't used anywhere else, and can be emulated with existing, smaller instructions (albeit using quite a few of them).

- MATCH_KEYS doesn't need to push a boolean indicating match / no match. It already pushes None on no match, so following it with a simple DUP_TOP() + LOAD_CONST(None) + IS_OP(1) should suffice.

These are mostly just refactoring opportunities... quick-and-dirty measurements of Lib/test_patma.py show no performance impact for these changes.

----------
assignee: brandtbucher
components: Interpreter Core
messages: 396533
nosy: brandtbucher
priority: normal
severity: normal
status: open
title: Improve the bytecode for mapping patterns
versions: Python 3.11

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

From report at bugs.python.org  Fri Jun 25 22:32:57 2021
From: report at bugs.python.org (Andrei Kulakov)
Date: Sat, 26 Jun 2021 02:32:57 +0000
Subject: [New-bugs-announce] [issue44512] csv.DictWriter: inconsistency in
 handling of extrasaction arg
Message-ID: <1624674777.38.0.50893926031.issue44512@roundup.psfhosted.org>


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

In csv.DictWriter, the arg `extrasaction` case is handled inconsistently:

- if it's misspelled, e.g. ignor instead of 'ignore', a ValueError is raised by the __init__ method.

- if it's 'Ignore', 'IGNORE', it will work properly

- if it's 'raise', it will also work properly

- BUT: if it's 'Raise' or 'RAISE', it will have the same effect as 'ignore'

The code is here: https://github.com/python/cpython/blob/main/Lib/csv.py#L135-L146


[ins] In [1]: from csv import DictWriter

[ins] In [4]: d=DictWriter(open('testcsv','w'),'abc',extrasaction='IGNORE')

[ins] In [5]: list(d._dict_to_list(dict(d=1)))
Out[6]: ['', '', '']

[ins] In [7]: d=DictWriter(open('testcsv','w'),'abc',extrasaction='RAISE')

[ins] In [8]: list( d._dict_to_list(dict(d=1)) )
Out[8]: ['', '', '']

[ins] In [9]: d=DictWriter(open('testcsv','w'),'abc',extrasaction='TEST')
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-9-953d1100c7f9> in <module>
----> 1 d=DictWriter(open('testcsv','w'),'abc',extrasaction='TEST')

/usr/local/Cellar/python at 3.9/3.9.1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/csv.py in __init__(self, f, fieldnames, restval, extrasaction, dialect, *args, **kwds)
    134         self.restval = restval          # for writing short dicts
    135         if extrasaction.lower() not in ("raise", "ignore"):
--> 136             raise ValueError("extrasaction (%s) must be 'raise' or 'ignore'"
    137                              % extrasaction)
    138         self.extrasaction = extrasaction

ValueError: extrasaction (TEST) must be 'raise' or 'ignore'


[ins] In [10]: d=DictWriter(open('testcsv','w'),'abc',extrasaction='raise')

[ins] In [11]: list( d._dict_to_list(dict(d=1)) )
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-11-1fde207e1805> in <module>
----> 1 list( d._dict_to_list(dict(d=1)) )

/usr/local/Cellar/python at 3.9/3.9.1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/csv.py in _dict_to_list(self, rowdict)
    147             wrong_fields = rowdict.keys() - self.fieldnames
    148             if wrong_fields:
--> 149                 raise ValueError("dict contains fields not in fieldnames: "
    150                                  + ", ".join([repr(x) for x in wrong_fields]))
    151         return (rowdict.get(key, self.restval) for key in self.fieldnames)

ValueError: dict contains fields not in fieldnames: 'd'


----
I propose to accept any case of Raise, RAISE, etc, to have the effect of 'raise'.

I can put up the PR if that sounds good.

----------
components: Library (Lib)
messages: 396536
nosy: andrei.avk
priority: normal
severity: normal
status: open
title: csv.DictWriter: inconsistency in handling of extrasaction arg
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Sat Jun 26 00:22:23 2021
From: report at bugs.python.org (redrose2100)
Date: Sat, 26 Jun 2021 04:22:23 +0000
Subject: [New-bugs-announce] [issue44513] for string methods strip, lstrip,
 rstrip, when param is a string which has more than one char,
 those methods is no useful currently
Message-ID: <1624681343.46.0.141247598588.issue44513@roundup.psfhosted.org>


New submission from redrose2100 <hitredrose at 163.com>:

for string methods strip, lstrip, rstrip, when param is a string which has more than 1 char, currently those methods remove char ,but not remove string , it is no useful

following is the results in python 3.9.5

Python 3.9.5 (default, May 18 2021, 14:42:02) [MSC v.1916 64 bit (AMD64)] :: Anaconda, Inc. on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> s="hellolloehb"
>>> print(s.lstrip("hello"))
b
>>> s="blloehhello"
>>> print(s.rstrip("hello"))
b
>>> s="helloehhollbllohhehello"
>>> print(s.strip("hello"))
b
>>>
In fact,
when s="hellolloehb" , s.lstrip("hello") expect to get "lloehb"
when s="blloehhello" , s.rstrip("hello") expect to get "blloeh"
when s="helloehhollbllohhehello" , s.strip("hello") expect to get "ehhollbllohhe"

----------
components: Library (Lib)
messages: 396538
nosy: redrose2100
priority: normal
severity: normal
status: open
title: for string methods strip, lstrip, rstrip, when param is a string which has more than one char, those methods is no useful currently
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Sat Jun 26 02:01:54 2021
From: report at bugs.python.org (Kevin Follstad)
Date: Sat, 26 Jun 2021 06:01:54 +0000
Subject: [New-bugs-announce] [issue44514] configparser.rst & bz2.rst leave
 temp files after 'make doctest'
Message-ID: <1624687314.08.0.619588014681.issue44514@roundup.psfhosted.org>


New submission from Kevin Follstad <kfollstad at gmail.com>:

Both Docs/library/configparser.rst and Docs/library/bz2.rst create untracked temp files on the filesystem when 'make doctest' is run because testcleanup directives are absent in these files.

----------
assignee: docs at python
components: Documentation
messages: 396541
nosy: docs at python, kfollstad
priority: normal
severity: normal
status: open
title: configparser.rst & bz2.rst leave temp files after 'make doctest'
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/issue44514>
_______________________________________

From report at bugs.python.org  Sat Jun 26 04:30:11 2021
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 26 Jun 2021 08:30:11 +0000
Subject: [New-bugs-announce] [issue44515] contextlib test incompatibility
 with non-refcounted GC
Message-ID: <1624696211.08.0.171107948528.issue44515@roundup.psfhosted.org>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

Backporting the latest contextlib module and test suite to contextlib2, I ran into a couple of CI failures on PyPy3.

Investigation showed that a couple of the new test cases were assuming the use of a refcounted GC. One could be fixed by switching to using a synchronous context manager instead of a ``__del__`` method, but the other needed a few explicit gc.collect() calls.

----------
assignee: ncoghlan
keywords: 3.10regression
messages: 396545
nosy: ncoghlan, yselivanov
priority: normal
severity: normal
stage: commit review
status: open
title: contextlib test incompatibility with non-refcounted GC
type: behavior

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

From report at bugs.python.org  Sat Jun 26 05:22:10 2021
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Bidoul?=)
Date: Sat, 26 Jun 2021 09:22:10 +0000
Subject: [New-bugs-announce] [issue44516] Update bundled pip to 21.1.3
Message-ID: <1624699330.3.0.716498297863.issue44516@roundup.psfhosted.org>


Change by St?phane Bidoul <stephane.bidoul at acsone.eu>:


----------
nosy: sbidoul
priority: normal
severity: normal
status: open
title: Update bundled pip to 21.1.3
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Sat Jun 26 05:23:40 2021
From: report at bugs.python.org (Erlend E. Aasland)
Date: Sat, 26 Jun 2021 09:23:40 +0000
Subject: [New-bugs-announce] [issue44517] test__xxsubinterpreters: AMD64
 Fedora Stable 3.x buildbot aborts at test_still_running
Message-ID: <1624699420.1.0.797294128445.issue44517@roundup.psfhosted.org>


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

Builder: https://buildbot.python.org/all/#/builders/543

The buildbot has failed since 0982ded179f280176868c1c4eccf77bf70687816:
bpo-44032: Move pointer to code object from frame-object to frame specials array. (GH-26771)

Test stdio log attached.

----------
components: Subinterpreters, Tests
files: test-stdio.txt
messages: 396546
nosy: Mark.Shannon, erlendaasland, pablogsal, vstinner
priority: normal
severity: normal
status: open
title: test__xxsubinterpreters: AMD64 Fedora Stable 3.x buildbot aborts at test_still_running
type: crash
versions: Python 3.11
Added file: https://bugs.python.org/file50127/test-stdio.txt

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

From report at bugs.python.org  Sun Jun 27 05:11:32 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 27 Jun 2021 09:11:32 +0000
Subject: [New-bugs-announce] [issue44518] Finalization of non-exhausted
 asynchronous generators is deferred
Message-ID: <1624785092.65.0.844977946345.issue44518@roundup.psfhosted.org>


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

In the following example:

def gen():
    try:
        yield 1
    finally:
        print('finalize inner')

def func():
    try:
        for x in gen():
            break
    finally:
        print('finalize outer')

func()
print('END')

the output in CPython is:

finalize inner
finalize outer
END


But in similar example for asynchronous generator:

async def gen():
    try:
        yield 1
    finally:
        print('finalize inner')

async def func():
    try:
        async for x in gen():
            break
    finally:
        print('finalize outer')

import asyncio
asyncio.run(func())
print('END')

the output in CPython is:

finalize outer
finalize inner
END

There is a strong link somewhere which prevents finalization of the asynchronous generator object until leaving the outer function.

Tested on CPython 3.7-3.11. In PyPy "finalize inner" is not printed at all. Using closing() and aclosing() is the right way to get deterministic finalization, but in any case it would be better to get rid of strong link which prevents finalization of the asynchronous generator object.

----------
components: Interpreter Core
messages: 396569
nosy: Mark.Shannon, asvetlov, gvanrossum, serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: Finalization of non-exhausted asynchronous generators is deferred
type: resource usage
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Sun Jun 27 10:28:32 2021
From: report at bugs.python.org (David Lambert)
Date: Sun, 27 Jun 2021 14:28:32 +0000
Subject: [New-bugs-announce] [issue44519] help(math.fabs)
Message-ID: <1624804112.12.0.943654144.issue44519@roundup.psfhosted.org>


New submission from David Lambert <b49p23tivg at gmail.com>:

math.fabs returns float.
The documentation should say so, and help(math.fabs) should include the expected return type  -> float

fabs(x, /) -> float
    Return the absolute value of the float x.

I did not check, but expect these annotations recommendations are pervasive throughout the python libraries.

----------
assignee: docs at python
components: Documentation
messages: 396582
nosy: David Lambert, docs at python
priority: normal
severity: normal
status: open
title: help(math.fabs)
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Mon Jun 28 04:25:44 2021
From: report at bugs.python.org (=?utf-8?b?0J7Qu9C10LMg0JzQsNGB0LvQvg==?=)
Date: Mon, 28 Jun 2021 08:25:44 +0000
Subject: [New-bugs-announce] [issue44520] exception is thrown if bs = None
Message-ID: <1624868744.26.0.26782984577.issue44520@roundup.psfhosted.org>


New submission from ???? ????? <asicscwcs at gmail.com>:

need moved the check parameter to the top of the isnstance check, because if bs = None then an exception is thrown

----------
components: Library (Lib)
messages: 396617
nosy: asicscwcs
priority: normal
pull_requests: 25500
severity: normal
status: open
title: exception is thrown if  bs = None
type: crash
versions: Python 3.9

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

From report at bugs.python.org  Mon Jun 28 05:58:50 2021
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Mon, 28 Jun 2021 09:58:50 +0000
Subject: [New-bugs-announce] [issue44521] str.removeprefix(): add strict:
 bool
Message-ID: <1624874330.53.0.57173423417.issue44521@roundup.psfhosted.org>


New submission from ???? ????????? <socketpair at gmail.com>:

#39939 introduced .removeprefix for several classes. I propose adding kwargs-only parameter `, *, strict: bool = False`. It should raise some exception (I'm unuse what exactly) if the string DOES NOT start from specified prefix. False by default only for compatibility purposes. Personally I think it should be True, but I understand why it's impossible to change API.

The same about `removesuffix()`.

----------
components: Interpreter Core, Library (Lib)
messages: 396627
nosy: socketpair
priority: normal
severity: normal
status: open
title: str.removeprefix(): add strict: bool
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Mon Jun 28 09:06:46 2021
From: report at bugs.python.org (Bupjae Lee)
Date: Mon, 28 Jun 2021 13:06:46 +0000
Subject: [New-bugs-announce] [issue44522] [doc] open() function
 errors='surrogateescape' has inaccurate information
Message-ID: <1624885606.68.0.537794724905.issue44522@roundup.psfhosted.org>


New submission from Bupjae Lee <bupjae at gmail.com>:

https://docs.python.org/3/library/functions.html#open

error parameter of open() function says this:

'surrogateescape' will represent any incorrect bytes as code points in the Unicode Private Use Area ranging from U+DC80 to U+DCFF.


However, U+DC80 to U+DCFF doesn't belong to "Unicode Private Use Area"; it belongs to "Low Surrogate Area".



Suggested fix:

'surrogateescape' will represent any incorrect bytes as (unpaired) low surrogate code units ranging from U+DC80 to U+DCFF.

----------
assignee: docs at python
components: Documentation
messages: 396632
nosy: bupjae2, docs at python
priority: normal
severity: normal
status: open
title: [doc] open() function errors='surrogateescape' has inaccurate information
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/issue44522>
_______________________________________

From report at bugs.python.org  Mon Jun 28 10:15:05 2021
From: report at bugs.python.org (Alexander Neumann)
Date: Mon, 28 Jun 2021 14:15:05 +0000
Subject: [New-bugs-announce] [issue44523] weakref.proxy documentation might
 be outdated
Message-ID: <1624889705.43.0.546367758127.issue44523@roundup.psfhosted.org>


New submission from Alexander Neumann <aleneum at gmail.com>:

The documentation currently states:

> Proxy objects are not hashable regardless of the referent; this avoids a number of problems related to their fundamentally mutable nature, and prevent their use as dictionary keys. callback is the same as the parameter of the same name to the ref() function.

However, it seems with commit 96074de573f82fc66a2bd73c36905141a3f1d5c1 (https://github.com/python/cpython/commit/96074de573f82fc66a2bd73c36905141a3f1d5c1) hash/reversed pass throughs have been introduced that enable weakref.proxy to be used as a dictionary key. At least the following code fails with Python 3.8 but works with Python 3.9:

```
import weakref


class Model:
    pass


m = Model()
proxy = weakref.proxy(m)
ref = weakref.ref(m)
print(hash(m))
print(hash(ref))
print(hash(proxy))
```

----------
assignee: docs at python
components: Documentation
messages: 396637
nosy: aleneum, docs at python
priority: normal
severity: normal
status: open
title: weakref.proxy documentation might be outdated
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Mon Jun 28 10:15:33 2021
From: report at bugs.python.org (Lars)
Date: Mon, 28 Jun 2021 14:15:33 +0000
Subject: [New-bugs-announce] [issue44524] __name__ attribute in typing module
Message-ID: <1624889733.91.0.716738825713.issue44524@roundup.psfhosted.org>


New submission from Lars <gemerden at gmail.com>:

I noticed some (perhaps intentional) oddities with the __name__ attribute:

 - typing classes like Any (subclass of _SpecialForm) do not have a __name__ attribute,
 - abstract base classes in typing, like MutableSet do not have a __name__ attribute,
 - 'ChainMap', 'Counter', 'OrderedDict' do not have a __name__ attribute when imported from typing, but do when imported from collections.

I have written a function to show presence/absence if the name __name__ attribute:

def split_module_names(module):
    unnamed, named = set(), set()
    for name in dir(module):
        if not name.startswith('_'):
            attr = getattr(module, name)
            try:
                if hasattr(attr, '__name__'):
                    named.add(name)
                else:
                    unnamed.add(name)
            except TypeError:
                pass
    return named, unnamed

import typing
import collections

typing_named, typing_unnamed = split_module_names(typing)
collec_named, collec_unnamed = split_module_names(collections)

print("typing_unnamed:", typing_unnamed)
print("collec_named & typing_unnamed:", collec_named & typing_unnamed)

Is this intentional? It seems a little inconsistent.

I also found something that sometimes the __name__ attribute does resolve:

class S(typing.Sized):
        def __len__(self):
            return 0

print("'Sized' in typing_unnamed:", 'Sized' in typing_unnamed)
print("[t.__name__ for t in S.__mro__]:", [t.__name__ for t in S.__mro__])  # here __name__ is resolved!
print("getattr(typing.Sized, '__name__', None):", getattr(typing.Sized, '__name__', None))

printing:

'Sized' in typing_unnamed: True
[t.__name__ for t in S.__mro__]: ['S', 'Sized', 'Generic', 'object']
getattr(typing.Sized, '__name__', None): None

----------
messages: 396638
nosy: farcat
priority: normal
severity: normal
status: open
title: __name__ attribute in typing module
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Mon Jun 28 10:22:18 2021
From: report at bugs.python.org (Ken Jin)
Date: Mon, 28 Jun 2021 14:22:18 +0000
Subject: [New-bugs-announce] [issue44525] Implement CALL_FUNCTION adaptive
 interpreter optimizations
Message-ID: <1624890138.2.0.824780513801.issue44525@roundup.psfhosted.org>


New submission from Ken Jin <kenjin4096 at gmail.com>:

CALL_FUNCTION can be specialized. Copying from Mark's comments https://github.com/faster-cpython/ideas/issues/54#issue-898013125

```
There are a number of specializations of CALL_FUNCTION that make sense:

1. Calls to a Python function where the arguments and parameters match exactly.
2. Calls to a Python function with keyword arguments, or defaults, when the argument shuffle can be pre-computed.
3. Calls to builtin functions.
4. Calls to specific builtin functions, specifically len and instance.
5. Calls to type with a single argument.
6. Instantiation of a "normal" class, that is a class that does not redefine __new__ and whose metaclass is type.
```

I've prepared a PR that should speed up non-keyword calls to PyCFunction. It covers specializations 3 and 4. Stable pyperf microbenchmarks show 5-15% less call overhead for some PyCFunctions. Please see https://github.com/faster-cpython/ideas/issues/54#issuecomment-868978681 for the benchmark script and results.

This issue is also tied to issue44207 (Add a version number to Python functions) which will be required for specializations 1 and 2.

----------
messages: 396639
nosy: Mark.Shannon, kj
priority: normal
severity: normal
status: open
title: Implement CALL_FUNCTION adaptive interpreter optimizations
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Mon Jun 28 10:24:51 2021
From: report at bugs.python.org (serif)
Date: Mon, 28 Jun 2021 14:24:51 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue44526=5D_Doc_typo_in_=22Wh?=
 =?utf-8?q?at=E2=80=99s_New_In_Python_3=2E10=22_=28x/y-axis=29?=
Message-ID: <1624890291.98.0.24550553964.issue44526@roundup.psfhosted.org>


New submission from serif <vrenna at live.com>:

Page:

What?s New In Python 3.10
https://docs.python.org/3.10/whatsnew/3.10.html

Section:

PEP 634: Structural Pattern Matching
    Patterns and classes

In the example code, x and y in the printed messages are swapped.

        case Point(x=0, y=y):
            print(f"Y={y} and the point is on the y-axis.")
        case Point(x=x, y=0):
            print(f"X={x} and the point is on the x-axis.")

Should be:

        case Point(x=0, y=y):
            print(f"Y={y} and the point is on the x-axis.")
        case Point(x=x, y=0):
            print(f"X={x} and the point is on the y-axis.")

----------
assignee: docs at python
components: Documentation
messages: 396640
nosy: docs at python, serif2
priority: normal
severity: normal
status: open
title: Doc typo in "What?s New In Python 3.10" (x/y-axis)
versions: Python 3.10

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

From report at bugs.python.org  Mon Jun 28 13:29:19 2021
From: report at bugs.python.org (bugale bugale)
Date: Mon, 28 Jun 2021 17:29:19 +0000
Subject: [New-bugs-announce] [issue44527] subprocess.run gets stuck
 indefinitely
Message-ID: <1624901359.36.0.684419072719.issue44527@roundup.psfhosted.org>


New submission from bugale bugale <bugalit at gmail.com>:

The implementation for subprocess.run on Windows has a bug that causes it to hang indefinitely in some scenarios.
The issue can be easily reproduced by this code:

import subprocess
subprocess.run(['cmd.exe', '/c', 'ping 1.2.3.4 -n 9999'], capture_output=True, timeout=1)

Instead of exiting after 1 second, it hangs indefinitely.

After looking at the code a bit, I found the issue:
https://github.com/python/cpython/blob/efe7d08d178a7c09bcca994f2068b019c8633d83/Lib/subprocess.py#L512

            if _mswindows:
                # Windows accumulates the output in a single blocking
                # read() call run on child threads, with the timeout
                # being done in a join() on those threads.  communicate()
                # _after_ kill() is required to collect that and add it
                # to the exception.
                exc.stdout, exc.stderr = process.communicate()

In the case of Windows, after the process is killed, communicate is called without a timeout. This usually works because after the process is killed the pipes are closed and the communicate returns almost immediately.
However, if the created subprocess created other processes that hold the pipes, they are not closed and this line blocks indefinitely.

----------
components: Library (Lib)
messages: 396653
nosy: bugale bugale
priority: normal
severity: normal
status: open
title: subprocess.run gets stuck indefinitely
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Mon Jun 28 13:41:20 2021
From: report at bugs.python.org (pavel-lexyr)
Date: Mon, 28 Jun 2021 17:41:20 +0000
Subject: [New-bugs-announce] [issue44528] Move IP version resolving to
 http.server's API
Message-ID: <1624902080.06.0.889341047193.issue44528@roundup.psfhosted.org>


New submission from pavel-lexyr <pavel at lexyr.com>:

Python's native HTTP server (http.server module) has special code to allow it to detect and bind to IPv6 addresses when called as a CLI tool. As of right now, the code is in private functions. Those are not intended to be called by library users - only the CLI command. People want to create HTTP/WSGI servers programmatically - then they run into similar problems. Since the relevant code is not open for library use, they copy it to their own projects instead. That's code duplication.

Exhibit A: https://github.com/prometheus/client_python/pull/657

This doesn't look like a good way to do things. To avoid such problems, it can be useful to have the CLI tool's protocol version resolver added to the library.

This relates to bpo-20215, which has related aspirations - but a broader scope.

----------
components: Library (Lib)
messages: 396655
nosy: jaraco, pavel-lexyr
priority: normal
severity: normal
status: open
title: Move IP version resolving to http.server's API
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Mon Jun 28 14:15:36 2021
From: report at bugs.python.org (Kaleb Barrett)
Date: Mon, 28 Jun 2021 18:15:36 +0000
Subject: [New-bugs-announce] [issue44529] Using typing.Union in isinstance
 checks
Message-ID: <1624904136.53.0.718038325255.issue44529@roundup.psfhosted.org>


New submission from Kaleb Barrett <dev.ktbarrett at gmail.com>:

I have type aliases of Unions like so:

Request = Union[WriteRequest, ReadRequest]

I'd like to be able to use "Request" in an isinstance check rather than having to duplicate the information in a tuple to pass to the check. Currently I get:

TypeError: Subscripted generics cannot be used with class and instance checks

Seems like Unions could be used here interchangeably with tuples since they mean the same thing in this context. Of course this would only work if the element types are being capable of being used in isinstance checks.

----------
messages: 396658
nosy: ktbarrett
priority: normal
severity: normal
status: open
title: Using typing.Union in isinstance checks
type: enhancement

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

From report at bugs.python.org  Mon Jun 28 18:35:33 2021
From: report at bugs.python.org (Gabriele N Tornetta)
Date: Mon, 28 Jun 2021 22:35:33 +0000
Subject: [New-bugs-announce] [issue44530] Propagate qualname from the
 compiler unit to code objects for finer grained profiling data
Message-ID: <1624919733.39.0.974767657181.issue44530@roundup.psfhosted.org>


New submission from Gabriele N Tornetta <phoenix1987 at gmail.com>:

When dumping profiling data out of code objects using out-of-process tools like Austin (https://github.com/p403n1x87/austin) one has access only to file name, function name, and line number. Consider the flame graph generated by running the following script, and aggregating on function names

----
class Foo:
    def on_cpu(self, n):
        a = []
        for i in range(n):
            a.append(i)


class Bar:
    def on_cpu(self, n):
        a = []
        for i in range(n):
            a.append(i)


if __name__ == "__main__":
    f = Foo()
    b = Bar()

    f.on_cpu(1_000_000)
    b.on_cpu(5_000_000)
----

Without the extra information coming from the actual Python source, one would not be able to tell, by looking at the flame graph alone, that on_cpu has contributions from two different methods. By propagating the qualname information from the compiler to code objects, such names would be disambiguated and the resulting flame graph would be clearer.

I would like to propose adding the co_qualname field to the PyCodeObject structure, which is to be set to NULL except for when the code object is created by the compiler in compile.c.

----------
components: C API
files: py_main.png
messages: 396667
nosy: Gabriele Tornetta
priority: normal
severity: normal
status: open
title: Propagate qualname from the compiler unit to code objects for finer grained profiling data
type: enhancement
versions: Python 3.11
Added file: https://bugs.python.org/file50128/py_main.png

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

From report at bugs.python.org  Mon Jun 28 22:02:58 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Jun 2021 02:02:58 +0000
Subject: [New-bugs-announce] [issue44531] Add _PyType_AllocNoTrack()
 function: allocate without tracking in the GC
Message-ID: <1624932178.77.0.0459304316784.issue44531@roundup.psfhosted.org>


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

The PyType_GenericAlloc() function tracks the newly created object in the garbage collector (GC) as soon as memory is initialized, but before all object members are initialized.

If a GC collection happens before the object is fully initialized, the traverse function of the newly created object can crash.

This case is hypothetical for built-in types since their constructor should not trigger a GC collection. It is more likely in third party extensions and subclasses.

Anyway, I propose to add a new _PyType_AllocNoTrack() function which allocates memory without tracking the newly allocated object directly in the GC.

This function can be used to only track explicitly the object in the GC once it is fully initialized.

----------
components: C API
messages: 396695
nosy: vstinner
priority: normal
severity: normal
status: open
title: Add _PyType_AllocNoTrack() function: allocate without tracking in the GC
versions: Python 3.11

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

From report at bugs.python.org  Tue Jun 29 02:53:42 2021
From: report at bugs.python.org (junyixie)
Date: Tue, 29 Jun 2021 06:53:42 +0000
Subject: [New-bugs-announce] [issue44532] multi subinterpreters use
 _PyStructSequence_InitType failed.
Message-ID: <1624949622.19.0.942644638958.issue44532@roundup.psfhosted.org>


New submission from junyixie <xie.junyi at outlook.com>:

In _PyStructSequence_InitType, it will check type is initialized.
but when we have multi subinterpreters, type may be initialized expected.

when type already been initialized, should return 0 rather than throw exception.
```c
/* PyTypeObject has already been initialized */
if (Py_REFCNT(type) != 0) {
    return 0;
}
```


```c
int
_PyStructSequence_InitType(PyTypeObject *type, PyStructSequence_Desc *desc,
                           unsigned long tp_flags)
{
    PyMemberDef *members;
    Py_ssize_t n_members, n_unnamed_members;

#ifdef Py_TRACE_REFS
    /* if the type object was chained, unchain it first
       before overwriting its storage */
    if (type->ob_base.ob_base._ob_next) {
        _Py_ForgetReference((PyObject *)type);
    }
#endif

    /* PyTypeObject has already been initialized */
    if (Py_REFCNT(type) != 0) {
        PyErr_BadInternalCall();
        return -1;
    }
```

----------
components: Subinterpreters
messages: 396703
nosy: JunyiXie
priority: normal
severity: normal
status: open
title: multi subinterpreters use _PyStructSequence_InitType failed.
type: crash

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

From report at bugs.python.org  Tue Jun 29 03:15:06 2021
From: report at bugs.python.org (tygrus)
Date: Tue, 29 Jun 2021 07:15:06 +0000
Subject: [New-bugs-announce] [issue44533] Where are the log file(s)
Message-ID: <1624950906.15.0.177262141584.issue44533@roundup.psfhosted.org>


New submission from tygrus <tygrus at iinet.net.au>:

The Python app shows errors and says "Check the logs for full command output."
But where are the logs?
And how to understand the data in the logs?

----------
messages: 396704
nosy: tygrus
priority: normal
severity: normal
status: open
title: Where are the log file(s)
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Jun 29 08:14:15 2021
From: report at bugs.python.org (Roy Smith)
Date: Tue, 29 Jun 2021 12:14:15 +0000
Subject: [New-bugs-announce] [issue44534] unittest.mock.Mock.unsafe doc is
 garbled
Message-ID: <1624968855.9.0.632630406188.issue44534@roundup.psfhosted.org>


New submission from Roy Smith <roy at panix.com>:

At https://docs.python.org/3.9/library/unittest.mock.html#unittest.mock.Mock, it says:

unsafe: By default if any attribute starts with assert or assret will raise an AttributeError.

That's not an English sentence.  I think what was intended was, "By default accessing an attribute which starts with assert or assret will raise an AttributeError."

----------
assignee: docs at python
components: Documentation
messages: 396719
nosy: docs at python, roysmith
priority: normal
severity: normal
status: open
title: unittest.mock.Mock.unsafe doc is garbled
versions: Python 3.9

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

From report at bugs.python.org  Tue Jun 29 08:44:02 2021
From: report at bugs.python.org (Steve Dower)
Date: Tue, 29 Jun 2021 12:44:02 +0000
Subject: [New-bugs-announce] [issue44535] Cannot build in VS 2022
Message-ID: <1624970642.63.0.621346715913.issue44535@roundup.psfhosted.org>


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

The project files require an additional check in PCbuild/python.props to select the right toolset for VisualStudioVersion=17.0. Without this, everything will refuse to build.

The toolset is still v142, so there should be not compatibility issues. The problem is in detection, not use.

----------
assignee: steve.dower
components: Build, Windows
messages: 396723
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Cannot build in VS 2022
type: compile error
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Tue Jun 29 10:55:23 2021
From: report at bugs.python.org (=?utf-8?b?55Sz5rO36L2p?=)
Date: Tue, 29 Jun 2021 14:55:23 +0000
Subject: [New-bugs-announce] [issue44536] wrong output of np.lcm.reduce(*awg)
Message-ID: <1624978523.12.0.931215741886.issue44536@roundup.psfhosted.org>


New submission from ??? <751630742 at qq.com>:

np.lcm.reduce([1,2,3,100])
Out[125]: 300

np.lcm.reduce([1,2,3,100,101])
Out[126]: 30300

np.lcm.reduce([1,2,3,100,101,99019])
Out[127]: -1294691596

30300*99019
Out[128]: 3000275700

----------
assignee: docs at python
components: Documentation
files: a text for lcm() in  numpy.py
messages: 396742
nosy: docs at python, zlwq
priority: normal
severity: normal
status: open
title: wrong output of np.lcm.reduce(*awg)
versions: Python 3.8
Added file: https://bugs.python.org/file50133/a text for lcm() in  numpy.py

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

From report at bugs.python.org  Tue Jun 29 19:35:17 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 29 Jun 2021 23:35:17 +0000
Subject: [New-bugs-announce] [issue44537] Document PGO in devguide
Message-ID: <1625009717.25.0.620179855703.issue44537@roundup.psfhosted.org>


New submission from Guido van Rossum <guido at python.org>:

The only docs for PGO seem to be in the toplevel README.rst. Sinec that is what's shown to all visitors to the GitHub repo, perhaps this information is not so useful there, and instead a section could be added to the devguide? (Ditto for LTO.)

Note that for Windows this info is in PCbuild/readme.txt. It's perhaps okay to keep it there, and just mention in the devguide that the Windows info in there.

FWIW, maybe we should get rid of the tradition that the toplevel README.rst file's heading gives the version? That tradition dates from the times when source distributions were done as tarballs... It would save one more place to update (there's another mention of the version later in README.rst which still points to 3.10).

----------
assignee: docs at python
components: Documentation
messages: 396764
nosy: docs at python, gvanrossum
priority: normal
severity: normal
status: open
title: Document PGO in devguide
versions: Python 3.11

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

From report at bugs.python.org  Tue Jun 29 19:41:33 2021
From: report at bugs.python.org (Tim)
Date: Tue, 29 Jun 2021 23:41:33 +0000
Subject: [New-bugs-announce] [issue44538] ast.Slice 3.9.6 documentation bug
Message-ID: <1625010093.71.0.0337806588286.issue44538@roundup.psfhosted.org>


New submission from Tim <tim.baer at c3.ai>:

Based off the ast 3.9.6 documentation  (https://docs.python.org/3/library/ast.html), we would expect `Slice` to inherit from `expr`. However, looking at `ast.Slice.__mro__` produces the following output: `(<class '_ast.Slice'>, <class '_ast.slice'>, <class '_ast.AST'>, <class 'object'>)`.

It appears that instead of inheriting from `expr`, `Slice` inherits from `slice` which appears to be a deprecated type.

----------
assignee: docs at python
components: Documentation
messages: 396765
nosy: c3-timjbaer, docs at python
priority: normal
severity: normal
status: open
title: ast.Slice 3.9.6 documentation bug
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Wed Jun 30 04:12:46 2021
From: report at bugs.python.org (Mohamad Mansour)
Date: Wed, 30 Jun 2021 08:12:46 +0000
Subject: [New-bugs-announce] [issue44539] Imghdr JPG Quantized
Message-ID: <1625040766.45.0.209799652803.issue44539@roundup.psfhosted.org>


New submission from Mohamad Mansour <moemansour03 at gmail.com>:

Previous method to check JPG images was using the following command (h[6:10] in (b'JFIF', b'Exif'))
However, its not always the case as some might start with b'\xff\xd8\xff\xdb' header.
Reference:
https://www.digicamsoft.com/itu/itu-t81-36.html
https://web.archive.org/web/20120403212223/http://class.ee.iastate.edu/ee528/Reading%20material/JPEG_File_Format.pdf

----------
components: C API
messages: 396771
nosy: m.mansour
priority: normal
severity: normal
status: open
title: Imghdr JPG Quantized
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/issue44539>
_______________________________________

From report at bugs.python.org  Wed Jun 30 08:44:01 2021
From: report at bugs.python.org (MB113)
Date: Wed, 30 Jun 2021 12:44:01 +0000
Subject: [New-bugs-announce] [issue44540] venv: activate.bat fails for venv
 with special characters in PATH
Message-ID: <1625057041.78.0.250792490415.issue44540@roundup.psfhosted.org>


New submission from MB113 <m.brockbernd at ziggo.nl>:

If your virtual env Scripts folder is in a path with a special character (for batch-scripts) it will give this error:  

The system cannot find the path specified.

In my case it was a '&' in my path.

Now I see that the fix from specifically this issue: https://bugs.python.org/issue36634 has caused my problems.

So in the end neither works.
set "VIRTUAL_ENV=__VENV_DIR__" doesn't work with quotes
set VIRTUAL_ENV=__VENV_DIR__  doesn't work with 'special chars' (&*)

----------
components: Library (Lib), Windows
messages: 396776
nosy: MB113, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: venv: activate.bat fails for venv with special characters in PATH
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Wed Jun 30 12:24:29 2021
From: report at bugs.python.org (=?utf-8?q?Maciej_Kope=C4=87?=)
Date: Wed, 30 Jun 2021 16:24:29 +0000
Subject: [New-bugs-announce] [issue44541] collections.abc.Sequence index
 implementation
Message-ID: <1625070269.09.0.120970069586.issue44541@roundup.psfhosted.org>


New submission from Maciej Kope? <maciejpkopec at gmail.com>:

Hello,

https://github.com/python/cpython/blob/3.9/Lib/_collections_abc.py#L1012
Shouldn't the loop condition be i <= 0 not i < 0? The implementation now is causing not to search in 1-element sequences, since it raises ValueError. Please let me know if this is the expected behaviour.

Kind regards,
Maciej Kope?

----------
messages: 396783
nosy: LordVilgefortz
priority: normal
severity: normal
status: open
title: collections.abc.Sequence index implementation
type: behavior
versions: Python 3.9

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