From report at bugs.python.org  Tue Sep  1 04:33:31 2020
From: report at bugs.python.org (Lucca Ruhland)
Date: Tue, 01 Sep 2020 08:33:31 +0000
Subject: [New-bugs-announce] [issue41684] argparse: unexpected subparser
 behaviour on parse_args with namespace option
Message-ID: <1598949211.7.0.649344000832.issue41684@roundup.psfhosted.org>


New submission from Lucca Ruhland <lucca.ruhland at gmail.com>:

When parsing arguments with a namespace object, the subparser are behaving different than the main parser, although this is not stated in the documentation.

Each attribute which is not already part of the namespace, should be saved into the namespace object.
Therefore any already existing namespace attribute should overwrite the default value of any argument which is not explicitly set. 

While this is true for the parent parser, it does not work for the subparser.
Here is a small example code:
------------------------------------------------------------------------
import argparse

parser = argparse.ArgumentParser()
parser.add_argument('--root', type=str, default='.')
subparsers = parser.add_subparsers()
subparser = subparsers.add_parser('subp')
subparser.add_argument('--subroot', type=str, default='./subdir')
our_args = argparse.Namespace(root="./config_root", subroot="./config_subdir")

argv = ['subp']
args = parser.parse_args(argv, namespace=our_args)
print(args)
------------------------------------------------------------------------
>>> Expected: Namespace(root='./config_root', subroot='./config_subdir')
>>> Output: Namespace(root='./config_root', subroot='./subdir')

When calling the subparser, the namespace attribute is overwritten by the default value.

----------
assignee: docs at python
components: Documentation
messages: 376183
nosy: docs at python, lucca.ruhland
priority: normal
severity: normal
status: open
title: argparse: unexpected subparser behaviour on parse_args with namespace option
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Tue Sep  1 05:38:54 2020
From: report at bugs.python.org (Ned Deily)
Date: Tue, 01 Sep 2020 09:38:54 +0000
Subject: [New-bugs-announce] [issue41685] make doctest on 3.10 (master
 branch) fails with setuptools 50.0.0
Message-ID: <1598953134.12.0.788721169473.issue41685@roundup.psfhosted.org>


New submission from Ned Deily <nad at python.org>:

See pypa/setuptools#2361 for details.

For now, temporarily pin setuptools version in the Doc venv to a previous version.

Victor notes:
""Temporarily pin setuptools": we already pin Sphinx version to also avoid breaking the CI when a new Sphinx version is released. It would make sense to make our CI less dependent on releases of third party components: better control when we update dependencies. The risk is to forget to update these dependences if the updates are not automated."

----------
assignee: docs at python
components: Documentation
messages: 376184
nosy: docs at python, mdk, ned.deily, vstinner
priority: critical
severity: normal
stage: commit review
status: open
title: make doctest on 3.10 (master branch) fails with setuptools 50.0.0
versions: Python 3.10

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

From report at bugs.python.org  Tue Sep  1 08:32:23 2020
From: report at bugs.python.org (hafiz bilal)
Date: Tue, 01 Sep 2020 12:32:23 +0000
Subject: [New-bugs-announce] [issue41686] C++ Embedded 'time.sleep()' is not
 working on Windows host due to 'Py_InitializeEx(0)'
Message-ID: <1598963543.37.0.281772531598.issue41686@roundup.psfhosted.org>


New submission from hafiz bilal <hafizbilal100 at gmail.com>:

Hi,

time.sleep() function is not working on Windows host if I use C API Py_InitializeEx(0) function.

Issue could be reproduce with following simple example.

int main()
{
   Py_InitializeEx(0);
   PyRun_SimpleString("import time \n"
		      "start = time.time() \n"
		      "time.sleep(4) \n"
		      "print('elapsed: %d' % (time.time() - start))");
}

output:

elapsed: 0


Note, issue is not reproduce on Linux host.

----------
components: C API
messages: 376189
nosy: hafizbilal100
priority: normal
severity: normal
status: open
title: C++ Embedded 'time.sleep()' is not working on Windows host due to 'Py_InitializeEx(0)'
versions: Python 3.8

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

From report at bugs.python.org  Tue Sep  1 09:55:22 2020
From: report at bugs.python.org (Jakub Kulik)
Date: Tue, 01 Sep 2020 13:55:22 +0000
Subject: [New-bugs-announce] [issue41687] sendfile implementation is not
 compatible with Solaris
Message-ID: <1598968522.06.0.521626204763.issue41687@roundup.psfhosted.org>


New submission from Jakub Kulik <kulikjak at gmail.com>:

Hi,

Sendfile on Solaris raises EINVAL if offset is equal or bigger than the size of the file. This is different from Linux, where similar sendfile call returns 0, which is used in an ad-hoc fashion to indicate EOF. Since Python sendfile implementation expects 0 to be returned, it breaks. I already reported this in issue 36610, which led to sendfile eventually being disabled on Solaris to be safe before the 3.8 release.

We were first looking into a possibility to change Solaris behavior of sendfile to reflect that of Linux but decided not to because of the significant risk that it can break existing programs. The other reason is that sendfile isn't standardized (Linux manpage explicitly states that) and hence Solaris implementation isn't broken, just different. Because of that, we patched the runtime and added #ifdef branch (of which there are already many due to os differences) with additional offset check. It is tested with the current master and also 3.7, which we are using internally.

Thanks

----------
components: Library (Lib)
messages: 376191
nosy: kulikjak
priority: normal
severity: normal
status: open
title: sendfile implementation is not compatible with Solaris
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Sep  1 16:08:17 2020
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 01 Sep 2020 20:08:17 +0000
Subject: [New-bugs-announce] [issue41688] Document how **= does not fall
 back on **
Message-ID: <1598990897.9.0.376254193992.issue41688@roundup.psfhosted.org>


New submission from Brett Cannon <brett at python.org>:

https://bugs.python.org/issue38302 covers fixing the fact that `a **= b` does not fall back on `a = a ** b` when `__ipow__` is defined for PYthon 3.10. For older versions of CPython with the bug we should document the slip in semantics.

----------
assignee: docs at python
components: Documentation
messages: 376207
nosy: brett.cannon, docs at python
priority: high
severity: normal
status: open
title: Document how **= does not fall back on **
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Sep  2 00:37:01 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 02 Sep 2020 04:37:01 +0000
Subject: [New-bugs-announce] [issue41689] allow __text_signature__ to work
 for c heap types
Message-ID: <1599021421.22.0.223210002461.issue41689@roundup.psfhosted.org>


New submission from Benjamin Peterson <benjamin at python.org>:

C types can add a signature to their __doc__. Currently, PyType_FromSpec just deletes such signatures instead of making them visible from __text_signature__.

----------
components: C API
messages: 376216
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: allow __text_signature__ to work for c heap types
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Wed Sep  2 06:59:21 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 02 Sep 2020 10:59:21 +0000
Subject: [New-bugs-announce] [issue41690] Use a loop to collect args in the
 parser instead of recursion
Message-ID: <1599044361.34.0.302314568095.issue41690@roundup.psfhosted.org>


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

This program can segfault the parser by stackoverflow:

import ast

code = "f(" + ",".join(['a' for _ in range(100000)]) + ")"
print("Ready!")
ast.parse(code)

the reason is that the rule for arguments has a simple recursion when collecting args:

args[expr_ty]:
    [...]
    | a=named_expression b=[',' c=args { c }] {
        [...] }

Check https://github.com/we-like-parsers/pegen/issues/245 for more context and informaton

----------
messages: 376225
nosy: pablogsal
priority: normal
severity: normal
status: open
title: Use a loop to collect args in the parser instead of recursion
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Wed Sep  2 07:27:58 2020
From: report at bugs.python.org (David Crespo)
Date: Wed, 02 Sep 2020 11:27:58 +0000
Subject: [New-bugs-announce] [issue41691] Idle 3.8.5 on Win64 won't save a
 file if it didn't include a newline when it was opened (ex: opening empty
 file)
Message-ID: <1599046078.06.0.268934557443.issue41691@roundup.psfhosted.org>


New submission from David Crespo <dcrespo3d at gmail.com>:

Idle won't save a file if it didn't include a newline when it was opened (ex: opening empty file)

Steps for reproducing the error:
1) get into some folder in Windows File Explorer
2) right-click on empty space for context menu
3) click new -> create text file
4) rename to test.py
5) right click on test.py for context menu
6) click Edit with Idle -> Edit with Idle 3.8 64-bit
7) write some code, ex: print('hello, world!)
8) try to save the file with CTRL+S, or menu file->save, file->save as or file->save a copy

IDLE will silently refuse to save the file, the 'not saved' asterisk will remain next to the file name and no file is written.

I am using a workaround for this since creating empty files and editing them is part of my usual workflow.

If I edit the file with another text editor, save it, and then open it from the context menu, it can be saved after editing, but ONLY if i put a newline in the file from the alternate text editor. If my the file does NOT contain any newline at opening time, IDLE refuses to save it.

This error (refusing to save) seems to happen also when opening from menu file->open any file which does NOT contain any newline.

Regards.

----------
assignee: terry.reedy
components: IDLE
messages: 376228
nosy: dcrespo3d, terry.reedy
priority: normal
severity: normal
status: open
title: Idle 3.8.5 on Win64 won't save a file if it didn't include a newline when it was opened (ex: opening empty file)
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Wed Sep  2 09:59:25 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 02 Sep 2020 13:59:25 +0000
Subject: [New-bugs-announce] [issue41692] Deprecate immortal interned
 strings: PyUnicode_InternImmortal()
Message-ID: <1599055165.93.0.874786911809.issue41692@roundup.psfhosted.org>


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

Python has the concept of "immortal" interned strings: PyUnicode_InternImmortal().

The feature was first introduced in the Python 2 "str" (bytes) type, bpo-576101 (commit 45ec02aed14685c353e55841b5acbc0dadee76f8). New PyString_InternImmortal() function.

commit 45ec02aed14685c353e55841b5acbc0dadee76f8
Author: Guido van Rossum <guido at python.org>
Date:   Mon Aug 19 21:43:18 2002 +0000

    SF patch 576101, by Oren Tirosh: alternative implementation of
    interning.  I modified Oren's patch significantly, but the basic idea
    and most of the implementation is unchanged.  Interned strings created
    with PyString_InternInPlace() are now mortal, and you must keep a
    reference to the resulting string around; use the new function
    PyString_InternImmortal() to create immortal interned strings.

Later, the feature was added to the PyUnicodeObject type, new PyUnicode_InternImmortal() function:

commit 1680713e524016d93a94114c4a874ad71a090b95
Author: Walter D?rwald <walter at livinglogic.de>
Date:   Fri May 25 13:52:07 2007 +0000

    Add interning of unicode strings by copying the functionality from
    stringobject.c.
    
    Intern "True" and "False" in bool_repr() again as it was in the
    8bit string era.

Since Python 3.10, (mortal) interned strings are cleared at Python exit in Py_Finalize(). It avoids leaking memory when Python is embedded in an application: bpo-1635741.

commit 666ecfb0957a2fa0df5e2bd03804195de74bdfbf
Author: Victor Stinner <vstinner at python.org>
Date:   Thu Jul 2 01:19:57 2020 +0200

    bpo-1635741: Release Unicode interned strings at exit (GH-21269)
    
    * PyUnicode_InternInPlace() now ensures that interned strings are
      ready.
    * Add _PyUnicode_ClearInterned().
    * Py_Finalize() now releases Unicode interned strings:
      call _PyUnicode_ClearInterned().

--

PyUnicode_InternImmortal() is not used in the Python standard library. I propose to start deprecating the function and remove it in Python 3.12 (PEP 387 requires a deprecation for 2 releases). In Python 3.10, calling the function will emit a DeprecationWarning at runtime.

Note: PyString_InternImmortal() (for bytes strings) has been removed from Python 3.0.

----------
components: Interpreter Core
messages: 376237
nosy: inada.naoki, serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: Deprecate immortal interned strings: PyUnicode_InternImmortal()
versions: Python 3.10

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

From report at bugs.python.org  Wed Sep  2 10:17:11 2020
From: report at bugs.python.org (Abael He)
Date: Wed, 02 Sep 2020 14:17:11 +0000
Subject: [New-bugs-announce] [issue41693] AttributeError: 'str' object has
 no attribute '__cause__' (python3.8/traceback.py", line 479, in __init__)
Message-ID: <1599056231.08.0.17351963613.issue41693@roundup.psfhosted.org>


New submission from Abael He <abaelhe at icloud.com>:

Abaels-MBP:notebook-myfork abaelhe$ pip install jupyterlab_powerpoint
Defaulting to user installation because normal site-packages is not writeable
Looking in indexes: https://pypi.tuna.tsinghua.edu.cn/simple, https://mirror.baidu.com/pypi/simple
Collecting jupyterlab_powerpoint
  Downloading https://pypi.tuna.tsinghua.edu.cn/packages/67/b3/7c65696326b35c2cf62f7203ddc6915518769b3281297762505496c02cbb/jupyterlab_powerpoint-0.1.0-py2.py3-none-any.whl (22 kB)
Collecting python-pptx>=0.6.0

??

Building wheels for collected packages: python-pptx
  Building wheel for python-pptx (setup.py) ... done
  Created wheel for python-pptx: filename=python_pptx-0.6.18-py3-none-any.whl size=275703 sha256=2cc60bf3fd5d8de7909a47cf2318248fe7f966f64da1014be413db2274abd19c
  Stored in directory: /Users/abaelhe/Library/Caches/pip/wheels/2c/92/3f/c614b86f8f18dc83f377a94e76a2f2fb1a1b6d5d74d438d2f4
Successfully built python-pptx
Installing collected packages: lxml, XlsxWriter, python-pptx, jupyterlab-powerpoint
Successfully installed XlsxWriter-1.3.3 jupyterlab-powerpoint-0.1.0 lxml-4.5.2 python-pptx-0.6.18
Abaels-MBP:notebook-myfork abaelhe$ jupyter labextension install jupyterlab_powerpoint
jupyter serverextension enable --py jupyterlab_powerpointjupyter serverextension enable --py jupyterlab_powerpointjupyter serverextension enable --py jupyterlab_powerpointBuilding jupyterlab assets (build:prod:minimize)
--- Logging error ---
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/shutil.py", line 670, in _rmtree_safe_fd
    os.unlink(entry.name, dir_fd=topfd)
PermissionError: [Errno 13] Permission denied: '403.html'

During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/logging/__init__.py", line 1081, in emit
    msg = self.format(record)
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/logging/__init__.py", line 925, in format
    return fmt.format(record)
  File "/Users/abaelhe/Library/Python/3.8/lib/python/site-packages/traitlets/config/application.py", line 117, in format
    return super(LevelFormatter, self).format(record)
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/logging/__init__.py", line 672, in format
    record.exc_text = self.formatException(record.exc_info)
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/logging/__init__.py", line 622, in formatException
    traceback.print_exception(ei[0], ei[1], tb, None, sio)
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/traceback.py", line 103, in print_exception
    for line in TracebackException(
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/traceback.py", line 479, in __init__
    if (exc_value and exc_value.__cause__ is not None
AttributeError: 'str' object has no attribute '__cause__'
Call stack:
  File "/Users/abaelhe/Library/Python/3.8/bin/jupyter-labextension", line 8, in <module>
    sys.exit(main())
  File "/Users/abaelhe/Library/Python/3.8/lib/python/site-packages/jupyter_core/application.py", line 270, in launch_instance
    return super(JupyterApp, cls).launch_instance(argv=argv, **kwargs)
  File "/Users/abaelhe/Library/Python/3.8/lib/python/site-packages/traitlets/config/application.py", line 664, in launch_instance
    app.start()
  File "/Users/abaelhe/Library/Python/3.8/lib/python/site-packages/jupyterlab/labextensions.py", line 308, in start
    super(LabExtensionApp, self).start()
  File "/Users/abaelhe/Library/Python/3.8/lib/python/site-packages/jupyter_core/application.py", line 259, in start
    self.subapp.start()
  File "/Users/abaelhe/Library/Python/3.8/lib/python/site-packages/jupyterlab/labextensions.py", line 104, in start
    build(clean_staging=self.should_clean,
  File "/Users/abaelhe/Library/Python/3.8/lib/python/site-packages/jupyterlab/commands.py", line 459, in build
    return handler.build(name=name, version=version, static_url=static_url,
  File "/Users/abaelhe/Library/Python/3.8/lib/python/site-packages/jupyterlab/commands.py", line 640, in build
    self._populate_staging(
  File "/Users/abaelhe/Library/Python/3.8/lib/python/site-packages/jupyterlab/commands.py", line 1100, in _populate_staging
    _rmtree(templates, self.logger)
  File "/Users/abaelhe/Library/Python/3.8/lib/python/site-packages/jupyterlab/commands.py", line 1824, in _rmtree
    shutil.rmtree(path, onerror=onerror)
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/shutil.py", line 715, in rmtree
    _rmtree_safe_fd(fd, path, onerror)
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/shutil.py", line 672, in _rmtree_safe_fd
    onerror(os.unlink, fullname, sys.exc_info())
  File "/Users/abaelhe/Library/Python/3.8/lib/python/site-packages/jupyterlab/commands.py", line 1822, in onerror
    logger.debug('Error in shutil.rmtree', exc_info=exc_info)
Message: 'Error in shutil.rmtree'
Arguments: ()
--- Logging error ---
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/shutil.py", line 670, in _rmtree_safe_fd
    os.unlink(entry.name, dir_fd=topfd)
PermissionError: [Errno 13] Permission denied: 'partial.html'

??

An error occured.

----------
components: Library (Lib)
files: traceback.log
messages: 376239
nosy: abaelhe
priority: normal
severity: normal
status: open
title: AttributeError: 'str' object has no attribute '__cause__' (python3.8/traceback.py", line 479, in __init__)
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file49437/traceback.log

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

From report at bugs.python.org  Wed Sep  2 12:15:41 2020
From: report at bugs.python.org (Dallas Marlow)
Date: Wed, 02 Sep 2020 16:15:41 +0000
Subject: [New-bugs-announce] [issue41694] python3 futures.as_completed
 timeout broken if future contains undefined reference
Message-ID: <1599063341.29.0.717862056359.issue41694@roundup.psfhosted.org>


New submission from Dallas Marlow <dallasmarlow at gmail.com>:

I recently noticed that timeouts do not work with futures.as_completed if a future contains an undefined variable or method. The following code runs for 30 seconds which I believe is a bug as I would expect the invalid print future to throw an exception immediately or the as_completed method throw an exception instead.

#########################

import concurrent.futures

with concurrent.futures.ThreadPoolExecutor() as ex:
	futures = [
		ex.submit(time.sleep, 30),
		ex.submit(print, a),
	]
	for future in concurrent.futures.as_completed(futures, timeout=1):
		_ = future.result()

----------
components: Interpreter Core
messages: 376250
nosy: dallasmarlow
priority: normal
severity: normal
status: open
title: python3 futures.as_completed timeout broken if future contains undefined reference
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Wed Sep  2 12:41:04 2020
From: report at bugs.python.org (=?utf-8?q?Beno=C3=AEt_Brayer?=)
Date: Wed, 02 Sep 2020 16:41:04 +0000
Subject: [New-bugs-announce] [issue41695] http.cookies.SimpleCookie.parse
 could not parse cookies when one cookie value is json
Message-ID: <1599064864.53.0.936259028803.issue41695@roundup.psfhosted.org>


New submission from Beno?t Brayer <brayer.benoit at gmail.com>:

Using python3.8.5, SimpleCookie parser seems to be unable to load the cookie string when a json string is used inside one of the cookie values.

I did not try to replay using other python3 versions yet.

Please use the following code to replay the bug:

>>> from http import cookies
>>> cookie_parser = cookies.SimpleCookie()
>>> cookie_parser.load('CookieScriptConsent={"action":"accept"}; __stripe_mid=plip; __stripe_sid=plop; _ga=tada; _gcl_au=pouet; _hjid=hello; authn_token=mylogin; rememberMe=true')
>>> cookie_parser.keys()
dict_keys([])
>>> cookie_parser = cookies.SimpleCookie()
>>> cookie_parser.load('__stripe_mid=plip; __stripe_sid=plop; _ga=tada; _gcl_au=pouet; _hjid=hello; authn_token=mylogin; rememberMe=true')
>>> cookie_parser.keys()
dict_keys(['__stripe_mid', '__stripe_sid', '_ga', '_gcl_au', '_hjid', 'authn_token', 'rememberMe'])

----------
messages: 376253
nosy: brayer.benoit
priority: normal
severity: normal
status: open
title: http.cookies.SimpleCookie.parse could not parse cookies when one cookie value is json
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Wed Sep  2 20:33:50 2020
From: report at bugs.python.org (Shantanu)
Date: Thu, 03 Sep 2020 00:33:50 +0000
Subject: [New-bugs-announce] [issue41696] asyncio.run interacts surprisingly
 with debug mode
Message-ID: <1599093230.84.0.897076872177.issue41696@roundup.psfhosted.org>


New submission from Shantanu <hauntsaninja at gmail.com>:

To quote the docs (https://docs.python.org/3/library/asyncio-dev.html):

```
By default asyncio runs in production mode. In order to ease the development asyncio has a debug mode.

There are several ways to enable asyncio debug mode:

    Setting the PYTHONASYNCIODEBUG environment variable to 1.

    Using the -X dev Python command line option.

    Passing debug=True to asyncio.run().

    Calling loop.set_debug().
```

Unfortunately, this documentation is misleading (or wrong) when using asyncio.run. For instance, from a naive read of the above, I'd expect debug mode to be True for many of the following:

```
~/tmp ? cat test57.py
import asyncio
import time

async def foo():
    loop = asyncio.get_event_loop()
    time.sleep(2)
    print(loop.get_debug())

print(asyncio.coroutines._DEBUG)
asyncio.run(foo())
~/tmp ? python3 --version       
Python 3.7.3

# expected
~/tmp ? python3 test57.py
False
False

# surprising, would expect this to work
~/tmp ? python3 -X dev test57.py
True
False

# surprising, would expect this to work
~/tmp ? PYTHONASYNCIODEBUG=1 python3 test57.py
True
False

# expected
~/tmp ? vim test57.py
~/tmp ? cat test57.py
import asyncio
import time

async def foo():
    loop = asyncio.get_event_loop()
    time.sleep(2)
    print(loop.get_debug())

print(asyncio.coroutines._DEBUG)
asyncio.run(foo(), debug=True)
~/tmp ? python3 test57.py       
False
True
Executing <Task finished coro=<foo() done, defined at test57.py:4> result=None created at /Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.7/lib/python3.7/asyncio/base_events.py:563> took 2.003 seconds
~/tmp ? 
```

This appears to be because asyncio.run sets debug mode here: https://github.com/python/cpython/blob/4a97b1517a6b5ff22e2984b677a680b07ff0ce11/Lib/asyncio/runners.py#L42

We should either change asyncio.run to use the existing value of debug mode if left unspecified, or we should update the documentation to explicitly call out that the environment variable and command line flag will not work when using asyncio.run

----------
components: asyncio
messages: 376268
nosy: asvetlov, hauntsaninja, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.run interacts surprisingly with debug mode

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

From report at bugs.python.org  Wed Sep  2 21:18:07 2020
From: report at bugs.python.org (Brad Larsen)
Date: Thu, 03 Sep 2020 01:18:07 +0000
Subject: [New-bugs-announce] [issue41697] Heap buffer overflow in the parser
Message-ID: <1599095887.78.0.252018926067.issue41697@roundup.psfhosted.org>


New submission from Brad Larsen <brad at bradfordlarsen.com>:

It looks like commit 4a97b1517a6b5ff22e2984b677a680b07ff0ce11 introduced a heap buffer overflow:

    commit 4a97b1517a6b5ff22e2984b677a680b07ff0ce11 (HEAD -> master, origin/master, origin/HEAD)
    Author: Pablo Galindo <Pablogsal at gmail.com>
    Date:   Wed Sep 2 17:44:19 2020 +0100
    
        bpo-41690: Use a loop to collect args in the parser instead of recursion (GH-22053)
    
        This program can segfault the parser by stack overflow:
    
        ```
        import ast
    
        code = "f(" + ",".join(['a' for _ in range(100000)]) + ")"
        print("Ready!")
        ast.parse(code)
        ```
    
        the reason is that the rule for arguments has a simple recursion when collecting args:
    
        args[expr_ty]:
            [...]
            | a=named_expression b=[',' c=args { c }] {
                [...] }


If you try building with clang-10 with `--with-pydebug --with-address-sanitizer`, you should see a crash like the following during the `generate-posix-vars` step:

    =================================================================
    ==39814==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x625000264148 at pc 0x000001ff3be8 bp 0x7ffec90e5d00 sp 0x7ffec90e5cf8
    READ of size 4 at 0x625000264148 thread T0
        #0 0x1ff3be7 in _PyPegen_collect_call_seqs /build/python/cpython/Parser/pegen.c:2253:61
        #1 0x218ab08 in args_rule /build/python/cpython/Parser/parser.c:12240:20
        #2 0x20f8906 in arguments_rule /build/python/cpython/Parser/parser.c:12159:18
        #3 0x2158c61 in t_primary_raw /build/python/cpython/Parser/parser.c:14063:18
        #4 0x21416fb in t_primary_rule /build/python/cpython/Parser/parser.c:13896:22
        #5 0x246d944 in single_subscript_attribute_target_rule /build/python/cpython/Parser/parser.c:13265:18
        #6 0x2433a19 in _tmp_20_rule /build/python/cpython/Parser/parser.c:16717:54
        #7 0x24016e3 in assignment_rule /build/python/cpython/Parser/parser.c:2093:18
        #8 0x23e6617 in small_stmt_rule /build/python/cpython/Parser/parser.c:1526:31
        #9 0x2018581 in simple_stmt_rule /build/python/cpython/Parser/parser.c:1424:18
        #10 0x200c22c in statement_rule /build/python/cpython/Parser/parser.c:1258:32
        #11 0x2007026 in _loop1_11_rule /build/python/cpython/Parser/parser.c:16174:30
        #12 0x200455a in statements_rule /build/python/cpython/Parser/parser.c:1193:18
        #13 0x230193f in block_rule /build/python/cpython/Parser/parser.c:6257:18
        #14 0x205886b in function_def_raw_rule /build/python/cpython/Parser/parser.c:4927:18
        #15 0x20229a4 in function_def_rule /build/python/cpython/Parser/parser.c:4856:37
        #16 0x200e2da in compound_stmt_rule /build/python/cpython/Parser/parser.c:1872:33
        #17 0x200a873 in statement_rule /build/python/cpython/Parser/parser.c:1234:18
        #18 0x2007026 in _loop1_11_rule /build/python/cpython/Parser/parser.c:16174:30
        #19 0x200455a in statements_rule /build/python/cpython/Parser/parser.c:1193:18
        #20 0x230193f in block_rule /build/python/cpython/Parser/parser.c:6257:18
        #21 0x2392ac3 in class_def_raw_rule /build/python/cpython/Parser/parser.c:6196:18
        #22 0x202fb74 in class_def_rule /build/python/cpython/Parser/parser.c:6139:34
        #23 0x2010e47 in compound_stmt_rule /build/python/cpython/Parser/parser.c:1914:30
        #24 0x200a873 in statement_rule /build/python/cpython/Parser/parser.c:1234:18
        #25 0x2007026 in _loop1_11_rule /build/python/cpython/Parser/parser.c:16174:30
        #26 0x200455a in statements_rule /build/python/cpython/Parser/parser.c:1193:18
        #27 0x230193f in block_rule /build/python/cpython/Parser/parser.c:6257:18
        #28 0x238f31b in else_block_rule /build/python/cpython/Parser/parser.c:3787:18
        #29 0x204e3c4 in try_stmt_rule /build/python/cpython/Parser/parser.c:4460:19
        #30 0x2014f68 in compound_stmt_rule /build/python/cpython/Parser/parser.c:1977:29
        #31 0x200a873 in statement_rule /build/python/cpython/Parser/parser.c:1234:18
        #32 0x2007026 in _loop1_11_rule /build/python/cpython/Parser/parser.c:16174:30
        #33 0x200455a in statements_rule /build/python/cpython/Parser/parser.c:1193:18
        #34 0x1ff8c93 in file_rule /build/python/cpython/Parser/parser.c:726:18
        #35 0x1ff742d in _PyPegen_parse /build/python/cpython/Parser/parser.c:24794:18
        #36 0x1fc1128 in _PyPegen_run_parser /build/python/cpython/Parser/pegen.c:1111:17
        #37 0x1fc5e38 in _PyPegen_run_parser_from_string /build/python/cpython/Parser/pegen.c:1238:14
        #38 0x1a8952b in PyParser_ASTFromStringObject /build/python/cpython/Parser/peg_api.c:27:21
        #39 0x1339bef in Py_CompileStringObject /build/python/cpython/Python/pythonrun.c:1203:11
        #40 0x1f2ac43 in builtin_compile_impl /build/python/cpython/Python/bltinmodule.c:819:14
        #41 0x1f1902a in builtin_compile /build/python/cpython/Python/clinic/bltinmodule.c.h:249:20
        #42 0x1cab483 in cfunction_vectorcall_FASTCALL_KEYWORDS /build/python/cpython/Objects/methodobject.c:440:24
        #43 0x58bfa8 in PyVectorcall_Call /build/python/cpython/Objects/call.c:242:24
        #44 0x58c3c6 in _PyObject_Call /build/python/cpython/Objects/call.c:265:16
        #45 0x58c8b1 in PyObject_Call /build/python/cpython/Objects/call.c:292:12
        #46 0x1017138 in do_call_core /build/python/cpython/Python/ceval.c:5141:9
        #47 0xfeada4 in _PyEval_EvalFrameDefault /build/python/cpython/Python/ceval.c:3609:22
        #48 0xf4068b in _PyEval_EvalFrame /build/python/cpython/./Include/internal/pycore_ceval.h:40:12
        #49 0x1025062 in _PyEval_EvalCode /build/python/cpython/Python/ceval.c:4376:14
        #50 0x58ec4e in _PyFunction_Vectorcall /build/python/cpython/Objects/call.c:395:12
        #51 0x10365bd in _PyObject_VectorcallTstate /build/python/cpython/./Include/cpython/abstract.h:114:11
        #52 0x1014541 in PyObject_Vectorcall /build/python/cpython/./Include/cpython/abstract.h:123:12
        #53 0x10151c6 in call_function /build/python/cpython/Python/ceval.c:5121:13
        #54 0xfe8b6a in _PyEval_EvalFrameDefault /build/python/cpython/Python/ceval.c:3564:19
        #55 0xf4068b in _PyEval_EvalFrame /build/python/cpython/./Include/internal/pycore_ceval.h:40:12
        #56 0x1025062 in _PyEval_EvalCode /build/python/cpython/Python/ceval.c:4376:14
        #57 0x58ec4e in _PyFunction_Vectorcall /build/python/cpython/Objects/call.c:395:12
        #58 0x10365bd in _PyObject_VectorcallTstate /build/python/cpython/./Include/cpython/abstract.h:114:11
        #59 0x1014541 in PyObject_Vectorcall /build/python/cpython/./Include/cpython/abstract.h:123:12
        #60 0x10151c6 in call_function /build/python/cpython/Python/ceval.c:5121:13
        #61 0xfe5f00 in _PyEval_EvalFrameDefault /build/python/cpython/Python/ceval.c:3533:23
        #62 0x59721b in _PyEval_EvalFrame /build/python/cpython/./Include/internal/pycore_ceval.h:40:12
        #63 0x58f614 in function_code_fastcall /build/python/cpython/Objects/call.c:329:24
        #64 0x58d86d in _PyFunction_Vectorcall /build/python/cpython/Objects/call.c:366:20
        #65 0x10365bd in _PyObject_VectorcallTstate /build/python/cpython/./Include/cpython/abstract.h:114:11
        #66 0x1014541 in PyObject_Vectorcall /build/python/cpython/./Include/cpython/abstract.h:123:12
        #67 0x10151c6 in call_function /build/python/cpython/Python/ceval.c:5121:13
        #68 0xfe5f00 in _PyEval_EvalFrameDefault /build/python/cpython/Python/ceval.c:3533:23
        #69 0x59721b in _PyEval_EvalFrame /build/python/cpython/./Include/internal/pycore_ceval.h:40:12
        #70 0x58f614 in function_code_fastcall /build/python/cpython/Objects/call.c:329:24
        #71 0x58d86d in _PyFunction_Vectorcall /build/python/cpython/Objects/call.c:366:20
        #72 0x10365bd in _PyObject_VectorcallTstate /build/python/cpython/./Include/cpython/abstract.h:114:11
        #73 0x1014541 in PyObject_Vectorcall /build/python/cpython/./Include/cpython/abstract.h:123:12
        #74 0x10151c6 in call_function /build/python/cpython/Python/ceval.c:5121:13
        #75 0xfe5f00 in _PyEval_EvalFrameDefault /build/python/cpython/Python/ceval.c:3533:23
        #76 0x59721b in _PyEval_EvalFrame /build/python/cpython/./Include/internal/pycore_ceval.h:40:12
        #77 0x58f614 in function_code_fastcall /build/python/cpython/Objects/call.c:329:24
        #78 0x58d86d in _PyFunction_Vectorcall /build/python/cpython/Objects/call.c:366:20
        #79 0x10365bd in _PyObject_VectorcallTstate /build/python/cpython/./Include/cpython/abstract.h:114:11
        #80 0x1014541 in PyObject_Vectorcall /build/python/cpython/./Include/cpython/abstract.h:123:12
        #81 0x10151c6 in call_function /build/python/cpython/Python/ceval.c:5121:13
        #82 0xfe71eb in _PyEval_EvalFrameDefault /build/python/cpython/Python/ceval.c:3547:19
        #83 0x59721b in _PyEval_EvalFrame /build/python/cpython/./Include/internal/pycore_ceval.h:40:12
        #84 0x58f614 in function_code_fastcall /build/python/cpython/Objects/call.c:329:24
        #85 0x58d86d in _PyFunction_Vectorcall /build/python/cpython/Objects/call.c:366:20
        #86 0x10365bd in _PyObject_VectorcallTstate /build/python/cpython/./Include/cpython/abstract.h:114:11
        #87 0x1014541 in PyObject_Vectorcall /build/python/cpython/./Include/cpython/abstract.h:123:12
        #88 0x10151c6 in call_function /build/python/cpython/Python/ceval.c:5121:13
        #89 0xfe71eb in _PyEval_EvalFrameDefault /build/python/cpython/Python/ceval.c:3547:19
        #90 0x59721b in _PyEval_EvalFrame /build/python/cpython/./Include/internal/pycore_ceval.h:40:12
        #91 0x58f614 in function_code_fastcall /build/python/cpython/Objects/call.c:329:24
        #92 0x58d86d in _PyFunction_Vectorcall /build/python/cpython/Objects/call.c:366:20
        #93 0x5946bd in _PyObject_VectorcallTstate /build/python/cpython/./Include/cpython/abstract.h:114:11
        #94 0x5959b3 in object_vacall /build/python/cpython/Objects/call.c:791:14
        #95 0x595f4c in _PyObject_CallMethodIdObjArgs /build/python/cpython/Objects/call.c:882:24
        #96 0x11ffca4 in import_find_and_load /build/python/cpython/Python/import.c:1765:11
        #97 0x11fbbc7 in PyImport_ImportModuleLevelObject /build/python/cpython/Python/import.c:1866:15
        #98 0x100dc88 in import_name /build/python/cpython/Python/ceval.c:5242:15
        #99 0xfc8157 in _PyEval_EvalFrameDefault /build/python/cpython/Python/ceval.c:3126:19
        #100 0xf4068b in _PyEval_EvalFrame /build/python/cpython/./Include/internal/pycore_ceval.h:40:12
        #101 0x1025062 in _PyEval_EvalCode /build/python/cpython/Python/ceval.c:4376:14
        #102 0x102a75f in _PyEval_EvalCodeWithName /build/python/cpython/Python/ceval.c:4408:12
        #103 0xf402c5 in PyEval_EvalCodeEx /build/python/cpython/Python/ceval.c:4424:12
        #104 0xf3ff2d in PyEval_EvalCode /build/python/cpython/Python/ceval.c:857:12
        #105 0x1f2cc4e in builtin_exec_impl /build/python/cpython/Python/bltinmodule.c:1035:13
        #106 0x1f1aa5d in builtin_exec /build/python/cpython/Python/clinic/bltinmodule.c.h:371:20
        #107 0x1caae6e in cfunction_vectorcall_FASTCALL /build/python/cpython/Objects/methodobject.c:424:24
        #108 0x58bcb5 in PyVectorcall_Call /build/python/cpython/Objects/call.c:230:16
        #109 0x58c3c6 in _PyObject_Call /build/python/cpython/Objects/call.c:265:16
        #110 0x58c8b1 in PyObject_Call /build/python/cpython/Objects/call.c:292:12
        #111 0x1017138 in do_call_core /build/python/cpython/Python/ceval.c:5141:9
        #112 0xfeada4 in _PyEval_EvalFrameDefault /build/python/cpython/Python/ceval.c:3609:22
        #113 0xf4068b in _PyEval_EvalFrame /build/python/cpython/./Include/internal/pycore_ceval.h:40:12
        #114 0x1025062 in _PyEval_EvalCode /build/python/cpython/Python/ceval.c:4376:14
        #115 0x58ec4e in _PyFunction_Vectorcall /build/python/cpython/Objects/call.c:395:12
        #116 0x10365bd in _PyObject_VectorcallTstate /build/python/cpython/./Include/cpython/abstract.h:114:11
        #117 0x1014541 in PyObject_Vectorcall /build/python/cpython/./Include/cpython/abstract.h:123:12
        #118 0x10151c6 in call_function /build/python/cpython/Python/ceval.c:5121:13
        #119 0xfe5a21 in _PyEval_EvalFrameDefault /build/python/cpython/Python/ceval.c:3516:23
        #120 0x59721b in _PyEval_EvalFrame /build/python/cpython/./Include/internal/pycore_ceval.h:40:12
        #121 0x58f614 in function_code_fastcall /build/python/cpython/Objects/call.c:329:24
        #122 0x58d86d in _PyFunction_Vectorcall /build/python/cpython/Objects/call.c:366:20
        #123 0x10365bd in _PyObject_VectorcallTstate /build/python/cpython/./Include/cpython/abstract.h:114:11
        #124 0x1014541 in PyObject_Vectorcall /build/python/cpython/./Include/cpython/abstract.h:123:12
        #125 0x10151c6 in call_function /build/python/cpython/Python/ceval.c:5121:13
        #126 0xfe5f00 in _PyEval_EvalFrameDefault /build/python/cpython/Python/ceval.c:3533:23
        #127 0x59721b in _PyEval_EvalFrame /build/python/cpython/./Include/internal/pycore_ceval.h:40:12
        #128 0x58f614 in function_code_fastcall /build/python/cpython/Objects/call.c:329:24
        #129 0x58d86d in _PyFunction_Vectorcall /build/python/cpython/Objects/call.c:366:20
        #130 0x10365bd in _PyObject_VectorcallTstate /build/python/cpython/./Include/cpython/abstract.h:114:11
        #131 0x1014541 in PyObject_Vectorcall /build/python/cpython/./Include/cpython/abstract.h:123:12
        #132 0x10151c6 in call_function /build/python/cpython/Python/ceval.c:5121:13
        #133 0xfe71eb in _PyEval_EvalFrameDefault /build/python/cpython/Python/ceval.c:3547:19
        #134 0x59721b in _PyEval_EvalFrame /build/python/cpython/./Include/internal/pycore_ceval.h:40:12
        #135 0x58f614 in function_code_fastcall /build/python/cpython/Objects/call.c:329:24
        #136 0x58d86d in _PyFunction_Vectorcall /build/python/cpython/Objects/call.c:366:20
        #137 0x10365bd in _PyObject_VectorcallTstate /build/python/cpython/./Include/cpython/abstract.h:114:11
        #138 0x1014541 in PyObject_Vectorcall /build/python/cpython/./Include/cpython/abstract.h:123:12
        #139 0x10151c6 in call_function /build/python/cpython/Python/ceval.c:5121:13
        #140 0xfe71eb in _PyEval_EvalFrameDefault /build/python/cpython/Python/ceval.c:3547:19
        #141 0x59721b in _PyEval_EvalFrame /build/python/cpython/./Include/internal/pycore_ceval.h:40:12
        #142 0x58f614 in function_code_fastcall /build/python/cpython/Objects/call.c:329:24
        #143 0x58d86d in _PyFunction_Vectorcall /build/python/cpython/Objects/call.c:366:20
        #144 0x5946bd in _PyObject_VectorcallTstate /build/python/cpython/./Include/cpython/abstract.h:114:11
        #145 0x5959b3 in object_vacall /build/python/cpython/Objects/call.c:791:14
        #146 0x595f4c in _PyObject_CallMethodIdObjArgs /build/python/cpython/Objects/call.c:882:24
        #147 0x11ffca4 in import_find_and_load /build/python/cpython/Python/import.c:1765:11
        #148 0x11fbbc7 in PyImport_ImportModuleLevelObject /build/python/cpython/Python/import.c:1866:15
        #149 0x1f1601a in builtin___import__ /build/python/cpython/Python/bltinmodule.c:280:12
        #150 0x1cb2676 in cfunction_call /build/python/cpython/Objects/methodobject.c:537:18
        #151 0x5873a9 in _PyObject_MakeTpCall /build/python/cpython/Objects/call.c:191:18
        #152 0x594638 in _PyObject_VectorcallTstate /build/python/cpython/./Include/cpython/abstract.h:112:16
        #153 0x591aaa in _PyObject_CallFunctionVa /build/python/cpython/Objects/call.c:542:18
        #154 0x590ea2 in PyObject_CallFunction /build/python/cpython/Objects/call.c:564:14
        #155 0x11f8d6e in PyImport_Import /build/python/cpython/Python/import.c:2067:9
        #156 0x11eb740 in PyImport_ImportModule /build/python/cpython/Python/import.c:1482:14
        #157 0x12f10ac in init_sys_streams /build/python/cpython/Python/pylifecycle.c:1962:19
        #158 0x12eed4d in init_interp_main /build/python/cpython/Python/pylifecycle.c:1034:14
        #159 0x12e3727 in pyinit_main /build/python/cpython/Python/pylifecycle.c:1107:23
        #160 0x12e41cf in Py_InitializeFromConfig /build/python/cpython/Python/pylifecycle.c:1151:18
        #161 0x4e6b2d in pymain_init /build/python/cpython/Modules/main.c:66:14
        #162 0x4df188 in pymain_main /build/python/cpython/Modules/main.c:694:23
        #163 0x4df653 in Py_BytesMain /build/python/cpython/Modules/main.c:727:12
        #164 0x4dcec7 in main /build/python/cpython/./Programs/python.c:15:12
        #165 0x7fda2537d0b2 in __libc_start_main /build/glibc-YYA7BZ/glibc-2.31/csu/../csu/libc-start.c:308:16
        #166 0x43501d in _start (/build/python/cpython/python+0x43501d)

    0x625000264148 is located 16 bytes to the right of 8248-byte region [0x625000262100,0x625000264138)
    allocated by thread T0 here:
        #0 0x4ad75d in malloc (/build/python/cpython/python+0x4ad75d)
        #1 0x8afdec in _PyMem_RawMalloc /build/python/cpython/Objects/obmalloc.c:99:12
        #2 0x8b909e in _PyMem_DebugRawAlloc /build/python/cpython/Objects/obmalloc.c:2145:24
        #3 0x8b0a36 in _PyMem_DebugRawMalloc /build/python/cpython/Objects/obmalloc.c:2178:12
        #4 0x8b39e3 in _PyMem_DebugMalloc /build/python/cpython/Objects/obmalloc.c:2330:12
        #5 0x8b5b32 in PyMem_Malloc /build/python/cpython/Objects/obmalloc.c:605:12
        #6 0x1f906d2 in block_new /build/python/cpython/Python/pyarena.c:80:25
        #7 0x1f93300 in block_alloc /build/python/cpython/Python/pyarena.c:111:24
        #8 0x1f91bd1 in PyArena_Malloc /build/python/cpython/Python/pyarena.c:182:15
        #9 0x1cf79e7 in _Py_arg /build/python/cpython/Python/Python-ast.c:3516:17
        #10 0x233c6d3 in param_rule /build/python/cpython/Parser/parser.c:5946:20
        #11 0x2338044 in param_with_default_rule /build/python/cpython/Parser/parser.c:5790:18
        #12 0x2323c16 in _loop1_153_rule /build/python/cpython/Parser/parser.c:24561:39
        #13 0x2319647 in _tmp_134_rule /build/python/cpython/Parser/parser.c:23634:31
        #14 0x23093c5 in invalid_parameters_rule /build/python/cpython/Parser/parser.c:15128:29
        #15 0x22f6a43 in params_rule /build/python/cpython/Parser/parser.c:5124:39
        #16 0x2058782 in function_def_raw_rule /build/python/cpython/Parser/parser.c:4917:23
        #17 0x20229a4 in function_def_rule /build/python/cpython/Parser/parser.c:4856:37
        #18 0x200e2da in compound_stmt_rule /build/python/cpython/Parser/parser.c:1872:33
        #19 0x200a873 in statement_rule /build/python/cpython/Parser/parser.c:1234:18
        #20 0x2007026 in _loop1_11_rule /build/python/cpython/Parser/parser.c:16174:30
        #21 0x200455a in statements_rule /build/python/cpython/Parser/parser.c:1193:18
        #22 0x230193f in block_rule /build/python/cpython/Parser/parser.c:6257:18
        #23 0x2392ac3 in class_def_raw_rule /build/python/cpython/Parser/parser.c:6196:18
        #24 0x202fb74 in class_def_rule /build/python/cpython/Parser/parser.c:6139:34
        #25 0x2010e47 in compound_stmt_rule /build/python/cpython/Parser/parser.c:1914:30
        #26 0x200a873 in statement_rule /build/python/cpython/Parser/parser.c:1234:18
        #27 0x2007026 in _loop1_11_rule /build/python/cpython/Parser/parser.c:16174:30
        #28 0x200455a in statements_rule /build/python/cpython/Parser/parser.c:1193:18
        #29 0x230193f in block_rule /build/python/cpython/Parser/parser.c:6257:18

    SUMMARY: AddressSanitizer: heap-buffer-overflow /build/python/cpython/Parser/pegen.c:2253:61 in _PyPegen_collect_call_seqs
    Shadow bytes around the buggy address:
      0x0c4a800447d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c4a800447e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c4a800447f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c4a80044800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c4a80044810: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x0c4a80044820: 00 00 00 00 00 00 00 fa fa[fa]fa fa fa fa fa fa
      0x0c4a80044830: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c4a80044840: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c4a80044850: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c4a80044860: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c4a80044870: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07 
      Heap left redzone:       fa
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack after return:      f5
      Stack use after scope:   f8
      Global redzone:          f9
      Global init order:       f6
      Poisoned by user:        f7
      Container overflow:      fc
      Array cookie:            ac
      Intra object redzone:    bb
      ASan internal:           fe
      Left alloca redzone:     ca
      Right alloca redzone:    cb
      Shadow gap:              cc
    ==39814==ABORTING

In particular, the stack trace here in the ASAN output indicates that it's the `EXTRA_EXPR(first, last)` macro use in this line that's problematic:

    return _Py_Call(_PyPegen_dummy_name(p), args, keywords, EXTRA_EXPR(first, last));

----------
components: Interpreter Core
messages: 376270
nosy: blarsen, gvanrossum, pablogsal
priority: normal
severity: normal
status: open
title: Heap buffer overflow in the parser
type: crash
versions: Python 3.10

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

From report at bugs.python.org  Wed Sep  2 21:32:40 2020
From: report at bugs.python.org (Andy Maier)
Date: Thu, 03 Sep 2020 01:32:40 +0000
Subject: [New-bugs-announce] [issue41698] io.[Text]IOBase.seek doesn't take
 keyword parameter - revisited
Message-ID: <1599096760.67.0.528727675431.issue41698@roundup.psfhosted.org>


New submission from Andy Maier <andreas.r.maier at gmx.de>:

I stumbled across the problem reported in https://bugs.python.org/issue25030 on Python 3.8:

>>> with open('x.txt', 'a') as fp:
...   fp.seek(0, whence=os.SEEK_END)
... 
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
TypeError: seek() takes no keyword arguments

Which I coded with a keyword argument because the documentation says so:

   seek(offset, whence=SEEK_SET)

See https://docs.python.org/3.8/library/io.html#io.IOBase.seek

The fix for issue issue25030 changed the documentation to:

   seek(offset[, whence])

and supposedly was integrated into 2.7, 3.4, and the default branch back then.

It seems the fix got lost?

----------
assignee: docs at python
components: Documentation
messages: 376272
nosy: andymaier, docs at python
priority: normal
severity: normal
status: open
title: io.[Text]IOBase.seek doesn't take keyword parameter - revisited
versions: Python 3.8

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

From report at bugs.python.org  Wed Sep  2 23:24:15 2020
From: report at bugs.python.org (Sophia Wisdom)
Date: Thu, 03 Sep 2020 03:24:15 +0000
Subject: [New-bugs-announce] [issue41699] Potential memory leak with asyncio
 and run_in_executor
Message-ID: <1599103455.66.0.578420174204.issue41699@roundup.psfhosted.org>


New submission from Sophia Wisdom <sophia at reduct.video>:

The below example leaks ~20 megabytes of memory. The amount leaked is related to both the number of items in the list and the number of times `run_in_executor` is called.

```
import asyncio

def leaker():
    x = list(range(int(1000)))
    1/0

async def function():
    loop = asyncio.get_running_loop()
    for i in range(10000):
        loop.run_in_executor(None, leaker)
```
at this point, `ps -o rss -p {pid}` outputs about 10MB

after invoking this:
```
asyncio.run(function())
```
Memory jumps to about 94MB, and doesn't return.

The lists don't show up in `gc.get_objects()`, but the amount of memory leaked does increase (though not proportionately) when the lists increase in size.

Note - this doesn't happen if `run_in_executor` is `await`ed immediately, but it does still occur if we e.g. put the future in a dictionary and then `await` the results later.
The leak still occurs on my machine if the `1/0` is omitted, but not on a colleague's.

We're pretty confused as to why this happens, and would appreciate any help.

----------
components: asyncio
messages: 376275
nosy: asvetlov, sophia2, yselivanov
priority: normal
severity: normal
status: open
title: Potential memory leak with asyncio and run_in_executor
versions: Python 3.10, Python 3.8

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

From report at bugs.python.org  Thu Sep  3 05:40:09 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 03 Sep 2020 09:40:09 +0000
Subject: [New-bugs-announce] [issue41700] test_c_locale_coercion:
 test_PYTHONCOERCECLOCALE_set_to_one() failed on PPC64 Fedora 3.9
Message-ID: <1599126009.78.0.459572903927.issue41700@roundup.psfhosted.org>


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

https://buildbot.python.org/all/#/builders/34/builds/16

pythoninfo:

pre_config[utf8_mode]: 1
os.environ[LANG]: C.UTF-8
sys.filesystem_encoding: utf-8/surrogateescape
sys.flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0, dev_mode=False, utf8_mode=1)

Tests logs:

0:23:06 load avg: 2.33 Re-running test_c_locale_coercion in verbose mode
skipped 'No C-with-UTF-8 locale available'
test_LC_ALL_set_to_C (test.test_c_locale_coercion.LocaleCoercionTests) ... ok
test_PYTHONCOERCECLOCALE_not_set (test.test_c_locale_coercion.LocaleCoercionTests) ... ok
test_PYTHONCOERCECLOCALE_not_zero (test.test_c_locale_coercion.LocaleCoercionTests) ... ok
test_PYTHONCOERCECLOCALE_set_to_one (test.test_c_locale_coercion.LocaleCoercionTests) ... ERROR
test_PYTHONCOERCECLOCALE_set_to_warn (test.test_c_locale_coercion.LocaleCoercionTests) ... ok
test test_c_locale_coercion failed
test_PYTHONCOERCECLOCALE_set_to_zero (test.test_c_locale_coercion.LocaleCoercionTests) ... ok

======================================================================
ERROR: test_PYTHONCOERCECLOCALE_set_to_one (test.test_c_locale_coercion.LocaleCoercionTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.9.edelsohn-fedora-ppc64/build/Lib/test/test_c_locale_coercion.py", line 410, in test_PYTHONCOERCECLOCALE_set_to_one
    loc = locale.setlocale(locale.LC_CTYPE, "")
  File "/home/shager/cpython-buildarea/3.9.edelsohn-fedora-ppc64/build/Lib/locale.py", line 610, in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting

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

Ran 6 tests in 3.138s

FAILED (errors=1, skipped=1)
1 test failed again:
    test_c_locale_coercion


I guess that the locale.setlocale(locale.LC_CTYPE, "") call should catch the locale.Error and skip the test if the locale is not supported.

----------
components: Tests
messages: 376290
nosy: ncoghlan, vstinner
priority: normal
severity: normal
status: open
title: test_c_locale_coercion: test_PYTHONCOERCECLOCALE_set_to_one() failed on PPC64 Fedora 3.9
versions: Python 3.9

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

From report at bugs.python.org  Thu Sep  3 06:21:19 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 03 Sep 2020 10:21:19 +0000
Subject: [New-bugs-announce] [issue41701] Buildbot web page: connection lost
 after 1 minute, then display "Connection restored" popup
Message-ID: <1599128479.83.0.639934661132.issue41701@roundup.psfhosted.org>


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

Since the buildbot server migrated to a new machine, the web page losts is connection and the whole web page is reloaded every minute. Try for example:

https://buildbot.python.org/all/#/release_status

The new buildbot.python.org machine is now behind a load balancer.

TCP connections closed after 1 minute already affected clients: see bpo-41642. It seems like HTTPS connections (tcp/443) are also affected.

----------
components: Tests
messages: 376293
nosy: vstinner
priority: normal
severity: normal
status: open
title: Buildbot web page: connection lost after 1 minute, then display "Connection restored" popup
versions: Python 3.10

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

From report at bugs.python.org  Thu Sep  3 07:45:52 2020
From: report at bugs.python.org (Valdemar Rolfsen)
Date: Thu, 03 Sep 2020 11:45:52 +0000
Subject: [New-bugs-announce] [issue41702] Inconcistent behaviour in strftime
Message-ID: <1599133552.94.0.223502406334.issue41702@roundup.psfhosted.org>


New submission from Valdemar Rolfsen <valdemar.rolfsen at gmail.com>:

Inconsistency in strftime between python 3.6 and 3.7 when parsing first-century dates.

Python 3.6
>>> datetime.datetime.strptime(d, "%Y-%m-%d").strftime("%Y-%m-%d")
'0020-10-05'

Python 3.7
>>> datetime.datetime.strptime("0020-10-05", "%Y-%m-%d").strftime("%Y-%m-%d")
'20-10-05'

This means that the following would work for 3.6 but raise a ValueError for 3.7:

>>> d = "0020-10-05"
>>> d = datetime.datetime.strptime(d, "%Y-%m-%d").strftime("%Y-%m-%d")
>>> d = datetime.datetime.strptime(d, "%Y-%m-%d").strftime("%Y-%m-%d")

----------
components: Library (Lib)
messages: 376296
nosy: belopolsky, p-ganssle, valdemarrolfsen
priority: normal
severity: normal
status: open
title: Inconcistent behaviour in strftime
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Thu Sep  3 09:26:53 2020
From: report at bugs.python.org (Matthieu Dartiailh)
Date: Thu, 03 Sep 2020 13:26:53 +0000
Subject: [New-bugs-announce] [issue41703] Most bytecode changes are absent
 from Python 3.9 What's new
Message-ID: <1599139613.26.0.744077883478.issue41703@roundup.psfhosted.org>


New submission from Matthieu Dartiailh <m.dartiailh at gmail.com>:

A number of bytecodes have been added removed in Python 3.9 as documented in https://docs.python.org/3.9/library/dis.html. However only the addition of LOAD_ASSERTION_ERROR is currently documented in What's New. The relevant bpo issues are:
- https://bugs.python.org/issue33387
- https://bugs.python.org/issue39320

----------
messages: 376298
nosy: mdartiailh
priority: normal
severity: normal
status: open
title: Most bytecode changes are absent from Python 3.9 What's new

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

From report at bugs.python.org  Thu Sep  3 11:29:29 2020
From: report at bugs.python.org (Jack Jansen)
Date: Thu, 03 Sep 2020 15:29:29 +0000
Subject: [New-bugs-announce] [issue41704] logging module needs some form of
 introspection or debugging support
Message-ID: <1599146969.01.0.981479655014.issue41704@roundup.psfhosted.org>


New submission from Jack Jansen <Jack.Jansen at cwi.nl>:

The logging module and its API make it easy to modify the behaviour of all loggers used in any package in your program.

Unfortunately the downside of this is that if any author of any module that you use changes the global logger configuration you get in a situation where all your logger calls are not behaving as expected. Moreover, it is very difficult to debug this and to find the culprit.

If the logger module had a global "debug logger usage" flag which would make it emit a log message whenever a call changed the global configuration this would help, especially if the messages were vectored through a single function or method that you could then set a breakpoint on.

----------
components: Library (Lib)
messages: 376308
nosy: jackjansen
priority: normal
severity: normal
status: open
title: logging module needs some form of introspection or debugging support
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Thu Sep  3 15:28:37 2020
From: report at bugs.python.org (Safihre)
Date: Thu, 03 Sep 2020 19:28:37 +0000
Subject: [New-bugs-announce] [issue41705] os.makedirs fails long-path
 UNC-paths if it is the first sub-folder
Message-ID: <1599161317.94.0.39054668985.issue41705@roundup.psfhosted.org>


New submission from Safihre <safihre at sabnzbd.org>:

It consistently fails on the first directory in a long-path UNC notation server-folder.

>>> os.makedirs(r"\\?\UNC\DiskStation\already_exists", exist_ok=True)
Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "C:\Users\safihre\AppData\Local\Programs\Python\Python38\lib\os.py", line 213, in makedirs
    makedirs(head, exist_ok=exist_ok)
  File "C:\Users\safihre\AppData\Local\Programs\Python\Python38\lib\os.py", line 213, in makedirs
    makedirs(head, exist_ok=exist_ok)
  File "C:\Users\safihre\AppData\Local\Programs\Python\Python38\lib\os.py", line 223, in makedirs
    mkdir(name, mode)
OSError: [WinError 123] The filename, directory name, or volume label syntax is incorrect: '\\\\?\\UNC\\'

>>> os.makedirs(r"\\?\UNC\DiskStation\already_exists")
Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "C:\Users\safihre\AppData\Local\Programs\Python\Python38\lib\os.py", line 213, in makedirs
    makedirs(head, exist_ok=exist_ok)
  File "C:\Users\safihre\AppData\Local\Programs\Python\Python38\lib\os.py", line 213, in makedirs
    makedirs(head, exist_ok=exist_ok)
  File "C:\Users\safihre\AppData\Local\Programs\Python\Python38\lib\os.py", line 223, in makedirs
    mkdir(name, mode)
OSError: [WinError 123] The filename, directory name, or volume label syntax is incorrect: '\\\\?\\UNC\\'


The second level directory is working correctly as expected:

>>> os.makedirs(r"\\?\UNC\DiskStation\already_exists\new")

>>> os.makedirs(r"\\?\UNC\DiskStation\already_exists\new")
Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "C:\Users\safihre\AppData\Local\Programs\Python\Python38\lib\os.py", line 223, in makedirs
    mkdir(name, mode)
FileExistsError: [WinError 183] Cannot create a file when that file already exists: '\\\\?\\UNC\\DiskStation\\test_get2\\test2'


Inspecting the code, I think the problem is in the os.path.exists function that is called from within os.makedirs, the line in os.makedirs says:
if head and tail and not path.exists(head):

But:
>>> head, tail = path.split(r"\\?\UNC\DiskStation\already_exists")
('\\\\?\\UNC\\DiskStation', 'already_exists')

>>> os.path.exists(r'\\?\UNC\DiskStation')
False
>>> os.path.exists(r'\\DiskStation')
False

So it wrongly goes ahead and tries to create \\?\UNC\DiskStation

----------
components: Windows
messages: 376312
nosy: Safihre, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: os.makedirs fails long-path UNC-paths if it is the first sub-folder
versions: Python 3.8

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

From report at bugs.python.org  Thu Sep  3 16:30:50 2020
From: report at bugs.python.org (William Chargin)
Date: Thu, 03 Sep 2020 20:30:50 +0000
Subject: [New-bugs-announce] [issue41706] docs: operator dunder (`__add__`,
 et al.) invocations described incorrectly
Message-ID: <1599165050.43.0.0605757296817.issue41706@roundup.psfhosted.org>


New submission from William Chargin <wchargin at gmail.com>:

The operator override dunder methods, like `__add__`, are described in
the ?Data model? docs here:
<https://docs.python.org/3.10/reference/datamodel.html#object.__add__>

Those docs say:

> For instance, to evaluate the expression `x + y`, where `x` is an
> instance of a class that has an `__add__()` method, `x.__add__(y)` is
> called.

But this is not correct: `x + y` always uses `type(x).__add__`, which
may be different from `x.__add__` if `__add__` has been set directly on
the instance.

Demonstration:

```
class C:
    def __add__(self, other):
        return "from class"


c = C()
print(c + c)  # prints "from class"

c.__add__ = lambda other: "from instance"
print(c.__add__(c))  # prints "from instance"
print(type(c).__add__(c, c))  # prints "from class"

print(c + c)  # prints "from class"!
```

The same issue appears in the reversed operator dunder (`__radd__`,
et al.) docs below.

I have a patch that I can submit as a PR; just need a bpo number.

----------
assignee: docs at python
components: Documentation
messages: 376316
nosy: docs at python, wchargin
priority: normal
severity: normal
status: open
title: docs: operator dunder (`__add__`, et al.) invocations described incorrectly
type: enhancement
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Sep  3 16:51:59 2020
From: report at bugs.python.org (Alex Mohr)
Date: Thu, 03 Sep 2020 20:51:59 +0000
Subject: [New-bugs-announce] [issue41707] Builtins like int() and float()
 should not blindly treat buffer protocol bytes as string characters.
Message-ID: <1599166319.13.0.56353332302.issue41707@roundup.psfhosted.org>


New submission from Alex Mohr <alexjmohr at gmail.com>:

Instead they should request and take into consideration the buffer object's data format.  For example, surely we don't want to treat floating point binary representations as string characters:

>>> from array import array
>>> a = array('f', [1.2, 2.3, 3.4])
>>> int(a)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for int() with base 10: b'\x9a\x99\x99?33\x13@\x9a\x99Y@'

It's even a little dangerous, since you can get "lucky" with certain binary representations:

>>> a = array('I', [875770417, 875770420])
>>> int(a)
12344234

----------
components: Interpreter Core
messages: 376317
nosy: amohr
priority: normal
severity: normal
status: open
title: Builtins like int() and float() should not blindly treat buffer protocol bytes as string characters.
type: behavior

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

From report at bugs.python.org  Thu Sep  3 17:56:49 2020
From: report at bugs.python.org (Jeff Scheibly)
Date: Thu, 03 Sep 2020 21:56:49 +0000
Subject: [New-bugs-announce] [issue41708] request make uninstall target
Message-ID: <1599170209.73.0.817887899624.issue41708@roundup.psfhosted.org>


New submission from Jeff Scheibly <jeff.scheibly at base2s.com>:

I went through and ran the make altinstall from the Python3.8.3.tar.gz and after running the .configure --enable-optimizations, I ran make altinstall, which was successful.

Would it be possible to get a uninstall target added so that in the case you may need a different version the uninstall would be super quick.

----------
components: Installation
messages: 376325
nosy: jeffs
priority: normal
severity: normal
status: open
title: request make uninstall target
versions: Python 3.8

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

From report at bugs.python.org  Fri Sep  4 03:04:28 2020
From: report at bugs.python.org (Kitty Beans)
Date: Fri, 04 Sep 2020 07:04:28 +0000
Subject: [New-bugs-announce] [issue41709] Idle erases clipboard upon closing
Message-ID: <1599203068.1.0.547512334334.issue41709@roundup.psfhosted.org>


New submission from Kitty Beans <Spacekiwigames at yahoo.com>:

Idle erases the contents of my clipboard after copying any text from the idle window, and then closing idle.

This happens on my Linux Mint 19.3 Laptop and Desktop; Windows 10 Laptop does not seem to have this issue (it has never altered my clipboard outside of me actually copying text)

Only tested with Idle version 3.6.8

----------
assignee: terry.reedy
components: IDLE
messages: 376337
nosy: Spacekiwigames, terry.reedy
priority: normal
severity: normal
status: open
title: Idle erases clipboard upon closing
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Fri Sep  4 04:34:54 2020
From: report at bugs.python.org (Jonas Norling)
Date: Fri, 04 Sep 2020 08:34:54 +0000
Subject: [New-bugs-announce] [issue41710] Timeout is affected by jumps in
 system time
Message-ID: <1599208494.85.0.752607116191.issue41710@roundup.psfhosted.org>


New submission from Jonas Norling <jonas.norling at greeneggs.se>:

The timeout for threading.Lock, threading.Condition, etc, is not using a monotonic clock ? it is affected if the system time (realtime clock) is set.

The attached program can be used to show the problem. It is expected to print "Took 2.000 s" repeatedly, but if run with permissions to set the system time, it prints:
$ sudo ./time_test.py
Took 2.400 s
Took 1.657 s
Took 2.044 s
Took 2.401 s
...

(the 1.6 s time can be explained by NTP correcting the clock)

There are already a number of closed bugs for this and related issues: bpo 23428, bpo 31267, bpo 35747.

This happens in Python 3.7.7 (ARM32, Yocto Warrior), Python 3.8.2 (AMD64, Ubuntu Linux 20.04) and Python v3.9.0rc1 (AMD64, Ubuntu Linux 20.04).

----------
components: Interpreter Core
files: time_test.py
messages: 376338
nosy: wocket
priority: normal
severity: normal
status: open
title: Timeout is affected by jumps in system time
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file49440/time_test.py

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

From report at bugs.python.org  Fri Sep  4 05:02:51 2020
From: report at bugs.python.org (pig)
Date: Fri, 04 Sep 2020 09:02:51 +0000
Subject: [New-bugs-announce] [issue41711] Socker send method throws a
 timeout exception
Message-ID: <1599210171.24.0.888697969812.issue41711@roundup.psfhosted.org>


Change by pig <pppig0921 at 163.com>:


----------
components: IO
nosy: pppig0921
priority: normal
severity: normal
status: open
title: Socker send method throws a timeout exception
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Fri Sep  4 05:47:22 2020
From: report at bugs.python.org (yeting li)
Date: Fri, 04 Sep 2020 09:47:22 +0000
Subject: [New-bugs-announce] [issue41712] REDoS in purge
Message-ID: <1599212842.75.0.630288607393.issue41712@roundup.psfhosted.org>


New submission from yeting li <liyt at ios.ac.cn>:

I  find this regex "(\d+\.\d+\.\d+)(\w+\d+)?$" may be stucked by input.
The vulnerable regex is located in
https://github.com/python/cpython/blob/54a66ade2067c373d31003ad260e1b7d14c81564/Tools/msi/purge.py#L15

The ReDOS vulnerability of the regex is mainly due to the sub-pattern \w+\d+
and can be exploited with the following string
"1.1.1"+"1" * 5000 + "!"


I think you can limit the input length or fix this regex.

For example, you can modify the sub-pattern \w+\d+ to ([A-Za-z_]*\d)+

Looking forward for your response?!

Best,
Yeting Li

----------
components: Library (Lib)
files: purge.py
messages: 376343
nosy: yetingli
priority: normal
severity: normal
status: open
title: REDoS in purge
type: security
versions: Python 3.10
Added file: https://bugs.python.org/file49443/purge.py

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

From report at bugs.python.org  Fri Sep  4 05:53:41 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Sep 2020 09:53:41 +0000
Subject: [New-bugs-announce] [issue41713] test_interpreters leaked [1424,
 1422, 1424] references
Message-ID: <1599213221.63.0.522110671593.issue41713@roundup.psfhosted.org>


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

AMD64 Fedora Rawhide Refleaks 3.x:
https://buildbot.python.org/all/#/builders/565/builds/11

test_interpreters leaked [1424, 1422, 1424] references, sum=4270

According to git bisect, the leak was introduced by:

commit 71d1bd9569c8a497e279f2fea6fe47cd70a87ea3
Author: Mohamed Koubaa <koubaa.m at gmail.com>
Date:   Thu Sep 3 03:21:06 2020 -0500

    bpo-1635741: Port _signal module to multi-phase init (PEP 489) (GH-22049)

 .../2020-09-01-17-07-20.bpo-1635741.7wSuCc.rst     |   1 +
 Modules/signalmodule.c                             | 168 +++++++++++----------
 2 files changed, 87 insertions(+), 82 deletions(-)


Example of leak:

$ ./python -m test -R 3:3 test_interpreters -m test.test_interpreters.TestInterpreterClose.test_from_current
0:00:00 load avg: 0.72 Run tests sequentially
0:00:00 load avg: 0.72 [1/1] test_interpreters
beginning 6 repetitions
123456
......
test_interpreters leaked [237, 237, 237] references, sum=711
test_interpreters leaked [18, 18, 18] memory blocks, sum=54
test_interpreters failed

== Tests result: FAILURE ==

1 test failed:
    test_interpreters

Total duration: 1.1 sec
Tests result: FAILURE

----------
components: Interpreter Core
messages: 376345
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_interpreters leaked [1424, 1422, 1424] references
versions: Python 3.10

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

From report at bugs.python.org  Fri Sep  4 06:19:47 2020
From: report at bugs.python.org (Richard Purdie)
Date: Fri, 04 Sep 2020 10:19:47 +0000
Subject: [New-bugs-announce] [issue41714] multiprocessing.Queue deadlock
Message-ID: <1599214787.05.0.21620669779.issue41714@roundup.psfhosted.org>


New submission from Richard Purdie <richard.purdie at linuxfoundation.org>:

We're having some problems with multiprocessing.Queue where the parent process ends up hanging with zombie children. The code is part of bitbake, the task execution engine behind OpenEmbedded/Yocto Project.

I've cut down our code to the pieces in question in the attached file. It doesn't give a runnable test case unfortunately but does at least show what we're doing. Basically, we have a set of items to parse, we create a set of multiprocessing.Process() processes to handle the parsing in parallel. Jobs are queued in one queue and results are fed back to the parent via another. There is a quit queue that takes sentinels to cause the subprocesses to quit.

If something fails to parse, shutdown with clean=False is called, the sentinels are sent. the Parser() process calls results.cancel_join_thread() on the results queue. We do this since we don't care about the results any more, we just want to ensure everyting exits cleanly. This is where things go wrong. The Parser processes and their queues all turn into zombies. The parent process ends up stuck in self.result_queue.get(timeout=0.25) inside shutdown().

strace shows its acquired the locks and is doing a read() on the os.pipe() it created. Unfortunately since the parent still has a write channel open to the same pipe, it hangs indefinitely.

If I change the code to do:

        self.result_queue._writer.close()
        while True:
            try:
               self.result_queue.get(timeout=0.25)
            except (queue.Empty, EOFError):
                break

i.e. close the writer side of the pipe by poking at the queue internals, we don't see the hang. The .close() method would close both sides.

We create our own process pool since this code dates from python 2.x days and multiprocessing pools had issues back when we started using this. I'm sure it would be much better now but we're reluctant to change what has basically been working. We drain the queues since in some cases we have clean shutdowns where cancel_join_thread() hasn't been used and we don't want those cases to block.

My question is whether this is a known issue and whether there is some kind of API to close just the write side of the Queue to avoid problems like this?

----------
components: Library (Lib)
files: simplified.py
messages: 376350
nosy: rpurdie
priority: normal
severity: normal
status: open
title: multiprocessing.Queue deadlock
type: crash
versions: Python 3.6
Added file: https://bugs.python.org/file49444/simplified.py

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

From report at bugs.python.org  Fri Sep  4 07:11:24 2020
From: report at bugs.python.org (yeting li)
Date: Fri, 04 Sep 2020 11:11:24 +0000
Subject: [New-bugs-announce] [issue41715] REDoS inc_analyzer
Message-ID: <1599217884.95.0.47859264992.issue41715@roundup.psfhosted.org>


New submission from yeting li <liyt at ios.ac.cn>:

Hi,

I find this regex "^([a-zA-Z]|_\w*[a-zA-Z]\w*|[a-zA-Z]\w*)$" may be stucked by input.
The vulnerable regex is located in
https://github.com/python/cpython/blob/54a66ade2067c373d31003ad260e1b7d14c81564/Tools/c-analyzer/c_analyzer/common/info.py#L12

The ReDOS vulnerability of the regex is mainly due to the sub-pattern \w*[a-zA-Z]\w*
and can be exploited with the following string
"_" + "a" * 5000 + "!"


I think you can limit the input length or fix this regex.


Looking forward for your response?!

Best,
Yeting Li

----------
files: info.py
messages: 376355
nosy: yetingli
priority: normal
severity: normal
status: open
title: REDoS inc_analyzer
Added file: https://bugs.python.org/file49445/info.py

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

From report at bugs.python.org  Fri Sep  4 08:12:06 2020
From: report at bugs.python.org (chen-y0y0)
Date: Fri, 04 Sep 2020 12:12:06 +0000
Subject: [New-bugs-announce] [issue41716] SyntaxError: EOL while scanning
 string literal
Message-ID: <1599221526.43.0.8824911096.issue41716@roundup.psfhosted.org>


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

# I try to run:
import os
os.system(r"start C:\Windows\System32\")
# But I get an Exception:
SyntaxError: EOL while scanning string literal
# A string after ?r? means the string's original meaning. But??

----------
components: Argument Clinic
messages: 376361
nosy: larry, prasechen
priority: normal
severity: normal
status: open
title: SyntaxError: EOL while scanning string literal
type: compile error
versions: Python 3.8

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

From report at bugs.python.org  Fri Sep  4 11:13:58 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Sep 2020 15:13:58 +0000
Subject: [New-bugs-announce] =?utf-8?b?W2lzc3VlNDE3MTddIFtBSVhdIHRlc3Rf?=
 =?utf-8?q?io=3A_files_was_modified_by_test=5Fio=3A_=28=40test=5F6488748?=
 =?utf-8?q?=5Ftmp=C3=A6=29_on_POWER6_AIX_3=2E9?=
Message-ID: <1599232438.83.0.403363375817.issue41717@roundup.psfhosted.org>


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

'@test_6488748_tmp?' is likely TESTFN_NONASCII which is exposed as test.support.os_helper.TESTFN, but test_io has many many tests using TESTFN.

https://buildbot.python.org/all/#/builders/330/builds/20

0:06:47 [130/425/1] test_io failed (env changed) (1 min 8 sec) -- running: test_concurrent_futures (31.1 sec)
(...)
Warning -- files was modified by test_io
  Before: []
  After:  ['@test_6488748_tmp?']

Since build 1, 19 days ago:
https://buildbot.python.org/all/#/builders/330/builds/1


If someone is able to reproduce the issue, please attempt to identify which test method leaks the temporary file using the command:

./python -m test.bisect_cmd test_io --fail-env-changed -v

After 10-20 minutes, the command should give the name of a single method which creates the temporary file.

----------
components: Tests
messages: 376371
nosy: BTaskaya, David.Edelsohn, vstinner
priority: normal
severity: normal
status: open
title: [AIX] test_io: files was modified by test_io: (@test_6488748_tmp?) on POWER6 AIX 3.9
versions: Python 3.9

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

From report at bugs.python.org  Fri Sep  4 11:36:12 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Sep 2020 15:36:12 +0000
Subject: [New-bugs-announce] [issue41718] test.regrtest has way too many
 imports
Message-ID: <1599233772.93.0.299899979889.issue41718@roundup.psfhosted.org>


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

Follow-up of bpo-40275.

While investigating a crash on AIX (bpo-40068), I noticed that test_threading crashed because the test imports the logging module, and the logging has a bug on AIX on fork. I created an issue to reduce the number of imports made by "import test.support":

https://bugs.python.org/issue40275
I would prefer to better isolate tests: test_threading should only test the threading module, not the logging module.

Thanks to the hard work of Hai Shi, "import test.support" now imports only 37 modules instead of 171! He split the 3200 lines of Lib/test/support/__init__.py into new helper submodules: bytecode, import, threading, socket, etc. For example, TESTFN now comes from test.support.os_helper.
Sadly, test.regrtest.save_env still imports asyncio and multiprocessing, and so in practice, running any test using "python -m test (...)" still imports around 233 modules :-(

I measured the number of imports done in practice using the following file, Lib/test/test_sys_modules.py:
----
import unittest
from test import support
import sys

class Tests(unittest.TestCase):
    def test_bug(self):
        modules = sorted(sys.modules)
        print("sys.modules:")
        print("")
        import pprint
        pprint.pprint(modules)
        print("")
        print("len(sys.modules):", len(modules))

def test_main():
    support.run_unittest(Tests)

if __name__ == "__main__":
    test_main()
----

master:

* ./python -m test test_sys_modules: 233 modules (multiprocessing, asyncio, etc.)
* ./python Lib/test/test_sys_modules.py: 95 modules

3.9:

* ./python -m test test_sys_modules: 232
* ./python Lib/test/test_sys_modules.py: 117

3.5:

* ./python -m test test_sys_modules: 167
* ./python Lib/test/test_sys_modules.py: 151

2.7:

* ./python -m test test_sys_modules: 170
* ./python Lib/test/test_sys_modules.py: 122

----------
components: Tests
messages: 376374
nosy: shihai1991, vstinner
priority: normal
severity: normal
status: open
title: test.regrtest has way too many imports
versions: Python 3.10

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

From report at bugs.python.org  Fri Sep  4 11:54:10 2020
From: report at bugs.python.org (chen-y0y0)
Date: Fri, 04 Sep 2020 15:54:10 +0000
Subject: [New-bugs-announce] [issue41719] Why does not range() support
 decimals?
Message-ID: <1599234850.47.0.91793785644.issue41719@roundup.psfhosted.org>


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

# I try:
>>> range(0,5,0.5)
# I hope it will (0.0,0.5,1.0,1.5,2.0,2.5,3.0,3.5,4.0,4.5). But...
Traceback (most recent call last):
  File "<pyshell#0>", line 1, in <module>
    range(0,5,0.5)
TypeError: 'float' object cannot be interpreted as an integer

----------
components: Argument Clinic
messages: 376378
nosy: larry, prasechen
priority: normal
severity: normal
status: open
title: Why does not range() support decimals?
type: compile error
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Fri Sep  4 13:41:53 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 04 Sep 2020 17:41:53 +0000
Subject: [New-bugs-announce] [issue41720] Missed "return NotImplemented" in
 Vec2D.__rmul__
Message-ID: <1599241313.26.0.364304470035.issue41720@roundup.psfhosted.org>


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

Vec2D.__rmul__() misses "return NotImplemented" and therefore implicitly returns None for arguments which are not int or float.

>>> import turtle
>>> print(object() * turtle.Vec2D(1, 2))
None

----------
components: Library (Lib)
messages: 376389
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Missed "return NotImplemented" in Vec2D.__rmul__
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Sep  4 16:00:05 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 04 Sep 2020 20:00:05 +0000
Subject: [New-bugs-announce] [issue41721] xlc: add -qalias=noansi -qmaxmem=-1
Message-ID: <1599249605.65.0.634527594272.issue41721@roundup.psfhosted.org>


Change by Stefan Krah <stefan at bytereef.org>:


----------
nosy: David.Edelsohn, skrah
priority: normal
severity: normal
status: open
title: xlc: add -qalias=noansi -qmaxmem=-1

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

From report at bugs.python.org  Fri Sep  4 19:14:43 2020
From: report at bugs.python.org (vishal rao)
Date: Fri, 04 Sep 2020 23:14:43 +0000
Subject: [New-bugs-announce] [issue41722] multiprocess error on large dataset
Message-ID: <1599261283.51.0.132892099897.issue41722@roundup.psfhosted.org>


New submission from vishal rao <vishalraoanizer at gmail.com>:

I am processing a large pandas dataframe using pathos framework which internally uses Python multiprocess package. I get the following error when i run the code with a large dataset. The issue doesn't occur on smaller datasets.
/opt/conda/lib/python3.7/site-packages/pathos/multiprocessing.py in map(self, f, *args, **kwds)
    135         AbstractWorkerPool._AbstractWorkerPool__map(self, f, *args, **kwds)
    136         _pool = self._serve()
--> 137         return _pool.map(star(f), zip(*args)) # chunksize
    138     map.__doc__ = AbstractWorkerPool.map.__doc__
    139     def imap(self, f, *args, **kwds):

/opt/conda/lib/python3.7/site-packages/multiprocess/pool.py in map(self, func, iterable, chunksize)
    266         in a list that is returned.
    267         '''
--> 268         return self._map_async(func, iterable, mapstar, chunksize).get()
    269 
    270     def starmap(self, func, iterable, chunksize=None):

/opt/conda/lib/python3.7/site-packages/multiprocess/pool.py in get(self, timeout)
    655             return self._value
    656         else:
--> 657             raise self._value
    658 
    659     def _set(self, i, obj):

/opt/conda/lib/python3.7/site-packages/multiprocess/pool.py in _handle_tasks(taskqueue, put, outqueue, pool, cache)
    429                         break
    430                     try:
--> 431                         put(task)
    432                     except Exception as e:
    433                         job, idx = task[:2]

/opt/conda/lib/python3.7/site-packages/multiprocess/connection.py in send(self, obj)
    207         self._check_closed()
    208         self._check_writable()
--> 209         self._send_bytes(_ForkingPickler.dumps(obj))
    210 
    211     def recv_bytes(self, maxlength=None):

/opt/conda/lib/python3.7/site-packages/multiprocess/connection.py in _send_bytes(self, buf)
    394         n = len(buf)
    395         # For wire compatibility with 3.2 and lower
--> 396         header = struct.pack("!i", n)
    397         if n > 16384:
    398             # The payload is large so Nagle's algorithm won't be triggered

error: 'i' format requires -2147483648 <= number <= 2147483647

I ran the code in debug mode, and saw that the value of n was 3140852627.

----------
components: Library (Lib)
messages: 376415
nosy: vishalraoanizer
priority: normal
severity: normal
status: open
title: multiprocess error on large dataset
versions: Python 3.7

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

From report at bugs.python.org  Fri Sep  4 22:53:13 2020
From: report at bugs.python.org (Sean Chao)
Date: Sat, 05 Sep 2020 02:53:13 +0000
Subject: [New-bugs-announce] [issue41723] doc: issue in a sentence in
 py_compile
Message-ID: <1599274393.95.0.247670918268.issue41723@roundup.psfhosted.org>


New submission from Sean Chao <seanchao0804 at gmail.com>:

I think in https://docs.python.org/3.10/library/py_compile.html#py_compile.compile
the sentence:
> If dfile is specified, it is used as the name of the source file in error messages when instead of file.
should not have the 'when'.

----------
assignee: docs at python
components: Documentation
messages: 376424
nosy: SeanChao, docs at python
priority: normal
severity: normal
status: open
title: doc: issue in a sentence in py_compile
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Sat Sep  5 02:23:53 2020
From: report at bugs.python.org (Ravi Misra)
Date: Sat, 05 Sep 2020 06:23:53 +0000
Subject: [New-bugs-announce] [issue41724] SQLite returns <str> instead of
 <datetime.datetime> with aggregate queries.
Message-ID: <1599287033.27.0.142696776365.issue41724@roundup.psfhosted.org>


New submission from Ravi Misra <ravimsh2004 at gmail.com>:

I tested the timestamp column in SQLite with MAX/MIN queries. They return string values instead of datetime.datetime.

----------
components: C API
messages: 376425
nosy: ravi-misra
priority: normal
severity: normal
status: open
title: SQLite returns <str> instead of <datetime.datetime> with aggregate queries.
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sat Sep  5 06:26:14 2020
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=)
Date: Sat, 05 Sep 2020 10:26:14 +0000
Subject: [New-bugs-announce] [issue41725] bz2 would use a dedicated
 exception for data error
Message-ID: <1599301574.54.0.309033165254.issue41725@roundup.psfhosted.org>


New submission from Micha? G?rny <mgorny at gentoo.org>:

Currently, the bz2 extension functions raise a generic OSError() on BZ_DATA_ERROR and BZ_DATA_ERROR_MAGIC.  When working on files, this makes it unnecessarily hard to catch compressor errors (i.e. invalid bz2 input file) without catching system I/O errors.  Could you please consider adding a new exception type for bz2 errors, akin to gzip.BadGzipFile?

----------
components: Extension Modules
messages: 376427
nosy: mgorny
priority: normal
severity: normal
status: open
title: bz2 would use a dedicated exception for data error
type: enhancement

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

From report at bugs.python.org  Sat Sep  5 11:40:32 2020
From: report at bugs.python.org (hai shi)
Date: Sat, 05 Sep 2020 15:40:32 +0000
Subject: [New-bugs-announce] [issue41726] Update the refcounts.dat of
 `PyType_FromModuleAndSpec`
Message-ID: <1599320432.34.0.409671228483.issue41726@roundup.psfhosted.org>


New submission from hai shi <shihai1991 at 126.com>:

`PyType_FromModuleAndSpec` in docs doesn't show the info:`Return value: New reference.`

----------
assignee: docs at python
components: Documentation
messages: 376432
nosy: docs at python, petr.viktorin, shihai1991
priority: normal
severity: normal
status: open
title: Update the refcounts.dat of `PyType_FromModuleAndSpec`
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Sat Sep  5 14:32:28 2020
From: report at bugs.python.org (MegMM)
Date: Sat, 05 Sep 2020 18:32:28 +0000
Subject: [New-bugs-announce] [issue41727] Confusing presentation for
 configuration settings references
Message-ID: <1599330748.16.0.0755344279451.issue41727@roundup.psfhosted.org>


New submission from MegMM <mm_reads at live.com>:

Priority: LOW
Keywords: Documentation, Presentation of configuration settings

Most of the documentation is excellent, but I'm running into a confusing method of referring to configuration settings in files. For instance on https://docs.python.org/3/library/venv.html, there is a section that reads:

The created pyvenv.cfg file also includes the include-system-site-packages key, set to true if venv is run with the --system-site-packages option, false otherwise.


Nothing about it is wrong but the presentation of the setting and variable should written as shown in the file instead of written out: "include-system-site-packages=True" 

Also, I see this in a lot of the documentation, which makes it hard to check if file settings match up with documentation as expected or not.

----------
assignee: docs at python
components: Documentation
files: SUGGESTED CHANGE-- venv.html
messages: 376436
nosy: MegMM, docs at python
priority: normal
severity: normal
status: open
title: Confusing presentation for configuration settings references
type: enhancement
versions: Python 3.8
Added file: https://bugs.python.org/file49446/SUGGESTED CHANGE-- venv.html

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

From report at bugs.python.org  Sat Sep  5 19:48:02 2020
From: report at bugs.python.org (Elliott Balsley)
Date: Sat, 05 Sep 2020 23:48:02 +0000
Subject: [New-bugs-announce] [issue41728] Add logfile() when debug is True
Message-ID: <1599349682.16.0.1036411059.issue41728@roundup.psfhosted.org>


New submission from Elliott Balsley <ebalsley at pm.me>:

When you add a TarInfo object created directly in memory, for example from a byte string, there is no debug logging available.  `tarfile.add()` logs the name of each file added when debug level is 1 or higher.  I think it would be a good idea to do the same for `tarfile.addfile()`, perhaps with a higher debug level.  It looks like debug=3 is currently unused, even though it's defined in the documentation.

----------
components: Library (Lib)
messages: 376448
nosy: ebalsley
priority: normal
severity: normal
status: open
title: Add logfile() when debug is True
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Sat Sep  5 19:59:41 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 05 Sep 2020 23:59:41 +0000
Subject: [New-bugs-announce] [issue41729] test_winconsoleio fails and hangs
 on Windows
Message-ID: <1599350381.8.0.512044336394.issue41729@roundup.psfhosted.org>


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

f:\dev\3x>python -m test test.test_winconsoleio
Running Debug|Win32 interpreter...
0:00:00 Run tests sequentially
0:00:00 [1/1] test.test_winconsoleio
??????????^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z








----
It quickly fails, prints seems garbage and several blanks lines, and hangs.  Ditto for 3.9 and 3.8.  When I ran entire suite, it was still hanging after 50 minutes.

Victor's patch for issue 38325 skipped the tests that failed on Windows, but now the overall test is worse.  One must interrupt with ^C to get the test summary for the suite.

----------
components: Tests, Windows
messages: 376449
nosy: eryksun, paul.moore, steve.dower, terry.reedy, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: test_winconsoleio fails and hangs on Windows
type: crash
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Sep  5 23:54:50 2020
From: report at bugs.python.org (wyz23x2)
Date: Sun, 06 Sep 2020 03:54:50 +0000
Subject: [New-bugs-announce] [issue41730] Show deprecation warnings for
 tkinter.tix
Message-ID: <1599364490.99.0.633496777395.issue41730@roundup.psfhosted.org>


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

The tkinter.tix module was deprecated since Python 3.6, but nether DeprecationWarning nor PendingDeprecationWarning is warned. It should show a message and removal might be scheduled for 3.11/3.12.

----------
components: Tkinter
messages: 376455
nosy: wyz23x2
priority: normal
severity: normal
status: open
title: Show deprecation warnings for tkinter.tix
type: behavior
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Sun Sep  6 00:57:49 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 06 Sep 2020 04:57:49 +0000
Subject: [New-bugs-announce] [issue41731] test_cmd_line_script fails with
 verbosity level more than 1
Message-ID: <1599368269.38.0.401478917428.issue41731@roundup.psfhosted.org>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

When verbosity level is more than 1 the test tries to print the script_exec_args passed to script. It fails when the tuple has more than 1 elements and is used in formatting with %r. The two tests fail as below : 

./python -m test test_cmd_line_script -vv

======================================================================
ERROR: test_package_error (test.test_cmd_line_script.CmdLineTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/root/cpython/Lib/test/test_cmd_line_script.py", line 368, in test_package_error
    self._check_import_error(["-m", "test_pkg"], msg, cwd=script_dir)
  File "/root/cpython/Lib/test/test_cmd_line_script.py", line 148, in _check_import_error
    print('Output from test script %r:' % script_exec_args)
TypeError: not all arguments converted during string formatting

======================================================================
ERROR: test_package_recursion (test.test_cmd_line_script.CmdLineTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/root/cpython/Lib/test/test_cmd_line_script.py", line 379, in test_package_recursion
    self._check_import_error(["-m", "test_pkg"], msg, cwd=script_dir)
  File "/root/cpython/Lib/test/test_cmd_line_script.py", line 148, in _check_import_error
    print('Output from test script %r:' % script_exec_args)
TypeError: not all arguments converted during string formatting

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

Ran 44 tests in 4.936s

FAILED (errors=2)
test test_cmd_line_script failed
test_cmd_line_script failed

== Tests result: FAILURE ==

1 test failed:
    test_cmd_line_script

Total duration: 5.0 sec
Tests result: FAILURE

----------
components: Tests
messages: 376457
nosy: xtreak
priority: normal
severity: normal
status: open
title: test_cmd_line_script fails with verbosity level more than 1
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Sep  6 05:06:52 2020
From: report at bugs.python.org (Diogo Flores)
Date: Sun, 06 Sep 2020 09:06:52 +0000
Subject: [New-bugs-announce] [issue41732] Custom iterator to memoryview -
 performance improvement
Message-ID: <1599383212.96.0.797075491806.issue41732@roundup.psfhosted.org>


New submission from Diogo Flores <dxflores at outlook.com>:

Hi,

Here's a patch that adds an iterator to memoryview, which makes iterating over memoryview objs considerably faster.

The following values result from a compilation with debug ON.

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

Without patch:

cpython: ./python.exe -m timeit -s "a=memoryview(b'x'*1000000)" "for x in a: pass"
5 loops, best of 5: 98 msec per loop

cpython: ./python.exe -m timeit -s "a=b'x'*1000000" "for x in a: pass"
5 loops, best of 5: 68.6 msec per loop


With patch:

cpython: ./python.exe -m timeit -s "a=memoryview(b'x'*1000000)" "for x in a: pass"
5 loops, best of 5: 68.1 msec per loop

cpython: ./python.exe -m timeit -s "a=b'x'*1000000" "for x in a: pass"
5 loops, best of 5: 70 msec per loop

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

Please let me know your thoughts regarding it.

Diogo

----------
messages: 376460
nosy: dxflores
priority: normal
severity: normal
status: open
title: Custom iterator to memoryview - performance improvement
versions: Python 3.10

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

From report at bugs.python.org  Sun Sep  6 09:41:11 2020
From: report at bugs.python.org (Jason Chen)
Date: Sun, 06 Sep 2020 13:41:11 +0000
Subject: [New-bugs-announce] [issue41733] ContextVar get value is unexpected
Message-ID: <1599399671.9.0.0244607607619.issue41733@roundup.psfhosted.org>


New submission from Jason Chen <chenzep at gmail.com>:

import asyncio
from contextvars import *

var = ContextVar('VarTest', default=None)

def get_var(tag=None):
    obj = var.get()
    if obj is None:
        obj = object()
        var.set(obj)
    print(f'{tag=}: get_var result is {obj=}')
    return obj

async def get_var_object(tag):
    return get_var(tag)

async def asyncio_main():
    await asyncio.gather(*[get_var_object(id) for id in range(2)])

def test(get_var_before_run=False):
    print(f'{get_var_before_run=}')
    if get_var_before_run:
        get_var()
    asyncio.run(asyncio_main())
    print()


if __name__ == '__main__':
    test(get_var_before_run=False)
    test(get_var_before_run=True)


---- Output:-------

tag=0: get_var result is obj=<object object at 0x7f194571d210>
tag=1: get_var result is obj=<object object at 0x7f194571d200>

get_var_before_run=True
tag=None: get_var result is obj=<object object at 0x7f194571d210>
tag=0: get_var result is obj=<object object at 0x7f194571d210>
tag=1: get_var result is obj=<object object at 0x7f194571d210>


--- my question: ------
-- all objects in get_var_before_run=True are same.
-- my expected result is all objects should be different, because the code runs in different context.

----------
components: asyncio
messages: 376464
nosy: asvetlov, chenzep, yselivanov
priority: normal
severity: normal
status: open
title: ContextVar get value is unexpected
versions: Python 3.8

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

From report at bugs.python.org  Sun Sep  6 15:15:07 2020
From: report at bugs.python.org (=?utf-8?q?Filipe_La=C3=ADns?=)
Date: Sun, 06 Sep 2020 19:15:07 +0000
Subject: [New-bugs-announce] [issue41734] Refactor b32{encode, decode} tests
Message-ID: <1599419707.5.0.662940988901.issue41734@roundup.psfhosted.org>


New submission from Filipe La?ns <filipe.lains at gmail.com>:

As discussed in https://github.com/python/cpython/pull/20441, these tests could be improved by using the same format of the b32hex{encode,decode} tests.

----------
components: Tests
messages: 376468
nosy: FFY00, p-ganssle
priority: normal
severity: normal
status: open
title: Refactor b32{encode,decode} tests
type: enhancement

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

From report at bugs.python.org  Sun Sep  6 23:14:46 2020
From: report at bugs.python.org (Ma Lin)
Date: Mon, 07 Sep 2020 03:14:46 +0000
Subject: [New-bugs-announce] [issue41735] Thread locks in zlib module may go
 wrong in rare case
Message-ID: <1599448486.98.0.401518384343.issue41735@roundup.psfhosted.org>


New submission from Ma Lin <malincns at 163.com>:

The code in zlib module:

    self->zst.next_in = data->buf;  // set next_in
    ...
    ENTER_ZLIB(self);   // acquire thread lock

`self->zst` is a `z_stream` struct defined in zlib, used to record states of a compress/decompress stream:

    typedef struct z_stream_s {
        Bytef    *next_in;  /* next input byte */
        uInt     avail_in;  /* number of bytes available at next_in */
        uLong    total_in;  /* total number of input bytes read so far */

        Bytef    *next_out; /* next output byte will go here */
        uInt     avail_out; /* remaining free space at next_out */
        uLong    total_out; /* total number of bytes output so far */
        
        ... // Other states
    } z_stream;

Setting `next_in` before acquiring the thread lock may mix up compress/decompress state in other threads.

Moreover, modify `ENTER_ZLIB` macro, don't release the GIL when the thread lock can be acquired immediately. This behavior is the same as the bz2/lzma modules.

----------
components: Library (Lib)
messages: 376473
nosy: malin
priority: normal
severity: normal
status: open
title: Thread locks in zlib module may go wrong in rare case
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Sep  7 10:13:38 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Sep 2020 14:13:38 +0000
Subject: [New-bugs-announce] [issue41736] test_site: test_s_option() failed
 on AMD64 Windows8.1 Refleaks 3.7
Message-ID: <1599488018.49.0.898281203833.issue41736@roundup.psfhosted.org>


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

It's not the first time that I see this error, but it looks random:

* 2009-11-08: bpo-7283: "test_site failure when .local/lib/pythonX.Y/site-packages hasn't been created yet": x86-64 Ubuntu 14.04 ICC Debug 3.5, AppVeyor (Windows)
* 2017-11-20: bpo-32091: "test_s_option() of test_site.HelperFunctionsTests failed on x86 Gentoo Refleaks 3.6"
* 2018-07-21: bpo-34177: "test_site fails in macOS-PR VSTS builds for 3.7 branch"
* 2019-09-16: bpo-38184: "test_site: test_s_option() failed on AMD64 Fedora Rawhide Refleaks 2.7 and AMD64 Fedora Stable Refleaks 3.7"
* etc.

Usually, I close the issue since it only occurs once and then hides for 1 year...

---

AMD64 Windows8.1 Refleaks 3.7:
https://buildbot.python.org/all/#/builders/63/builds/21

0:50:59 load avg: 4.70 [345/416/1] test_site failed -- running: test_multiprocessing_spawn (9 min 23 sec), test_importlib (1 min 11 sec)
beginning 6 repetitions
123456
.test test_site failed -- Traceback (most recent call last):
  File "D:\buildarea\3.7.ware-win81-release.refleak\build\lib\test\test_site.py", line 205, in test_s_option
    self.assertIn(usersite, sys.path)
AssertionError: 'C:\\Users\\buildworker\\AppData\\Roaming\\Python\\Python37\\site-packages' not found in ['D:\\buildarea\\3.7.ware-win81-release.refleak\\build', 'D:\\buildarea\\3.7.ware-win81-release.refleak\\build\\PCbuild\\amd64\\python37_d.zip', 'D:\\buildarea\\3.7.ware-win81-release.refleak\\build\\DLLs', 'D:\\buildarea\\3.7.ware-win81-release.refleak\\build\\lib', 'D:\\buildarea\\3.7.ware-win81-release.refleak\\build\\PCbuild\\amd64', 'D:\\buildarea\\3.7.ware-win81-release.refleak\\build', 'D:\\buildarea\\3.7.ware-win81-release.refleak\\build\\lib\\site-packages']
(...)
1:10:20 load avg: 0.08 Re-running test_site in verbose mode
beginning 6 repetitions
123456
......
beginning 6 repetitions
123456
test__getuserbase (test.test_site.HelperFunctionsTests) ... ok
(...)
test_no_home_directory (test.test_site.HelperFunctionsTests) ... ok
test_s_option (test.test_site.HelperFunctionsTests) ... FAIL
test_abs_paths (test.test_site.ImportSideEffectTests) ... ok
(...)
test_underpth_nosite_file (test.test_site._pthFileTests) ... ok

======================================================================
FAIL: test_s_option (test.test_site.HelperFunctionsTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\buildarea\3.7.ware-win81-release.refleak\build\lib\test\test_site.py", line 205, in test_s_option
    self.assertIn(usersite, sys.path)
AssertionError: 'C:\\Users\\buildworker\\AppData\\Roaming\\Python\\Python37\\site-packages' not found in ['D:\\buildarea\\3.7.ware-win81-release.refleak\\build', 'D:\\buildarea\\3.7.ware-win81-release.refleak\\build\\PCbuild\\amd64\\python37_d.zip', 'D:\\buildarea\\3.7.ware-win81-release.refleak\\build\\DLLs', 'D:\\buildarea\\3.7.ware-win81-release.refleak\\build\\lib', 'D:\\buildarea\\3.7.ware-win81-release.refleak\\build\\PCbuild\\amd64', 'D:\\buildarea\\3.7.ware-win81-release.refleak\\build', 'D:\\buildarea\\3.7.ware-win81-release.refleak\\build\\lib\\site-packages']

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

Ran 30 tests in 1.172s
(...)

----------
components: Tests
messages: 376496
nosy: corona10, pablogsal, vstinner
priority: normal
severity: normal
status: open
title: test_site: test_s_option() failed on AMD64 Windows8.1 Refleaks 3.7
versions: Python 3.7

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

From report at bugs.python.org  Mon Sep  7 11:36:37 2020
From: report at bugs.python.org (Danny Lin)
Date: Mon, 07 Sep 2020 15:36:37 +0000
Subject: [New-bugs-announce] [issue41737] Improper NotADirectoryError when
 opening a file under a fake directory
Message-ID: <1599492997.14.0.974001441191.issue41737@roundup.psfhosted.org>


New submission from Danny Lin <danny0838 at gmail.com>:

On Linux (tested on Ubuntu 16.04), if "/path/to/file" is an existing file, the code:

    open('/path/to/file/somename.txt')

raises NotADirectoryError: [Errno 20] Not a directory: '/path/to/file/somename.txt'

On Windows, similar code:

    open(r'C:\path\to\file\somename.txt')

raises FileNotFoundError: [Errno 2] No such file or directory: 'C:\\path\\chrome\\to\\file\\somename.txt'

I think the behavior on Linux is not correct. The user probably cares about the existence of the file to be opened, rather than whether its ancestor directories are valid.

OTOH, if NotADirectoryError should be raised, it should mention '/path/to/file' rather then '/path/to/file/somename.txt'. But what if '/path/to' or '/path' is actually a file? Should it be '/path/to' or '/path' instead for the same reason?

----------
messages: 376505
nosy: danny87105
priority: normal
severity: normal
status: open
title: Improper NotADirectoryError when opening a file under a fake directory
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Mon Sep  7 11:46:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Sep 2020 15:46:06 +0000
Subject: [New-bugs-announce] [issue41739] test_logging: threading_cleanup()
 failed to cleanup 1 threads (count: 1, dangling: 2)
Message-ID: <1599493566.06.0.792070733484.issue41739@roundup.psfhosted.org>


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

s390x RHEL8 LTO + PGO 3.x:
https://buildbot.python.org/all/#/builders/442/builds/399

0:01:43 load avg: 4.23 [229/423/1] test_logging failed (env changed) -- running: test_concurrent_futures (48.1 sec)
Warning -- threading_cleanup() failed to cleanup 1 threads (count: 1, dangling: 2)
Warning -- Dangling thread: <Thread(Thread-4, started daemon 4395811469584)>
Warning -- Dangling thread: <_MainThread(MainThread, started 4395867015984)>

----------
components: Tests
messages: 376509
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_logging: threading_cleanup() failed to cleanup 1 threads (count: 1, dangling: 2)
versions: Python 3.10

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

From report at bugs.python.org  Mon Sep  7 11:45:21 2020
From: report at bugs.python.org (Danny Lin)
Date: Mon, 07 Sep 2020 15:45:21 +0000
Subject: [New-bugs-announce] [issue41738] MIME type for *.zip becomes
 application/x-zip-compressed on Windows
Message-ID: <1599493521.86.0.992768213147.issue41738@roundup.psfhosted.org>


New submission from Danny Lin <danny0838 at gmail.com>:

On Windows, command "python -m mimetypes foo.zip" outputs "type: application/x-zip-compressed encoding: None", while it's "type: application/zip encoding: None" on Linux.

According to the mimetype.py in CPython source code, the MIME type for '.zip' is 'application/zip'. It seems to be overwritten somewhere on Windows.

----------
components: Windows
messages: 376508
nosy: danny87105, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: MIME type for *.zip becomes application/x-zip-compressed on Windows
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Mon Sep  7 15:21:29 2020
From: report at bugs.python.org (Phillip M. Feldman)
Date: Mon, 07 Sep 2020 19:21:29 +0000
Subject: [New-bugs-announce] [issue41740] string concatenation via `sum`
Message-ID: <1599506489.43.0.159938522754.issue41740@roundup.psfhosted.org>


New submission from Phillip M. Feldman <Phillip.M.Feldman at gmail.com>:

I'm not sure whether this is a bug or a feature request, but it seems as though the following should produce the same result:

In [1]: 'a' + 'b' + 'c'
Out[1]: 'abc'

In [2]: sum(('a', 'b', 'c'))
TypeError Traceback (most recent call last)
in
----> 1 sum(('a', 'b', 'c'))

TypeError: unsupported operand type(s) for +: 'int' and 'str'

The error message is confusing (there is no integer).

----------
components: Interpreter Core
messages: 376526
nosy: Phillip.M.Feldman at gmail.com
priority: normal
severity: normal
status: open
title: string concatenation via `sum`
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Mon Sep  7 17:50:53 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Sep 2020 21:50:53 +0000
Subject: [New-bugs-announce] [issue41741] test_peg_generator timed out (25
 min) on x86 Gentoo Non-Debug with X 3.9
Message-ID: <1599515453.81.0.896157572076.issue41741@roundup.psfhosted.org>


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

On the slow x86 Gentoo Non-Debug with X 3.9 buildbot, test_peg_generator timed out after 25 min, twice.

https://buildbot.python.org/all/#/builders/51/builds/24

Either, we increase the buildbot timeouts, test_peg_parser is made faster, or the test is splitted into multiple test files.

This buildbot worker is slow, so it sounds like a good idea to increase timeouts.


0:00:00 load avg: 4.79 Run tests in parallel using 2 child processes (timeout: 25 min, worker timeout: 30 min)
(...)
0:46:55 load avg: 6.60 [263/425/1] test_peg_generator crashed (Exit code 1) -- running: test_lib2to3 (5 min 20 sec)
Timeout (0:25:00)!
Thread 0xb7bcd700 (most recent call first):
  File "/buildbot/buildarea/cpython/3.9.ware-gentoo-x86.nondebug/build/Lib/subprocess.py", line 1873 in _try_wait
  File "/buildbot/buildarea/cpython/3.9.ware-gentoo-x86.nondebug/build/Lib/subprocess.py", line 1915 in _wait
  File "/buildbot/buildarea/cpython/3.9.ware-gentoo-x86.nondebug/build/Lib/subprocess.py", line 1185 in wait
  File "/buildbot/buildarea/cpython/3.9.ware-gentoo-x86.nondebug/build/Lib/distutils/spawn.py", line 76 in spawn
  File "/buildbot/buildarea/cpython/3.9.ware-gentoo-x86.nondebug/build/Lib/distutils/ccompiler.py", line 910 in spawn
  File "/buildbot/buildarea/cpython/3.9.ware-gentoo-x86.nondebug/build/Lib/distutils/unixccompiler.py", line 117 in _compile
  File "/buildbot/buildarea/cpython/3.9.ware-gentoo-x86.nondebug/build/Lib/distutils/ccompiler.py", line 574 in compile
  File "/buildbot/buildarea/cpython/3.9.ware-gentoo-x86.nondebug/build/Lib/distutils/command/build_ext.py", line 529 in build_extension
  File "/buildbot/buildarea/cpython/3.9.ware-gentoo-x86.nondebug/build/Lib/distutils/command/build_ext.py", line 474 in _build_extensions_serial
  File "/buildbot/buildarea/cpython/3.9.ware-gentoo-x86.nondebug/build/Lib/distutils/command/build_ext.py", line 449 in build_extensions
  File "/buildbot/buildarea/cpython/3.9.ware-gentoo-x86.nondebug/build/Lib/distutils/command/build_ext.py", line 340 in run
  File "/buildbot/buildarea/cpython/3.9.ware-gentoo-x86.nondebug/build/Tools/peg_generator/pegen/build.py", line 91 in compile_c_extension
  File "/buildbot/buildarea/cpython/3.9.ware-gentoo-x86.nondebug/build/Tools/peg_generator/pegen/testutil.py", line 104 in generate_parser_c_extension
  File "/buildbot/buildarea/cpython/3.9.ware-gentoo-x86.nondebug/build/Lib/test/test_peg_generator/test_c_parser.py", line 80 in build_extension
  File "/buildbot/buildarea/cpython/3.9.ware-gentoo-x86.nondebug/build/Lib/test/test_peg_generator/test_c_parser.py", line 83 in run_test
  File "/buildbot/buildarea/cpython/3.9.ware-gentoo-x86.nondebug/build/Lib/test/test_peg_generator/test_c_parser.py", line 446 in test_soft_keywords_lookahead

(...)
1:09:00 load avg: 6.25 Re-running test_peg_generator in verbose mode

(...)

10 slowest tests:
- test_tokenize: 7 min 54 sec
- test_unparse: 7 min 16 sec
- test_concurrent_futures: 6 min 44 sec
- test_lib2to3: 5 min 42 sec
- test_multiprocessing_spawn: 5 min 15 sec
- test_asyncio: 5 min 10 sec
- test_regrtest: 2 min 53 sec
- test_multiprocessing_forkserver: 2 min 38 sec
- test_unicodedata: 2 min 32 sec
- test_capi: 2 min 27 sec

1 test failed:
    test_peg_generator

(...)

test_syntax_error_for_string (test.test_peg_generator.test_c_parser.TestCParser) ... ok
test_ternary_operator (test.test_peg_generator.test_c_parser.TestCParser) ... ok
test_with_stmt_with_paren (test.test_peg_generator.test_c_parser.TestCParser) ... Timeout (0:25:00)!
Thread 0xb7bec700 (most recent call first):
  File "/buildbot/buildarea/cpython/3.9.ware-gentoo-x86.nondebug/build/Lib/subprocess.py", line 1873 in _try_wait
  File "/buildbot/buildarea/cpython/3.9.ware-gentoo-x86.nondebug/build/Lib/subprocess.py", line 1915 in _wait
  File "/buildbot/buildarea/cpython/3.9.ware-gentoo-x86.nondebug/build/Lib/subprocess.py", line 1185 in wait
  File "/buildbot/buildarea/cpython/3.9.ware-gentoo-x86.nondebug/build/Lib/distutils/spawn.py", line 76 in spawn
  File "/buildbot/buildarea/cpython/3.9.ware-gentoo-x86.nondebug/build/Lib/distutils/ccompiler.py", line 910 in spawn
  File "/buildbot/buildarea/cpython/3.9.ware-gentoo-x86.nondebug/build/Lib/distutils/unixccompiler.py", line 117 in _compile
  File "/buildbot/buildarea/cpython/3.9.ware-gentoo-x86.nondebug/build/Lib/distutils/ccompiler.py", line 574 in compile
  File "/buildbot/buildarea/cpython/3.9.ware-gentoo-x86.nondebug/build/Lib/distutils/command/build_ext.py", line 529 in build_extension
  File "/buildbot/buildarea/cpython/3.9.ware-gentoo-x86.nondebug/build/Lib/distutils/command/build_ext.py", line 474 in _build_extensions_serial
  File "/buildbot/buildarea/cpython/3.9.ware-gentoo-x86.nondebug/build/Lib/distutils/command/build_ext.py", line 449 in build_extensions
  File "/buildbot/buildarea/cpython/3.9.ware-gentoo-x86.nondebug/build/Lib/distutils/command/build_ext.py", line 340 in run
  File "/buildbot/buildarea/cpython/3.9.ware-gentoo-x86.nondebug/build/Tools/peg_generator/pegen/build.py", line 91 in compile_c_extension
  File "/buildbot/buildarea/cpython/3.9.ware-gentoo-x86.nondebug/build/Tools/peg_generator/pegen/testutil.py", line 104 in generate_parser_c_extension
  File "/buildbot/buildarea/cpython/3.9.ware-gentoo-x86.nondebug/build/Lib/test/test_peg_generator/test_c_parser.py", line 80 in build_extension
  File "/buildbot/buildarea/cpython/3.9.ware-gentoo-x86.nondebug/build/Lib/test/test_peg_generator/test_c_parser.py", line 83 in run_test
  File "/buildbot/buildarea/cpython/3.9.ware-gentoo-x86.nondebug/build/Lib/test/test_peg_generator/test_c_parser.py", line 343 in test_with_stmt_with_paren
  ...

----------
components: Tests
messages: 376535
nosy: pablogsal, vstinner, zach.ware
priority: normal
severity: normal
status: open
title: test_peg_generator timed out (25 min) on x86 Gentoo Non-Debug with X 3.9
versions: Python 3.9

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

From report at bugs.python.org  Tue Sep  8 04:45:15 2020
From: report at bugs.python.org (leveque)
Date: Tue, 08 Sep 2020 08:45:15 +0000
Subject: [New-bugs-announce] [issue41742] Request for
 docs.python.org/3/library/configparser.html#exceptions improvement
Message-ID: <1599554715.27.0.66152205525.issue41742@roundup.psfhosted.org>


New submission from leveque <jean-francois.leveque at sorbonne-universite.fr>:

Hi,

docs.python.org/3/library/configparser.html#exceptions does not mention KeyError which is mentioned under https://docs.python.org/3/library/configparser.html#mapping-protocol-access and https://docs.python.org/3/library/configparser.html#customizing-parser-behaviour.

Could it be added ?

Cheers,

----------
assignee: docs at python
components: Documentation
messages: 376551
nosy: docs at python, leveque
priority: normal
severity: normal
status: open
title: Request for docs.python.org/3/library/configparser.html#exceptions improvement
type: enhancement
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Sep  8 09:23:40 2020
From: report at bugs.python.org (David Williams)
Date: Tue, 08 Sep 2020 13:23:40 +0000
Subject: [New-bugs-announce] [issue41743] Remove Unnecessarily Gendered
 Language from the Documentation
Message-ID: <1599571420.09.0.38882357277.issue41743@roundup.psfhosted.org>


New submission from David Williams <mobiusinversion at gmail.com>:

The Python documentation contains unnecessarily verbose and gendered language which does not enhance clarity, and rather, serves as non-inclusive to the LGTBQ community

For example:
https://www.python.org/dev/peps/pep-3136/


"Introduction
The break statement allows the programmer to terminate a loop early, and the continue statement allows the programmer to move to the next iteration of a loop early. In Python currently, break and continue can apply only to the innermost enclosing loop.

Motivation
If the programmer wishes to move to the next iteration of an outer enclosing loop, or terminate multiple loops at once, he or she has a few less-than elegant options."

There are 2 issues here. First is that break and continue don't allow the programmer to do anything, they cause the program control flow to change. Second, there is no reason to appeal to gendered pronouns which are antiquated. The motivation section could easily be rewritten to a more include and parsimonious form (less chatter):

"Motivation
Python syntax is limited when it comes to moving to the next iteration of an outer enclosing loop, or terminating multiple loops at once, "

----------
assignee: docs at python
components: Documentation
messages: 376569
nosy: docs at python, mobiusinversion
priority: normal
severity: normal
status: open
title: Remove Unnecessarily Gendered Language from the Documentation
type: enhancement
versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Sep  8 11:33:50 2020
From: report at bugs.python.org (Vaclav Slavik)
Date: Tue, 08 Sep 2020 15:33:50 +0000
Subject: [New-bugs-announce] [issue41744] NuGet python.props only works in
 python nuget, not other variants
Message-ID: <1599579230.23.0.203265478789.issue41744@roundup.psfhosted.org>


New submission from Vaclav Slavik <vaclav at slavik.io>:

NuGet automatically includes .props file from the build directory in the target using the package, but only if the file has the correct name: it must be $(id).props. This means that Python's support for this only works correctly in the python nuget packages, but not in pythonx86 and others, because the file is copied as python.props (instead of pythonx86.props etc) there too.

----------
components: Windows
messages: 376577
nosy: paul.moore, steve.dower, tim.golden, vslavik, zach.ware
priority: normal
severity: normal
status: open
title: NuGet python.props only works in python nuget, not other variants
type: behavior

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

From report at bugs.python.org  Tue Sep  8 11:40:46 2020
From: report at bugs.python.org (Julian Berman)
Date: Tue, 08 Sep 2020 15:40:46 +0000
Subject: [New-bugs-announce] [issue41745] BoundArguments.arguments used in
 the recommended way to call a callable silently succeeds for nonexistent
 arguments
Message-ID: <1599579646.4.0.421271904228.issue41745@roundup.psfhosted.org>


New submission from Julian Berman <Julian+Python.org at GrayVines.com>:

The following code succeeds "silently", which seems undesirable:

    from inspect import signature
    def two():
        return 2
    bound = signature(two).bind()
    bound.arguments["does_not_exist"] = 12
    two(*bound.args, **bound.kwargs)

where the mechanism for finally calling `two` is the recommended way shown in the docs for `inspect.BoundArguments`: https://docs.python.org/3/library/inspect.html#inspect.BoundArguments.apply_defaults

What's happened there is that:

    print(b.args, b.kwargs)

"silently" ignored the non-existent argument.

Somewhere along the line here it seems like something should complain. I don't see previous discussion of this from quickly searching on the bug tracker, but obviously if I've missed something let me know.

I'm also not really sure what the desirable solution is. To me, it's possibly that BoundArguments should have a fully-managed way to invoke a callable rather than asking a user to unpack *args and *kwargs, and that that mechanism, say arguments.be_passed_to(callable) should do the error checking). Having `.arguments` full-on reject unknown parameters seems like another possibility but there may be reasons that's not a good idea (e.g. if you were to for some reason use a bound arguments object to call some other function that *did* take that additional argument).

----------
components: Library (Lib)
messages: 376578
nosy: Julian
priority: normal
severity: normal
status: open
title: BoundArguments.arguments used in the recommended way to call a callable silently succeeds for nonexistent arguments
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Sep  8 16:31:17 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 08 Sep 2020 20:31:17 +0000
Subject: [New-bugs-announce] [issue41746] Add optional type information to
 asdl_seq objects
Message-ID: <1599597077.35.0.913235954629.issue41746@roundup.psfhosted.org>


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

Casting incorrect elements pulled from asdl_seq objects has been a pain when developing the new PEG parser and is a source of spooky-bug-at-a-distance problems in which the consequences of an incorrect casting from void* are felt much later.

I propose to add a new field to asdl_seq objects, which is an enumeration of the possible types it can contain. The main ideas are:

* By default, the enumeration will have UNDEFINED type.
* We can add some extra macros mirroring asdl_seq_GET and asdl_seq_SET that will receive the expected type and in debug mode will assert that the type is correct. Something like:

expr_ty item = asdl_set_GET_TYPED(sequence, n, EXPR);

* Usage of asdl_seq_GET and asdl_seq_SET do not do extra checks.

* To set the type information, we can add a new constructor:

asdl_seq_new_typed(size, arena, TYPE);

I think this change is worth because is not very invasive (old usage remains the same), we can slowly migrate only the parts that we need/want and will add some extra debugging possibilities for cases that has been quite challenging.

----------
components: Interpreter Core
messages: 376592
nosy: gvanrossum, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Add optional type information to asdl_seq objects
versions: Python 3.10

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

From report at bugs.python.org  Tue Sep  8 16:38:57 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Tue, 08 Sep 2020 20:38:57 +0000
Subject: [New-bugs-announce] [issue41747] dataclasses: generated method's
 using the wrong qualname
Message-ID: <1599597537.61.0.699248126431.issue41747@roundup.psfhosted.org>


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

$ cat t.py
from dataclasses import dataclass

@dataclass
class Foo:
    bar: int

Foo()
$ python t.py
Traceback (most recent call last):
  File "/home/isidentical/cpython/cpython/t.py", line 7, in <module>
    Foo()
TypeError: __create_fn__.<locals>.__init__() missing 1 required positional argument: 'bar'

----------
components: Library (Lib)
messages: 376594
nosy: BTaskaya, eric.smith
priority: normal
severity: normal
status: open
title: dataclasses: generated method's using the wrong qualname
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Tue Sep  8 17:59:30 2020
From: report at bugs.python.org (Ademar Nowasky Junior)
Date: Tue, 08 Sep 2020 21:59:30 +0000
Subject: [New-bugs-announce] [issue41748] HTMLParser: parsing error
Message-ID: <1599602370.01.0.842812753139.issue41748@roundup.psfhosted.org>


New submission from Ademar Nowasky Junior <nowasky.jr at gmail.com>:

HTML tags that have a attribute name starting with a comma character aren't parsed and break future calls to feed(). 

The problem occurs when such attribute is the second one or later in the HTML tag. Doesn't seems to affect when it's the first attribute.

#POC:

from html.parser import HTMLParser

class MyHTMLParser(HTMLParser):
    def handle_starttag(self, tag, attrs):
        print("Encountered a start tag:", tag)

parser = MyHTMLParser()

#This is ok
parser.feed('<yyy id="poc" a,="">')

#This breaks
parser.feed('<zzz id="poc" ,a="">')

#Future calls to feed() will not work
parser.feed('<img id="poc" src=x>')

----------
components: Library (Lib)
messages: 376607
nosy: nowasky.jr
priority: normal
severity: normal
status: open
title: HTMLParser: parsing error
type: crash
versions: Python 3.8

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

From report at bugs.python.org  Tue Sep  8 23:56:25 2020
From: report at bugs.python.org (Emmanuel Arias)
Date: Wed, 09 Sep 2020 03:56:25 +0000
Subject: [New-bugs-announce] [issue41749] Little improve on imghdr library
Message-ID: <1599623785.24.0.70056245504.issue41749@roundup.psfhosted.org>


New submission from Emmanuel Arias <eamanu at yaerobi.com>:

For the `what()` function, the `file` parameter is always needed.
In despite of that users can use `h` for send a bytes stream to 
detect the kind of the image, the `file` parameter is need.

Don't have sense ask for `file` parameter when this parameter will
not any effect on the result of the `what` function.

----------
components: Library (Lib)
messages: 376618
nosy: eamanu
priority: normal
severity: normal
status: open
title: Little improve on imghdr library
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Wed Sep  9 05:48:57 2020
From: report at bugs.python.org (J Rt)
Date: Wed, 09 Sep 2020 09:48:57 +0000
Subject: [New-bugs-announce] [issue41750] unpractical printing of datetimes
 by the interpreter
Message-ID: <1599644937.99.0.824034115929.issue41750@roundup.psfhosted.org>


New submission from J Rt <jean.rblt at gmail.com>:

I think the way datetimes get printed by the interpreter is a bit unpractical. For example:

datetime.datetime(2020, 9, 9, 8, 0, tzinfo=<UTC>) 

The reason for the inpracticality is that this cannot be put right into python back:

>>>datetime.datetime(2020, 9, 9, 8, 0, tzinfo=<UTC>)                                             
  File "<ipython-input-77-304f010bd0d1>", line 1
    datetime.datetime(2020, 9, 9, 8, 0, tzinfo=<UTC>)
                                               ^
SyntaxError: invalid syntax

Would there be a way to make the output printed directly usable again in the interpreter? Printing datetime.datetime(2020, 9, 9, 8, 0, tzinfo=pytz.utc) for example, or something like that?

----------
components: Library (Lib)
messages: 376626
nosy: jean.rblt
priority: normal
severity: normal
status: open
title: unpractical printing of datetimes by the interpreter
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Wed Sep  9 06:09:46 2020
From: report at bugs.python.org (Erez Zinman)
Date: Wed, 09 Sep 2020 10:09:46 +0000
Subject: [New-bugs-announce] [issue41751] Error copying an instance of a
 subclass of OrderedDict
Message-ID: <1599646186.11.0.087964047368.issue41751@roundup.psfhosted.org>


New submission from Erez Zinman <erezinman.programmer at gmail.com>:

This bug occurs when copying/pickling an ordered-dict subtype that has default items. The initialization function that's returned is **not** `object.__new__` so the default items are set when the copied/pickled item is created. The problem I encountered is that when deleting an initial item, it appears in the copy. See the MWE below:

```
from collections import OrderedDict
import copy


class A(OrderedDict):
    def __init__(self):
        self['123'] = 123

a = A()
del a['123']
copy.copy(a)


# --> A([('123', 123)])

```


This can cause other problems as well, because you don't assume that the class is re-initialized on deserialization/copy.

----------
components: Library (Lib)
messages: 376627
nosy: erezinman
priority: normal
severity: normal
status: open
title: Error copying an instance of a subclass of OrderedDict
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Wed Sep  9 09:00:36 2020
From: report at bugs.python.org (Karel)
Date: Wed, 09 Sep 2020 13:00:36 +0000
Subject: [New-bugs-announce] [issue41752] Wave shouldn't try to close an
 open file at all costs
Message-ID: <1599656436.68.0.838572818257.issue41752@roundup.psfhosted.org>


New submission from Karel <biosthezerg at centrum.cz>:

The standard `wave` library tries to close a file unconditionally. I believe this is wrong.

>From the docs:
Wave_write.close(): Make sure nframes is correct, and close the file if it was opened by wave. *This method is called upon object collection.* [...]

This leads to problems when an exception is throw when a file is open. See the following MWE:
```
from io import BytesIO
import wave
audio_out = BytesIO() 
with wave.open(audio_out, "w") as file_out:
    raise Exception('aaa!') 

Error: # channels not specified
```

Even when I remove the context manager, so it shouldn't close the file automatically, it still does, the following:
```
file_out = wave.open(audio_out, "w")
raise Exception('aaa!')
```
doesn't throw an error at me immediately, but when the file_out variable is running out of scope, I get a printout saying: `Exception ignored in: <bound method Wave_write.__del__ of <wave.Wave_write object at 0x7ff549064eb8>> [...] wave.Error: # channels not specified`.

Expected behaviour: When I use a Wave_write object as a context manager, it tries to close the file unconditionally (as it does now). When I call `wave.open` manually, no automatic file closing is done.

----------
components: Library (Lib)
messages: 376634
nosy: biosthezerg
priority: normal
severity: normal
status: open
title: Wave shouldn't try to close an open file at all costs
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Wed Sep  9 13:54:01 2020
From: report at bugs.python.org (Kaushik G)
Date: Wed, 09 Sep 2020 17:54:01 +0000
Subject: [New-bugs-announce] [issue41753] subprocess.run on windows does not
 convert path to string
Message-ID: <1599674041.89.0.322905352297.issue41753@roundup.psfhosted.org>


New submission from Kaushik G <kaushik.ghose at gmail.com>:

a call of the form `subprocess.run([x, y, z])` where one of the elements is a `pathlib.Pat`h fails on windows because the path is not converted to a string as it should. This works fine (as expected) on macOS and Linux.

A typical error message is:

`TypeError: argument of type 'WindowsPath' is not iterable`

----------
components: Windows
messages: 376651
nosy: kaushik.ghose, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: subprocess.run on windows does not convert path to string
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Thu Sep 10 02:15:31 2020
From: report at bugs.python.org (Tony DiLoreto)
Date: Thu, 10 Sep 2020 06:15:31 +0000
Subject: [New-bugs-announce] [issue41754] Webbrowser Module Cannot Find
 xdg-settings on OSX
Message-ID: <1599718531.77.0.777287973454.issue41754@roundup.psfhosted.org>


New submission from Tony DiLoreto <tony.diloreto at gmail.com>:

The following code does not work on many OSX installations of Python via homebrew:

>>> import webbrowser
>>> webbrowser.open("http://www.google.com")

And throws the following error stack trace:

  File "/usr/local/opt/python at 3.8/Frameworks/Python.framework/Versions/3.8/lib/python3.8/webbrowser.py", line 26, in register
    register_standard_browsers()
  File "/usr/local/opt/python at 3.8/Frameworks/Python.framework/Versions/3.8/lib/python3.8/webbrowser.py", line 551, in register_standard_browsers
    raw_result = subprocess.check_output(cmd, stderr=subprocess.DEVNULL)
  File "/usr/local/opt/python at 3.8/Frameworks/Python.framework/Versions/3.8/lib/python3.8/subprocess.py", line 411, in check_output
    return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
  File "/usr/local/opt/python at 3.8/Frameworks/Python.framework/Versions/3.8/lib/python3.8/subprocess.py", line 489, in run
    with Popen(*popenargs, **kwargs) as process:
  File "/usr/local/opt/python at 3.8/Frameworks/Python.framework/Versions/3.8/lib/python3.8/subprocess.py", line 854, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/usr/local/opt/python at 3.8/Frameworks/Python.framework/Versions/3.8/lib/python3.8/subprocess.py", line 1702, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
NotADirectoryError: [Errno 20] Not a directory: 'xdg-settings'



The only workaround right now is to modify webbrowser.py via the instructions here: https://github.com/jupyter/notebook/issues/3746#issuecomment-489259515.

Thank you for resolving.

----------
components: Library (Lib), macOS
messages: 376672
nosy: ned.deily, ronaldoussoren, tony.diloreto
priority: normal
severity: normal
status: open
title: Webbrowser Module Cannot Find xdg-settings on OSX
type: crash
versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Sep 10 16:29:13 2020
From: report at bugs.python.org (Thomas Guettler)
Date: Thu, 10 Sep 2020 20:29:13 +0000
Subject: [New-bugs-announce] [issue41755] Docs: Please remove `from
 distutils.core import setup`
Message-ID: <1599769753.52.0.764816611922.issue41755@roundup.psfhosted.org>


New submission from Thomas Guettler <guettli at thomas-guettler.de>:

Please remove this page or at least the code snippet 
containing `from distutils.core import setup`
on this page: https://docs.python.org/3/distutils/setupscript.html

There is the more up to date doc here: https://packaging.python.org/tutorials/packaging-projects/#creating-setup-py

Quoting Zen o Py: There should be one-- and preferably only one --obvious way to do it.

Thank you very much!

----------
messages: 376695
nosy: guettli
priority: normal
severity: normal
status: open
title: Docs: Please remove `from distutils.core import setup`

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

From report at bugs.python.org  Thu Sep 10 21:10:36 2020
From: report at bugs.python.org (Vladimir Matveev)
Date: Fri, 11 Sep 2020 01:10:36 +0000
Subject: [New-bugs-announce] [issue41756] Do not always use exceptions to
 return result from coroutine
Message-ID: <1599786636.95.0.884410425349.issue41756@roundup.psfhosted.org>


New submission from Vladimir Matveev <desco.by at gmail.com>:

Currently async functions are more expensive to use comparing to their sync counterparts. A simple microbenchmark shows that difference could be quite significant:
```
import time

def f(a):
    if a == 0:
        return 0
    return f(a - 1)

async def g(a):
    if a == 0:
        return 0
    return await g(a - 1)

N = 100000
C = 200

t0 = time.time()
for _ in range(N):
    f(C)
t1 = time.time()
for _ in range(N):
    try:
        g(C).send(None)
    except StopIteration:
        pass
t2 = time.time()

print(f"Sync functions: {t1 - t0} s")
print(f"Coroutines: {t2 - t1} s")
```
Results from master on my machine:

Sync functions: 2.8642687797546387 s
Coroutines: 9.172159910202026 s

NOTE: Due to viral nature of async functions their number in codebase could become quite significant so having hundreds of them in a single call stack is not something uncommon.

One of reasons of such performance gap is that async functions always return its results via raising StopIteration exception which is not cheap. This can be avoided if in addition to `_PyGen_Send` always return result via exception we could have another function that will allow us to distinguish whether value that was returned from generator is a final result (return case) of whether this is yielded value.
In linked PR I've added function `_PyGen_SendNoStopIteration` with this behavior and updated ceval.c and _asynciomodule.c to use it instead of `_PyGen_Send` which resulted in a measurable difference:

Sync functions: 2.8861589431762695 s
Coroutines: 5.730362176895142 s

----------
messages: 376698
nosy: v2m, yselivanov
priority: normal
severity: normal
status: open
title: Do not always use exceptions to return result from coroutine
type: performance
versions: Python 3.10

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

From report at bugs.python.org  Thu Sep 10 21:32:52 2020
From: report at bugs.python.org (Giordon Stark)
Date: Fri, 11 Sep 2020 01:32:52 +0000
Subject: [New-bugs-announce] [issue41757] weakmethod's ref is deleted before
 weakref's garbage-collect callback is executed
Message-ID: <1599787972.05.0.537049441536.issue41757@roundup.psfhosted.org>


New submission from Giordon Stark <kratsg+python at gmail.com>:

Hi, this is my first issue, so I hope to try my best to explain the problem. Unfortunately, I cannot get an easy minimum-reproducible-example of this because I can only seem to invoke this behavior using pytest (6.0.1) on two tests of our code. First, let me explain the issue.

AttributeError: 'NoneType' object has no attribute '_alive'
Exception ignored in: <function WeakMethod.__new__.<locals>._cb at 0x1696c2a70>
Traceback (most recent call last):
  File "/Users/kratsg/.virtualenvs/pyhf-dev/lib/python3.7/weakref.py", line 55, in _cb
    if self._alive:

occurs sometimes. Not always (feels like a race condition) and occurs after pytest has finished, which indicates it must be hitting garbage-collect. The backtrace isn't as helpful as it seems to jump from our code straight to the callback (indicating a garbage-collect):

/Users/kratsg/pyhf/tests/test_validation.py(1082)test_optimizer_stitching()
-> pdf = pyhf.simplemodels.hepdata_like([50.0], [100.0], [10])
  /Users/kratsg/pyhf/src/pyhf/simplemodels.py(64)hepdata_like()
-> return Model(spec, batch_size=batch_size)
  /Users/kratsg/pyhf/src/pyhf/pdf.py(590)__init__()
-> config=self.config, batch_size=self.batch_size
  /Users/kratsg/pyhf/src/pyhf/pdf.py(339)__init__()
-> self.config.auxdata_order,
  /Users/kratsg/pyhf/src/pyhf/parameters/paramview.py(66)__init__()
-> self._precompute()
  /Users/kratsg/pyhf/src/pyhf/parameters/paramview.py(78)_precompute()
-> self.allpar_viewer, self.selected_viewer, self.all_indices
  /Users/kratsg/pyhf/src/pyhf/parameters/paramview.py(27)extract_index_access()
-> index_selection = baseviewer.split(indices, selection=subviewer.names)
  /Users/kratsg/pyhf/src/pyhf/tensor/common.py(59)split()
-> data = tensorlib.einsum('...j->j...', tensorlib.astensor(data))
  /Users/kratsg/pyhf/src/pyhf/tensor/numpy_backend.py(268)einsum()
-> return np.einsum(subscripts, *operands)
  <__array_function__ internals>(6)einsum()
> /Users/kratsg/.virtualenvs/pyhf-dev/lib/python3.7/weakref.py(56)_cb()
-> if self._alive:

Essentially, inside weakref.py's _cb(), I tried to figure out what "self" was:

(Pdb) self
(Pdb) !arg
<weakref at 0x16f31c5d0; dead>

and it seems like the evaluation of "self._alive" is doomed to fail as self is None. So meth comes in, we take it apart into obj and func, define an inner function _cb that closes over a weakref to a weakref to obj and registers that function to fire when the underlying object gets gc'd. However, there seems to be an assumption that "self" is not None by the time the callback is fired.

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

Steps to reproduce:

Clone: https://github.com/scikit-hep/pyhf
Set up virtual env/install: python3 -m pip install -e .[complete]
Run pytest: pytest tests/test_validation.py -vvvv -k "test_optimizer_stitching[scipy-numpy or test_optimizer_stitching[minuit-numpy" -s

----------
components: macOS
messages: 376699
nosy: kratsg, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: weakmethod's ref is deleted before weakref's garbage-collect callback is executed
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Fri Sep 11 04:29:13 2020
From: report at bugs.python.org (Tushar Sadhwani)
Date: Fri, 11 Sep 2020 08:29:13 +0000
Subject: [New-bugs-announce] [issue41758] turtledemo.colormixer crashes with
 a stack overflow
Message-ID: <1599812953.89.0.679415765486.issue41758@roundup.psfhosted.org>


New submission from Tushar Sadhwani <tushar.sadhwani000 at gmail.com>:

turtledemo.colormixer crashes after (what i'm assuming) 1000 changes to the state of a color bar.


# Error:

PS C:\Users\tusha> python -m turtledemo.colormixer
Fatal Python error: Cannot recover from stack overflow.
Python runtime state: initialized

Current thread 0x00000f74 (most recent call first):
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\tkinter\__init__.py", line 2761 in coords
  File "<string>", line 1 in coords
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 755 in _pointlist
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 3158 in _goto
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 1826 in sety
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtledemo\colormixer.py", line 29 in shift
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 655 in eventfun
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\tkinter\__init__.py", line 1883 in __call__
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\tkinter\__init__.py", line 1305 in update
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 562 in _update
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 2662 in _update
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 3195 in _goto
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 1826 in sety
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtledemo\colormixer.py", line 29 in shift
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 655 in eventfun
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\tkinter\__init__.py", line 1883 in __call__
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\tkinter\__init__.py", line 1305 in update
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 562 in _update
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 583 in _bgcolor
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 1240 in bgcolor
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtledemo\colormixer.py", line 35 in setbgcolor
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtledemo\colormixer.py", line 32 in shift
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 655 in eventfun
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\tkinter\__init__.py", line 1883 in __call__
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\tkinter\__init__.py", line 1305 in update
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 562 in _update
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 2662 in _update
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 3195 in _goto
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 1826 in sety
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtledemo\colormixer.py", line 29 in shift
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 655 in eventfun
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\tkinter\__init__.py", line 1883 in __call__
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\tkinter\__init__.py", line 1305 in update
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 562 in _update
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 583 in _bgcolor
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 1240 in bgcolor
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtledemo\colormixer.py", line 35 in setbgcolor
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtledemo\colormixer.py", line 32 in shift
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 655 in eventfun
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\tkinter\__init__.py", line 1883 in __call__
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\tkinter\__init__.py", line 1305 in update
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 562 in _update
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 583 in _bgcolor
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 1240 in bgcolor
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtledemo\colormixer.py", line 35 in setbgcolor
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtledemo\colormixer.py", line 32 in shift
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 655 in eventfun
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\tkinter\__init__.py", line 1883 in __call__
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\tkinter\__init__.py", line 1305 in update
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 562 in _update
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 2662 in _update
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 3195 in _goto
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 1826 in sety
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtledemo\colormixer.py", line 29 in shift
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 655 in eventfun
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\tkinter\__init__.py", line 1883 in __call__
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\tkinter\__init__.py", line 1305 in update
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 562 in _update
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 583 in _bgcolor
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 1240 in bgcolor
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtledemo\colormixer.py", line 35 in setbgcolor
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtledemo\colormixer.py", line 32 in shift
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 655 in eventfun
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\tkinter\__init__.py", line 1883 in __call__
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\tkinter\__init__.py", line 1305 in update
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 562 in _update
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 2662 in _update
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 3195 in _goto
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 1826 in sety
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtledemo\colormixer.py", line 29 in shift
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 655 in eventfun
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\tkinter\__init__.py", line 1883 in __call__
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\tkinter\__init__.py", line 1305 in update
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 562 in _update
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 583 in _bgcolor
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 1240 in bgcolor
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtledemo\colormixer.py", line 35 in setbgcolor
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtledemo\colormixer.py", line 32 in shift
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 655 in eventfun
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\tkinter\__init__.py", line 1883 in __call__
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\tkinter\__init__.py", line 1305 in update
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 562 in _update
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 2662 in _update
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 2459 in pen
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 2291 in fillcolor
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtledemo\colormixer.py", line 31 in shift
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 655 in eventfun
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\tkinter\__init__.py", line 1883 in __call__
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\tkinter\__init__.py", line 1305 in update
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 562 in _update
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 2662 in _update
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 3195 in _goto
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 1826 in sety
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtledemo\colormixer.py", line 29 in shift
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 655 in eventfun
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\tkinter\__init__.py", line 1883 in __call__
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\tkinter\__init__.py", line 1305 in update
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 562 in _update
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 583 in _bgcolor
  File "C:\Users\tusha\.pyenv\pyenv-win\versions\3.8.1-amd64\lib\turtle.py", line 1240 in bgcolor
  ...

----------
components: Demos and Tools
messages: 376704
nosy: tusharsadhwani
priority: normal
severity: normal
status: open
title: turtledemo.colormixer crashes with a stack overflow
type: crash
versions: Python 3.8

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

From report at bugs.python.org  Fri Sep 11 05:22:51 2020
From: report at bugs.python.org (Freek de Kruijf)
Date: Fri, 11 Sep 2020 09:22:51 +0000
Subject: [New-bugs-announce] [issue41759] ElementTree.parse gives error
 message about missing1 required positional argument: 'source' but it is
 there
Message-ID: <1599816171.47.0.67185595118.issue41759@roundup.psfhosted.org>


New submission from Freek de Kruijf <f.de.kruijf at gmail.com>:

In a function definition I have the following piece of code:

    try:
        with open(requests,'rt') as f:
            tree = ElementTree.parse(f)

On execution I got:

Traceback (most recent call last):
   File "/srv/www/bin/web.py", line 362, in <module>
     build_db()
   File "/srv/www/bin/web.py", line 58, in build_db
     db_builder.build_DB()
   File "/srv/www/bin/db_builder.py", line 190, in build_DB
     tree = ElementTree.parse(f)
 TypeError: parse() missing 1 required positional argument: 'source'

There is an assignment for requests like
requests = '..' + os.path.sep + "/etc/signatures.xml"
This gives requests the value ..//etc/signatures.xml while the program runs in /srv/www/bin/

When I run the small python script like:

import xml.etree.ElementTree as ElementTree
with open('/srv/www/etc/signatures.xml','rt') as f:
    tree = ElementTree.parse(f)

all is well.
Apparently open(requests,'rt') does not raise an error.

----------
components: Extension Modules
messages: 376706
nosy: f.de.kruijf
priority: normal
severity: normal
status: open
title: ElementTree.parse gives error message about missing1 required positional argument: 'source' but it is there
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Fri Sep 11 05:47:08 2020
From: report at bugs.python.org (Matthias Klose)
Date: Fri, 11 Sep 2020 09:47:08 +0000
Subject: [New-bugs-announce] [issue41760] 3.8.6 rc1 documentation fails to
 build with sphinx 3.2.1
Message-ID: <1599817628.06.0.2679531144.issue41760@roundup.psfhosted.org>


New submission from Matthias Klose <doko at debian.org>:

the 3.8.6 rc1 documentation fails to build with sphinx 3.2.1:

[...]
reading sources... [ 98%] whatsnew/3.1
reading sources... [ 98%] whatsnew/3.2
reading sources... [ 98%] whatsnew/3.3
reading sources... [ 98%] whatsnew/3.4
reading sources... [ 98%] whatsnew/3.5
reading sources... [ 99%] whatsnew/3.6
reading sources... [ 99%] whatsnew/3.7
reading sources... [ 99%] whatsnew/3.8
reading sources... [ 99%] whatsnew/changelog
reading sources... [100%] whatsnew/index

/<<PKGBUILDDIR>>/Doc/tools/extensions/pyspecific.py:245: RemovedInSphinx40Warning: PyModulelevel is deprecated. Please check the implementation of <class 'pyspecific.PyDecoratorFunction'>
  return PyModulelevel.run(self)
/<<PKGBUILDDIR>>/Doc/tools/extensions/pyspecific.py:277: RemovedInSphinx40Warning: PyClassmember is deprecated. Please check the implementation of <class 'pyspecific.PyCoroutineMethod'>
  return PyClassmember.run(self)
/<<PKGBUILDDIR>>/Doc/tools/extensions/pyspecific.py:289: RemovedInSphinx40Warning: PyClassmember is deprecated. Please check the implementation of <class 'pyspecific.PyAwaitableMethod'>
  return PyClassmember.run(self)
/<<PKGBUILDDIR>>/Doc/tools/extensions/pyspecific.py:271: RemovedInSphinx40Warning: PyModulelevel is deprecated. Please check the implementation of <class 'pyspecific.PyCoroutineFunction'>
  return PyModulelevel.run(self)
/<<PKGBUILDDIR>>/Doc/tools/extensions/pyspecific.py:283: RemovedInSphinx40Warning: PyClassmember is deprecated. Please check the implementation of <class 'pyspecific.PyAwaitableFunction'>
  return PyClassmember.run(self)
/<<PKGBUILDDIR>>/Doc/tools/extensions/pyspecific.py:302: RemovedInSphinx40Warning: PyClassmember is deprecated. Please check the implementation of <class 'pyspecific.PyAbstractMethod'>
  return PyClassmember.run(self)

Warning, treated as error:
/<<PKGBUILDDIR>>/Doc/library/string.rst:311:duplicate token description of sign, other instance in library/functions
make[1]: *** [Makefile:52: build] Error 2

----------
components: Build
messages: 376711
nosy: doko
priority: normal
severity: normal
status: open
title: 3.8.6 rc1 documentation fails to build with sphinx 3.2.1
versions: Python 3.8

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

From report at bugs.python.org  Fri Sep 11 06:37:24 2020
From: report at bugs.python.org (Dominik Schmid)
Date: Fri, 11 Sep 2020 10:37:24 +0000
Subject: [New-bugs-announce] [issue41761] multiprocessing.Queue prevents
 program exit when containing a reasonable amount of data
Message-ID: <1599820644.84.0.266224553021.issue41761@roundup.psfhosted.org>


New submission from Dominik Schmid <dominikschmid93 at gmail.com>:

Reproduction steps: run the attached queue_busted.py

expected result: 
"done." is printed and the program terminates.

actual result:
"done." is printed and the program does not terminate.

Documentation link for your convenience:
https://docs.python.org/3.7/library/multiprocessing.html#multiprocessing.Queue.close

The lowest to trigger the bug seems to be 1639 42's in the queue.
If I put numpy.array([42]) into the queue instead of 42, I need much fewer items to trigger the bug.
When q.close() is called explicitly, it always terminates but sometimes prints a BrokenPipeError.

Reproduced on windows (Python 3.7.2) and Debian (Python 2.7.16).

----------
components: Library (Lib)
files: queue_busted.py
messages: 376716
nosy: Dominik Schmid
priority: normal
severity: normal
status: open
title: multiprocessing.Queue prevents program exit when containing a reasonable amount of data
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file49451/queue_busted.py

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

From report at bugs.python.org  Fri Sep 11 06:45:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Sep 2020 10:45:24 +0000
Subject: [New-bugs-announce] [issue41762] Documentation job fails on CIs:
 duplicate token description of format_spec
Message-ID: <1599821124.33.0.316149667628.issue41762@roundup.psfhosted.org>


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

https://travis-ci.com/github/python/cpython/jobs/383579366

Warning, treated as error:

/home/travis/build/python/cpython/Doc/library/string.rst:311:duplicate token description of format_spec, other instance in reference/lexical_analysis

----------
assignee: docs at python
components: Documentation
messages: 376717
nosy: docs at python, vstinner
priority: normal
severity: normal
status: open
title: Documentation job fails on CIs: duplicate token description of format_spec
versions: Python 3.10

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

From report at bugs.python.org  Fri Sep 11 11:39:13 2020
From: report at bugs.python.org (E. Paine)
Date: Fri, 11 Sep 2020 15:39:13 +0000
Subject: [New-bugs-announce] [issue41763] IDLE: scale font to Windows'
 "zoom" factor
Message-ID: <1599838753.63.0.774381112035.issue41763@roundup.psfhosted.org>


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

Following #33656, IDLE now "lies" to Windows and declares it has system DPI awareness to achieve a *sharper* look. System dpi is in effect:
DPI_AWARENESS_UNAWARE * Windows' zoom factor

Therefore, for IDLE to scale to the Windows' zoom/scale factor (System > Display > Scale and layout > Change the size of text, apps and other items), we need multiply the user's chosen font size by the zoom factor.

Unfortunately I cannot quote the docs about the multiplication I gave above but have extensively tested and found this to hold true (the docs are not very explanatory but a link and small snippet can be found below):

DPI_AWARENESS                Return value
DPI_AWARENESS_UNAWARE        96
DPI_AWARENESS_SYSTEM_AWARE   The system DPI.
[https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getdpiforwindow]

We can use the GetDpiForWindow function to get the system dpi and divide it by 96 (DPI_AWARENESS_UNAWARE) to get the scale factor for the font. This keeps IDLE sharp while allowing it to respect the user's scaling preferences.

I was not intending for this to not be an option (it would happen on any Windows system unless the user digs through the source), though appreciate that it could cause a significant change on first-load.

I considered adding this logic to the idlelib.run.fix_scaling method (which already modifies tkinter font size) but thought that users would not want this if their application was not set as DPI aware so settled on extending the idlelib.config.IdleConf.GetFont method instead.

My motivation for this is that currently that the user has to manually change their font size to match their Windows zoom factor (IDLE, without the user changing their font size, remains the same size regardless of what setting the user chooses as their scale factor). I have prepared a branch if this change is something that would interest you Terry.

Eryk, I have nosied you as I believe you are the person for Windows API calls (please do remove yourself if I am wrong).

----------
assignee: terry.reedy
components: IDLE
messages: 376733
nosy: epaine, eryksun, taleinat, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: scale font to Windows' "zoom" factor
type: enhancement
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Sep 11 13:12:58 2020
From: report at bugs.python.org (ali)
Date: Fri, 11 Sep 2020 17:12:58 +0000
Subject: [New-bugs-announce] [issue41764] sub function would not work
 without the flags but the search would work fine
Message-ID: <1599844378.36.0.50803589802.issue41764@roundup.psfhosted.org>


New submission from ali <alibayat006 at gmail.com>:

it would work like this sub("pattern","replace", txt, flags= re.IGNORECASE | re.DOTALL)
but it wouldnt work like this  sub("pattern","replace", txt, re.IGNORECASE | re.DOTALL)

----------
components: Regular Expressions
messages: 376734
nosy: bayat, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: sub function would not work without the flags but the search would work fine
versions: Python 3.8

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

From report at bugs.python.org  Fri Sep 11 18:42:29 2020
From: report at bugs.python.org (Mark Summerfield)
Date: Fri, 11 Sep 2020 22:42:29 +0000
Subject: [New-bugs-announce] [issue41765] XFCE task switcher shows 'Tk'
 insteadl of Window title
Message-ID: <1599864149.95.0.416329554824.issue41765@roundup.psfhosted.org>


New submission from Mark Summerfield <mark at qtrac.eu>:

This tiny test application illustrates the problem:
```python
#!/usr/bin/env python3
import tkinter as tk
app = tk.Tk()
app.withdraw()
app.title('Test App')
app.deiconify()
app.mainloop()
```
When run on Linux with XFCE the task bar entry shows the text 'Test App', but the task switcher shows 'Tk' rather than the title text.

----------
components: Tkinter
messages: 376745
nosy: mark
priority: normal
severity: normal
status: open
title: XFCE task switcher shows 'Tk' insteadl of Window title
type: behavior
versions: Python 3.6, Python 3.8

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

From report at bugs.python.org  Fri Sep 11 19:05:31 2020
From: report at bugs.python.org (neonene)
Date: Fri, 11 Sep 2020 23:05:31 +0000
Subject: [New-bugs-announce] [issue41766] Python3.10 (x64) crashes after
 flake8/pyflakes on Windows
Message-ID: <1599865531.82.0.625715596762.issue41766@roundup.psfhosted.org>


New submission from neonene <nicesalmon at gmail.com>:

On Python3.10(64bit only) for Windows,
flake8 (with .pyc cache) frequently crashes after output.

e.g:
python -m flake8   c:/Python3/Lib/turtle.py
python -m pyflakes c:/Python3/Lib/turtle.py

I think I encountered the crash after PR21293 applied.
(bpo-41194: "Convert _ast extension to PEP 489")

----------
components: Interpreter Core, Windows
messages: 376747
nosy: neonene, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python3.10 (x64) crashes after flake8/pyflakes on Windows
type: crash
versions: Python 3.10

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

From report at bugs.python.org  Fri Sep 11 20:17:04 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Sat, 12 Sep 2020 00:17:04 +0000
Subject: [New-bugs-announce] [issue41767] KeyError exception is more
 difficult to read due to quoting
Message-ID: <1599869824.76.0.302997879758.issue41767@roundup.psfhosted.org>


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

For example:

>>> import pwd
>>> pwd.getpwnam("test")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: "getpwnam(): name not found: 'test'"


An improvement would be something which doesn't have the extra set of quotes such as:

>>> import pwd
>>> pwd.getpwnam("test")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: getpwnam(): name not found: 'test'



I understand this is due to the `KeyError` repr, I wonder if something could be done to improve this (maybe a subclass of KeyError? maybe a new  optional named-only argument to KeyError?)


Seems there are others which could be improved here as well:

>>> import unicodedata
>>> unicodedata.lookup('zzz')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: "undefined character name 'zzz'"

----------
messages: 376754
nosy: Anthony Sottile
priority: normal
severity: normal
status: open
title: KeyError exception is more difficult to read due to quoting
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Sep 11 21:10:24 2020
From: report at bugs.python.org (melwitt)
Date: Sat, 12 Sep 2020 01:10:24 +0000
Subject: [New-bugs-announce] [issue41768] unittest.mock spec calls class
 properties
Message-ID: <1599873024.24.0.929930382889.issue41768@roundup.psfhosted.org>


New submission from melwitt <melwittt at gmail.com>:

When async magic method support was added to unittest.mock.Mock to address issue #26467, it introduced a getattr call [1] that causes class properties to be called when the class is used as a mock spec.

This caused a problem for a test in my project when running with Python 3.8 where previously the test worked OK with Python 3.6.

The test aims to verify that a class instance is not created if the called code path does not access the class property and thus the class will not create a heavy object unless it's needed (lazy create on access via @property).

As of Python 3.8, the @property is always called and is called by the mock spec process itself, even though the code path being tested does not access the class @property.

Here is a code snippet that illustrates the @property calling from the mock spec alone:

class SomethingElse(object):
    def __init__(self):
        self._instance = None

    @property
    def instance(self):
        if not self._instance:
            self._instance = 'object'

...

    def test_property_not_called_with_spec_mock(self):
        obj = SomethingElse()
        self.assertIsNone(obj._instance)
        mock = Mock(spec=obj)
        self.assertIsNone(obj._instance)

$ ./python -m unittest -v unittest.test.testmock.testmock.MockTest.test_property_not_called_with_spec_mock
test_property_not_called_with_spec_mock (unittest.test.testmock.testmock.MockTest) ... FAIL

======================================================================
FAIL: test_property_not_called_with_spec_mock (unittest.test.testmock.testmock.MockTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/vagrant/cpython/Lib/unittest/test/testmock/testmock.py", line 2173, in test_property_not_called_with_spec_mock
    self.assertIsNone(obj._instance)
AssertionError: 'object' is not None

[1] https://github.com/python/cpython/blob/fb2718720346c8c7a0ad2d7477f20e9a5524ea0c/Lib/unittest/mock.py#L492

----------
components: Library (Lib)
messages: 376757
nosy: melwitt
priority: normal
severity: normal
status: open
title: unittest.mock spec calls class properties
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Fri Sep 11 22:38:08 2020
From: report at bugs.python.org (Rafael Guterres Jeffman)
Date: Sat, 12 Sep 2020 02:38:08 +0000
Subject: [New-bugs-announce] [issue41769] Positional arguments which use
 store boolean actions do not behave as other actions.
Message-ID: <1599878288.06.0.921718987462.issue41769@roundup.psfhosted.org>


New submission from Rafael Guterres Jeffman <rjeffman at redhat.com>:

argparse allow the use of `store_true` and `store_false` for positional arguments, and although it is weird, it should be fine, but using either action raises a behavior I believe is wrong.

Given the following Python code:

```
import argparse

arg = argparse.ArgumentParser()
arg.add_argument("opt", action="store_false")

arg.parse_args(["-h"])
```

The output is:

```
usage: t.py [-h]

positional arguments:
  opt

optional arguments:
  -h, --help  show this help message and exit
```

Note that the positional argument is not shown in the `usage` line.

When any string parameter is given, the result is:

```
usage: t.py [-h]
t.py: error: unrecognized arguments:
```

(add to the end of the output the value of the argument.)

Even if the use of a positional value is not the best way to describe boolean parameter (optional arguments provide a much better interface for such values), if argparse is to support positional boolean values they should work as other positional arguments.

I'd suggest raising an error if store_true or store_false is used along with positional values.

----------
components: Library (Lib)
messages: 376764
nosy: rjeffman
priority: normal
severity: normal
status: open
title: Positional arguments which use store boolean actions do not behave as other actions.
versions: Python 3.8

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

From report at bugs.python.org  Fri Sep 11 23:00:14 2020
From: report at bugs.python.org (chen-y0y0)
Date: Sat, 12 Sep 2020 03:00:14 +0000
Subject: [New-bugs-announce] [issue41770] Import  module doesn't updated
Message-ID: <1599879614.84.0.25424318959.issue41770@roundup.psfhosted.org>


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

# I create a module:
# \sys.path\xxx.py
a = 9
# And:
>>> import xxx
>>> xxx.a
9
# I delete this imported module and modified this module:
del xxx
# \sys.path\xxx.py
a = 9
b = 8
# And re-import:
>>> import xxx
>>> xxx.b
# But:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: type object 'xxx' has no attribute 'b'

----------
components: Windows
messages: 376766
nosy: paul.moore, prasechen, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Import  module doesn't updated
type: resource usage
versions: Python 3.8

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

From report at bugs.python.org  Sat Sep 12 00:16:45 2020
From: report at bugs.python.org (Mark Hammond)
Date: Sat, 12 Sep 2020 04:16:45 +0000
Subject: [New-bugs-announce] [issue41771] bdist_wininst doesn't execute
 postinstall script
Message-ID: <1599884205.28.0.064503063783.issue41771@roundup.psfhosted.org>


New submission from Mark Hammond <mhammond at skippinet.com.au>:

install.c tries to dynamically load PyCFunction_New at https://github.com/python/cpython/blob/fb2718720346c8c7a0ad2d7477f20e9a5524ea0c/PC/bdist_wininst/install.c#L686 - however, since 3.8 this no longer exists - PyCFunction_New is a #define which calls PyCFunction_NewEx

----------
assignee: mhammond
messages: 376771
nosy: mhammond
priority: normal
severity: normal
status: open
title: bdist_wininst doesn't execute postinstall script
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Sep 12 02:38:10 2020
From: report at bugs.python.org (Amir Mohamadi)
Date: Sat, 12 Sep 2020 06:38:10 +0000
Subject: [New-bugs-announce] [issue41772] Zipfile.testzip considers wrong
 password as correct
Message-ID: <1599892690.25.0.248465863083.issue41772@roundup.psfhosted.org>


Change by Amir Mohamadi <amiremohamadi at yahoo.com>:


----------
components: Library (Lib)
nosy: Amir
priority: normal
severity: normal
status: open
title: Zipfile.testzip considers wrong password as correct
type: behavior

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

From report at bugs.python.org  Sat Sep 12 11:31:17 2020
From: report at bugs.python.org (Ram Rachum)
Date: Sat, 12 Sep 2020 15:31:17 +0000
Subject: [New-bugs-announce] [issue41773] Clarify handling of infinity and
 nan in random.choices
Message-ID: <1599924677.89.0.407491787221.issue41773@roundup.psfhosted.org>


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

I was recently tripped up by a bug caused by passing infinite weights to random.choices. I toyed around with that function, and it seemed that when it's given weights that include infinity or NaN, it selects a specific element, always without being random. That's regardless of whether multiple items have infinity weights. It chooses a different specific item if the infinity is negative. The specific item isn't always the one that has the infinite weight.

I don't know whether that's the intended behavior for some reason, or whether it's even possible to define a logical behavior for infinite weights. If it's not possible, then maybe this function should raise an errors when given weights that include infinity or nan.

I see that the documentation states that the weights must be non-negative; maybe we should have a check for that too.

----------
components: Library (Lib)
messages: 376802
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Clarify handling of infinity and nan in random.choices
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Sat Sep 12 12:20:35 2020
From: report at bugs.python.org (Sreedevi)
Date: Sat, 12 Sep 2020 16:20:35 +0000
Subject: [New-bugs-announce] [issue41774] While removing element from list
 using for and remove(), which has same items output is not right
Message-ID: <1599927635.78.0.618314187509.issue41774@roundup.psfhosted.org>


New submission from Sreedevi <sreedevi.ha at gmail.com>:

Define a list which has all same elements.
While removing the same element from list using for loop and by using remove() method, output should be empty list, but the output we get is one element is unremoved

----------
assignee: terry.reedy
components: IDLE, Windows
files: listrepxxx.py
messages: 376803
nosy: paul.moore, sreedevi.ha, steve.dower, terry.reedy, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: While removing element from list using for and remove(), which has same items output is not right
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file49454/listrepxxx.py

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

From report at bugs.python.org  Sun Sep 13 00:00:10 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 13 Sep 2020 04:00:10 +0000
Subject: [New-bugs-announce] [issue41775] IDLE: change Shell window title
Message-ID: <1599969610.9.0.339863836693.issue41775@roundup.psfhosted.org>


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

The IDLE Shell window title is set with pyshell line 836
    shell_title = "Python " + python_version() + " Shell"
The python_version() part was added in March 2013 by the first patch for issue 17390: https://hg.python.org/cpython/rev/74d9a9507019.

In issue 41765, Mark Summerfield suggested in a side-comment that the title should be 'IDLE'.

E. Paine agreed that it should be changed, suggesting that it contributes to the fact that "there are lots people when first starting who think the IDLE shell *is the* Python shell".  I have noticed this fact on Stackoverflow, where about half the questions tagged 'python-idle' have nothing to do with IDLE.  (I regularly remove such mistaken tags.)  I have wondered why and how to better counter this.  For one thing, it results in users blaming IDLE for Python behavior, such as not running buggy code.  I never noticed before that IDLE promotes the confusion a bit in the shell title.

Issues such as #37903 (move prompt to shell sidebar, which I am planning to review soon) and #37892 (separate input area) will differentiate the IDLE Shell from the standard REPL even more.

Paine suggested 'IDLE <version> Shell'.  I don't want to suggest that IDLE is independently versioned, and prefer 'IDLE Shell (<version>)'.  The parenthesized version is used for editor windows (and was also added by #17390).  On Windows, mousing over a taskbar icon initially shows about 10-14 variable-width letters of the title.  Is 'Shell' or '3.x.y' more important to be ensured of visibility?

Other suggestions and comments?

[If IDLE becomes a tabbed-window application, the window title would be 'IDLE (version)' and the shell would be on a 'Shell' tab.]

----------
assignee: terry.reedy
components: IDLE
messages: 376819
nosy: cheryl.sabella, epaine, taleinat, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE: change Shell window title
type: enhancement
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Sep 13 07:59:02 2020
From: report at bugs.python.org (AmirHossein Haji Mohammad Sadegh)
Date: Sun, 13 Sep 2020 11:59:02 +0000
Subject: [New-bugs-announce] [issue41776] Revise example of "continue" in
 the tutorial documentation
Message-ID: <1599998342.74.0.122825904284.issue41776@roundup.psfhosted.org>


New submission from AmirHossein Haji Mohammad Sadegh <amirrossein at gmail.com>:

It's not wrong but in the example for "continue" in the tutorial, the code prints "Found an even number" for even numbers and "Found a number" for odd numbers. Maybe it would be better if we print "Found an odd number" for odd numbers. Like this:

for num in range(2, 10):
    if num % 2 == 0:
        print("Found an even number", num)
        continue
    print("Found an odd number", num)

Found an even number 2
Found an odd number 3
Found an even number 4
Found an odd number 5
Found an even number 6
Found an odd number 7
Found an even number 8
Found an odd number 9

----------
assignee: docs at python
components: Documentation
messages: 376834
nosy: amirrossein, docs at python
priority: normal
severity: normal
status: open
title: Revise example of "continue" in the tutorial documentation
type: performance

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

From report at bugs.python.org  Sun Sep 13 09:23:48 2020
From: report at bugs.python.org (Edson Tadeu M. Manoel)
Date: Sun, 13 Sep 2020 13:23:48 +0000
Subject: [New-bugs-announce] [issue41777] When using `python -bb`,
 `struct.calcsize` raises a warning when used with str argument
 after being used with bytes (might be a larger problem with dicts)
Message-ID: <1600003428.26.0.120292470084.issue41777@roundup.psfhosted.org>


New submission from Edson Tadeu M. Manoel <e.tadeu at gmail.com>:

Here is the inconsistent behavior, when running with `python -bb` (or just `python -b`), caused by an internal cache:

    >>> import struct
    >>> struct.calcsize(b'!d')  # cache for '!d' uses bytes
    8
    >>> struct.calcsize('!d')  # so there's a warning when trying to use str
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    BytesWarning: Comparison between bytes and string
    >>> struct.calcsize('>d')  # cache for '>d' uses str
    8
    >>> struct.calcsize(b'>d')  # so now the warning is inverted, it shows up when trying to use bytes
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    BytesWarning: Comparison between bytes and string
    >>> struct.calcsize('>d')  # no problem when using str
    8

Note that this might be caused by a possible larger problem when dealing with keys of different string types in dicts under `python -b` (or `python -bb`):

    $ python
    Python 3.8.5 (tags/v3.8.5:580fbb0, Jul 20 2020, 15:57:54) [MSC v.1924 64 bit (AMD64)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> d={}
    >>> d['a']=1
    >>> d[b'a']=2
    >>> d['a']
    1
    >>> d[b'a']
    2


    $ python -bb
    Python 3.8.5 (tags/v3.8.5:580fbb0, Jul 20 2020, 15:57:54) [MSC v.1924 64 bit (AMD64)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> d={}
    >>> d['a']=1
    >>> d[b'a']=2
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>

I'm not sure if this warning is intentional, since in Python 3 there seems to be no special reason for dicts to try to compare 'a' with b'a' (other than possible implementation details).


Note: this is from an issue found here: https://github.com/pytest-dev/pytest-xdist/issues/596

----------
components: Interpreter Core, Library (Lib)
messages: 376836
nosy: tadeu
priority: normal
severity: normal
status: open
title: When using `python -bb`, `struct.calcsize` raises a warning when used with str argument after being used with bytes (might be a larger problem with dicts)
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sun Sep 13 16:50:22 2020
From: report at bugs.python.org (Emmanuel Arias)
Date: Sun, 13 Sep 2020 20:50:22 +0000
Subject: [New-bugs-announce] [issue41778] Change a punctuation on
 documentation
Message-ID: <1600030222.8.0.0896023770417.issue41778@roundup.psfhosted.org>


New submission from Emmanuel Arias <eamanu at yaerobi.com>:

On this paragrapah the clarification about IIS7 seems there's not
connection beacuase is in other sentence. Move the punctuation
to connect both the last sentence with the information in the
parenthesis.

I think the NEWS is not necessary here.

----------
components: email
messages: 376850
nosy: barry, eamanu, r.david.murray
priority: normal
severity: normal
status: open
title: Change a punctuation on documentation
versions: Python 3.10

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

From report at bugs.python.org  Mon Sep 14 02:10:16 2020
From: report at bugs.python.org (Ali Zaeri)
Date: Mon, 14 Sep 2020 06:10:16 +0000
Subject: [New-bugs-announce] [issue41779] add BLOB photo to sqlite3 python
Message-ID: <1600063816.71.0.85406743494.issue41779@roundup.psfhosted.org>


New submission from Ali Zaeri <alizaerialora at gmail.com>:

Hi this is my problem that I share it in stackowerflow hope you can help me:

https://stackoverflow.com/q/63763089/14168432

----------
messages: 376868
nosy: alizaerialora
priority: normal
severity: normal
status: open
title: add BLOB photo to sqlite3 python

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

From report at bugs.python.org  Mon Sep 14 03:06:06 2020
From: report at bugs.python.org (Allan Daemon)
Date: Mon, 14 Sep 2020 07:06:06 +0000
Subject: [New-bugs-announce] [issue41780] Generic Alias attributes nor in
 dir()
Message-ID: <1600067166.95.0.710796917701.issue41780@roundup.psfhosted.org>


New submission from Allan Daemon <rea.aft at gmail.com>:

The implementation of PEP 585 in 3.9 adds some new attributes, but they aren't listed with dir() (then, not list in autocomplete and IntelliSense).

Python 3.9.0rc1+ (heads/3.9:d7cd1164c1, Aug 25 2020, 17:27:09)

>>> li = list[int]
>>> li.__origin__
<class 'list'>
>>> getattr(li, '__origin__')
<class 'list'>
>>> '__origin__' in dir(li)
False

That applies to:

__origin__
__args__
__parameters__

It seems to be not the expected behaviour, so this bug report. If this is not the case, some piece of documentation could be interesting. Also, I couldn't find anything about Generic Alias in the documentation, only in the source code. Should this be addressed too?

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 376873
nosy: AllanDaemon, docs at python
priority: normal
severity: normal
status: open
title: Generic Alias attributes nor in dir()
type: behavior
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Mon Sep 14 08:00:22 2020
From: report at bugs.python.org (Patrick Reader)
Date: Mon, 14 Sep 2020 12:00:22 +0000
Subject: [New-bugs-announce] [issue41781] Typos in typing.py
Message-ID: <1600084822.87.0.84820912855.issue41781@roundup.psfhosted.org>


New submission from Patrick Reader <pxeger at protonmail.com>:

In typing.py, the `_allow_reckless_class_cheks` function is spelt wrong, and there is also a typo `instnance` in its docstring. I can do a PR but I thought I'd open an issue since it might be considered a breaking change (although it is `_private` so maybe not?)

https://github.com/python/cpython/blob/1b4552c5e8e925f24c15f707050f22c977171125/Lib/typing.py#L1037

----------
components: Library (Lib)
messages: 376877
nosy: pxeger
priority: normal
severity: normal
status: open
title: Typos in typing.py
versions: Python 3.10

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

From report at bugs.python.org  Mon Sep 14 09:49:54 2020
From: report at bugs.python.org (Shubham Singh)
Date: Mon, 14 Sep 2020 13:49:54 +0000
Subject: [New-bugs-announce] [issue41782] No f-string in
 logging.basicConfig()
Message-ID: <1600091394.24.0.394183543133.issue41782@roundup.psfhosted.org>


New submission from Shubham Singh <shubham.25powertech at gmail.com>:

There is no method to implement format strings in the basicConfig() method of the logging module. There are the implementations of '%', '{' or '$' for printf-style, str.format() or string.Template respectively using the style keyword.

----------
messages: 376878
nosy: shubham.25powertech
priority: normal
severity: normal
status: open
title: No f-string in logging.basicConfig()
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Mon Sep 14 12:44:39 2020
From: report at bugs.python.org (Mertcan)
Date: Mon, 14 Sep 2020 16:44:39 +0000
Subject: [New-bugs-announce] [issue41783] Standard Color class
Message-ID: <1600101879.5.0.216501247063.issue41783@roundup.psfhosted.org>


New submission from Mertcan <mertcand450 at hotmail.com>:

I think it would be useful to have a Color class in Python. Thus, it can become a standard and additional libraries may not be needed for many operations. Many libraries can be built around this Color class and can pave the way for many innovations. It can be a good advantage, especially in the GUI area, that beautiful libraries have a common data type. Thanks!

----------
components: Library (Lib)
messages: 376883
nosy: mertcandav
priority: normal
severity: normal
status: open
title: Standard Color class
type: enhancement

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

From report at bugs.python.org  Mon Sep 14 15:37:03 2020
From: report at bugs.python.org (Alex Gaynor)
Date: Mon, 14 Sep 2020 19:37:03 +0000
Subject: [New-bugs-announce] [issue41784] Promote PyUnicode_AsUTF8AndSize to
 be available with the limited API (PEP 384)
Message-ID: <1600112223.54.0.368726029107.issue41784@roundup.psfhosted.org>


New submission from Alex Gaynor <alex.gaynor at gmail.com>:

This function is incredibly useful for efficient interoperability between Python and other languages with UTF-8 based strings (e.g. Rust). Right now it's not possible to do interop without several copies/allocations if you're trying to build an abi3 wheel. This is tactically relevant to me here: https://github.com/PyO3/pyo3/issues/1125

This API has been stable since it was introduced in Python 3.1, so I think making it stable would be appropriate.

Inada, Benjamin suggested I should ask you for your feedback on this. I'm happy to send a pull request.

----------
components: C API
keywords: easy (C)
messages: 376896
nosy: alex, benjamin.peterson, inada.naoki
priority: normal
severity: normal
status: open
title: Promote PyUnicode_AsUTF8AndSize to be available with the limited API (PEP 384)
type: enhancement

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

From report at bugs.python.org  Mon Sep 14 16:57:09 2020
From: report at bugs.python.org (=?utf-8?q?Hildo_Guillardi_J=C3=BAnior?=)
Date: Mon, 14 Sep 2020 20:57:09 +0000
Subject: [New-bugs-announce] [issue41785] Unittest do not support datatime
 for AlmostEqual method
Message-ID: <1600117029.56.0.0494687927822.issue41785@roundup.psfhosted.org>


New submission from Hildo Guillardi J?nior <hildogjr at gmail.com>:

I am running a test

`self.assertAlmostEqual(date1, date2, 6)`

and getting the result:

ERROR: test_datetime_linspace (__main__.TestFunctions)
Check the linspace object output type and delta between them.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/lab/Documents/UNICAMP/LabREI/web-visualization/tests/test_interpreter.py", line 87, in test_datetime_linspace
    self.assertAlmostEqual(time_list[-1], now, 6)
  File "/usr/lib/python3.8/unittest/case.py", line 957, in assertAlmostEqual
    if round(diff, places) == 0:
TypeError: type datetime.timedelta doesn't define __round__ method


Despite the definition

@overload
    def assertAlmostEqual(self, first: datetime.datetime, second: datetime.datetime,
                          places: int = ..., msg: Any = ...,
                          delta: datetime.timedelta = ...) -> None: ...

on file case.pyi, the case.py doesn't deal good with `if round(diff, places) == 0:`, with `diff` the difference between the two varaibles.

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 376904
nosy: hildogjr
priority: normal
severity: normal
status: open
title: Unittest do not support datatime for AlmostEqual method
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Mon Sep 14 18:05:08 2020
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 14 Sep 2020 22:05:08 +0000
Subject: [New-bugs-announce] [issue41786] re.RegexFlag.__str__ is incorrect
Message-ID: <1600121108.29.0.968906869143.issue41786@roundup.psfhosted.org>


New submission from Ethan Furman <ethan at stoneleaf.us>:

In issue36548 - Make the repr of re flags more readable - __str__ is set to object.__str__.  Hovewer, setting __str__ to object.__str__ means that EnumMeta will replace __str__ with the first Enum's __str__ instead (Flag, in this case).

As asked in issue40066: do we want the str() and repr() to be the same, or should the str() be the plain numeric value?

----------
components: Library (Lib)
messages: 376911
nosy: ethan.furman, ezio.melotti, mrabarnett, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: re.RegexFlag.__str__ is incorrect
versions: Python 3.10

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

From report at bugs.python.org  Mon Sep 14 18:49:01 2020
From: report at bugs.python.org (Cameron Simpson)
Date: Mon, 14 Sep 2020 22:49:01 +0000
Subject: [New-bugs-announce] [issue41787] adding PEP references to
 documentation
Message-ID: <1600123741.16.0.294796218957.issue41787@roundup.psfhosted.org>


New submission from Cameron Simpson <cs at cskk.id.au>:

Add rationale for __length_hint__ and link to PEP 424, per the discussion here:

https://mail.python.org/archives/list/python-dev at python.org/thread/HXNFMIEZH73MXYEBP4TDIK3KFPYJ4QKR/#CXBEWAYSCAZCU7QABRBTKNVPDM3LELUM

Once the phrasing and directives are agreed, continue to chase other references in the docs.

This will produce multiple small PRs, possibly one per PEP as chased.

Phrasing:

I intend to amend the "New in version V." lines to become "New in version V, originally specified by PEPNNN." with a link to the PEP on "PEPNNN". I'm tempted to make "version V" also a link to its Whats New page; that will make for a bit more visual noise but seems pertinent.

The other thing I'd like to consider is a _single sentence_ in the docs identifying the main motivating use case for the feature. The __length_hint__ docs are a prime example here - the purpose of the feature is not mentioned, merely its semantics. While a feature can be used for many purposes, knowing why it was introduces brings a lot of cognitive benefit to the reader.

----------
assignee: docs at python
components: Documentation
messages: 376914
nosy: cameron, docs at python
priority: normal
severity: normal
status: open
title: adding PEP references to documentation

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

From report at bugs.python.org  Mon Sep 14 22:09:28 2020
From: report at bugs.python.org (Matthew Davis)
Date: Tue, 15 Sep 2020 02:09:28 +0000
Subject: [New-bugs-announce] [issue41788] enhancement: add assertDuration
 context manager to unittest module
Message-ID: <1600135768.52.0.225674115318.issue41788@roundup.psfhosted.org>


New submission from Matthew Davis <ubuntu.one at mdavis.xyz>:

# Summary

I propose an additional unit test type for the unittest module.
TestCase.assertDuration(min=None, max=None), which is a context manager, similar to assertRaises. It runs the code inside it, and then fails the test if the duration of the code inside was not between min and max.


# Use case

I want to check that when I call a certain function in my application, it doesn't take far more time than I expect, or far less time.

e.g. if I'm trying to do things concurrently, I want to test that they are indeed concurrent, by measuring whether the duration equals the sum of all processes' duration, or the max.

# MWE

```
import unittest
from time import sleep, time
from multiprocessing import Pool

def slow(x):
    sleep(x)
    
# blocking sleep for 0, 1, 2, 3 seconds, concurrently
def together():
    with Pool(4) as p:
        p.map(slow, range(4))

class TestConcurrent(unittest.TestCase):
    # this is how you do it today
    def test_today(self):
        start = time()
        together()
        end = time()
        duration = end - start
        self.assertGreaterEqual(duration, 2)
        # max should be 3 seconds, plus some overhead
        # if together() called slow() in series,
        # total duration would be 0 + 1 + 2 + 3 = 6 > 4
        self.assertLessEqual(duration, 4) 
        
    # this is how I want to do it
    def test_simpler(self):
        with self.assertDuration(min=2, max=4):
            together()
```

# Solution

I just need to add a new context manager next to this one:
https://github.com/python/cpython/blob/6b34d7b51e33fcb21b8827d927474ce9ed1f605c/Lib/unittest/case.py#L207

----------
components: Library (Lib)
messages: 376923
nosy: matt-davis
priority: normal
severity: normal
status: open
title: enhancement: add assertDuration context manager to unittest module

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

From report at bugs.python.org  Mon Sep 14 22:12:45 2020
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 15 Sep 2020 02:12:45 +0000
Subject: [New-bugs-announce] [issue41789] Enum: __str__ and friends
 sometimes erroneously replaced
Message-ID: <1600135965.76.0.76515083772.issue41789@roundup.psfhosted.org>


New submission from Ethan Furman <ethan at stoneleaf.us>:

If an Enum declares __str__, __repr__, __format__, or __reduce_ex__ to be object`s, then it will get replaced by the base Enum's corresponding method.  E.g.:

  class RegexFlag(IntFlag):

     IGNORECASE = I = 2

     def repr(self):
         return 're.%s' % self.name

     __str__ = object.__str__

The intent of the above is have str(RegexFlag.I) == repr(RegexFlag.I) (with some quotes, of course), but currently RegexFlag.__str__ will be replaced with Flag.__str__.

----------
assignee: ethan.furman
components: Library (Lib)
messages: 376924
nosy: barry, eli.bendersky, ethan.furman
priority: normal
severity: normal
stage: needs patch
status: open
title: Enum: __str__ and friends sometimes erroneously replaced
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Sep 14 23:15:13 2020
From: report at bugs.python.org (mohamed koubaa)
Date: Tue, 15 Sep 2020 03:15:13 +0000
Subject: [New-bugs-announce] [issue41790] C-API documentation
Message-ID: <1600139713.54.0.954662294559.issue41790@roundup.psfhosted.org>


New submission from mohamed koubaa <koubaa.m at gmail.com>:

The C-API documentation introduction contains an error:

"Almost all Python objects live on the
heap: you never declare an automatic or static variable of type
:c:type:`PyObject`, only pointer variables of type :c:type:`PyObject*` can  be
declared.  The sole exception are the type objects; since these must never be
deallocated, they are typically static :c:type:`PyTypeObject` objects."

With heap types, PyTypeObject can be deallocated.

----------
assignee: docs at python
components: Documentation
messages: 376926
nosy: docs at python, koubaa
priority: normal
pull_requests: 21308
severity: normal
status: open
title: C-API documentation
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Tue Sep 15 00:31:47 2020
From: report at bugs.python.org (Radim Novotny)
Date: Tue, 15 Sep 2020 04:31:47 +0000
Subject: [New-bugs-announce] [issue41791] mimetypes module does not
 recognize jp2 type
Message-ID: <1600144307.97.0.591745605568.issue41791@roundup.psfhosted.org>


New submission from Radim Novotny <novotny.radim at gmail.com>:

Even if jp2 is in the official list of types https://www.iana.org/assignments/media-types/media-types.xhtml it's not recognized by the MimeTypes.guess_type:

   >>> from mimetypes import MimeTypes
   >>> MimeTypes().guess_type('test.jp2')
   (None, None)

The same example works in Python 3.7 and returns 'image/jp2'

----------
messages: 376927
nosy: naro
priority: normal
severity: normal
status: open
title: mimetypes module does not recognize jp2 type
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Tue Sep 15 04:07:17 2020
From: report at bugs.python.org (Patrick Reader)
Date: Tue, 15 Sep 2020 08:07:17 +0000
Subject: [New-bugs-announce] [issue41792] No (public) way to dynamically
 introspect if an annotation is a TypedDict
Message-ID: <1600157237.06.0.946064898038.issue41792@roundup.psfhosted.org>


New submission from Patrick Reader <pxeger at protonmail.com>:

See https://github.com/python/typing/issues/751

----------
components: Library (Lib)
messages: 376931
nosy: pxeger
priority: normal
severity: normal
status: open
title: No (public) way to dynamically introspect if an annotation is a TypedDict

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

From report at bugs.python.org  Tue Sep 15 11:59:08 2020
From: report at bugs.python.org (wim glenn)
Date: Tue, 15 Sep 2020 15:59:08 +0000
Subject: [New-bugs-announce] [issue41793] Inaccuracy about reflected
 operands in datamodel docs.
Message-ID: <1600185548.76.0.619464921638.issue41793@roundup.psfhosted.org>


New submission from wim glenn <wim.glenn at gmail.com>:

Qualifying that the right operand's type must be a *strict* subclass for the reflected method to take precedence avoids an edge case / counter-example when the types are actually equal.

    >>> class A:
    ...     def __add__(self, other):
    ...         print(1)
    ...     def __radd__(self, other):
    ...         print(2)
    ...
    >>> A() + A()
    1
    >>> issubclass(A, A)
    True

----------
assignee: docs at python
components: Documentation
messages: 376944
nosy: docs at python, wim.glenn
priority: normal
severity: normal
status: open
title: Inaccuracy about reflected operands in datamodel docs.

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

From report at bugs.python.org  Wed Sep 16 01:28:08 2020
From: report at bugs.python.org (Bale)
Date: Wed, 16 Sep 2020 05:28:08 +0000
Subject: [New-bugs-announce] [issue41794] Memory leak in asyncio server
Message-ID: <1600234088.51.0.0738259012408.issue41794@roundup.psfhosted.org>


Change by Bale <hswhsw490 at gmail.com>:


----------
components: asyncio
nosy: EmperorBale, asvetlov, valid22, yselivanov
priority: normal
severity: normal
status: open
title: Memory leak in asyncio server
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Wed Sep 16 04:46:53 2020
From: report at bugs.python.org (Richard Neumann)
Date: Wed, 16 Sep 2020 08:46:53 +0000
Subject: [New-bugs-announce] [issue41795] Allow assignment in yield statement
Message-ID: <1600246013.94.0.808986319549.issue41795@roundup.psfhosted.org>


New submission from Richard Neumann <mail at richard-neumann.de>:

I often write factory (deserialization) methods for ORM models for web application backends that produce a number of records (ORM model instances) of itself and related database tables:

    @classmethod
    def from_json(cls, json):
        """Yields records from a JSON-ish dict."""
        modules = json.pop('modules', None) or ()
        order = super().from_json(json)
        yield order

        for module in modules:
            yield OrderedModule(order=order, module=Module(module))

This yields the main record "order" and related records from OrderedModules, which have a foreign key to Order.
Thusly I can save all records by:

    for record in Order.from_json(json):
        record.save()

Since I have several of those deserialization functions for multiple tables in multiple databases, it'd be nice to reduce the amount of code with some extra syntactic sugar, like:

    @classmethod
    def from_json(cls, json):
        """Yields records from a JSON-ish dict."""
        modules = json.pop('modules', None) or ()
        yield order = super().from_json(json)  # Assignment via "="

        for module in modules:
            yield OrderedModule(order=order, module=Module(module))

or:

    @classmethod
    def from_json(cls, json):
        """Yields records from a JSON-ish dict."""
        modules = json.pop('modules', None) or ()
        yield order := super().from_json(json)  # Assignment via ":="

        for module in modules:
            yield OrderedModule(order=order, module=Module(module))

I therefor propose to allow assignment of names in generator-like yield statements as described above.

----------
messages: 376979
nosy: conqp
priority: normal
severity: normal
status: open
title: Allow assignment in yield statement
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Wed Sep 16 06:10:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Sep 2020 10:10:24 +0000
Subject: [New-bugs-announce] [issue41796] _ast module state should be made
 per interpreter
Message-ID: <1600251024.87.0.709557549839.issue41796@roundup.psfhosted.org>


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

In September 2019, the _ast extension module was converted to PEP 384 (stable ABI): bpo-38113.

In bpo-41631, I moved the _ast module state back to a global state, rather than a regular module state, to fix multiple bugs.

The state should be made per intepreter (moved into PyInterpreterState).

Also, each interpreter should have its own _ast types (_ast.AST, _ast.Constant, etc.), rather than sharing all types.

Hopefully, in 3.9, _ast types have been converted to heap types.

To fix bpo-41631, I wanted to convert _ast.AST heap type back into a static type, to prevenet a subinterpreter to modify it, but Petr Viktorin asked me to leave it as it is:
https://github.com/python/cpython/pull/21961#issuecomment-685821519

I agree since I would like to convert all static types to heap types: bpo-40077.

----------
components: Interpreter Core
messages: 376983
nosy: vstinner
priority: normal
severity: normal
status: open
title: _ast module state should be made per interpreter
versions: Python 3.10

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

From report at bugs.python.org  Wed Sep 16 09:23:38 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 16 Sep 2020 13:23:38 +0000
Subject: [New-bugs-announce] [issue41797] PyModule_GetState doesn't work
 with LazyLoader
Message-ID: <1600262618.31.0.325694341017.issue41797@roundup.psfhosted.org>


New submission from Petr Viktorin <encukou at gmail.com>:

One underlying issue from bpo-41631 is that importlib.util.LazyLoader produces modules that are only fully loaded after an attribute is accessed (through __getattribute__).

C-API functions like PyModule_GetState, PyModule_GetDict and such do not get attributes, and when called on a _LazyModule, they might try to access uninitialized C-level state.

I see two possible ways to fix this:
- Make PyModule_GetState, etc. trigger a full load. Since this is C-API, it would need a fast (no Python code) way either to do the full load or to detect _LazyModule.
- Make LazyLoader eager for either all extension & builtin modules, or for modules that have C-level storage. The latter would need a way to pass info from PyModuleDef to the loader.


Brett, does that analysis make sense from the importlib POV?

----------
components: C API
messages: 376991
nosy: brett.cannon, petr.viktorin
priority: normal
severity: normal
status: open
title: PyModule_GetState doesn't work with LazyLoader

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

From report at bugs.python.org  Wed Sep 16 10:07:49 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Sep 2020 14:07:49 +0000
Subject: [New-bugs-announce] [issue41798] [C API] Revisit usage of the
 PyCapsule C API with multi-phase initialization API
Message-ID: <1600265269.2.0.881235166904.issue41798@roundup.psfhosted.org>


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

More and more extension modules are converted to the multi-phase initialization API (PEP 489) in bpo-1635741.

The problem is that the usage of the PyCapsule C API is not adapted in these extensions, to isolate well capsule objects from other module instances.

For example, the pyexpat extension uses "static struct PyExpat_CAPI capi;". It was fine when it was not possible to create more than one instance of the extension module. But with PR 22222 (currently under review), it becomes possible to have multiple extension module instances. Each module instance creates its own capsule object, but all capsule object points to the same unique "struct PyExpat_CAPI" instance.

For the specific case of the pyexpat in its current implementation, reusing the same "struct PyExpat_CAPI" instance is ok-ish, since the value is the same for all module instances. But this design sounds fragile.

It would be safer to allocate a "struct PyExpat_CAPI" on the heap memory in each module instance, and use a PyCapsule destructor function (3rd parameter of PyCapsule_New()).

The _ctypes does that:
---
        void *space = PyMem_Calloc(2, sizeof(int));
        if (space == NULL)
            return NULL;
        errobj = PyCapsule_New(space, CTYPES_CAPSULE_NAME_PYMEM, pymem_destructor);
---

with:
---
static void pymem_destructor(PyObject *ptr)
{
    void *p = PyCapsule_GetPointer(ptr, CTYPES_CAPSULE_NAME_PYMEM);
    if (p) {
        PyMem_Free(p);
    }
}
---


The PyCapsule API is used by multiple extension modules:

* _ctypes: allocate memory on the heap and uses a destructor to release it

* _curses: static variable, PyInit__curses() sets PyCurses_API[0] to &PyCursesWindow_Type (static type)

* _datetime: static variable, PyInit__datetime() creates a timezone object and stores it into CAPI.TimeZone_UTC

* _decimal: static variable

* _socket: static variable, PyInit__socket() sets PySocketModuleAPI.error to PyExc_OSError, and sets PySocketModuleAPI.timeout_error to _socket.timeout (a new exception object)

* pyexpat: static varaible

* unicodedata: static variable

* posix: nt._add_dll_directory() creates a PyCapsule using AddDllDirectory() result as a the pointer value
The _datetime module overrides the 


--

See also the PEP 630 "Isolating Extension Modules".

----------
components: C API
messages: 376992
nosy: vstinner
priority: normal
severity: normal
status: open
title: [C API] Revisit usage of the PyCapsule C API with multi-phase initialization API
versions: Python 3.10

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

From report at bugs.python.org  Wed Sep 16 14:09:57 2020
From: report at bugs.python.org (Jay Patel)
Date: Wed, 16 Sep 2020 18:09:57 +0000
Subject: [New-bugs-announce] [issue41799] splunklib.client does not handle
 Unicode characters
Message-ID: <1600279797.15.0.70851751953.issue41799@roundup.psfhosted.org>


New submission from Jay Patel <jay.patel at crestdatasys.com>:

Using splunklib.client module to use Pythonic interface to the Splunk REST API. I am using the connect method of the module to connect and log in to a Splunk instance.

Code:
import splunklib.client as splunk_client
kwargs_config_flags = {
                'host': "test_instance??",
                'port': 8089,
                'username': <username>,
                'password': <password>,
                'owner': None,
                'app': None}
sc = splunk_client.connect(**kwargs_config_flags)

For python 3
Output:
''latin-1' codec can't encode characters in position 0-1: ordinal not in range(256)'

I tried to encode the host to utf-8, "test_instance??".encode("utf-8")
Output:
'a bytes-like object is required, not 'str''

For python 2
It is working as expected.
output: 'nodename nor servname provided, or not known'

Is there a way by which this can be handled at the module level?

----------
components: Unicode
messages: 377005
nosy: ezio.melotti, jpatel, vstinner
priority: normal
severity: normal
status: open
title: splunklib.client does not handle Unicode characters
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Thu Sep 17 03:49:13 2020
From: report at bugs.python.org (=?utf-8?q?Jurko_Gospodneti=C4=87?=)
Date: Thu, 17 Sep 2020 07:49:13 +0000
Subject: [New-bugs-announce] [issue41800] Python installation fails when run
 under system account if there is already an existing installation on the
 system already
Message-ID: <1600328953.43.0.732217021063.issue41800@roundup.psfhosted.org>


New submission from Jurko Gospodneti? <jurko.gospodnetic at gmail.com>:

This issue seems to affect all Python 3 Windows installers.

Reproduced on:
- various Windows 10 systems
- one Windows 8 system
- one Windows 7 system
- all tested Python 3+ installers up to and including 3.8.5

Scenario:
1. there is already an existing Python 3+ installation on a Windows system, installed for all users
2. you run a Python 3+ installer (any version, even the one matching the already installed Python version) under the `systemprofile` Windows user account, targeting all users and the same target folder that the currently existing installation is located in
- example how to do this manually:
    - using the Microsoft/SysInternals `psexec` utility to open a command prompt running under the `systemprofile` Windows user account:
      `psexec -i -s cmd`
    - run the Python installer from that command-prompt, in our case it was the following command:
      `python-3.8.5.exe /passive TargetDir=C:\Python38 InstallAllUsers=1 PrependPath=1`
3. result will be any of the following at random:
- failed installation with different Windows error codes, including totally opaque 0x80070643 `Fatal Error during installation`
- successful installation
- seemingly successful installation that does not really install all the Python components, e.g. the whole `Lib` folder may end up being empty
- seemingly successful installation that then can not be uninstalled as the uninstaller reports that it can not find the existing installation on the system
  - this effect can often, but not always, be fixed by rerunning the installer and then running the uninstaller
    - you can run the uninstaller from the command-line using something like:
      `python-3.8.5.exe /uninstall /passive`

Additional notes on produced results:
- each installation seems to generate differently named log files in the `C:\Windows\Temp` folder, i.e. the `systemprofile` user account's `%TEMP%` folder
- the log file names indicate whether each specific component is being installed for the current-user or all-user variants, and those seem to be chosen at random in our problematic scenario
- it seems like the components whose log files are marked as being installed for the current user are not getting installed at all, or may possibly be getting installed to some other undisclosed location

The same does not occur if any of the following is true:
- if the installation is run from an regular end-user account
- if there is no Python currently installed on the system

A workaround we found in our case (Python gets installed as a step in one of our installers) is to basically do (uninstall, install) in a loop with some hand-crafted checking to see if the existing installation is ok (includes running some Python code + checking for some specific Python distribution files we've found to be missing in some scenarios).

----------
components: Installation
messages: 377039
nosy: Jurko.Gospodneti?
priority: normal
severity: normal
status: open
title: Python installation fails when run under system account if there is already an existing installation on the system already
versions: Python 3.5

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

From report at bugs.python.org  Thu Sep 17 06:48:28 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Sep 2020 10:48:28 +0000
Subject: [New-bugs-announce] [issue41801] 23 tests failed for 3.9.0b2-64
 installed on Windows 10
Message-ID: <1600339708.31.0.111996920302.issue41801@roundup.psfhosted.org>


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

Win10, master repository 32-debug build: test_locale and test__locale fail as they have for a year.  test_compileall test_asyncio failed as they have before, but not a few weels ago.

*** PermissionError: [WinError 5] Access is denied: 'f:\\dev\\3x\\\\lib\\__pycache__\\quopri.cpython-310.pyc.39387352' -> 'f:\\dev\\3x\\\\lib\\__pycache__\\quopri.cpython-310.pyc'

test test_asyncio failed -- Traceback (most recent call last):
  File "f:\dev\3x\lib\test\test_asyncio\test_sendfile.py", line 464, in test_sendfile_close_peer_in_the_middle_of_receiving
    self.assertTrue(1024 <= self.file.tell() < len(self.DATA),
AssertionError: False is not true : 131088
 

Installed 64-bit  3.9.0b2 has 19 more (same after 'repair'):

12 failed with 
ModuleNotFoundError: No module named '_testinternalcapi'

test_buffer test_capi test_deque test_fstring test_grammar
test_keyword test_memoryio test_parser test_string_literals
test_struct test_syntax test_traceback

7 failed otherwise, usually with multiple errors

test_array test_exceptions test_flufl test_itertools 
test_ordered_dict test_pickle test_sys test_xml_etree_c

----------
components: Installation, Windows
messages: 377052
nosy: lukasz.langa, paul.moore, steve.dower, terry.reedy, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: 23 tests failed for 3.9.0b2-64 installed on Windows 10
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Thu Sep 17 07:05:53 2020
From: report at bugs.python.org (Campbell Barton)
Date: Thu, 17 Sep 2020 11:05:53 +0000
Subject: [New-bugs-announce] [issue41802] Missing documentation for
 'PyDict_DelItem' behavior
Message-ID: <1600340753.64.0.782309837767.issue41802@roundup.psfhosted.org>


New submission from Campbell Barton <ideasman42 at gmail.com>:

When calling 'PyDict_DelItem' on a key that isn't in the hash a KeyError is raised. This is not documented.

----------
components: C API
messages: 377053
nosy: ideasman42
priority: normal
severity: normal
status: open
title: Missing documentation for 'PyDict_DelItem' behavior
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Sep 17 07:50:11 2020
From: report at bugs.python.org (Skyreka Agence Web)
Date: Thu, 17 Sep 2020 11:50:11 +0000
Subject: [New-bugs-announce] [issue41803] Robots.txt
Message-ID: <1600343411.93.0.266726612445.issue41803@roundup.psfhosted.org>


New submission from Skyreka Agence Web <admin at skyreka.com>:

I can't  documentation about it, but all of the robots.txt checkers I find behave like this. You can test on this site: http://www.skyreka.com/robots.txt, I believe that this is how it's implemented now in most parsers ?

----------
messages: 377055
nosy: admin2
priority: normal
severity: normal
status: open
title: Robots.txt

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

From report at bugs.python.org  Thu Sep 17 12:42:20 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Sep 2020 16:42:20 +0000
Subject: [New-bugs-announce] [issue41804] test_epoll fails
 test_control_and_wait() randomly on aarch64 RHEL8 Refleaks 3.9
Message-ID: <1600360940.95.0.528440416873.issue41804@roundup.psfhosted.org>


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

test_epoll.test_control_and_wait() failed once on aarch64 RHEL8 Refleaks 3.9:
https://buildbot.python.org/all/#/builders/247/builds/32

This buildbot runs test_epoll 6 times in a row and the system load was quite high (10.39).

0:03:01 load avg: 10.39 [ 97/425/1] test_epoll failed -- running: test_multiprocessing_fork (3 min), test_gdb (46.3 sec), test_peg_generator (1 min 25 sec), test_capi (2 min 26 sec), test_weakref (2 min 1 sec), test_statistics (1 min 6 sec), test_multiprocessing_spawn (2 min 44 sec), test_io (1 min 53 sec)
beginning 6 repetitions
123456
...test test_epoll failed -- Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.9.cstratak-RHEL8-aarch64.refleak/build/Lib/test/test_epoll.py", line 199, in test_control_and_wait
    self.assertEqual(events, expected)
AssertionError: Lists differ: [(5, 5)] != [(4, 5), (5, 5)]

First differing element 0:
(5, 5)
(4, 5)

Second list contains 1 additional elements.
First extra element 1:
(5, 5)

- [(5, 5)]
+ [(4, 5), (5, 5)]

----------
components: Tests
messages: 377059
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_epoll fails test_control_and_wait() randomly on aarch64 RHEL8 Refleaks 3.9
versions: Python 3.9

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

From report at bugs.python.org  Thu Sep 17 15:28:28 2020
From: report at bugs.python.org (Patrick Reader)
Date: Thu, 17 Sep 2020 19:28:28 +0000
Subject: [New-bugs-announce] [issue41805] types.GenericAlias and types.Union
 have no documentation
Message-ID: <1600370908.0.0.224627521485.issue41805@roundup.psfhosted.org>


New submission from Patrick Reader <pxeger at protonmail.com>:

See title.

For reference:

`GenericAlias` was added by Guido van Rossum <guido at python.org> in commit 48b069a003ba6c684a9ba78493fbbec5e89f10b8 "bpo-39481: Implementation for [PEP 585](https://www.python.org/dev/peps/pep-0585/) (#18239)"

`Union` was added by Maggi Moss <MaggieMoss at users.noreply.github.com> in commit 1b4552c5e8e925f24c15f707050f22c977171125 "bpo-41428: Implementation for [PEP 604](https://www.python.org/dev/peps/pep-0604/) (GH-21515)"

I can do a PR which would need backporting (is that the right word?) to 3.9 at least for `GenericAlias`.

----------
assignee: docs at python
components: Documentation
messages: 377064
nosy: docs at python, pxeger
priority: normal
severity: normal
status: open
title: types.GenericAlias and types.Union have no documentation
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Thu Sep 17 16:25:37 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 17 Sep 2020 20:25:37 +0000
Subject: [New-bugs-announce] [issue41806] socket methods with timeout take
 very slow path on Windows
Message-ID: <1600374337.91.0.20537040247.issue41806@roundup.psfhosted.org>


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

When a socket object has a non-zero timeout, all send/recv/etc. calls are preceded by a select() call before making the actual call. If there is no timeout, the select call is skipped.

It appears that on Windows, select() will block until the previous operation has completed, even if the next one would reliably succeed. For example, http.client uses a default blocksize of 8192 bytes (which is _really_ small for 2020, but probably not for 2002 when it was set - can we just increase it?), which will break up a stream into many little chunks.

With no timeout set: send() is called repeatedly and Windows buffers blocks internally, resulting in the actual sends being bigger (as seen with a network trace - they'd range from 8KB-50KB).

With a timeout set: select() is called and waits for the previous send() to complete, then calls the next send(). This results in every single send being exactly 8KB.

This latter case also results in every operation becoming essentially synchronous, instead of picking up some implied parallelism in the OS and network driver. (Yes, increasing the block size in the above example also helps, but doesn't prevent the issue in the first place, nor does it help with other cases.)

Has anyone ever looked into alternate ways to have the timeout work here? Such as SO_SNDTIMEO? I don't want to force through a full redesign here, but getting the select() call out of the main path here seems like an easy win.

Would anyone like to take a look? I'm happy to help mentor someone through a patch (as long as you're familiar with networking/sockets already).

----------
components: Library (Lib), Windows
messages: 377065
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: socket methods with timeout take very slow path on Windows
type: performance
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Sep 17 20:40:16 2020
From: report at bugs.python.org (zamunda)
Date: Fri, 18 Sep 2020 00:40:16 +0000
Subject: [New-bugs-announce] [issue41807] Warnings when installing Linter on
 VS code on Linux and Windows.
Message-ID: <1600389616.58.0.106724247852.issue41807@roundup.psfhosted.org>


New submission from zamunda <kissmeon at abv.bg>:

nstalled VS code, installed Python extension and when it loaded a pop up showed "Linter is not available" or something like that. Press Install, choose linter or never show again options.
Pressed Install - and it loaded the code to install it. It installed some stuff but there are errors about Path or something. See in the screenshot.
I've never had such Warnings before.

When I installed Python (on my system Windows) I put a checkmark on Add to Path, so it's not the problem.

Then I moved to Linux hoping it will work better and without warnings. Same Warining there too.

I guess there is a problem with python3-pip or something.

----------
components: Installation
files: 93283029-5dfbc880-f7d8-11ea-8552-fa5ee1e1d924.png
messages: 377078
nosy: zamunda
priority: normal
severity: normal
status: open
title: Warnings when installing Linter on VS code on Linux and Windows.
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file49462/93283029-5dfbc880-f7d8-11ea-8552-fa5ee1e1d924.png

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

From report at bugs.python.org  Thu Sep 17 21:02:29 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Sep 2020 01:02:29 +0000
Subject: [New-bugs-announce] [issue41808] Synchronize What's New in 3.9
 master and 3.9 copies
Message-ID: <1600390949.09.0.806445771766.issue41808@roundup.psfhosted.org>


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

The 3.9 copy is 5 lines longer, meaning that after the b1 split, something was added to 3.9 directly instead of to master first and backported, or added to both and deleted from master.

Lukasz, is checking the two copies part of the final release process?

The 5 lines not in master are from PR-21012 and PR-21039 of issue 40939, by Lysandros and Pablo.  Please one of you verify that they should be added to master, as in the PR I will add, and not deleted from 3.9.
___
* The Public C API functions :c:func:`PyParser_SimpleParseStringFlags`,
  :c:func:`PyParser_SimpleParseStringFlagsFilename`,
  :c:func:`PyParser_SimpleParseFileFlags` and :c:func:`PyNode_Compile`
  are deprecated and will be removed in Python 3.10 together with the old parser.
___

----------
assignee: docs at python
components: Documentation
messages: 377081
nosy: docs at python, lukasz.langa, lys.nikolaou, pablogsal, terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: Synchronize What's New in 3.9 master and 3.9 copies
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Fri Sep 18 10:24:23 2020
From: report at bugs.python.org (musiquegraeme)
Date: Fri, 18 Sep 2020 14:24:23 +0000
Subject: [New-bugs-announce] [issue41809] finding file attributes in Windows
 seems to fail
Message-ID: <1600439063.01.0.806947932317.issue41809@roundup.psfhosted.org>


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

When I try this in shell 
     os.stat('MyFile2.iso').st_file_attributes
I get a value - 32

When I try this in IDLE 
     print (os.stat('MyFile2.iso').st_file_attributes)

I get the error message.

AttributeError: 'os.stat_result' object has no attribute 'st_file_atributes'

----------
assignee: terry.reedy
components: IDLE
messages: 377119
nosy: musiquegraeme, terry.reedy
priority: normal
severity: normal
status: open
title: finding file attributes in Windows seems to fail
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Fri Sep 18 15:29:00 2020
From: report at bugs.python.org (Bas van Beek)
Date: Fri, 18 Sep 2020 19:29:00 +0000
Subject: [New-bugs-announce] [issue41810] Consider reintroducing
 `types.EllipsisType` for the sake of typing
Message-ID: <1600457340.51.0.170346163147.issue41810@roundup.psfhosted.org>


New submission from Bas van Beek <bas.vanbeek at hotmail.com>:

`Ellipsis` is one of the few builtin objects whose type is not exposed via the `types` module. 
This is not really an issue during runtime, as you can always call `type(Ellipsis)`, but for the purpose of typing it is detrimental; the lack of suitable type means that it is impossible to properly annotate a function which takes or returns `Ellipsis` (unless one is willing to resort to the use of non-public types: https://github.com/python/typeshed/issues/3556).

In order to resolve this issue I propose to reintroduce `types.EllipsisType`. This should be a fairly simple process, so if there are no objections I'd be willing to give it a shot.

----------
components: Library (Lib)
messages: 377135
nosy: BvB93
priority: normal
severity: normal
status: open
title: Consider reintroducing `types.EllipsisType` for the sake of typing
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Sat Sep 19 04:49:31 2020
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 19 Sep 2020 08:49:31 +0000
Subject: [New-bugs-announce] [issue41811] pstats.SortKey enum is broken
Message-ID: <1600505371.4.0.907102076211.issue41811@roundup.psfhosted.org>


New submission from Ethan Furman <ethan at stoneleaf.us>:

Currently, __new__ creates each member as an empty string, then adds the _value_ attribute.  Because of this, each member is equal to each other, and all appear the same to any data structure that relies on equality and hash as distinguishers (so, basically, all of them).

The fix is to use the first value as the string to be created.

----------
assignee: ethan.furman
components: Library (Lib)
messages: 377153
nosy: ethan.furman
priority: normal
severity: normal
status: open
title: pstats.SortKey enum is broken
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Sep 19 06:39:21 2020
From: report at bugs.python.org (Tomohiko Kinebuchi)
Date: Sat, 19 Sep 2020 10:39:21 +0000
Subject: [New-bugs-announce] [issue41812] Broken link on documentation header
Message-ID: <1600511961.8.0.4482824701.issue41812@roundup.psfhosted.org>


New submission from Tomohiko Kinebuchi <cocoatomo77 at gmail.com>:

the link "Documentation" on the head of the top page leads 404 pages.

----------
assignee: docs at python
components: Documentation
files: Screen Shot 2020-09-11 at 22.10.37.png
messages: 377156
nosy: cocoatomo, docs at python
priority: normal
severity: normal
status: open
title: Broken link on documentation header
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49463/Screen Shot 2020-09-11 at 22.10.37.png

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

From report at bugs.python.org  Sat Sep 19 09:57:34 2020
From: report at bugs.python.org (Paolo Lammens)
Date: Sat, 19 Sep 2020 13:57:34 +0000
Subject: [New-bugs-announce] [issue41813] Clarify specification of
 object.__await__
Message-ID: <1600523854.86.0.266063347768.issue41813@roundup.psfhosted.org>


New submission from Paolo Lammens <lammenspaolo at gmail.com>:

The current specification of object.__await__ is just:

> `object.__await__(self)`
>
> Must return an iterator. Should be used to implement awaitable objects. For instance, `asyncio.Future` implements this method to be compatible with the await expression.

This is pretty vague leaves the doubt of *what* objects is the iterator expected to yield (and how the value of the yielded object affects the management of the awaitable object).

Although the vagueness is probably on purpose (since this isn't tied to any particular event loop implementation, so it can be an arbitrary iterable), I think it's worthwhile adding a note clarifying this aspect.

I originally posed this question on StackOverflow: https://stackoverflow.com/q/63964011/6117426

----------
assignee: docs at python
components: Documentation
messages: 377166
nosy: docs at python, plammens
priority: normal
severity: normal
status: open
title: Clarify specification of object.__await__

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

From report at bugs.python.org  Sat Sep 19 11:43:58 2020
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sat, 19 Sep 2020 15:43:58 +0000
Subject: [New-bugs-announce] [issue41814] Mismatch between the manipulation
 of `sys.path` by `runpy` and by the Python command-line interface
Message-ID: <1600530238.56.0.932749272178.issue41814@roundup.psfhosted.org>


New submission from G?ry <gery.ogam at gmail.com>:

Nicholas, I have noticed that `runpy.run_path` alters `sys.path` as expected for a file_path argument which is a valid `sys.path` entry (typically a directory or zip file). That is to say it adds the file_path argument to the beginning of `sys.path`, like `python <valid sys.path entry>`.

However, I have also noticed that `runpy.run_path` does not alter `sys.path` as expected for a file_path argument which is a Python source or bytecode file path. That is to say it does not add the *parent path* of the file_path argument to the beginning of `sys.path`, contrary to `python <source or bytecode file path>`.

Likewise, I have also noticed that `runpy.run_module` (with the alter_sys argument set to `True` of course) does not alter `sys.path` as expected. That is to say it does not add the path of the *current directory* to the beginning of `sys.path`, contrary to `python -m <module>`.

Only the first of the three previous `sys.path` manipulations is documented in https://docs.python.org/3/library/runpy.html though, so the `runpy` implementation is at least compliant with its specification. So is the mismatch between the manipulation of `sys.path` by `runpy` and by the Python command-line interface a specification bug or is it the intended behaviour?

----------
components: Library (Lib)
messages: 377171
nosy: maggyero, ncoghlan
priority: normal
severity: normal
status: open
title: Mismatch between the manipulation of `sys.path` by `runpy` and by the Python command-line interface
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sat Sep 19 12:08:19 2020
From: report at bugs.python.org (Peter McCormick)
Date: Sat, 19 Sep 2020 16:08:19 +0000
Subject: [New-bugs-announce] [issue41815] SQLite: segfault if backup called
 on closed database
Message-ID: <1600531699.45.0.309106066833.issue41815@roundup.psfhosted.org>


New submission from Peter McCormick <peter at pdmccormick.com>:

Attempting to backup a closed database will trigger segfault:

```
target = sqlite.connect(':memory:')
source = sqlite.connect(":memory:")
source.close()
source.backup(target)
```

----------
files: fix.patch
keywords: patch
messages: 377176
nosy: pdmccormick
priority: normal
severity: normal
status: open
title: SQLite: segfault if backup called on closed database
type: crash
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49464/fix.patch

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

From report at bugs.python.org  Sat Sep 19 15:20:58 2020
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 19 Sep 2020 19:20:58 +0000
Subject: [New-bugs-announce] [issue41816] need StrEnum in enum.py
Message-ID: <1600543258.21.0.858019496053.issue41816@roundup.psfhosted.org>


New submission from Ethan Furman <ethan at stoneleaf.us>:

Due to the nature of `str`, if an Enum tries to mixin the str type, all of it's members will be strings -- even if they didn't start out that way:

  class MyStrEnum(str, Enum):
     tuple = 'oops',
     okay = 'correct'

  >>> list(MyStrEnum)
  [<MyStrEnum.tuple: "('oops',)">, MyStrEnum.okay: 'correct'>]

The StrEnum class will have a check to ensure that each value was already a string, or can be converted to a string via

  str(bytes, encoding, errors)

----------
assignee: ethan.furman
components: Library (Lib)
messages: 377186
nosy: barry, eli.bendersky, ethan.furman, serhiy.storchaka, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: need StrEnum in enum.py
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Sat Sep 19 15:36:58 2020
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 19 Sep 2020 19:36:58 +0000
Subject: [New-bugs-announce] [issue41817] Incorrect types in
 tkinter.EventType Enum
Message-ID: <1600544218.82.0.650310547242.issue41817@roundup.psfhosted.org>


New submission from Ethan Furman <ethan at stoneleaf.us>:

Several of the EventType members, such as Key, are actually tuples instead of strings.  I suspect the comma was accidentally left in place when EventType was created from a different data structure.

Switching the Enum type to the new StrEnum fixes the problem.  (It will be merged in in the next couple days.)

----------
components: Library (Lib)
messages: 377188
nosy: ethan.furman, gpolo, serhiy.storchaka, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Incorrect types in tkinter.EventType Enum
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Sep 19 19:19:34 2020
From: report at bugs.python.org (Soumendra Ganguly)
Date: Sat, 19 Sep 2020 23:19:34 +0000
Subject: [New-bugs-announce] [issue41818] Lib/pty.py major revision
Message-ID: <1600557574.22.0.272934906824.issue41818@roundup.psfhosted.org>


New submission from Soumendra Ganguly <soumendra at tamu.edu>:

The current pty library has the following issues:

  1. Does not set slave termios. Documented in the source.

  2. Does not set initial slave window size. Documented in the source. Does not handle SIGWINCH. See bpo-41494, bpo-41541. This is essential in the following practical scenarios: i. creating split windows/panes while using a terminal multiplexer; ii. when resizing GUI terminal emulator window, especially relevant when using tiling window managers; iii. resizing an ansi-term window created inside a GNU Emacs frame.

  3. Does not perform signal handling. Signals must be blocked during sensitive portions of code.

  4. Hangs on FreeBSD. See bpo-26228.

  5. Includes deprecated functions pty.master_open(), pty.slave_open().

  6. In pty.fork(), the fallback code should try using TIOCSCTTY first. It is still using the old method of opening a tty to make it the controlling tty. Currently even SysV based systems provide TIOCSCTTY. See https://stackoverflow.com/questions/51593530/code-explanation-for-glibc-login-tty-function-openttyname-immediately-f

The current version of pty.spawn() uses pty.fork() internally. However, pty.fork() closes slave and only returns (pid, master_fd). To update winsize, access to slave is necessary. Further, slave termios must be properly set. The proposed modifications do this by implementing a login_tty(3) based function ( tty.login() ), and using that in pty.spawn() instead of pty.fork(). tty.login() tries TIOCSCTTY before falling back to the old SysV method because Python currently does not provide an interface to the native login_tty(3).

  7. tty.setraw() is called right after tty.tcgetattr(). This increases redundancy of code because tty.setraw() itself makes an identical tty.tcgetattr() call.

  8. Requires testing/porting to more platforms. Solaris, Illumos, macOS, Cygwin, etc. Windows ConPTY?

  9. There should be an option in pty.spawn() to turn off slave's ECHO flag. For example, when it is being used in a pipe. See https://github.com/karelzak/util-linux/commit/1eee1acb245a8b724e441778dfa9b858465bf7e5 and https://github.com/karelzak/util-linux/commit/75ccd75a2fa1194c6415c47b0024a438e26f1ad7#diff-3834a3d25eeaf20d9d0dcb05a46995f6

  10. Tests are incomplete. Tests consider OSes such as Tru64 but not {Free/Net/Open/...}BSD.

Find ongoing work here: https://github.com/8vasu/pypty2

----------
components: FreeBSD, Library (Lib), Tests, Windows, macOS
messages: 377195
nosy: koobs, ned.deily, paul.moore, ronaldoussoren, soumendra, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Lib/pty.py major revision
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Sep 20 02:10:02 2020
From: report at bugs.python.org (Samuel Marks)
Date: Sun, 20 Sep 2020 06:10:02 +0000
Subject: [New-bugs-announce] [issue41819] Fix some compiler warnings
Message-ID: <1600582202.7.0.502087072911.issue41819@roundup.psfhosted.org>


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

https://github.com/SamuelMarks/cpython/tree/3.9-compiler-fixes

----------
components: Build
messages: 377205
nosy: samuelmarks
priority: normal
pull_requests: 21373
severity: normal
status: open
title: Fix some compiler warnings
type: compile error
versions: Python 3.9

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

From report at bugs.python.org  Sun Sep 20 02:46:37 2020
From: report at bugs.python.org (Anudeep Balla)
Date: Sun, 20 Sep 2020 06:46:37 +0000
Subject: [New-bugs-announce] [issue41820] ipaddress Library gives me
 incorrect results
Message-ID: <1600584397.02.0.984052429754.issue41820@roundup.psfhosted.org>


New submission from Anudeep Balla <anudeepballa07 at gmail.com>:

https://docs.python.org/3.8/library/ipaddress.html

import ipaddress


ADDRESSES = [
    '172.16.254.00'
]

for ip in ADDRESSES:
    addr = ipaddress.ip_address(ip)
    if addr.version==4:
        {
            print("true")
        }
    else:
        {
            print("false")
        }
Screen Shot 2020-09-20 at 1 33 30 AM

I tried to validate an invalid IPv4 address using IPaddress library from py 3.8.6 but somehow it considers any address ending with "00" to be valid.

I hope this is helpful to the community please let me know if the issue is with validation from your end or a bug in the library.

@AnudeepBalla

----------
components: Library (Lib)
messages: 377208
nosy: anudeepballa07
priority: normal
severity: normal
status: open
title: ipaddress Library gives me incorrect results
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sun Sep 20 06:10:35 2020
From: report at bugs.python.org (john_miller)
Date: Sun, 20 Sep 2020 10:10:35 +0000
Subject: [New-bugs-announce] [issue41821] Printing specific Unicode
 characters causes unwanted beeping in Windows 7 console
Message-ID: <1600596635.97.0.661976850635.issue41821@roundup.psfhosted.org>


New submission from john_miller <johnson.b.ourne+pythonbugtracker at gmail.com>:

I noticed some beeping when printing data to the console (cmd), so I narrowed down the problem to three specific Unicode-characters somehow producing beeps when printed to the Windows console (CMD). This also works in interactive mode. (I checked every single Unicode-character up to sys.maxunicode (except character-values between 0xD800 and 0xE000) by bisecting ever-more fine-grained until I narrowed it down to only those three characters producing unwanted beeps.)

Isolated example of bug: for i in ['\u2022', '\u2024', '\u2219']: print(i)

\u0007 beeps too, but this works as intended.

Python version: 3.8.5 (tags/v3.8.5:580fbb0, Jul 20 2020, 15:43:08) [MSC v.1926 32 bit (Intel)]
Windows version: Microsoft Windows 7 Professional (6.1.7601 Service Pack 1 Build 7601)
CMD active code page: 850 (According to chcp-command.) 
sys.stdout.encoding: utf-8

Might be loosly related to PEP-528 (https://www.python.org/dev/peps/pep-0528/)

Addendum:
Piping the output like: 'python.exe script.py >> testfile.txt' produced an error.
This might happen with more Unicode characters but I haven't checked.

Addendum-Example:
Traceback (most recent call last):
  File "pytest2.py", line 38, in <module>
    print(hex(i), ":", chr(i), end='\n')
  File "C:\Python38-32\lib\encodings\cp1252.py", line 19, in encode
    return codecs.charmap_encode(input,self.errors,encoding_table)[0]
UnicodeEncodeError: 'charmap' codec can't encode character '\u2023' in position 0: character maps to <undefined>

----------
components: Unicode, Windows
messages: 377214
nosy: ezio.melotti, john_miller, paul.moore, steve.dower, tim.golden, vstinner, zach.ware
priority: normal
severity: normal
status: open
title: Printing specific Unicode characters causes unwanted beeping in Windows 7 console
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sun Sep 20 20:38:26 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 21 Sep 2020 00:38:26 +0000
Subject: [New-bugs-announce] [issue41822] Document the mean of values for
 sys.float_info.rounds
Message-ID: <1600648706.73.0.507862170012.issue41822@roundup.psfhosted.org>


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

The current docs unnecessarily refer readers to the C99 standard. "integer constant representing the rounding mode used for arithmetic operations. This reflects the value of the system FLT_ROUNDS macro at interpreter startup time. See section 5.2.4.2.2 of the C99 standard for an explanation of the possible values and their meanings."

The docs should quote the standard, "The rounding mode for floating-point addition is characterized by the implementation defined value of FLT_ROUNDS: -1 indeterminable, 0 toward zero, 1 to nearest, 2 toward positive infinity, 3 toward negative infinity.  All other values for FLT_ROUNDS characterize implementation-defined rounding."
behavior.

----------
assignee: docs at python
components: Documentation
keywords: newcomer friendly
messages: 377236
nosy: docs at python, rhettinger
priority: normal
severity: normal
status: open
title: Document the mean of values for sys.float_info.rounds

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

From report at bugs.python.org  Sun Sep 20 21:01:54 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 21 Sep 2020 01:01:54 +0000
Subject: [New-bugs-announce] [issue41823] Add more fields to sys.float_info
Message-ID: <1600650114.4.0.96172232586.issue41823@roundup.psfhosted.org>


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

Consider adding new non-sequence fields to sys.float_info: doubling_rounding and ieee_754.

The code in test_math defines a useful constant:

   # detect evidence of double-rounding: fsum is not always correctly
   # rounded on machines that suffer from double rounding.
   x, y = 1e16, 2.9999 # use temporary values to defeat peephole optimizer
   HAVE_DOUBLE_ROUNDING = (x + y == 1e16 + 4)

There is another useful value in a float.__getformat__ which is hard to find and only documented for internal use:

   >>> float.__getformat__('double')
   'IEEE, little-endian

Making this information available would make it easier for users to do what we do in test_math:

    @requires_IEEE_754
    @unittest.skipIf(HAVE_DOUBLE_ROUNDING,
       "fsum is not exact on machines with double rounding")
    def testFsum(self):
        ...

----------
components: Extension Modules
messages: 377237
nosy: mark.dickinson, rhettinger, tim.peters
priority: normal
severity: normal
status: open
title: Add more fields to sys.float_info
versions: Python 3.10

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

From report at bugs.python.org  Mon Sep 21 12:35:27 2020
From: report at bugs.python.org (Dominic Davis-Foster)
Date: Mon, 21 Sep 2020 16:35:27 +0000
Subject: [New-bugs-announce] [issue41824] Docs for typing.ForwardRef don't
 state that is was added in 3.7
Message-ID: <1600706127.1.0.52497874592.issue41824@roundup.psfhosted.org>


New submission from Dominic Davis-Foster <dom1310df at googlemail.com>:

typing.ForwardRef was first documented in GH-14216 but there's no mention that the class was only added in Python 3.7.

In Python 3.6 there's no typing.ForwardRef; there is a typing._ForwardRef which seems to be the same thing from before it was made public.


What I don't know is whether the change of name was made in 3.7 or in a point release.

----------
components: Library (Lib)
messages: 377262
nosy: dom1310df
priority: normal
severity: normal
status: open
title: Docs for typing.ForwardRef don't state that is was added in 3.7
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Mon Sep 21 12:41:50 2020
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 21 Sep 2020 16:41:50 +0000
Subject: [New-bugs-announce] [issue41825] os.waitid() documentation needs TLC
Message-ID: <1600706510.78.0.601178112511.issue41825@roundup.psfhosted.org>


New submission from Georg Brandl <georg at python.org>:

There are a few points where `os.waitid()` docs need improvement. Current text:

Wait for the completion of one or more child processes. idtype can be P_PID, P_PGID or P_ALL. id specifies the pid to wait on. options is constructed from the ORing of one or more of WEXITED, WSTOPPED or WCONTINUED and additionally may be ORed with WNOHANG or WNOWAIT. The return value is an object representing the data contained in the siginfo_t structure, namely: si_pid, si_uid, si_signo, si_status, si_code or None if WNOHANG is specified and there are no children in a waitable state.

Problems are:

* The given use of the *pid* argument is only for the case of `idtype=P_PID`.  For `P_ALL` it is ignored, and for `P_PGID` it specifies that the child's PGID must be *pid*.

* "One or more child processes" is misleading -- the function waits for until exactly one child process to exit (or aborts with WNOHANG).  Sure, there can be multiple candidate processes, but this should be formulated differently.

* The explanation of *options* is quite cumbersome, it seems to be copied directly from the manpage (where it is laid out much more clearly and with explanation of the different options).

Additionally the flags P_*, W* and CLD_* are just stated as-is, and need explanation in the docs. You should not need to consult the manpage to be able to use the function at all.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 377263
nosy: docs at python, georg.brandl
priority: normal
severity: normal
stage: needs patch
status: open
title: os.waitid() documentation needs TLC
type: enhancement
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Sep 21 13:56:12 2020
From: report at bugs.python.org (Skip Montanaro)
Date: Mon, 21 Sep 2020 17:56:12 +0000
Subject: [New-bugs-announce] [issue41826] test_peg_generator compilation
 warnings
Message-ID: <1600710972.69.0.778161141813.issue41826@roundup.psfhosted.org>


New submission from Skip Montanaro <skip.montanaro at gmail.com>:

I don't see anything like this while building Python proper, but when test_peg_generator is run, it spews a few compiler warnings. Platform is Ubuntu 20.04. Seems low-ish priority, but I saw no mention of it in a quick bpo search, so thought I would toss it out there.

-------------------------------------------------
% ./python ./Tools/scripts/run_tests.py test_peg_generator
/home/skip/src/python/cpython/python -u -W default -bb -E -m test -r -w -j 0 -u all,-largefile,-audio,-gui test_peg_generator
Using random seed 1793668
0:00:00 load avg: 0.09 Run tests in parallel using 10 child processes
0:00:30 load avg: 0.45 running: test_peg_generator (30.0 sec)
0:00:54 load avg: 0.64 [1/1] test_peg_generator passed (54.8 sec)
In file included from /home/skip/src/python/cpython/Parser/pegen.h:7,
                 from /tmp/tmp3fq3wryo/parse.c:2:
/tmp/tmp3fq3wryo/parse.c: In function ?start_rule?:
/tmp/tmp3fq3wryo/parse.c:59:29: warning: passing argument 1 of ?_Py_Module? from incompatible pointer type [-Wincompatible-pointer-types]
   59 |             _res = Module ( a , NULL , p -> arena );
      |                             ^
      |                             |
      |                             asdl_seq * {aka struct <anonymous> *}
/home/skip/src/python/cpython/Include/Python-ast.h:541:39: note: in definition of macro ?Module?
  541 | #define Module(a0, a1, a2) _Py_Module(a0, a1, a2)
      |                                       ^~
/home/skip/src/python/cpython/Include/Python-ast.h:542:35: note: expected ?asdl_stmt_seq *? {aka ?struct <anonymous> *?} but argument is of type ?asdl_seq *? {aka ?struct <anonymous> *?}
  542 | mod_ty _Py_Module(asdl_stmt_seq * body, asdl_type_ignore_seq * type_ignores,
      |                   ~~~~~~~~~~~~~~~~^~~~
In file included from /home/skip/src/python/cpython/Parser/pegen.h:7,
                 from /tmp/tmpybnujtsb/parse.c:2:
/tmp/tmpybnujtsb/parse.c: In function ?start_rule?:
/tmp/tmpybnujtsb/parse.c:61:29: warning: passing argument 1 of ?_Py_Module? from incompatible pointer type [-Wincompatible-pointer-types]
   61 |             _res = Module ( a , NULL , p -> arena );
      |                             ^
      |                             |
      |                             asdl_seq * {aka struct <anonymous> *}
/home/skip/src/python/cpython/Include/Python-ast.h:541:39: note: in definition of macro ?Module?
  541 | #define Module(a0, a1, a2) _Py_Module(a0, a1, a2)
      |                                       ^~
/home/skip/src/python/cpython/Include/Python-ast.h:542:35: note: expected ?asdl_stmt_seq *? {aka ?struct <anonymous> *?} but argument is of type ?asdl_seq *? {aka ?struct <anonymous> *?}
  542 | mod_ty _Py_Module(asdl_stmt_seq * body, asdl_type_ignore_seq * type_ignores,
      |                   ~~~~~~~~~~~~~~~~^~~~
In file included from /home/skip/src/python/cpython/Parser/pegen.h:7,
                 from /tmp/tmpgbehpd3_/parse.c:2:
/tmp/tmpgbehpd3_/parse.c: In function ?start_rule?:
/tmp/tmpgbehpd3_/parse.c:77:29: warning: passing argument 1 of ?_Py_Module? from incompatible pointer type [-Wincompatible-pointer-types]
   77 |             _res = Module ( a , NULL , p -> arena );
      |                             ^
      |                             |
      |                             asdl_seq * {aka struct <anonymous> *}
/home/skip/src/python/cpython/Include/Python-ast.h:541:39: note: in definition of macro ?Module?
  541 | #define Module(a0, a1, a2) _Py_Module(a0, a1, a2)
      |                                       ^~
/home/skip/src/python/cpython/Include/Python-ast.h:542:35: note: expected ?asdl_stmt_seq *? {aka ?struct <anonymous> *?} but argument is of type ?asdl_seq *? {aka ?struct <anonymous> *?}
  542 | mod_ty _Py_Module(asdl_stmt_seq * body, asdl_type_ignore_seq * type_ignores,
      |                   ~~~~~~~~~~~~~~~~^~~~
/tmp/tmpgbehpd3_/parse.c: In function ?import_from_rule?:
/tmp/tmpgbehpd3_/parse.c:148:58: warning: passing argument 2 of ?_Py_ImportFrom? from incompatible pointer type [-Wincompatible-pointer-types]
  148 |             _res = _Py_ImportFrom ( c -> v . Name . id , d , 0 , EXTRA );
      |                                                          ^
      |                                                          |
      |                                                          asdl_seq * {aka struct <anonymous> *}
In file included from /home/skip/src/python/cpython/Parser/pegen.h:7,
                 from /tmp/tmpgbehpd3_/parse.c:2:
/home/skip/src/python/cpython/Include/Python-ast.h:625:60: note: expected ?asdl_alias_seq *? {aka ?struct <anonymous> *?} but argument is of type ?asdl_seq *? {aka ?struct <anonymous> *?}
  625 | stmt_ty _Py_ImportFrom(identifier module, asdl_alias_seq * names, int level,
      |                                           ~~~~~~~~~~~~~~~~~^~~~~
/tmp/tmpgbehpd3_/parse.c:190:44: warning: passing argument 2 of ?_Py_ImportFrom? from incompatible pointer type [-Wincompatible-pointer-types]
  190 |             _res = _Py_ImportFrom ( NULL , c , 1 , EXTRA );
      |                                            ^
      |                                            |
      |                                            asdl_seq * {aka struct <anonymous> *}
In file included from /home/skip/src/python/cpython/Parser/pegen.h:7,
                 from /tmp/tmpgbehpd3_/parse.c:2:
/home/skip/src/python/cpython/Include/Python-ast.h:625:60: note: expected ?asdl_alias_seq *? {aka ?struct <anonymous> *?} but argument is of type ?asdl_seq *? {aka ?struct <anonymous> *?}
  625 | stmt_ty _Py_ImportFrom(identifier module, asdl_alias_seq * names, int level,
      |                                           ~~~~~~~~~~~~~~~~~^~~~~
In file included from /home/skip/src/python/cpython/Parser/pegen.h:7,
                 from /tmp/tmplmi91q5h/parse.c:2:
/tmp/tmplmi91q5h/parse.c: In function ?start_rule?:
/tmp/tmplmi91q5h/parse.c:69:29: warning: passing argument 1 of ?_Py_Module? from incompatible pointer type [-Wincompatible-pointer-types]
   69 |             _res = Module ( a , NULL , p -> arena );
      |                             ^
      |                             |
      |                             asdl_seq * {aka struct <anonymous> *}
/home/skip/src/python/cpython/Include/Python-ast.h:541:39: note: in definition of macro ?Module?
  541 | #define Module(a0, a1, a2) _Py_Module(a0, a1, a2)
      |                                       ^~
/home/skip/src/python/cpython/Include/Python-ast.h:542:35: note: expected ?asdl_stmt_seq *? {aka ?struct <anonymous> *?} but argument is of type ?asdl_seq *? {aka ?struct <anonymous> *?}
  542 | mod_ty _Py_Module(asdl_stmt_seq * body, asdl_type_ignore_seq * type_ignores,
      |                   ~~~~~~~~~~~~~~~~^~~~
/tmp/tmplmi91q5h/parse.c: In function ?listcomp_rule?:
/tmp/tmplmi91q5h/parse.c:199:39: warning: passing argument 2 of ?_Py_ListComp? from incompatible pointer type [-Wincompatible-pointer-types]
  199 |             _res = _Py_ListComp ( b , c , EXTRA );
      |                                       ^
      |                                       |
      |                                       asdl_seq * {aka struct <anonymous> *}
In file included from /home/skip/src/python/cpython/Parser/pegen.h:7,
                 from /tmp/tmplmi91q5h/parse.c:2:
/home/skip/src/python/cpython/Include/Python-ast.h:676:60: note: expected ?asdl_comprehension_seq *? {aka ?struct <anonymous> *?} but argument is of type ?asdl_seq *? {aka ?struct <anonymous> *?}
  676 | expr_ty _Py_ListComp(expr_ty elt, asdl_comprehension_seq * generators, int
      |                                   ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
/tmp/tmplmi91q5h/parse.c: In function ?_tmp_2_rule?:
/tmp/tmplmi91q5h/parse.c:385:110: warning: passing argument 3 of ?_Py_comprehension? from incompatible pointer type [-Wincompatible-pointer-types]
  385 |             _res = _Py_comprehension ( _Py_Name ( ( ( expr_ty ) a ) -> v . Name . id , Store , EXTRA ) , b , c , ( y == NULL ) ? 0 : 1 , p -> arena );
      |                                                                                                              ^
      |                                                                                                              |
      |                                                                                                              asdl_seq * {aka struct <anonymous> *}
In file included from /home/skip/src/python/cpython/Parser/pegen.h:7,
                 from /tmp/tmplmi91q5h/parse.c:2:
/home/skip/src/python/cpython/Include/Python-ast.h:748:38: note: expected ?asdl_expr_seq *? {aka ?struct <anonymous> *?} but argument is of type ?asdl_seq *? {aka ?struct <anonymous> *?}
  747 | comprehension_ty _Py_comprehension(expr_ty target, expr_ty iter, asdl_expr_seq
      |                                                                  ~~~~~~~~~~~~~
  748 |                                    * ifs, int is_async, PyArena *arena);
      |                                    ~~^~~
/tmp/tmpmg0f1xoj/parse.c: In function ?with_stmt_rule?:
/tmp/tmpmg0f1xoj/parse.c:270:31: warning: passing argument 1 of ?_Py_With? from incompatible pointer type [-Wincompatible-pointer-types]
  270 |             _res = _Py_With ( b , _PyPegen_singleton_seq ( p , c ) , NULL , EXTRA );
      |                               ^
      |                               |
      |                               asdl_seq * {aka struct <anonymous> *}
In file included from /home/skip/src/python/cpython/Parser/pegen.h:7,
                 from /tmp/tmpmg0f1xoj/parse.c:2:
/home/skip/src/python/cpython/Include/Python-ast.h:603:38: note: expected ?asdl_withitem_seq *? {aka ?struct <anonymous> *?} but argument is of type ?asdl_seq *? {aka ?struct <anonymous> *?}
  603 | stmt_ty _Py_With(asdl_withitem_seq * items, asdl_stmt_seq * body, string
      |                  ~~~~~~~~~~~~~~~~~~~~^~~~~
/tmp/tmpmg0f1xoj/parse.c:270:35: warning: passing argument 2 of ?_Py_With? from incompatible pointer type [-Wincompatible-pointer-types]
  270 |             _res = _Py_With ( b , _PyPegen_singleton_seq ( p , c ) , NULL , EXTRA );
      |                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                                   |
      |                                   asdl_seq * {aka struct <anonymous> *}
In file included from /home/skip/src/python/cpython/Parser/pegen.h:7,
                 from /tmp/tmpmg0f1xoj/parse.c:2:
/home/skip/src/python/cpython/Include/Python-ast.h:603:61: note: expected ?asdl_stmt_seq *? {aka ?struct <anonymous> *?} but argument is of type ?asdl_seq *? {aka ?struct <anonymous> *?}
  603 | stmt_ty _Py_With(asdl_withitem_seq * items, asdl_stmt_seq * body, string
      |                                             ~~~~~~~~~~~~~~~~^~~~

== Tests result: SUCCESS ==

1 test OK.

Total duration: 55.0 sec
Tests result: SUCCESS

----------
components: Tests
messages: 377265
nosy: skip.montanaro
priority: normal
severity: normal
status: open
title: test_peg_generator compilation warnings
versions: Python 3.10

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

From report at bugs.python.org  Mon Sep 21 14:49:48 2020
From: report at bugs.python.org (jeet shah)
Date: Mon, 21 Sep 2020 18:49:48 +0000
Subject: [New-bugs-announce] [issue41827] 2D array issue
Message-ID: <1600714188.09.0.0697938264435.issue41827@roundup.psfhosted.org>


New submission from jeet shah <jeetshahj12375 at gmail.com>:

See difference in output by changing array definition.

----------
files: matrix summation-Copy1.ipynb
messages: 377268
nosy: jeetshahj12375
priority: normal
severity: normal
status: open
title: 2D array issue
type: behavior
versions: Python 3.10
Added file: https://bugs.python.org/file49469/matrix summation-Copy1.ipynb

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

From report at bugs.python.org  Mon Sep 21 20:14:10 2020
From: report at bugs.python.org (Drew Scholz)
Date: Tue, 22 Sep 2020 00:14:10 +0000
Subject: [New-bugs-announce] [issue41828] No longer able to override
 DATA_UPLOAD_MAX_MEMORY_SIZE outside of settings.py
Message-ID: <1600733650.36.0.422785737088.issue41828@roundup.psfhosted.org>


New submission from Drew Scholz <drew.scholz at metergroup.com>:

After upgrading our Django 1.11 project from Python 2.7 to 3.7, our single endpoint decorator to override django conf settings no longer works. requests.py inside the virtual environment /lib/python3.7/site-packages/django/http triggers the RequestDataTooBig exception (~line 271) before the change to DATA_UPLOAD_MAX_MEMORY_SIZE has been increased by our decorator. We are able to make the change global inside settings.py however we are concerned with the security vulnerabilities due to the size we want to allow for the single endpoint.

----------
files: decorators.py
messages: 377293
nosy: drew.scholz
priority: normal
severity: normal
status: open
title: No longer able to override DATA_UPLOAD_MAX_MEMORY_SIZE outside of settings.py
type: security
versions: Python 3.7
Added file: https://bugs.python.org/file49470/decorators.py

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

From report at bugs.python.org  Mon Sep 21 20:43:13 2020
From: report at bugs.python.org (Tony Wu)
Date: Tue, 22 Sep 2020 00:43:13 +0000
Subject: [New-bugs-announce] [issue41829] sqlite3.Row always read as tuple
 when supplied to executemany
Message-ID: <1600735393.55.0.581457090913.issue41829@roundup.psfhosted.org>


New submission from Tony Wu <tonywuyt126 at gmail.com>:

Supplying a sequence or sqlite3.Row objects to sqlite3.Connection.executemany will cause the Row objects to be interpreted as Sequences instead of Mappings even if the statement to be executed uses named parameter substitution.

That is, values in the Rows are accessed using their numerical indices instead of column names.

This script demonstrate how this is unexpected behavior.

Issue found in Python 3.8.5 and 3.7.6.

----------
components: Extension Modules
files: row_substitution.py
messages: 377295
nosy: tony.wu
priority: normal
severity: normal
status: open
title: sqlite3.Row always read as tuple when supplied to executemany
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file49471/row_substitution.py

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

From report at bugs.python.org  Tue Sep 22 03:52:06 2020
From: report at bugs.python.org (sanka sowmya)
Date: Tue, 22 Sep 2020 07:52:06 +0000
Subject: [New-bugs-announce] [issue41830] "NameError: name 'AttributeError'
 is not defined"
Message-ID: <1600761126.36.0.940081595242.issue41830@roundup.psfhosted.org>


New submission from sanka sowmya <sasowmy1 at in.ibm.com>:

I am using 3.6.8 version of python.
I am seeing an error as NameError: name 'AttributeError' is not defined

URL where logs can be seen:https://bpa.st/DDTQ

----------
messages: 377305
nosy: sasowmy1
priority: normal
severity: normal
status: open
title: "NameError: name 'AttributeError' is not defined"
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue Sep 22 04:02:08 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 22 Sep 2020 08:02:08 +0000
Subject: [New-bugs-announce] [issue41831] Restore default __str__ of
 tkinter.EventType
Message-ID: <1600761728.11.0.806408234986.issue41831@roundup.psfhosted.org>


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

The tkinter.EventType enum was introduced in issue27294. It implements __str__ as returning the name for the sole purpose of using in Event.__repr__(). But overriding __str__ in the str subclass may be not good idea, because different code will get different string representation, depending on whether it calls str() explicitly or implicitly (Python code) or read the content of the str object directly using C API (C code).

The following code sets EventType.__str__ = str.__str__, so both method will get the same value. Instead Event.__repr__() was changed to use the name of the enum member directly.

----------
components: Tkinter
messages: 377306
nosy: ethan.furman, serhiy.storchaka, terry.reedy
priority: normal
severity: normal
status: open
title: Restore default __str__ of tkinter.EventType
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Sep 22 06:29:31 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 22 Sep 2020 10:29:31 +0000
Subject: [New-bugs-announce] [issue41832] PyType_FromSpec() should accept
 tp_doc=NULL
Message-ID: <1600770571.99.0.249807543427.issue41832@roundup.psfhosted.org>


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

When a Python type is defined in a C extension module as a static type, its documentation can be a NULL string (NULL pointer). But PyType_FromSpec() does crash if tp_doc is NULL, since this change:

commit 032400b2d83ba1c2e4ee1cd33f51e9a598b2cf6c
Author: Georg Brandl <georg at python.org>
Date:   Sat Feb 19 21:47:02 2011 +0000

    #11249: in PyType_FromSpec, copy tp_doc slot since it usually will point to a static string literal which should not be deallocated together with the type.

(...)
diff --git a/Objects/typeobject.c b/Objects/typeobject.c
index e9c7591b81..b1fe44ebe4 100644
--- a/Objects/typeobject.c
+++ b/Objects/typeobject.c
@@ -2347,6 +2347,17 @@ PyObject* PyType_FromSpec(PyType_Spec *spec)
            goto fail;
        }
        *(void**)(res_start + slotoffsets[slot->slot]) = slot->pfunc;
+
+        /* need to make a copy of the docstring slot, which usually
+           points to a static string literal */
+        if (slot->slot == Py_tp_doc) {
+            ssize_t len = strlen(slot->pfunc)+1;
+            char *tp_doc = PyObject_MALLOC(len);
+            if (tp_doc == NULL)
+               goto fail;
+            memcpy(tp_doc, slot->pfunc, len);
+            res->ht_type.tp_doc = tp_doc;
+        }
     }
 
     return (PyObject*)res;


I propose to accept tp_doc=NULL in PyType_FromSpec(), as we do in static types.

I noticed this difference while reviewing PR 22220 which convert _lsprof extension static types to heap types.

----------
components: Interpreter Core
messages: 377308
nosy: vstinner
priority: normal
severity: normal
status: open
title: PyType_FromSpec() should accept tp_doc=NULL
versions: Python 3.10

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

From report at bugs.python.org  Tue Sep 22 07:47:35 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 22 Sep 2020 11:47:35 +0000
Subject: [New-bugs-announce] [issue41833] threading.Thread: use target name
 if the name parameter is omitted
Message-ID: <1600775255.57.0.261270212449.issue41833@roundup.psfhosted.org>


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

When debugging race conditions in a multithreaded application with many threads, it's hard to debug when threads have generic names like "Thread-3".

I propose to use the target name in threading.Thread constructor if the name parameter is omitted.


See for example bpo-41739 with "Dangling thread: <Thread(Thread-3, started daemon 4396088817936)>": the "Thread-3" name is not helpful. I suspect that the bug comes from threading.Thread(target=remove_loop, args=(fn, del_count)): with my proposed change, the thread would be called "target=remove_loop", which is more helpful than "Thread".

Fall back on _newname() as usual if target.__name__ attribute does not exist.

Attached PR implements this idea.

----------
components: Library (Lib)
messages: 377314
nosy: vstinner
priority: normal
severity: normal
status: open
title: threading.Thread: use target name if the name parameter is omitted
versions: Python 3.10

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

From report at bugs.python.org  Tue Sep 22 08:39:27 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 22 Sep 2020 12:39:27 +0000
Subject: [New-bugs-announce] [issue41834] Remove _Py_CheckRecursionLimit
 variable
Message-ID: <1600778367.51.0.464121227135.issue41834@roundup.psfhosted.org>


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

_Py_CheckRecursionLimit variable is no longer needed and can be removed.

In Python 3.9, I added a recursion limit per interpreter.

In Python 3.8 and older, it was used by _Py_MakeRecCheck() macro to check for recursion error. 

Previously, the _Py_CheckRecursionLimit variable was kept for backward compatibility with the stable ABI, but in Python 3.8 and older, Py_EnterRecursiveCall() and Py_LeaveRecursiveCall() could not be used with the limited C API since these macros accessed PyThreadState structure member, whereas the structure is opaque in the limited C API.

Attached PR removed the variable.

---

(3) bpo-40513: Limit made per interpreter.

commit 4e30ed3af06ae655f4cb8aad8cba21f341384250
Author: Victor Stinner <vstinner at python.org>
Date:   Tue May 5 16:52:52 2020 +0200

    bpo-40513: Per-interpreter recursion_limit (GH-19929)
    
    Move recursion_limit member from _PyRuntimeState.ceval to
    PyInterpreterState.ceval.
    
    * Py_SetRecursionLimit() now only sets _Py_CheckRecursionLimit
      of ceval.c if the current Python thread is part of the main
      interpreter.
    * Inline _Py_MakeEndRecCheck() into _Py_LeaveRecursiveCall().
    * Convert _Py_RecursionLimitLowerWaterMark() macro into a static
      inline function.

---

(2) bpo-38644: The _Py_CheckRecursionLimit variable was used by Py_EnterRecursiveCall() and Py_LeaveRecursiveCall() macros. I converted these macros into function calls in Python 3.9:

commit f4b1e3d7c64985f5d5b00f6cc9a1c146bbbfd613
Author: Victor Stinner <vstinner at python.org>
Date:   Mon Nov 4 19:48:34 2019 +0100

    bpo-38644: Add Py_EnterRecursiveCall() to the limited API (GH-17046)
    
    Provide Py_EnterRecursiveCall() and Py_LeaveRecursiveCall() as
    regular functions for the limited API. Previously, there were defined
    as macros, but these macros didn't work with the limited API which
    cannot access PyThreadState.recursion_depth field.
    
    Remove _Py_CheckRecursionLimit from the stable ABI.
    
    Add Include/cpython/ceval.h header file.

In pycore_ceval.h, the function is overriden by a macro which points to an inline function which uses:

* tstate->recursion_depth
* tstate->interp->ceval.recursion_limit
* tstate->stackcheck_counter (if USE_STACKCHECK macro is defined)

---

(1) bpo-31857: Original change adding the FIXME.

commit 1896793520a49a6f97ae360c0b288967e56b005e
Author: pdox <pdox at alum.mit.edu>
Date:   Wed Oct 25 23:03:01 2017 -0700

    bpo-31857: Make the behavior of USE_STACKCHECK deterministic (#4098)

This change added the FIXME comment:

/* Due to the macros in which it's used, _Py_CheckRecursionLimit is in
   the stable ABI.  It should be removed therefrom when possible.
*/

----------
components: C API
messages: 377317
nosy: vstinner
priority: normal
severity: normal
status: open
title: Remove _Py_CheckRecursionLimit variable
versions: Python 3.10

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

From report at bugs.python.org  Tue Sep 22 08:56:44 2020
From: report at bugs.python.org (Marco Sulla)
Date: Tue, 22 Sep 2020 12:56:44 +0000
Subject: [New-bugs-announce] [issue41835] Speed up dict vectorcall creation
 using keywords
Message-ID: <1600779404.53.0.758044601526.issue41835@roundup.psfhosted.org>


New submission from Marco Sulla <launchpad.net at marco.sulla.e4ward.com>:

I've done a PR that speeds up the vectorcall creation of a dict using keyword arguments. The PR in practice creates a insertdict_init(), a specialized version of insertdict. I quote the comment to the function:

Same to insertdict but specialized for inserting without resizing and for dict that are populated in a loop and was empty before (see the empty arg).
Note that resizing must be done before calling this function. If not 
possible, use insertdict(). Furthermore, ma_version_tag is left unchanged, you have to change it after calling this function (probably at the end of a loop).

This change speeds up the code up to a 30%. Tested with:

python -m timeit -n 2000  --setup "from uuid import uuid4 ; o =
{str(uuid4()).replace('-', '') : str(uuid4()).replace('-', '') for i
in range(10000)}" "dict(**o)"

----------
components: Interpreter Core
messages: 377318
nosy: Marco Sulla, inada.naoki
priority: normal
pull_requests: 21398
severity: normal
status: open
title: Speed up dict vectorcall creation using keywords
versions: Python 3.10

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

From report at bugs.python.org  Tue Sep 22 10:04:23 2020
From: report at bugs.python.org (Philippe Ombredanne)
Date: Tue, 22 Sep 2020 14:04:23 +0000
Subject: [New-bugs-announce] [issue41836] Improve ctypes error reporting
 with missing DLL path
Message-ID: <1600783463.67.0.783578166669.issue41836@roundup.psfhosted.org>


New submission from Philippe Ombredanne <pombredanne at nexb.com>:

When the dependency of a DLL is missing (at least on Windows) the error " OSError: [WinError 126] The specified module could not be found" is raised when calling ctypes.CDLL(dll_path) even when this "dll_path" exists... because the error comes from another DLL.

These errors are really hard to diagnose because the path of the missing DLL is not returned in the exception message. Returning it would help fixing these kind of errors quickly.

Researching errors such as this one https://github.com/nexB/scancode-toolkit/issues/2236 wastes quite a bit of time and would be made a non issue if we had the path in the error message.

----------
components: ctypes
messages: 377322
nosy: pombredanne
priority: normal
severity: normal
status: open
title: Improve ctypes error reporting with missing DLL path
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Tue Sep 22 20:59:08 2020
From: report at bugs.python.org (Ned Deily)
Date: Wed, 23 Sep 2020 00:59:08 +0000
Subject: [New-bugs-announce] [issue41837] Upgrade installers to OpenSSL
 1.1.1h
Message-ID: <1600822748.89.0.850484234677.issue41837@roundup.psfhosted.org>


New submission from Ned Deily <nad at python.org>:

"22-Sep-2020  OpenSSL 1.1.1h is now available, including bug fixes"

Christian, any changes need in _ssl or any other reasons we should not upgrade?

Changes between 1.1.1g and 1.1.1h [22 Sep 2020]

  *) Certificates with explicit curve parameters are now disallowed in
     verification chains if the X509_V_FLAG_X509_STRICT flag is used.
     [Tomas Mraz]

  *) The 'MinProtocol' and 'MaxProtocol' configuration commands now silently
     ignore TLS protocol version bounds when configuring DTLS-based contexts, and
     conversely, silently ignore DTLS protocol version bounds when configuring
     TLS-based contexts.  The commands can be repeated to set bounds of both
     types.  The same applies with the corresponding "min_protocol" and
     "max_protocol" command-line switches, in case some application uses both TLS
     and DTLS.
  
     SSL_CTX instances that are created for a fixed protocol version (e.g.
     TLSv1_server_method()) also silently ignore version bounds.  Previously
     attempts to apply bounds to these protocol versions would result in an
     error.  Now only the "version-flexible" SSL_CTX instances are subject to
     limits in configuration files in command-line options.
     [Viktor Dukhovni]

  *) Handshake now fails if Extended Master Secret extension is dropped
     on renegotiation.
     [Tomas Mraz]

----------
components: Build, Windows, macOS
messages: 377352
nosy: christian.heimes, ned.deily, paul.moore, ronaldoussoren, steve.dower, tim.golden, zach.ware
priority: high
severity: normal
status: open
title: Upgrade installers to OpenSSL 1.1.1h
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Sep 23 05:41:05 2020
From: report at bugs.python.org (Mohit Kumar)
Date: Wed, 23 Sep 2020 09:41:05 +0000
Subject: [New-bugs-announce] [issue41838] Value error is showing in docset
 python (class)
Message-ID: <1600854065.72.0.967885714399.issue41838@roundup.psfhosted.org>


New submission from Mohit Kumar <mkay6123 at gmail.com>:

https://github.com/python/bugs.python.org/issues/55

----------
assignee: docs at python
components: Documentation
messages: 377362
nosy: docs at python, mkay6122
priority: normal
severity: normal
status: open
title: Value error is showing in docset python (class)
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Wed Sep 23 05:44:51 2020
From: report at bugs.python.org (Jakub Kulik)
Date: Wed, 23 Sep 2020 09:44:51 +0000
Subject: [New-bugs-announce] [issue41839] Fix error checking in
 sched_get_priority_ functions
Message-ID: <1600854291.47.0.647428852002.issue41839@roundup.psfhosted.org>


New submission from Jakub Kulik <kulikjak at gmail.com>:

Python presumes that any negative number returned from sched_get_priority_min or sched_get_priority_max indicates that error has occurred. However, neither Linux manual pages nor POSIX.1-2001 specification forbids negative values to be returned; only -1 has a special meaning for error.

On Solaris, sched_get_priority_min can, in some instances, return -60, and while this is a legitimate scheduling priority value, Python throws an OSError. Checking for -1 rather than all negative values fixes this issue.

----------
components: Library (Lib)
messages: 377363
nosy: kulikjak
priority: normal
severity: normal
status: open
title: Fix error checking in sched_get_priority_ functions
type: behavior
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Wed Sep 23 08:22:04 2020
From: report at bugs.python.org (CendioOssman)
Date: Wed, 23 Sep 2020 12:22:04 +0000
Subject: [New-bugs-announce] [issue41840] [regression]
 symtable.Symbol.is_local() is no longer True for bound global symbols
Message-ID: <1600863724.98.0.825702411391.issue41840@roundup.psfhosted.org>


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

So Issue40196 (and PR 19391) broke things for us here as Symbol.is_local() no longer works properly for symbols on the global/module scope.

Previously it would return True for all global symbols that were bound. Now it only returns True when the symbol is not used in any other scope. This means we cannot tell the difference between globals that are from the module itself, and globals that come in via imports.

This also seems to contradict this part of the language reference:

"(The variables of the module code block are local and global.)"

https://docs.python.org/3/reference/executionmodel.html

I don't see any clean workaround as there is no Symbol.is_bound() that could be used instead.

(inb4 https://xkcd.com/1172/)

----------
components: Library (Lib)
messages: 377373
nosy: CendioOssman
priority: normal
severity: normal
status: open
title: [regression] symtable.Symbol.is_local() is no longer True for bound global symbols
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/issue41840>
_______________________________________

From report at bugs.python.org  Wed Sep 23 08:31:32 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 23 Sep 2020 12:31:32 +0000
Subject: [New-bugs-announce] [issue41841] idlelib/NEWS.txt for 3.10.0 and
 backports
Message-ID: <1600864292.35.0.268589439404.issue41841@roundup.psfhosted.org>


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

Master became 3.10 as of 3.9.0 beta 1: Monday, 2020-05-18.
However, backported IDLE issues continued going under What's New 3.9
on both master and 3.9 until 3.9.0rc1, Tuesday, 2020-08-11.
Subsequent merges go under
What's New 3.10.0 on master
What's New 3.9.1 on 3.9

In other words, News is handled as if master were still branched off as of .0rc1.  This is different from the changelog attached to What's New in 3.x.

Release peps -- needed for proposed and actual release dates.
3.8 PEP 569 https://www.python.org/dev/peps/pep-0569/
3.9 PEP 596 https://www.python.org/dev/peps/pep-0596/
3.10 PEP 619 https://www.python.org/dev/peps/pep-0619/

----------
assignee: terry.reedy
components: IDLE
messages: 377375
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: idlelib/NEWS.txt for 3.10.0 and backports
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Sep 23 08:56:58 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Sep 2020 12:56:58 +0000
Subject: [New-bugs-announce] [issue41842] Add codecs.unregister() to
 unregister a codec search function
Message-ID: <1600865818.68.0.279745610542.issue41842@roundup.psfhosted.org>


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

Writing an unit test on the Python codecs machinery is facing a practical problem: there is no C nor Python API to unregister a codec search function.

It's even documented in a note of the codecs.register() function:

"Note: Search function registration is not currently reversible, which may cause problems in some cases, such as unit testing or module reloading."

https://docs.python.org/dev/library/codecs.html#codecs.register

test_codecs contains a long comment about that:

        # There's no way to unregister a codec search function, so we just
        # ensure we render this one fairly harmless after the test
        # case finishes by using the test case repr as the codec name
        # The codecs module normalizes codec names, although this doesn't
        # appear to be formally documented...
        # We also make sure we use a truly unique id for the custom codec
        # to avoid issues with the codec cache when running these tests
        # multiple times (e.g. when hunting for refleaks)

See bpo-22166 which fixed memory leaks in test_codecs.

In 2011, a Python user requested the function
https://mail.python.org/pipermail/python-dev/2011-September/113588.html

Marc-Andre Lemburg explained:

"There is no API to unregister a codec search function, since deregistration
would break the codec cache used by the registry to speedup codec
lookup."

One simple solution would be to clear the cache (PyInterpreterState.codec_search_cache) when codecs.unregister() removes a search function. I expect that calling unregister() is an uncommon operation, so the performance is not a blocker issue.

----------
components: Library (Lib), Unicode
messages: 377377
nosy: ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: Add codecs.unregister() to unregister a codec search function
versions: Python 3.10

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

From report at bugs.python.org  Wed Sep 23 09:24:12 2020
From: report at bugs.python.org (Jakub Kulik)
Date: Wed, 23 Sep 2020 13:24:12 +0000
Subject: [New-bugs-announce] [issue41843] Reenable sendfile in
 shutil.copyfile() on Solaris
Message-ID: <1600867452.06.0.35884925988.issue41843@roundup.psfhosted.org>


New submission from Jakub Kulik <kulikjak at gmail.com>:

The use of sendfile() in shutil.copyfile() on Solaris was previously disabled in #36610 due to slightly different behavior. This difference was recently accounted for in #41687, and I observed no other unexpected problems/differences with sendfile.

Can we get this reenabled? I can prepare PR, however, I am not sure whether #36610 should be reverted (hence enabling sendfile in copyfile on every system where it is available) or whether I should just add Solaris to _USE_CP_SENDFILE condition.

----------
components: Library (Lib)
messages: 377383
nosy: giampaolo.rodola, kulikjak
priority: normal
severity: normal
status: open
title: Reenable sendfile in shutil.copyfile() on Solaris
type: performance
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Wed Sep 23 10:23:59 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 23 Sep 2020 14:23:59 +0000
Subject: [New-bugs-announce] [issue41844] IDLE subsection of What's New 3.9
Message-ID: <1600871039.14.0.615866740871.issue41844@roundup.psfhosted.org>


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

Following #33821, master issue for IDLE entries in Doc/whatsnew/3.8.rst.  This doc has a section 'Improved Modules' with a subsection 'idlelib and IDLE'.  The initial unlabeled subsubsection includes important enhancements to IDLE since 3.7.0.

Because of IDLE's special backport policy (PEP 434), this initial part concludes with "The changes above have been backported to 3.7 maintenance releases."  Future subsubsections 'New in 3.8.z:', z >= 1, will follow for backports to 3.8.z.  This issue will close after the last 3.8 maintenance release.

This file will always exists in the master branch.  Changes are applied to master and backported as needed at the time.  Entries will be the same in the What's New x.y for all x.y branches that get the enhancement.  However, each file needs different backports.  Hence separate PRs are needed for auto backport to work.  It seems convenient to have separate issues for each.

----------
assignee: terry.reedy
components: IDLE
messages: 377387
nosy: terry.reedy
priority: normal
severity: normal
status: open
title: IDLE subsection of What's New 3.9
type: enhancement
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Wed Sep 23 10:31:49 2020
From: report at bugs.python.org (Alex Gaynor)
Date: Wed, 23 Sep 2020 14:31:49 +0000
Subject: [New-bugs-announce] [issue41845] Promote PyObject_GenericGetDict to
 the stable API
Message-ID: <1600871509.15.0.3993940648.issue41845@roundup.psfhosted.org>


New submission from Alex Gaynor <alex.gaynor at gmail.com>:

Currently PyObject_GenericSetDict is part of the stable API, but PyObject_GenericGetDict is not. I noticed this while working on https://github.com/PyO3/pyo3/pull/1207

Because of the symmetry here, it seems appropriate to promote Get.

----------
components: C API
messages: 377388
nosy: alex, benjamin.peterson
priority: normal
severity: normal
status: open
title: Promote PyObject_GenericGetDict to the stable API
versions: Python 3.10

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

From report at bugs.python.org  Wed Sep 23 10:32:22 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 23 Sep 2020 14:32:22 +0000
Subject: [New-bugs-announce] [issue41846] IDLE subsection of What's New 3.10
Message-ID: <1600871542.4.0.618379951214.issue41846@roundup.psfhosted.org>


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

Following #41844, master issue for IDLE entries in Doc/whatsnew/3.10.rst.  This doc has a section 'Improved Modules' with a subsection 'idlelib and IDLE'.  The initial unlabeled subsubsection includes important enhancements to IDLE since 3.9.0.

Because of IDLE's special backport policy (PEP 434), this initial part concludes with "The changes above have been backported to 3.9 maintenance releases."  Future subsubsections 'New in 3.10.z:', z >= 1, will follow for backports to 3.10.z.  These can precede the backport message as long as it is true. This issue will close after the last 3.10 maintenance release.

This file will always exists in the master branch.  Changes are applied to master and backported as needed at the time.  Entries will be the same in the What's New x.y for all x.y branches that get the enhancement.  However, each file needs different backports.  Hence separate PRs are needed for auto backport to work.  It seems convenient to have separate issues for each.

----------
assignee: terry.reedy
components: IDLE
messages: 377390
nosy: terry.reedy
priority: normal
severity: normal
status: open
title: IDLE subsection of What's New 3.10
versions: Python 3.10

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

From report at bugs.python.org  Wed Sep 23 18:45:27 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 23 Sep 2020 22:45:27 +0000
Subject: [New-bugs-announce] [issue41847] Update "install launcher for all
 users" installer option
Message-ID: <1600901127.12.0.836630425545.issue41847@roundup.psfhosted.org>


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

The "Install launcher for all users" option on the front page of the installer should be updated to read "Install py.exe launcher for all users" to reduce confusion.

However, we should also consider disabling this by default, so that the normal settings do not require admin privileges to install.

The reason we started with it enabled by default is because we had to stomp on the 3.4 and earlier py.exe, since there was no other way to make sure it wasn't an issue. That problem still remains, which likely means that if we detect an all-users launcher from a previous version we need to keep the option enabled, but at least for clean installs of 3.10 we can avoid the need for admin completely.

----------
components: Windows
messages: 377430
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Update "install launcher for all users" installer option
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Wed Sep 23 19:33:02 2020
From: report at bugs.python.org (Sergei Lebedev)
Date: Wed, 23 Sep 2020 23:33:02 +0000
Subject: [New-bugs-announce] [issue41848] PEG parser doesn't allow lambda in
 for_if_clause
Message-ID: <1600903982.27.0.474581886877.issue41848@roundup.psfhosted.org>


New submission from Sergei Lebedev <slebedev at google.com>:

Reproducer:

[x for x in [] if lambda: x]

This parses fine in 3.8, but doesn't parse in 3.9 because the grammar expects a disjunction after if in for_if_clause [*]. While this change has zero practical significance, I think it might be useful to maintain a list of such changes for tooling authors (who might need to support multiple Python versions).

[*]: https://github.com/python/cpython/blob/68526fe258da8c01196fd7cf48e8e5f1280bf8fd/Grammar/python.gram#L523

----------
components: Interpreter Core
messages: 377435
nosy: lys.nikolaou, slebedev
priority: normal
severity: normal
status: open
title: PEG parser doesn't allow lambda in for_if_clause
type: behavior
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Wed Sep 23 20:33:10 2020
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 24 Sep 2020 00:33:10 +0000
Subject: [New-bugs-announce] [issue41849] Support reading long lines with
 io._WindowsConsoleIO
Message-ID: <1600907590.14.0.954461587522.issue41849@roundup.psfhosted.org>


New submission from Eryk Sun <eryksun at gmail.com>:

io._WindowsConsoleIO reads from the console via ReadConsoleW in line-input mode, which limits the line length to the maximum of 256 and the size of the client buffer, including the trailing CRLF (or just CR if processed-input mode is disabled). Text that's typed or pasted beyond the length limit is ignored. The call returns when a carriage return ("\r") is read or the user types the enter key anywhere on the line.

Currently the buffer that _WindowsConsoleIO passes to ReadConsoleW is capped at 512 wide characters, based on the C runtime's BUFSIZ (512) macro. This is too small. Legacy mode (i.e. PYTHONLEGACYWINDOWSSTDIO) uses io.FileIO with an 8 KiB buffer, which is 8K characters when the console input codepage is a legacy single-byte encoding. _WindowsConsoleIO should support at least this much. 

I'd prefer that it allowed up to 32K characters, which is the upper limit for a process command line or for a long filepath. By way of comparison, input(), which calls _PyOS_WindowsConsoleReadline if stdin is a console file, is currently capped at 16K characters.

To be able to read up to 32K characters also requires increasing the BufferedReader default buffer size and TextIOWrapper chunk size to 96 KiB (BMP codes in the range 0x0800-0xFFFF encode as a 3-byte UTF-8 sequence) in order to ensure that f.readline() and f.buffer.readline() request the maximum size. This would require changing _io__WindowsConsoleIO___init___impl to set `self->blksize = 96 * 1024` when `console_type == 'r'`, as well as changing _io_open_impl to manually set the _CHUNK_SIZE of the TextIOWrapper to 96 KiB for console input (type 'r'). Maybe TextIOWrapper should just query the raw _blksize as the initial chunk size. That would remove the need to manually set _CHUNK_SIZE.

----------
components: IO, Unicode, Windows
messages: 377436
nosy: eryksun, ezio.melotti, paul.moore, steve.dower, tim.golden, vstinner, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Support reading long lines with io._WindowsConsoleIO
type: enhancement
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Thu Sep 24 04:23:10 2020
From: report at bugs.python.org (Gregoire Chalony)
Date: Thu, 24 Sep 2020 08:23:10 +0000
Subject: [New-bugs-announce] [issue41850] inspect.py: access block stack
Message-ID: <1600935790.44.0.688452336961.issue41850@roundup.psfhosted.org>


New submission from Gregoire Chalony <gchalony at gmail.com>:

The inspect module doesn't currently expose any way to access the block stack at runtime.
Would that be possible?

Aked on StackOverflow here: https://stackoverflow.com/questions/63187845/cpython-access-loop-depth-level-block-stack.

----------
messages: 377442
nosy: gchalony
priority: normal
severity: normal
status: open
title: inspect.py: access block stack
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Thu Sep 24 07:27:19 2020
From: report at bugs.python.org (E. Paine)
Date: Thu, 24 Sep 2020 11:27:19 +0000
Subject: [New-bugs-announce] [issue41851] tkinter: add font neg and equal
 methods
Message-ID: <1600946839.14.0.547852459363.issue41851@roundup.psfhosted.org>


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

I think it would be helpful to add these methods to the tkinter font class.

Starting with the equal method, I have found it very useful to be able to compare tkinter fonts based on their value rather than just name. I used this, for example, in #28694 to ensure the -font attribute had been changed correctly (though there I compared each of the attributes explicitly rather than using `.actual()` as I have in this patch).

The neg method, I think, would be very useful to allow easy conversion between points and pixels. For example:

points = Font(size=16)
pixels = -points

----------
components: Tkinter
messages: 377446
nosy: epaine, gpolo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: tkinter: add font neg and equal methods
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Thu Sep 24 12:44:20 2020
From: report at bugs.python.org (Ben Kurtovic)
Date: Thu, 24 Sep 2020 16:44:20 +0000
Subject: [New-bugs-announce] [issue41852] Inconsistent errors for
 JSON-encoding NaNs with allow_nan=False
Message-ID: <1600965860.06.0.567784845074.issue41852@roundup.psfhosted.org>


New submission from Ben Kurtovic <ben.kurtovic at gmail.com>:

json.dump vs. json.dumps have inconsistent error messages when encoding NaN with allow_nan=False:

>>> json.dumps(float('nan'), allow_nan=False)
ValueError: Out of range float values are not JSON compliant
>>> json.dump(float('nan'), sys.stdout, allow_nan=False)
ValueError: Out of range float values are not JSON compliant: nan

json.dump's error includes the value (which is useful); json.dumps's does not.

json.dumps uses this C implementation: https://github.com/python/cpython/blob/d67de0a30d76c6a28056bae22fd7d13f2e111b77/Modules/_json.c#L1340
json.dump uses this Python implementation: https://github.com/python/cpython/blob/d67de0a30d76c6a28056bae22fd7d13f2e111b77/Lib/json/encoder.py#L223

(Separately, is it expected that only one uses the C implementation? This seems it could have unexpected performance implications - without testing, I would've expected json.dump to take the "faster" path since it doesn't need to hold the entire encoded string in memory.)

----------
components: Extension Modules, Library (Lib)
messages: 377450
nosy: earwig
priority: normal
severity: normal
status: open
title: Inconsistent errors for JSON-encoding NaNs with allow_nan=False
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Sep 24 12:45:07 2020
From: report at bugs.python.org (Forrest Shields)
Date: Thu, 24 Sep 2020 16:45:07 +0000
Subject: [New-bugs-announce] [issue41853] Windows docs for command line
 install don't mention /log option
Message-ID: <1600965907.53.0.783405131873.issue41853@roundup.psfhosted.org>


New submission from Forrest Shields <forrestshields2 at gmail.com>:

Section "3.1.3. Installing Without UI" of the Windows documentation at https://docs.python.org/3/using/windows.html#installing-without-ui does not mention the existence of the `/log` option.

However, this option is detailed when the Windows installer is executed with a `/?` argument. (see attached image).

The documentation (for all versions that contained the logging option) should be updated.

The help dialog also defines the `/simple` option. This appears to overlap with a "name=value" option called SimpleInstall. If both options are still active, then the docs should also mention `/simple`.  If this option is deprecated in favor of the "name=value" version, then the help dialog needs to be updated.

Finally, I think the docs would be much more readable if the slash options were in a table similar to the "name=value" options.

----------
assignee: docs at python
components: Documentation, Windows
files: Python-3.8.5-for-WIndows--Setup-Help.png
messages: 377452
nosy: docs at python, forrestshields2, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows docs for command line install don't mention /log option
type: enhancement
versions: Python 3.10, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49473/Python-3.8.5-for-WIndows--Setup-Help.png

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

From report at bugs.python.org  Thu Sep 24 16:23:50 2020
From: report at bugs.python.org (Reuben Thomas)
Date: Thu, 24 Sep 2020 20:23:50 +0000
Subject: [New-bugs-announce] [issue41854]
 argparse.add_mutually_exclusive_group fails for optional positional
 arguments
Message-ID: <1600979030.91.0.326865229332.issue41854@roundup.psfhosted.org>


New submission from Reuben Thomas <rrt at sc3d.org>:

The following code:

group = parser.add_mutually_exclusive_group()
group.add_argument('--install-only', action='store_true',
                    help='just install the program, do not run it')
group.add_argument('args', metavar='ARGUMENT', nargs='*', default=None,
                    help='arguments to PROGRAM')

gives the following error:

    group.add_argument('args', metavar='ARGUMENT', nargs='*',
  File "/usr/lib/python3.8/argparse.py", line 1398, in add_argument
    return self._add_action(action)
  File "/usr/lib/python3.8/argparse.py", line 1621, in _add_action
    raise ValueError(msg)
ValueError: mutually exclusive arguments must be optional

But the 'args' argument *is* optional, as there can be 0 of them.

----------
components: Library (Lib)
messages: 377460
nosy: rrt
priority: normal
severity: normal
status: open
title: argparse.add_mutually_exclusive_group fails for optional positional arguments
versions: Python 3.8

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

From report at bugs.python.org  Thu Sep 24 16:30:47 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 24 Sep 2020 20:30:47 +0000
Subject: [New-bugs-announce] [issue41855] FastPath.zip_children can give
 duplicate results on Python 3.8
Message-ID: <1600979447.4.0.878308868671.issue41855@roundup.psfhosted.org>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

Scott J. reports in an e-mail:

When upgrading to Python 3.8.2, we noticed two issues in
importlib.metadata which are not present in importlib_metadata.

1.  FastPath.zip_children() is very slow for large zips. Python 3.8.3
    > already has a fix for this
    > ([[bug]{.ul}](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.python.org%2Fissue39667&data=02%7C01%7Cbwarsaw%40linkedin.com%7C514c7c4d1eea417ed26908d86024cd43%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637365058462361570&sdata=Msk47lScorCQpx5PHiKrpeYYzBLMR89HNZ7RwY7ch4c%3D&reserved=0),
    > [[changelog]{.ul}](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.python.org%2F3%2Fwhatsnew%2Fchangelog.html%23id45&data=02%7C01%7Cbwarsaw%40linkedin.com%7C514c7c4d1eea417ed26908d86024cd43%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637365058462371564&sdata=CSPBVi5rPFSCovRZdd8WNbOQ4mxDycy%2FmjDhbty4OLk%3D&reserved=0)),
    > which includes merging in importlib_metadata 1.5.0.

2.  FastPath.zip_children() can give duplicate results, causing
    > duplicate results in entry_points(). This issue was reported in
    > importlib_metadata in March
    > ([[link]{.ul}](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.com%2Fpython-devs%2Fimportlib_metadata%2F-%2Fissues%2F117&data=02%7C01%7Cbwarsaw%40linkedin.com%7C514c7c4d1eea417ed26908d86024cd43%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637365058462371564&sdata=g5N0ew3WAOUfPJ5eL7oY0j9NIpXkh8HAkV%2FWD4UppX8%3D&reserved=0))
    > and fixed in importlib_metadata 1.5.2
    > ([[changelog]{.ul}](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fimportlib-metadata.readthedocs.io%2Fen%2Flatest%2Fchangelog.html%23v1-5-2&data=02%7C01%7Cbwarsaw%40linkedin.com%7C514c7c4d1eea417ed26908d86024cd43%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637365058462381558&sdata=UpnqBoyl%2FcGMkF%2BfFufredA0QGt31o5Qag3joQ%2FJhDs%3D&reserved=0)).

In June, importlib_metadata 1.6.1 (including the fix for \#2) was merged
into Python
([[bug]{.ul}](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.python.org%2Fissue39791%23msg370782&data=02%7C01%7Cbwarsaw%40linkedin.com%7C514c7c4d1eea417ed26908d86024cd43%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637365058462381558&sdata=i8Y8o5f3uBXPP8OU9I3PkKSHzS%2B3z4kcd%2FdH1l%2B9YI8%3D&reserved=0),
[[PR]{.ul}](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpython%2Fcpython%2Fpull%2F20659&data=02%7C01%7Cbwarsaw%40linkedin.com%7C514c7c4d1eea417ed26908d86024cd43%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637365058462391552&sdata=Q5P3RuTNpctc4E93l2dqXRc1LYmw9XSnBb%2FaJbKTcMg%3D&reserved=0))
and backported to 3.9
([[PR]{.ul}](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpython%2Fcpython%2Fpull%2F20661&data=02%7C01%7Cbwarsaw%40linkedin.com%7C514c7c4d1eea417ed26908d86024cd43%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637365058462391552&sdata=f%2BghmbplIsbmc9CFgoQX7vxc%2FZPLG2TkEgjMZtez71s%3D&reserved=0)).
However, the backport for Python 3.8 was **not** merged
([[PR]{.ul}](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpython%2Fcpython%2Fpull%2F20662&data=02%7C01%7Cbwarsaw%40linkedin.com%7C514c7c4d1eea417ed26908d86024cd43%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637365058462391552&sdata=JTpQpeuzE%2BGvL%2FNccWcuu0vQWRKQbkBHLmzeNmWZMFc%3D&reserved=0)).
Jason said:

> Of course this can\'t backport to 3.8; importlib.resources.files
> doesn\'t exist there. No problem. Bug fixes will need to be backported
> specially if needed.

As far as I can tell, no version of importlib_metadata newer than 1.5.0
has ever been merged into Python 3.8, and so bug \#2 is still present
(tested in 3.8.6rc1). This seems like it falls under the \"bug fixes if
needed\" category. We just need to fix the duplicate entries, as
reported in importlib_metadata. This should be trivial. The diff in
python 3.9 is
[[here]{.ul}](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpython%2Fcpython%2Fpull%2F20661%2Ffiles%23diff-499abe3a411df5cf55659b640ac3b2b4L411-R435&data=02%7C01%7Cbwarsaw%40linkedin.com%7C514c7c4d1eea417ed26908d86024cd43%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637365058462401547&sdata=qZXa9e13SVng5tkL3Im2s1Gc2OSLOKlqiiDKBTqkxoI%3D&reserved=0).

----------
assignee: jaraco
messages: 377461
nosy: barry, jaraco
priority: normal
severity: normal
status: open
title: FastPath.zip_children can give duplicate results on Python 3.8
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Thu Sep 24 19:40:02 2020
From: report at bugs.python.org (Reuben Thomas)
Date: Thu, 24 Sep 2020 23:40:02 +0000
Subject: [New-bugs-announce] [issue41856] argparse: auto-generated synopsis
 omits REMAINDER argument
Message-ID: <1600990802.2.0.259982030629.issue41856@roundup.psfhosted.org>


New submission from Reuben Thomas <rrt at sc3d.org>:

Consider the following example from the Python documentation:

>>> parser = argparse.ArgumentParser(prog='PROG')
>>> parser.add_argument('--foo')
>>> parser.add_argument('command')
>>> parser.add_argument('args', nargs=argparse.REMAINDER)

Now show the help:

>>> parser.parse_args(['-h'])

This prints:

usage: PROG [-h] [--foo FOO] command ...

positional arguments:
  command
  args

Note that "args" is not shown in the synopsis. I suggest that the synopsis should instead say:

usage: PROG [-h] [--foo FOO] command args...

----------
components: Library (Lib)
messages: 377469
nosy: rrt
priority: normal
severity: normal
status: open
title: argparse: auto-generated synopsis omits REMAINDER argument
versions: Python 3.8

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

From report at bugs.python.org  Thu Sep 24 22:00:00 2020
From: report at bugs.python.org (Zane Bitter)
Date: Fri, 25 Sep 2020 02:00:00 +0000
Subject: [New-bugs-announce] [issue41857] Document timeout arguments to
 poll() in select module
Message-ID: <1600999200.88.0.890857154586.issue41857@roundup.psfhosted.org>


New submission from Zane Bitter <zaneb at fedoraproject.org>:

The select.poll.poll() and select.devpoll.poll() methods don't have their timeout arguments documented in their docstrings. In both cases the argument is in milliseconds, whereas the timeout arguments to select.kqueue.control() and select.epoll.poll() are in seconds, and are documented in the docstring.

----------
assignee: docs at python
components: Documentation
messages: 377473
nosy: docs at python, zaneb
priority: normal
severity: normal
status: open
title: Document timeout arguments to poll() in select module
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Thu Sep 24 22:16:48 2020
From: report at bugs.python.org (Emmanuel Arias)
Date: Fri, 25 Sep 2020 02:16:48 +0000
Subject: [New-bugs-announce] [issue41858] Fix incomplete line on optparse
 documentation
Message-ID: <1601000208.27.0.918892305857.issue41858@roundup.psfhosted.org>


New submission from Emmanuel Arias <eamanu at yaerobi.com>:

This line seems to be incomplete. This fix come from the translation
to spanish of @fjsevilla-dev on https://github.com/python/python-docs-es/pull/758/file.
reading the proposal for the translate has sense add `the next lines`.

----------
assignee: docs at python
components: Documentation
messages: 377474
nosy: docs at python, eamanu
priority: normal
severity: normal
status: open
title: Fix incomplete line on optparse documentation
versions: Python 3.10

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

From report at bugs.python.org  Fri Sep 25 00:12:05 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 25 Sep 2020 04:12:05 +0000
Subject: [New-bugs-announce] [issue41859] Uncaught ValueError
Message-ID: <1601007125.39.0.397372093674.issue41859@roundup.psfhosted.org>


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

I found this in today's long running shell session.  The trigger event isn't known.

Exception in Tkinter callback
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/tkinter/__init__.py", line 1885, in __call__
    return self.func(*args)
  File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/idlelib/multicall.py", line 176, in handler
    r = l[i](event)
  File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/idlelib/autocomplete_w.py", line 430, in keyrelease_event
    self.hide_window()
  File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/idlelib/autocomplete_w.py", line 447, in hide_window
    self.widget.event_delete(HIDE_VIRTUAL_EVENT_NAME, seq)
  File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/idlelib/multicall.py", line 392, in event_delete
    triplets.remove(triplet)
ValueError: list.remove(x): x not in list

----------
assignee: terry.reedy
components: IDLE
messages: 377479
nosy: rhettinger, terry.reedy
priority: normal
severity: normal
status: open
title: Uncaught ValueError
versions: Python 3.9

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

From report at bugs.python.org  Fri Sep 25 01:14:18 2020
From: report at bugs.python.org (Heng Sun)
Date: Fri, 25 Sep 2020 05:14:18 +0000
Subject: [New-bugs-announce] [issue41860] random.choices() raises "int too
 large" error while random.randint does not
Message-ID: <1601010858.58.0.226250103404.issue41860@roundup.psfhosted.org>


New submission from Heng Sun <sunheng at hotmail.com>:

If I run this one line of code:

random.choices(range(2**100), k=5)

I would get error:

OverflowError: Python int too large to convert to C ssize_t

But I can run equivalent line to achieve this without error:

[random.randint(0, 2**100-1) for j in range(5)]

With the understanding of the issue coming from len(), ref https://bugs.python.org/issue12159, I still think random.choices() should be able to handle large integers.

----------
components: Library (Lib)
messages: 377480
nosy: mathtester
priority: normal
severity: normal
status: open
title: random.choices() raises "int too large" error while random.randint does not
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Fri Sep 25 08:18:11 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Fri, 25 Sep 2020 12:18:11 +0000
Subject: [New-bugs-announce] [issue41861] Convert sqlite3 to PEP 384
Message-ID: <1601036291.36.0.740279655223.issue41861@roundup.psfhosted.org>


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

https://www.python.org/dev/peps/pep-0384/

----------
components: Library (Lib)
messages: 377488
nosy: erlendaasland
priority: normal
severity: normal
status: open
title: Convert sqlite3 to PEP 384

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

From report at bugs.python.org  Fri Sep 25 08:48:03 2020
From: report at bugs.python.org (Christopher Reilly)
Date: Fri, 25 Sep 2020 12:48:03 +0000
Subject: [New-bugs-announce] [issue41862] can not open file in system folder
Message-ID: <1601038083.98.0.914885440709.issue41862@roundup.psfhosted.org>


New submission from Christopher Reilly <reilly.christopher at gmail.com>:

I am trying to load a Windows dll "ibfs64.dll" located in the C:\Windows\System32 folder:

    ctypes.windll.LoadLibrary('ibfs64.dll')

When I attempt this call with Python 3.8.5 downloaded from python.org, the call fails with 

> FileNotFoundError: Could not find module 'ibfs64.dll' (or one of its dependencies). Try using the full path with constructor syntax.

The function call, however, succeeds in Python 3.7.9 (downloaded from python.org). This behavior (3.7.9 works, 3.8.5 does not), has been duplicated by another user on two different Windows 10 machines (my machine is also Windows 10).

Another piece of information is that this function call also succeeds in anaconda environments running Python 3.7.9 and Python 3.8.5.

When I use the dll-diagnostics tracing utility (https://pypi.org/project/dll-diagnostics/) with the anaconda-managed Python 3.8.5 installation, it succeeds:

> DLL Diagnostic Tools version 0.0.3
> Copyright (c) 2019 Adam Rehn
> 
> Parsing module header and detecting architecture... done.
> 
> Identifying the module's delay-loaded dependencies... done.
> 
> Parsed module details: Module:          C:\Windows\System32\ibfs64.dll
> Type:            Dynamic-Link Library Architecture:    x64
> 
> The module imports 0 delay-loaded dependencies:
> 
> 
> Performing LoadLibrary() trace for C:\Windows\System32\ibfs64.dll...
> Done.
> 
> Summary of LdrLoadDll calls: C:\Windows\System32\ibfs64.dll    Loaded
> successfully
> 
> Summary of LdrpLoadDllInternal calls: C:\Windows\System32\ibfs64.dll  
> Loaded successfully NTDLL.DLL                         Loaded
> successfully
> 
> Summary of LdrpMinimalMapModule calls:
> C:\Windows\System32\ADVAPI32.dll                                      
> Mapped successfully C:\Windows\System32\ibfs64.dll                    
> Mapped successfully C:\Windows\System32\msvcrt.dll                    
> Mapped successfully C:\Windows\System32\RPCRT4.dll                    
> Mapped successfully C:\Windows\System32\sechost.dll                   
> Mapped successfully
> C:\Windows\WinSxS\amd64_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.9672_none_88e266cb2fac7c0d\MSVCR80.dll
> Mapped successfully
> 
> Summary of LdrpResolveDllName calls: ibfs64.dll    
> C:\Windows\System32\ibfs64.dll MSVCR80.dll   
> C:\Windows\WinSxS\amd64_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.9672_none_88e266cb2fac7c0d\MSVCR80.dll

But when I try it with the Python 3.8.5 installed from python.org, it fails:

> DLL Diagnostic Tools version 0.0.3
> Copyright (c) 2019 Adam Rehn
> 
> Parsing module header and detecting architecture... Traceback (most recent call last):
> 
> File "c:\users\chris\appdata\local\programs\python\python38-32\lib\runpy.py", line 194, in _run_module_as_main
> 
> return _run_code(code, main_globals, None,
> 		       
> File "c:\users\chris\appdata\local\programs\python\python38-32\lib\runpy.py", line 87, in _run_code
> 
> exec(code, run_globals)
> 
> File "C:\Users\Chris\AppData\Local\Programs\Python\Python38-32\Scripts\dlldiag.exe\__main__.py", line 7, in <module>
> 
> File "c:\users\chris\appdata\local\programs\python\python38-32\lib\site-packages\dlldiag\main.py", line 29, in main
> 
> subcommands[subcommand]['function']()
> 
> File "c:\users\chris\appdata\local\programs\python\python38-32\lib\site-packages\dlldiag\subcommands\trace.py", line 188, in trace
> 
> header = ModuleHeader(args.module)
> 
> File "c:\users\chris\appdata\local\programs\python\python38-32\lib\site-packages\dlldiag\common\ModuleHeader.py", line 14, in __init__
> 
> self._pe = pefile.PE(module, fast_load=True)
> 
> File "c:\users\chris\appdata\local\programs\python\python38-32\lib\site-packages\pefile.py", line 1754, in __init__
> 
> self.__parse__(name, data, fast_load)
> 
> File "c:\users\chris\appdata\local\programs\python\python38-32\lib\site-packages\pefile.py", line 1797, in __parse__
> 
> stat = os.stat(fname)
> 
> FileNotFoundError: [WinError 2] The system cannot find the file specified: 'C:\\Windows\\system32\\ibfs64.dll'

In fact, I can not even open the file in the python.org installation of Python 3.8.5, while I can in the python.org installation of Python 3.7.9. In other words, the command

    open(r'C:\Windows\System32\ibfs64.dll','r')

succeeds with the python.org installation of Python 3.7.9, but fails (same FileNotFoundError) with version Python 3.8.5. 

What is the anaconda-managed installation doing differently? Why is the Python 3.7.9 installation from python.org successful while the 3.8.5 installation is not?

----------
components: IO, Installation, Windows, ctypes
messages: 377489
nosy: paul.moore, reilly.christopher, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: can not open file in system folder
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Fri Sep 25 14:35:09 2020
From: report at bugs.python.org (Gagandeep Longia)
Date: Fri, 25 Sep 2020 18:35:09 +0000
Subject: [New-bugs-announce] [issue41863] IDLE shell not opening
Message-ID: <1601058909.32.0.910402125729.issue41863@roundup.psfhosted.org>


New submission from Gagandeep Longia <glongia18 at gmail.com>:

I downloaded Python 3.5 and tried opening the IDLE shell. 

Each time I do it, it says "The application "IDLE" can't be opened."

Any help? My Mac OS X is 10.14.6 Mojave

----------
components: macOS
messages: 377496
nosy: glongia18, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: IDLE shell not opening
versions: Python 3.5

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

From report at bugs.python.org  Sat Sep 26 06:04:51 2020
From: report at bugs.python.org (micwin)
Date: Sat, 26 Sep 2020 10:04:51 +0000
Subject: [New-bugs-announce] [issue41864] Compiler error in
 _zoneinfo.c:1227: error: #pragma GCC diagnostic not allowed inside
 functions
Message-ID: <1601114691.42.0.0298399391813.issue41864@roundup.psfhosted.org>


New submission from micwin <micwinx at web.de>:

Python 3.9.0rc2
OS: centos 6.10
Compiler: gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-23)

configure && make 

Python-3.9.0rc2/Modules/_zoneinfo.c:1227: error: #pragma GCC diagnostic not allowed inside functions
Python-3.9.0rc2/Modules/_zoneinfo.c:1228: error: #pragma GCC diagnostic not allowed inside functions
Python-3.9.0rc2/Modules/_zoneinfo.c:1229: warning: comparison is always false due to limited range of data type
Python-3.9.0rc2/Modules/_zoneinfo.c:1230: error: #pragma GCC diagnostic not allowed inside functions


Proposed fix, here the diff:

1227d1226
< #if defined(__GNUC__) && __GNUC__ >= 5
1230d1228
< #endif
1232d1229
< #if defined(__GNUC__) && __GNUC__ >= 5
1234d1230
< #endif

----------
components: Build
messages: 377520
nosy: micwin
priority: normal
severity: normal
status: open
title: Compiler error in _zoneinfo.c:1227: error: #pragma GCC diagnostic not allowed inside functions
type: compile error
versions: Python 3.9

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

From report at bugs.python.org  Sat Sep 26 09:03:29 2020
From: report at bugs.python.org (Jack W.)
Date: Sat, 26 Sep 2020 13:03:29 +0000
Subject: [New-bugs-announce] [issue41865] doc search for super().__init__()
 returns no useful results
Message-ID: <1601125409.76.0.692244032033.issue41865@roundup.psfhosted.org>


New submission from Jack W. <softwoehr at gmail.com>:

It's oddly difficult to glean from the official documentation the correct syntax for superclass initialization.

----------
assignee: docs at python
components: Documentation
messages: 377527
nosy: docs at python, softwoehr
priority: normal
severity: normal
status: open
title: doc search for super().__init__() returns no useful results
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Sat Sep 26 12:23:58 2020
From: report at bugs.python.org (siyuan0322)
Date: Sat, 26 Sep 2020 16:23:58 +0000
Subject: [New-bugs-announce] [issue41866] Document error in chinese version
 of contextlib.
Message-ID: <1601137438.19.0.414392303646.issue41866@roundup.psfhosted.org>


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

In the Chinese version of documentation (both simplified and tradinational) of contextlib, the URL of `__enter__` and `__exit__` of [`contextlib.AbstractContextManager`](https://docs.python.org/zh-cn/3/library/contextlib.html#contextlib.AbstractContextManager) is pointing to the `__aenter__` and `__aexit__` method, which is a small mistake.

----------
assignee: docs at python
components: Documentation
messages: 377532
nosy: docs at python, siyuan
priority: normal
severity: normal
status: open
title: Document error in chinese version of contextlib.
versions: Python 3.8

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

From report at bugs.python.org  Sat Sep 26 12:44:43 2020
From: report at bugs.python.org (Ram Rachum)
Date: Sat, 26 Sep 2020 16:44:43 +0000
Subject: [New-bugs-announce] [issue41867] Include options for timespec in
 docstrings of isoformat
Message-ID: <1601138683.03.0.777121692912.issue41867@roundup.psfhosted.org>


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

Writing the patch now.

----------
components: Library (Lib)
messages: 377534
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Include options for timespec in docstrings of isoformat
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Sat Sep 26 14:51:05 2020
From: report at bugs.python.org (KK Hiraskar)
Date: Sat, 26 Sep 2020 18:51:05 +0000
Subject: [New-bugs-announce] [issue41868] SMTPLIB integrate or provide
 option to use "logging"
Message-ID: <1601146265.03.0.468460712956.issue41868@roundup.psfhosted.org>


New submission from KK Hiraskar <hpkkumar007 at gmail.com>:

Currently "smtplib" is directly printing data to stdout/stderr, and not getting any good way to get this data in to the logs written by "logging"

please provide an option to achieve this.

----------
components: email
messages: 377537
nosy: barry, hpkkumar007, r.david.murray
priority: normal
severity: normal
status: open
title: SMTPLIB integrate or provide option to use "logging"
type: enhancement

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

From report at bugs.python.org  Sat Sep 26 21:06:35 2020
From: report at bugs.python.org (Michael L. Boom)
Date: Sun, 27 Sep 2020 01:06:35 +0000
Subject: [New-bugs-announce] [issue41869] Multiprocessing Manager Object
 Cleanup
Message-ID: <1601168795.22.0.608352680719.issue41869@roundup.psfhosted.org>


New submission from Michael L. Boom <mikeboom at mikeboom.com>:

I have a program that is running a multiprocessing manager.  Other programs connect and get proxies for objects.  If those programs close cleanly, the destructor in the multiprocessing manager for the corresponding object gets called.  If I kill that program, the destructor never gets called.  This is a serious problem as I can?t cleanup resources in this case.

----------
components: Library (Lib)
messages: 377551
nosy: boom0192
priority: normal
severity: normal
status: open
title: Multiprocessing Manager Object Cleanup
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Sun Sep 27 09:20:58 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 27 Sep 2020 13:20:58 +0000
Subject: [New-bugs-announce] [issue41870] Use PEP 590 vectorcall to speed up
 calls to bool()
Message-ID: <1601212858.37.0.301484827373.issue41870@roundup.psfhosted.org>


New submission from Dong-hee Na <donghee.na92 at gmail.com>:

bool type is well-used builtin types, I noticed that if we use vector call to bool type, it shows the awesome performance enhancement.

Mean +- std dev: [master] 91.4 us +- 3.3 us -> [vectorcall] 48.6 us +- 3.1 us: 1.88x faster (-47%)

----------
assignee: corona10
files: bench_bool.py
messages: 377565
nosy: corona10, vstinner
priority: normal
severity: normal
status: open
title: Use PEP 590 vectorcall to speed up calls to bool()
type: performance
versions: Python 3.10
Added file: https://bugs.python.org/file49475/bench_bool.py

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

From report at bugs.python.org  Sun Sep 27 09:30:06 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 27 Sep 2020 13:30:06 +0000
Subject: [New-bugs-announce] [issue41871] Add PyList_Remove() in listobject.c
Message-ID: <1601213406.91.0.754630281807.issue41871@roundup.psfhosted.org>


New submission from hai shi <shihai1991 at 126.com>:

Do we need add PyList_Remove() in C level? same thing like list.remove().
As victor comment in: https://github.com/python/cpython/pull/19069#discussion_r491893466.

----------
components: C API
messages: 377566
nosy: shihai1991, vstinner
priority: normal
severity: normal
status: open
title: Add PyList_Remove() in listobject.c
versions: Python 3.10

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

From report at bugs.python.org  Sun Sep 27 09:58:04 2020
From: report at bugs.python.org (Chris Withers)
Date: Sun, 27 Sep 2020 13:58:04 +0000
Subject: [New-bugs-announce] [issue41872] get_type_hints fails to resolve
 forward references in nested function
Message-ID: <1601215084.02.0.220244006466.issue41872@roundup.psfhosted.org>


New submission from Chris Withers <chris at withers.org>:

Reproducer:

    def test_forward_type_references(self):
        def foo(a: 'Foo') -> 'Bar': pass

        class Foo: pass
        class Bar: pass

        get_type_hints(foo)


The above gives the following exception, rather than resolving the type:

/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/typing.py:1001: in get_type_hints
    value = _eval_type(value, globalns, localns)
/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/typing.py:260: in _eval_type
    return t._evaluate(globalns, localns)
/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/typing.py:464: in _evaluate
    eval(self.__forward_code__, globalns, localns),
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

>   ???
E   NameError: name 'Foo' is not defined

----------
components: Library (Lib)
messages: 377569
nosy: cjw296
priority: normal
severity: normal
status: open
title: get_type_hints fails to resolve forward references in nested function
type: behavior
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Sep 28 04:55:08 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Mon, 28 Sep 2020 08:55:08 +0000
Subject: [New-bugs-announce] [issue41873] Add vectorcall for float()
Message-ID: <1601283308.14.0.0300181585929.issue41873@roundup.psfhosted.org>


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

I got these benchmarks:

.\python.bat -m pyperf timeit "float(0)"

Before: Mean +- std dev: 79.0 ns +- 1.0 ns
After:  Mean +- std dev: 51.5 ns +- 1.6 ns

----------
components: Interpreter Core
messages: 377590
nosy: Dennis Sweeney
priority: normal
severity: normal
status: open
title: Add vectorcall for float()
type: performance
versions: Python 3.10

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

From report at bugs.python.org  Mon Sep 28 06:55:46 2020
From: report at bugs.python.org (Red Rooster)
Date: Mon, 28 Sep 2020 10:55:46 +0000
Subject: [New-bugs-announce] [issue41874] datetime.strptime raises error if
 date is before 1900
Message-ID: <1601290546.43.0.7600207822.issue41874@roundup.psfhosted.org>


New submission from Red Rooster <mark.muzenhardt at googlemail.com>:

This fails, because the date is before 1900:
d = datetime.strptime("28. Februar 1899", '%d. %B %Y')

But the opposite conversion direction works:
d=datetime(1899,2,28)
d.strftime('%d. %B %Y')

prints out "28. Februar 1899" as it should be.

----------
components: Library (Lib)
messages: 377592
nosy: redrooster
priority: normal
severity: normal
status: open
title: datetime.strptime raises error if date is before 1900
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Mon Sep 28 07:15:51 2020
From: report at bugs.python.org (yota moteuchi)
Date: Mon, 28 Sep 2020 11:15:51 +0000
Subject: [New-bugs-announce] [issue41875] __builtin_unreachable error in gcc
 4.4.5
Message-ID: <1601291751.72.0.463788017117.issue41875@roundup.psfhosted.org>


New submission from yota moteuchi <yota.news at gmail.com>:

While compiling a very recent release of Python (ie. 3.9.0rc2) with a fairly old release of gcc (ie. debian 6.0.6 gcc 4.4.5) I get the following error :

gcc -pthread -c -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall    -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -fvisibility=hidden  -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o Parser/pegen/pegen.o Parser/pegen/pegen.c

Parser/pegen/pegen.c: In function ?_PyPegen_seq_count_dots?:
Parser/pegen/pegen.c:1414: error: implicit declaration of function ?__builtin_unreachable?

Indeed, this '__builtin_unreachable()' function will exists starting from gcc 4.5.

The configure file could detect this and offer an alternative.

(does a table of the supported gcc release for each python versions exists ?)

----------
components: Build
messages: 377594
nosy: yota moteuchi
priority: normal
severity: normal
status: open
title: __builtin_unreachable error in gcc 4.4.5
type: compile error
versions: Python 3.9

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

From report at bugs.python.org  Mon Sep 28 11:33:27 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 28 Sep 2020 15:33:27 +0000
Subject: [New-bugs-announce] [issue41876] Add __repr__ for Tkinter Font
 objects
Message-ID: <1601307207.95.0.784900613947.issue41876@roundup.psfhosted.org>


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

Currently Font objects have default repr:

    <tkinter.font.Font object at 0x7fa22c3bd1e0>

Since Font is just an object oriented wrapper for font name, and Font objects with the same name are equal, it is worth to show the font name in the repr and do not show an id.

    <tkinter.font.Font object 'TkDefaultFont'>

----------
components: Tkinter
keywords: easy
messages: 377603
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Add __repr__ for Tkinter Font objects
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Mon Sep 28 14:19:17 2020
From: report at bugs.python.org (=?utf-8?b?VsOhY2xhdiBCcm/FvmVr?=)
Date: Mon, 28 Sep 2020 18:19:17 +0000
Subject: [New-bugs-announce] [issue41877] Check against misspellings of
 assert etc. in mock
Message-ID: <1601317157.88.0.730935461305.issue41877@roundup.psfhosted.org>


New submission from V?clav Bro?ek <vabr at google.com>:

Recently we cleaned up the following typos in mocks in unittests of our codebase:

* Wrong prefixes of mock asserts: asert/aseert/assrt -> assert
* Wrong attribute names around asserts: autospect/auto_spec -> autospec, set_spec -> spec_set

Especially the asserts are dangerous, because a misspelled assert_called will fail silently. We found real bugs in production code which were masked by a misspelled assert_called.

There is prior work done to report similar cases of assert misspellings with an AttributeError: https://github.com/testing-cabal/mock/commit/7c530f0d9aa48d2538501761098df7a5a8979a7d, and adding new cases will be an easy change. I suppose that adding similar error signalling for the wrong argument names will not be much harder.

I'm prepared to implement it, if people of this project would be happy to have such checks.

----------
components: Library (Lib)
messages: 377611
nosy: vabr2
priority: normal
severity: normal
status: open
title: Check against misspellings of assert etc. in mock
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Mon Sep 28 15:12:20 2020
From: report at bugs.python.org (Robert Haschke)
Date: Mon, 28 Sep 2020 19:12:20 +0000
Subject: [New-bugs-announce] [issue41878] python3 fails to use custom
 dict-like object as symbols in eval()
Message-ID: <1601320340.36.0.581578891193.issue41878@roundup.psfhosted.org>


New submission from Robert Haschke <haschke.robert at gmail.com>:

The attached file implements a custom dict-like class (MyDict) as a minimal example of code I am using in a larger codebase. 
Before you ask, why I reimplemented a dict-like object: The real code base employs a hierarchical dict, referencing recursively to the parent dict, if a key cannot be found in the current dict.

The main code of the file defines two entries/variables for this dict:
symbols = MyDict()
symbols['abc'] = '[1, 2, 3]'
symbols['xyz'] = 'abc + abc'

and eval_text('xyz', symbols) should evaluate to the python expression as you would have evaluated those variables in a python interpreter.
While this works for the first given expression (above), it fails for this one:
symbols['xyz'] = '[abc[i]*abc[i] for i in [0, 1, 2]]'

raising NameError: name 'abc' is not defined.
The same code works perfectly in python 2.7. Hence, I assume this is a bug in python3.

----------
files: buggy.py
messages: 377616
nosy: Robert Haschke
priority: normal
severity: normal
status: open
title: python3 fails to use custom dict-like object as symbols in eval()
versions: Python 3.8
Added file: https://bugs.python.org/file49476/buggy.py

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

From report at bugs.python.org  Mon Sep 28 16:15:35 2020
From: report at bugs.python.org (Nick Gaya)
Date: Mon, 28 Sep 2020 20:15:35 +0000
Subject: [New-bugs-announce] [issue41879] Outdated description of async
 iterables in documentation of async for statement
Message-ID: <1601324135.53.0.963696566223.issue41879@roundup.psfhosted.org>


New submission from Nick Gaya <nicholasgaya+github at gmail.com>:

The documentation for the `async for` statement incorrectly states that "An asynchronous iterable is able to call asynchronous code in its iter implementation". Actually, this behavior was deprecated in Python 3.6 and removed in Python 3.7.  As of Python 3.7, the `__aiter__()` method must return an asynchronous iterator directly.

Suggested fix: Update the `async for` statement description for Python 3.7+ to match the "Asynchronous Iterators" section in the data model documentation.

> An :term:`asynchronous iterator` can call asynchronous code in its *next* method.

Relevant documentation:
- https://docs.python.org/3/reference/compound_stmts.html#the-async-for-statement
- https://docs.python.org/3/reference/datamodel.html#asynchronous-iterators

----------
assignee: docs at python
components: Documentation
messages: 377621
nosy: docs at python, nickgaya
priority: normal
severity: normal
status: open
title: Outdated description of async iterables in documentation of async for statement
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Sep 28 16:15:56 2020
From: report at bugs.python.org (Ben Wolsieffer)
Date: Mon, 28 Sep 2020 20:15:56 +0000
Subject: [New-bugs-announce] [issue41880] Get Python include directories
 from sysconfigdata
Message-ID: <1601324156.19.0.410608433996.issue41880@roundup.psfhosted.org>


New submission from Ben Wolsieffer <benwolsieffer at gmail.com>:

The distutils.sysconfig.get_python_inc() function finds headers relative to sys.base_prefix or sys.base_exec_prefix. This causes problems when cross-compiling extension modules because Python's headers are not platform independent.

Instead, get_python_inc() should use the INCLUDEPY and CONFINCLUDEPY variables from sysconfigdata to find headers. The _PYTHON_SYSCONFIGDATA_NAME environment variable can then be used to make build arch Python load sysconfigdata from host arch Python.

----------
components: Cross-Build, Distutils
messages: 377622
nosy: Alex.Willmer, benwolsieffer, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: Get Python include directories from sysconfigdata
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Mon Sep 28 16:39:53 2020
From: report at bugs.python.org (Kevin Ardath)
Date: Mon, 28 Sep 2020 20:39:53 +0000
Subject: [New-bugs-announce] [issue41881] New Line escape issue in raw
 strings
Message-ID: <1601325593.83.0.504309665752.issue41881@roundup.psfhosted.org>


New submission from Kevin Ardath <ardath.kevin at gmail.com>:

When attempting to concatenate some strings with a new line, I observed that formatting braces in a raw string skipped a new line escape:

print(r'{{}}\nx'.format())

Produces:
{}\nx

Rather than:
{}
x

----------
messages: 377624
nosy: ardath.kevin
priority: normal
severity: normal
status: open
title: New Line escape issue in raw strings
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Mon Sep 28 19:04:08 2020
From: report at bugs.python.org (Mikhail Terekhov)
Date: Mon, 28 Sep 2020 23:04:08 +0000
Subject: [New-bugs-announce] [issue41882] CCompiler.has_function does not
 delete temporary files
Message-ID: <1601334248.35.0.2911303448.issue41882@roundup.psfhosted.org>


New submission from Mikhail Terekhov <termim at gmail.com>:

CCompiler.has_function does not delete temporary files. Depending on the 
check result it leaves temporary C source, object and executable files.

----------
components: Distutils
messages: 377646
nosy: dstufft, eric.araujo, termim
priority: normal
severity: normal
status: open
title: CCompiler.has_function does not delete temporary files
type: resource usage
versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Sep 28 23:40:06 2020
From: report at bugs.python.org (Ian M. Hoffman)
Date: Tue, 29 Sep 2020 03:40:06 +0000
Subject: [New-bugs-announce] [issue41883] ctypes pointee goes out of scope,
 then pointer in struct dangles and crashes
Message-ID: <1601350806.96.0.0908350548542.issue41883@roundup.psfhosted.org>


New submission from Ian M. Hoffman <hoffman.ian.m at gmail.com>:

A description of the problem, complete example code for reproducing it, and a work-around are available on SO at the link:

https://stackoverflow.com/questions/64083376/python-memory-corruption-after-successful-return-from-a-ctypes-foreign-function

In summary: (1) create an array within a Python function, (2) create a ctypes.Structure with a pointer to that array, (3) return that struct from the Python function, (4) pass the struct out and back to a foreign function, (5) Python can successfully dereference the return from the foreign function, then (6) Python crashes.

As far as I can tell, when the array in the function goes out of scope at the end of the function, the pointer to it in the struct becomes dangling ... but the dangling doesn't catch up with Python until the very end when the Python struct finally goes out of scope in Python and the GC can't find its pointee.

I've reproduced this on Windows and linux with gcc- and MSVC-compiled Python 3.6 and 3.8.

Perhaps it is not good practice on my part to have let the array go out of scope, but perhaps a warning from Python (or at least some internal awareness that the memory is no longer addressed) is in order so that Python doesn't crash upon failing to free it.

This may be related to #39217; I can't tell.

----------
components: ctypes
messages: 377652
nosy: NankerPhelge
priority: normal
severity: normal
status: open
title: ctypes pointee goes out of scope, then pointer in struct dangles and crashes
type: crash
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Tue Sep 29 08:56:02 2020
From: report at bugs.python.org (Raymond Sit)
Date: Tue, 29 Sep 2020 12:56:02 +0000
Subject: [New-bugs-announce] [issue41884] tempfile.py
 TemporaryDirectory/mkdtemp defaults to mode 0o700,
 propose to add mode argument
Message-ID: <1601384162.52.0.6703641276.issue41884@roundup.psfhosted.org>


New submission from Raymond Sit <raysit555 at gmail.com>:

`tempfile.TemporaryDirectory` always creates the directory with 0o700 permissions. So other applications which could run as a different user (i.e. root) cannot access the directory.

To improve the usability I would like to add the option to set the permissions of the directory.

Proposed Change is in the PR linked (https://github.com/python/cpython/pull/22451)

----------
components: Library (Lib)
files: tempfile.py
messages: 377667
nosy: ray-sit
priority: normal
pull_requests: 21480
severity: normal
status: open
title: tempfile.py TemporaryDirectory/mkdtemp defaults to mode 0o700, propose to add mode argument
type: enhancement
versions: Python 3.10
Added file: https://bugs.python.org/file49477/tempfile.py

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

From report at bugs.python.org  Tue Sep 29 11:00:37 2020
From: report at bugs.python.org (dkreeft)
Date: Tue, 29 Sep 2020 15:00:37 +0000
Subject: [New-bugs-announce] [issue41885] Unexpected behavior re.sub() with
 raw f-strings
Message-ID: <1601391637.99.0.417746893206.issue41885@roundup.psfhosted.org>


New submission from dkreeft <dkreeft at xccelerated.io>:

Steps to reproduce (Windows/Python 3.7.7):

1. Define replacement string that starts with an integer:

REPLACEMENT = '12345'

2. Use re.sub() as follows:

re.sub(r'([a-z]+)', fr"\1{REPLACEMENT}", 'something')

3. The outcome is not 'something12345' as expected, but 'J345'.

Note that I am using the group in the replacement argument, which is a raw f-string.

A quick investigation with other replacement strings renders similar unexpected behavior:

REPLACEMENT = '1': leads to re.error (invalid group reference 11 at position 1)
REPLACEMENT = '13': 'K'
etc.

So it seems like the f-string is evaluated first, yielding a string starting with an integer. Python then interprets the '\1' to indicate group 1 as '\1<first integer>', which leads to the behavior described above. Even if this is by design, it seems confusing and makes using groups with re.sub() cumbersome if the replacement f-string starts with an integer.

----------
components: Regular Expressions, Windows
messages: 377669
nosy: dkreeft, ezio.melotti, mrabarnett, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Unexpected behavior re.sub() with raw f-strings
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Tue Sep 29 16:58:03 2020
From: report at bugs.python.org (da-woods)
Date: Tue, 29 Sep 2020 20:58:03 +0000
Subject: [New-bugs-announce] [issue41886] PyType_Type is documented
 incorrectly
Message-ID: <1601413083.05.0.277057194365.issue41886@roundup.psfhosted.org>


New submission from da-woods <dw-git at d-woods.co.uk>:

In the documentation PyType_Type is listed as a "PyObject*" (https://docs.python.org/3/c-api/type.html#c.PyType_Type). This is misleading because it is both not a pointer and is a PyTypeObject.

Other type objects are documented as "PyTypeObject" (see unicode https://docs.python.org/3/c-api/unicode.html#c.PyUnicode_Type as an arbitrary example) so I think the documentation is just inconsistent for PyType_Type alone.

----------
assignee: docs at python
components: Documentation
messages: 377683
nosy: da-woods, docs at python
priority: normal
severity: normal
status: open
title: PyType_Type is documented incorrectly
versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Sep 29 21:46:57 2020
From: report at bugs.python.org (Saiyang Gou)
Date: Wed, 30 Sep 2020 01:46:57 +0000
Subject: [New-bugs-announce] [issue41887] ast.literal_eval does not accept
 strings with leading whitespaces
Message-ID: <1601430417.52.0.930336195437.issue41887@roundup.psfhosted.org>


New submission from Saiyang Gou <gousaiyang223 at gmail.com>:

`ast.literal_eval` does not accept code with leading whitespaces, while `eval` accepts them, which is an inconsistency.

```
>>> import ast
>>> eval(' 1')
1
>>> ast.literal_eval(' 1')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.9/ast.py", line 62, in literal_eval
    node_or_string = parse(node_or_string, mode='eval')
  File "/usr/local/lib/python3.9/ast.py", line 50, in parse
    return compile(source, filename, mode, flags,
  File "<unknown>", line 1
    1
IndentationError: unexpected indent
```

----------
components: Library (Lib)
messages: 377687
nosy: gousaiyang
priority: normal
severity: normal
status: open
title: ast.literal_eval does not accept strings with leading whitespaces
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Sep 29 23:06:11 2020
From: report at bugs.python.org (anthony shaw)
Date: Wed, 30 Sep 2020 03:06:11 +0000
Subject: [New-bugs-announce] [issue41888] Duplicate Opcode value in master
 and 3.9rc2
Message-ID: <1601435171.42.0.708807939591.issue41888@roundup.psfhosted.org>


New submission from anthony shaw <anthonyshaw at apache.org>:

I noticed that HAVE_ARGUMENT and STORE_NAME have the same value (90) in Include/opcode.h in both the source code and in the 2bd31b5f revision (3.9.0rc2).

This must be creating some weird bugs.

https://github.com/python/cpython/blob/582aaf19e8b94a70c1f96792197770d604ba0fdf/Include/opcode.h#L70-L71

----------
components: Interpreter Core
messages: 377688
nosy: anthonypjshaw
priority: normal
severity: normal
status: open
title: Duplicate Opcode value in master and 3.9rc2
type: compile error
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Wed Sep 30 00:21:36 2020
From: report at bugs.python.org (puddly)
Date: Wed, 30 Sep 2020 04:21:36 +0000
Subject: [New-bugs-announce] [issue41889] enum: Mixin and int base class
 regression in 3.8.6
Message-ID: <1601439696.58.0.28102514399.issue41889@roundup.psfhosted.org>


New submission from puddly <puddly3 at gmail.com>:

The following code worked in 3.8.5 but does not in 3.8.6 due to the fix for #39587:

```
import enum


class MyInt(int):
    def __new__(cls, value):
        return super().__new__(cls, value)

class HexMixin:
    def __repr__(self):
        return hex(self)

class MyIntEnum(HexMixin, MyInt, enum.Enum):
    pass


class Foo(MyIntEnum):
    TEST = 1

assert isinstance(Foo.TEST, MyInt)
assert repr(Foo.TEST) == "0x1"
```


In 3.8.6, the `Foo` enum itself fails to be created because `HexMixin` is now considered the member type instead of `MyInt`:

```
Traceback (most recent call last):
  File "enum_test.py", line 18, in <module>
    class Foo(MyIntEnum):
  File "/usr/local/Cellar/python at 3.8/3.8.6/Frameworks/Python.framework/Versions/3.8/lib/python3.8/enum.py", line 215, in __new__
    enum_member = __new__(enum_class)
TypeError: object.__new__(Foo) is not safe, use int.__new__()
```

----------
components: Library (Lib)
messages: 377692
nosy: barry, eli.bendersky, ethan.furman, puddly
priority: normal
severity: normal
status: open
title: enum: Mixin and int base class regression in 3.8.6
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Sep 30 04:41:57 2020
From: report at bugs.python.org (Hazem Amara)
Date: Wed, 30 Sep 2020 08:41:57 +0000
Subject: [New-bugs-announce] [issue41890] crypt produces wrong hashes for
 passwords containing newline character
Message-ID: <1601455317.01.0.940646263522.issue41890@roundup.psfhosted.org>


New submission from Hazem Amara <amarahzm at gmail.com>:

I am having an issue with crypt library (Lib/crypt.py) when hashing passwords containing \n character. I am using python 3.8.2 on Linux.  To compare hashed passwords produced by crypt, I used openssl and mkpasswd utilities. 

When generating hashes for password without \n, crypt, openssl and mkpasswd return the same result:

openssl passwd -6 -salt "saltySalt" "password"
$6$saltySalt$0zG/rneQmcu2mKFi/xXKF5WVH4ald6AlPTwnSRggVpyu7iRbq9buUmS5gD884iB1seAPw3UehNZ/b.jxL0g4Y/

mkpasswd -S "saltySalt" -m sha-512 "password"
$6$saltySalt$0zG/rneQmcu2mKFi/xXKF5WVH4ald6AlPTwnSRggVpyu7iRbq9buUmS5gD884iB1seAPw3UehNZ/b.jxL0g4Y/

python3 -c 'import crypt; print(crypt.crypt("password","$6$saltySalt"))'
$6$saltySalt$0zG/rneQmcu2mKFi/xXKF5WVH4ald6AlPTwnSRggVpyu7iRbq9buUmS5gD884iB1seAPw3UehNZ/b.jxL0g4Y/


But when generating hashes for passwords containing \n character, crypt returns a result different from the result returned by openssl and mkpasswd: 

openssl passwd -6 -salt "saltySalt" "password\n"
$6$saltySalt$v.6rXp74bIjKX42ufuY7/KWnngOAgFReenROiPODOQYzlRuE2NT4/Bgs8s4ULd3BgKNZQQ7i9GqlibMhRw2SV1
 
mkpasswd -S "saltySalt" -m sha-512 "password\n"
$6$saltySalt$v.6rXp74bIjKX42ufuY7/KWnngOAgFReenROiPODOQYzlRuE2NT4/Bgs8s4ULd3BgKNZQQ7i9GqlibMhRw2SV1
 
python3 -c 'import crypt; print(crypt.crypt("password\n","$6$saltySalt"))'
$6$saltySalt$hsmSR02RXIRP5U14cDo3wtwLCOD1Lb/9huWQEuJYRyatQjRjXmzYJI9rpfqys8ucIc.GbymuE3a5DVcLzSxn5/


I did not find a special mention for newline character in the documentation. Thanks for your help.

----------
components: Library (Lib)
messages: 377694
nosy: amarahzm
priority: normal
severity: normal
status: open
title: crypt produces wrong hashes for passwords containing newline character
versions: Python 3.8

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

From report at bugs.python.org  Wed Sep 30 07:01:52 2020
From: report at bugs.python.org (Richard Kojedzinszky)
Date: Wed, 30 Sep 2020 11:01:52 +0000
Subject: [New-bugs-announce] [issue41891] asyncio.wait_for does not wait for
 task/future to be completed in all cases
Message-ID: <1601463712.11.0.444677837126.issue41891@roundup.psfhosted.org>


New submission from Richard Kojedzinszky <richard at kojedz.in>:

This code should run without errors:

```
#!/usr/bin/env python

import asyncio

async def task1():
    cv = asyncio.Condition()

    async with cv:
        await asyncio.wait_for(cv.wait(), 10)

async def main(loop):
    task = loop.create_task(task1())

    await asyncio.sleep(0)

    task.cancel()

    res = await asyncio.wait({task})

if __name__ == '__main__':
    loop = asyncio.get_event_loop()

    loop.run_until_complete(main(loop))
```

----------
components: asyncio
messages: 377695
nosy: asvetlov, rkojedzinszky, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.wait_for does not wait for task/future to be completed in all cases
type: behavior
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Wed Sep 30 10:20:25 2020
From: report at bugs.python.org (WoodyWoo)
Date: Wed, 30 Sep 2020 14:20:25 +0000
Subject: [New-bugs-announce] [issue41892] use both "for" and
 "ElementTree.remove" has a index bug
Message-ID: <1601475625.07.0.195514916094.issue41892@roundup.psfhosted.org>


New submission from WoodyWoo <saulmatchless at 163.com>:

#Just run it in Python v3.8.6 of win7 32bit 
import xml.etree.ElementTree as ET 
xmlstr='''<root>
<a no="1"/>
<b/>
<c/>
</root>'''
etroot = ET.fromstring(xmlstr)
for ELEMchild in etroot:
    if ELEMchild.get("no") == "1" :
        etroot.remove(ELEMchild)       #so far so good
    print (ELEMchild.tag)
    #It should be :  "b /n c" or "a /n b /n c",I can live with it both.
    #But it is :  "a /n c".
    #The index of ELEMchild should not +1 when there was a remove method worked on one of the before ELEMs.
    #I was forced to use while and if to control the index +1/+0.
    #BTW,ELEM has no method returning index in siblings, which is buging me too.

----------
components: XML
messages: 377698
nosy: WoodyWoo
priority: normal
severity: normal
status: open
title: use both "for" and "ElementTree.remove" has a index bug
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Wed Sep 30 11:45:40 2020
From: report at bugs.python.org (pushpam kumar)
Date: Wed, 30 Sep 2020 15:45:40 +0000
Subject: [New-bugs-announce] [issue41893] remove() method is not working as
 expected(Hard to explain)
Message-ID: <1601480740.82.0.874646425374.issue41893@roundup.psfhosted.org>


New submission from pushpam kumar <ctf.challenge.pushpam at gmail.com>:

I am not able to understand why "password" word is not removed by remove() method

----------
components: Interpreter Core
files: testtt.py
messages: 377708
nosy: ctf.challenge.pushpam
priority: normal
severity: normal
status: open
title: remove() method is not working as expected(Hard to explain)
versions: Python 3.8
Added file: https://bugs.python.org/file49478/testtt.py

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

From report at bugs.python.org  Wed Sep 30 13:26:23 2020
From: report at bugs.python.org (Kevin)
Date: Wed, 30 Sep 2020 17:26:23 +0000
Subject: [New-bugs-announce] [issue41894] UnicodeDecodeError during load
 failure in non-UTF-8 locale
Message-ID: <1601486783.26.0.906458411993.issue41894@roundup.psfhosted.org>


New submission from Kevin <kadler at us.ibm.com>:

If a native module fails to load, the dynload code will call PyUnicode_FromString on the error message to give back to the user. This can cause a UnicodeDecodeError if the locale is not a UTF-8 locale and the error message contains non-ASCII code points.

While Linux systems almost always use a UTF-8 locale by default nowadays, AIX systems typically use non-UTF-8 locales by default. We encountered an issue where a customer did not have libbz2 installed, causing a load failure when bz2 tried to import _bz2 when running in an Italian locale:

$ LC_ALL=it_IT python3 -c 'import bz2'        
Traceback (most recent call last): 
 File "<string>", line 1, in <module> 
 File "/QOpenSys/pkgs/lib/python3.6/bz2.py", line 21, in <module> 
   from _bz2 import BZ2Compressor, BZ2Decompressor 
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe8 in position 161: invalid continuation byte

After switching to a UTF-8 locale, the problem goes away:

$ LC_ALL=IT_IT python3 -c 'import bz2'   
Traceback (most recent call last): 
 File "<string>", line 1, in <module> 
 File "/QOpenSys/pkgs/lib/python3.6/bz2.py", line 21, in <module> 
   from _bz2 import BZ2Compressor, BZ2Decompressor 
ImportError:    0509-022 Impossibile caricare il modulo /QOpenSys/pkgs/lib/python3.6/lib-dynload/_bz2.so. 
       0509-150   Il modulo dipendente libbz2.so non ? stato caricato. 
       0509-022 Impossibile caricare il modulo libbz2.so. 
       0509-026 Errore di sistema: Un file o una directory nel nome percorso non esiste. 
       0509-022 Impossibile caricare il modulo /QOpenSys/pkgs/lib/python3.6/lib-dynload/_bz2.so. 
       0509-150   Il modulo dipendente /QOpenSys/pkgs/lib/python3.6/lib-dynload/_bz2.so non ? stato caricato.


While this conceivably affects any Unix-like platform, the only system I can recreate it on is AIX and IBM i PASE. As far as I can tell, on Linux you will always get something like "error while loading shared libraries: libbz2.so.1.0: cannot open shared object file: No such file or directory". Even though there seems to be some translations in GLIBC, I have been unable to get them to be used on either Fedora or Ubuntu.

----------
components: Interpreter Core
messages: 377713
nosy: kadler
priority: normal
severity: normal
status: open
title: UnicodeDecodeError during load failure in non-UTF-8 locale
type: behavior
versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Sep 30 13:38:05 2020
From: report at bugs.python.org (dexter)
Date: Wed, 30 Sep 2020 17:38:05 +0000
Subject: [New-bugs-announce] [issue41895] PyMethodDef does NOT have any
 field contains context in embedded C
Message-ID: <1601487485.79.0.674367935184.issue41895@roundup.psfhosted.org>


New submission from dexter <nan.nine at outlook.com>:

I am trying to create app embedded python as interpreter, and I use PyImport_AppendInittab to import some helper functions to python. on website the example is excellent when you already know how many functions we want to import. but when my functions are based on a runtime dynamic list, even I create all PyModuleDef and PyMethodDef, but when the function all goes to PyCFunction which only has two PyObject* and return PyObject* i lost context information about C. may be I am not clear, but what I am expecting is PyMethodDef should define like
struct PyMethodDef {
    const char  *ml_name;   /* The name of the built-in function/method */
    PyCFunction ml_meth;    /* The C function that implements it */
    int         ml_flags;   /* Combination of METH_xxx flags, which mostly
                               describe the args expected by the C func */
    const char  *ml_doc;    /* The __doc__ attribute, or NULL */
    void* extra; /* <================= here is NEW */ 
};

and PyCFunction should define like

typedef PyObject *(*PyCFunction)(PyObject *, PyObject *, void * /* for extra void* */);

----------
components: C API
messages: 377714
nosy: dexter
priority: normal
severity: normal
status: open
title: PyMethodDef does NOT have any field contains context in embedded C
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Wed Sep 30 14:28:10 2020
From: report at bugs.python.org (Tama-kun)
Date: Wed, 30 Sep 2020 18:28:10 +0000
Subject: [New-bugs-announce] [issue41896] Moving index with wordstart
 expression includes non-alphanumberic and underline characters if word is
 tagged and iat the edge of a text widget
Message-ID: <1601490490.12.0.958872838055.issue41896@roundup.psfhosted.org>


New submission from Tama-kun <Tama-sama at outlook.com>:

This issue occurs when using the current mouse position from an event and the wordstart expression to find the index of the start of a clicked word on a text widget and the indices for the clicked word are tagged. If there's a single non-alphanumberic and underline character between the clicked word and the left edge of the text widget the index return for the start of the word will be the one for said non-alphanumeric and underline character. 

test.index(('@%s,%s wordstart' % (event.x, event.y)))

Assuming "[testing]" is at the indices 1.0 to 1.9 of a text widget, clicking on testing will return 1.1. If we tag the indices 1.1 to 1.8 with test.tag_add("tag", 1.1, 1.8) then clicking on the word testing will return 1.0. This change of return doesn't occur if "[testing]" does not begin at a x.0 index or if there's multiple non-alphanumeric and underline characters such as "[[testing]". Using wordend will return 1.8 in both tagged and non tagged scenarios.

The attached script illustrates this bug, only the middle text widget will print out the unexpected start index when clicking on the word testing. This issue isn't present when using python 3.5, running the script on python 3.5 will print out all expected indices.

----------
components: Tkinter
files: test.py
messages: 377716
nosy: Tama-kun, gpolo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Moving index with wordstart expression includes non-alphanumberic and underline characters if word is tagged and iat the edge of a text widget
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file49479/test.py

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

From report at bugs.python.org  Wed Sep 30 14:55:04 2020
From: report at bugs.python.org (Saiyang Gou)
Date: Wed, 30 Sep 2020 18:55:04 +0000
Subject: [New-bugs-announce] [issue41897] ast.parse in Python 3.9 does not
 produce SyntaxError for assignment to __debug__
Message-ID: <1601492104.09.0.103643328706.issue41897@roundup.psfhosted.org>


New submission from Saiyang Gou <gousaiyang223 at gmail.com>:

ast.parse in Python 3.9 does not produce SyntaxError for assignment to __debug__:

```
>>> import ast
>>> ast.dump(ast.parse('__debug__ = 0'))
"Module(body=[Assign(targets=[Name(id='__debug__', ctx=Store())], value=Constant(value=0))], type_ignores=[])"
>>> exec('__debug__ = 0')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1
SyntaxError: cannot assign to __debug__
```

In Python 3.8 a SyntaxError was properly raised. Probably this is due to the new PEG parser.

----------
components: Library (Lib)
messages: 377717
nosy: gousaiyang
priority: normal
severity: normal
status: open
title: ast.parse in Python 3.9 does not produce SyntaxError for assignment to __debug__
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Wed Sep 30 15:13:37 2020
From: report at bugs.python.org (Troy Daniels)
Date: Wed, 30 Sep 2020 19:13:37 +0000
Subject: [New-bugs-announce] [issue41898] Any logging causes assertLogs to
 pass
Message-ID: <1601493217.83.0.77998878518.issue41898@roundup.psfhosted.org>


New submission from Troy Daniels <udalrich.schermer at gmail.com>:

The following test code unexpectedly passes.

import logging
import unittest

LOG_FORMAT = '%(levelname)-10s %(asctime)s: %(message)s'


def set_up_logger(app_name, level=logging.INFO, file="test.log"):
    formatter = logging.Formatter(LOG_FORMAT)
    log = logging.getLogger(app_name)
    # The next line lets the test pass
    log.setLevel(level)
    return log

logger = set_up_logger(__name__)

class TestLogging(unittest.TestCase):
    def test_logging(self):
        with self.assertLogs(level=logging.WARNING):
            logger.info('foo')

Based on discussion at https://stackoverflow.com/questions/64141681/any-level-of-logging-lets-assertlogs-pass, it appears that I need to pass in the logger which is going to be doing the logging.  

Doing so would make the test over-specific and fragile.  The requirement is that a warning be logged, not that a specific logger issue the warning.

This was verified with Python 3.8.5 on a Mac, but probably exists in most/all other versions.

----------
components: Tests
messages: 377719
nosy: udalrich.schermer
priority: normal
severity: normal
status: open
title: Any logging causes assertLogs to pass
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Wed Sep 30 20:08:35 2020
From: report at bugs.python.org (WoodyWoo)
Date: Thu, 01 Oct 2020 00:08:35 +0000
Subject: [New-bugs-announce] [issue41899] Poor example for Element.remove()
Message-ID: <1601510915.6.0.455772572055.issue41899@roundup.psfhosted.org>


New submission from WoodyWoo <saulmatchless at 163.com>:

We can remove elements using Element.remove(). Let?s say we want to remove all countries with a rank higher than 50:

>>>
>>> for country in root.findall('country'):
...     rank = int(country.find('rank').text)
...     if rank > 50:
...         root.remove(country)
...
>>> tree.write('output.xml')

When the original xml has over 2 country with  rank>50,and they are one by one neighborly siblings element,the upper code will delete the 1st 3rd 5th and more odd No. country.
A proper example should be:
index=0
while index < len(root.findall("./*")):
    rank = int (root[index].find("rank").text)
    if rank>50:
        root.remove(root[index])
        index=index+0
        continue
    index=index+1


I think "for each in list" should not work by index,but should work by pointer like thing,could be a list of pointers.
A finial solution should be like this --- when the "for each in list" was acting,the pointers list would be fixed,and you need not to worry about the "list" changing.

----------
assignee: docs at python
components: Documentation
messages: 377726
nosy: WoodyWoo, docs at python
priority: normal
severity: normal
status: open
title: Poor example for Element.remove()
type: behavior
versions: Python 3.8

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